00:29 airlied[d]: pushed the first pass of aligning the instruction latency categories for blackwell
00:29 airlied[d]: probably going to have to do another 🙂
03:03 x512[m]: gfxstrand[d]: Do NVK use Vulkan image layout transition? If yes, what does it mean exactly, some kind of inline tiling format conversion?
03:27 chikuwad[d]: rinlovesyou[d]: do you have both drivers installed at the same time?
03:27 chikuwad[d]: i.e. prop and nvk
03:29 rinlovesyou[d]: yes, but this was never an issue in the past
03:29 rinlovesyou[d]: i just blacklist the nvidia module
03:29 rinlovesyou[d]: i have switched to 25.1 staging and it actually works, so something between it and master causes my display to freeze up
03:30 rinlovesyou[d]: now it's just about seeing if kde will freeze again
03:30 rinlovesyou[d]: oh no this is worse actually
03:30 chikuwad[d]: rinlovesyou[d]: oh yeah I know
03:30 rinlovesyou[d]: kde is running on llvmpipe rn
03:30 chikuwad[d]: see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13436#note_2983601
03:35 rinlovesyou[d]: will this break things if i then load back into prop?
03:36 chikuwad[d]: no
03:36 rinlovesyou[d]: alright i'll go back to master and try this out
03:45 rinlovesyou[d]: hmm now it keeps going back to llvmpipe
03:48 rinlovesyou[d]: i must've messed with my build script too much, rolling back to an older one got zink working again
03:48 rinlovesyou[d]: now let's just hope that KDE stops freezing with it
03:52 rinlovesyou[d]: so far so good, thank you very much for that solution
03:55 rinlovesyou[d]: Ah but there it goes freezing again
03:56 chikuwad[d]: oof :\
03:56 rinlovesyou[d]: Will check journal in a bit but pretty sure last time all i got was zink saying "device lost"
04:59 rinlovesyou[d]: oh boy
04:59 rinlovesyou[d]: Jul 18 05:54:36 cachyos-sarah kernel: nouveau 0000:0b:00.0: gsp: mmu fault queued
04:59 rinlovesyou[d]: Jul 18 05:54:36 cachyos-sarah kernel: nouveau 0000:0b:00.0: gsp: rc engn:00000001 chid:40 type:31 scope:1 part:233
04:59 rinlovesyou[d]: Jul 18 05:54:36 cachyos-sarah kernel: nouveau 0000:0b:00.0: fifo:1eae1001:0005:0028:[Xwayland[1385]] errored - disabling channel
04:59 rinlovesyou[d]: Jul 18 05:54:36 cachyos-sarah kernel: nouveau 0000:0b:00.0: Xwayland[1385]: channel 40 killed!
05:09 chikuwad[d]: :Sweat:
06:13 x512[m]: Managarm microkernel OS is also doing Nvidia Open-GPU driver port: https://github.com/managarm/managarm/commit/6cae701a72a63c5f80da8a0e6e1818131916a481.
06:14 x512[m]: Nvidia bring new era of alternative OS hardware GPU acceleration support.
07:27 kar1m0[d]: I wonder if Nvidia will fix the 80w restriction for laptop gpus
07:27 kar1m0[d]: Because it really is annoying
07:32 magic_rb[d]: kar1m0[d]: There is a restriction? My gpu can go to 110w with dynamic boost
07:32 kar1m0[d]: magic_rb[d]: Mine doesn't seem to go above 80
07:33 kar1m0[d]: Even though my tgp/tdp whatever it's called is 145w
07:33 kar1m0[d]: magic_rb[d]: How did you do it? Might work for me as well.
07:33 chikuwad[d]: you have to enable nvidia-powerd
07:33 chikuwad[d]: https://download.nvidia.com/XFree86/Linux-x86_64/510.47.03/README/dynamicboost.html
07:33 magic_rb[d]: ^ i use nixos so no clue how normal distros do it
07:34 kar1m0[d]: chikuwad[d]: It is enabled...
07:34 chikuwad[d]: `systemctl enable --now nvidia-powerd.service`
07:34 chikuwad[d]: kar1m0[d]: what's your hardware?
07:34 kar1m0[d]: chikuwad[d]: Rtx 4080 laptop
07:34 magic_rb[d]: It will dynamically increase the max tdp if it thinks it can
07:34 chikuwad[d]: cpu?
07:34 kar1m0[d]: chikuwad[d]: i7-13700hx
07:34 chikuwad[d]: hm
07:35 chikuwad[d]: alternatively you can see if LACT allows you to change your TDP
07:35 chikuwad[d]: https://github.com/ilya-zlobintsev/LACT/
07:35 magic_rb[d]: Hm indeed, it should work
07:35 chikuwad[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1395670284324966430/image.png?ex=687b4abe&is=6879f93e&hm=5c4a9065dfacacf6e4231aeffa63d922406499faaaca089af422d58c11052395&
07:50 kar1m0[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1395673996271550484/image.png?ex=687b4e33&is=6879fcb3&hm=49cf4504cd53553e39d0617f37d2b73d7f54e9a2c8053f7102adf326124fa716&
07:50 kar1m0[d]: chikuwad[d]: I do not have this?
07:50 chikuwad[d]: rip
08:24 kar1m0[d]: chikuwad[d]: nvidia hates me:(
09:32 airlied[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36217 latencies for blackwell, currently undergoing CTS with coopmat enabled
10:00 airlied[d]: oh I had to put back the magic + 1 on raw, now it should pass CTS
10:00 airlied[d]: nooooo, whack a mole
10:20 OftenTimeConsuming: I seem to have a debug log output for a Xorg hang triggered by firefox, as I know about sysrq: Keyboard mode set to system default now; https://termbin.com/zyoh
16:41 gfxstrand[d]: Anybody want to ACK the NIR patch in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36207?
16:42 gfxstrand[d]: I also need to figure out how to handle pre-Volta null descriptors from just the descriptor bits. Not sure how I'm gonna do that just yet.
16:45 gfxstrand[d]: Volta+ has a `COMPONENTS_SIZES_INVALID` which gives null descriptor behavior. Pascal and earlier don't
16:46 gfxstrand[d]: And since the sizes are specified as `FOO_MINUS_ONE` everywhere, there's no way to have a zero-size descriptor
16:48 gfxstrand[d]: karolherbst[d]: Is there anything useful in .w returned by `txq.dimension`? I think texture type and sampler pos are out
16:48 karolherbst[d]: yes
16:49 karolherbst[d]: for buffer and non mipmapped textures it returns 1, for anything else it returns the number of levels
16:49 gfxstrand[d]: Right...
16:49 gfxstrand[d]: I wonder if I can specify zero levels
16:50 karolherbst[d]: I mean.. that's like no image 😛
16:50 gfxstrand[d]: I guess this means I need to plug my maxwell back in
16:50 karolherbst[d]: I'm sure it's just 1 based on nvidia, because anything else is a little weird
16:51 gfxstrand[d]: Yeah, MAX_MIP_LEVEL is -1 as well. 😭
16:51 gfxstrand[d]: But maybe I can specify an absurd number of levels?
16:51 karolherbst[d]: what do you need it for?
16:52 gfxstrand[d]: I need to be able to detect null texture descriptors
16:52 karolherbst[d]: is it a 0x0x0 sized image?
16:53 gfxstrand[d]: Yes but you can't specify that because all the dimensions are -1
16:53 karolherbst[d]: mhhhh
16:54 karolherbst[d]: I wonder what happens if you specify the min miplevel to be 1 for a single level image
16:54 karolherbst[d]: because the returned value is relative to that
16:55 gfxstrand[d]: So right now we're setting `MIN_MIP_LEVEL = 1` and `MAX_MIP_LEVEL = 1`
16:55 gfxstrand[d]: Let's see what txq.dimension does with that
16:55 karolherbst[d]: mhhh funky
16:55 gfxstrand[d]: If the hardware just does the obvious subtraction, we might get 0
16:56 karolherbst[d]: that feels illegal 😄
16:56 gfxstrand[d]: Eh, old hardware is frozen in time. If it works it works.
16:59 gfxstrand[d]: Looks like TXQ will do it
16:59 gfxstrand[d]: Sweet
17:00 karolherbst[d]: ufnky
17:01 karolherbst[d]: still feels illegal 😄
17:01 gfxstrand[d]: meh
17:01 gfxstrand[d]: We've been writing the null descriptors that way for a while and they work. This just means I have a way to detect them.
17:27 gfxstrand[d]: I might also need to do something with image reads/writes. I think technically a write to a null at (0, 0) might be writing data today which can then be read by a similar read.
18:59 gfxstrand[d]: The sins I am committing with txq...
19:41 airlied[d]: gfxstrand[d]: fyi on my 5080 the latency MR I submitted seems to pass CTS
19:47 gfxstrand[d]: \o/
19:47 gfxstrand[d]: I'll run it on my 5090, too
22:02 gfxstrand[d]: airlied[d]: Running now. I'll review on Monday.
23:22 mhenning[d]: That's an issue with downloading the repository, and you download all the files even if you're not compiling all of them