07:28 airlied: dschuermann: (or any compilery folks) I've got a shader with a long sequence of 64 result operations, where I have 64 results in nir then 64 load_global, 64 alu combos of those values, then 64 store_global. currently this eats VGPRs, and I wrote a really hacky benchmark specific pass that groups the sequences into groups of 8 which speeds things up a lot on radv, but I'm wondering what pass in nir/aco
07:29 airlied: should I be looking into to figure this out?
07:36 pendingchaos: aco's scheduler groups loads/stores into clauses
07:46 airlied: it might be this is a very benchmark specific pattern, but it really doesn't move anything
07:52 airlied: marking things with ACCESS_CAN_REORDER seems to help a bit, not as much as my hack though
07:56 airlied: also probably not legal :-P
15:33 alyssa: I just upgraded to f44 and am getting piles of build warnings with gcc, anyone know what's up?
15:34 alyssa: src/gallium/auxiliary/draw/draw_decompose_tmp.h:51:13: warning: variable « flags » defined but not used
16:03 daniels: alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42584
16:04 alyssa: daniels: thanks, missed that one
16:49 karolherbst: guess we have the first conformant OpenCL 3.1 implementation: https://www.khronos.org/conformance/adopters/conformant-products/opencl#submission_471
16:57 karolherbst: only need to sort out the libclc mess so we don't ship broken runtimes :')
17:58 alyssa: Woo
18:03 karolherbst: alyssa: any preferences on how to deal with libclc? I kinda don't want a hard fork of llvm, because that's going to suck, so I was wondering if I want a repo that has llvm as a submodule + a directory with patches + a script that handles it all, but that also kinda sucks, so I'm wondering if I want an llvm fork repo afterall. Could also add it to
18:03 karolherbst: mesa, but then updating libclc is going to be a disaster when we move e.g. from llvm-22 to llvm-23 as a base and would need to reapply patches or something.
18:03 karolherbst: any thoughts?
18:07 alyssa: i haven't eaten enough today to think about LLVM politics, sorry
18:08 alyssa: & I don't think I have anything to add beyond my ideas lat time
18:11 karolherbst: okay, fair enough
18:12 karolherbst: maybe I just have a repo, cp the libclc directory and then have commits fixing it, and on a new LLVM release it's a new branch with the same fixes or fewer or different ones.. mhhh. Yeah maybe that's the least amount of effort
18:41 karolherbst: yeah.. that works out nicely
18:46 karolherbst: for llvm-22 it would look like this: https://gitlab.freedesktop.org/karolherbst/mesa-libclc/-/commits/llvm_22 I think I like this enough
18:56 karolherbst: and now I wonder if I want to read the file at runtime or compile-time...
18:56 jenatali: Join us in doing it at compile time
18:57 jenatali: That's the exact solution we used back when we had to get commits added to libclc to be able to ship an initial version of our CL stack btw, a fork of LLVM with downstream patches that get bundled into the binary
18:57 karolherbst: yeah but distributions would need to rebuild mesa on a libclc update and now I've add another repository where I'd go "pls rebuild on every update"
18:58 karolherbst: _but_
18:58 karolherbst: I also dislike how there is always an initial start-up latency with rusticl, because libclc needs to be build and cached first...
18:58 karolherbst: so long-term I do kinda want this to be precached, but that has soo many details to be figured out that I don't really know how to deal with this anyway
19:49 jenatali: That's more or less one of the exact projects on my plate, shader pre-caching
19:49 jenatali: Not for CL, but for D3D in general
19:51 karolherbst: Yeah.. I think for now it's easier to just add project build options for where to load the spirvs from and just hope everybody gets it right
19:52 karolherbst: I was kinda curious if there is a way to tag our own libclc files, so we can tell them apart from upstream ones
21:56 alyssa:wonders why her gpu is slow today
22:10 alyssa: Release build of the 26.1 branchpoint is half the fps of the fedora build
22:10 alyssa: Does my compiler just suck?
22:11 alyssa: dcbaker: you have any idea?
22:13 dcbaker: alyssa: half? Uh, as long as you're bulding with -Dbuildtype=release then no
22:13 dcbaker: but even debugoptimised should be pretty close
22:13 alyssa: I am.. what the heck?!
22:14 alyssa: ok built 26.1 branch and that's fine so uhhh
22:14 alyssa: I feel like my computer is toying with me
22:14 zmike: did you pass -Denable-vroom=enabled ?
22:14 dcbaker: Do you have MTL by chance?
22:15 alyssa: LNL
22:15 alyssa: i'm bisecting, we'll see if this turns out to be PEBKAC
22:15 dcbaker: cool, then you don't have the big-little problem that I have
22:15 karolherbst: imagine having three core types
22:16 dcbaker: no thanks
22:16 alyssa: sometimes CPUs like to spoon
22:16 dcbaker: lol
22:16 karolherbst: don't worry, you won't be able avoid them
22:16 karolherbst: this bad boi can fit so many CPU threads *pats laptop with 22 threads*
22:17 dcbaker: with the cost of computers these days I'm pretty sure I'm going to be back to running the Pentium 3 Thinpad that still says "IBM" on it, lol
22:17 karolherbst: though the annoying part is that the E and ultra E or whatever cores show up as different cycle event types in perf
22:17 karolherbst: so that's great