On Thu, Apr 02, 2015 at 04:39:56PM +0530, Deepak S wrote: > > > On Friday 27 March 2015 04:31 PM, Chris Wilson wrote: > >This reverts commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b > >Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >Date: Thu Jun 12 10:28:55 2014 +0100 > > > > drm/i915: Restrict GPU boost to the RCS engine > > > >The premise that media/blitter workloads are not affected by boosting is > >patently false with a trip through igt. The question that remains is > >what exactly is going wrong with the media workload that prompted this? > >Hopefully that would be fixed by the missing agressive downclocking, in > >addition to the extra restrictions imposed on how frequent a process is > >allowed to boost. > > we may have to look at media workload. Last time when we observed that for > a 1080p HD clip GPU freq was staying at Rp0 most of the time. > Hopefully aggressive downclocking should help > > Acked-by: Deepak S <deepak.s@xxxxxxxxxxxxxxx> I think here what will help most is limiting the RPS boost to once per client (per busy period). I've actually found a couple of other places where we will artificially boost clocks: mmioflips and sw-semaphores. I've patches to also restrict those to once per busy period. The plan is that we only give RPS boosts to missed pageflips (via the vblank tracker) and only the first time a client stalls on a bo. I think with those in place, we can have the best of both worlds - instant boost for compute/gpu bound applications, and low render frequencies for sustained throughput. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
