The Wayland Situation: Facts About X vs. Wayland

[ssvb]

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):

=======================================================
    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):

=======================================================
    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):

=======================================================
    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):

=======================================================
    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)

=======================================================
    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

[mannerov]

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.

[ssvb]

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.

[mannerov]

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)

[nachokb]

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

[farnz]

So if a compositor advertises, say, "svg_render_buffers", it's the compositor who gets the responsibility to do the actual rendering right? This could get extracted (that's my idea of a RenderManager) to be used by many compositors... but the important part is that the payload data between the client and the compositor is lightweight enough (and semantically rich enough*) to enable efficient remoting.

* what curuga said "sending text as text"... it's not just about bandwidth, but compressing text with a lossy DCT codec should be a sin :P... although I'm completely opposed to adding a drawing API to the wayland protocol

-- nachokb

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.

[farnz]

that's interesting... so can one running instance of a compositor support windows with different buffers of different types? can a compositor advertise multiple types?

so right now a client (e.g. a toolkit) renders to an EGL buffer or a Pixman buffer depending on what is advertised by the compositor right?



that sounds good... I can imagine this capability will be used in the future...

A compositor can indeed advertise different buffer types; note that for pixel buffers, as used in core Wayland, there is no difference between EGL and Pixman - both provide you with a lump of pixels laid out in memory. However, a compositor could (for example) advertise support for 32-bit ARGB, RGB, AYUV and YUV buffers in various pixel layouts, permitting a movie player to use a hardware decoder to decode into a buffer the compositor can use directly, as well as permitting Pixman and EGL based renderers to draw directly to buffers the compositor can handle. You can also easily imagine a compositor advertising support for high bit depth buffers for professional screens (e.g. 16-bits per channel ARGB).

[nachokb]

There is nothing preventing you defining (say) an svg_render_buffer, and providing a library that permits a client to always use svg_render_buffers, even when the compositor does not support said interface (when the compositor supports it, pass the client ops through to the compositor; when it doesn't, draw into wl_buffers and pass those to the compositor). If there are genuine efficiency gains from doing that, go for it!

So if a compositor advertises, say, "svg_render_buffers", it's the compositor who gets the responsibility to do the actual rendering right? This could get extracted (that's my idea of a RenderManager) to be used by many compositors... but the important part is that the payload data between the client and the compositor is lightweight enough (and semantically rich enough*) to enable efficient remoting.

* what curuga said "sending text as text"... it's not just about bandwidth, but compressing text with a lossy DCT codec should be a sin :P... although I'm completely opposed to adding a drawing API to the wayland protocol

-- nachokb

[nachokb]

the compositor advertises that it can support.

that's interesting... so can one running instance of a compositor support windows with different buffers of different types? can a compositor advertise multiple types?

so right now a client (e.g. a toolkit) renders to an EGL buffer or a Pixman buffer depending on what is advertised by the compositor right?

There is nothing preventing you defining (say) an svg_render_buffer, and providing a library that permits a client to always use svg_render_buffers, even when the compositor does not support said interface (when the compositor supports it, pass the client ops through to the compositor; when it doesn't, draw into wl_buffers and pass those to the compositor). If there are genuine efficiency gains from doing that, go for it!

that sounds good... I can imagine this capability will be used in the future...

[farnz]

does wayland / weston require that the surface buffer is specifically an image? what if it's something like a "document" (or command dump) instead... say, a buffer has an "image/svg" MIME content-type; the toolkit updates that svg, and weston delegates the drawing itself to some SvgRenderer (TM) (off-process).

The idea being, there could be many different renderers (so if a renderer gets old, it's only loaded if an app requires it). Thus, GTK+ apps could use a CairoRenderer (it would need some kind of document format, or at the very least marshalling cairo calls, perhaps the Broadway work could be useful here), Qt apps could use a QPainterRenderer, something else could use a PDFRenderer (wine using a win32 renderer :O).

That way, the buffer would contain enough information for the remote system to render the image while minimizing bandwidth requirements...

This could be implemented as some kind of RenderManager which does not need to be integrated into the compositor. But wayland/weston would need to support adding hooks for the renderer.

Also, how does wayland manage the case in which different backends could needs different kind of buffers (e.g. EGL-backend needs a GL buffer, but Pixman backend requires something else?).

Lastly, GTK+ already has some remoting work done with its Broadway backend...

tl;dr add support for *external*, deprecatable, registerable implementations of drawing APIs, and each buffer having a MIME content-type

-- nachokb

Core Wayland requires that a wl_buffer (the buffers that clients hand to the compositor) are pixmaps in a format the compositor advertises that it can support.

However, Wayland is (at heart) an efficient IPC protocol. There is nothing preventing you defining (say) an svg_render_buffer, and providing a library that permits a client to always use svg_render_buffers, even when the compositor does not support said interface (when the compositor supports it, pass the client ops through to the compositor; when it doesn't, draw into wl_buffers and pass those to the compositor). If there are genuine efficiency gains from doing that, go for it!