[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 #6 from Chris Wilson <chris at chris-wilson.co.uk> ---
(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!

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