[Bug 102199] Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=102199

--- Comment #7 from Lyude Paul <lyude at redhat.com> ---
(In reply to Chris Wilson from comment #6)
> (In reply to Lyude Paul from comment #4)
> > (In reply to Jani Nikula from comment #2)
> > > 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%

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170815/0916ba6d/attachment-0001.html>