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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
