Desktops Running On XMir
Daniel van Vugt
daniel.van.vugt at canonical.com
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  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.
 Throttling should occur, but we also have a regression in this area:
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...)
> 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>>
> 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
> running on XMir on Mir:
> * XFCE -
> * LXDE -
> * GNOME 3 -
> 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.
> Jono Bacon
> Ubuntu Community Manager
> www.ubuntu.com <http://www.ubuntu.com> <http://www.ubuntu.com> /
> 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>
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> Modify settings or unsubscribe at:
More information about the Mir-devel