[Intel-gfx] [PATCH] drm/i915/tgl: Suspend pre-parser across GTT invalidations

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2019-09-16 21:37:26)
> 
> 
> On 9/14/19 1:25 AM, Chris Wilson wrote:
> > Before we execute a batch, we must first issue any and all TLB
> > invalidations so that batch picks up the new page table entries.
> > Tigerlake's preparser is weakening our post-sync CS_STALL inside the
> > invalidate pipe-control and allowing the loading of the batch buffer
> > before we have setup its page table (and so it loads the wrong page and
> > executes indefinitely).
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > ---
> > Suggestions welcome as this does not seem intended behaviour, so I
> > suspect there is a strong pipecontrol flag we are missing.
> 
> When I discussed the pre-parser with the HW team the feedback I got was 
> that the only way to make sure we don't race the memory update is to 
> either leave enough CL of space or turn the parser off like you did 
> below. That discussion was about actual physical memory access though 
> and not TLB.
> Anyway, turning off the parser around the pipe control, if it fixes the 
> problem, shouldn't be too bad since the main performance advantage of 
> the parser is expected inside the user batch. The alternative would 
> probably be to stop invalidating the TLBs from within the ring and 
> switch to MMIO invalidations when lite-restoring a new request in the 
> ring (the CS will implicitly stop the parser and invalidate everything 
> on a full ctx switch).

I also only observe the effect on rcs0 atm. Does that tie in with the
preparser theory? i.e. that either the MI_FLUSH_DW is a strong barrier
or the preparser is rcs0 only. (Strictly speaking I haven't yet run the
igt_cs_tlb test on tgl/bcs0 so I am basing the above off the igt test
results that pass on bcs0 but consistently failed on rcs0.)
-Chris