NVIDIA Confirms Sway Wayland Compositor Works Fine With Their New GBM Driver Support

[Myownfriend]

That's all very nice, but does it perpetuate the glorious NVIDIA tradition of...

• Breaking suspend/resume?
• Draining the battery?
• Breaking on each kernel update?

I can't speak on the first two but I used to experience the last one until I started running Dracut if it didn't work after an update. That seems to work for me as I've pretty much always been on the newest kernel version since I switched to Fedora in April.

[polarathene]

So, lets revisit that.

First, ignore invitations on creating a standard, do not show up.
Second, claim the standard is bad and your (actually not fit for the task) thing is better.
Third, claiming to want to create a better standard to make everyone happy while not asking anyone on their opinion.
Fourth, giving that up and use the original standard that was the best solution from the beginning.

1. EGLStreams AFAIK was already a standard? (since 2011?), might not be in use with desktop environments, but I believe it is commercially in display products? (kiosks, automotive, etc)
2. Pretty sure they had valid reasons about why GBM was bad, I remember slides or something about it years ago. IIRC there was acknowledgement of those issues, but by this time (much later than 2011) GBM had already become established in the ecosystem well enough that there wasn't interest in changing to an alternative unless it was much more compelling and ready, there was especially little interest in supporting both options.
3. They did ask for opinions, they just didn't get as much engagement from the community IIRC?
4. They gave up because their alternative wasn't going anywhere or getting any traction last I heard. They were too late and not regarded too well in the community in general AFAIK. It's not that GBM is the best solution, but it's the dominant broadly adopted / accepted one. For the same reason Windows isn't necessarily the best OS but most prefer it, it meets the requirements for most with less friction, good enough is not best though.

Not advocating for nvidia here, but at least they're doing stuff like this, why bash them for that?

I recently found out that nvidia's embedded products including the latest Xavier NX from last year are provided with their L4T distro based off Ubuntu 18.04 , the latest release is August 2021, but still no upgrade to a newer distro, the kernel is stuck on 4.9 still... They have good hardware in that space, it's just sad that they fumble so much on open-source that they can't even support a modern kernel or packages for their platforms.

[polarathene]

It will still be utterly incomplete if they don't implement
-Vulkan mailbox present mode (everything seems to be forced into fifo mode...)
-is VRR property even implemented for Nvidia DRM modesetting driver?
-is any kind of GPU gamma ramps support implemented for Nvidia DRM modesetting driver?
-there don't seem to be any overclock options on Nvidia Wayland (xorg rootless also doesn't work, WTF, and even then there is no real undervolting possible)
-Nvidia DRM modesetting driver doesn't seem to offer any kind of custom EDID interface
-Does manual fan control work on Wayland?

I will never use it if stays that incomplete...

I don't think they care if you'll never use it.

They're more than likely motivated financially to add this GBM support for enterprise users where a lot of that isn't going to be deal breakers.

[arQon]

By the time Wayland is ready and Xorg is finally dead and really not maintained to any capacity, NVIDIA drivers might as well support all these features.

By the time those things happen, we'll probably be living on Mars too. :P

[shmerl]

Good for Nvidia, but my take on it - too little, too late. They are decades late and it's basically DOA.

With Intel joining high end GPU market especially, Nvidia will become irrelevant on Linux desktop due to lack of upstreamed driver. It will be just AMD and Intel.

[Myownfriend]

1. EGLStreams AFAIK was already a standard? (since 2011?), might not be in use with desktop environments, but I believe it is commercially in display products? (kiosks, automotive, etc)

My understanding is that it's a standard only in that it was submitted to the Khronos group to become a standard and was excepted as one was but the only people to ever use EGLStreams was Nvidia.

2. Pretty sure they had valid reasons about why GBM was bad, I remember slides or something about it years ago. IIRC there was acknowledgement of those issues, but by this time (much later than 2011) GBM had already become established in the ecosystem well enough that there wasn't interest in changing to an alternative unless it was much more compelling and ready, there was especially little interest in supporting both options...

...It's not that GBM is the best solution, but it's the dominant broadly adopted / accepted one. For the same reason Windows isn't necessarily the best OS but most prefer it, it meets the requirements for most with less friction, good enough is not best though.

The best thing I've heard about EGLStreams is that it had some advantages that ultimately don't matter for what it would be used for. Other than that, I had heard that it was just kind of inferior to GBM and Nvidia was pushing it only because it better matched what they were already doing in their driver.

3. They did ask for opinions, they just didn't get as much engagement from the community IIRC?

Heard that. I forgot what they reaction was though.

4. They gave up because their alternative wasn't going anywhere or getting any traction last I heard. They were too late and not regarded too well in the community in general AFAIK.

The only reason that Gnome and KDE have EGLStreams backends is because Nvidia wrote and maintained them. I'm currently running a Gnome Wayland session on an Nvidia card so I'm using EGLStream now and the experience isn't great. GTK4 applications launch as transparent windows with mouse trails unless I use the Cairo backend, Electron 12 or new applications will work in Wayland but will occasionally show mouse trails, OBS doesn't launch at all in Wayland because I guess Pipewire needs GBM, and because EGLStreams was supposed to be an alternative to DMAbuf as well (which is a kernel interface), I only recently got hardware accelerated XWayland applications. I couldn't even get the hardware accelerated Webrender backend for Firefox without DMAbuf and that was in Wayland and X11.

Not advocating for nvidia here, but at least they're doing stuff like this, why bash them for that?

I agree. I have my issues with them even outside of Linux but people have wanted Nvidia to support DMAbuf and GBM for a long time. Now they're finally do it so they should be happy.

I recently found out that nvidia's embedded products including the latest Xavier NX from last year are provided with their L4T distro based off Ubuntu 18.04 , the latest release is August 2021, but still no upgrade to a newer distro, the kernel is stuck on 4.9 still... They have good hardware in that space, it's just sad that they fumble so much on open-source that they can't even support a modern kernel or packages for their platforms.

And their Tegra drivers have supported GBM for awhile now. It's weird on disconnected the Tegra stuff is with the desktop. I'd really love to see them get a little less paranoid about open source development. It's like they don't think they can keep their dominance unless their software and stuff proprietary, but they clearly have good cards, they don't have to rely on proprietary technologies to stay successful.

[oiaohm]

1. EGLStreams AFAIK was already a standard? (since 2011?), might not be in use with desktop environments, but I believe it is commercially in display products? (kiosks, automotive, etc)

That is one huge fib. Nvidia department who made arm chips for the kiosks, automotive and so on(Tegra) had been using GBM years before EGLStreams and never changed to using EGLStreams. Nvidia department that makes DGPU never managed to convince anyone outside their department to use EGLStreams let alone to convince any other vendor to come on board to the point of putting products out.

ST-Ericsson were going release chips 2012 using EGLstreams but these were pushed then they were dissolved in 2013 before they could. polarathene the reality here two parties pushed EGLStreams into the khronos standard. That Nvidia DGPU department and ST-Ericsson yes 2 August 2013 ST-Ericsson ceases to exist before making any chips that have EGLStreams drivers leaving only a solo supporter as the Nvidia DGPU department. Yes Nvidia Tegra that makes Nvidia arm chips had already chosen the GBM route..

2. Pretty sure they had valid reasons about why GBM was bad,

No this is not really the case. Because why did the Nvidia Tegra developers go GBM if there was major problems in the design.(there are security reasons to go the GBM route as well)

There was a problem for Nvidia doing closed source drivers(the Nvidia DGPU) as they would have to get a patch into mesa so they could hook their closed source driver in. That may or may not have been easy.(they did not try until it was not going anywere).

Next was they did not like the GBM model where every process has its own memory pool. But the per process memory pool is important so compositor can restart. The key feature that Nvidia did not like about GBM turns out to be key. KDE developers are wanting to be able to on the fly restart the wayland compositor they will be needing GBM feature of memory per process not memory in a global pool as EGLStreams has.

Yes the Nvidia developer putting support for EGLStreams into KDE end up in a rock and hard place between the KDE lead developer and what he could do with EGLStreams. Yes the KDE lead developer did a demo restarting the wayland compositor on intel and amd and arm and qualcom and broadcom GPUs and it works then the Nvidia developer was completely and totally screwed when the KDE lead developer asked the Nvidia lead developer to show how because this would be a future KDE feature. Every route the Nvidia developer tried with KDE lead back the the memory issue where restarting the compositor lead applications segfaulting that required him to go to the Nvidia driver developer team and ask if they could fix EGLStreams to make this work. This leads to the 470.xx Nvidia driver work with GBM support and DMA BUF support as the Nvidia DGPU drivers developers find they are totally screws EGLStreams simply is not going to work.

Issue here Nvidia thought they had a valid reason for EGLStreams. EGLStreams is fine if you are not wanting to restart the wayland compositor or use exactly the same drivers for Xwayland and bare metal X11. A lot of embedded systems need to be able to restart as many individual parts as possible this is why automotive and aircraft have avoided EGLStreams absolutely.

This has been 7 years of hell caused by a single department at Nvidia. This has also delayed the wayland protocol work on how to handle compositor restarting and on the fly replacement because it was need to know how the hell were you meant to-do that with EGLStreams the answer is you don't because no one is going to support in future and it cannot be done with the EGLStreams design.

[polarathene]

the reality here two parties pushed EGLStreams into the khronos standard. That Nvidia DGPU department and ST-Ericsson

Ah ok... I didn't look into it too deeply myself, just that it was a Khronos standard. Having it made one by just those two companies makes sense I guess... apologies.

why did the Nvidia Tegra developers go GBM if there was major problems in the design.

Were they pushing Wayland with those devices? From what I could briefly gather, they default to X11 (at least with L4T on their embedded range), and given the Ubuntu 18.04 base and 4.9 kernel, I wouldn't expect much from Wayland, at least with the DEs.

They do support EGLStreams in their documentation though. But given the rather outdated software support elsewhere in L4T, I assume any preference for GBM may related to that or other factors. Honestly I haven't looked into either that much myself.

---

I don't recall the issues nvidia addressed years ago about GBM having and EGLStreams solving, but it's good to know that it's own flaws were later identified and adopting GBM was the more appropriate choice for them to pursue in the end

[smitty3268]

I don't recall the issues nvidia addressed years ago about GBM having and EGLStreams solving, but it's good to know that it's own flaws were later identified and adopting GBM was the more appropriate choice for them to pursue in the end

GBM certainly wasn't perfect when it came out, but over time extra features like modifiers have been added to improve it. My understanding is that EGLStreams has some fundamental issues in the design that make it a poor match for compositors that are tougher to solve.

[oiaohm]

Were they pushing Wayland with those devices? From what I could briefly gather, they default to X11 (at least with L4T on their embedded range), and given the Ubuntu 18.04 base and 4.9 kernel, I wouldn't expect much from Wayland, at least with the DEs.

https://www.phoronix.com/scan.php?pa...egra-Mesa-2018
The reality was the customers buying Tegra boards wanted a open source graphic stack that support GBM that was Wayland and Linux framebuffer compatible(yes this need gbm support as well) everything that L4T is not. Yes lot of things like cars you want to fully audit the stack for flaws that is hard to do with binary blob drivers.

Nvidia has had a level of stubborn here yes they have attempt to ignore their own customers. This GBM support that Nvidia has just done support Wayland but does not support running legacy embedded applications that use Linux Framebuffer out. So Nvidia are still going to have customers demanding that keep on supporting GBM and DRM in kernel. And these are customers who buy big enough volumes that Nvidia cannot refuse.

GBM certainly wasn't perfect when it came out, but over time extra features like modifiers have been added to improve it. My understanding is that EGLStreams has some fundamental issues in the design that make it a poor match for compositors that are tougher to solve.

No its not just tougher issues with EGLStreams to solve in fact close to impossible there is a core design problem. Its the cases where you need your compositor to be able to crash and restart without screwing over applications. EGLSTreams are core part of design has a shared buffer system between all applications. Yes this is also a security nightmare why GEM handles and other things were given up on as well.

This is a case that something Nvidia thought was a design fault of libgbm/dmabuf combination that they could design without turns out to be a critical feature. Yes Nvidia successfully have thrown the baby out with the bath water here and are finally waking up to the case that is exactly what they did and are trying to fix the broken baby. Still not doing the best job.