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@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 ;-) Not only does it disable down-clocking, but it also disables up-clocking. Fantastic. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
