2D Performance Is Improving For Ubuntu 13.10 XMir

[TheBlackCat]

So for now XMir looks superior to XWayland, but XMir is running with X as root so end results may change when unity 8 is ready and XMir also runs rootless.

How is it "superior" to be running a rooted X inside Mir/Wayland? It is not that this sort of thing would be fundamentally impossible in XWayland, it is just that nobody implemented it because they didn't see any reason to. So what is the advantage of running rooted X inside XMir/XWayland?

[nadro]

Two things. The first, no, you can't make it talk directly to Mir if using a fullscreen X server. The second, neither Wayland nor Mir are supposed to bring noticeable better performance than X for fullscreen games, for the simple reason none of them talk a lot to the X server. At most, they call GLXSwapBuffers (I'm not sure if that was the function name, but I think everyone understand what it does), which they will need to call anyway, or an equivalent. Most of the works is done via direct rendering, which should not be affected by none of Mir, X, or Wayland.

You can talk directly to Mir even if fullscreen XMir session is active. What about fullscreen games? Remember about events. XEvent system isn't too fast, so here some performance improvements may come, anyway simple SwapBuffer should be little more efficient too in Mir and in Wayland than in X.

BTW. This disscustion Mir vs. Wayland at now is really fun. Both Display Servers are really similar from game developer point of view, so write two different backends aren't a problem. If Canonical want own DS who care? Welcome in open source world, where everyone can do what they want. I'm happy that X will be replaced soon by modern DS. Both Mir and Wayland teams did great job for Linux world. Competition always improve level of software. If someone have that many problems with Mir look what Intel did with OpenCL, this the same situation.

[Pajn]

How is it "superior" to be running a rooted X inside Mir/Wayland? It is not that this sort of thing would be fundamentally impossible in XWayland, it is just that nobody implemented it because they didn't see any reason to. So what is the advantage of running rooted X inside XMir/XWayland?

Wayland and Mir hopes to finally give us a flicker-free boot experience.
Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).
So if you want to use XFCE with a flicker-free boot experience you will
have to use Mir as a system compositor, compositing the boot and the
login manager and then run XFCE in XMir.

Also I like the idea of full compatibility. Either it's a game, a program or
a DE it's nice to be able to run in in the compatibility layer. I think the
golden goal is that anything that runs in X shall be able to run in XMir
or XWayland without any changes.

And to everyone in this thread:
Thanks for finally having a thread were discussions works! I'm so sick
of the other threads that is so full of shitstorming. Thanks!

[ickle]

Some test where actually (a tiny bit) better than pure Xorg.
This surprise me a bit. Is there anyone that can explain how
that is possible?

Based on the architecture it is not.

In X, we render directly to the screen.

In X+Unity, we render to a backbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers (i.e. replace the scanout with Unity's backbuffer), which X does with a pageflip.

in X+Unity+XMir, we render to a backbbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers, X then copies that to its own frontbuffer, and when Mir requests a new frame, copies that to the buffer provided by Mir. (Now with composite bypass enabled, the buffer provided by Mir is its back buffer, eliminating one of the many copies.) Mir than pageflips between its backbuffer and the scanout.

What you are seeing here is that most of these benchmarks are not stressing the graphics driver at all [QGears, gtkperf], or do not render to the screen [cairo-trace], and so they show very little difference for that extra two copies every 60Hz. The one that shows some difference, x11perf -comppixwin500, is really just a driver artifact - the error bar indicates that for one run, the driver got stuck using the BCS for the repeated copies rather than RCS. That happens irrespective of the compositing system - it just requires something else to render at the wrong time to trick the driver into believing that we are going to be using the BCS for the near future and so it then continues to use BCS to avoid the overhead of switching rings.

Throughput testing in applications seems to be around the 10% mark below X+Unity, which itself is about 30% slower than raw X, and we haven't even started to talk about the increased power consumption yet...

[Pajn]

Based on the architecture it is not.

In X, we render directly to the screen.

In X+Unity, we render to a backbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers (i.e. replace the scanout with Unity's backbuffer), which X does with a pageflip.

in X+Unity+XMir, we render to a backbbuffer, tell Unity about what is rendered, Unity copies that to its own backbuffer, then tells X to swap buffers, X then copies that to its own frontbuffer, and when Mir requests a new frame, copies that to the buffer provided by Mir. (Now with composite bypass enabled, the buffer provided by Mir is its back buffer, eliminating one of the many copies.) Mir than pageflips between its backbuffer and the scanout.

What you are seeing here is that most of these benchmarks are not stressing the graphics driver at all [QGears, gtkperf], or do not render to the screen [cairo-trace], and so they show very little difference for that extra two copies every 60Hz. The one that shows some difference, x11perf -comppixwin500, is really just a driver artifact - the error bar indicates that for one run, the driver got stuck using the BCS for the repeated copies rather than RCS. That happens irrespective of the compositing system - it just requires something else to render at the wrong time to trick the driver into believing that we are going to be using the BCS for the near future and so it then continues to use BCS to avoid the overhead of switching rings.

Throughput testing in applications seems to be around the 10% mark below X+Unity, which itself is about 30% slower than raw X, and we haven't even started to talk about the increased power consumption yet...

Thank you for a informative and interesting post!

If I get you correct, what this basically means is that this kind of benchmarks
doesn't rely mean anything. The differences are too small and the "background
noise" are to high. Is that correct?

If so, I guess that would mean that this 10% extra overhead aren?t noticeable in
real usage as the "background noise" can be much higher than the slowdown itself.

If so that's pretty great, sure it's still a slowdown however that's what expected.

What would be more interesting than performance benchmarks would be power
consumption. Where a small performance degradation isn't noticeable even the
smallest extra power consumption is when running on battery.

Michael (I hope you read this forum):
Could you run some battery benchmarks on X, XWayland and XMir? I think that
would be very interesting. Especially considering that XWayland is rootless, as
that is what will mainly be used in the future.
It would also be nice if XMir were run with both Unity and something slimmer like
XFCE to see how much of the consumption is in the DE itself.

[ickle]

Thank you for a informative and interesting post!

If I get you correct, what this basically means is that this kind of benchmarks
doesn't rely mean anything. The differences are too small and the "background
noise" are to high. Is that correct?

If so, I guess that would mean that this 10% extra overhead aren?t noticeable in
real usage as the "background noise" can be much higher than the slowdown itself.

That's correct. One of the big changes noticeable with the UXA to SNA transition is that we go from being driver-limited to application-limited. The most obvious example here is firefox. The biggest way we can futher improve firefox is to reduce the drawing overhead in the application (and the js/xul overheads, but that is a different topic!).

IIf so that's pretty great, sure it's still a slowdown however that's what expected.

What would be more interesting than performance benchmarks would be power
consumption. Where a small performance degradation isn't noticeable even the
smallest extra power consumption is when running on battery.

One of the tasks I am working on is improving the tools we have for analysing power consumption. For one of our big challenges we have is making sure the GPU is running at the right speed at the right time (i.e. turned off for as long as possible, yet still able to deliver those first few frames without a hiccup). As you can probably imagine, the highly irregular nature of a composited 2D workload is harder to get right than a game where we never have enough power... And yet more people are likely to notice the delay when moving windows or the jitter in some wobbly window animation. (And those extra stages in the render pipeline between the application and the user make that challenge so much more fun!) This is yet another reason why consistent latency matters so much more than throughput for user experience.

[Vim_User]

Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).

Any link to that statement?

[TheOne]

How is it "superior" to be running a rooted X inside Mir/Wayland? It is not that this sort of thing would be fundamentally impossible in XWayland, it is just that nobody implemented it because they didn't see any reason to. So what is the advantage of running rooted X inside XMir/XWayland?

I haven't said there is some end user advantage (that would be said by a fanboy ), but there may be a development advantage that would help on improving XMir, but as mrugiero has said, there are some optimizations that apply to XMir with a root X and that doesn't apply on a rootless environment, so again, end results may change when running XMir rootless.

Any link to that statement?

Actually XFCE is being slowly ported to GTK3 so that means they will have wayland support out of the box

Link: http://wiki.xfce.org/releng/4.12/roadmap/gtk3

[mrugiero]

You can talk directly to Mir even if fullscreen XMir session is active. What about fullscreen games? Remember about events. XEvent system isn't too fast, so here some performance improvements may come, anyway simple SwapBuffer should be little more efficient too in Mir and in Wayland than in X.

I must say, I forgot about input, REALLY bad. On SwapBuffers, again, even if it's slightly more efficient, that's not a main bottleneck, so any improvement on that side will probably be negligible.
On the point about talking directly to Mir, what I mean is that you will be unable to use it from inside the X session. You could use it, but then you'd be fully restricted to using it fullscreen.

BTW. This disscustion Mir vs. Wayland at now is really fun. Both Display Servers are really similar from game developer point of view, so write two different backends aren't a problem. If Canonical want own DS who care? Welcome in open source world, where everyone can do what they want.

You know, the fact they can doesn't make caring and discussing any less valid. They can do whatever they want, and they are doing it. This doesn't mean I can't criticize them if I think what they do is wrong.
And writing two different backends IS a problem. Extra work means extra money, which means it's harder to meet the expected costs/benefits ratio a company would expect before porting anything.

I'm happy that X will be replaced soon by modern DS. Both Mir and Wayland teams did great job for Linux world. Competition always improve level of software. If someone have that many problems with Mir look what Intel did with OpenCL, this the same situation.

That's false at so many levels. Competition *may* be good, and it also may be awfully bad. You push deadlines, release half assed products, how that can be good for anyone?
Also, Intel's own OpenCL implementation (which I already criticized in the appropriate thread, mind you) is a whole different thing than Mir, since software written for OpenCL should run on Intel's implementation as well as in Gallium. This means, their fragmentation is localized: it only means they aren't sharing the workload with Gallium. In the case of Mir versus Wayland, you need to write software for Mir or for Wayland. In the common case, this only means porting toolkits to an extra platform. In less common cases, this means writing two backends or supporting only a fraction of the Linux desktop. This is the same problem we have with toolkits.

Wayland and Mir hopes to finally give us a flicker-free boot experience.
Some DEs wont get ported to Wayland or Mir (XFCE for example have said they will stick to X).
So if you want to use XFCE with a flicker-free boot experience you will have to use Mir as a system compositor, compositing the boot and the login manager and then run XFCE in XMir.

Sacrificing performance through the whole session just to get flicker-free boot is a waste, IMO.

that means they will have wayland support out of the box

No, it doesn't. The window manager, a core part of any DE, talks directly to the X server. Porting to a different toolkit doesn't change this (I heard Qt5 is an exception to this, but I'm not really sure), and it means you need to explicitly port it to Wayland.
XFCE said that for now they'll stick to X, they never stated something like "we will never use either Mir or Wayland". I think it's the sane decision for their limited workforce, to wait until the ones with most people do the hard bits and to have a somewhat easier porting. In the end, I'd expect them to use Wayland.
Also, I wouldn't sacrifice the whole use performance just for flicker-free boot. It's a personal choice, but I think it's the wrong one.

Also I like the idea of full compatibility. Either it's a game, a program or a DE it's nice to be able to run in in the compatibility layer. I think the golden goal is that anything that runs in X shall be able to run in XMir or XWayland without any changes.

That's pointless. If you are going to use an X DE, being unable to run in a correctly integrated way anything non-X-ish, then you are better off just running X.
I mean, having options and legacy compatibility is alright, but if you are actually making no use of the modern features, you are just wasting cycles in a middleware that does nothing. You keep dragging behind you all of the crufty problems of X.

[TheOne]

...
The window manager, a core part of any DE, talks directly to the X server. Porting to a different toolkit doesn't change this (I heard Qt5 is an exception to this, but I'm not really sure), and it means you need to explicitly port it to Wayland.
...

I thought about that after posting, thanks for the correction.