00:13_lyude[d]: My apologies for breaking it 😳
00:14_lyude[d]: I really gotta get a Blackwell system
00:20_lyude[d]: karolherbst[d]: I asked for it but to be honest I'm not sure I see anything disp related, though usually when disp stuff goes wrong you see an actual evo (or XiD with GSP) error, or the display push buffer update commands start hanging
00:29matt_schwartz[d]: _lyude[d]: no worries, i broke amdgpu brightness adjustment for a couple of .x stable releases a few months back 🐸
02:00airlied[d]: So one thing I notice with openrm is they don't get those nocat record msgs which might point out we are doing something wrong
10:14karolherbst[d]: _lyude[d]: yeah... it's just kinda weird that having higher clocks "solves" it, but then it could be some weird timeout thing... it's not the first time something like that came up
14:55karolherbst[d]: I just noticed that the atomic instructions also have the GRP + UGPR + offset encoding...
14:55karolherbst[d]: including the stride for shared..
17:05karolherbst[d]: can I nuke `MemAddrType`? It's annoying 🙃
17:28mhenning[d]: What's annoying about it?
17:29mhenning[d]: But yeah in practice it's only ever 64 right now
17:30marysaka[d]: Is it not 32 for local and shared? or maybe I am misremembering but in all cases trivial to figure out
17:31mhenning[d]: Oh, I guess. The IR only specifies it on global though
17:31mhenning[d]: and recent archs don't have a bit to encode it for global any more
17:45karolherbst[d]: mhenning[d]: dealing with GPR + UGPR, because the bit that determines the bit size of either source depends on things...
17:46karolherbst[d]: so if you enable UGPR mode, it's bit 72 for the UGPR and 91 for the GPR, but in non UGPR mode it's 72 for the GPR and it feels like that a `MemAddrType` is a poor abstraction for it
17:46karolherbst[d]: especially because a zero source is always 64 bit for UGPR and always 32 for GPR
17:47karolherbst[d]: in UGPR mode the GPR can only be 64 bit if the UGPR is 64, and the UGPR can only be 32 if the GPR is so as well
17:47karolherbst[d]: though the latter case should never be an issue
17:47karolherbst[d]: but anyway, I'd rather just infer the bit size from the source directly
18:00karolherbst[d]: but maybe I set up my MR first, because then it's more obvious and maybe there is a better suggestion 😄
19:19_lyude[d]: oooo - looks like the checkerboard pattern on my discord is a special bug :), still happens with the latest nvk
20:01mhenning[d]: Does anyone have ideas for how to fix https://gitlab.freedesktop.org/mesa/mesa/-/issues/14610 ? I suspect it's a kernel issue. I'm a little nervous about shipping compression in the current state - I'm wondering if we should toggle it off for kernel 6.19 / mesa 26.0 to give us some time to figure this out
20:11_lyude[d]: oh nope! I tested wrong it is fixed 😄
20:22marysaka[d]: mhenning[d]: I feel like it's a kernel bug too and wonder if it's not the whole "moving out/in of VRAM" part of it... but I'm was pretty sure it shouldn't be trigger so I'm quite confused still
20:24marysaka[d]: I will try to reproduce with my RM backend and see if I hit the MMU fault tomorrow, but we should probably disable large page and compression for now until we figure that one out...
20:25marysaka[d]: I got an MMU fault on DOOM quite fast while on the main menu for example so the possibility of hitting it in normal scenario seems extremely likely to me :blobcatnotlikethis:
20:28mohamexiety[d]: I did look at it for a bit but I wasn't really sure how to triage it tbh
20:32marysaka[d]: yeah I'm not sure if DOOM 2016 one is related so I should probably retest with an older kernel too just to be extra certain
20:32mohamexiety[d]: one weird part is i am pretty sure these flakes are recent too
20:33mohamexiety[d]: this didn't happen back when it got merged; it's been a while but I remember each CTS run being consistent :thonk:
20:34mhenning[d]: oh, that's interesting. If an earlier version of the patch doesn't have the issue that might help track it down
20:36mhenning[d]: marysaka[d]: doom 2016 might be a different issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/10910
20:37marysaka[d]: I see hmm
20:37mhenning[d]: also note that radv has some doom 2016 driconf workarounds
20:38mohamexiety[d]: yeah i am p sure doom never worked :KEKW:
20:41marysaka[d]: ... maybe I should look at it someday and finish it while at it 🙃
21:28mohamexiety[d]: i don't think i can get the same nvk I was using back then but I will try to run the exact same kernel branch and see tomorrow or friday. the working branch was based on 6.18rcs iirc
23:10phomes_[d]: I tried to reproduce 14610. I ran it for 30 mins but did not see the crash. On a 4070 with 12GB
23:11phomes_[d]: doom 2016 was already crashing for me before compression with release builds and it hits an assert with debug builds before it launches