[Intel-gfx] [PATCH 08/49] drm/i915: Re-enable RPS wait-boosting for all engines

Chris Wilson chris at chris-wilson.co.uk
Thu Apr 2 04:39:25 PDT 2015


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 at chris-wilson.co.uk>
> >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 at linux.intel.com>

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


More information about the Intel-gfx mailing list