Announcement

Collapse
No announcement yet.

KDE On The Importance Of Wayland Explicit Sync

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

  • #31
    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.
    But everyone else was able to make do and have not only decent performance, but also decent quality without it.

    It is not to suggest that this explicit sync will not be an overall improvement.

    But we have no guarantee nvidia will actually fix its own drivers - just hopes and dreams. They previously promised the same thing with EGLStreams and failed miserable.

    I hope they do better this time.

    Comment


    • #32
      As a 1660 super owner I am so happy to read of these developments.
      Nouveau is running well on Plasma 6 - but it would be nice to get the full features of the card that the proprietary driver offers.
      Thanks to all devs working to get Wayland fully performant.
      Finally it is happening.

      Comment


      • #33
        Originally posted by jeisom View Post

        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.
        maybe the keyword in your case is 'NVIDIA'

        in my case the keyword is 'AMD opensource drivers'

        anyhow I am happy for you that Plasma 6 works fine now

        Comment


        • #34
          What are the benefits that me (using mesa with amd hardware) will get from those patches? I'm a little confuse about implicit / explicit sync talk.

          Comment


          • #35
            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.
            an outdated rendering design that allows linux (AMD opensource stack) to run windows games via a set of wrappers faster/more efficiently than windows
            What a disaster ....

            Comment


            • #36
              Originally posted by furtadopires View Post
              What are the benefits that me (using mesa with amd hardware) will get from those patches? I'm a little confuse about implicit / explicit sync talk.
              Reading the blog posts:

              Recently news went around about explicit sync being merged into Wayland protocols, and in the wake of that I saw a lot of people having questions about it, and why it was such a big deal… So here’s a short-ish explanation of what it is, why it’s needed and what the benefits are over the old model.




              for AMD & opensource stack it entails avoiding (micro)stuttering in corner cases.

              Note that already (for example) running Cyberpunk under Wayland (so I assume XWayland) provides better min frame rates and no stuttering compared to X11 -- AMD opensource drivers.

              Comment


              • #37
                Originally posted by mxan View Post

                So much manpower wasted to hack around the lack of explicit sync when Vulkan needs it and all other platforms support it.

                Also, EGLStreams were superior to GBM, there is no question about it, Wayland would've been adopted far sooner if the desktops adopted EGLStreams instead of sticking to inferior GBM.
                Yeah, so "superior" that it couldn't even support direct scanout which is like one of the basic features of modern compositor. NVIDIA picked EGLStreams only because they already supported it, not because it was better for Wayland.​ If they would help improve GBM instead of their inferior solution, Wayland would be ready sooner.

                Originally posted by Grinness View Post

                an outdated rendering design that allows linux (AMD opensource stack) to run windows games via a set of wrappers faster/more efficiently than windows
                What a disaster ....
                Yeah by using various workarounds. Performance is not the only important thing, code also needs to be maintainable, the more workarounds the harder code becomes to maintain.

                Various developers asked for this for years. Every other modern platform (including Android based on Linux) are using explicit sync for good reasons. Vulkan is also based on explicit sync concept for good reasons. This time NVIDIA is right and their work will be beneficial not only for them but also for Linux in general. If we want to have modern graphics stack we shouldn't keep it designed around concepts introduced in 90's.

                Comment


                • #38
                  Why the big fuzz then?


                  If we already have “explicit sync through a backdoor”, and explicit sync doesn’t bring major performance improvements for everyone, why is it such big news then?

                  The answer is simple: The proprietary NVidia driver doesn’t support implicit sync at all, and neither commonly used compositors nor the NVidia driver support the first explicit sync protocol, which means on Wayland you get significant flickering and frame pacing issues. The driver also ships with some workarounds, but they don’t exactly fix the problem either:
                  • it delays Wayland commits until rendering is completed, but it goes against how graphics APIs work on Wayland and can cause serious issues, even crash apps in extreme cases
                  • it delays X11 presentation until rendering is completed, but as Xwayland copies window contents sometimes, that still often causes glitches if Xwayland is also using the NVidia GPU for those copies

                  There’s been a lot of discussions around the internet between people experiencing the issues constantly, and others not seeing any, and now you should know why it doesn’t seem to affect everyone: It’s not a deterministic “this doesn’t work” problem but a lack of synchronization, which means that a lot of factors - like the apps you use, the CPU and GPU you have, the driver version, the kernel, compositor and so on - decide whether or not you actually see the issue.

                  With the explicit sync protocol being implemented in compositors and very soon in Xwayland and the proprietary NVidia driver, all those problems will finally be a thing of the past, and the biggest remaining blocker for NVidia users to switch to Wayland will be gone.

                  Source : https://zamundaaa.github.io/wayland/...icit-sync.html

                  Comment


                  • #39
                    Originally posted by dragon321 View Post

                    Yeah, so "superior" that it couldn't even support direct scanout which is like one of the basic features of modern compositor. NVIDIA picked EGLStreams only because they already supported it, not because it was better for Wayland.​ If they would help improve GBM instead of their inferior solution, Wayland would be ready sooner.



                    Yeah by using various workarounds. Performance is not the only important thing, code also needs to be maintainable, the more workarounds the harder code becomes to maintain.

                    Various developers asked for this for years. Every other modern platform (including Android based on Linux) are using explicit sync for good reasons. Vulkan is also based on explicit sync concept for good reasons. This time NVIDIA is right and their work will be beneficial not only for them but also for Linux in general. If we want to have modern graphics stack we shouldn't keep it designed around concepts introduced in 90's.
                    maybe read the below before writing 'NVIDIA' here or there:

                    After fighting with the divide between implicit and explicit synchronization with Vulkan on Linux for over seven years, we may finally have some closure.


                    couple of quotes:

                    "The RADV driver currently tracks when each window-system buffer is acquired by the client and only enables implicit synchronization for window-system buffers and only when owned by the client. Thanks to details of the amdgpu kernel driver, enabling implicit synchronization doesn't actually cause the client to synchronize with itself when doing work on multiple queues."

                    "The end result is that we can't just rewire everything and drop in a new solution atomically. Whatever we do has to be something that can be rolled out one component at a time.

                    This solution allows us to roll out better explicit synchronization support to users seamlessly. Vulkan drivers seamlessly work with compositors which only understand implicit synchronizaiton and, if Wayland compositors pick up sufficient explicit synchronization support, we can transition to that once the compositors are ready"


                    The above is a post from 2022.
                    As you can see the plan is being actioned

                    ... and AMD opensource stack has no problems with either implicit or explicit sync.

                    Comment


                    • #40
                      Originally posted by oiaohm View Post

                      There is something in that colllabora link that is important.


                      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.


                      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.
                      I don't agree with explicit sync disadvanatages.

                      1st. Race conditions : technically speaking if you have race condition in explicit sync, that simply means developer didn't put synchronization primitive (probably fence) when he is supposed to. When implicit synchronization removes that responsibility from programmer of application, that responsibility is moved to things programmer use (either compositor, API or driver has to put synchronization primitive themselves). But in that case you might easly have race condition in driver. The most obvious example is literally Nvidia - implicit sync that doesn't put fence down the line(because they don't implement a lot of it) and you have flickering or other issues. That is race condition case technically in implicit sync. In case of opengl stuff you had a lot of things in the past when ATI/AMD driver liked to NOT put synchronization stuff in right moment and you had a lot of weird artifacts. (talking about times when ATI/AMD drivers were bad and there was no opensource).

                      Thing is in implicit sync setting stuff right is hard because from one side as developer of driver you want to remove as many fences as possible to make things fast, but if you remove too much you generate bugs.

                      2nd. I don't understand your problem with memory managment. Yes EGLstreams had some issues, but none of the issues come from idea "it is because of explicit sync" but simply design didn't account for certain edge cases. And considering it was pretty much solo done by Nvidia without much community questions of sort "what about this case" - yea it was bound to happen. GBM also has cases that it doesn't support while EGLstreams do (and in fact Marek Olsak AMD developer in one certain case admitted it). Anyone who designed any serious system/design almost always later on gets some special edge case that didn't account for. That is normal.

                      > implicit sync for what is good for that shared memory/resource management

                      No. Even blog specifically mentions problems with it. Vulkan buffer managment is explicit. And is good, defines really well what can be shared between what different command queues. Yes it works.

                      Implicit sync has advantages in 3 cases:
                      a) you don't care about performance - in that case oversynchronization is not a problem for you. In that case you didn't have to write anything synchronization wise on side of programmer and technically driver didn't have to optimize anything.

                      b) You deploy something simple, trivial. In that case delegating responsibility to driver means less work for you. This is part of reason why some small develeper shouldn't use vulkan or dx12 at all. OpenGL or DX11 will be easier for them and with way less work. But at the same time in complex cases, like game engines, compositors it isn't. Mentioned "backdoor" from blog would be extremely straightforward in explicit synchronization world.

                      c) in certain cases, explicit synchronization doesn't make much sense. Vulkan WSI is good example. Like how windows should implement, how they should be managed is domain that compositor knows probably better. So it makes sense to delegate that responsibility from client to server. That being said, here implicit sync becomes responsibility of server and on server it becomes explicit in reality.
                      Last edited by piotrj3; 06 April 2024, 04:45 PM.

                      Comment

                      Working...
                      X