Desktops Running On XMir
smspillaz at gmail.com
Wed Jun 26 07:45:01 UTC 2013
On Tue, Jun 25, 2013 at 6:43 PM, Daniel van Vugt
<daniel.van.vugt at canonical.com> 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  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
Indeed, copying from back to front is a very expensive operation and
scales poorly. As suggested, it is also not great on battery life
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.
>  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>
>> 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:
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
More information about the Mir-devel