08:30 mripard: tomba: hwentlan__: could you have a look at https://lore.kernel.org/r/20260224-drm-private-obj-reset-v5-0-5a72f8ec9934@kernel.org ?
08:33 tomba: mripard: sure. ah, I didn't notice it was a dependency for "drm/atomic: Rework initial state allocation"
10:29 zmike: tarceri: any luck?
10:38 mripard: sima: thanks for the backmerge, I did the one in drm-misc-next
10:44 zmike: what's the nir pass for combining writemasked stores? like store_deref(x) store_deref(y) store_deref(z) -> store_deref(xyz)
10:45 pendingchaos: zmike: nir_opt_combine_stores
10:45 zmike: ty
11:37 zmike: mareko: any further comments on nir parts of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37408 ? I may merge those separately since llvmpipe still has weird issues
16:11 mareko: have we decided whether we intend to implement GL_NV_mesh_shader or keep the current NIR support for it?
16:11 glehmann: imo we should drop the NIR support
16:17 zmike: I think that's up to nvk
16:17 zmike: supposedly it's much faster
16:41 karolherbst: well I don't think there is much of a difference between using the KHR one with 32 invocations or the NV one, but maybe Mary could answer that
16:43 zmike: they've been incredibly insistent that the NV version continue to be supported everywhere in vulkan
16:43 zmike: so there must be some value
16:44 zmike: they = nvidia
16:45 karolherbst: ohh yeah, I mean having more than 32 invocations and doing shared memory operations is terrible for performance, because it's all done in 3D, which doesn't have shared memory and workgroups don't exist.
16:45 Mary: There are not many differences with the KHR extension apart from the 32 invocations, being able to readback output attributes and being able to alter the "first task"
16:46 karolherbst: do the other two points matter for performance much? Though those are just additional features
16:46 Mary: I was kind of considering exposing the NV extension too after we land the KHR one
16:48 Mary: yeah I am not sure what NVIDIA consider "much faster" there... maybe ensuring that users of the API do not try to use anything emulated is there reasoning?
16:53 glehmann: imo, NV_mesh is just going to bit rot because it has next to no users, and to be honest I'm suprised nvidia still hasn't changed their hw to properly model KHR/d3d12 mesh
16:57 zmike: GL_NV_mesh obviously
17:04 karolherbst: I think outside of shared atomics it's probably fine, so maybe they just hope it's not a massive problem 🙃
17:16 mareko: shared memory is close to SIMDs anyway, it should be easy to support in all shader stages in all HW designs (we certainly support shared memory in all shader stages)
17:25 karolherbst: well the good news is that even on nvidia it uses the same storage (L1 cache), but in 3D shaders you don't have atomics to that area
17:26 karolherbst: but need to use 3D pipeline specific instructions, that usually operate on vertex attributes, etc.. which also live in L1 cache
17:27 karolherbst: so yeah.. I suspect it would be very easy to fix actually
17:31 pac85: Sounds more like bad news than good news though lol
17:38 mareko: zmike: FYI https://gitlab.freedesktop.org/mesa/gpu-ratemeter/
17:39 zmike: sweatytowelguy
17:40 zmike: mareko: don't throw distractions like that in front of me
17:41 mareko: it's OK to ignore it
17:42 zmike: you know I'm bad at that when there are numbers which could be going up
17:43 MrCooper: "feel free to ignore the carrot in front of your nose" :)
17:43 mareko: some of those would be RADV improvements, and that's good, right
17:46 anholt: mareko: cool! definitely seems worth looking at for us. (given that we can do closed and open on the same kernel)