| Thread Previous • Date Previous • Date Next • Thread Next |
Digging in the kernel, there's some suspicious logic in the i915 driver (used by Mesa i965 etc): /* Throttle our rendering by waiting until the ring has completed our requests * emitted over 20 msec ago. * * Note that if we were to use the current jiffies each time around the loop, * we wouldn't escape the function with any frames outstanding if the time to * render a frame was over 20ms. * * This should get us reasonable parallelism between CPU and GPU but also * relatively low latency when blocking on a particular request to finish. */ static int i915_gem_ring_throttle(struct drm_device *dev, struct drm_file *file) I think that's the problem. Maybe Mir is behaving so well that a single frame doesn't fill the ring (when Mir is only double buffering). So we have to rely on the 20ms delay in the i915 kernel module that causes us to skip a frame. I'm still hoping to be wrong, and that this isn't a *feature* of the i915 kernel module. -- 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: Confirmed Status in mesa package in Ubuntu: Confirmed 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
| Thread Previous • Date Previous • Date Next • Thread Next |
