Page 28 of 29 FirstFirst ... 1826272829 LastLast
Results 271 to 280 of 283

Thread: The Wayland Situation: Facts About X vs. Wayland

  1. #271
    Join Date
    Sep 2012
    Posts
    6

    Default

    Quote 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...

  2. #272
    Join Date
    Dec 2012
    Posts
    155

    Default

    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)

  3. #273
    Join Date
    Jan 2012
    Posts
    106

    Default

    Quote 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.

  4. #274
    Join Date
    Dec 2012
    Posts
    155

    Default

    Quote 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.

  5. #275
    Join Date
    Jan 2012
    Posts
    106

    Default

    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

  6. #276
    Join Date
    Jan 2012
    Posts
    106

    Default

    Quote 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.

  7. #277
    Join Date
    Dec 2012
    Posts
    155

    Default

    Quote 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 at 06:44 PM.

  8. #278
    Join Date
    Feb 2013
    Posts
    5

    Default

    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.

  9. #279
    Join Date
    Jul 2010
    Posts
    61

    Default

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

    Quote 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.

  10. #280
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,858

    Default

    Quote 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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •