KDE's KWin Merges Wayland Explicit Sync Support

[byteabit]

Better late than never.

[Brittle2]

Great, now imagine if the Wayland folks listened to Nvidia 10 years and supported superior EGLStreams instead of sticking to shitty GBM. Wayland could’ve taken way less than 16 years to be adopted. Lol

xwayland had eglstreams, abd was as shit as you imagine, the moment nvidia stoped pushing that shit it was removed

[oiaohm]

The problem was that wayland devs were asses about wanting "every frame is perfect" while everyone else already knew that explicit sync was the way forward.
Nvidia, vulkan, ubuntu's mir, android are all explicit sync.

Fast forward 10 years and now we have tearing protocol and explicit sync

The old disconnected mir protocol by Ubuntu/canonical did not include explicit sync instead was also implicit sync based.

Android and Vulkan explicit sync both intentionally don't cover buffer allocation and free operations these are left as implicit synced operations. Windows graphics. drivers are in fact the same where explicit sync for most things but buffer allocations and free are still implicit synced. This split between explicit and implicit sync seams to work.

Nvidia with eglstreams tried to explicit sync everything including buffer allocations and frees problem is this just does not work. Nvidia funded developers found this out the hard way. The Nvidia support of GBM and DRI3 has most of their driver explicit sync with memory management now implicit sync. Reason why Nvidia wanted to avoid this implicit sync on memory management as this implicit sync on memory management equals having to work with Linux core kernel parts so needing to release driver source code as GPLv2 compatible license.

DRI2 and DRI1 in the open source driver stacks did also try avoiding having full implicit sync memory management with kernel integration this did cause security issues and stability issues. Eglstreams also displayed the same security and stability issues. Memory management there are limited ways you can do this well.

Yes the explicit sync supported by Wayland is close to the Android explicit sync in design. The first version of the protocol just merged for explicit sync was proposed in 2016 was rejected because it was not generic and only worked with Open source driver. The reality here is if Nvidia had not done eglstreams but instead followed the GBM/DRI3 route we would have had explicit sync in Wayland in 2016. Lot of the work fixing up xwayland for explicit sync would have been done sooner because the developer time attempting to make eglstreams work with Xwayland would have gone into Xwayland for explicit sync with GBM/DRI3.

Hindsight is 20/20. Like it or not Nvidia made a mistake with their push to Explicit sync with eglstreams this has wasted years of developer time. Yes everything we are seeing for explicit sync now with Wayland we should have been seeing 2013-2017 as part of DRI3 on Linux if eglstreams never happened. Without eglstreams we would not know that explicit sync memory management is a total disaster plan. Also eglstreams shows the how important it is to listen to peer review because there was peer review after peer review of eglstreams by vendors outside Nvidia pointing at the memory management as a major issue but the Nvidia developers were sure they were right so they ignored it.

Every frame is perfect is a mode we do need. Lot of ways the tearing protocol as optional request is correct people with visual triggered epilepsy at times require the option to disable tearing being displayed and with the way the tearing protocol is done in wayland protocol the wayland compositor is free to go I am ignoring application request for tearing and enforcing tear free. If you want as many humans a possible to be able to use the software every frame is perfect/tear free is a requirement that you must be able to turn on and perform successfully.

petete there is something important to remember. Nvidia developers have stopped working on making eglstreams work and Nvidia has left users with cards that open source people cannot write functional third party drivers with due to lack of firmware and these cards are not getting their closed source drivers from Nvidia updated to support the newer GBM/DRI3 interfaces. So yes Nvidia screws up implementing something then leaves their users who bought their product to live with the fault.

[gufide]

it is not always inferior, there were cases when AMD engineer admitted it is superior. Simply EGLstreams didn't account for certain cases, but GBM also doesn't and you have solutions "around it" to make certain things work.

Surely there is some aspects EGLStreams was a good solution to some problems, specifically for tiled rendering, explicit sync and other stuff, but is considerably inferior to properly render a desktop where every frame is exactly what it's supposed to be.

NVidia had another solution for a generic Unix device memory allocator but it went nowhere.

[RealNC]

This is only for kwin 6, I guess? Not 5.

[oiaohm]

Surely there is some aspects EGLStreams was a good solution to some problems, specifically for tiled rendering, explicit sync and other stuff, but is considerably inferior to properly render a desktop where every frame is exactly what it's supposed to be.

No the explicit sync of eglstreams is the problem.

NVidia had another solution for a generic Unix device memory allocator but it went nowhere.

infected with the same problem

https://www.x.org/wiki/Events/XDC2016/Program/Unix_Device_Memory_Allocation.pdf

Note the complaint against DMABUF

No centralizeduserspaceallocation API

DMABUF being kernel allocated is why it works. Kernel allocated means the kernel knows the allocations if a program has to be force terminated the kernel apply clean up operations on all those allocations.

Basically in 2016 Nvidia still was not getting why eglstreams fails and Unix Device Memory is basically a double down on the defects. One of the core defects is the idea we can allocate share resources in user-space and not tell the kernel about them and expect everything to work right. Shared resources allocations is something like it or not is required to be the kernel job.

Please note I am not saying no explicit sync the hard reality is implicit sync item need to be used to create the item that you use for explicit sync so that the kernel need know about the explicit sync usage and can perform correct clean up in case of application termination.