07:34 tzimmermann: jfalempe, hi. could you also review https://lore.kernel.org/dri-devel/20251110154616.539328-3-tzimmermann@suse.de/ ?
07:34 tzimmermann: it's the one remaining patch for sysrq
08:42 jfalempe: tzimmermann: sure, let me take a look.
08:42 tzimmermann: thanks a lot
09:23 K900: Hey folks, anything I can do to help move https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38373 forward?
09:24 K900: It's messing up a lot of people on current NixOS unstable, and we have a release to tag by the end of the month
09:24 K900: And I'd really prefer not to have that ship with 25.2
09:24 dj-death: pickup the gtk+ fix seems like the right way
09:24 dj-death: apparently that MR doesn't fix the problem completely
09:25 K900: Yes, for newer applications, but this will still bite people that are using older binaries in flatpaks/containers/nix shell and such
09:32 dj-death: K900: Rb, hopefully should land today
09:32 K900: Thanks
09:33 K900: There's also https://gitlab.freedesktop.org/mesa/mesa/-/issues/14309 that's been reported
09:33 K900: But I think that's a zmike kind of situation
09:37 K900: dj-death you might also want the equivalent of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38550
14:43 NishanthMenon: narmstrong: https://lore.kernel.org/all/3daf857c-1532-4943-8eb1-58c5cdc3a560@ideasonboard.com/ any feedback?
14:45 narmstrong: yep, applying it now
14:47 NishanthMenon: thanks narmstrong
16:21 alyssa: a moment ago we had 454 people in #dri-devel and my brain immediately went "ah a pound of users"
16:24 alyssa:
16:57 mareko: before we started working on amdgpu native context, we looked at alternatives, zink on venus on RADV seemed like a good choice, but after we started putting it through rigorous testing and benchmarking, we discovered that it's the worst slowest most buggy solution, zink+venus had 30-40% of the perf of native RADV, was slower than virgl, and lots of apps didn't work, it was a disaster
17:09 alyssa: /o\
17:10 mareko: *native radeonsi
17:56 anholt: mareko: did native context for radv ever land?
18:02 alyssa: anholt: seemingly yes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34470
18:04 anholt: oh, good.
18:04 anholt: would be great if chromeos could really understand that their generic vert drivers were actually just a proprietary-driver cost, not a general cost of doing business.
18:04 anholt: *virt
18:34 mareko: anholt: yes and it's already used commercially
18:34 alyssa: =D
18:34 anholt: excellent. so glad to hear it happened.
18:34 alyssa: mareko: in radv or in radeonsi?
18:34 mareko: radv, radeonsi, incl. vaapi
18:34 alyssa: oh cool wow
18:34 mareko: rusticl too if anybody cares
18:34 alyssa: !
18:35 alyssa: that might be the first commercial deployment of rusticl even?
18:35 alyssa: karolherbst: is this true
18:35 mareko: no
18:36 alyssa: oops i must be behind on my gossip then
18:36 pac85: I think radeonsi and radv share the "winsys" code (which is what the DRM code is called there iirc)
18:36 mareko: radv (VK), radeonsi (GL) incl. VAAPI has commercial use, i.e. the whole AMD userspace that we support runs in Qemu
18:37 pac85: Anyway I posted this yesterday https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38560
18:37 mareko: rusticl should work too, but we don't use it
18:37 alyssa: ah yeah ok
18:38 mareko: ROCm also runs it Qemu
18:38 alyssa: even Fedora Asahi doesn't ship rusticl out of the box iirc
18:38 pac85: Nice!
18:40 mareko: both KVM and Xen work
18:41 mareko: we did quite a lot of work on Xen to make it work
18:41 pac85: I think it was mentioned at XDC?
18:41 mareko: yes
19:06 karolherbst: alyssa: it should be enabled by default though if one installs it, no? On asahi I mean
19:08 karolherbst: but on asahi you literally have no other choice anyway. So if it's not installed by default, might be a good first platform to do so
19:13 alyssa: karolherbst: right
19:14 alyssa: but if you don't install any package depending on mesa-libOpenCL you don't get cl out of the box
19:14 jannau: mesa-libOpenCL installed by default in Fedora-Asahi-Remix. for almost a year now
19:14 alyssa: Oh cool
19:14 alyssa: NIce
19:14 alyssa: I guess we are shipping rusticl then! =D
19:14 alyssa:will close the tab and stop spreading misinfo
19:15 jannau: there are no packages in fedora which recommend or require mesa-libOpenCL but the asahi desktop metapackage pulls it in
19:16 alyssa: ah cool
19:16 alyssa: arguably clinfo, clpeak, etc should recommend it but shrug
19:17 jannau: I'm not sure if it's actually a good idea due to the missing preemption for compute jobs
19:18 karolherbst: the hw can preempt compute jobs? nice
19:19 karolherbst: or is it more of a interrupt thing where the kernel needs to do everything
19:19 jannau: packages which use opencl like darktable and libavfilter probably should recommend mesa-libOpenCL
19:19 karolherbst: they usually pull in the loader
19:20 karolherbst: and the loader could recommend it I guess instead
19:21 jannau: no, preemption is broken for compute and so compute jobs are scheduled with highest fw priority. which is annoying if the compute job takes a while and you still want to render the desktop
19:38 karolherbst: ahh....