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