Quoting Mika Kuoppala (2020-07-24 08:38:56) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > Whether this is an arbitrary stall or a vital ingredient, neverthess the > > impact is noticeable. If we do not have the stall around the xcs > > invalidation before a request, writes within that request sometimes go > > astray. > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2169 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 18 ++++++++++++------ > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > > index 353b1717fe84..7d914527d236 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -4761,10 +4761,12 @@ static int gen12_emit_flush_render(struct i915_request *request, > > > > static int gen12_emit_flush(struct i915_request *request, u32 mode) > > { > > +#define WA_CNT 16 /* Magic delay or size of some internal pipelined buffer? */ > > Odd, very odd indeed. > > I looked at the selftest in question. For completeness, there should be > READ_ONCE on where the hwsp is read, but that is just a makeup. > > But how about forcing the write completion check on, on the actual > write to the hwsp? It is enabled with bit 10. Nope. Which is a relief, since I'd working on the assumption that the delay needs to be before the write not after. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
