[Intel-gfx] [PATCH v4 38/38] drm/i915: Allow scheduler to manage inter-ring object synchronisation

[John Harrison]

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.


> -Chris
>