On 8/23/19 7:26 AM, Chris Wilson wrote:
Quoting Chris Wilson (2019-08-23 08:27:25)
Quoting Daniele Ceraolo Spurio (2019-08-23 03:09:09)
TGL has an improved CS pre-parser that can now pre-fetch commands across
batch boundaries. This improves performances when lots of small batches
are used, but has an impact on self-modifying code. If we want to modify
the content of a batch from another ring/batch, we need to either
guarantee that the memory location is updated before the pre-parser gets
to it or we need to turn the pre-parser off around the modification.
In i915, we use self-modifying code only for GPU relocations.
The pre-parser fetches across memory synchronization commands as well,
so the only way to guarantee that the writes land before the parser gets
to it is to have more instructions between the sync and the destination
than the parser FIFO depth, which is not an optimal solution.
Well, our ABI is that memory is coherent before the breadcrumb of *each*
batch. That is a fundamental requirement for our signaling to userspace.
Please tell me that there is a context flag to turn this off, or we else
we need to emit 32x flushes or whatever it takes.
Are you referring to the specific case where we have a request modifying
an object that is then used as a batch in the next request? Because
coherency of objects that are not executed as batches is not impacted.
So looking at what you are doing, it seems entirely possible that we can
switch off the preparser for the breadcrumb -- is that enough to make
that final signal coherent and provide the barrier required for the
invalidation at the start of the next? (You might even only enable the
preparser around userspace batches.) Or I hope they have an extra flush
bit for correct serialisation.
The instructions I got from the HW team on how to handle the
self-modifying code say that the pre-parser must be disabled before the
write is emitted and re-enabled afterward, so I'm not sure if having it
off just around the breadcrumb is enough, we might need and extra
BBSTART in the breadcrumb to flush the parser status. Should we just
keep the parser off by default and have the userspace app opt-in (via
and ARB_CHECK in the batch) if they know they can handle it?
Daniele
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
