07:16 buduar: so with nuclear chipsets and having googling done on them, it's pretty devastating , that soon you will meet very nasty and suicidal duffy duck that you might have to kill to get access to any kind of chance continuing your life a bit longer. But for me the risk was fine, cause such ducks terrorised me upfront cause of my genetics, so their agent was some simon who was very obnoxious suicidal leftover, and the snitches were of course our local
07:16 buduar: leftovers from birth, most the credit goes to those clowns. But they are soon done in a war i believe.
07:16 buduar: this is such regulation that nuclear tech should not be talked about, they start to squeeze your nuts
08:47 averne: airlied: Hi, I've been working on an FFmpeg hwaccel for the Nintendo Switch (NVidia Tegra X1). Due to the nature of the platform it's pretty low level code, as I have to fill out hardware structures (the ones on https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/nvdec_drv.h), and talk to the NVDEC engine through ioctls. It primarily targets the Nintendo Switch OS, but also works on Linux4Tegra.
08:47 averne: Lynne from #ffmpeg-devel told me you'd be potentially interested in that code, as you were working on a vulkan-decode backend for nvk, so here it is: https://github.com/averne/FFmpeg/tree/tx1. Apparently you got a mesa branch into a state where you could submit commands. Can I ask where to find it? I'd be interested in contributing to nvk.
08:55 DodoGTA: averne: The NVK code is now in the main Mesa repository on GitLab
09:00 averne: Yes, but I think this was a WIP branch (not mainlined). I looked on his gitlab but couldn't find it.
09:01 DodoGTA: averne: https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/nouveau/vulkan
09:05 averne: Thanks but there's no vulkan-video code there as far as I can tell
09:08 DodoGTA: averne: I don't think anyone has worked on Vulkan video support for NVK
09:10 averne: I was told airlied had some WIP code, we'll see when he's up
09:18 fdobridge: <a​irlied> Yeah I hadn't done much useful yet, was going to start playing around soon
09:19 fdobridge: <a​irlied> I don't think the hw is exact same as Tegra but should be pretty close
09:19 fdobridge: <a​irlied> And I can dump cmdstreams easy enough
09:22 averne: Let me know if I can be of help then, I think the nvk project is very cool and I'd be excited to contribute. I haven't tried reverse engineering the cuvid libs, but indeed I think it should be rather close. The main different thing would be the dma mapping and cmdbuf submission, since Tegras use unified memory
09:23 averne: Also I'm curious, how do you dump the command streams? I used an LD_PRELOAD stub myself, but I know the nouveau project has some stuff to dump mmio accesses and so on
09:39 fdobridge: <a​irlied> I just booked Vulkan endcommandbuffer
09:39 fdobridge: <a​irlied> Hooked
09:39 fdobridge: <a​irlied> With a layer and poked around inside the cmdbuffer ptr
09:47 averne: I see, thanks
09:49 marliere: when i click in a bookmarks dropdown menu in firefox it crashes if the folder has too many (enough to cover the entire screen), is it possible that its something related to nouveau?
09:50 marliere: it flickers for a while then crashes
09:53 karolherbst: possibly
09:53 karolherbst: any errors in dmesg?
10:03 marliere: no :(
10:05 karolherbst: annoying
10:05 karolherbst: what mesa version are you on?
10:05 marliere: im gonna launch sway with debug logs to see if it says anything
10:06 marliere: im running debian stable, mesa-va-drivers/stable,now 22.3.6-1+deb12u1 mesa-vdpau-drivers/stable,now 22.3.6-1+deb12u1 mesa-vulkan-drivers/stable,now 22.3.6-1+deb12u1
10:11 karolherbst: gfxstrand: ehhh... so I moved things around a little (explicit_io before opt_memcpy) and now opt_memcpy replaces it with a `copy_deref` and I run into the same issue again :') But it seems like that for some copies of arrays, opt_memcpy requires assigned types otherwise it crashes
10:12 karolherbst: ohh wrong channel
10:13 karolherbst: marliere: mhh.. could be some broken state tracking from 22.3. There has been some fixes. In any case, if you get EoL software (which mesa 22.3 is) from your distribution you'd have to file a bug against your distribution instead unless you can show that this bug persists using a supported mesa version/driver
10:17 marliere: understood. if sway logs doesnt show anything ill test 23.1
10:18 marliere: thanks!
10:20 karolherbst: hopefully it's fixed with 23.1, feel free to open a bug and everything. Normally we do test Firefox regularly, but 22.3 landed a huge rework (some threading fixes) and it impacts Firefox as well and there have been regressions from that
10:50 marliere: ah! fixed indeed :)
10:51 karolherbst: cool
14:02 buduar: Anyway i will volunteer to do that compiler, but for free contribution it takes a bit time, it does look like i had a mistake in the channel log, so the point of encoding 1 2 3 , 2 3 4, 4 5 6 ... is just a view where every operand appears twice, it's visual aid, so as other encoding is 1 2 3 , 4 5 6, 7 8 9 and twice of that since two operands, when you make indirection from there, you can look if two 4's are added it will end up in 6 and 7
14:02 buduar: index so 13 if however 2 and 6 , you have 2 and 9 11, was suppose to be random example , it compresses a bit more than two separate fully contiguous offsets. so with three operands it would be 1 2 3 , 3 2 1, 2 1 3.... now every value appears three times, but overall it's really whatever, something can be pushed and materialized with little effort.
14:25 Ermine: karolherbst, airlied, ^ this guy again. Requesting banhammer
14:58 marliere: what was that about?
15:00 DodoGTA: marliere: There's a weird person that comes in the Linux IRC channels sometimes
15:00 marliere: word
15:00 Ermine: Linux graphics-related channels namely
19:36 fdobridge: <g​fxstrand> Yeah, he's been around a while
19:36 fdobridge: <g​fxstrand> Used to rant in my DMs for hours
19:36 fdobridge: <g​fxstrand> He stoped several years back
21:22 fdobridge: <p​homes> gfxstrand: hi. I wanted to implement VK_EXT_pipeline_creation_cache_control and VK_EXT_pipeline_creation_feedback
21:22 fdobridge: <p​homes> I guess I need to implement some caching in NVK first. I studied the common pipeline cache implementation plus a few of the drivers
21:22 fdobridge: <p​homes> with that I have played around with caching nir in NVK, which seems to work
21:22 fdobridge: <p​homes> Before I continue. Do you think this is a task I could take on?