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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
