<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations" href="https://bugs.freedesktop.org/show_bug.cgi?id=102199#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations" href="https://bugs.freedesktop.org/show_bug.cgi?id=102199">bug 102199</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to Lyude Paul from <a href="show_bug.cgi?id=102199#c4">comment #4</a>) > (In reply to Jani Nikula from <a href="show_bug.cgi?id=102199#c2">comment #2</a>) > > Semi-clueless shot in the dark: Does loading vs. not loading the DMC > > firmware make a difference? > > No unfortunately. In fact the performance almost seems to be worse, and it > doesn't look like it chooses to boost very often. > > Regarding i915_rps_boost_info, I see some very interesting patterns when > gnome-shell is animating. The GPU almost never boosts up even when > continuously replaying the activity overlay animations, and stays at 300 > MHz. Very, very rarely it will decide to boost at which point I can see > mutter reporting the FPS doubling. The boost doesn't last very long though, > and shortly after goes away. Even more interestingly, when the GPU is > rendering the animations it is marked as busy in i915_rps_boost_info despite > never actually boosting. Ok, so it only very rarely is waitboosting (i.e. it doesn't wait). We used to also do a boost if we detect a missed vblank interval for a pageflip. That got lost in the atomic transition... And the typical load is? The last chunk of i915_rps_info should be giving the %load during the EI interval and how far off upclocking it is. > Now, I didn't notice this until just now but something else that's rather > interesting happens when I stop replaying the animations. The second I stop, > the GPU immediately boosts for a split second, then stops. This happens > consistently as well. That'll be a sync somewhere triggering a waitboost. > If I monitor i915_rps_boost_info while running two displays + gnome-shell > though, the GPU boosts almost immediately when the animations start, and > mutter reports FPS counts much closer to what I would expect. Additionally, > the boost count for gnome-shell's process (marked as system-logind) actually > starts going up during animations and labeling itself as actively boosting. > Unplugging the display again makes the GPU stop boosting like before. So there's a difference in the boost counter between the two? In that case the second load is just slow enough that we are stalling for a sync (glFinish, throttling on SwapBuffers) and triggering enough of a waitboost to improve performance. As an experiment, try diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index c47ade3cb786..b88bfef368a3 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -478,6 +478,8 @@ static void __fence_set_priority(struct dma_fence *fence, int prio) return; rq = to_request(fence); + gen6_rps_boost(rq, NULL); + engine = rq->engine; if (!engine->schedule) return; That's total overkill!</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>