Announcement

Collapse
No announcement yet.

Explicit GPU Synchronization Merged For XWayland

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

  • #41
    Originally posted by Khrundel View Post
    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.
    The stated goal by the Wayland core developer was to implement something that fixed the core issue with X11. Do note X11 protocol lets you go and implement it yourself as well.

    You will find that the state goal you have just claimed was not a stated goal of early Wayland. The choice was provided where they could have choose to work on Weston or work on their own. Gnome and KDE choose to work on their own.

    The plugin system of weston makes no sense if it was not designed to be a universal yes parties have implemented like wlroots panels and other things using weston plugins.

    Replacing x.org with weston is not in contradicted the intended goal of the Wayland project. Providing the offer with the wayland protocol like what existed on X11 protocol that you can build your own may not have been the wise choice. But provide that option does not mean that the intention was at first for it to be branching in all the directions it has.

    There is a difference between the stated goals of Wayland and what happened.

    Comment


    • #42
      Originally posted by MrCooper View Post
      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.​
      Okay, thanks for the heads up. I'm slowly trying to wrap my head around all the deeper-level graphics stuff. Sometimes means some misguided thinking, more just part of the learning process. Still a little over my head, but that is part of the process. Just found a page in the kernel docs called "Buffer Sharing and Synchronization (dma-buf)" under the "Driver implementer's API guide" section. Will do some reading. I think I am kind of getting at least the gist of things, at least at a *very basic* level. Just skimmed through the Collabora. Mostly over my head, but help. Thanks again!

      Comment


      • #43
        Originally posted by oiaohm View Post

        The stated goal by the Wayland core developer was to implement something that fixed the core issue with X11.
        Sure. And one of the "corest" issue with x11 is an existence of xorg in the stack, which brings almost no useful functions but requires a tons of babysitting. Haven't you read this statement in their rationale? Every programmer had met a situation when some library does in project some petty function while requiring a bunch of support code, so after another struggle with it he decides "why don't rewrite this feature myself?".
        Xorg could look fine for some bootleg DE developer, almost everything already here, you can get some existing components, write some configs and all will work almost without issues. But to somebody who tries to develop a solid stable DE all these features like "every program can take any DS responsibility" are another source of disturbance which can lead to falling apart.
        Originally posted by oiaohm View Post
        Do note X11 protocol lets you go and implement it yourself as well.
        No, it doesn't. And no need to. If you are already breaking compatibility, why not to develop protocol which suits modern use cases?
        You will find that the state goal you have just claimed was not a stated goal of early Wayland. The choice was provided where they could have choose to work on Weston or work on their own. Gnome and KDE choose to work on their own.
        Sure. They have evaluated pros and cons of usage of shared code and have chosen not to. That is pretty smart, when you have simple protocol.
        The plugin system of weston makes no sense if it was not designed to be a universal yes parties have implemented like wlroots panels and other things using weston plugins.
        Nobody forbids you from using weston in your project and I believe samsung was using it in production. That doesn't mean it was intended as single implementation.
        Their intention was built into protocol itself: barest minimum of features hints that goal: еvery server should be able to implement in independently.

        Single wayland DS is dumbest idea ever: you've just got rid of monstrous blob which could break everything and developed nice and compact protocol which allow clients to do their GUI while leaving DS free to implement anything as it wants. Why anybody would choose to create another "fits for all" blob with complicated API to control it?

        The whole Idea of "lets gather together and concentrate our efforts" works in child cartoons only. That is what wayland critics can't understand. Every another developer added to project brings less utility and this works for projects with single well-defined set of functions. When new developer does not implement existing set of functions but brings just another feature nobody asked because he needs it within his experimental DE, his work will slowdown project's development.

        Comment


        • #44
          Originally posted by Khrundel View Post
          Their intention was built into protocol itself: barest minimum of features hints that goal: еvery server should be able to implement in independently.
          That is a side effect of a early stated goal. Prevent Wayland protocol turning into X11 protocol stack of random added on garbage has implemented a strict policy that any protocol extension has to prove it functionality. You have to remember X11 protocol end up with a stack of useless items added to it that people put into the protocol without checking if they were really a good idea.


          This is a classic example. Xprint is lets just duplicate what IPP is https://dl.acm.org/doi/pdf/10.1145/338183.338184 ISO 10175(is kind of a early name for IPP) without any really good reason and even then forward everything we do to IPP so just adding extra complex for no good reason. Of course there are worst features that were deleted from X11 server where they were added to x11 server code and they never worked..

          Remember that any new functionally being added to Wayland core protocol has to prove it functionality goal is still in effect and this is what makes some of the debates about adding Wayland features take so long as the checking that the design is sane end up finding design flaws requiring the feature to be redone over and over again until in the end it agreed to be right.

          This is the problem the early stated goals of Wayland are not for every server should implement their own thing. Side effect of keeping the Wayland protocol clean and compact makes everyone who already had massive complex X11 compositor dealing with stack of X11 quirks to say this looks simple to implement in our existing X11 compositor instead of using someone else solution....

          There are side effects to the Wayland stated core goals and most of those core goals are still in effect.

          Originally posted by Khrundel View Post
          They have evaluated pros and cons of usage of shared code and have chosen not to. That is pretty smart, when you have simple protocol.

          See problem even you. A simple cleanly design protocol if that you implement this goal one of the annoy side effects is people getting the idea to implement their own version instead of using the provided shared solution. This is why was not a goal of the Wayland project to have this happen with fragmentation but a side effect of a core goal. This is just annoying side effect of effort to keep Wayland protocol clean of garbage so it does not turn into X11 protocol that required at one point a developer spending 10 years just deleting stuff..

          Of course as Wayland protocol grows the cost of doing own thing increases and this in theory should encourage smaller items do joint development. Bad luck for Wayland developers is that most people doing joint development have gone wlroots instead of Weston. Lets say wlroots had not appeared as Wayland compexity grew many parties would have been forced into Weston as the option and we would not be looking down the same fragmentation problem.

          This is more what can go wrong has.

          Last edited by oiaohm; 11 April 2024, 08:19 AM.

          Comment


          • #45
            Originally posted by oiaohm View Post

            It absolutely happening. We are watching current maintainer of x.org from Oracle just adding security update after security update to the old version..
            So? Backporting fixes isn't "diverging".

            Just because normal xserver and Xwayland are sharing the same master this does not mean Diverging cannot happen.
            Yes it does, since the non-Xwayland-specific code in the Xwayland binary is shared with the other DDXen.

            All the Explicit GPU sync stuff only has Xwayland implementation at this stage.
            One DDX supporting a feature other DDXen don't isn't divergence. There's no incompatibility.

            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.
            You're losing me. Xwayland uses the same glamor code as the rest of xserver, it's not possible for any glamor patches of mine to be in Xwayland but not in xserver.

            Look, I explicitly designed the Xwayland-only release process to prevent the issue you're worried about. So can we please stop wasting time on this? Thanks.

            Comment


            • #46
              Do we really have to entertain trolls with another wayland vs x11 discussion? Again?

              My dude, you don't like Wayland? Want to keep using x11, to get new features? GO FOR IT, the code is right there! write something, make a merge request. Hire someone to do it for you, no one will stop you.

              The rest of us will use Wayland while you shout at the clouds.

              Comment


              • #47
                Originally posted by MrCooper View Post
                You're losing me. Xwayland uses the same glamor code as the rest of xserver, it's not possible for any glamor patches of mine to be in Xwayland but not in xserver.
                You really need to look.

                For ALUs which may leave the alpha channel at values other than 1.0. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1615 v2: * List safe ALUs instead of unsafe ones (cherry picked from commit e5a3f3e84dbbc1484d56d9a64f14508a4bf8af19)

                This patch is in xwayland but is not in the server branch.

                Yes look at the server-21.1-branch and they are missing.

                The patches from Peter Hutterer that should both side of those 3 glamor patches exist in both branches but the 3 glamor patches are only in one branch.

                So the maintainer of the xserver branch has not been merging your patches there is a divergence you have not noticed in the glamor code.




                Really you need to stop claiming this is not happening. Did you have a disagreement with the party who is maintaining the server branch.

                You are not the only developer who working what is a shared part between all who patches are making it into the xwayland branch and not into the server branch.

                Comment


                • #48
                  Originally posted by oiaohm View Post
                  That is a side effect of a early stated goal. Prevent Wayland protocol turning into X11 protocol stack of random added on garbage has implemented a strict policy that any protocol extension has to prove it functionality. You have to remember X11 protocol end up with a stack of useless items added to it that people put into the protocol without checking if they were really a good idea.
                  Oh, just stop it.
                  The goal was to be able to implement simple functions themselves. All your fantasies is just meant to not to notice an elephant in the room. There is nothing wrong with "random added garbage" ie "lots of convenient functions" unless your intention is to make independent implementations easier to create.

                  Btw, even their lexicon tells you about their main goal. Wayland is main artifact of development and it is a protocol while weston is just a reference implementation. And it wasn't only candidate to replace xorg, there was another, Mir. And it was a display server with its own client protocol, which wasn't mentioned much. An idea of a new alternative display server have lost the competition. Some time ago mir was transformed to DS for wayland and still nobody want to use it, even smaller projects prefer implement it semi-independently using wlroots. And, another btw, you can suspect some "malicious" intention from gnome or kde, but there is wlroots. Even smaller teams prefer to write wayland support library from scratch instead of using and improving weston. This tells about sanity of keeping some common display server in stack.

                  I mean every interface point brings some additional complexity and limits freedom of internal architecture. When you have simple enough client protocol it is easier to implement this protocol instead of maintaining DS and its additional interface from both sides.

                  Comment


                  • #49
                    Originally posted by Khrundel View Post
                    Btw, even their lexicon tells you about their main goal. Wayland is main artifact of development and it is a protocol while weston is just a reference implementation. And it wasn't only candidate to replace xorg, there was another, Mir. And it was a display server with its own client protocol, which wasn't mentioned much.

                    MIR was mentioned a lot back in the day. The reality is the Canonical choice of CLA and GPLv3 fairly much shot itself in foot with Mir.


                    Guess how many X11 windows managers/X11 compositors projects were GPLv3 accepting even up to the current day.

                    The reality is Mir changing to a Wayland compositor and fixed up CLA did not change the fact it was licensed wrong to bring the normal X11 Windows manager developers in.

                    wlroots is MIT Weston is MIT X.org Xserver is MIT. Notice a kind of trend here. The reality here is MIR was not going to be competition it was not licensed right to be competition for the core role. Having Canonical marketing department Mir just made a lot of noise about it presence.

                    Originally posted by Khrundel View Post
                    Even smaller teams prefer to write wayland support library from scratch instead of using and improving weston.
                    The fun part is this behavior with Wayland is a repeat. When the X11 protocol was fairly new and still fairly simple it was still common to see all the different Unix vendors to write their own X11 server than use the reference X11 server as well. This is history that has repeated over and over again while a protocol is simple you end up with a stack of competing implementations that is just the way it is.

                    While the wayland protocol is still simple enough to implement we should expect to see fragmentation. But remember the Wayland protocol with extensions is progressively growing and applications expect more of those extensions so the complexity to make Wayland solution is growing. At some point using a common core will come the only practical way if you are not a large project to implement Wayland. Then even for large projects there is going to be pressure to use the common core and that is if Wayland follows the same live cycle X11 protocol did so far it seams to be following exactly the same path.

                    Comment


                    • #50
                      IMHO Wayland is already on a different path from X11, just like Vulkan is on a different path from OpenGL, because it isn't as naive as its predecessor project, even if for no other reason...

                      there is people thinking it up with an eye on security by design, so it shouldn't fall into the same horrible traps that made an X11 protocol replacement so direly necessary

                      there is governance so extensions aren't added to core without being necessary and well designed and proven as an extension somewhere first (with competing implementations actually serving this purpose well, such as gamescope implementing draft version protocol extensions for HDR but totally willing to replace it once a final design is agreed on), all the while signaling this draft state well enough that nobody walks into a trap without prior warni

                      there is also nowadays a wider base of commongly agreed on requirements for desktops, workstations, servers, render farms, mobile, iot, vr, etc partly born from FOSS software development model winning hearts and minds all around the world and different industries (see Automotive Grade Linux, Academy Software Foundation, etc)

                      also the issues of the past are well known and the devs that worked on X.org are present in wayland development, so it's much less likely they'll be repeated now

                      Comment

                      Working...
                      X