Explicit GPU Synchronization Merged For XWayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • oiaohm
    Senior Member
    • Mar 2017
    • 8457

    #31
    Originally posted by Monsterovich View Post
    That's some nonsense, I've never met any workarounds, ever.
    Just go into firefox X11 copy paste code and see the 20 different windows manager work around. There are a lot of them.

    Originally posted by Monsterovich View Post
    Those servers are in no way related to any DE. I don't even have a point in discussing them, because most people use Xorg anyway.

    An Xlib compatibility layer implemented on top of the Haiku API, in order to run X11 applications on Haiku without an X server. - waddlesplash/xlibe


    This is where you are wrong again. These are not ultra common but they do exist DE integrated X11 application support and have existed for the from well before xorg and xfree86 existing

    Most people use xorg is correct. But the fragmentation has been around the edges for a very long time.

    Comment

    • oiaohm
      Senior Member
      • Mar 2017
      • 8457

      #32
      Originally posted by Monsterovich View Post
      ​Jesus f*cking Christ, why are you so stupid? Weston has his own protocols. KDE has its own, GNOME has its own, wlroots has its own, and so on.
      Is that in fact true. Weston being the reference compositor only implements what is in the Wayland standards. Weston does not in fact have it own unique protocols.


      Originally posted by Monsterovich View Post
      ​​In Xorg, you can run a panel or window manager from another DE and it will work, in Wayland this is not possible. So there is no default server, just like there is no universal server.
      first question is what you just wrote design into weston. The answer is in fact yes.

      For your weston based DEs it is possible to take panel and window manager from other weston based and mix and match. Weston is the reference server and by the Wayland developers was intended to be the universal server.

      Wlroots based wayland compositors also mix and match parts with each other. KDE has support for using Wlroots panels by the way.
      https://github.com/KDE/layer-shell-qt Wlroots panels are done by wlr-layer-shell

      So not as impossible as you are making out.

      By the way weston has been made by third party addons support wlr-layer-shell in the past.


      What you have said is not possible is in fact possible. Panels are in fact shareable between KDE and Wlroots based wayland compositors and could also include weston if people were willing to work on the plugin into weston to support wlr-layer-shell.

      Weston, KDE and Wlroots based are all design to take plugins that can extend the supported Wayland protocol. Gnome Mutter does not have this feature.

      The plugin systems of Weston, KDE and Wlroots are all very powerful and all different. Yes the teams had different ideas how the plugins should be done..

      ​​Monsterovich this is why I said you need to be truthful. When the arguement that you cannot use a panel or windows manager from a different DE under Wayland is not in fact true. You can use different panel/window manager if your solution is weston, wlroots or kde based and mix between all 3 as long as you have the plugins to allow it.

      I don't know rust based cosmic well enough to say if it could as well. Gnome with the way Mutter is designed is a problem child.

      Comment

      • MastaG
        Senior Member
        • May 2012
        • 433

        #33
        Erik is working really hard on this.
        There is even a draft MR for all the Wayland haters adding explicit sync to X11 Vulkan WSI: https://gitlab.freedesktop.org/mesa/...requests/27226

        Once this has landed my wishlist would be:
        - HDR support in Gnome/KDE with proper tonemapping
        - RT kernel support fully merged (has been a long long road)
        - The last couple amd-pstate fixes (proper boosting across all modes)
        - Wine wayland support finished (including all bells and whistles like OpenGL and Vulkan) and backported to Proton

        Comment

        • Bane
          Junior Member
          • May 2021
          • 3

          #34
          Originally posted by pharmasolin View Post
          Xorg fans, what else is wrong with a Wayland?
          Spanning multi-monitors for things like Citrix desktops. I don't believe there is anything in the protocol for handling this the last I looked (2-3 months ago).

          Comment

          • oiaohm
            Senior Member
            • Mar 2017
            • 8457

            #35
            Originally posted by MastaG View Post
            Erik is working really hard on this.
            There is even a draft MR for all the Wayland haters adding explicit sync to X11 Vulkan WSI: https://gitlab.freedesktop.org/mesa/...requests/27226
            Read closer and start cursing because you have read that wrong.

            Xwayland implementation: xorg/xserver!967 (merged)
            I see Xwayland support merged. Where is the merge for X11 bare metal.... That right not merged because X11 bare metal is still stuck on 2021 X11 protocol and this was added to X11 protocol in 2024.

            Yes you have X11 Vulkan WSI support for explicit sync when using Xwayland but not when using any other form of x.org server because the other X11 servers don't support modern enough X11 protocol to have that feature. There is no time line for when X.org servers that are not Xwayland are going to get updates to newer X11 protocol to support explicit sync.

            The first 2 digits of Xwayland and x.org versions these days is the version of X11 protocol it supports.

            Redhat developer/maintainer in charge of Xwayland does update Xwayland to current X11 protocol very often. The Oracle developer/maintainer in charge of the other x.org X11 servers just does security patches and does not do X11 version updates this is why it stuck as 2021 X11 protocol

            Erik does good work but he is not in charge if x11 will or will not support particular features.

            This is a problem I said was likely to happen and is now happening. What is happening is Xwayland and other X11 servers based off x.org are diverging from each other. Yes its very much you want the latest and greatest X11 protocol features you will be using Wayland with Xwayland because the other x.org parts do not have the personal to keep themselves on the current X11 protocol version.

            Parties trying to stay on X11 without wayland should be cursing lot of this that Wayland users are getting more X11 features than them.

            Comment

            • Alexmitter
              Senior Member
              • Mar 2019
              • 1132

              #36
              Originally posted by Monsterovich View Post
              There are essentially no standards at Wayland because DEs make their own unique protocols.
              Private protocol extensions existed in the days of Xorg Compositors too, Gnome always only worked under Mutter, KDE never worked right under anything but kwin.

              Originally posted by Monsterovich View Post
              The whole world worked like Xorg until the incompetent morons came up with Wayland.
              X11 is a protocol too, until it wasn't because to be compatible to Xorg, you need to be bug to bug compatible with how messy the protocol, its extensions and the trash around it became. Nothing stopped anyone ever to write a clean X11 display server, but its simply impossible.

              Originally posted by Monsterovich View Post
              Then throw Wayland in the trash, because just its developers refuse to make universal protocols and graphical server by default, so you have to make your own,
              Wayland is a universal protocol and its very simple, it passes buffers around. Can't get any simpler.

              Originally posted by Monsterovich View Post
              increasing fragmentation on desktop.
              In the X11 days, everyone had their own compositor with custom features tailor made for their desktop. Nothing changed.


              Originally posted by Monsterovich View Post
              Shut up, Wayland shill.
              How about you talk with Xorg developers, because they are the one that came up with Wayland after all.

              Comment

              • MrCooper
                Senior Member
                • Aug 2008
                • 635

                #37
                Originally posted by M.Bahr View Post
                By the way explicit sync is in the making and planning by the mesa devs way longer before this merge request. I think the time and effort would have been better spent focusing on wayland and not on x11.​
                It was Nvidia's choice to do this, instead of handling implicit sync in their driver as required by the existing Wayland protocol and X Present extension.

                Originally posted by dpeterc View Post
                It is not touching or fixing X11 problems, but the ones Wayland protocol failed to address properly.
                https://blogs.gnome.org/shell-dev/20...s-with-gpu-int
                This is getting ridiculous. Can everyone please stop abusing my blog post as "evidence" for unrelated points?

                The issue it describes isn't Wayland specific, it's the same with Xorg. Wayland's design allows dealing with it better than X.​

                Originally posted by ehansin View Post
                Still wrapping my head around implicit vs. explicit sync, but makes me thinks of the async stuff or event loops. Taking what I have read already here recently and then using the async/events loop analogy, I'm thinking along of lines of "implicit sync just dumps streams to the compositor for the compositor to try and sort out with all the other application/surface streams and see if it can make the best of it", whereas "explicit sync dumps to the compositor when it is ready, each application/surface can do this at their own pace and the compositor can composite frames when it wants to - if a given application/surface it not ready at any one given frame, it can just do its thing and be composited in a future frame."
                There's no direct connection between those two choices. The compositor can just as well handle client updates intelligently with implicit sync, or naïvely with explicit sync.

                Explicit vs implicit sync in the display protocols are essentially just two different mechanisms for communicating the same synchronization information between the client and display server. Explicit sync passes the information as part of the protocol, implicit sync relies on implicit synchronization objects in the kernel.​

                Originally posted by galgo View Post
                Will this make gnome completely smooth without needing triple buffering?
                It's not related to that.​​

                Originally posted by oiaohm View Post
                That right not merged because X11 bare metal is still stuck on 2021 X11 protocol and this was added to X11 protocol in 2024.
                There's simply no implementation of PresentPixmapSynced for any X server other than Xwayland yet.

                What is happening is Xwayland and other X11 servers based off x.org are diverging from each other.
                That's incorrect. "Diverging" would be developing in conflicting directions, which can't happen because Xwayland changes always land on the xserver master branch first. Xwayland is just way ahead of the rest of xserver in terms of major releases.

                Comment

                • oiaohm
                  Senior Member
                  • Mar 2017
                  • 8457

                  #38
                  Originally posted by MrCooper View Post
                  That's incorrect. "Diverging" would be developing in conflicting directions, which can't happen because Xwayland changes always land on the xserver master branch first. Xwayland is just way ahead of the rest of xserver in terms of major releases.
                  It absolutely happening. We are watching current maintainer of x.org from Oracle just adding security update after security update to the old version..





                  Just because normal xserver and Xwayland are sharing the same master this does not mean Diverging cannot happen.

                  All the Explicit GPU sync stuff only has Xwayland implementation at this stage.

                  As you look the commit list of the 3 branches you start seeing more and more cases features that should be generic not making it into server branch.

                  Like one of the clear ones of trouble that is recent is glamor is a generic part shared between server and xwayland. Why does xwayland have Michel Dänzerand glamor patches xserver does not.

                  More you look at the generic parts that should be shared between server and xwayland the more you see yes stuff is going up into master then it making it back to xwayland but then it not making it back to server. There is Diverging happening without explain because these are common shared parts having differences.

                  Yes just because there is a common master does not mean two sub branches cannot diverge into incompatible items. We have the warning signs that this is happening.

                  Its a question of time now until one of these failures to merge in uniform way on shared parts results in a incompatibility that turns up in some used software causing end users problems,

                  MrCooper lets be real you would not Linux kernel 6.8.4​ and 4.19.311​ to the same right. They are both pulling code from the same master but there is enough differences in patches between them that they are now diverged from each other. We are seeing the same kind of slow but sure diverging between xserver and xwayland. Remember git is designed to allow diverging implementations it not designed to prevent it. With git to prevent diverging implementations requires maintainers to take their job serous-ally to make sure stuff is merged to prevent too much diverging.

                  Comment

                  • M.Bahr
                    Senior Member
                    • Oct 2023
                    • 128

                    #39
                    Originally posted by MrCooper View Post
                    It was Nvidia's choice to do this, instead of handling implicit sync in their driver as required by the existing Wayland protocol and X Present extension.
                    .
                    Thanks for the info "MrCooper" (M.D.) I appreciate what you do as a developer for Linux. However back to the topic i know that this merge request for explicit sync in xwayland is from nvidia. But all the other driver teams are focusing on modern wayland. In contrast to nvidia's merge request for explicit sync in XWAYLAND! the mesa driver teams are working on explicit sync for WAYLAND! the real deal for some years now. Their plans and propositions for this date back to some years ago long before nvidia brought up this merge request. So i think we have to differentiate and be more precise when we are talking about explicit sync. Otherwise people may mistake xwayland merge requests with wayland as it already happened actually according to some confusing posts here.

                    As i already mentioned in my very first comment it doesn't make sense to me to add features to x11 due to its age and fragility. From the perspective of nvidia though adding explicit sync to xwayland (x11) makes sense as they got issues with their linux driver for wayland. They don't want or can't implement implicit sync for whatever reason. Somebody told me that nvidia's linux driver actually shares quite much the same code with their windows driver except for some linux specific adjustments. This goes so far that even bugs in their windows driver are reproducable in their linux driver. Maybe you got some more information about this topic? Thanks
                    Last edited by M.Bahr; 10 April 2024, 11:11 AM. Reason: typos

                    Comment

                    • Khrundel
                      Senior Member
                      • May 2016
                      • 327

                      #40
                      Originally posted by oiaohm View Post

                      Just think how far weston would be if all the different vendors had agreed to work on it instead of their own but if they don't want to agree todo that Wayland developers cannot force that.
                      OMG.
                      Being able to implement protocol themselves instead of working with common implementation is the main reason why wayland was created in a first place. So, replacing xorg with weston contradicts intended goal of project.

                      Comment

                      Working...
                      X