00:42 snowycoder[d]: marysaka[d]: Can I help with those? They seem doable
02:23 mhenning[d]: snowycoder[d]: Yeah, if you can figure it out I think that would be appreciated
06:52 anholt: working on closing out some old MRs of mine. If one of you has an nvidia proprietary setup and could send me a glxinfo and the test log of dEQP-EGL.info.configs, that would help.
10:50 snowycoder[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1339911517679652904/glxinfo_gtx1660.txt?ex=67b07158&is=67af1fd8&hm=cbcccfd80c4e18360f6b5436b88f35a77f1c1179ec5a1b50e746e72905cb6135&
10:50 snowycoder[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1339911518094885007/TestResults_gtx1660.qpa?ex=67b07158&is=67af1fd8&hm=7c7dbe09efaaf68c51e5be428630611f0f520725e44cf92ccb12934d6f5f8cce&
10:50 snowycoder[d]: anholt: Here are the results for nvidia-open 570.86.16-6 for my GTX 1660
10:50 snowycoder[d]: If you need the results for the closed-source drivers I can install them
10:50 tiredchiku[d]: the kernel module makes no difference in userspace caps fwiw
10:51 tiredchiku[d]: as in, nvidia-open and old nvidia prop module
11:36 gfxstrand[d]: Ugh... Chromium is double-waiting on a binary semaphore. 😫
11:39 gfxstrand[d]: Maybe? I don't see a reset between them so maybe okay?
11:41 gfxstrand[d]: And they're shared semaphores so even though they're in the same process (probably) I can't tell what signals map to what waits.
11:41 gfxstrand[d]: If this is a chromium bug why doesn't it repro on other drivers? If this is a NVK bug, how?!?
11:44 gfxstrand[d]: airlied[d]: any thoughts on how to make syncobjs globally identifiable? I know that's a potential security hazard so maybe behind a flag or in debugfs but it would be nice to have something.
11:45 gfxstrand[d]: Otherwise, debugging shared sync stuff is hell.
11:46 gfxstrand[d]: gfxstrand[d]: Okay, Zink+ANV has the same problem. I'm not going crazy. 😅
15:08 zmike[d]: strong work
15:17 gfxstrand[d]: Unfortunately, not the whole bug. 😭
15:37 gfxstrand[d]: I think I found the real bug but now I don't know what to do about it
15:44 gfxstrand[d]: When the client does `glWaitSemaphoreEXT()`, Zink throws away the `VkSemaphore`.
15:44 gfxstrand[d]: It's supposed to be persistent
15:44 gfxstrand[d]: I have no idea how there aren't CTS tests for this
15:46 redsheep[d]: Sounds like nvk has no bugs
15:56 gfxstrand[d]: gfxstrand[d]: Well, that was A bug but not THE bug
16:03 anholt: snowycoder[d]: super useful, thanks! and so weird (sRGB GLX visuals only with MSAA?!)
16:04 zmike[d]: gfxstrand[d]: there aren't cts tests for any of that stuff I don't think
16:04 zmike[d]: testing for EXT is optional
16:04 zmike[d]: and what do you mean throws away?
16:04 gfxstrand[d]: Check the MR
16:05 gfxstrand[d]: I just pushed a patch
16:06 gfxstrand[d]: It's also entirely possible that chromium is busted, too
16:06 gfxstrand[d]: But I think it works with ANV+Iris
16:07 gfxstrand[d]: But it's so hard to tell what's actually going on in that app. 😭
16:08 zmike[d]: huh
16:08 zmike[d]: ok
16:08 zmike[d]: hm
16:08 gfxstrand[d]: Someone somewhere isn't signaling a semaphore they said they did
16:09 gfxstrand[d]: But with those two bugs fixed, I'm having trouble convincing myself that Zink missed anything.
16:11 gfxstrand[d]: Also, Zink has a double-memory-map bug
16:11 gfxstrand[d]: I should find and fix that
16:12 zmike[d]: buH/
16:12 zmike[d]: it does?
16:15 gfxstrand[d]: Yeah. Not sure how yet
16:15 gfxstrand[d]: It's also possible there's a memory corruption somewhere. :blobcatnotlikethis:
16:15 gfxstrand[d]: Honestly, that would explain a lot
16:20 gfxstrand[d]: Ugh... I need to disable threaded context
16:25 gfxstrand[d]: How do I force a threaded context sync?
16:27 zmike[d]: something like `ctx = zink_tc_context_unwrap(pctx, screen->threaded);`
16:27 zmike[d]: or just `threaded_context_unwrap_sync(pctx)`
16:32 gfxstrand[d]: Well, disabling TC doesn't fix it. 😢
16:38 zmike[d]: that's good because tc bugs are the hardest to fix
16:40 gfxstrand[d]: I really wish there were a good way to know what a syncobj actually was at the kernel level. 😕
16:40 zmike[d]: I wish they weren't so fucking slow
17:15 asdqueerfromeu[d]: zmike[d]: Is `pctx` an `Option<ZinkContext>`? /s
17:20 zmike[d]: Don't get rust on my zink
17:33 redsheep[d]: It's a good thing it's resistant to corrosion
17:36 karolherbst[d]: I just had a brilliant idea
17:37 gfxstrand[d]: I think this is going to need a piglit test...
18:00 zmike[d]: karolherbst[d]: NO
18:01 karolherbst[d]: it's too late
18:14 orowith2os[d]: Are there pieces of zink that would even benefit from Rust?
18:14 orowith2os[d]: Might not be too far fetched to have some stuff with it if it makes some of it less of a headache
18:15 gfxstrand[d]: Sandwiching rust between C and C often isn't as good an idea as it sounds. Partially converting so you have C on a third side is less of a good idea.
18:16 gfxstrand[d]: If one were to write Zink today, would it benefit from being written in Rust? Maybe?
18:17 orowith2os[d]: I guess that's fair
18:17 orowith2os[d]: Considering the hell that I've seen in rusticl, I don't know if I'd like it with OpenGL either
18:18 karolherbst[d]: the thing with zink is, that it deals with a lot more of a shared C API, so not sure if it's more of a bother for everybody else in the end
18:21 orowith2os[d]: Maybe if someone tries to write a gallium driver in rust, they'd be able to give some more details on it
18:26 gfxstrand[d]: I think the first patch in !33549 is a correct and a good idea and also impossible to hit since you never have glSignalSemaphore and a swapchain at the same time.
18:26 gfxstrand[d]: I think the second patch is BS but I also think I'm roughly on to something. We need a ping-pong piglit test to debug fully, though.
18:31 gfxstrand[d]: I'm going to need to dig in and actually understand Zink's glWaitSemaphore path before I can fix it, though. There are too many assumptions in that path for quick hacks.
18:32 zmike[d]: I think the second patch is correct according to spec; I had apparently misunderstood that gl semaphores were onshot use objects
18:39 gfxstrand[d]: Yeah but I don't think it's enough, hence the need to grok.
18:40 zmike[d]: 🤔
18:40 gfxstrand[d]: And I'm tired of "run all of chromium being the CTS test. :frog_upside_down:
18:40 zmike[d]: yep
18:43 zmike[d]: fwiw it runs great on radv
18:45 zmike[d]: oh wait, it locks up here too
18:45 gfxstrand[d]: What does?
18:45 gfxstrand[d]: Yup
18:45 zmike[d]: good that you're looking into this
18:48 snowycoder[d]: mhenning[d]: This fixes all reported failures https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33555.
18:48 snowycoder[d]: Tl;Dr: preprocess buffer alignment was not reported in `getDeviceBufferMemoryRequirements` making all DGC tests fail at buffer allocation.
19:06 gfxstrand[d]: snowycoder[d]: Good catch! Left you one comment.
19:08 gfxstrand[d]: zmike[d]: This is what happens when someone at Collabora says, "We should demo NVK! How about demoing with chromium and WebGPU?"
19:08 gfxstrand[d]: But I don't mind much because Chrome working is kinda important...
19:13 zmike[d]: gfxstrand[d]: tbf when I was working on aquarium there was no vulkan mode to enable
19:14 zmike[d]: you are reaping the benefits of the future you helped bring about
19:20 gfxstrand[d]: https://tenor.com/view/fry-futurama-frozen-gif-260392732511353704
19:23 snowycoder[d]: gfxstrand[d]: Thanks! Left a fast question.
19:23 snowycoder[d]: (Also if you have any ideas on how to solve the sync issue in `VK_EXT_discard_rectangles` give me a pointer, I'm out of ideas)
19:40 airlied[d]: gfxstrand[d]: I suppose we could just add uuids to them all :-), but maybe a debugfs option to label them though adding any sort of cross process sync point to add a global identifier might hide other bugs 😦
19:42 gfxstrand[d]: airlied[d]: I did think about a UUID query. Debugfs feels a bit heavyweight if they're getting created and destroyed often.
19:43 gfxstrand[d]: Just have an atomic u64 and assign one to every syncobj.
19:43 gfxstrand[d]: IDK if people would think that's a security issue, though.
19:45 gfxstrand[d]: Or let the creator label them somehow.
19:45 gfxstrand[d]: But damn if it wouldn't be useful...
19:47 gfxstrand[d]: Obviously, you wouldn't be able to turn a UUID into a handle. You could just see the UUID of one you already have a handle to.
20:03 gfxstrand[d]: airlied[d]: would an atomic u64 be enough or is there some fast enough UUID generator we should use instead?
20:08 gfxstrand[d]: Hey, look! uuid.c!
20:11 airlied[d]: Other option is give userspace a place to provide a unique name, to avoid locks or atomics
20:13 gfxstrand[d]: Yeah. Might be useful to know where it came from. But then we have to write two ioctls, deal with races, and handle passing strings in and out of the kernel. That sounds like a pain.
20:14 gfxstrand[d]: But `get_random_bytes()` sounds expensive.
20:14 gfxstrand[d]: I guess we could always assign UUIDs on demand instead of doing it up-front. That way we wouldn't pay the cost unless we need it.
20:15 gfxstrand[d]: That sounds non-terrible
22:01 redsheep[d]: gfxstrand[d]: I wonder if what you're working on will fix the visual corruption, because that seemed vague like a sync issue, probably with DMA bufs
22:02 gfxstrand[d]: Unlikely
22:02 gfxstrand[d]: This seems pretty specific to GL Vulkan interop.