** Description changed: - Double-buffered compositing performance is poor. + Double-buffered compositing performance is sometimes artificially poor + on some intel systems. When this happens the frame rate seen is halved - + about 30 FPS. However at the same time, Mir is observed to use very + little render time and both the CPU and GPU are still mostly idle. It's + just the Intel DRM logic sometimes takes two frames (~32ms) to complete + a single page flip. - 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. + Two known workarounds avoid the issue: + (a) Add glFinish() into the mesa DisplayBuffer code; or + (b) env INTEL_DEBUG=sync for the Mir server binary.
** Summary changed: - Double-buffered compositing performance is very poor (30 FPS) on intel + Double-buffered compositing performance is sometimes very poor (30 FPS) on intel ** Changed in: mesa (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1377872 Title: Double-buffered compositing performance is sometimes very poor (30 FPS) on intel To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1377872/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
