01:21 fdobridge: <g​fxstrand> Indirect is so much more annoying pre-Turing.
01:24 fdobridge: <k​arolherbst🐧🦀> because of mme limitations?
01:30 fdobridge: <g​fxstrand> Yeah
01:31 fdobridge: <g​fxstrand> 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:32 fdobridge: <g​fxstrand> I'm calling it quits for the week. Next week, I'll hopefully get back to NAK.
01:33 fdobridge: <k​arolherbst🐧🦀> nice
01:34 fdobridge: <k​arolherbst🐧🦀> 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:39 DodoGTA: What is fdobridge?
02:06 fdobridge: <J​., Echo (she) 🇱🇹> And this server is why it exists 🐸
11:27 fodasso: Hello, do I need the libdrm_intel kernel driver in order to use NVK or drm-next?
17:47 fdobridge: <g​ouz> @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:49 fdobridge: <g​fxstrand> 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:50 fdobridge: <g​fxstrand> In theory, if the builder succeeds, it should work the same on both.
17:50 fdobridge: <g​fxstrand> There are some minor differences like pre-Turing can't shift by zero.
17:50 fdobridge: <g​ouz> the test runs on the sw simulator?
17:50 fdobridge: <g​fxstrand> We could certainly do that, yes.
17:51 fdobridge: <g​fxstrand> 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:52 fdobridge: <g​ouz> ahh i see, so the builder will fail if i use more registers
18:48 fdobridge: <E​sdras Tarsis> ```
18:48 fdobridge: <E​sdras Tarsis> [ 3.148712] nouveau 0000:08:00.0: gsp: firmware "nvidia/tu117/gsp/gsp-5256011.bin" unavailable
18:48 fdobridge: <E​sdras Tarsis> [~] $ ls /lib/firmware/nvidia/tu117/gsp
18:48 fdobridge: <E​sdras Tarsis> gsp-5256011.bin
18:48 fdobridge: <E​sdras Tarsis> ```
18:48 fdobridge: <E​sdras Tarsis> what
18:51 fdobridge: <k​arolherbst🐧🦀> did you add it to your initramfs?
18:52 fdobridge: <E​sdras Tarsis> I don't think so, I just updated the initramfs with mkinitcpio
18:54 fdobridge: <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:55 fdobridge: <E​sdras Tarsis> I just compiled using localmodconfig
19:04 fdobridge: <E​sdras Tarsis> The firmware is a big chungus 🐸
19:24 fdobridge: <E​sdras 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:27 fdobridge: <E​sdras Tarsis> https://cdn.discordapp.com/attachments/1034184951790305330/1063902079233556520/PXL_20230114_192642866.jpg
19:29 fdobridge: <k​arolherbst🐧🦀> yeah....
21:50 fdobridge: <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:29 fodasso: 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:29 fodasso: Could this mean my hardware is faulty?
23:30 HdkR: CPU crashes don't always mean your hardware is faulty
23:31 HdkR: More likely a driver bug
23:34 fodasso: This happens on any mesa version higher than 22.2.3, even with mesa-nvk-9999
23:34 fodasso: Tried both sway and wayfire, but am unable to start either of them.
23:34 fodasso: Could it be a wlroots incompatibility? Should I try a DE?
23:35 fodasso: RTX 2060, so it should theoretically work...
23:35 HdkR: If you go back to an older mesa version and it doesn't reproduce then it is likely a regression.
23:35 HdkR: 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:36 fodasso: OK, will take a look at it.