Asahi Linux Continues Making Progress On Apple Silicon Graphics, Promising OpenGL Speed

[robclark]

Of course it isn't, but dealing with implicit sync in kernel space is slower than explicit sync which is the point.

Sure.. CrOS and android are both all-explicit, so I'm well aware of the benefits.. and I'm also well aware that it is easy to allow userspace to ask to disable the implicit sync path on the kernel side (either globally or just the buffers which aren't shared with a window system that expects implicit sync[1]), getting all the same benefits. The only drawback is some legacy code-paths that are only hit for old userspace, but no real drawback for modern userspace. And eventually, years down the road, a new driver with no legacy code-paths today will earn it's own legacy codepaths ;-)

[1] https://lore.kernel.org/lkml/CAF6AEG...mail.com/T/

[mdedetrich]

And dealing with implicit sync in userspace isn't any faster.

Of course it isn't, but dealing with implicit sync in kernel space is slower than explicit sync which is the point.

[GeneralZod]

Not yet

Now it does (just about ).

[robclark]

Yeah I don't see what point he is making in his argument. Shifting it to userpsace is a good thing because you don't want these slow overhead workarounds on the driver level/kernel space. The fundamental issue with Linux wrt implicit/explicit sync is that part of its core in kernel graphics stack/drivers is still dealing with implicit sync. We will always have to deal with implicit sync somewhere, but the ideal situation is that we only deal with it in userspace.

My point is that we still have implicit sync.. I totally agree that it is the right thing for a new kernel driver not having to care about older userspace to not deal with it in the kernel. But that as long as we have to deal with it somewhere the problem hasn't gone away and nothing has gotten faster. The net result is just the new driver has a tiny bit less code in the kernel. Certainly a good thing, but other drivers can still do explicit sync on the kernel side so the kernel side isn't holding anyone back. And dealing with implicit sync in userspace isn't any faster.

[mdedetrich]

OpenGL is implicit sync, Vulkan is explicit sync, and Zink is a userspace OpenGL-on-Vulkan implementation... thus the portmanteau of Zink and Sync.

Touché

[ssokolow]

Sorry dont get this

OpenGL is implicit sync, Vulkan is explicit sync, and Zink is a userspace OpenGL-on-Vulkan implementation... thus the portmanteau of Zink and Sync.

[mdedetrich]

Zync.

Sorry dont get this

[ssokolow]

We will always have to deal with implicit sync somewhere, but the ideal situation is that we only deal with it in userspace.

Zync.

[mdedetrich]

The important bit is that by shuttling it into userspace *only* userspace has to worry about it.

It no longer has to be dealt with on both sides, which means not being involved in the uAPI and it's eternity-plus-one-day stability guarantees.

Yeah I don't see what point he is making in his argument. Shifting it to userpsace is a good thing because you don't want these slow overhead workarounds on the driver level/kernel space. The fundamental issue with Linux wrt implicit/explicit sync is that part of its core in kernel graphics stack/drivers is still dealing with implicit sync. We will always have to deal with implicit sync somewhere, but the ideal situation is that we only deal with it in userspace.

[GeneralZod]

but can it run Crysis?

Not yet

I also tried Crysis but it hangs at 100% after the loading screen for some reason, though the main menu was very smooth too ^^;;

Thank you everyone who sent me game gifts so I could try them!!!

Edit: No idea why the heart emoji is so humungous, but I'm not removing it