XWayland Nukes The NVIDIA EGLStream Backend

[Khrundel]

What if you intend to use Vulkan?

Vulkan has nothing to do with EGL/GBM debate. You can run vkcube and glxgears simultaneously and both windows will display, despite using different window integration API. And also most modern composers use OpenGL for composing work while most games using vulkan for rendering and they interoperate correctly.

[Alexmitter]

EGLstreams was never a good match for Wayland. If Nvidia wanted to prove otherwise they would have need to show us that it actually brings benefits, not poop out half ass implementations for a bunch of major components and then never maintain them again.

[oleid]

And also most modern composers use OpenGL for composing work while most games using vulkan for rendering and they interoperate correctly.

Sway, for example, now has a Vulkan backend. Would this be possible with eglstreams?
It would seem using eglstreams limits you to an outdated API.

[blacknova]

Wasn't the main issue of GBM vs EGLStreams related to sync methods - implicit and explicit? With EGLStreams build around idea of explicit sync while GBM is designed with implicit sync in mind. And now whole Linux graphics stack is planning on transion to explicit sync anyway as implicit sync proves to be a performance bottleneck.

[Britoid]

Wayland progress could have been accelerated had NVIDIA just adopted GBM from the start.

Still would need to support Explicit sync on the display stack, which EGLStreams had native support for.

[dragon321]

I think many people don't realize that to this day, EGLStreams ARE the better option.

It's not. EGLStreams is not better option than GBM, at least not better option for Wayland needs. Sway developers pointed few flaws of EGLStreams, for example lack of ability to support direct scanout or "breaking" Wayland rendering model. Also compositors that supported both GBM and EGLStreams (like Mutter or KDE) basically always had some issues specific to EGLStreams and that was not because their EGLStreams implementation wasn't good enough because in KWin case it was implemented by NVIDIA developer. So how can you say that EGLStreams was better than GBM when even NVIDIA developers couldn't implement it in compositors to be as good as GBM?

EGLStreams wasn't better option for Wayland. It was better option only for NVIDIA. Mostly because they already supported it and could use it without any additional work. FOSS community didn't want it not only because they already had GBM but because they didn't want to have inferior solution when they already had better solution.

[r_a_trip]

I feel like I should point out that I'm an AMD user, and have been for the entirety of my PC existence (minus my very first laptop, which had an Intel iGPU but still FOSS driver). I dislike Nvidia as a whole, and maybe I didn't keep up on it but their initial pitch for EGLStreams had a lot of really good reasons for picking it that wasn't just "we don't want to do the work to implement GBM in our proprietary driver".

I wonder how many of the implementation issues came from the fact that most compositors were already written with GBM in mind, and the EGLStream code was essentially a shim rather than a ground-up implementation.

That is a nice what if, but if the world is already running with working GBM code in the wild, pitching EGLStreams is too little too late. It doesn't matter if EGLStreams is technically better than GBM. GBM was already the lay of the land and EGLStreams needs to be a whole lot better if everybody has to justify rewriting large parts of the stack. Nvidia just dragged their feet and was unwilling to accept that their proposal was too late and it didn't have broad support.

Nvidia being a straggler has made the whole Wayland transition a whole lot more painful. Unnecessarily so. The majority of the complaints about Wayland not working properly (glitches, black screens, etc.) are accompanied by the word Nvidia. Rarely do I read AMD or Intel.

[User42]

Nvidia ease of use on Linux along with CUDA is definitely another reason I won’t switch to another brand any time soon.

While I agree for cuda, and by extension most GPU-accelerated workloads, the ease of use does not make sense on Linux, unless that already referred to cuda. Compare whatever nvidia makes your distro make you do to get accelerated graphics to just doing nothing... Intel and AMD have nailed that (as well as most hardware vendors actually).

[mppix]

Nobody implementing EGLStreams ever actually tried to get it onto feature parity with GBM, or solve any of it's issues because everybody in the FOSS world was already dead-set on GBM. Every implementation was purely a workaround until NVidia got in line and implemented GBM, which they stated they would do long before any EGLStream implementations went live, and as such were half-assed. Nobody took the effort to try and fix any major issues because why would they? It was a temporary solution to a temporary problem so why would they devote developer resources?

Not sure why you'd like to revise history..

Nvidia themselves could not implement EGLStreams without major protocol revisions that that they could not deliver either.

Then they also suggested useing Vulkan, that people generally speaking liked, but that was not ready either.

Also, they did not announce adopting GBM until they implemented the open source driver.

Either way, projects like these always require a degree of collaboration and trust and Nvidia did not act in good faith for a long time.
They eventually had to give in and adopt what upstream has been doing.

1. I think you're not reading my comment in the context of "the entire history of wayland" and instead think I'm saying that wayland still has a vast number of issues.
2. See #1
3. I never said that. I said that the GBM vs EGLStreams debate had no real impact on the actual adoption rate of Wayland, because surface protocol was never a blocking issue. Even if it took people 2 years to rewrite the entire backend of Mutter and KWin to use EGLStreams, it STILL would not have affected the adoption rate or completion rate of Wayland protocols because:
4. yes, crazy amount of bureaucracy. Have you ever taken a look through the git issues for potential wayland protocol extensions? I'm not going to say it's any more or less than any other project, but OBJECTIVELY it is the number 1 factor in the time it's taking for Wayland to fix all of the issues required for major adoption.

1+2 sure

3 I probably dont undertand this statement. People (including Nvidia) tried to rewrite Gnome and KDE backends for EGLstreams and showed that it does not work without serious revisions to EGLstreams that never materialized.

4 i dont understand this either. You probably dont have much exposure to industry standards. They tend to be intentionally slow to ensure compatibility and buyin of all shareholders. The fact that updates are made means the standard is well and alive.
If you are looking for slow: look the time scales needed to update internet protocols ...
Also, examples of dead pojects that cannot be updated: VNC, X11, ...

[jeisom]

Calling BS on pretty much every part of this:
- "VAST amount of issues" .. like?; "missing protocols" .. like?

Fractional scaling(2022) and Copy/paste interoperability(2021?) are recent additions. In this day and age having neither was a major UX problem. I'd have to choose between pretending I'm blind or having text so small on a 32in screen I'd have to be about 45cm from the screen to read or I can read from 2M away which defeats the idea of I want more information on screen. C&P should be self explanatory.

On top of that I've seen plenty of AMD users complain about stability as well in the last year or so. It really has been just in the last 6 months that it has been getting to the point of being usable on anything other than gnome for most users AMD, Intel and Nvidia.