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

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-11-27 15:21:30)
> 
> 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? :)

Adding the MI_USER_INTERRUPT, enabling fence signaling for submit
fences, tidying up, worrying about interrupt latency.

The devilish details.
-Chris