[Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly

[Rafael Antognolli]

On Wed, May 06, 2020 at 04:32:02PM +0100, Chris Wilson wrote:
> Quoting Mika Kuoppala (2020-05-06 16:20:22)
> > Chris Wilson <chris at chris-wilson.co.uk> writes:
> > 
> > > Quoting Mika Kuoppala (2020-05-06 15:47:34)
> > >> Aux table invalidation can fail on update. So
> > >> next access may cause memory access to be into stale entry.
> > >> 
> > >> Proposed workaround is to invalidate entries between
> > >> all batchbuffers.
> > >
> > > This sounds like it should have a sunset clause. Do we anticipate being
> > > able to drop this w/a in future?
> > 
> > Rafael kindly pointed out that Mesa already does this:
> > https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/iris/iris_state.c#L5131
> > So I would say we can drop this patch.
> 
> Is the false hit self-contained? Is it caused by PTE update of the
> address or by a 3D state change i.e. is it a potential isolation issue?
> -Chris

There's no 3D state for the aux table. What we do in Iris is:
 - allocate buffers and cpu map them
 - write the multiple levels of the table (main buffers -> CCS buffers)
   and keep track of when it changes
 - whenever it changes, we emit LRI to 0x4208 to invalidate the cache.

Anv does something similar except it writes to the table from the GPU.

I tried removing the heuristics and invalidating the table on the
beginning of every batch, but it doesn't help. We can probably get
preempted mid-batch and then another context with a different aux table
and the wrong cache is probably causing the hang. The kernel
invalidating it seems to fix the problem.

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx