Announcement

Collapse
No announcement yet.

XWayland 21.1.2 Released With NVIDIA Hardware Acceleration Support

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

  • #21
    Finally.. Thanks NVidia.

    Comment


    • #22
      Originally posted by Azrael5 View Post
      Why didn't Linux developers take advantage of Eglstream in Wayland?
      Quite a few reasons.
      1. EGLStreams was not decided on(*1), it is a different solution for a different purpose that Nvidia already implemented, mainly for Android.
      2. It is defective and not fit for Wayland. GBM on the other side does work very well for its job.
      3. EGLStreams has no advantages, not even for Nvidia GPUs. The only reason why is that EGLStreams were already implemented in their driver as said in 1.

      1*: There was a big invitation from Mesa/Xorg to discuss how a buffer manager for Wayland should look like, Nvidia was invited but did not attend and then later spitted out baseless claims on why GBM is bad for their GPUs and that EGLStreams is better that were all disproven.

      Comment


      • #23
        Originally posted by Alexmitter View Post
        1*: There was a big invitation from Mesa/Xorg to discuss how a buffer manager for Wayland should look like, Nvidia was invited but did not attend and then later spitted out baseless claims on why GBM is bad for their GPUs and that EGLStreams is better that were all disproven.
        Can you send a link to that discussion? I bet you can't, because this is false claim from reddit.

        Comment


        • #24
          any Ubuntu PPA or deb release file?

          This PPA is daily build but 86weeks old. https://launchpad.net/~wayland.admin...u/daily-builds
          Last edited by phoronix_is_awesome; 09 July 2021, 01:57 PM.

          Comment


          • #25
            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.
            Good summary, one other important thing to add to put things into context is that GBM is a Linux only technology where as EGLStreams was an open khronos standard that was designed to be cross platform. There was a reason why NVidia was pushing (albeit ultimately unsuccessfully EGLStreams), its design was universal across platforms where as GBM is Linux specific and its easy to understand why NVidia initially didn't want to use OS specific API's.

            Originally posted by Alexmitter View Post

            1*: There was a big invitation from Mesa/Xorg to discuss how a buffer manager for Wayland should look like, Nvidia was invited but did not attend and then later spitted out baseless claims on why GBM is bad for their GPUs and that EGLStreams is better that were all disproven.
            This is incorrect, there are things that by design EGLStreams does better than GBM. EGLStreams is fully asynchronous where as GBM is synchronous in design. This gives EGLStreams advantages in certain cases but in general it can be said that NVidia probably gave up on pushing it because in Linux no one wanted it. Even the creator of Sway ultimately conceded this point in an online debate, a large portion of GBM winning was largely political.
            Last edited by mdedetrich; 09 July 2021, 01:45 PM.

            Comment


            • #26
              Originally posted by Azrael5 View Post
              How long for 470 Nvidia drivers?
              CUDA 11.4 deb(local) includes the 470 driver. I have been using it since July 1.

              Comment


              • #27
                Originally posted by mdedetrich View Post
                This is incorrect, there are things that by design EGLStreams does better than GBM. EGLStreams is fully asynchronous where as GBM is synchronous in design. This gives EGLStreams advantages in certain cases but in general it can be said that NVidia probably gave up on pushing it because in Linux no one wanted it.
                https://www.kernel.org/doc/html/v4.1...i/dma-buf.html
                This is serous-ally not as straight forwards. GBM may be synchoronous but the dma-buf used with it was asynchronous. You have to remember EGLStreams was attempting todo the functionality of both GBM and DMA-BUF and other parts.

                Reality is EGLStreams only had advantages is very limited use cases even with workloads needing asynchronous this is due to the smaller scope of what GBM provides to EGLstream and the other parts covering the scope of EGLStreams end up being asynchronous. EGLStreams had a major downside to GBM/DMA-BUF solution as well. Its the issue with how are buffers passed between are handled. GBM/DMA-BUF the passed buffer between processors does not pull a magic disappearing act because the application that allocated buffer terminated on the application that received the buffer that is attempting to use it.

                Also we know Nvidia gave up pushing EGLStreams as hard when their developer work on KDE run into impossible problems. Like KDE developers want the ability to restart the compositor and get new issue old buffers from applications you cannot do that with EGLStreams(method to clean up memory leaks you can do with GBM/DMA-BUF). The disadvantages of EGLStreams did not justify the advantages.

                Comment


                • #28
                  Originally posted by oiaohm View Post

                  https://www.kernel.org/doc/html/v4.1...i/dma-buf.html
                  This is serous-ally not as straight forwards. GBM may be synchoronous but the dma-buf used with it was asynchronous. You have to remember EGLStreams was attempting todo the functionality of both GBM and DMA-BUF and other parts.
                  If one part of the system is synchronus and another asynchronous part of the system is just wrapping the synchronous part, its not truly asynchronous. There were legitimate performance improvements that EGLStreams had over GBM which came to light when technical knowledgeable people looked over the fine details.

                  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

                  Comment


                  • #29
                    Originally posted by mdedetrich View Post
                    Good summary, one other important thing to add to put things into context is that GBM is a Linux only technology where as EGLStreams was an open khronos standard that was designed to be cross platform.
                    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!

                    Comment


                    • #30
                      Originally posted by kylew77 View Post

                      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!
                      Well duh. Wayland is developed by the Linux community for Linux, why exactly should they make their own work harder for the benefit a totally different OS? What is the benefit FOR WAYLAND in that? Does anybody in Linux whine that pf is OpenBSD-only? Does anyone call MS names because PowerShell is still Windows only (at least in practice)?

                      Comment

                      Working...
                      X