Ubuntu 22.04 LTS Changes Default For NVIDIA Driver Back To Using X.Org Rather Than Wayland

[IndioNuvemChuva]

The broken driver model is MESA and most open source drivers and in general wayland/dma-buf/gbm. They raised implicit sync model to everything in linux graphics stack, when entire world made everything go explicit sync model (including our loved Vulkan).

I also think that of note is that, when people talk about AMD's or Intel's drivers what they're really talking about is Mesa. And, really, Wayland implementations - both client and compositor - in general are heavily reliant on the Mesa code path (wl_drm) by virtue of how the protocol expects accelerated buffers to be handled. In fact, Wayland - the protocol - expects clients and compositors alike to be aware and accommodate for possibly multiple, often mutually exclusive, methods of handling hardware side buffers.

And from that quirk is really where most of the bugs in the NVIDIA Wayland Experience™ have stemmed. Most developers understandably have no interest in keeping multiple mutually exclusive code paths, and so they opted for wl_drm, which already had good traction, as they were there first. Problem is, these were all extensions, whose design was very much only intended to be used for and within Mesa itself. In effect, what happened is that most applications were given, in fact, the choice between foregoing accelerated buffers entirely or be vendor locked to Mesa.

So, up until very recently, it wasn't that NVIDIA wasn't willing to implement the perceived standard, it was more-so that they wouldn't re-implement a Mesa-only extension to the protocol. An implementation which would either require a hefty set of additions to Mesa that would let it support foreign implementations of its device buffer handling interface (GBM), or the creation of a competing implementation that would most likely lead to a repeat of the libGL fiasco that plagued Linux all throughout the 2000's with a fresh coat of paint on it. In the end, the former ended up happening, albeit it took a while. And, in fact, as soon as the last patch for it landed, NVIDIA launched their first implementation of GBM.

I think it's unbelievably childish what a lot of people in the Linux community are doing in pointing to NVIDIA demanding that they "fix their Wayland implementation", one that couldn't have even existed up until a couple of months ago; or demanding that they open source their driver, which, for most intents and purposes, with only the notable exception of poor compatibility with most Wayland implementations, works fine. While also sternly refusing to even consider the possibility that what they call "NVIDIA's sabotage of Wayland" might, in fact, be just a purely technical consequence of how the protocol itself was first designed and how it evolved over the years.

At the end of the day, what people these people are doing here is celebrating the fact that Wayland implementations are vendor locked to Mesa. I though we were over the olden days of GNU when being vendor locked was seen as a good thing, so long as it was our side doing it.

[wertigon]

The broken driver model is MESA and most open source drivers and in general wayland/dma-buf/gbm. They raised implicit sync model to everything in linux graphics stack, when entire world made everything go explicit sync model (including our loved Vulkan).

You are arguing like a person would say Linux is "broken" because the MACH has a better structure - that kind of thinking aged like fine milk. But to clarify, "broken" driver model, in this case, is that it is not compatible with the Linux model. Maybe I should have said "Incompatible" model instead, but oh well.

Still;

Kopper+Zink works for freakin' *everything* (once bugs have been ironed out). And everything needs to support Vulkan in either case. So why not simply *only* support Vulkan, and Zink the games on OpenGL, and call it a day? From where I am standing this is now the logical choice to support desktop Linux. Who cares about whether Wayland renders at 10 000 FPS or 100 000 FPS? Does it matter if a Bugatti can go 300 mph and the Ferrari only 290 mph, when all your driving will happen below 100 mph regardless?

[wertigon]

I think it's unbelievably childish what a lot of people in the Linux community are doing in pointing to NVIDIA demanding that they "fix their Wayland implementation", one that couldn't have even existed up until a couple of months ago; or demanding that they open source their driver, which, for most intents and purposes, with only the notable exception of poor compatibility with most Wayland implementations, works fine. While also sternly refusing to even consider the possibility that what they call "NVIDIA's sabotage of Wayland" might, in fact, be just a purely technical consequence of how the protocol itself was first designed and how it evolved over the years.

I think it's unbelievably entitled to ask the entire community to bend over backwards because the community chose a solution they perceived as better. Whether or not this is actually technically better or not, I leave unsaid.

We as a community has been asking Nvidia for over pretty much a freakin' decade to create a Wayland implementation based on GBM; it's great they finally got their thumb outta their arse to make it, but it is very late to the party here. This GBM implementation could have existed years ago; it didn't. Only when AMD finally got their shit together and started delivering Open Source drivers to their hardware that were as good as, or even better than, Nvidia hardware on Linux, did Nvidia even start paying lip service.

Nvidia is a corporation; fine. I get that. But Nvidia as a company has chosen short sighted greed over long term strategy way too often, and now it is starting to show.

We need the Wayland driver today, because there is a viable alternative to use today. If Nvidia will not let us have our fancy toys we will choose a corporation that will let us have our fancy toys. It is that simple. And no it is not childish to ask of Nvidia to support the vendor-neutral (AMD + Intel + Qualcomm + Others) Mesa stack over their own incompatible implementation.

Nvidia saying it is unfair to ask of them to properly support Wayland is like GM waking up now and saying it is unfair to ask of them to build EVs. Well, sorry, the market is requesting EVs, and if you guys don't have any, then the customers will choose another brand, like Tesla, Nio, XPeng or BYD. This has been on the horizon for over a decade.

[Developer12]

You do realize there are numerous Wayland issues (or issues with Wayland ecosystem such as XWayland) that have nothing to do with NVidia?

And yet it's been deemed good enough to ship everywhere else. Only Nvidia has come hat-in-hand on the very last day asking to be excused.

[IndioNuvemChuva]

We as a community has been asking Nvidia for over pretty much a freakin' decade to create a Wayland implementation based on GBM; it's great they finally got their thumb outta their arse to make it, but it is very late to the party here. This GBM implementation could have existed years ago; it didn't.

And how exactly do you suggest they could've done it right away while also avoiding both of the issues I've mentioned?
(those being the hefty set of additions to mesa itself or the split libraries problem that plagued opengl before)

[piotrj3]

You are arguing like a person would say Linux is "broken" because the MACH has a better structure - that kind of thinking aged like fine milk. But to clarify, "broken" driver model, in this case, is that it is not compatible with the Linux model. Maybe I should have said "Incompatible" model instead, but oh well.

Still;

Kopper+Zink works for freakin' *everything* (once bugs have been ironed out). And everything needs to support Vulkan in either case. So why not simply *only* support Vulkan, and Zink the games on OpenGL, and call it a day? From where I am standing this is now the logical choice to support desktop Linux. Who cares about whether Wayland renders at 10 000 FPS or 100 000 FPS? Does it matter if a Bugatti can go 300 mph and the Ferrari only 290 mph, when all your driving will happen below 100 mph regardless?

You don't understand the issue. The issue is exactly that open souce stack is broken with Vulkan, and because of that also Open source driver stack is mostly late to implement newest and shiniest vulkan extensions. Everytime Vulkan interacts with any window system you have to implicit sync. (and because of tons of issues) Vulkan on open source stack has problems.

Read next post about that more in detail.
-

[piotrj3]

I also think that of note is that, when people talk about AMD's or Intel's drivers what they're really talking about is Mesa. And, really, Wayland implementations - both client and compositor - in general are heavily reliant on the Mesa code path (wl_drm) by virtue of how the protocol expects accelerated buffers to be handled. In fact, Wayland - the protocol - expects clients and compositors alike to be aware and accommodate for possibly multiple, often mutually exclusive, methods of handling hardware side buffers.

And from that quirk is really where most of the bugs in the NVIDIA Wayland Experience™ have stemmed. Most developers understandably have no interest in keeping multiple mutually exclusive code paths, and so they opted for wl_drm, which already had good traction, as they were there first. Problem is, these were all extensions, whose design was very much only intended to be used for and within Mesa itself. In effect, what happened is that most applications were given, in fact, the choice between foregoing accelerated buffers entirely or be vendor locked to Mesa.

So, up until very recently, it wasn't that NVIDIA wasn't willing to implement the perceived standard, it was more-so that they wouldn't re-implement a Mesa-only extension to the protocol. An implementation which would either require a hefty set of additions to Mesa that would let it support foreign implementations of its device buffer handling interface (GBM), or the creation of a competing implementation that would most likely lead to a repeat of the libGL fiasco that plagued Linux all throughout the 2000's with a fresh coat of paint on it. In the end, the former ended up happening, albeit it took a while. And, in fact, as soon as the last patch for it landed, NVIDIA launched their first implementation of GBM.

I think it's unbelievably childish what a lot of people in the Linux community are doing in pointing to NVIDIA demanding that they "fix their Wayland implementation", one that couldn't have even existed up until a couple of months ago; or demanding that they open source their driver, which, for most intents and purposes, with only the notable exception of poor compatibility with most Wayland implementations, works fine. While also sternly refusing to even consider the possibility that what they call "NVIDIA's sabotage of Wayland" might, in fact, be just a purely technical consequence of how the protocol itself was first designed and how it evolved over the years.

At the end of the day, what people these people are doing here is celebrating the fact that Wayland implementations are vendor locked to Mesa. I though we were over the olden days of GNU when being vendor locked was seen as a good thing, so long as it was our side doing it.

Problem is far bigger, even if Nvidia could implement everything, Wayland is quite "dead" from start unless big changes will be comming.

I will quote here Jason Ekstrand, former Intel linux graphics and now Collabora:

Ok, this is where it starts getting depressing. I made the claim above that Wayland has an explicit synchronization protocol that's of questionable usefulness. I would claim that basically any bit of plumbing we do through window systems is currently of questionable usefulness. Why?

From my perspective, as a Vulkan driver developer, I have to deal with the fact that Vulkan is an explicit sync API but Wayland and X11 aren't. Unfortunately, the Wayland extension solves zero problems for me because I can't really use it unless it's implemented in all of the compositors. Until every Wayland compositor I care about my users being able to use (which is basically all of them) supports the extension, I have to continue carry around my pile of hacks to keep implicit sync and Vulkan working nicely together.

From the perspective of a Wayland compositor (I used to play in this space), they'd love to implement the new explicit sync extension but can't. Sure, they could wire up the extension, but the moment they go to flip a client buffer to the screen directly, they discover that KMS doesn't support any explicit sync APIs. So, yes, they can technically implement the extension assuming the EGL stack they're running on has the sync_file extensions but any client buffers which come in using the explicit sync Wayland extension have to be composited and can't be scanned out directly. As a 3D driver developer, I absolutely don't want compositors doing that because my users will complain about performance issues due to the extra blit.

Ok, so let's say we get KMS wired up with implicit sync. That solves all our problems, right? It does, right up until someone decides that they wan to screen capture their Wayland session via some hardware media encoder that doesn't support explicit sync. Now we have to plumb it all the way through the media stack, gstreamer, etc. Great, so let's do that! Oh, but gstreamer won't want to plumb it through until they're guaranteed that they can use explicit sync when displaying on X11 or Wayland. Are you seeing the problem?

To make matters worse, since most things are doing implicit synchronization today, it's really easy to get your explicit synchronization wrong and never notice. If you forget to pass a sync_file into one place (say you never notice KMS doesn't support them), it will probably work anyway thanks to all the implicit sync that's going on elsewhere. So, clearly, we all need to go write piles of code that we can't actually properly test until everyone else has written their piece and then we use explicit sync if and only if all components support it. Really? We're going to do multiple years of development and then just hope it works when we finally flip the switch? That doesn't sound like a good plan to me.

AMD developer 1 year ago also said about that MESA should be remade in explicit sync way. Nvidia developer in that SDL issues post, said also many issues like sharing screen on Wayland is comming from that implicit sync and they literally cannot implement them without some hacky solutions like artificial fences.

How the fuck we fucked up so bad on linux graphics stack, that all 3 major GPU companies want to go explicit sync, while everything low-level with graphics stack on linux is implicit sync. There is also a reason why every major GPU company can release newest and shiniest vulkan extensions instantly the moment it is announced as experimental. Meanwhile in open source we wait and wait. Currently actually issue isn't so bad, but the more we want to move to more threads and so on, the bigger implicit sync cost (and we move in that direction). The more Vulkan will grow the implicit sync cost will be bigger.

[caligula]

I'm not sure that bugs for Intel or AMD that prevents people from playing World of Warcraft on Proton is relevant to this discussion. So that's kind of off topic.

For Wayland and Intel and AMD, this is not an issue.(Or rather, it's not an issue that it's broken causing Canonical to reverse course)

That might be true, but my point was, there are quite likely Wayland bugs that also affect other GPUs. It's up to the distribution to decide which ones are critical enough to block new releases. Some other distros happily offer Wayland desktop.

[wertigon]

You don't understand the issue. The issue is exactly that open souce stack is broken with Vulkan, and because of that also Open source driver stack is mostly late to implement newest and shiniest vulkan extensions. Everytime Vulkan interacts with any window system you have to implicit sync. (and because of tons of issues) Vulkan on open source stack has problems.

Read next post about that more in detail.
-

Ok... And this is not solved by Kopper why? https://gitlab.freedesktop.org/mesa/...requests/14541

[IndioNuvemChuva]

Ok... And this is not solved by Kopper why? https://gitlab.freedesktop.org/mesa/...requests/14541

And how is any of it solved by Kopper, exactly?