Announcement

Collapse
No announcement yet.

XWayland 24.1 Planned For Release Next Month With Explicit Sync & Other Features

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

  • #41
    Originally posted by mSparks View Post
    The proprietary NVidia driver doesn't support implicit sync at all
    There is a problem here.
    Nvidia bypasses X11 protocol as much as they can.

    Originally posted by mSparks View Post
    X11s entire design is isolated, atomic bytestreams that are not subject to the race conditions that make wayland so unstable, that isn't implicit sync - not even close, it is however what wayland is finally trying to replicate with this new extension.

    Example: Identifying a race condition in i3-wm
    Like it or not X11 protocol does race condition tools have be developed to detect it. In fact you wrote the cause of the problem. "bytestreams" being more than one. What keeps the possible multi-able X11 protocol byte-streams the application can be sending items in on synced then answer is absolutely nothing. What says that you cannot start a operation on one X11 bytestream and close it on another absolutely nothing. What says application can only have one connection open to the X11 server answer absolutely nothing. Welcome to race condition coded into the X11 protocol.

    Wayland protocol in fact does not allow this race condition. Wayland you cannot start operation on one connection and close different connection. Wayland compositor is free to restrict application to a single wayland connection and that is in the wayland protocol as well. These two changes kill the possible race condition.

    Nvidia wanted with Xwayland originally to bipass the Wayland compositor with eglstreams and it was highly unstable.

    Wayland is forcing Nvidia to use defined behavior instead of undefined behavior.

    Sometimes, black or incorrect textures appear in KDE instead of window contents or other interface elements, like widgets on the panel. One easy way to reproduce the problem is this: Toggle Kwin compositing off and then on again with a hotkey. Have multiple windows opened, from different applications. I typically use Firefox, Thunderbird, QtCreator, Kate and other KDE applications for testing. Preferably, one window should be maximized in the background. Open new windows or resize (preferably ...


    Nvidia bad behavior is not limited to Wayland. There have been on going cases with Nvidia wish to use more explicit sync than you should resulting in issues under .x.org X11 server running in bare metal.

    Nvidia forums contain issue after issue that relate to Nvidia lack of functional implicit sync on GPU memory operations. GBM/DRI3 support by Nvidia is having their driver at least add some implicit sync as in the implicit sync for memory management you need not to have disasters all the time.

    Comment


    • #42
      Originally posted by mSparks View Post

      X11s entire design is isolated, atomic bytestreams that are not subject to the race conditions that make wayland so unstable, that isn't implicit sync - not even close, it is however what wayland is finally trying to replicate with this new extension.
      X11 is 100% implicit sync, and always has been. It doesn't sound like you actually understand what explicit sync is about.

      Nvidia works around it by replacing a bunch of X with their own alternative code, by plugging in their x driver. xwayland didn't allow them to replace x anymore with their own private interface, which is why it didn't work for them.
      Last edited by smitty3268; 15 April 2024, 01:53 AM.

      Comment


      • #43
        Originally posted by smitty3268 View Post

        X11 is 100% implicit sync, and always has been. It doesn't sound like you actually understand what explicit sync is about.

        Nvidia works around it by replacing a bunch of X with their own alternative code, by plugging in their x driver. xwayland didn't allow them to replace x anymore with their own private interface, which is why it didn't work for them.
        If anything there is NO sync in X11, because one window cannot modify the memory of another window, they can only exchange commands.

        implicit/explicit sync only applies when you have something trying to do different things on the same resource at the same time - this is where wayland explodes everywhere (not least QtWayland judging by the issue reports). The closest X11 gets to any kind of synchronisation is enabling vsync in the gpu driver, whereas wayland tries to do all that in software on the CPU, X11 leaves it all up to the GPU driver, and is otherwise asynchronous always - nothing "workaround" about it.

        heck, that was the whole "selling point" of wayland we've been fed for the last few years it was implicit sync "every frame is perfect" that you "couldnt do" in X11 (except you could, with vsync). Accepting that was BS is a big step for wayland, however comic the squirming is.
        Last edited by mSparks; 15 April 2024, 03:40 AM.

        Comment


        • #44
          Originally posted by oiaohm View Post
          Will allow the old faking to work. Please note PCSX was not using window manager rules to fake it. Instead using open window at absolute position to fake it. .
          The customer's applications also make use of this for other scenarios but in this case they needed window manager rules to override the application behavior to ensure consistency.

          In any case not really important. The demo was intended to show an approach that is available with Wayland (custom compositor) that would be a lot of work on X11 (custom display server + custom window manager).

          Originally posted by oiaohm View Post
          PCSX2 being a game thing input latency is a thing. Having input pass though to compositors instead of one they class as a problem.
          I would be surprised if that has ever actually been measured.

          But even if that were a genuine concern it would be far better to address this directly, e.g. having an even queue per sub surface.
          Web browsers need to do this kind of input forwarding as well and could leverage this.

          It is also not unlikely that this kind of set up would become more common now that it is so much easier to accomplish.
          Process separation can be nice for isolation, modularity, stability and scalability.

          Comment


          • #45
            Originally posted by mSparks View Post
            If anything there is NO sync in X11, because one window cannot modify the memory of another window, they can only exchange commands.
            This is not true. XACE provides protections to prevent X11 applications from altering window owning to a different application. Of course people don't have XACE enabled by default.

            The reality the default security of X11 is security by obscurity. Once you go snooping around in X11 lists of resources without XACE loaded you can get up to all kind of trouble.

            Originally posted by mSparks View Post
            implicit/explicit sync only applies when you have something trying to do different things on the same resource at the same time
            To be correct default X11 protocol is explicit sync hidden by security by obscurity with no structures to perform safe explicit sync. Yes the presume you will not go around looking at resource ids and using those resource ids to access and alter items your application did not create is what the X11 protocol is depending on.

            Yes lack of safe and solid sync solution in X11 results in X11 protocol having lots of different cases of race conditions.

            Originally posted by mSparks View Post
            heck, that was the whole "selling point" of wayland we've been fed for the last few years it was implicit sync "every frame is perfect" that you "couldnt do" in X11 (except you could, with vsync).
            To be correct you could not do every frame is perfect with vsync on under X11 all the time. Take x11 2d operations there is no sync to know what is a complete set of 2d operations yes no opengl equal to begin/end so a X11 2d operations application could have a half complete output no sync to refer to so a vsync and output a half done. There is example after example like this mSparks inside X11 protocol. This is why it comes impossible to get rid of tearing completely with X11 and it all due to too many defects in the protocol with areas lacking sync info..

            The new explicit sync support in wayland does not remove implicit sync memory management of Wayland.

            Application under Wayland passes a buffer up to Wayland compositor and the Wayland compositor frees the buffer it received what happens to the buffer the application still has? That right the buffer the application still has remains in existence until the application frees it and the kernel determines no other party is using it.. Yes the reverse is also true with compositor sending something application and the application frees it the compositor keeps it copy until it frees compositor frees it..

            Wayland memory management implicit sync prevents applications rug pulling another application. Yes it possible under x11 to deallocate or alter another application allocated X11 resource at any time.

            Implicit sync is not only for every frame is perfect. Implicit sync is really good with resource management so you don't have one process being able to rug pull the resources out from under a different process. Implicit sync on resource management has very low cost because resource allocation and frees are commonly not on hot paths.​

            In fact you can do every frame is perfect with careful usage of explicit sync. The problem comes doing memory/resource management with explicit sync.

            How can you make sure application executing real true buffer free should be doing the real true buffer free. Remember explicit sync the process is basically standing on it own two feet no third party to check if it right or wrong. Implicit sync you have a third party who can be checking the buffer user count and the like to decide when a buffer should truly be freed.
            Last edited by oiaohm; 15 April 2024, 06:48 AM.

            Comment


            • #46
              Originally posted by anda_skoa View Post
              I would be surprised if that has ever actually been measured.
              Its been measured and its not much. It about 1/3 of the cost of Xwayland in input latency. Gamer for you these minor values count..

              Comment


              • #47
                Originally posted by oiaohm View Post
                Implicit sync is really good with resource management
                Hmmm, so I agree maybe I came across to strongly against implicit sync.
                Both implicit/explicit have very meaningful differences, pros and cons,

                e.g. it is not a good idea to require applications to have to worry about synchronisation issues, abstracting away those issues / implicit sync is a good thing. race conditions - particularly in graphics are a development nightmare.

                But, afaik, the #1 Pro for explicit sync is performance - which is why from a display server pov, implicit is substandard.

                There is very similar arguments for opengl v vulkan, both have a place, because opengl is and will always be far more development friendly, due to most of the hard work being done by the driver, whereas there is no beating a well written vulkan application for performance - but its much easier to create a badly written, buggy, poorly performing vulkan application than an opengl one.

                Comment


                • #48
                  Originally posted by mSparks View Post
                  Hmmm, so I agree maybe I came across to strongly against implicit sync.
                  This is the danger of pushing for something and not understanding it. X11 core protocol is very much like MS-Dos memory management both are explicit sync without correct protective items. Making them highly dangerous and unstable. XACE tried to fix X11 of this but never succeed.

                  Wayland core is a lot more implicit sync this has advantage blocking Wayland from having a lot of exploits and segment fault risk. Like not being able to mess with another applications memory.

                  Originally posted by mSparks View Post
                  Both implicit/explicit have very meaningful differences, pros and cons,
                  This is the next trap there is not just 1 form of implicit or explicit sync. It also possible to have a solution that is mixed.

                  Originally posted by mSparks View Post
                  But, afaik, the #1 Pro for explicit sync is performance - which is why from a display server pov, implicit is substandard.
                  There is more to consider here. Vulkan did. Vulkan is not pure explicit sync. Everything that called immutable with vulkan when you create buffers is because the buffers you are creating are in fact managed by implicit sync. Yes you free a buffer under Vulkan this is managed by implicit sync. Vulkan and Wayland buffer/memory management in fact lines up.

                  Wayland explicit sync is about GPU and other buffer processing operations not buffer create or destory operations just like Vulkan.

                  Originally posted by mSparks View Post
                  There is very similar arguments for opengl v vulkan, both have a place, because opengl is and will always be far more development friendly, due to most of the hard work being done by the driver, whereas there is no beating a well written vulkan application for performance - but its much easier to create a badly written, buggy, poorly performing vulkan application than an opengl one.
                  This is where people straight up go wrong. People fail to notice that Vulkan is not pure explicit sync instead Vulkan is everything bare memory/buffer management explicit sync. with the memory/buffer management being implicit sync. Pure explicit sync is unstable. Multi process Memory management need to be implicit sync if it not you have problems..

                  Examples of pure explicit sync are eglstreams and X11 core protocol and both of these items are unstable and suffer from race conditions and segfaults and other issues due to using too much explicit sync.

                  Remember the Wayland explicit sync( linux-drm-syncobj-v1) is based on GBM/DMABUF sync files so does not cover creating or destroying a buffer instead leaves that to implicit sync where it makes sense to be..


                  Also note the top copyright.
                  Copyright 2016 The Chromium Authors.​
                  This is in reality is updated version of the 2016 protocol that did not take off back then because Nvidia back in 2016 would not agree to support it. Yes 2016 Nvidia was sure they could get eglstreams to work. There is a older protocol extension proposed than even 2016 that would have seen explicit sync in the Wayland protocol that was shot down by Nvidia in 2014.

                  The reality is stable form of explicit sync without Nvidia getting in the way would have been in Wayland protocol quite early on in Wayland protocol development.

                  mSparks the thing with implicit sync and explicit sync you need moderation. Correct mix of both. Too much implicit sync the result is slow. Too much explicit sync the result is unstable. There is a Goldilocks​ valve of how much explicit and implicit sync you should have for good performance and stability.

                  Yes if your agree that implicit sync is really good for resource management you should be anti core X11 protocol or you actions don't match your words mSparks.

                  Early software development created some insanely dangerous things like MS Dos and core X11 protocol.

                  Comment


                  • #49
                    Originally posted by oiaohm View Post

                    X11 core protocol is very much like...
                    this is the root if the issue tho, you dont seem to understand the design of X11.

                    X11 is absolutely unrivalled, and will remain absolutely unrivalled for what it is designed for, not least because none of the others even try.

                    X11 is designed for GUI when compute and presentation are not just isolated, but physically separated. although html5 and "remote desktop" based solutions have a fair bit of cross over into its domain they dont come close to the feature set, versatility, cross platform compatability, ease of use and performance.

                    Additionaly, and tbh quite unexpectedly for everyone.

                    That design has also proven itself to be VERY difficult to even match, let alone beat in a "desktop use" environment.

                    Not least because many of the assumptions the push to wayland were based on turned out to simply be wrong.

                    "almost as good as X11 for the desktop" is simply not good enough for a linux desktop. Linux users don't care about new shiny and cool, if its the best they are quite happy to - prefer to - keep using it for 20+ years unless something actually demonstrably better - that they need - is available. e.g. how many linux boxes have 20+ year old gpus.
                    Last edited by mSparks; 15 April 2024, 10:00 AM.

                    Comment


                    • #50
                      Originally posted by mSparks View Post
                      "almost as good as X11 for the desktop" is simply not good enough for a linux desktop. Linux users don't care about new shiny and cool, if its the best they are quite happy to - prefer to - keep using it for 20+ years unless something actually demonstrably better - that they need - is available. e.g. how many linux boxes have 20+ year old gpus.
                      wait what's so good about the x11 desktop?

                      Comment

                      Working...
                      X