Desktops Running On XMir

Wed Jun 26 01:43:02 UTC 2013

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:
> 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
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> 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
>        (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:
>
>         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
>         <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>
>
>         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 <http://www.ubuntu.com> <http://www.ubuntu.com> /
>         www.jonobacon.org <http://www.jonobacon.org>
>         <http://www.jonobacon.org>
>         www.identi.ca/jonobacon <http://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
>         <http://www.twitter.com/jonobacon>>
>
>
>
>     --
>     Mir-devel mailing list
>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>