Announcement

Collapse
No announcement yet.

The Wayland Situation: Facts About X vs. Wayland

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

  • Originally posted by farnz View Post
    Exactly that. If you do it right, you can implement a proxy Wayland server that just passes things through unmodified if your upstream compositor supports the "RenderManager" extension internally, and that renders to a wl_buffer (using Cairo, or EGL/OpenVG, or EGL/OpenGL ES 3, or magic fairies, or whatever) if it doesn't.

    Then, I only need to implement core Wayland in my compositor to work with apps that need your RenderManager; the app uses your proxy to convert svg_render_buffers to wl_buffers that I can use. If I see advantages to rendering svg_render_buffers myself, I can do that, too).

    Note that one of many reasons to not provide a rendering protocol in Wayland is to avoid the pain X11 can get into where a client asks it to spend lots of time rendering something - X appears to take lots of CPU, while the client takes very little, because X is doing all the rendering work on behalf of the client. A separate RenderManager proxy helps with this, especially if you layer it as client->per-client RenderManager->compositor, as it's a specific client's RenderManager that starts to eat CPU, and you can thus identify the culprit.

    It's also true here that (because of the way Wayland IPC is designed), you can experiment with extensions like a RenderManager without having to make the compositor aware that such an extension even exists- just write a proxy that translates your extension back into core Wayland protocol (e.g. by doing the rendering work needed to transform a svg_render_buffer to a standard wl_buffer). If the extension turns out to be incredible, many compositors will implement it internally, with no need for the RenderManager proxy. If it's useful, people will run it where it's needed, and eventually, it'll be an extension that people just assume is available.
    Beautiful...

    Comment


    • Well, there is news about X vs Wayland.

      Currently Wayland can't be benchmarked because Mesa egl doesn't support eglSwapInterval(0) (ie: when swapping, you won't wait the frame to be displayed).
      But that's about to be changed. Soon it will be supported.

      With an experimental support of eglSwapInterval(0), tests with glmark2 ( a high fps benchmark ) shows that Wayland process frames faster than X.

      This difference in time for processing frames is about 0.250ms Wayland vs X for me and my hd4000 (My tests are not reliable, there were made with different Mesa version, but someone reproduced the results and got a similar gain with same Mesa version). As an indication, some of the tests took less than 0.250ms per frame on Wayland (fps doubled, but as I say it is a high fps benchmark)

      While these tests can't be taken into account until everything is merged and tests are done with other benchmarks and on other GPUs, it would indicate that Wayland process frames faster than X. For games (low fps compared to glmark2), it won't change the fps. But it would indicate that Wayland would enhance battery life when doing light work on our computer (surfing, ...) since CPU/GPU would have more idle time.


      Note to Michael: Please don't use these numbers for a news, but you can make yours if you want. (contact me then to get the modifications to do)

      Comment


      • Originally posted by mannerov View Post
        Well, there is news about X vs Wayland.

        Currently Wayland can't be benchmarked because Mesa egl doesn't support eglSwapInterval(0) (ie: when swapping, you won't wait the frame to be displayed).
        But that's about to be changed. Soon it will be supported.

        With an experimental support of eglSwapInterval(0), tests with glmark2 ( a high fps benchmark ) shows that Wayland process frames faster than X.
        So what was the glmark2 score in your case for Wayland vs. Xorg? Also sync to vblank is quite conveniently not supported for nouveau, and I'm getting glmark2 results not in Wayland favour there.

        Comment


        • Originally posted by ssvb View Post
          So what was the glmark2 score in your case for Wayland vs. Xorg? Also sync to vblank is quite conveniently not supported for nouveau, and I'm getting glmark2 results not in Wayland favour there.
          fps are not really relevant, so I tell frame time: (Please consider it is quite noisy)

          On the first tests:
          X (intel hd4000 sna, Mesa 9.1.4) | Wayland (intel hd4000 Mesa git)
          0.575ms | 0.264ms
          0.509ms | 0.249ms
          0.578ms | 0.182ms
          0.587ms | 0.186ms
          0.602ms | 0.190ms
          ...
          1.387ms | 1.124ms
          ...

          Maybe when your nouveau issues are fixed you'll get good results too.

          Comment


          • A recent glmark2 snapshot from bzr, where they added the wayland backend (the 2012.12 version id is bogus in logs). The same hardware, the same version of Mesa. NOUVEAU is reclocked for best performance. Running glmark2 in its default 800x600 window. The desktop resolution is 1920x1080.

            Proprietary NVIDIA X11 driver (with XRENDER compositing in XFCE):
            Code:
            =======================================================
                glmark2 2012.12
            =======================================================
                OpenGL Information
                GL_VENDOR:     NVIDIA Corporation
                GL_RENDERER:   Quadro NVS 140M/PCIe/SSE2
                GL_VERSION:    3.3.0 NVIDIA 325.15
            =======================================================
            [build] use-vbo=false: FPS: 755 FrameTime: 1.325 ms
            [build] use-vbo=true: FPS: 724 FrameTime: 1.381 ms
            ...
            =======================================================
                                              glmark2 Score: 482 
            =======================================================
            Proprietary NVIDIA X11 driver (without compositing):
            Code:
            =======================================================
                glmark2 2012.12
            =======================================================
                OpenGL Information
                GL_VENDOR:     NVIDIA Corporation
                GL_RENDERER:   Quadro NVS 140M/PCIe/SSE2
                GL_VERSION:    3.3.0 NVIDIA 325.15
            =======================================================
            [build] use-vbo=false: FPS: 926 FrameTime: 1.080 ms
            [build] use-vbo=true: FPS: 904 FrameTime: 1.106 ms
            ...
            =======================================================
                                              glmark2 Score: 582 
            =======================================================
            Free NOUVEAU X11 driver (with XRENDER compositing in XFCE):
            Code:
            =======================================================
                glmark2 2012.12
            =======================================================
                OpenGL Information
                GL_VENDOR:     nouveau
                GL_RENDERER:   Gallium 0.4 on NV86
                GL_VERSION:    OpenGL ES 3.0 Mesa 9.1.6
            =======================================================
            [build] use-vbo=false: FPS: 499 FrameTime: 2.004 ms
            [build] use-vbo=true: FPS: 529 FrameTime: 1.890 ms
            ...
            =======================================================
                                              glmark2 Score: 388 
            =======================================================
            Free NOUVEAU X11 driver (without compositing):
            Code:
            =======================================================
                glmark2 2012.12
            =======================================================
                OpenGL Information
                GL_VENDOR:     nouveau
                GL_RENDERER:   Gallium 0.4 on NV86
                GL_VERSION:    OpenGL ES 3.0 Mesa 9.1.6
            =======================================================
            [build] use-vbo=false: FPS: 526 FrameTime: 1.901 ms
            [build] use-vbo=true: FPS: 546 FrameTime: 1.832 ms
            ...
            =======================================================
                                              glmark2 Score: 408 
            =======================================================
            Wayland/Weston 1.2 (compositing is mandatory by design)
            Code:
            =======================================================
                glmark2 2012.12
            =======================================================
                OpenGL Information
                GL_VENDOR:     nouveau
                GL_RENDERER:   Gallium 0.4 on NV86
                GL_VERSION:    OpenGL ES 3.0 Mesa 9.1.6
            =======================================================
            [build] use-vbo=false: FPS: 400 FrameTime: 2.500 ms
            [build] use-vbo=true: FPS: 424 FrameTime: 2.358 ms
            ...
            =======================================================
                                              glmark2 Score: 325 
            =======================================================
            In this particular setup Wayland seems to show the worst performance. More results from different hardware are surely welcome

            Comment


            • Originally posted by mannerov View Post
              fps are not really relevant, so I tell frame time
              How so? Actually I would say that the results with different versions of Mesa are not really relevant.

              Comment


              • Originally posted by ssvb View Post
                How so? Actually I would say that the results with different versions of Mesa are not really relevant.
                As I said: "My tests are not reliable, there were made with different Mesa version, but someone reproduced the results and got a similar gain with same Mesa version"

                Maybe your tests would be better with eglSwapInterval(0) working: without, eglSwapBuffers waits until the last frame is being displayed by Weston and Weston launches a callback to tell it to EGL.
                EDIT: Moreover glmark2 calls a functions that wait at least an event comes (here: the event 'frame displayed') before redrawing, that impacts performance and is wrong for eglSwapInterval(0) (no frame event will never come, so the benchmark stops waiting an event like keyboard, ...). My benchmarks were done with wl_display_dispatch (in flink() ) replaced by wl_display_roundtrip.
                Last edited by mannerov; 08-12-2013, 06:44 PM.

                Comment


                • I have an questin. I hope people in intrest still readind this thread and will be able to give me straight anwswer.

                  Why does Weston, require KMS/GEM drivers ? Why does other Wayland compositors are made in a way they need KMS/GEM drivers ? Wayland doesn't need such drivers to work (as far as I know, just compisters that are it's client).

                  It seems like huge overlook and reason that Wayland will have very slow adoption. NVIDIA and AMD doesn't want to make drivers that are using GEM (and rightfully so, they have their own optimized memory managers that are deisgned with their hardware in mind, which are far more efficient and faster, than generic apprach like GEM ever be).

                  So why enforce such drivers ? Why not allow binary GPU drivers ?

                  To be frank, looking at it now, Wayland might as well as not exist for me. Without binary drivers from NVIDIA or AMD there is nothing to look after. And those two won't make binary drivers for Wayland, unless Wayland changes something to do not enforce KMS/GEM.

                  Comment


                  • Originally posted by iniside View Post
                    Why does Weston, require KMS/GEM drivers ?
                    It doesn't.

                    Originally posted by iniside View Post
                    Why not allow binary GPU drivers ?
                    It does.

                    There are just a couple basic mechanisms needed, and nobody has done the work to get binary driver providers and wayland people to work together to make that happen.

                    Comment


                    • Originally posted by iniside View Post
                      I have an questin. I hope people in intrest still readind this thread and will be able to give me straight anwswer.

                      Why does Weston, require KMS/GEM drivers ? Why does other Wayland compositors are made in a way they need KMS/GEM drivers ? Wayland doesn't need such drivers to work (as far as I know, just compisters that are it's client).

                      It seems like huge overlook and reason that Wayland will have very slow adoption. NVIDIA and AMD doesn't want to make drivers that are using GEM (and rightfully so, they have their own optimized memory managers that are deisgned with their hardware in mind, which are far more efficient and faster, than generic apprach like GEM ever be).

                      So why enforce such drivers ? Why not allow binary GPU drivers ?

                      To be frank, looking at it now, Wayland might as well as not exist for me. Without binary drivers from NVIDIA or AMD there is nothing to look after. And those two won't make binary drivers for Wayland, unless Wayland changes something to do not enforce KMS/GEM.
                      They either need to have KMS / GEM support (unlikely), use a wrapper library that was discussed by the Wayland developers that allows them to say "We have KMS / GEM support" when they actually don't, but are in reality handling KMS / GEM style functions within the driver so it doesn't matter.

                      Also the only reason no-binary-drivers should be a "killer" for you is if you only have Nvidia hardware... Intel OSS driver is your only option for them, Radeon is right up there with Fglrx at this point if you have Kernel 3.11 and Mesa 9.2 (which you will by the time youre using Wayland), even if you have GCN you should be fine by then.

                      Comment


                      • Originally posted by iniside View Post
                        I have an questin. I hope people in intrest still readind this thread and will be able to give me straight anwswer.

                        Why does Weston, require KMS/GEM drivers ? Why does other Wayland compositors are made in a way they need KMS/GEM drivers ? Wayland doesn't need such drivers to work (as far as I know, just compisters that are it's client).

                        It seems like huge overlook and reason that Wayland will have very slow adoption. NVIDIA and AMD doesn't want to make drivers that are using GEM (and rightfully so, they have their own optimized memory managers that are deisgned with their hardware in mind, which are far more efficient and faster, than generic apprach like GEM ever be).

                        So why enforce such drivers ? Why not allow binary GPU drivers ?

                        To be frank, looking at it now, Wayland might as well as not exist for me. Without binary drivers from NVIDIA or AMD there is nothing to look after. And those two won't make binary drivers for Wayland, unless Wayland changes something to do not enforce KMS/GEM.
                        I'm sorry, but you don't really know what you're talking about. Unfortunately, that's par for the course when it comes to people discussing Wayland.

                        Weston needs to be able to do modesetting, because it's taking the place of X which used to do that work.

                        Modesetting means banging directly on the hardware bits and is highly hardware dependent. Which means each GPU driver needs to provide the code to do that.

                        X used to work with userspace code modesetting (in the DDX X.org drivers) but that was a messy hack. New OSS drivers all provide their driver code directly in the kernel. Because that's the only sane place for this code, the nvidia and amd proprietary drivers also place their modesetting code inside the kernel. (in their proprietary kernel modules)

                        Weston gets rid of the nasty hack that no one was really using anymore anyway (x drivers) and requires kernel based modesetting, which everyone already has on linux. INCLUDING THE PROPRIETARY DRIVERS! It may indeed be a problem on BSDs/Solaris/etc. where the OSS drivers are too old, though.

                        Weston only supports the OSS KMS api currently, because that's the only one that they can. The proprietary drivers install their own support into X. Similarly, they need to do the exact same thing in Weston. They already have kernel modesetting capabilities, they just need to wire up everything correctly. Note: they had to do the exact same thing to X. That's why whenever X updates to a new version you have to download a new proprietary driver to work with it. The exact same situation will be necessary with Weston, only it should be simpler for the proprietary drivers than before because there's none of the messy stuff that X brought into the situation to deal with.

                        In short - Weston absolutely allows for proprietary drivers to run, and it won't be difficult for them to support. However, it is something they will have to support themselves, unless they plan on opening up the specs to their hardware so that the open source coders know which hardware bits to bang on. Exactly the same as X. We're just still waiting on the proprietary drivers to actually support it, which is fair enough since there still aren't any distros trying to use it, which means their customers still don't need that support yet. When they do need it, Nvidia and AMD should be able to provide it easily.

                        Comment


                        • Originally posted by Ericg View Post
                          They either need to have KMS / GEM support (unlikely), use a wrapper library that was discussed by the Wayland developers that allows them to say "We have KMS / GEM support" when they actually don't, but are in reality handling KMS / GEM style functions within the driver so it doesn't matter.

                          Also the only reason no-binary-drivers should be a "killer" for you is if you only have Nvidia hardware... Intel OSS driver is your only option for them, Radeon is right up there with Fglrx at this point if you have Kernel 3.11 and Mesa 9.2 (which you will by the time youre using Wayland), even if you have GCN you should be fine by then.
                          Well, I'm not sure if the open source drivers will be good enough if I want play games or work with Maya/Modo. And yes, I have GCN (Radeon HD7850).

                          I'm sorry, but you don't really know what you're talking about.
                          Of course I don't. That's why I asked.

                          I'm curious about other things. What about other Wayland Compositors ? Like KWin or Mutter or anything else that might popup in future. Does NVIDIA and AMD had to adapt their drivers on per compositor basis ? Or I have misunderstrand something here ? Or meant Wayland not Weston ?

                          Comment


                          • Originally posted by iniside View Post
                            I'm curious about other things. What about other Wayland Compositors ? Like KWin or Mutter or anything else that might popup in future. Does NVIDIA and AMD had to adapt their drivers on per compositor basis ? Or I have misunderstrand something here ? Or meant Wayland not Weston ?
                            Course not. Do drivers need to support individual compositors under X?

                            Sure, other compositors may expose driver bugs. But once you support the Wayland Protocol and all its required dependencies (EGL-- the same as Mir-- and one extra OpenGL extension) you should be fine


                            As far as Radeon + future performance... Games you should be pretty good on, honestly. Maya / Modo, maybe maybe not. I really don't know for that one.

                            Comment


                            • "Wayland's main goal is that no matter the system load, no matter what is going on, it will be flicker free, tear free, and flash free."

                              I'm looking forward for Wayland and newly added AMD GPU fan-profiles!

                              Comment


                              • Have NVIDIA solved this?

                                A past discussion where NVIDIA James Jones alerts Kristian about DDX on xwayland and xwayland becoming its own DDX (i huge problem since the NVIDIA way of doing that would be from the kernel module)
                                http://lists.freedesktop.org/archive...ch/041534.html
                                Then in 3.46 nvidia landed EGL extensions but could not yet solve KMS (no kms no wayland support on most DE's), So, will NVIDIA have HW accelerated xwayland? how can they solve that?

                                Comment

                                Working...
                                X