[Intel-gfx] [PATCH 06/13] drm/i915/bdw: implement semaphore signal
Chris Wilson
chris at chris-wilson.co.uk
Thu Jan 30 14:35:41 CET 2014
On Thu, Jan 30, 2014 at 02:18:32PM +0100, Daniel Vetter wrote:
> On Thu, Jan 30, 2014 at 1:46 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > Oh. So they changed how post-sync writes operated - this should be a
> > separate fix for stable I believe (so that batches are not run before we
> > have finished invalidating the TLBs required).
>
> We have an igt to exercise tlb invalidation stuff, which runs on all
> rings. But it only runs a batch, so only uses the CS tlb. Do we need
> to extend this?
So the spec says:
Pipe Control Flush Enable (IVB+)
If ENABLED, the PIPE_CONTROL command will wait until all previous writes
of immediate data from post sync circles are complete before executing
the next command.
Post Sync Operation
This field specifies an optional action to be taken upon completion of
the synchronization operation.
TLB Invalidate
If ENABLED, all TLBs belonging to Render Engine will be invalidated once
the flush operation is complete.
Command Streamer Stall Enable
If ENABLED, the sync operation will not occur until all previous flush
operations pending a completion of those previous flushes will complete,
including the flush produced from this command. This enables the command
to act similar to the legacy MI_FLUSH command.
Going by that, the order is
flush, stall, TLB invalidate / post-sync op, [pipe control flush]
Based on my reading of the above (which unless someone has a more
definitive source) says that without the CONTROL_FLUSH_ENABLE, the CS
can continue operations as soon as the flush is complete - in parallel
to the TLB invalidate. Adding CONTROL_FLUSH_ENABLE would then stall the
CS until the post-sync operation completes. That still leaves the
possibility that the TLB invalidate is being performed in parallel and
is itself provides no CS sync.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list