Launchpad has imported 2 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=86366.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2014-11-17T03:43:35+00:00 Daniel van Vugt wrote: In the Mir server code (DRI output) we call: 1. eglSwapBuffers() 2. get the new front buffer 3. schedule a page flip: drmModePageFlip() This works well, however if I force it to wait for the page flip immediately: 4. select() on the DRM fd and then drmHandleEvent() then step 4 (under some rare but predictable rendering loads) takes 32ms to complete. I've now confirmed it is just the page flip event that takes almost two frames to arrive. And there are two workarounds that seem to successfully kick the driver into action: 3.5. glFinish() or 0. env INTEL_DEBUG=sync Using either of these workarounds, rendering completes in about 1ms and select then returns the next page flip event (~16ms interval). So it seems the intel batching logic is deferring rendering way too long, or the page flip event delivery is being deferred. However the two workarounds suggest the former. Using: Mesa 10.3.2-0ubuntu1 (Ubuntu 15.04 vivid) Intel® HD Graphics 4600 (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz) Reply at: https://bugs.launchpad.net/mir/+bug/1377872/comments/5 ------------------------------------------------------------------------ On 2014-11-17T04:04:10+00:00 Daniel van Vugt wrote: I wonder if this is just a race? If the page flip actually completes faster than select() takes to start up then that would explain it. Reply at: https://bugs.launchpad.net/mir/+bug/1377872/comments/7 ** Changed in: mesa Status: Unknown => Confirmed ** Changed in: mesa Importance: Unknown => Medium -- 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) Status in Mesa: Confirmed Status in Mir: In Progress Status in “mesa” package in Ubuntu: New 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
