Subject: Desktops Running On XMir

From: Jono Bacon <[email-masked]>
Date: Mon, 24 Jun 2013 13:43:52 -0700

Hi All,

In case anyone didn't see it, Thomas did some testing of other desktops
running on XMir on Mir:

 * XFCE -
https://plus.google.com/u/1/110095242873945299189/posts/93dAjSwbmch
 * LXDE -
https://plus.google.com/u/1/110095242873945299189/posts/ZxfdAPrybtn
 * GNOME 3 -
https://plus.google.com/u/1/110095242873945299189/posts/3q7YJrc8Fpp

He couldn't test KDE because of an archive issue (non-Mir related). He will
test this soon. Unity 7 already runs on XMir.

I asked him about performance and he said it feels native.

Thanks,

   Jono

-- 
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 25 Jun 2013 10:06:30 +0800

I was thinking about this just today, and the fact that it works means 
XMir is probably not working how it should (!)

1. Double-buffered compositors (Usually only Compiz. Sometimes Gnome) 
have >=two buffers of their own. Only the front one gets sent to Mir's 
backbuffer...? This would be sub-optimal because:
   (a) The X compositor is maintaining two buffers at the same time that 
Mir is. It's a waste of resources in the least
   (b) It creates at least one frame of lag.

2. Single-buffered desktops (all others?), which are updated by region 
blits only. No full-screen buffer swapping in the X compositor, because 
for most of them there is no "compositor". Last I checked, single 
buffering cannot work in Mir because we haven't implemented it. You have 
to simulate it by copying the X buffer to Mir's backbuffer (see 
mir/examples/fingerpaint.c). This is again sub-optimal because of the 
copying and lag.

So given these desktops do work under XMir (I checked), and given Mir 
does not understand single buffering, that means our XMir approach 
probably has some slow buffer copying that needs to be eliminated. It 
might feel native, but benchmarks will disagree.

Also, last I checked, RAOF's plan was to use composition bypass to solve 
this problem (when it's ready). Thus skipping the extra step we still 
have and achieving equal performance to native X.

P.S. I just measured 9-16% improvement in windowed Compiz/XMir 
performance by tweaking the compiz config to eliminate Compiz' double 
buffering (untick everything under CCSM > OpenGL). This is safe under 
XMir because Mir does the real buffer swapping.

- Daniel

On 25/06/13 04:43, Jono Bacon wrote:
> He couldn't test KDE because of an archive issue (non-Mir related). He
> will test this soon. Unity 7 already runs on XMir.
>
> www.ubuntu.com <http://www.ubuntu.com> / www.jonobacon.org
> <http://www.jonobacon.org>
> www.identi.ca/jonobacon <http://www.identi.ca/jonobacon>
> www.twitter.com/jonobacon <http://www.twitter.com/jonobacon>
>
>

---

From: Kevin Gunn <[email-masked]>
Date: Tue, 25 Jun 2013 10:52:29 -0500

Daniel - cmiiw, but I believe the introduced lag won't be a full frame
(16ms) because as i understood from RAOF, the input buffers on xmir aren't
vysnch governed, only the ouput final fb render of unity-system-compositor
(u-s-c)
hence, x/compiz level can literally draw as fast as possible into the input
buffers...and only the u-s-c composition turn is vsynch'd.
so while maybe it could be more effecient, its not as bad as vsynch lock at
multiple levels.

and doesn't compiz have a bypass mechanism itself ? meaning shouldn't it
draw into mir's input buffers directly ?
(i'm guessing this is exactly the problem you're pointing out...)
br,kg

On Mon, Jun 24, 2013 at 9:06 PM, Daniel van Vugt <
[email-masked]> wrote:

> 1. Double-buffered compositors (Usually only Compiz. Sometimes Gnome) have
> >=two buffers of their own. Only the front one gets sent to Mir's
> blits only. No full-screen buffer swapping in the X compositor, because for
> most of them there is no "compositor". Last I checked, single buffering
> cannot work in Mir because we haven't implemented it. You have to simulate
> it by copying the X buffer to Mir's backbuffer (see
> So given these desktops do work under XMir (I checked), and given Mir does
> not understand single buffering, that means our XMir approach probably has
> some slow buffer copying that needs to be eliminated. It might feel native,
> but benchmarks will disagree.
>
> this problem (when it's ready). Thus skipping the extra step we still have
> and achieving equal performance to native X.
>
> P.S. I just measured 9-16% improvement in windowed Compiz/XMir performance
> by tweaking the compiz config to eliminate Compiz' double buffering (untick
> everything under CCSM > OpenGL). This is safe under XMir because Mir does
> the real buffer swapping.
>
> - Daniel
>
>
>
>> https://plus.google.com/u/1/**110095242873945299189/posts/**93dAjSwbmch<https://plus.google.com/u/1/110095242873945299189/posts/93dAjSwbmch>
>>   * LXDE -
>> https://plus.google.com/u/1/**110095242873945299189/posts/**ZxfdAPrybtn<https://plus.google.com/u/1/110095242873945299189/posts/ZxfdAPrybtn>
>>   * GNOME 3 -
>> https://plus.google.com/u/1/**110095242873945299189/posts/**3q7YJrc8Fpp<https://plus.google.com/u/1/110095242873945299189/posts/3q7YJrc8Fpp>
>>
>> www.identi.ca/jonobacon <http://www.identi.ca/**jonobacon<http://www.identi.ca/jonobacon>
>> >
>> www.twitter.com/jonobacon <http://www.twitter.com/**jonobacon<http://www.twitter.com/jonobacon>
>> >
>>
>>
>>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 09:43:02 +0800

I can't prove the lag in case #1 right now. But it should be there. 
Compiz relies on the X driver to throttle it [1] at glXSwapBuffers. So 
so long as XMir is giving Compiz the native buffers then I guess there 
won't be lag.

As for the single-buffered desktops (everything else), again, they 
should not work on XMir unless XMir is copying the X frontbuffer to 
Mir's backbuffer. This may not be a vsync lag, but it's a very intensive 
memory operation that will at least use high CPU, and will cause a 
little lag (hopefully much less than a frame). So the fact that these 
desktops work is probably a bug, suggesting suboptimal performance. I 
hope I'm wrong somewhere and that XMir is doing direct GBM buffer magic 
to avoid any copies.

[1] Throttling should occur, but we also have a regression in this area: 
https://bugs.launchpad.net/mir/+bug/1194004

On 25/06/13 23:52, Kevin Gunn wrote:
> (16ms) because as i understood from RAOF, the input buffers on xmir
> aren't vysnch governed, only the ouput final fb render of
> unity-system-compositor (u-s-c)
> hence, x/compiz level can literally draw as fast as possible into the
> input buffers...and only the u-s-c composition turn is vsynch'd.
> so while maybe it could be more effecient, its not as bad as vsynch lock
> at multiple levels.
>
> On Mon, Jun 24, 2013 at 9:06 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     I was thinking about this just today, and the fact that it works
>     means XMir is probably not working how it should (!)
>
>     1. Double-buffered compositors (Usually only Compiz. Sometimes
>     Gnome) have >=two buffers of their own. Only the front one gets sent
>     to Mir's backbuffer...? This would be sub-optimal because:
>        (a) The X compositor is maintaining two buffers at the same time
>     that Mir is. It's a waste of resources in the least
>     2. Single-buffered desktops (all others?), which are updated by
>     region blits only. No full-screen buffer swapping in the X
>     compositor, because for most of them there is no "compositor". Last
>     I checked, single buffering cannot work in Mir because we haven't
>     implemented it. You have to simulate it by copying the X buffer to
>     Mir's backbuffer (see mir/examples/fingerpaint.c). This is again
>     sub-optimal because of the copying and lag.
>
>     So given these desktops do work under XMir (I checked), and given
>     Mir does not understand single buffering, that means our XMir
>     approach probably has some slow buffer copying that needs to be
>     eliminated. It might feel native, but benchmarks will disagree.
>
>     Also, last I checked, RAOF's plan was to use composition bypass to
>     solve this problem (when it's ready). Thus skipping the extra step
>     we still have and achieving equal performance to native X.
>
>     performance by tweaking the compiz config to eliminate Compiz'
>     double buffering (untick everything under CCSM > OpenGL). This is
>     safe under XMir because Mir does the real buffer swapping.
>
>     - Daniel
>
>
>
>         https://plus.google.com/u/1/__110095242873945299189/posts/__93dAjSwbmch
>         <https://plus.google.com/u/1/110095242873945299189/posts/93dAjSwbmch>
>            * LXDE -
>         https://plus.google.com/u/1/__110095242873945299189/posts/__ZxfdAPrybtn
>         <https://plus.google.com/u/1/110095242873945299189/posts/ZxfdAPrybtn>
>            * GNOME 3 -
>         https://plus.google.com/u/1/__110095242873945299189/posts/__3q7YJrc8Fpp
>         <https://plus.google.com/u/1/110095242873945299189/posts/3q7YJrc8Fpp>
>
>         www.ubuntu.com <http://www.ubuntu.com> <http://www.ubuntu.com> /
>         www.jonobacon.org <http://www.jonobacon.org>
>         <http://www.identi.ca/__jonobacon <http://www.identi.ca/jonobacon>>
>         <http://www.twitter.com/__jonobacon
>         <http://www.twitter.com/jonobacon>>
>
>
>
>     --
>     Mir-devel mailing list
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Sam Spilsbury <[email-masked]>
Date: Wed, 26 Jun 2013 00:45:01 -0700

Hi,

On Tue, Jun 25, 2013 at 6:43 PM, Daniel van Vugt
<[email-masked]> wrote:
> I can't prove the lag in case #1 right now. But it should be there. Compiz
> relies on the X driver to throttle it [1] at glXSwapBuffers. So so long as
> XMir is giving Compiz the native buffers then I guess there won't be lag.

Does it? I thought that the reason why the paint timer existed in the
composite plugin was precisely because glXSwapBuffers was not
guaranteed to block on all drivers. In fact, we always return false in
PaintHandler::hasVSync () in the SwapBuffers/SwapInterval case. [a]

>
> As for the single-buffered desktops (everything else), again, they should
> not work on XMir unless XMir is copying the X frontbuffer to Mir's
> backbuffer. This may not be a vsync lag, but it's a very intensive memory
> operation that will at least use high CPU, and will cause a little lag
> (hopefully much less than a frame). So the fact that these desktops work is
> probably a bug, suggesting suboptimal performance. I hope I'm wrong
> somewhere and that XMir is doing direct GBM buffer magic to avoid any
> copies.

Indeed, copying from back to front is a very expensive operation and
scales poorly. As suggested, it is also not great on battery life
either.

I think as others have suggested, the correct solution to this is
really the use of hardware overlays (or composition bypass). In the
full-screen XMir case that would mean that you'd have only two buffers
- one buffer for the hardware overlay (or even the main buffer that
Mir would otherwise be using should surface size == output size) and
another buffer as the backbuffer. Compiz' paint timer ensure that
glXSwapBuffers is only called at most once every 16 milliseconds.

Best,

Sam.

[a] http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/view/head:/plugins/opengl/src/doublebuffer/src/double-buffer.cpp#L151

> https://lists.ubuntu.com/mailman/listinfo/mir-devel

--
Sam Spilsbury

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 26 Jun 2013 16:07:25 +0800

Sam,

Yes, Compiz should limit itself to whatever the configured refresh_rate 
is, but only when detect_refresh_rate==false. Unfortunately this bug is 
standing in the way:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1194009
and my powertop results suggest it is actually using 200Hz.

For performance Compiz assumes that if the driver does wait for vsync as 
a no-op then that's a driver bug (or configuration fault). Because we 
can't reliably detect what the correct driver behaviour should be, or if 
it's worked. Sometimes a successful wait for vsync will return 
immediately if you're right on the line.

Secondly, it is dangerous to only render at the monitor's refresh rate. 
Because rendering will take time, and on slow machines that might mean 
you miss the frame deadline, and skip a frame unnecessarily. So it's 
advisable to wake up at least a little faster than 60Hz and allow 
yourself as much of the 16ms to render as possible. Last I checked, I 
made the compiz timeout one millisecond from damage to render (Jan 
2012?). And looking at plugins/composite/src, this still seems to be 
true. Which is good.

- Daniel