[Intel-gfx] [PATCH] drm/i915: Copy across scheduler behaviour flags across submit fences

[Tvrtko Ursulin]

On 27/11/2019 14:37, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-11-27 14:22:37)
>>
>> On 27/11/2019 14:04, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2019-11-27 13:46:14)
>>>> On 27/11/2019 11:17, Chris Wilson wrote:
>>>>> We want the bonded request to have the same scheduler properties as its
>>>>> master so that it is placed at the same depth in the queue. For example,
>>>>> consider we have requests A, B and B', where B & B' are a bonded pair to
>>>>> run in parallel on two engines.
>>>>>
>>>>>         A -> B
>>>>>                      \- B'
>>>>>
>>>>> B will run after A and so may be scheduled on an idle engine and wait on
>>>>> A using a semaphore. B' sees B being executed and so enters the queue on
>>>>> the same engine as A. As B' did not inherit the semaphore-chain from B,
>>>>> it may have higher precedence than A and so preempts execution. However,
>>>>> B' then sits on a semaphore waiting for B, who is waiting for A, who is
>>>>> blocked by B.
>>>>>
>>>>> Ergo B' needs to inherit the scheduler properties from B (i.e. the
>>>>> semaphore chain) so that it is scheduled with the same priority as B and
>>>>> will not be executed ahead of Bs dependencies.
>>>>>
>>>>> Furthermore, to prevent the priorities changing via the expose fence on
>>>>> B', we need to couple in the dependencies for PI. This requires us to
>>>>> relax our sanity-checks that dependencies are strictly in order.
>>>>
>>>> Good catch, this needed some deep thinking! And it looks okay, even
>>>> though ideally we would be able to fix it not to signal the submit fence
>>>> until semaphore was completed. But for that I think we would need to
>>>> emit a request while emitting a request, so that the semaphore wait
>>>> would be in its own.
>>>
>>> At a push we could add an MI_USER_INTERRUPT after the initial breadcrumb
>>> and couple the submit fence into that. That would be virtually
>>> equivalent to emitting a separate request for semaphores. Something to
>>> ponder over.
>>
>> Hm, if not too difficult it would definitely be much preferable since
>> relying on controlling preemption decisions feels a bit fragile/hackish.
>>
>> Simply moving __notify_execute_cb from __i915_request_submit to
>> intel_engine_breadcrumbs_irq, under a __i915_request_has_started check,
>> could do it?
> 
> 95% of the way, yes.

Is the remaining 5% just a new flavour of __i915_request_has_started 
which does away with rcu_read_lock? :)

Regards,

Tvrtko