00:00 karolherbst[d]: I have no idea how much testing zink ever got for highly threaded applications
00:00 gfxstrand[d]: Nah. Piglit fires up a new process for every test
00:00 karolherbst[d]: somebody should maybe run the android emulator with native GL on top of zink + nvk
00:00 karolherbst[d]: that's going to hit every possible multi threading bug
00:01 karolherbst[d]: (and I made sure that stuff all works on the nvc0 driver)
00:02 karolherbst[d]: I've fixed some of those for rusticl, but I think there are a couple more bugs lurking inside zink
00:02 gfxstrand[d]: Bugs? In Zink?!?
00:03 karolherbst[d]: though the vvl also report some of the thread-safety violations
00:03 karolherbst[d]: bonus points when running on top of nvidia vulkan
00:03 karolherbst[d]: they _heavily_ make use of all those thread-safety guarantees or rather lack thereof
00:03 karolherbst[d]: they don't make anything thread safety unless they have to by spec :ferrisUpsideDown:
00:04 karolherbst[d]: *safe
00:04 karolherbst[d]: anyway.. making the android emulator run without problems would be a good place to start. I just don't know how much they are using vulkan already, so one might need to drop down the android version run inside it a bit
00:06 redsheep[d]: gfxstrand[d]: That fixed it so I don't need no_cbuf anymore, so the general zink breakage on main and the wayland session are fixed by 29737 now
00:06 redsheep[d]: Glad you could retroactively make me not wrong about that MR being the fix lmao
00:06 gfxstrand[d]: hehe
00:11 redsheep[d]: So what is even different between the state of 29737 and the cb0-rebase at this point?
00:14 redsheep[d]: The gitlab comparison tool is annoying, and lies to me telling me still saying all the stuff from cb0-rebase isn't in main
00:24 redsheep[d]: I am not sure if I should mention this since it seems impossible, but for whatever reason the last two fixes in 29737 also seem like they fixed the rest of the instability with the wayland session. All the crashing and visual artifacts are gone, to the point this might even be better than how the x11 session was before
00:26 redsheep[d]: I don't get how that makes sense given I was literally using an environment variable called no_cbuf but 🤷
00:31 gfxstrand[d]: gfxstrand[d]: Piglit's happy. Running Vulkan CTS again just to be sure
00:32 gfxstrand[d]: redsheep[d]: Mostly how they select when to use bound cbufs vs. bindless.
00:32 gfxstrand[d]: main and 29737 are still using bound as much as possible. It's bad for the big GPUs but it's fast if you can eat the stalls.
00:32 redsheep[d]: Oh the newer discord artifact just came back, ok impossible thing was impossible
00:33 gfxstrand[d]: I've got some ideas for improving it.
00:33 gfxstrand[d]: I need to stare at what the blob is doing
00:35 redsheep[d]: Sounds good, yeah they must be doing some real magic. Seems like this stuff is responsible for a pretty huge performance swing for sure
00:36 gfxstrand[d]: Not from what I've seen. I just need to get a feel for their strategy and what I want to do.
00:36 gfxstrand[d]: It looks like they use bound cbufs for some of the dynamic buffers. They might also be using them for descriptor sets sometimes.
15:24 Grzesiek11: hello, I wanted to try out nouveau on my GTX 660. it mostly works, but I am facing https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/248. I wanted to try loading the binary blobs, as suggested, I extracted them, but they fail to load: https://paste.debian.net/1320353/
19:20 pavlo_kozlenko[d]: rabbit hole