Announcement

Collapse
No announcement yet.

The Many Mutter + Shell Improvements Coming With GNOME 3.38

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

  • #11
    Does this compositor bypass for wayland and mutter mean that we will be able to use the alt+tab key combination when using a vmware vm guest?

    Comment


    • #12
      Originally posted by oiaohm View Post
      X11 server based solution you always have some unnecessary compositing even if you have no X11 compositor loaded.
      Incorrect.

      The server's implicit redirection only happens if your window's visual doesn't match the root window's visual. Otherwise the thing goes straight into the root pixmap.

      The second thing to worry about is blit vs. flip path. If the client uses dri2/3, the window is not obscured by other stuff, and its geometry matches the root window then you should get to page flip path. Which means no copies in the server whatsoever.

      Comment


      • #13
        Originally posted by oiaohm View Post

        Not quite problem is Compositor bypass does not always mean the same things. This case the X11 and Wayland mutter operational meaning is in fact different.



        No this is you believing you had a feature when you did not with X11.

        Compositor bypass under X11 only bypass the compositor work by the third party compositor on X11 does not in fact fully bypass the compositor code that is part of the X11 server itself. So yes X11 desktop compositor doing a compositor bipass is not putting output on screen with compositor bipass enabled you still have at-least 1 frame of latency and the source of that 1 frame of latency is the X11 server itself.

        Compositor bypass under Mutter Wayland solution you have zero frames of latency as this is a true full complete compositor bipass.

        The keywords from https://blogs.gnome.org/shell-dev/20...me-shell-3-38/
        without any unnecessary compositing..

        X11 server based solution you always have some unnecessary compositing even if you have no X11 compositor loaded.

        bearoso this is a feature that is not available using Mutter under X11. Yes we feature named the same under X11 and Wayland mutter being Compositor bypass the catch is the Wayland one is a superior implementation that is only possible because the X11 server is not there. In fact Xwayland that is X11 server modified to be on top of wayland can also lose the 1 frame of latency X11 suffers from due to properly bypassing compositor layers. Yes the process to modify Xwayland to run on top of wayland has been quite brutal working out how to remove X11 server internal compositing layers.

        The fix to the 1 frame of latency compositor bug is get rid of compositor on top of X11 protocol and get rid of a lot of X11 historic implementation compositing in the X11 server.

        This is another case of a feature that people have been saying why does not Wayland Compositor have this feature when X11 DE does while complete time person saying this not being aware the X11 version of it is broken and need to be re-implemented.

        You are going to see this a few times where you will see wayland compositor getting a feature that they are sounding old but it really a re-implementation better than the X11 solution could offer.
        That's complete nonsense. I assure you that Mutter/X11 is unredirecting fullscreen windows properly and it completely bypasses the compositor. X11 without Composite simply draws all windows to a shared scan-out framebuffer, which allows this. Now here's the catch: The Wayland protocol needs a compositor to put anything on the screen. So Wayland is actually the one not completely bypassing the compositor. If you bypass the compositor you're not using Wayland anymore. Of course, there's the fact that Wayland compositors subsume the window manager functionality from X11, so even though you're using a "compositor" in that sense it may not be doing any actual graphical compositing in terms of combining multiple images together.

        Comment


        • #14
          Exactly, I doubt there will ever be the possibility to allow tearing without implementing DRM leasing. And since vsync can't ever technically work without one frame lag, it's simply wrong to assume that Xorg would have to catch up in this matter. The very opposite is the truth for running fullscreen games without VRR.
          Oh, and VRR of course already works perfectly for games on Xorg with xf86-video-amdgpu.

          Comment


          • #15
            Originally posted by syrjala View Post
            The server's implicit redirection only happens if your window's visual doesn't match the root window's visual. Otherwise the thing goes straight into the root pixmap.
            You just wrote the problem.

            Root Pixmap does not exist in the wayland direct to screen. Application buffer straight to gpu then straight to output is what wayland is doing.

            Originally posted by syrjala View Post
            The second thing to worry about is blit vs. flip path. If the client uses dri2/3, the window is not obscured by other stuff, and its geometry matches the root window then you should get to page flip path. Which means no copies in the server whatsoever.
            Yes that is what is mechanically possible by dri2/3 and what a wayland compositor allows. Issue is X11 root pixmap this is a major headache. Remember X11 root pixmap if you have multi screens also mandates they are all joined into 1 huge pixmap this is also what blocks X11 servers from running screens at different clock speeds effectively. So yes X11 you are full screen on one monitor of a dual monitor setup you are still needing extra copy in X11 server.

            Originally posted by bearoso View Post
            That's complete nonsense. I assure you that Mutter/X11 is unredirecting fullscreen windows properly and it completely bypasses the compositor. X11 without Composite simply draws all windows to a shared scan-out framebuffer,
            Sharing the scan-out framebuffer or the root Pixmap requires compositor of some form. Wayland full screen buffer go straight form application to gpu to out.

            Yes that sharing the scan-out framebuffer by the X11 server due to X11 server design cost you a full frame of lag due to the way the root pixmap is coded.

            Wayland allows unsharing the output buffer completely.

            Yes both you have ignored the existence of the second compositor in the X11 server being the one that does the root pixmap mostly because it does not have the name compositor shoved on it.

            Comment


            • #16
              Originally posted by aufkrawall View Post
              Exactly, I doubt there will ever be the possibility to allow tearing without implementing DRM leasing. And since vsync can't ever technically work without one frame lag, it's simply wrong to assume that Xorg would have to catch up in this matter. The very opposite is the truth for running fullscreen games without VRR.
              Oh, and VRR of course already works perfectly for games on Xorg with xf86-video-amdgpu.
              It was the X11 lead developer who pointed out that X11 server runs with 1 frame lag on top of the lag you need to do vsync .

              VRR Except that is broken on dual screen setups with X11 and has been for ages.


              Yes that nvidia or amd broken here. Wayland is in fact designed to fix this.

              Gnome Shell + Mutter 3.37.91 Wayland 2x 60 Hz 4K displays (different brands) AMD Radeon Fury with RADV and Mesa from git....


              Fun part so is opengl vsync is not designed to deal with applications with output on multi screens running at different refresh rates.

              Getting multi monitors with different refresh rates to be able to work right does require leaving X11 and going to Wayland. Worse its going to require something special done for old opengl vsync and hopefully Vulkan applications will be able to support it.

              Its not as simple to implement VRR completely as one would think. X11 server implementation of VRR is half done. Its only half done because it does not support multi monitor VRR with monitors out of sync. Yes one monitor running at 60 and another running at 120 is a really good test.


              In the X11 session, we composite the whole X11 screen at once, without any separation between monitors. This remains unchanged, with the difference being where scheduling takes place (as mentioned in an earlier point). The improvements described here are thus limited to using the Wayland session.

              It is really easy to ignore that X11 VRR support is only half implemented and opengl vsync is not design for a fully implemented multi monitor clockspeed this include VRR running at different clock-speeds.

              Think about it for one min you are doing a presentation you notes are on your laptop . Of course you want the laptop screen to go to the most power effective clock speed the projector will be connect to different power in most cases.

              Comment


              • #17
                Originally posted by oiaohm View Post
                In the X11 session, we composite the whole X11 screen at once, without any separation between monitors. This remains unchanged, with the difference being where scheduling takes place (as mentioned in an earlier point). The improvements described here are thus limited to using the Wayland session.
                This is describing a limitation with respect to gnome on X11, you can have multiple monitors on X11 with different refresh rates.

                Comment


                • #18
                  Originally posted by Space Heater View Post
                  This is describing a limitation with respect to gnome on X11, you can have multiple monitors on X11 with different refresh rates.
                  Yes you can plug in different monitors with different refresh rates. Big thing you miss its not just gnome. Vsync in general on X11 issue.



                  Yes you plug in multi monitors with different refresh rates 1 is choose as the refresh rate to use. This results in 2 different ways of failure.

                  1) the slowest is chosen so the faster looks like crap to what it should.
                  2) the fast is chosen this one now eats your battery because you are now prepping up more display frames on the slow monitors that will never be displayed also causing more GPU load so effecting general performance,

                  Reality is Space Heater you just said works for me without in fact looking if it working correct. It does not matter if you have gnome or not X11 handles multiple monitors with different refresh rates badly. The idea that is a gnome limitation as wrong. KDE, Gnome and raw X11 screws up with multi monitors with different refresh rates.

                  Yes fixing this problem means we have to work the following
                  1)How to correctly deal with a application with a window part on different screens that different refresh rate screens.
                  2)Telling applications that full window is only on 1 screen only that screen Vsync rate.
                  3)Finally dealing with applications that change from 1 to 2 and back again without goofing anything.

                  The hack X11 and DE have been using has meant they have got to avoid solving the above problem.

                  One of the horrible parts is X11 mandating that all screens be merged into a single image this means that single image has to have a single clock rate for screen capture. This is one of the changes of Wayland. Each display under wayland can get its own image so when you screen capture you can collect them all up at that instant so allows them all to run at different clock speed.

                  Comment


                  • #19
                    Originally posted by oiaohm View Post
                    Reality is Space Heater you just said works for me without in fact looking if it working correct. It does not matter if you have gnome or not X11 handles multiple monitors with different refresh rates badly.
                    I have multiple monitors with different refresh rates, I'm aware X11 doesn't handle it perfectly, but they clearly are running at different rates. Pretending that because X11 has obvious limitations with multiple monitors is somehow equivalent to what gnome was previously doing with a single refresh rate across multiple monitors is intellectually dishonest if not outright lying.

                    Comment


                    • #20
                      Originally posted by Space Heater View Post
                      I have multiple monitors with different refresh rates, I'm aware X11 doesn't handle it perfectly, but they clearly are running at different rates. Pretending that because X11 has obvious limitations with multiple monitors is somehow equivalent to what gnome was previously doing with a single refresh rate across multiple monitors is intellectually dishonest if not outright lying.
                      When you get to application side of X11 for the like of opengl vsync you keep on getting single refresh rate across multiple monitors even that they are running as different. This in fact go back to the X11 protocol limitation that all displays have to be in a single image.

                      Yes the GPU CRT output from the driver is rendering to the screen at different refresh rates. Are the frames for output rendering to the different displays by X11 being provided at different frame rates. The answer is no.

                      The reality is the X11 server is not doing different rates. The drivers behind X11 server back is and that is what you are seeing.

                      So your idea that the monitors are running at different rates the reality it not the X11 server doing that. If X11 server has it way all monitors will be running at the exact same rate and that is how its internal logic works. So either you are rendering too many frames for your slow monitors or not enough frames for your fast monitors.

                      If you manage to use some of the old drivers with x.org X11 server you will find that no you don't have different Hz for different connected monitors because they will not mask over x.org server limitation that comes from X11 protocol limitations.

                      There a hack in the drivers that X11 uses that makes something look to work that does not work at all. Yes the reality you don't have monitors at different HZ actucally supported by x.org X11 server you are in fact depending on drivers to accept either too many frames or too little frames when monitors are on different clock rate.

                      Comment

                      Working...
                      X