Desktops Running On XMir
Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Jun 26 08:07:25 UTC 2013
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
On 26/06/13 15:45, Sam Spilsbury wrote:
> Hi,
>
> 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 [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
>
>>
>> [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>
>>>
>>>
>>
>> --
>> Mir-devel mailing list
>> Mir-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
>
> --
> Sam Spilsbury
>
More information about the Mir-devel
mailing list