[Intel-gfx] [PATCH 08/21] drm/i915: Use HWS for seqno tracking everywhere

Chris Wilson chris at chris-wilson.co.uk
Wed Jun 8 09:24:59 UTC 2016


On Mon, Jun 06, 2016 at 03:55:18PM +0100, Tvrtko Ursulin wrote:
> 
> On 03/06/16 17:08, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> >index 2a736f4a0fe5..4013ad92cdc6 100644
> >--- a/drivers/gpu/drm/i915/i915_irq.c
> >+++ b/drivers/gpu/drm/i915/i915_irq.c
> >@@ -2951,7 +2951,7 @@ static int semaphore_passed(struct intel_engine_cs *engine)
> >  	if (signaller->hangcheck.deadlock >= I915_NUM_ENGINES)
> >  		return -1;
> >
> >-	if (i915_seqno_passed(signaller->get_seqno(signaller), seqno))
> >+	if (i915_seqno_passed(intel_engine_get_seqno(engine), seqno))
> 
> Should be signaller, not engine, by the look of it.

Ta!

> >@@ -1543,7 +1537,9 @@ static int
> >  pc_render_add_request(struct drm_i915_gem_request *req)
> >  {
> >  	struct intel_engine_cs *engine = req->engine;
> >-	u32 scratch_addr = engine->scratch.gtt_offset + 2 * CACHELINE_BYTES;
> >+	u32 addr = engine->status_page.gfx_addr +
> >+		(I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT);
> >+	u32 scratch_addr = addr;
> >  	int ret;
> 
> Before my time. :)
> 
> Why was this code flushing all that space but above where it was
> writting the seqno?

The idea is simply that we need to delay the command streamer by
performing N writes before asserting the interrupt. The choice of where
is purely paranoia to make sure the GPU can't pack multiple writes into
one transaction.
 
> With this change it is flushing the seqno area as well.

s/flushing/writing/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list