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