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

[Chris Wilson]

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.
-Chris