Announcement

Collapse
No announcement yet.

KDE On The Importance Of Wayland Explicit Sync

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

  • #21
    What about GBM is still based on implicit sync?

    Comment


    • #22
      Originally posted by MorrisS. View Post
      What about GBM is still based on implicit sync?
      Currently nvidia doesnt have any sync. It just uses glfinish

      Comment


      • #23
        Originally posted by Brittle2 View Post

        the issue is because of nvidia
        The issue is because Linux relied on an outdated graphics rendering design (implicit sync) for 15 years longer than other desktop OS's.

        The reason why Nvidia doesn't support implicit sync directly is they removed it from all of their drivers when they had to rewrote their drivers from scratch for vista.

        Look up how old vista is and let that sink in.

        Comment


        • #24
          Originally posted by numacross View Post
          It really isn't only about NVIDIA.
          Implicit sync that's currently used in Linux is an inferior design. Every modern OS has moved to explicit sync in some form. Vulkan is based around it, and currently requires workarounds all over the graphical stack to make it work with implicit sync. Collabora posted an article explaining those issues.
          One could even argue that by being so stubborn NVIDIA has pushed the entire Linux graphics ecosystem forward, but it's not the whole truth. Everyone will benefit from explicit sync being properly supported.
          There is something in that colllabora link that is important.
          To improve both GPU and CPU utilization, modern APIs like Vulkan take a different approach. Most Vulkan objects such as images are immutable: while the underlying image contents may change, the fundamental properties of the image such as its dimensions, color format, and number of miplevels do not.
          This vulkan immutable items are created using implicit methods. Yes with vulkan since most of the time you are running in explicit sync you cannot go and alter a implict sync item.

          This is different from OpenGL where the application can change any property of anything at any time.
          EGLStreams from Nvidia based on Opengl attempted to this line with explicit sync and it simple does not work.

          This is one of these catches. Implicit sync is basic safe to change everything. Yes being safe to change everything equals extra locking.

          numacross the reality here is a pure implicit sync or pure explicit sync design on a multi process system is defective in different ways.

          Pure implicit sync you have over locking so slow but the item is stable.
          Pure explicit sync you have race conditions and other problems with memory management making the solution totally unstable.

          The art is having the right amount of implicit sync in the memory management to be stable and everything else to be explicit sync so it fast.

          The first DMABUF explicit sync extension was added to Wayland in 2016. Nvidia pushing for a pure explicit sync and not support the DMABUF solution lead to lot of projects sticking to old opengl implicit sync because this was still code once.

          Yes Nvidia marketing push that the best solution is always Explicit sync made it hard for quite some time to see the reality that the best solution is careful mix of implicit and explicit sync. Basically use implicit sync for what is good for that shared memory/resource management and using explicit sync for what it good for and that processing management and don't attempt to do everything with just one them because it does not end well. In fact end very badly if you attempt to do everything with explicit sync.

          Nvidia did not successfully push the Linux graphical stack forwards. Nvidia pushing impossible idea stalled out Linux graphical stack development as the other parties waited to see if Nvidia was right or wrong. Yes Nvidia with EGLstreams was proven wrong and that proved that pure explicit sync was a valid solution if you wanted unstable platform.

          Comment


          • #25
            Originally posted by mdedetrich View Post

            The issue is because Linux relied on an outdated graphics rendering design (implicit sync) for 15 years longer than other desktop OS's.

            The reason why Nvidia doesn't support implicit sync directly is they removed it from all of their drivers when they had to rewrote their drivers from scratch for vista.

            Look up how old vista is and let that sink in.
            So nvidia is the only graphics card vendor that does not support implicit sync? Let that sink in.

            Comment


            • #26
              Originally posted by ssokolow View Post

              From what I remember, nVidia support for GBM came about suspiciously soon after nVidia decided "OK, KDE, if that's what it takes, we'll write the EGLStreams backend and give you a developer liason" and said laison was kept very busy running to the nVidia driver team with "How do I do this thing we've already implemented for GBM or plan to implement for GBM?" questions where the answer turned out to be "We never thought anyone would need that, so the architecture doesn't support that".

              (eg. I think David Edmundson's crash recovery patches were one such example. I seem to remember something about EGLStreams's design making it fundamentally impossible to keep allocated GPU resources alive beyond the death of the process that allocated them.)
              Found one of my sources:


              (Can't quote it because the forum's oversensitive IDS thinks it's an exploit and returns error 403 on submit.)

              Comment


              • #27
                Since when has supporting Nvidia's proprietary garbage been "important"? 🤮

                Comment


                • #28
                  Originally posted by jeisom View Post
                  I am glad this is getting all resolved. Explicit sync is the main issue that is affecting my day to day usage, but the changes to Xwayland(967) are helping. Many are blaming Nvidia for wayland's slow adoption, but even on AMD hardware Plasma was unstable until Plasma 6 which just came out a couple months ago. Not everyone is going to be happy with using Gnome as the only stable(-ish) mass user implementation.
                  ... KDE + Wayland + AMD opensource drivers has been fully usable (including 3-monitors) since 5.26/5.27

                  Comment


                  • #29
                    Originally posted by jeisom View Post
                    I am glad this is getting all resolved. Explicit sync is the main issue that is affecting my day to day usage, but the changes to Xwayland(967) are helping. Many are blaming Nvidia for wayland's slow adoption, but even on AMD hardware Plasma was unstable until Plasma 6 which just came out a couple months ago. Not everyone is going to be happy with using Gnome as the only stable(-ish) mass user implementation.
                    Is there no remaining Wayland/AMD(gpu) issues to speak of? I find that hard to believe as I've read some amd gpu users/owners speak of some - I just can't recall what they are. I assume, there's more 'integrated' and smooth operation but like others have said - everyone should benefit from the implementation of explicit sync, not just nvidia.

                    Comment


                    • #30
                      Originally posted by Grinness View Post

                      ... KDE + Wayland + AMD opensource drivers has been fully usable (including 3-monitors) since 5.26/5.27
                      While it may have been in your case, the system I was using was not stable with 5.27. On the other hand Plasma 6 since release has been very stable on my primary system with an Nvidia card and honestly works better than with X11 with the exception of the explicit sync related issues.

                      Comment

                      Working...
                      X