On 11/01/2016 22:07, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 06:43:07PM +0000, John.C.Harrison@xxxxxxxxx wrote:
From: John Harrison <John.C.Harrison@xxxxxxxxx>
The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_sync() using hardware semaphores where available and
CPU stalls where not (e.g. in execlist mode and/or on Gen8 hardware).
Unfortunately, when a batch buffer is submitted to the driver the
_object_sync() call happens first. Thus in case where hardware
semaphores are disabled, the driver has already stalled until the
dependency has been resolved.
But this should just add the dependency to the request in the scheduler
callback for i915_gem_object_sync_to, or better renamed as
i915_gem_request_submit_after. Without a scheduler we can do the
optimisation of doing that work inline, with a scheduler we can just
track the dependency.
That's the whole point. The scheduler is already tracking the
dependencies between batch buffers and will ensure that everything
happens in the correct order. The problem is that the object sync code
is manually forcing that order before the batch buffers even get to the
scheduler, either through hardware semaphores (which have power and
performance penalties) or CPU stalling (which is just a performance
issue). Hence this patch is saying that if the dependency between the
objects is something the scheduler knows about, i.e. it is batch buffer
based, then don't bother doing the synchronisation up front. Just assume
the scheduler will do it internally later.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
