[Intel-gfx] [PATCH] drm/i915: Copy across scheduler behaviour flags across submit fences
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Wed Nov 27 14:22:37 UTC 2019
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?
Regards,
Tvrtko
More information about the Intel-gfx
mailing list