Actually cc'ing Deepak might help. -Daniel On Thu, Mar 27, 2014 at 8:45 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > On Thu, Mar 27, 2014 at 3:19 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> >> 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 ;-) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
