Announcement

Collapse
No announcement yet.

XWayland 21.1.2 Released With NVIDIA Hardware Acceleration Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • XWayland 21.1.2 Released With NVIDIA Hardware Acceleration Support

    Phoronix: XWayland 21.1.2 Released With NVIDIA Hardware Acceleration Support

    XWayland 21.1.2 is out today and while it may seem like "just a point release", it's quite an exciting one at that since it does bring NVIDIA hardware acceleration for XWayland when paired with their new NVIDIA 470 series driver...

    https://www.phoronix.com/scan.php?pa...1.1.2-Released

  • #2
    This proofs how Xwayland be the alternative name of Xorg. Pretty news for nvidia hardware acceleration, but the real good news will be the move to GBM support.

    Comment


    • #3
      Will it make Wayland session in Fedora default even with proprietary NV blob in place (at least soon)? Anyone succeeded to test that already and does it work? Though the timing for this is pretty terrible - they plan to switch to GBM backend in "some time" anyway. Seems like wasted time and resources for doing a thing that is already planned to be replaced.
      We'll see NVIDIA running on Gnome (and KDE maybe) and then all the other compositors in the future. What's confusing is how will it behave when there will be 2 backends available for the driver? EGLStreams by default and fallback to GBM or the other way around?

      Comment


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

        Comment


        • #5
          Originally posted by gnarlin View Post
          Can someone explain to me what this GBM vs EGLstreams kerfuffle is about?
          Well, as I understand it (anyone, feel free to correct me on that one, I'm not graphics specialist), they're both APIs that deal with graphics memory allocation/buffer management. Most vendors agreed to support Generic Buffer Management API in their drivers, but NVIDIA decided to push EGLStreams API as it was easier for them to implement into their closed driver. Since on Wayland there's no longer any centralized graphics server (each compositor/wm is now server by itself), in order to let NVIDIA GPUs to be usable on Wayland, there has to be special implementation of EGLStreams in each one. Some developers decided to integrate both APIs into their compositors (Gnome), some decided otherwise (libwlroots). KDE didn't want to implement that by themself, but NVIDIA employee made the implementation for them.

          TL;DR NVIDIA made the situation for developers to look this way: implement GBM backend in your compositor to make it work on all hardware apart from NVIDIA. Optionally implement alternative EGLStreams backend to allow NVIDIA hardware to work and make the code harder to maintain.

          Comment


          • #6
            Originally posted by bple2137 View Post

            Well, as I understand it (anyone, feel free to correct me on that one, I'm not graphics specialist), they're both APIs that deal with graphics memory allocation/buffer management. Most vendors agreed to support Generic Buffer Management API in their drivers, but NVIDIA decided to push EGLStreams API as it was easier for them to implement into their closed driver. Since on Wayland there's no longer any centralized graphics server (each compositor/wm is now server by itself), in order to let NVIDIA GPUs to be usable on Wayland, there has to be special implementation of EGLStreams in each one. Some developers decided to integrate both APIs into their compositors (Gnome), some decided otherwise (libwlroots). KDE didn't want to implement that by themself, but NVIDIA employee made the implementation for them.

            TL;DR NVIDIA made the situation for developers to look this way: implement GBM backend in your compositor to make it work on all hardware apart from NVIDIA. Optionally implement alternative EGLStreams backend to allow NVIDIA hardware to work and make the code harder to maintain.
            You got it mostly right, but Nvidia isn't the bad guy here.
            GBM is Mesa/Linux only, whereas EGLStreams is a standard OpenGL (OpenGL ES?) extension, thus cross-platform. It fits better Nvidia's cross-platform driver. For bonus points, GBM and EGLStreams are not exactly equivalent to each other and both have their downsides.

            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".

            I mean sure, one code path is preferable, but not when it means leaving a good chunk of your users hanging.

            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.

            Comment


            • #7
              Originally posted by gnarlin View Post
              Can someone explain to me what this GBM vs EGLstreams kerfuffle is about?
              This is more of a mess.
              Originally posted by bple2137 View Post
              Well, as I understand it (anyone, feel free to correct me on that one, I'm not graphics specialist), they're both APIs that deal with graphics memory allocation/buffer management. Most vendors agreed to support Generic Buffer Management API in their drivers, but NVIDIA decided to push EGLStreams API as it was easier for them to implement into their closed driver. Since on Wayland there's no longer any centralized graphics server (each compositor/wm is now server by itself), in order to let NVIDIA GPUs to be usable on Wayland, there has to be special implementation of EGLStreams in each one. Some developers decided to integrate both APIs into their compositors (Gnome), some decided otherwise (libwlroots). KDE didn't want to implement that by themself, but NVIDIA employee made the implementation for them.

              TL;DR NVIDIA made the situation for developers to look this way: implement GBM backend in your compositor to make it work on all hardware apart from NVIDIA. Optionally implement alternative EGLStreams backend to allow NVIDIA hardware to work and make the code harder to maintain.
              This is only part of the problems.
              https://www.tomshardware.com/news/jp...-million-units
              Some is that Nvidia has been over come with their self importance.
              Yes the Discrete PC GPU Market Share they lead. Problem is it a different matter when you look at the The Overall GPU Market. In the overall market AMD and Nvidia are fairly much head to head. AMD sells a hell load of APUs. Intel sells a mountain of iGPUs. So to be able support 80%+ of the PC in existence you have to support Intel and AMD graphics. Yes if you are talking about computers with a Discrete GPU to support over 80 percent of that market you have to support Nvidia but that is really 15-17% of the overall market. Nvidia miss understand it position made them believe they had more market force to have developer do what they want.

              Yes the situation for developers has really been for 80+% of users implementing the GBM back-end and you were done. There is also the problem that GBM can do things that EGLStreams cannot. https://bugs.kde.org/show_bug.cgi?id=428089 fun you have to been unable to implement a compositor restart using EGLStreams but it is possible with GBM. This is another part of the problem. Not only is EGLStreams a different implementation to deal with there are features that EGLStreams is missing that are really show stoppers like compositor restart without screwing over applications

              Worst compositor crash without screwing over applications. The reality here even if you cannot restart a GBM based compositor if you shut the compositor down the running applications can detect this and save state. EGLStreams current versions result in you kill compositor all memory allocated by the compositor gets de-allocated result in any application attempting to access that memory being segfault-ed normally resulting in being unable to save state even if the application wanted to.

              This kind of explains why libwlroots did not want anything to-do with Nvidia EGLStreams due to when you looked closely it was defective. Yes those defective parts meant you could not in fact implement a fully working alternative to GBM using Nvidia EGLStreams. Remember 80%+ of the target market share for libwlroots does not have Nvidia GPUs.

              The big cause of the complete EGLStreams vs GBM mess was Nvidia thinking they were more important due to the dominance in the discrete PC GPU market than that really makes you. This results in Nvidia not seeing that they really do need for the design of EGLStreams to be sitting down and getting accepted by AMD and Intel. Yes with AMD and Intel in fact being the dominate if they could not convince them that EGLStreams was a good idea they should have implemented GBM support back then.

              At least finally Nvidia is starting to wake up that they have to support GBM and they have to support DMA-BUF because Nvidia does not have enough market share to in fact push their own solution.

              Yes the reason why the KDE developer said Nvidia had to provide their own developer to implement EGLStreams support was party because of Nvidia in fact lack of market share. Lot of people due to all the marketing about Discrete PC GPUs would not think for one min that Nvidia is in fact a minority market share. Yes the real state play Nvidia is a minor player who attempted to act like a major player so causing the Linux world a huge mess.

              Comment


              • #8
                Originally posted by bug77 View Post

                You got it mostly right, but Nvidia isn't the bad guy here.
                GBM is Mesa/Linux only, whereas EGLStreams is a standard OpenGL (OpenGL ES?) extension, thus cross-platform. It fits better Nvidia's cross-platform driver. For bonus points, GBM and EGLStreams are not exactly equivalent to each other and both have their downsides.
                While I believe all of that is true, I think part of the kerfuffle was how long Nvidia waited to say they weren't going to support GBM. There were discussions about what thing to support and they kept quiet until everyone else agreed on GBM. I don't think Nvidia was being malicious, but they simply didn't care enough.

                Comment


                • #9
                  Why didn't Linux developers take advantage of Eglstream in Wayland?
                  Last edited by Azrael5; 09 July 2021, 10:24 AM.

                  Comment


                  • #10
                    Originally posted by Azrael5 View Post
                    Why didn't Linux developers take advantage of Eglstream in Wayland?
                    Apparently there is no real advantage of EGLStreams with respect to GBM:

                    EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.
                    https://www.phoronix.com/scan.php?page=news_item&px=XDC2016-Device-Memory-API

                    Everyone (except NVIDIA) standardized on GBM (all opensource stack)
                    It is NVIDIA fault


                    Comment

                    Working...
                    X