13:00 gfxstrand: tjaalton: Could you do a quick check of the Ubuntu and debian libx11 packages for --disable-thread-safety-constructor? It should NOT be set. If it is, Mesa 25.2 wil break.
13:00 gfxstrand: See https://gitlab.freedesktop.org/mesa/mesa/-/issues/13557 for more details.
13:01 gfxstrand: We've already had issues on Arch where they had it set on the 32-bit package but not the 64-bit one so check both if there's a difference.
13:26 tjaalton: gfxstrand: it's not set, so assuming it's not the default we should be fine
13:27 tjaalton: got dropped ~2y ago (again)
15:30 karolherbst: tnt: you might be interest in this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36249 at least the st_interop.c change
15:30 karolherbst: *interested
15:51 tnt: karolherbst: yes, I saw you posted about that some time ago. Thanks for the heads up. Although I can't say I really saw any ill-effects without it. But then again it might be hard to catch ...
15:52 karolherbst: tnt: for current code this shouldn't cause any changes in behavior
15:52 karolherbst: it's more to address a corner case in the spec
15:52 karolherbst: in the cl spec for "clEnqueueAcquireGLObjects"
15:52 karolherbst: "If an OpenGL context is bound to the current thread, then any OpenGL commands which" and the following
15:54 karolherbst: to fix sync issues, I need to flush again on clEnqueueAcquireGLObjects calls, but it's not guaranteed that a gl context is bound to the current thread, at least in davinci
15:55 karolherbst: tnt: I have the CL CTS tests be flaky in radeonsi and zink without it btw
15:55 karolherbst: never seen any issues on iris
16:12 mareko: the vdpau frontend is probably on the chopping block
16:12 zmike: at last
16:13 mareko: there is also some vl stuff that will be unused after vdpau is gone
16:37 karolherbst: for vdpau we'd then rely on this vdpau on top of vaapi layer?
16:37 karolherbst: (or on top of vulkan video I guess)
16:50 mareko: I've been told that vdpau isn't needed by anything
16:53 karolherbst: that sounds optimistic, though we can layer vdpau on top of vaapi, but I think we should be fine either way
16:58 mareko: having just VAAPI in Mesa sounds appealing, though having drivers other than radeonsi using vaapi wouldn't be bad either
16:59 karolherbst: intel has their external impl, and I think for zink there are probably plans to support it on top of vulkan video if it doesn't exist already
17:01 mareko: are radeonsi+radv the strongest drivers in terms of VAAPI and Vulkan Video support; sharing the same driver code between VAAPI and Vulkan seems beneficial, an external vaapi implementation wouldn't have that
17:49 jenatali: mareko: d3d12 supports vaapi
17:50 jenatali: There's also the MF video frontend which uses some vl stuff now too
20:15 zmike: mareko: not sure if you care but the tc commit in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36576 actually ended up being a harder bug to fix and I had to redo it
20:15 zmike: still no changes outside of my little sandbox
20:16 zmike: also I figured out a solution for multi-context buffer release
20:16 zmike: though images will be harder
20:36 daniels: mareko: I don't know of any substantial users of VDPAU who would be disadvantaged by having to drop back to VA-API. I'm not sure I can see too many more new VA-API drivers though; on Arm, all the codecs are provided by external (non-GPU) IP blocks which have their own V4L2 drivers and don't map well to the Mesa/VA world. Intel have their own external VA-API implementation and I'm not aware of any plans to change that.
20:38 K900: It is very unfortunate how V4L2 is just its own entirely separate abstraction that doesn't work with anything else
20:38 K900: Just when we got Vulkan Video which had decent chances of being The One Thing
20:39 emersion: intel dropped support for their old vaapi driver, we discussed integrating it in mesa, but that would be a whole bunch of work
20:39 K900: I wonder if it makes sense to specify video-only Vulkan devices and then have something bridge that to V4L2
20:45 daniels: that's one possible option for one class of V4L2 devices, yeah
20:45 daniels: but not for stateful codecs
20:46 K900: Is there literally any relevant hardware with stateful V4L2 codecs though
20:47 daniels: loads of Qualcomm
20:48 mareko: zmike: Ab
20:48 zmike: thx