01:21fdobridge: <gfxstrand> Indirect is so much more annoying pre-Turing.
01:24fdobridge: <karolherbst🐧🦀> because of mme limitations?
01:30fdobridge: <gfxstrand> Yeah
01:31fdobridge: <gfxstrand> Indirect is landed. I've not done indirect dispatch yet but that should be easy. The only other thing is `vkCmdCopyQueryPoolResults()` and I think Maxwell is roughly on-par with Turing. 😄
01:32fdobridge: <gfxstrand> I'm calling it quits for the week. Next week, I'll hopefully get back to NAK.
01:33fdobridge: <karolherbst🐧🦀> nice
01:34fdobridge: <karolherbst🐧🦀> I'll be done with all the RHEL DRM backporting soon, so I'll will have more time for random stuff and also nvk
01:39DodoGTA: What is fdobridge?
02:06fdobridge: <J., Echo (she) 🇱🇹> And this server is why it exists 🐸
11:27fodasso: Hello, do I need the libdrm_intel kernel driver in order to use NVK or drm-next?
17:47fdobridge: <gouz> @gfxstrand how can one write mme code and be sure that it will run on pre-Turing if there is no access to that hardware?
17:49fdobridge: <gfxstrand> Someone should add a build test that runs all the NVK MME builders on both Turing and pre-Turing. 🤔 It wouldn't be that hard.
17:50fdobridge: <gfxstrand> In theory, if the builder succeeds, it should work the same on both.
17:50fdobridge: <gfxstrand> There are some minor differences like pre-Turing can't shift by zero.
17:50fdobridge: <gouz> the test runs on the sw simulator?
17:50fdobridge: <gfxstrand> We could certainly do that, yes.
17:51fdobridge: <gfxstrand> I was thinking just run the builder and make sure you don't use any Turing-only features and you keep your register count on check.
17:52fdobridge: <gouz> ahh i see, so the builder will fail if i use more registers
18:48fdobridge: <Esdras Tarsis> ```
18:48fdobridge: <Esdras Tarsis> [ 3.148712] nouveau 0000:08:00.0: gsp: firmware "nvidia/tu117/gsp/gsp-5256011.bin" unavailable
18:48fdobridge: <Esdras Tarsis> [~] $ ls /lib/firmware/nvidia/tu117/gsp
18:48fdobridge: <Esdras Tarsis> gsp-5256011.bin
18:48fdobridge: <Esdras Tarsis> ```
18:48fdobridge: <Esdras Tarsis> what
18:51fdobridge: <karolherbst🐧🦀> did you add it to your initramfs?
18:52fdobridge: <Esdras Tarsis> I don't think so, I just updated the initramfs with mkinitcpio
18:54fdobridge: <J., Echo (she) 🇱🇹> I actually have a TU117 GPU so I can also try this (assuming I can wait for the kernel to compile 🐸)
18:55fdobridge: <Esdras Tarsis> I just compiled using localmodconfig
19:04fdobridge: <Esdras Tarsis> The firmware is a big chungus 🐸
19:24fdobridge: <Esdras Tarsis> @karolherbst🐧 @ASDQueerFromEU I added in FILES=() in mkinitcpio and now it is loading gsp but the screen freezes after that with some glitch pixels appearing
19:27fdobridge: <Esdras Tarsis> https://cdn.discordapp.com/attachments/1034184951790305330/1063902079233556520/PXL_20230114_192642866.jpg
19:29fdobridge: <karolherbst🐧🦀> yeah....
21:50fdobridge: <J., Echo (she) 🇱🇹> The closest thing to that I've seen is some weird screen flashes at one corner of the screen (only with the NVIDIA driver; nouveau was fine)
23:29fodasso: segfault at 20 ip 00007f467e0e1aef sp 00007ffd9b0a2490 error 4 in nouveau_dri.so[7f467d60f000+dc7000] likely on CPU 0/8 (core 0, socket 0)
23:29fodasso: Could this mean my hardware is faulty?
23:30HdkR: CPU crashes don't always mean your hardware is faulty
23:31HdkR: More likely a driver bug
23:34fodasso: This happens on any mesa version higher than 22.2.3, even with mesa-nvk-9999
23:34fodasso: Tried both sway and wayfire, but am unable to start either of them.
23:34fodasso: Could it be a wlroots incompatibility? Should I try a DE?
23:35fodasso: RTX 2060, so it should theoretically work...
23:35HdkR: If you go back to an older mesa version and it doesn't reproduce then it is likely a regression.
23:35HdkR: Which can be used to createa bug report for how a developer can reproduce the issue and bisect down to the exact change that broke it.
23:36fodasso: OK, will take a look at it.