| Message ID | 20191013203012.25208-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/execlists: Tweak virtual unsubmission | expand |
On 2019-10-13 at 21:30:12 +0100, Chris Wilson wrote: > Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > overtaking each other on preemption") we have restricted requests to run > on their chosen engine across preemption events. We can take this > restriction into account to know that we will want to resubmit those > requests onto the same physical engine, and so can shortcircuit the > virtual engine selection process and keep the request on the same > engine during unwind. > > References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") Chris, Based on what i understood here, change looks good to me. If it helps, please use Reviewed-by: Ramlingam C <ramalingam.c@intel.com> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- > drivers/gpu/drm/i915/i915_request.c | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > index e6bf633b48d5..03732e3f5ec7 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > list_for_each_entry_safe_reverse(rq, rn, > &engine->active.requests, > sched.link) { > - struct intel_engine_cs *owner; > > if (i915_request_completed(rq)) > continue; /* XXX */ > @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > * engine so that it can be moved across onto another physical > * engine as load dictates. > */ > - owner = rq->hw_context->engine; > - if (likely(owner == engine)) { > + if (likely(rq->execution_mask == engine->mask)) { > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); > if (rq_prio(rq) != prio) { > prio = rq_prio(rq); > @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > list_move(&rq->sched.link, pl); > active = rq; > } else { > + struct intel_engine_cs *owner = rq->hw_context->engine; > + > /* > * Decouple the virtual breadcrumb before moving it > * back to the virtual engine -- we don't want the > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index 437f9fc6282e..b8a54572a4f8 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -649,6 +649,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) > rq->gem_context = ce->gem_context; > rq->engine = ce->engine; > rq->ring = ce->ring; > + rq->execution_mask = ce->engine->mask; > > rcu_assign_pointer(rq->timeline, tl); > rq->hwsp_seqno = tl->hwsp_seqno; > @@ -671,7 +672,6 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) > rq->batch = NULL; > rq->capture_list = NULL; > rq->flags = 0; > - rq->execution_mask = ALL_ENGINES; > > INIT_LIST_HEAD(&rq->execute_cb); > > -- > 2.23.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 13/10/2019 21:30, Chris Wilson wrote: > Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > overtaking each other on preemption") we have restricted requests to run > on their chosen engine across preemption events. We can take this > restriction into account to know that we will want to resubmit those > requests onto the same physical engine, and so can shortcircuit the > virtual engine selection process and keep the request on the same > engine during unwind. > > References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- > drivers/gpu/drm/i915/i915_request.c | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > index e6bf633b48d5..03732e3f5ec7 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > list_for_each_entry_safe_reverse(rq, rn, > &engine->active.requests, > sched.link) { > - struct intel_engine_cs *owner; > > if (i915_request_completed(rq)) > continue; /* XXX */ > @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > * engine so that it can be moved across onto another physical > * engine as load dictates. > */ > - owner = rq->hw_context->engine; > - if (likely(owner == engine)) { > + if (likely(rq->execution_mask == engine->mask)) { > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); > if (rq_prio(rq) != prio) { > prio = rq_prio(rq); > @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > list_move(&rq->sched.link, pl); > active = rq; > } else { > + struct intel_engine_cs *owner = rq->hw_context->engine; I guess there is some benefit in doing fewer operations as long as we are fixing the engine anyway (at the moment at least). However on this branch here the concern was request completion racing with preemption handling and with this change the breadcrumb will not get canceled any longer and may get signaled on the virtual engine. Which then leads to the explosion this branch fixed. At least that's what I remembered in combination with the comment below.. Regards, Tvrtko > + > /* > * Decouple the virtual breadcrumb before moving it > * back to the virtual engine -- we don't want the > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index 437f9fc6282e..b8a54572a4f8 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -649,6 +649,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) > rq->gem_context = ce->gem_context; > rq->engine = ce->engine; > rq->ring = ce->ring; > + rq->execution_mask = ce->engine->mask; > > rcu_assign_pointer(rq->timeline, tl); > rq->hwsp_seqno = tl->hwsp_seqno; > @@ -671,7 +672,6 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) > rq->batch = NULL; > rq->capture_list = NULL; > rq->flags = 0; > - rq->execution_mask = ALL_ENGINES; > > INIT_LIST_HEAD(&rq->execute_cb); > >
Quoting Tvrtko Ursulin (2019-10-14 10:34:31) > > On 13/10/2019 21:30, Chris Wilson wrote: > > Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > > overtaking each other on preemption") we have restricted requests to run > > on their chosen engine across preemption events. We can take this > > restriction into account to know that we will want to resubmit those > > requests onto the same physical engine, and so can shortcircuit the > > virtual engine selection process and keep the request on the same > > engine during unwind. > > > > References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > --- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > > index e6bf633b48d5..03732e3f5ec7 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > list_for_each_entry_safe_reverse(rq, rn, > > &engine->active.requests, > > sched.link) { > > - struct intel_engine_cs *owner; > > > > if (i915_request_completed(rq)) > > continue; /* XXX */ > > @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > * engine so that it can be moved across onto another physical > > * engine as load dictates. > > */ > > - owner = rq->hw_context->engine; > > - if (likely(owner == engine)) { > > + if (likely(rq->execution_mask == engine->mask)) { > > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); > > if (rq_prio(rq) != prio) { > > prio = rq_prio(rq); > > @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > list_move(&rq->sched.link, pl); > > active = rq; > > } else { > > + struct intel_engine_cs *owner = rq->hw_context->engine; > > I guess there is some benefit in doing fewer operations as long as we > are fixing the engine anyway (at the moment at least). > > However on this branch here the concern was request completion racing > with preemption handling and with this change the breadcrumb will not > get canceled any longer and may get signaled on the virtual engine. > Which then leads to the explosion this branch fixed. At least that's > what I remembered in combination with the comment below.. No, we don't change back to the virtual engine, so that is not an issue. The problem was only because of the rq->engine = owner where the breadcrumbs were still on the previous engine lists and assumed to be under that engine->breadcrumbs.lock (but would in future be assumed to be under rq->engine->breadcrumbs.lock). -Chris
Quoting Tvrtko Ursulin (2019-10-14 10:34:31) > > On 13/10/2019 21:30, Chris Wilson wrote: > > Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > > overtaking each other on preemption") we have restricted requests to run > > on their chosen engine across preemption events. We can take this > > restriction into account to know that we will want to resubmit those > > requests onto the same physical engine, and so can shortcircuit the > > virtual engine selection process and keep the request on the same > > engine during unwind. > > > > References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > --- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- > > drivers/gpu/drm/i915/i915_request.c | 2 +- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > > index e6bf633b48d5..03732e3f5ec7 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > list_for_each_entry_safe_reverse(rq, rn, > > &engine->active.requests, > > sched.link) { > > - struct intel_engine_cs *owner; > > > > if (i915_request_completed(rq)) > > continue; /* XXX */ > > @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > * engine so that it can be moved across onto another physical > > * engine as load dictates. > > */ > > - owner = rq->hw_context->engine; > > - if (likely(owner == engine)) { > > + if (likely(rq->execution_mask == engine->mask)) { > > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); > > if (rq_prio(rq) != prio) { > > prio = rq_prio(rq); > > @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > > list_move(&rq->sched.link, pl); > > active = rq; > > } else { > > + struct intel_engine_cs *owner = rq->hw_context->engine; > > I guess there is some benefit in doing fewer operations as long as we > are fixing the engine anyway (at the moment at least). It also added a bit of consistency to how we detect virtual engine during i915_request construction (e.g. __i915_request_add_to_timeline), I liked that. -Chris
Quoting Ramalingam C (2019-10-14 10:28:18) > On 2019-10-13 at 21:30:12 +0100, Chris Wilson wrote: > > Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > > overtaking each other on preemption") we have restricted requests to run > > on their chosen engine across preemption events. We can take this > > restriction into account to know that we will want to resubmit those > > requests onto the same physical engine, and so can shortcircuit the > > virtual engine selection process and keep the request on the same > > engine during unwind. > > > > References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") > Chris, > > Based on what i understood here, change looks good to me. > > If it helps, please use > Reviewed-by: Ramlingam C <ramalingam.c@intel.com> Welcome! -Chris
On 14/10/2019 10:41, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2019-10-14 10:34:31) >> >> On 13/10/2019 21:30, Chris Wilson wrote: >>> Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from >>> overtaking each other on preemption") we have restricted requests to run >>> on their chosen engine across preemption events. We can take this >>> restriction into account to know that we will want to resubmit those >>> requests onto the same physical engine, and so can shortcircuit the >>> virtual engine selection process and keep the request on the same >>> engine during unwind. >>> >>> References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >>> --- >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- >>> drivers/gpu/drm/i915/i915_request.c | 2 +- >>> 2 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> index e6bf633b48d5..03732e3f5ec7 100644 >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c >>> @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>> list_for_each_entry_safe_reverse(rq, rn, >>> &engine->active.requests, >>> sched.link) { >>> - struct intel_engine_cs *owner; >>> >>> if (i915_request_completed(rq)) >>> continue; /* XXX */ >>> @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>> * engine so that it can be moved across onto another physical >>> * engine as load dictates. >>> */ >>> - owner = rq->hw_context->engine; >>> - if (likely(owner == engine)) { >>> + if (likely(rq->execution_mask == engine->mask)) { >>> GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); >>> if (rq_prio(rq) != prio) { >>> prio = rq_prio(rq); >>> @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>> list_move(&rq->sched.link, pl); >>> active = rq; >>> } else { >>> + struct intel_engine_cs *owner = rq->hw_context->engine; >> >> I guess there is some benefit in doing fewer operations as long as we >> are fixing the engine anyway (at the moment at least). >> >> However on this branch here the concern was request completion racing >> with preemption handling and with this change the breadcrumb will not >> get canceled any longer and may get signaled on the virtual engine. >> Which then leads to the explosion this branch fixed. At least that's >> what I remembered in combination with the comment below.. > > No, we don't change back to the virtual engine, so that is not an issue. > The problem was only because of the rq->engine = owner where the > breadcrumbs were still on the previous engine lists and assumed to be > under that engine->breadcrumbs.lock (but would in future be assumed to be > under rq->engine->breadcrumbs.lock). Breadcrumb signaling can only be set up on the physical engine? Hm, must be fine since without preemption that would be the scenario exactly. Okay, I see there is r-b from Ram already so no need for another one. Regards, Tvrtko
Quoting Tvrtko Ursulin (2019-10-14 10:50:25) > > On 14/10/2019 10:41, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-10-14 10:34:31) > >> > >> On 13/10/2019 21:30, Chris Wilson wrote: > >>> Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from > >>> overtaking each other on preemption") we have restricted requests to run > >>> on their chosen engine across preemption events. We can take this > >>> restriction into account to know that we will want to resubmit those > >>> requests onto the same physical engine, and so can shortcircuit the > >>> virtual engine selection process and keep the request on the same > >>> engine during unwind. > >>> > >>> References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") > >>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > >>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >>> --- > >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- > >>> drivers/gpu/drm/i915/i915_request.c | 2 +- > >>> 2 files changed, 4 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > >>> index e6bf633b48d5..03732e3f5ec7 100644 > >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > >>> @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > >>> list_for_each_entry_safe_reverse(rq, rn, > >>> &engine->active.requests, > >>> sched.link) { > >>> - struct intel_engine_cs *owner; > >>> > >>> if (i915_request_completed(rq)) > >>> continue; /* XXX */ > >>> @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > >>> * engine so that it can be moved across onto another physical > >>> * engine as load dictates. > >>> */ > >>> - owner = rq->hw_context->engine; > >>> - if (likely(owner == engine)) { > >>> + if (likely(rq->execution_mask == engine->mask)) { > >>> GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); > >>> if (rq_prio(rq) != prio) { > >>> prio = rq_prio(rq); > >>> @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) > >>> list_move(&rq->sched.link, pl); > >>> active = rq; > >>> } else { > >>> + struct intel_engine_cs *owner = rq->hw_context->engine; > >> > >> I guess there is some benefit in doing fewer operations as long as we > >> are fixing the engine anyway (at the moment at least). > >> > >> However on this branch here the concern was request completion racing > >> with preemption handling and with this change the breadcrumb will not > >> get canceled any longer and may get signaled on the virtual engine. > >> Which then leads to the explosion this branch fixed. At least that's > >> what I remembered in combination with the comment below.. > > > > No, we don't change back to the virtual engine, so that is not an issue. > > The problem was only because of the rq->engine = owner where the > > breadcrumbs were still on the previous engine lists and assumed to be > > under that engine->breadcrumbs.lock (but would in future be assumed to be > > under rq->engine->breadcrumbs.lock). > > Breadcrumb signaling can only be set up on the physical engine? Hm, must > be fine since without preemption that would be the scenario exactly. > Okay, I see there is r-b from Ram already so no need for another one. With no disrespect to Ram, as the expert you raised a technical point that I would be happier to record as resolved with an r-b from yourself. -Chris
On 14/10/2019 10:59, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2019-10-14 10:50:25) >> >> On 14/10/2019 10:41, Chris Wilson wrote: >>> Quoting Tvrtko Ursulin (2019-10-14 10:34:31) >>>> >>>> On 13/10/2019 21:30, Chris Wilson wrote: >>>>> Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from >>>>> overtaking each other on preemption") we have restricted requests to run >>>>> on their chosen engine across preemption events. We can take this >>>>> restriction into account to know that we will want to resubmit those >>>>> requests onto the same physical engine, and so can shortcircuit the >>>>> virtual engine selection process and keep the request on the same >>>>> engine during unwind. >>>>> >>>>> References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") >>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> >>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >>>>> --- >>>>> drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- >>>>> drivers/gpu/drm/i915/i915_request.c | 2 +- >>>>> 2 files changed, 4 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c >>>>> index e6bf633b48d5..03732e3f5ec7 100644 >>>>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c >>>>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c >>>>> @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>>>> list_for_each_entry_safe_reverse(rq, rn, >>>>> &engine->active.requests, >>>>> sched.link) { >>>>> - struct intel_engine_cs *owner; >>>>> >>>>> if (i915_request_completed(rq)) >>>>> continue; /* XXX */ >>>>> @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>>>> * engine so that it can be moved across onto another physical >>>>> * engine as load dictates. >>>>> */ >>>>> - owner = rq->hw_context->engine; >>>>> - if (likely(owner == engine)) { >>>>> + if (likely(rq->execution_mask == engine->mask)) { >>>>> GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); >>>>> if (rq_prio(rq) != prio) { >>>>> prio = rq_prio(rq); >>>>> @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) >>>>> list_move(&rq->sched.link, pl); >>>>> active = rq; >>>>> } else { >>>>> + struct intel_engine_cs *owner = rq->hw_context->engine; >>>> >>>> I guess there is some benefit in doing fewer operations as long as we >>>> are fixing the engine anyway (at the moment at least). >>>> >>>> However on this branch here the concern was request completion racing >>>> with preemption handling and with this change the breadcrumb will not >>>> get canceled any longer and may get signaled on the virtual engine. >>>> Which then leads to the explosion this branch fixed. At least that's >>>> what I remembered in combination with the comment below.. >>> >>> No, we don't change back to the virtual engine, so that is not an issue. >>> The problem was only because of the rq->engine = owner where the >>> breadcrumbs were still on the previous engine lists and assumed to be >>> under that engine->breadcrumbs.lock (but would in future be assumed to be >>> under rq->engine->breadcrumbs.lock). >> >> Breadcrumb signaling can only be set up on the physical engine? Hm, must >> be fine since without preemption that would be the scenario exactly. >> Okay, I see there is r-b from Ram already so no need for another one. > > With no disrespect to Ram, as the expert you raised a technical point that > I would be happier to record as resolved with an r-b from yourself. I went back to the patch I reviewed in July and it checks out. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Regards, Tvrtko
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index e6bf633b48d5..03732e3f5ec7 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) list_for_each_entry_safe_reverse(rq, rn, &engine->active.requests, sched.link) { - struct intel_engine_cs *owner; if (i915_request_completed(rq)) continue; /* XXX */ @@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) * engine so that it can be moved across onto another physical * engine as load dictates. */ - owner = rq->hw_context->engine; - if (likely(owner == engine)) { + if (likely(rq->execution_mask == engine->mask)) { GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID); if (rq_prio(rq) != prio) { prio = rq_prio(rq); @@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) list_move(&rq->sched.link, pl); active = rq; } else { + struct intel_engine_cs *owner = rq->hw_context->engine; + /* * Decouple the virtual breadcrumb before moving it * back to the virtual engine -- we don't want the diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 437f9fc6282e..b8a54572a4f8 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -649,6 +649,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) rq->gem_context = ce->gem_context; rq->engine = ce->engine; rq->ring = ce->ring; + rq->execution_mask = ce->engine->mask; rcu_assign_pointer(rq->timeline, tl); rq->hwsp_seqno = tl->hwsp_seqno; @@ -671,7 +672,6 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp) rq->batch = NULL; rq->capture_list = NULL; rq->flags = 0; - rq->execution_mask = ALL_ENGINES; INIT_LIST_HEAD(&rq->execute_cb);
Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") we have restricted requests to run on their chosen engine across preemption events. We can take this restriction into account to know that we will want to resubmit those requests onto the same physical engine, and so can shortcircuit the virtual engine selection process and keep the request on the same engine during unwind. References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- drivers/gpu/drm/i915/i915_request.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-)