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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
