<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#c7">Comment # 7</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:lyude@redhat.com" title="Lyude Paul <lyude@redhat.com>"> Lyude Paul</a> <pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=102199#c6">comment #6</a>) > (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! So doing this fixed the problem entirely. As for the average load% I think the down seems to usually be around 50% (after applying the patches you mentioned in irc), but the up percentage constantly fluctuates between 0 and 100%</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>