[Intel-gfx] [PATCH v4 38/38] drm/i915: Allow scheduler to manage inter-ring object synchronisation
John.C.Harrison at Intel.com
Tue Jan 12 03:38:06 PST 2016
On 11/01/2016 22:07, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 06:43:07PM +0000, John.C.Harrison at Intel.com wrote:
>> From: John Harrison <John.C.Harrison at Intel.com>
>> 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.
More information about the Intel-gfx