00:44 tarceri: daniels: you probably understand this better than me the last 2 comments in this mega thread discuss the remaining issue on BE r600 it seem its now just a mismatch in a switch table. Possibly we are flipping to endian dependent format when we don't need to: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11933
01:06 Shibe: Is there a "right" way of importing dmabufs with implicit modifiers with Vulkan? If without querying for supported formats I just try importing a dmabuf with modifiers set to INVALID vulkan validation grumbles at me but it also happens to work. I know implicit modifiers and multiple GPUs are not well-defined but is there a proper way to handle this? How do compositors do it?
01:09 Shibe: correction, if I import the dmabuf without adding a ImageDrmFormatModifierExplicitCreateInfoEXT with modifier info, it works but with it it doesn't (even if it's set to MOD_INVALID)
09:13 mlankhorst: jani: I'll keep an eye on drm-next
09:13 mlankhorst: Doesn't look like it's merged so far
09:26 tjaalton: jadahl: hey, I see you've worked on gnome-remote-desktop? I'm seeing an issue with version 48 and mesa 25.0.4+ on raspi4 & 5 where the RDP connection failes due to vaapi init failure(?). with 25.0.3 it was fine, and it works with a combo of 46 + 25.0.7
09:30 tjaalton: so I wonder if !323 helps here?
10:14 daniels: Shibe: no, there is not
11:09 tjaalton: jadahl: yep, !323 fixed it
11:40 sima: mlankhorst, do I need to process something?
11:40 sima: airlied is out this week
12:08 sima: mlankhorst, ah spotted the one you've likely talked about
12:09 sima: mlankhorst, jani I'll ping you when I'm done pr handling
12:18 zmike: mareko: does u_blitter have any functionality for doing averaged resolves of depth formats?
12:19 mareko: zmike: no
12:19 zmike: didn't think so
12:20 mareko: the existing shaders should work, but only if the render target is color
12:20 zmike: right
12:20 mareko: why do you need it?
12:20 zmike: testing something
12:21 zmike: it's allowed in vulkan
12:34 Venemo: does anyone know if vkrunner supports mesh and task shaders yet?
12:37 mareko: zmike: if it's for lavapipe, implementing MSAA resolves on the CPU should be faster
12:38 zmike: hm that's a good point
12:38 mareko: and OpenMP to parallelize
12:38 zmike: is there any openmp in mesa already?
12:40 mareko: in ac_surface_meta_address_test.c only
12:45 sima: mlankhorst, jani done
12:48 zmike: mareko: so what is the default resolve type for depth resolves? sample0?
12:48 zmike: in u_blitter
12:48 zmike: I thought looking at the shader that it might be MIN, but that doesn't seem right
14:17 mlankhorst: sima: waiting for drm-intel-next pull request for backmerge into drm-msic-next for panic :-)
14:40 sima: mlankhorst, yeah that's done now
14:48 mlankhorst: I just realized I misread pr handling as PR handling
14:52 mlankhorst: "We're very sorry for the backlash, and we are in a process of constant improvement. I'm sorry it may have caused some computers to physically burn down even with all the safeguards, and new safeguards have been introduced to prevent similar pull requests again."
17:08 karolherbst: mhh.. what's the difference between memobj_create_from_handle + resource_from_memobj and resource_from_handle?
17:10 Kayden: resource_from_handle predates memobjs if nothing else
17:12 zmike: iirc memobj is for win32 handles
17:19 karolherbst: zmike: weird, because I see it used in !defined WIN32 code
17:19 zmike: I think it's since been extended
17:19 karolherbst: Kayden: so more of a legacy API and I should kinda prefer using memobj_create_from_handle instead
17:20 karolherbst: I wonder if I should also use it for hte gl_sharing path at some point..
17:22 karolherbst: anyway... hopefully I can use it
17:22 jenatali: IIRC resource_from_handle is what's used for internal sharing scenarios, where the memobj stuff only serves the GL external objects extension
17:23 karolherbst: right...
17:23 karolherbst: I want to implement cl_khr_external_memory
17:23 karolherbst: _sadly_ cl_khr_external_memory_dma_buf doesn't provide any mechanism to transport modifier information so that's gonna be "fun"
17:24 jenatali: I think you want resource_from_handle
17:24 karolherbst: yeah.. using resource_from_handle for gl_sharing atm
17:24 karolherbst: but it does require some information I don't get, like the modifier..
17:24 karolherbst: well both do
17:25 jenatali: This is why Windows shared handles are strongly typed. That info flows between processes through a separate channel in the kernel, so only the handle needs to be marshaled
17:26 karolherbst: right.. but they could have just added it to the spec and I don't know why they haven't
17:42 karolherbst: well.. works good enough to import a buffer
17:54 karolherbst: mhhh "FAILED 10 of 12 tests." running the vulkan sharing tests
17:56 karolherbst: uhhh.. those tests...