03:08 alyssa: mareko: I filed a ticket asking for CTS for that, ages ago
12:20 Lynne: wake up, new descriptor API just dropped
12:21 Lynne: this time it's the right API with no issues whatsoever! it's the future
12:21 Lynne: > VK_EXT_descriptor_heap
12:21 Lynne: > VK_EXT
12:21 Lynne: RIP, it's not the future
12:33 austriancoder: gfxstrand: if you have some spare minutes, would be great if you could look at this single commit from an already reviewed MR. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38929/diffs?commit_id=635f22e8f252c49578d9e3281149be4f66781a7d
13:46 alyssa: Lynne: Lol
13:58 Lynne: at least they dropped internally synchronized queues
13:59 Lynne: is there a plan to how to handle them in mesa? a threaded dispatch like with opengl/vaapi?
14:01 mareko: does more than 1 gl/vaapi driver do threaded dispatch?
14:03 mareko: for kernel queues, no threaded dispatch is needed since the kernel has its own mutex
14:04 mareko: for user queues, we need a mutex around ring buffer writes
14:10 dj-death: Lynne: just lock
14:17 Lynne: that's a very wide and inefficient way of solving the issue
14:17 Lynne: I plan to have ffmpeg *hard* depend on the extension
14:17 Lynne: so it would be nice for it to be efficient
14:18 mareko: it's not going to be completely lockless, but the lock will move down the call stack
14:22 mareko: likely there had already been a lock downstream, so a lock in Vulkan apps was redundant
14:27 Lynne: I know, right!
14:28 Lynne: its the biggest mistake vulkan ever did
14:28 Lynne: by far
14:29 Lynne: they should have eliminated multiple queues too, it's the kernel's/firmware's job to schedule submits
14:29 bitblt: Is it possible to 'create' a fake display, similar to the one that can be created using the 'drm.edid_firmware=HDMI-A-1:edid/custom_edid.bin video=HDMI-A-1:e' kernel params, but after boot (by using some /sys toggles I don't know)?
14:31 bitblt: I know that the drm.edid_firmware option can be emulated after boot using 'echo HDMI-A-1:edid/custom_edid.bin > /sys/module/drm/parameters/edid_firmware'
14:32 bitblt: Is it possible to do after boot what the 'video=HDMI-A-1:e' kernel param does too?
14:36 mareko: a lot of HW supports multiple queues
14:45 Lynne: mareko: yes, and the kernel hides them and does scheduling
14:47 Lynne: the kernel hides the multiple video decode queues on AMD, for better or worse
14:48 MrCooper: bitblt: does it have to be a "real" driver, or could vkms work for your use case?
14:50 bitblt: it has to be a real driver, the target is to be able to spawn plasmashell in a headless machine with a real graphics card, and connect to it using sunshine/moonlight
14:51 bitblt: this is achievable if I use the above kernel params, but I want to see if its possible for the fake output to be toggled after booting
14:52 zamundaaa[m]: [@_oftc_bitblt:matrix.org](https://matrix.to/#/@_oftc_bitblt:matrix.org) afaik sunshine very recently gained support for portals, so you shouldn't need any kernel side stuff to create a "fake" output
14:55 bitblt: zamundaaa[m]: how would this work in a system that is completely headless?
14:58 zamundaaa[m]: If there is a KMS node, it'll work fine. KWin doesn't care if there's an output connected or not
14:58 zamundaaa[m]: If there is no KMS node at all, then I think atm you'd have to start kwin_wayland manually with the correct flag to select the virtual backend
14:59 zamundaaa[m]: You may also need to teach sunshine to request a virtual output through the portal, and give it permission to do so without prompting
15:01 bitblt: the kernel params option seems a lot simpler, so I'll stick to my original question :)
15:16 mareko: Lynne: that's going away in the future, the kernel won't be involved in queue scheduling
15:51 Lynne: mareko: how long away? userspace submission has been in the works for years AFAIK
15:52 Lynne: last I remember RADV only supported it somewhat for virtualization, while NVK requires a whole new kernel driver
16:00 dcbaker: anholt, robclark: thanks!
16:03 mareko: Lynne: after all bugs are fixed
17:12 frankbinns: dcbaker: looks like you might have force pushed the 25.3 staging branch just before assigning !39487 to Marge
17:12 frankbinns: I've rebased my branch and updated !39487, so it should be good to merge again
17:13 dcbaker: frankbinns: yeah I did, I rebased some test fixes into the branch before I merged yours, which is obviously the wrong order of operations. Thanks for fixing that
17:14 frankbinns: np :)
17:35 mareko: need: sparse storage and uniform texel buffer tests with 16-bit, 32-bit, and 64-bit results
17:36 zmike: file for vkcts coverage ?
18:10 mareko: every day I've been dreaming about app developers managing border colors for us, that day has come
18:11 mareko: finally it's a true GCN API
18:14 zmike: hahahaha
18:15 mareko: now we just need to offload shader compilation to app developers
18:16 alyssa: mareko: counter-proposal: API with no border colours except (0,0,0,0)
18:17 alyssa: mareko: zmike : https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5620
18:20 zmike: maybe the problem is that app developers aren't in direct control of the gpu
18:20 zmike: should apps just be kernel modules? 🤔
18:21 mareko: one step at a time
18:24 alyssa: i hate border colours
18:24 alyssa: least favourite vk feature