00:18tarceri: airlied: Are you able to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42967 when you have a spare moment?
00:32airlied: tarceri: oh nice, I did spot it last week but I forgot to write it down, will put on the today list
00:37tarceri: thanks
06:05zzag: emersion: can you please assign marge-bot to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40416 ? there have been no new feedback for more than a day by now
06:06zzag: also in order to get the MR backport to stable branch(es), what should I do or whom do I need to nag?
06:16zzag:hasn't had enough of coffee yet. have -> has, backport -> backported
07:24emersion: zzag: oh, can you add a S-o-b trailer to your commit message?
07:24zzag: one second
07:25emersion: for backports you'd have to reach eric_engestrom manually since this isn't a bugfix per se
07:29emersion: zzag: done!
07:30zzag: emersion: thanks!
09:15zzag: yay, it got merged
09:15zzag: eric_engestrom: any chance that https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40416 can be backported to stable branches as well?
13:15CounterPillow: this entire series was applied without my review comment being addressed, cool. https://lore.kernel.org/all/nGLVvJOTS8eSI7IusBrUxw@collabora.com/
13:16CounterPillow: bonus points for the absolute slop like `link.dpcd_caps.dongle_type = (typeof(link.dpcd_caps.dongle_type))0x7f;` in https://lore.kernel.org/all/20260610094639.1965367-22-chen-yu.chen@amd.com/
13:40tzimmermann: mripard, hi! since you have good expertise on atomic-state handling, could you please comment on this discussion: https://lore.kernel.org/dri-devel/63cca05a-ec83-430c-abcf-c2f0b508446f@suse.de/
15:49mripard: tzimmermann: my bad, I removed get_existing_*_state not get_*_state in anything but atomic_check
15:50mripard: (I still think we should warn about this though)
16:05idoleat: CounterPillow: sorry for your comments being ignored. I'm on the same team as Chenyu Chen. I'll pass the message to him. We we will paymore attention that all the comments should be addressed.
16:06CounterPillow: idoleat: thank you! <3
16:07alyssa:is once again bit by no vec32 in nir
16:07alyssa:groans
16:09alyssa: means i can't do scan/reduce lowering in nir for intel
16:09alyssa: for simd32
16:10alyssa:will simply open code bigvecs
16:11karolherbst: alyssa: isn't there like.. a better solution for this?
16:12karolherbst: or rather.. what's wrong about the lower_subgroups one?
16:13alyssa: it's very very slow
16:13alyssa: and we can do much better on intel
16:13alyssa: since intel is an explicit simd isa (unlike nvidia)
16:22karolherbst: ahhh
16:22karolherbst: right I see
16:23glehmann: alyssa: huh, how would you lower subgroups efficiently in NIR?
16:24alyssa: glehmann: logically convergent vec32s
16:24alyssa: open coding a hack to give me those without adding actual vec32 to nir
16:24karolherbst: guess we should tackle big vectors at some point...
16:25karolherbst: do we have an opinion on them?
16:25glehmann: my opinion is that alu swizzles need to be removed first
16:27karolherbst: also asking for https://gitlab.khronos.org/opencl/OpenCL-Docs/-/merge_requests/248
16:27glehmann: alyssa: how would you define operations on those vec32? I assume you want to do more than one op per instruction. do you want to support vec32 alu as well?
16:28karolherbst: though I guess that's just going to be SPV_EXT_long_vector
16:29glehmann: yes Vulkan also has an extension for it, and d3d12 has it in sm6.9
16:29glehmann: so we need to implement it at some point
16:29karolherbst: okay, so we'll end up supporting it one way or the other..
16:30alyssa: glehmann: fortunately, I need only vec16 alu
16:30alyssa: I know what to do, hopefully this pans out
16:31alyssa: and to answer why i'd want to lower in nir at all: letting nir_lower_int64 kick in for 64-bit scan/reduce
16:32glehmann: ah, I was about to says lowering reduce/scans in the backend sound like an easier solution to me
16:33glehmann: meanwhile, I'm optimizing open coded reductions that use shared memory to subgroup ops :D
16:36karolherbst: nice
16:40karolherbst: I think we've discssued lowering those at vtn type, but yeah... not sure I super like the swizzle approach, but I also honestly don't have a better idea. It's just very handy for backends to have the swizzle in nir_alu_src
16:40karolherbst: or maybe we keep it for vec4 max...
16:41glehmann: we can surely have a helper for backends that works like nir_alu_src
16:41karolherbst: yeah.. I guess
16:41alyssa: yes, I agree with glehmann
16:41alyssa: just.. work
16:41karolherbst: I guess the idea was instead of having it a src, we'd have a nir_swizzle src, const instruction and we could scan for it...
16:41karolherbst: either it's there or.. it's not
16:42karolherbst: yeah.. and I guess this is also going to drastically reduce memory usage of alu instructions overall
16:44karolherbst: at least I don't have a pressing need for CL, so I guess the we'll see it in vulkan first
17:14sghuge: Any pointers on how to reproduce this error: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/105285496 (apart from ADL platform)
21:53mareko: FYI, a limited version of VK_NV_fill_rectangle is possible on AMD HW
22:40karolherbst: are there users for it? Though I guess for meta it might be useful
22:41HdkR: It's whole purpose is blits right?
22:42HdkR: Or anything else that can just take a fragment shader of a screen space quad
22:42HdkR: It's handy :D
22:43mareko: first there needs to be a multi-vendor extension before users become interested
22:45mareko: rectangle primitives improve rasterization and pixel shading performance for quads, the perf gap is bigger with MSAA
22:45mareko: it can also be used to draw rectangular point sprites
22:47mareko: which would also improve performance for cases where square sprites waste performance
22:50mareko: drawing 2 triangles for such sprites is also wasteful, not just because of helper invocations, but because of rasterizer inefficienciees that can be far greater than the cost of helper invocations
22:53mareko: this is where we are right now: https://gitlab.khronos.org/vulkan/vulkan/-/issues/1757#note_618878
23:20karolherbst: yeah, I totally see the benefits for 2D acceleration and blits, was just curious if there are more use cases
23:20karolherbst: maybe we should implement the nv extension on NVK, though I guess all of this is fairly trivial. I just don't know if there are any tests for it anywhere
23:24rpavlik: follow-up on the packaging thing from last week: The closest I found in debian policy was this: https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources - which says if upstream fails to include the source for something, here is how you handle it. It says nothing about having to actually use it - cc
23:24rpavlik: karolherbst
23:25karolherbst: okay, but we'd include the source files
23:34airlied: I think we had consensus before that a multi-vendor ext was kinda difficult in that they all implemented rects in completely different ways
23:35airlied: at one point with GL for glamor I was just going to go all in and implement 3 vendor exts and wire them up because for glamor it would have been fine
23:35karolherbst: ohh we actually implemented the GL extension on nouveau...
23:37airlied: like they were all pretty trivial extensions
23:37karolherbst: I was checking how nvidia calls it in their official headers.. no wonder I couldn't find it: NVCE97_SET_FILL_VIA_TRIANGLE_MODE_FILL_BBOX 🙃
23:37karolherbst: yeah.. in the GL driver it's like 5 loc
23:38airlied: the biggest problem I think was deciding how much vertex data each hw needed
23:38airlied: some were fine with 3, some needed 4
23:38karolherbst: anyway.. if there are tests I (or somebody else) could wire it up easily in nvk
23:42airlied:reads the khronos ticket finally, seems well covered :)
23:48karolherbst: if I understand the Nvidia extension correctly, the rectangle is the axis aligned bounding box of a triangle