[Intel-gfx] [PATCH] tests/pm_rps: Add a new testcase to provoke the "stuck at max" bug
Chris Wilson
chris at chris-wilson.co.uk
Thu Mar 27 08:48:37 CET 2014
On Thu, Mar 27, 2014 at 08:45:33AM +0100, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 3:19 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Wed, Mar 26, 2014 at 10:17:51PM +0100, Daniel Vetter wrote:
> >> Note that the sleep(5); to fully idle the gpu is _really_ important.
> >> Without it the bug is not exhibited.
> >>
> >> The issue at hand is that after gem_quiescent_gpu we are at max
> >> (expected, since the blocking waits peg to max), but then we never go
> >> down to a lower freq again until we're fully idle. The tiny load is
> >> sufficient to keep the gpu at max. I've played around with this a bit
> >> and even ridiculously low loads (like one MI_STORE per 50ms) are
> >> enough to keep the gpu at max freq.
> >
> > commit 2754436913b94626a5414d82f0996489628c513d
> > Author: Deepak S <deepak.s at intel.com>
> > Date: Mon Jan 27 21:35:05 2014 +0530
> >
> > drm/i915: Disable/Enable PM Intrrupts based on the current freq.
> >
> > as expected is complete and utter codswallop.
>
> I can confirm that reverting this plus it's vlv deps gets
> igt/pm_rps/blocking going again. The gpu isn't pegged to max any more
> like with current -nightly.
>
> Deepak? I guess this might explain why the boost logic gives sometimes
> inferior power numbers ... Note: Since this is a regression it counts
> as high-prio for upstream business ;-)
Not only does it disable down-clocking, but it also disables
up-clocking. Fantastic.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list