desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #104495
[Bug 1377872] Re: Double-buffered compositing performance is very poor (30 FPS) on intel
Can't reproduce this any more.
Mir now has double buffered clients as well as double buffered
compositing so the bug should be more visible, not less. Although vivid
also just got updated to Mesa 10.5 which is where I would expect a fix
to come from. Seems to be fixed, probably by recent Mesa/kernel updates.
** Changed in: mir
Status: Triaged => Incomplete
** Changed in: mesa (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1377872
Title:
Double-buffered compositing performance is very poor (30 FPS) on intel
Status in Mesa:
Confirmed
Status in Mir:
Incomplete
Status in mesa package in Ubuntu:
Incomplete
Bug description:
Double-buffered compositing performance is poor.
Fortunately we don't use double-buffering in our default compositor
(mostly), and Ubuntu touch does not use the default compositor either.
However, if you make the compositor double-buffered, then it quickly
drops down to 30 FPS while not consuming any significant CPU or render
time.
Test case A:
Convert your compositor to double buffering by the code change suggested in bug 1350725.
Test case B (different bug?):
Switch all clients to double-buffering using this branch: lp:~vanvugt/mir/double
and then start a nested server.
Now start a bunch of clients, and you will find they slow down to 30
FPS after only starting a few. This does not happen with the default
triple buffered compositor.
I've been ignoring this issue for a little while [1] thinking I had simply run out of power, although suspected that can't be right as this is a powerful quad-core i7 and it's slowing down with only 10 clients.
[1] https://bugs.launchpad.net/mir/+bug/1350725/comments/1
Now today test case B has revealed (via MIR_CLIENT_PERF_REPORT) that
the slowdown happens without using any significant render time (less
than 2 ms) and without using any significant CPU (less than 20% of one
out of four cores).
So the conclusion is our default compositor is probably holding
buffers for a little too long somewhere. Because that's the only
sensible reason I can think of for my system to bog down to 30 FPS
without stressing the CPU or GPU. We've got poor parallelism in our
code somewhere. And once that's solved, we'll be able to make further
improvements such as resolving bug 1350725.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1377872/+subscriptions