07:15glehmann: karolherbst: alyssa: can you help me with https://gitlab.freedesktop.org/mesa/mesa/-/jobs/91215022
07:15glehmann: I don't reallly understand it, brw is calling nir_opt_algebraic_late
07:15glehmann: so why is the backend seeing fcanonicalize
07:33glehmann: I'm kind of tempted to add this to the fail list
08:16dolphin: airlied, sima: Sent the drm-intel-gt-next PR, just 5 patches.
08:32dolphin: airlied, sima: also noticed that somehow I had interactive rebase in-progress in dim repo so dim update-branches had not brough it up-to-date, so it now happened with relatively old DIM :/
09:00karolherbst: glehmann: are you 100% sure its fcanonicalize?
09:02karolherbst: but yeah I could maybe take a look later
09:06glehmann: karolherbst: not 100%, but another unknown opcode would be even weirder
09:07karolherbst: but not sure if I'll get to it today, because atm I'm bisecting LLVM..
09:18MrCooper: please accept my sincere condolences
09:33karolherbst: yeah.. it's two (ore more) regressions this time...
09:39glehmann: karolherbst: would be great if you find some time, I would like to merge this before the branch point
09:39karolherbst: when is the branch point? next week?
09:40karolherbst: yeah, should be doable
09:40glehmann: next wednesday
11:24mlankhorst: airlied, sima: sending out drm-misc-fixes a bit belated now, got a power outage after smelting of a lot of snow yesterday
11:50dolphin: mlankhorst: smelting snow? you got me curious on that
11:50sima: ice forgers in this community, we have
11:51sima: mlankhorst, anything urgent in there or ok if we delay by a week?
11:52dolphin: ah, that'd make sense. I always throught tap water is preferrable to avoid the debris, but I guess you could filter it
11:53sima: mlankhorst, I guess it's a bit a pile, I'll do another pr when I'm back from running errands
12:32mlankhorst: Yeah thanks :)
12:35mlankhorst: dolphin: There was a short distance between the electric cable company's box and my own power box, and we probably had a fault current from the high snow melting. Unfortunately the fuse on the power company's side was rated for the same current as our own, and it blew first. So they had to change it out for a higher rated fuse, and also to prevent the same problem, swap out the fuse on the other
12:35mlankhorst: side of their higher up power box for an even higher rated fuse.
12:36mlankhorst: So their fuse prevented our fuse from blowing up. :)
12:39mlankhorst: We had no water too, since we have our own well, but we have a lot of snow and a wood-burning stove. ;)
12:53dolphin: mlankhorst: is the ice melting for ice sculpting?
12:57mlankhorst: No, only 40 cm of snow that wants to be water again ;)
12:58dolphin: so you don't push it to piles and just wait? :)
13:00mlankhorst: Nah too many hectares, though all the snow on 1 big pile would be glorious!
13:00dolphin: that's interesting to hear
13:01dolphin: here folks just have a truck to take the big piles away
13:01mlankhorst: tractors are used here mostly
13:02dolphin: or they plow it into huge pile which you can drive on top in some area purposely for it
13:02mlankhorst: Do you live in a city or rural?
13:04dolphin: that experience is from more rural area, I live in a suburb and just pile the snow to high piles and wait
13:05dolphin: gotta run now, enjoy the weekend
13:05mlankhorst: Bb!
13:19alyssa: cmarcelo: can you look at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/91215022 ? this is in your area, thanks!
13:23karolherbst: mhhh interesting: https://github.com/llvm/llvm-project/commit/423bdb2bf257e19271d62e60b6339d84b8ce05aa
13:23karolherbst: though not sure why it breaks using the atomic functions...
13:24karolherbst: though I also haven't finished bisecting yet so maybe it's something else
13:26karolherbst: probably need to change the clc interface a little though the clc stuff does use CLC 2.0 so I'm kinda confused why we'd have to enable anything additionally..
13:28karolherbst: but this change kinda indicates we'd have to enable those feature macros even in CLC 2.0: https://github.com/llvm/llvm-project/commit/423bdb2bf257e19271d62e60b6339d84b8ce05aa#diff-06ca78b74b85e093d5b7eddd16b24b4781b2025e6e8bf6c035345155c2649a4dR323-R327
14:06karolherbst: ohh wait.. it's the generic address space thing... uhh...
14:22karolherbst: okay, now to the next regression :')
14:36alyssa: sounds like you're having fun
14:39karolherbst: alyssa: yeah... but that ends now, because the SPIRV reflection stuff is broken as well and I'm sure that's going to be a royal pain to fix
14:49karolherbst: mhh getting 0 entry points maybe it's a trivial fix after all
14:56zmike: dcbaker: any idea related to https://gitlab.freedesktop.org/mesa/mesa/-/issues/14667
14:58karolherbst: okay.. removing the call to "nir_remove_non_exported" fixes it...
14:59karolherbst: yeah.. I guess nir_fixup_is_exported needs adjustement now that the one wrapper is gone
15:02karolherbst: alyssa: do we want to use the nir_fixup_is_exported thing on anything that we don't generate ourselves? I could just do an ifdef thing against the LLVM version we are compiling against, but... maybe I can try to support both?
15:04alyssa: karolherbst: not sure I understand the question
15:05karolherbst: alyssa: like the spirv llvm translator won't generate the wrapper function anymore starting with version 22, so atm nir_fixup_is_exported is very broken. Now I could try to make it deal with generated SPIR-Vs having the wrapper and having them not, but I could also just check against the LLVM version we compile against
15:06karolherbst: but that of course only works if we generate the SPIR-V
15:06alyssa: version check seems ok
15:06alyssa: the fixup is just for the wrappers messing stuff up on our own spir-v.
15:06karolherbst: though... we support mesa_clc being provided externally, right?
15:07alyssa: no
15:07alyssa: we do for cross builds but we expect versions to match
15:07karolherbst: okay
15:07karolherbst: so using different LLVM for mesa-clc and the actual mesa build is heavily unsupported
15:07alyssa: yes
15:09jannau: gentoo uses a separate mesa_clc even for native mesa builds but version and llvm are enforced to match
15:20karolherbst: mhh now I have lower_to_bindgen_return crashing on functions like nir_bindless_image_load
15:22karolherbst: ohh that might be my fault
15:26alyssa: was binding all of NIR into OpenCL a bad idea?
15:26alyssa: well--
15:27karolherbst: the issue I'm running into now is that "nir_remove_entrypoints" removes all the entry points :)
15:27alyssa: Oops
15:27karolherbst: and now the serialize complains because things are huge or something
15:28karolherbst: okay.. dumping the shader and it's incredible
15:28karolherbst: block b2153191: // preds:
15:28karolherbst: 64 %3547661 = load_const (0x00000000000048cf = 18639)
15:28karolherbst: yeah...
15:29alyssa: I write a lot of OpenCL code, ok?
15:31karolherbst: I'm kinda curious on what's going on there, but I also kinda want to make progress and get it compiling :D
15:31karolherbst: mhhh
15:33karolherbst: yeah so the original nir_fixup_is_exported makes vtn_bindgen2 work, but then asahi_clc is broken...
15:33karolherbst: maybe I make it tomorrows me problem to figure this out
16:03cmarcelo: alyssa: will build the stuff to see what's up
16:19dcbaker: zmike: I haven't built main in a few days, I'll take a peak
16:19zmike: awesome thanks
16:22alyssa: cmarcelo: thanks
16:25dcbaker: zmike: I can reproduce
16:26zmike: hooray
16:31dcbaker: I have a ptach
16:31zmike: incrediblepleasesharethisissoawful
16:32dcbaker: I'll send it in a second
16:38dcbaker: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39355
16:41glehmann: isn't that just an alternative for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39350?
16:43zmike: hnnnnnnnggggg just fucking merge something this is excruciating
16:46dcbaker: eric_engestrom's patch is better. I have one small nit for it, otherwise it's reviewed
16:53eric_engestrom: dcbaker: thanks for the review; I'll apply your suggestion and merge it :)
16:54dcbaker: eric_engestrom: Thanks!
16:56zmike: hero
17:05alyssa: not rebasing pays off
17:06zmike: I have regrets
17:35zmike: is there a reason why spirv_to_nir takes a stage? can't that just be inferred from the spirv?
17:36zmike: i.e., would anyone be mad if I made that a thing
17:40zmike: I'm gonna assume no
17:51zmike: hm this is less easy than I thought
18:01MrCooper: life sucks, good thing it's already beer o'clock here
18:25mareko: life is great, more programming to do at 4am...
18:26alyssa: i love when gcc optimizes out my failing asserts because there's no way it's possibly false
18:26alyssa: helpful.
18:32alyssa: for (unsigned k = 0; k < 2; ++k)
18:32alyssa: printf("%u %u\n", k, k);
18:33alyssa: infinite loops
18:33alyssa: thanks gcc
18:37alyssa:builds with clang to see if she's losing it
18:39glehmann: zmike: any compiler cleanup in a nutshell
18:39alyssa: definitely seems to have some timetravel going on
18:39zmike: now I'm not even sure it was worth the effort
18:39sima: airlied, I'll do a bit of -fixes handling, unless you holler
18:39sima: there's also an amd one that showed up today
18:40alyssa: happens with gcc and not clang
18:40alyssa: this has.. got to be a compiler bug.. isn't it...
18:43alyssa: verified the asm, gcc is definitely making an infinite loop. wha
18:44pac85: Time to dig into gcc
18:45alyssa: might still be my own bug
18:45alyssa: Yep. My bug
18:46alyssa: Accidentally had a statically detactable buffer overflow
18:46Lilla: test
18:46alyssa: and since gcc detected that at compile-time, it decided the most appropriate response was to use it to justify breaking unrelated code far away
18:47alyssa: this is why I don't take "we need time travelling UB for performance!!!" seriously
18:51Lilla: sima: Is Hot Unplug (force unbind is what I'm interested in in specific) supported at all now for any GPU? I mean without any oops or kernel panic.
18:51Lilla: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#device-hot-unplug
18:58sima: Lilla, I think amdgpu put in quite a lot of work to make it work reasonably well
18:58sima: but might want to ask agd5f
18:58sima: i915/xe should be pretty well tested too
18:58sima: I think we've also fixed the worst of the fundamental issues
18:58sima: as long as you don't unload the driver itself
19:02Lilla: Thanks for the reply. I asked, because I have issues with amdgpu in practice, despite there being tests: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/lib/amdgpu/amd_pci_unplug.c?ref_type=heads
19:02Lilla: Good to know it's supposed to work, I will try debugging it.
19:18Lilla: sima: Is unbinding, then binding to vfio, then unbinding from vfio, then binding to gpu driver again supposed to work? That is when it breaks for me.
19:18sima: hm, that might be a bit much and hit some issues
19:19sima: I think vfio should clean up everything too, but who knows
19:25Lilla: Could this be a problem when doing that? https://lists.freedesktop.org/archives/amd-gfx/2025-June/126067.html
19:25agd5f: that won't work unless you reset the GPU via the driver in between
19:26agd5f: generic PCI resets don't work
19:28Lilla: agd5f: Is that possible from userspace currently?
19:55agd5f: Lilla, something like this: https://github.com/gnif/vendor-reset
20:00Lilla: agd5f: Is the documentation needed to add support for 9060 XT public?
20:02agd5f: Lilla, yeah, the driver already implements it
20:02Lilla: great, thank you
20:03airlied: sima: got time to send to Linus as well?
20:03sima: airlied, yeah I can do that