XWayland 21.1.2 Released With NVIDIA Hardware Acceleration Support

[MartinN]

Can someone explain to me what this GBM vs EGLstreams kerfuffle is about?

NVidia deceived themselves, based off their GPU success that everyone and their grandma will eventually want to play AAA PC games on their latest GPU, including billions of office workers even, on their lunch breaks. When that never happened and likely never will happen, they realized their gravity pull wasn't as strong as they thought it is, meaning, Linux and its ecosystem has an order of magnitude wider appeal to the people of planet Earth, who do work on Linux, with Linux or through Linux, some without even knowing what Linux is, like billions of Android users who wouldn't know what Linux is even if it hit them on their ass....

As someone else said, they overestimated their importance - and this falls squarely on the CEO and the company's echo chambered leadership. Intel, and AMD in particular with Lisa Su at the helm, followed a different paradigm, popularized by Ballmer's immortal meme - 'developers, developers, developers, developers'... and followed the pulse of the Linux developers - GBM instead of EGLStreams. In this instance, it paid off dearly for both Intel and AMD, whereas NVidia remains a niche player relative to these 2 in the global GPU market. NVidia worshipped at the wrong altar, are hopefully hip to this and will correct this, 'real soon now'....

Similar thing happened with Canonical's (and Shuttleworth's) exaggerated sense of self importance - their success with Ubuntu, blinded them to the pulse of the Linux dev community, and instead of getting on board with Wayland, they reinvented it as "Mir"... Today, Ubuntu ships with Wayland by default and Mir is, resting in Mir, pun intended.

Success is a powerful (self) opiate. If one does not possess the (self) awareness that all success is fleeting, then they are bound to eventually lose touch with reality as it happens, on the ground, in the trenches, by those who are actually creating it ('developers developers developers').

A vision disconnected from current reality is also known as a pipe dream. Sometimes we hit the nail on the head, other times we miss. Not blaming anyone, just giving you a 20/20 on what's already happened.

[oiaohm]

I am not saying that EGLStreams was better than GBM in every area, but saying it was outright worse is just your A-Grade Phoronix NVidia hate FUD

https://bugs.kde.org/show_bug.cgi?id=428089

Erik Kurzinger here is the Nvidia developer. No its not Phoronix Nvidia hate fud. The reality here is Nvidia developer working on KDE found case after case where EGLStreams fell apart. To fix bug 428089 a transition away from EGLStreams is stated.

The problem of 428089 is a design fault in EGLStreams there is no way to fix it without altering the behaviour of EGLStreams that could possible break applications design for EGLStreams as they might be expecting the behaviour.

There is a very important difference between GBM and EGLStream on buffer create and destroy. When on EGLStream you destroy a buffer you destroy in every instance but with GBM when you destroy a buffer you only destory it for your process.

https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

Current GBM shortcomings expressed in the presentation are process-local handles only

This is the 2016. Nvidia developer of EGLStreams totally missed how important process-local handles(please note that the lead developer of EGLStreams giving that presentation) were this results in the EGLStreams design being wrong at the core. Nvidia classed process local handles are no required feature in fact called it a defect. This defect of not having process-local handles is why you cannot use EGLStreams to replace GBM.

Its really simple to miss that wayland started in 2008 before DMA-Buf exists. DMA-Buf comes into existence in 2011. For the first 3-4 years(2008-2011/2012) of Wayland developed using GEM handles that are are asynchronous and global with all the same defects as EGLStreams. Yes it was a intel developer who was making the mistake with the GEM handles. Yes the GEM handle security and stablity defects due to not having process-local handle was raised in 2012 by a VMWare developer pointing out security and stability defects at that point moving to GBM/DMA-Buf combination was done by core Wayland development. So Nvidia developer of EGLStreams miss why Wayland development moved to GBM/DMA-BUF combination in the first place.

Yes it seams to take roughly 4 years to work out process-local handles are not mistake and should not be treated as a optional feature but a mandatory feature. Intel graphics driver developer was pulled up in 2012 with this fault by vmware developer and Nvidia developer was pulled to a halt over the same fault with EGLStreams 8 years later 2020 by the KDE lead developer of course you could say this was 4 years open to the public..

Lack of process-local handle support make EGLStreams outright worse for the Wayland compositor use case.

Please do note GBM is a process-local handle solution this means the synchronous nature of GBM not system wide but per process limited so synchronous inside a process but asynchronous between processes. Yes the process-local handle does alter how important the asynchronous feature is as well for performance. This is why the result with EGLStreams asynchronous compared to GBM is only minor performance uplift that only happens in limited cases for a major security and stability downgrade with EGLStream. Yes you could replace EGLStreams with GEM handles the predecessor in Wayland development in the sentence before this one and the sentence still 100 percent correct because both times the exact same mistake was made of underestimating how important process-local handles are to the point of having no support for them.

[oiaohm]

So the *BSDs essentially get fu**** again by a Linux only tech making Wayland harder to implement on their platform. Wayland barely works on FreeBSD and doesn't work at all on OpenBSD- in fact there is currently no plasma 5 desktop option in OpenBSD because of lack of support for Wayland and release 6.9 removed the old 3.x and 4.x series KDE desktops!

kylew77 do not fall for deceptive. GBM is not Linux only tech Nvidia people have incorrect claimed this over and over again. If you are using mesa3d and open source graphics drivers that match up you have to have GBM.

mdedetrich is basically full of crap on this topic claiming Linux only tech. All the BSD that have graphical modes have mesa3d and the match open source drivers all of them have GBM.

The hard reality here kylew77 is that AMD, Intel and others develop their drivers on Linux first intentional license the code MIT or equal so it can be ported to BSD platforms. You could claim that GBM, DMA-BUF... all the feature developed by AMD/Intel/Mesa developers are Linux first developments but they are not Linux only technology. Of course being developed Linux first means Linux users get the new features and fixes before the BSD users do this does cause a few problems when a wayland developments have found a driver bug because Linux gets the fix first and BSD gets it up to 18 months latter there is a horrible lag between the Linux users getting updated kernel graphical drivers and the BSD users getting the same kernel graphical driver updates. The lag between updates of drivers is a big problem for users of BSD.

Big issue screwing BSD over with gnome and kde is not the graphical stack but in fact gnome and kde moving to systemd for user session management this is in fact a Linux only tech at this stage and this is to take advantage of Linux cgroup technology.

There very little in the way of Linux only technology causing problems for BSD. Majority of the problem is speed of transfer of developments from Linux to BSD. If you are looking for problem child Linux only technology effecting BSD desktop that is cgroups/systemd and that is the complete end of the list. Not a very long list at all.

The big problem is not Linux only technology. The big problem is BSD solutions have the developer resources to keep up with graphical driver work to validate the improvements to get the improved to their user in a time effective way.

[phoronix_is_awesome]

So the *BSDs essentially get fu**** again by a Linux only tech making Wayland harder to implement on their platform. Wayland barely works on FreeBSD and doesn't work at all on OpenBSD- in fact there is currently no plasma 5 desktop option in OpenBSD because of lack of support for Wayland and release 6.9 removed the old 3.x and 4.x series KDE desktops!

Yeah, the Linux application ecosystem is pretty much a monopoly compared to BSD(FreeBSD, OpenBSD) and OpenSolaris distros. Even when FreeBSD and OpenSolaris both have native in-kernel ZFS mirrored root, I still had to go through all the troubles and hassles of compiling zfs-dkms for zfs root to be able to switch to Ubuntu MATE.

[Volta]

phoronix_is_awesome

Linux shouldn't give a shit about bsd. It's competition if you didn't notice. Wake me up when bsd support from bsd crowd toward KDE and Gnome is more than 1%.

[oiaohm]

Yeah, the Linux application ecosystem is pretty much a monopoly compared to BSD(FreeBSD, OpenBSD) and OpenSolaris distros. Even when FreeBSD and OpenSolaris both have native in-kernel ZFS mirrored root, I still had to go through all the troubles and hassles of compiling zfs-dkms for zfs root to be able to switch to Ubuntu MATE.

https://en.wikipedia.org/wiki/Unix#/media/File:Unix_history-simple.svg

BSD(FreeBSD, OpenBSD) and OpenSolaris are all in the Unix family tree yes they are all relatives of each other. Yes with BSD people have forked the kernel and the forked kernels have failed to merge back into 1 single kernel. Yes all the Unix Family trace back to a single source tree.
Linux is a Unix like and is not in fact from the Unix family of operating systems. There have been many Linux kernel forks over the years most have merged back into mainline so the tree so far has not permanently split.
Linux is not exactly monopoly just the development has not had the fragmenting forever nature. GPLv2 license has limited the cases of fragmentation. Majority of the different BSD exist due different tolerances to code licensing. Linux kernel copyleft license most of the time has served it well.

zfs issues on Linux is a license issue backed up with a Oracle problem.

https://itsfoss.com/linus-torvalds-zfs/

ZFS could be mainline in Linux next release if Oracle would provide a letter saying that would not sue and could also allow license change from CDDL to GPLv2 compatible license. Oracle is a company that is not past using the courts when they think they are in the right most well known is the google vs orcale case but there are many others. Do remember ZFS was developed at sun for Solaris and now Oracle owns that.

This ZFS issue is one of there rare cases that copyleft license of GPLv2 is not the most helpful for the Linux kernel.

[Alexmitter]

You got it mostly right, but Nvidia isn't the bad guy here.

Doubt

GBM is Mesa/Linux only, whereas EGLStreams is a standard OpenGL (OpenGL ES?) extension, thus cross-platform.

Both is incorrect. BSD's implemented GBM too, or rather its a free bonus for them by using the Linux Graphics Infrastructure.
EGLStreams is in the Khronos standard as a specific Nvidia extension and only implemented by Nvidia all platforms, not just Linux.

It fits better Nvidia's cross-platform driver.

No it does not, they just already had it implemented for a different use case.

Moreover, Wayland, as a protocol, does not care how it's implemented. Wayland's reference implementation used GBM and then all other implementers figured "well, using GBM gives me support for AMD, Intel and a bunch of other GPUs nobody really cares about, so I'm gonna target that".

That would be correct, if EGLStreams was up to the task, but it is not, was not and never will be. Its forcing the square block through a round hole. It is completely unfit for Wayland.

Also, a good chunk of the pains of moving to Wayland is not about GBM vs EGLStreams. It's about Wayland doing away with a lot of functionality that was deemed insecure and implementers having to reinvent the wheel. And since there's no "server" to be shared anymore, everyone gets to reinvent their own wheel. Happy-happy, joy-joy.

Everyone was already inventing their own wheel for 20 years. X Compositors where already a thing for a long time with about every desktop implementing their own slightly incompatible one with Xorg just being a annoying extra step in passing a buffer around. And yes, X11 with all its extensions is so fundamentally broken beyond repair that reinventing the wheel is a need on the path of Linux not just having a acceptable display protocol but a supreme one.

[kylew77]

kylew77 do not fall for deceptive. GBM is not Linux only tech Nvidia people have incorrect claimed this over and over again. If you are using mesa3d and open source graphics drivers that match up you have to have GBM.

mdedetrich is basically full of crap on this topic claiming Linux only tech. All the BSD that have graphical modes have mesa3d and the match open source drivers all of them have GBM.

The hard reality here kylew77 is that AMD, Intel and others develop their drivers on Linux first intentional license the code MIT or equal so it can be ported to BSD platforms. You could claim that GBM, DMA-BUF... all the feature developed by AMD/Intel/Mesa developers are Linux first developments but they are not Linux only technology. Of course being developed Linux first means Linux users get the new features and fixes before the BSD users do this does cause a few problems when a wayland developments have found a driver bug because Linux gets the fix first and BSD gets it up to 18 months latter there is a horrible lag between the Linux users getting updated kernel graphical drivers and the BSD users getting the same kernel graphical driver updates. The lag between updates of drivers is a big problem for users of BSD.

Big issue screwing BSD over with gnome and kde is not the graphical stack but in fact gnome and kde moving to systemd for user session management this is in fact a Linux only tech at this stage and this is to take advantage of Linux cgroup technology.

There very little in the way of Linux only technology causing problems for BSD. Majority of the problem is speed of transfer of developments from Linux to BSD. If you are looking for problem child Linux only technology effecting BSD desktop that is cgroups/systemd and that is the complete end of the list. Not a very long list at all.

The big problem is not Linux only technology. The big problem is BSD solutions have the developer resources to keep up with graphical driver work to validate the improvements to get the improved to their user in a time effective way.

Thank you for the clarification.

[nvaert1986]

My laptop has two outputs connected to the NVidia GPU, will I be able to use those as well as the laptop display connected to the Intel iGPU?

Last time I tried it on KDE Wayland it didn't work.

I have the exact same issue. The last time I tried it on Gnome it didn't work for me either,. I'd basically say this is a no go. Only my Intel iGPU would display output. My dGPU (NVIDIA; hard-wired to the external display output ports) did not display anything. It only works when I set my NVIDIA GPU as discrete in the UEFI / BIOS settings, but this causes my battery life to drop by 3+ hours.

[Azrael5]

So Nvidia is not compliant with Wayland yet.