[Intel-gfx] [PATCH] drm/i915: Click the ACTHD three times to go home

Chris Wilson chris at chris-wilson.co.uk
Mon Mar 27 14:25:31 UTC 2017


On Mon, Mar 27, 2017 at 05:00:49PM +0300, Mika Kuoppala wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > On Mon, Mar 27, 2017 at 04:19:58PM +0300, Mika Kuoppala wrote:
> >> Chris Wilson <chris at chris-wilson.co.uk> writes:
> >> 
> >> > On Mon, Mar 27, 2017 at 01:12:30PM +0300, Mika Kuoppala wrote:
> >> >> Chris Wilson <chris at chris-wilson.co.uk> writes:
> >> >> 
> >> >> > One POSTING_READ of ACTHD may not be enough to ensure that the seqno
> >> >> > write has been posted from the GPU and is now visible. So do three!
> >> >> >
> >> >> 
> >> >> Is this about posting read triggering or just adding enough delay
> >> >> that the write gets through?
> >> >
> >> > It's purely about a delay that we guess will cover 99.9999% of cases.
> >> 
> >> Acked-by: Mika Kuoppala <mika.kuoppala at intel.com>
> >
> > Thanks, for checking over the idea. I'm going to apply it to
> > topic/core-for-CI for some extended soak testing and see if that
> > silences fi-snb-2600
> 
> Another thing that would be worth testing is to force a latency guarantee
> through pm_qos.

iirc removing a pm_qos was synchronous, so for shortlived/frequent requests
they were a no-go (I tried holding pm_qos over the wait, which covers
all the irq_seqno_barriers). It bumped our client latency metrics quite
substantially.

Ugh. Super ugly would be to take pm_qos whilst irq is enabled, just we
keep that irq enabled all the time whilst the guc is active,
artificially forcing the cpus to never sleep whilst the GPU is busy.

On the other hand, they don't have seqno_barrier. Getting hacky.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list