<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Slow i965 performance (30 FPS), but super-fast with INTEL_DEBUG=sync" href="https://bugs.freedesktop.org/show_bug.cgi?id=86366#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Slow i965 performance (30 FPS), but super-fast with INTEL_DEBUG=sync" href="https://bugs.freedesktop.org/show_bug.cgi?id=86366">bug 86366</a> from <a class="email" href="mailto:daniel.van.vugt@canonical.com" title="Daniel van Vugt <daniel.van.vugt@canonical.com>"> Daniel van Vugt</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>