00:05airlied[d]: definitely doesn't have bounds check
01:08airlied[d]: okay last blackwell fail fixed
01:25gfxstrand[d]: I suppose I should come out of my hole and review patches some time.
01:25airlied[d]: you should at least get off the texture descriptor fence 🙂
01:25gfxstrand[d]: airlied[d]: I assume you're not including host image copy?
01:26airlied[d]: no I have a vk1.3 patch in my tree 🙂
01:26gfxstrand[d]: Hehe
01:27gfxstrand[d]: airlied[d]: This rabbit hole is deep...
01:27gfxstrand[d]: https://tenor.com/view/alice-rabbithole-falling-tumbling-bye-gif-5308157
01:27airlied[d]: I think just being happy with the extra column in the table would be a start
01:29gfxstrand[d]: Yeah... I think I probably am. I poked at it long enough to give up a few weeks ago.
03:39airlied: anarsoul: https://paste.centos.org/view/raw/3c11a4f7 could you try Linus tree + that to see if your device is happy?
03:40anarsoul[m]: Sure, I can try tomorrow
03:43airlied: maybe grab the patch in the paste in case it expires
03:52mangodev[d]: karolherbst[d]: what makes descriptors for dx12 so slow? are they used sub-optimally, is it extra bandwidth, or is it a different kind of descriptor?
04:44airlied: anarsoul: https://paste.centos.org/view/cd38da86 actually that one instead :-)
05:12airlied: anarsoul: https://lore.kernel.org/dri-devel/20250617050904.153255-1-airlied@gmail.com/T/#u is the offical version
05:13anarsoul[m]: Thanks, I'll try it tomorrow
06:40akyoto: hi, would this be an appropriate channel to ask for help with nouveau troubles during boot? or is the channel more dev oriented?
07:37akyoto: I tried 4 different kernels (6.15, drm-misc, nouveau master, 6.16-rc2) with varying degrees of success/failure
07:37akyoto: the log from the latest try: https://files.urbach.dev/dmesg.txt
08:26mangodev[d]: akyoto: both
08:26mangodev[d]: this channel has a good amount of dev stuff, but it also can be user support or informal issue reporting
08:26mangodev[d]: although dri-devel is more user-oriented (although dead, last time i checked)
09:05karolherbst[d]: `Are you using #"Nouveau" for full-text search in @couchdb?` we've gone too far
12:55ristovski[d]: I wonder, are there plans for nvidia to document/open source their OEM-level control of stuff like V/F curves and fan curves? afaik, stuff like MSI Afterburner uses NVML/NVAPI (but the juicy "secret" functions that aren't documented), so I don't see anything preventing better linux support in that regard
12:56karolherbst[d]: with GSP that's kinda pointless, no?
12:56ristovski[d]: I _may_ have at one point hypothetically traced certain MSI Afterburner calls, but iirc the stuff I was looking at wasn't (and still isn't) implemented in the GSP firmware (so I assume the functionality remains only in the blob drivers)
12:57karolherbst[d]: fan controls on newer chips are kinda locked down
12:58ristovski[d]: karolherbst[d]: at least stuff like undervolting and more granular clock controls would be nice (nvml allows changing clocks, but its very restrictive - its essentially a global offset)
12:58karolherbst[d]: so not even sure what those tools even do
12:58karolherbst[d]: ristovski[d]: I think there are GSP methods for it
13:00ristovski[d]: yeah I kinda got lost at that level, I was able to find the hidden nvapi methods that MSI Afterburner is using, but wasn't able to "replay" the same on linux with gsp
13:01ristovski[d]: (did manage a couple that fetch stuff, but the reply struct indicated that the GSP didn't have the functionality implemented yet)
13:02ristovski[d]: still baffles me why those are secret sauce anyway
13:04pavlo_kozlenko[d]: classic
13:23mohamexiety[d]: ristovski[d]: the blob drivers have already moved to the GSP as Blackwell doesn't support the older path
13:23mohamexiety[d]: so this functionality is probably implemented now
14:42ristovski[d]: mohamexiety[d]: I should re-test then, I'm still on 570.133.07
18:05anarsoul: airlied[d]: the patch didn't fix the issue for me
18:05anarsoul: i.e. I still get mmu faults in dmesg
18:05anarsoul: on a simple vulkaninfo run
18:13anarsoul: and kwin (wayland) hangs if I attempt to start vkcube on NVK
18:25anarsoul: vkcube failures: https://gist.github.com/anarsoul/ff875637179b4d02528cf95663ca00b7
18:28anarsoul: vulkaninfo mmu fault: https://gist.github.com/anarsoul/08925b9ad9190bc7842385e20bb125f4
18:29anarsoul: and a warn: https://gist.github.com/anarsoul/cf0d2617cdd2ef969038d769aa49e7ca
19:53airlied_: anarsoul: dang it, that was the __GFP_ZERO one? did either of the earlier ones work?
19:54anarsoul: that was __GFP_ZERO
19:57anarsoul: I didn't try earlier changes yet
19:58airlied_: I need to try harder to reproduce doom then, zeroing seems to paper over some of it here :-)
19:59anarsoul: it's not intermittent on my end, i.e. it fails every time
21:36pavlo_kozlenko[d]: Goodbye all
21:37pavlo_kozlenko[d]: you are good community
21:37pavlo_kozlenko[d]: I wish the project development, so good luck with reverse engineering Pascal
21:37pavlo_kozlenko[d]: karolherbst[d]: Well done for kicking that guy (xlibre)
22:27airlied_: anarsoul: https://paste.centos.org/view/2ae7dd2a okay if you get a chance see if this makes any difference
22:30anarsoul: compiling
22:37ismael: I'm on a rescue boot mode and using a secondary card's monitor for output (fbcon=map:1), and I noticed whenever the screen goes blank it doesn't restore afterwards, but I can make it come back using fbset
22:38ismael: so I'm guessing something is missing, i915 works fine on the same system
22:39ismael: I'm just running fbset -fb /dev/fb1 -g 3840 2160 3840 2160 32
22:41anarsoul: airlied: this one fixes the issue. Let me run it for a little longer though
22:42airlied: dang it I was afraid it would
22:42airlied[d]: skeggsb9778[d]: ^ looks like the zero was jinxed
22:43airlied: this really makes no sense
23:20airlied[d]: skeggsb9778[d]: should probably set the enteringgcoff flag on r535 as well
23:26ismael: [14330.714937] ACPI: \_SB_.PCI0.PEGP.DGFX: failed to evaluate _DSM
23:26ismael: may this have something to do with it?
23:32ismael: it seems definitely related to optimus