Mesa 24.1 Merges Vulkan Support For Wayland Explicit Sync

[oiaohm]

It was Linux/graphics driver devs that was blocking/stonewalling explicit sync for a decade, not NVidia, why do you think that NVidia created EGLStreams?

Here is a good questions I asked self that leads to a interesting answers.

What GPU maker made the first Explicit sync only GPU? The answer Intel and it the early Intel igpu that were a complete disaster to write drivers for.

What was the direct advantage of intel igpu doing explicit sync? Reduced hardware silicon area.

There is a old saying failure to learn from history you are doomed to repeat it.

This intel igpu that was explicit sync only is in fact from before DRI2.

There is a very simple implicit sync thing need.

Process 1 shared memory with process 2. This need to increase implicit synced counter. So when either process 1 or 2 free that memory it reduces by one and only if the counter is zero so that nobody is using is the memory really freed.

Welcome to a fun reality., You don't do automatic memory garbage collection in software without implicit sync.

Go back and read over the eglstreams presentations you find Nvidia developers not describing how eglstreams is going to garbage collect GPU vram or GPU memory mapped into CPU memory. Turns they don't mention this. Then Nvidia implementation of eglstreams and API design does not allow for this.

Intel route from explicit sync igpu to gem to GBM/DMABUF. Turns out to be about dealing with the memory management problem. What makes this even worse is that DMABUF work was a joint project between Nvidia and Intel.

Nvidia did not want to open source their memory management code on their GPUs. This causes a big problem. Because the OS kernel memory management of the CPU and the GPU memory management need to be kept in sync so that counters on memory remain right. Like kernel terminates a process the vram allocated by the application need to have it counter for number of times in use need to be reduced.

This is what makes the eglstreams mess so god darn stupid. Both Intel and Nvidia jointly developed the solution to GPU memory garbage collection in DMABUF then Nvidia decided not to use it in eglstreams. Nvidia also argues hard with the Linux kernel developers over DMABUF because the Linux kernel developers keep on wanting to keep core structures to the Linux kernel GPLv2. Yes core memory management is OS core parts.

mdedetrich like it or not the argument that Nvidia was pushing for explicit sync is a smoke screen. What Nvidia was wanting was to keep their driver closed source. Going explicit sync where everything is managed by the applications themselves equals not having to work with the kernel. Problem going pure explicit sync like this causes total memory management failures Intel know this from the time of DRI1 and Nvidia failed to listen to Intel warnings.

Yes this Nvidia mistake has wasted a huge amount of developer time at gnome that went to into attempting to make the eglstreams backend work that could never be made work due to fundamental design fault that Nvidia had done in Eglstraems what was exactly copy of what Intel did in their early igpus.

By the way Intel was not the only other GPU vendor in history to make this goof up AMD and ARM did the same at other times this is why when everyone that works on mesa is like we will not implement eglstreams because they could see issues should have had alarm bells ringing at Nvidia thinking how many other things that Nvidia had created that Mesa developers just copied without argument.

Failure to learn from history can be very costly. Major stall to wayland development from this Nvidia mistake. Everyone does need to learn from this mistake. Big thing you GPU stack cannot be 100 percent explicit sync. You need implicit sync memory garbage collection yes DX12 has implicit sync memory garbage collection. This means somehow you need to mesh implicit sync with explicit sync effectively.

You want the performance gains explicit sync offers without screwing up the memory management this is a lot more complex problem. This explains part of why the Linux kernel developers were like you want to completely drop implicit sync what kind of garbage are you talking about. Remember the Linux kernel has a formal memory model of how it memory works and explicit sync memory management absolutely does not fit. In have you cannot create a formal memory model of a explicit sync memory model that produces the result saying that this design is possible safe. Yes memory management design says you cannot to explicit sync memory management and have it work in a multi process operating system.

Reality here is the eglstreams design is fundamentally broken and this come very clear when you attempt to do up a formal memory model of it.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html

Doing formal memory models does take a lot of time. Yes this is something the eglstreams designer skipped if they had not they would have see that lot of there so called eglstreams sales points were in fact 100 percent fatality causing defects.

Yes we do need to make sure that if anyone else has idea like eglstreams that is highly defective they stop quickly and see their major mistake so not to create a new mess.

[mdedetrich]

EGLStreams comes in fact after the first explicit sync on Linux.

Yes and thats because at the time linux/graphics stack devs had zero interest in exploring explicit sync. Even up until now there was pushback from gnome/redhat employees against explicit sync (even if it was being done the "proper linux way") because they thought it was pointless/not needed even though it was obvious this was becoming less and less true as non NVidia related things such as Vulkan was having issues with implicit sync and everyone who was an actual stakeholder (i.e. Intel/NVidia/AMD) was pushing for it.

NVidia was completely correct here, Linux was not in a state of accepting explicit sync a decade ago when EGLStreams was created and we know this is 100% true because even now they weren't in such a state completely, it required a lot of aggressive pushing to get it through.

[oiaohm]

Yes and thats because at the time linux/graphics stack devs had zero interest in exploring explicit sync. Even up until now there was pushback from gnome/redhat employees against explicit sync (even if it was being done the "proper linux way") because they thought it was pointless/not needed even though it was obvious this was becoming less and less true as non NVidia related things such as Vulkan was having issues with implicit sync and everyone who was an actual stakeholder (i.e. Intel/NVidia/AMD) was pushing for it.

NVidia was completely correct here, Linux was not in a state of accepting explicit sync a decade ago when EGLStreams was created and we know this is 100% true because even now they weren't in such a state completely, it required a lot of aggressive pushing to get it through.

Except this explicit sync idea is not in the sales pitch for eglstraems I provided you with the links to the eglstreams sales pitch.

https://www.phoronix.com/news/MTgxMDE

Nvidia goal was to replace GBM with their own thing that is slide number 2.


mdedetrich find me a Nvidia document that says the objective of eglstraems is to support explicit sync correctly.

Something you have not allowed. Nvidia has not signed off on DMABUF based explicit sync. Nvidia and everyone else had signed off on EGL/Opengl Implicit sync.

mdedetrich there is a chicken and egg here you are missing. Why should gnome developers go to the effort of coding explicit sync support it this does not work on all GPUs??? See problem.

Nvidia not agree to DMABUF sync file solution used by Android for explicit sync was blocking Gnome/KDE/... and others from implementing explicit sync.

Vulkan having issues with implicit sync this gets interesting.

https://www.khronos.org/blog/understanding-vulkan-synchronization

implicit memory guarantee

mdedetrich there is a big elephant in the room. You cannot implement Vulkan correctly on top of Eglstraems because the Vulkan standard mandates implicit sync in places for implicit memory guarantees.

Yes everyone having issues with Implicit sync. Because like it or not to do multi process safe memory management with valid memory garbage collection you need implicit sync in places.

Explicit sync is a optional feature to get high performance.
Implicit sync is a mandatory feature so you don't have data leaks and segfaults. Yes as in your applications run stability. EGLSTREAMS developer failed to see that Implicit sync is a mandatory feature.

[mdedetrich]

Except this explicit sync idea is not in the sales pitch for eglstraems I provided you with the links to the eglstreams sales pitch.

Oh it most definitely is, NVidia was just hiding it on their presentation because they knew it wasn't a selling point the community would accept.

[oiaohm]

Oh it most definitely is, NVidia was just hiding it on their presentation because they knew it wasn't a selling point the community would accept.

Go and look up when Nvidia added explicit sync to opengl. I have a horrible problem it predates the existence of EGLSTREAMS.

The reason why Nvidia could not use explicit sync as a sales feature for EGLSTREAMs is a simple fact it already exists.

Eglstreams goes for a pure explicit sync with no implicit sync at all and this does not work.

Remember Android explicit sync support using sync files predates Eglstreams. DMABUF version of explicit sync with sync files predates Eglstreams.

This is the problem your arguement does not hold up on the timeline of events. Eglstreams come after explicit sync has been in existence in EGL for a few years without Eglstreams extentions.

[mdedetrich]

Go and look up when Nvidia added explicit sync to opengl. I have a horrible problem it predates the existence of EGLSTREAMS.

The reason why Nvidia could not use explicit sync as a sales feature for EGLSTREAMs is a simple fact it already exists.

Eglstreams goes for a pure explicit sync with no implicit sync at all and this does not work.

You do realize you just debunked your own argument? Earlier you said that EGLStreams had nothing to do with explicit sync and now you are saying that EGLStreams is purely explicit sync.

No one is debating that EGLStreams design wouldn't have been accepted into Linux/graphics stack, what is being said is that NVidia has been saying consistently for a long time that Linux/graphics stack needs explicit sync in one form or another and that historically Linux/graphics stack has been stonewalling that for various reasons (ranging from NVidia is "bad" and hence anything they say is bad i.e. shooting the messenger to explicit sync doesn't map nicely to the Linux/unix model where everything is a file or a process, streaming bytes into files only maps nicely with implicit sync).

Also the fact that all of your replies are always points back to everything being bad because NVidia suggested it is the biggest indicator of ad hominem I have seen in a while. Your so zealous/irrational on your hate of NVidia that you can't for a few seconds admit that they did something right, maybe you should look into that.

[MrCooper]

So is this the fix (or at least a big part of it) to the long-standing known problem within GBM implicit sync?

What problem would that be?

BTW, the core Wayland protocol using implicit sync isn't directly related to GBM.

I'm still not sure if I'd do it, but this opens up the possibility of switching to Linux on my main gaming rig.

Since this isn't about the nvidia driver, it's unlikely to make any difference for your Linux gaming experience.

And if done correctly in the client, this should allow for slightly better performance.

I guess this myth will never die. One shouldn't give others false hope like this though.

Except also Valve has a need for it, as Windows games can profit: https://lore.kernel.org/all/20220813...enhuizen.nl/T/

*Sigh*

Repeat after me: "Explicit sync isn't a single thing, it's many different things at different levels"

The patch series you referenced is about driver-internal synchronization. It can work the same and give the same benefit with implicit sync in the display protocols. It's not directly related to this article.

[oiaohm]

You do realize you just debunked your own argument? Earlier you said that EGLStreams had nothing to do with explicit sync and now you are saying that EGLStreams is purely explicit sync.

No I have not.
Question you have not asked you self what was the difference between the explicit sync that existed before Eglstreams and Eglstreams pure version.

No one is debating that EGLStreams design wouldn't have been accepted into Linux/graphics stack, what is being said is that NVidia has been saying consistently for a long time that Linux/graphics stack needs explicit sync in one form or another and that historically Linux/graphics stack has been stonewalling that for various reasons (ranging from NVidia is "bad" and hence anything they say is bad i.e. shooting the messenger to explicit sync doesn't map nicely to the Linux/unix model where everything is a file or a process, streaming bytes into files only maps nicely with implicit sync).

What you wrote here is not true. Nvidia was not being 100 percent truthful. Android and DMABUF had explicit sync before Eglstreams. This form of explicit sync that Nvidia would not agree to is hybrid. This hybrid is the same as DX12 and Vulkan is where you have explicit sync gpu calculation processing but implicit sync for GPU/CPU memory management.

What is the true elephant room for Nvidia if they have to implement true Hybrid explicit/implicit sync with full OS integration on the Linux kernel. The elephant is that Nvidia todo this is forced to open source there driver level GPU memory management code so that the "implicit memory guarantee" across CPU and GPU memory can in fact function.

The reality here is Nvidia wanted explicit sync as long as it did not require them to open source their driver code. Eglstreams is attempt to avoid having to open source their driver code for Linux kernel support.

Your stone walling argument is not true. The AMD, Intel and ARM developers come up with a design to support explicit sync on Linux of course these 3 did not care about having to open source their driver code to achieve the ends. The most important thing to AMD, Intel and ARM is that the result product was stable.

To be correct explicit sync maps perfectly fine into everything as a file as long as you have kernel support. Do note the sync file for allowing explicit sync of DMABUF comes from the Android that a mix of ARM Intel and AMD work.

Explicit sync turns out to fix perfectly fine in the Linux/Unix model where everything is a file or a process as long as you are willing to use files. Using files means you driver has to integrate into core kernel code so causing Nvidia problem here.

Eglstreams is nothing todo with getting Explicit sync because the Linux world before Eglstreams already had explicit sync. Its about Nvidia attempting to get explicit sync without integrating into the OS kernel. Without integrating into the os kernel you end up in segfault and data leak hell. Yes integrating into the OS kernel equals Nvidia having to release at least some of their driver source code.