| Message ID | 20170303121710.14497-3-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Chris Wilson <chris@chris-wilson.co.uk> writes: > As we now check if the seqno is complete in order to signal the fence, > we can also decide not to wake up the first_waiter until it is ready > (since it is waiting on the same seqno). The only caveat is that if we > need the engine->irq_seqno_barrier to enforce some coherency between an > interrupt and the seqno read, we have to always wake the waiter into to > perform that heavyweight barrier. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/i915_irq.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 3f39e36fa566..c902aff61a9d 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -1059,7 +1059,8 @@ static void notify_ring(struct intel_engine_cs *engine) > wait->seqno)) > rq = wait->request; > > - wake_up_process(wait->tsk); > + if (rq || engine->irq_seqno_barrier) > + wake_up_process(wait->tsk); This also needs to be respinned on top of getting the request ref. Were you thinking < gen5 or daydreaming that the next shiny one doesn't need a barrier? :) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> > } else { > __intel_engine_disarm_breadcrumbs(engine); > } > -- > 2.11.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Mar 03, 2017 at 07:57:24PM +0200, Mika Kuoppala wrote: > Chris Wilson <chris@chris-wilson.co.uk> writes: > > > As we now check if the seqno is complete in order to signal the fence, > > we can also decide not to wake up the first_waiter until it is ready > > (since it is waiting on the same seqno). The only caveat is that if we > > need the engine->irq_seqno_barrier to enforce some coherency between an > > interrupt and the seqno read, we have to always wake the waiter into to > > perform that heavyweight barrier. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > --- > > drivers/gpu/drm/i915/i915_irq.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > > index 3f39e36fa566..c902aff61a9d 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -1059,7 +1059,8 @@ static void notify_ring(struct intel_engine_cs *engine) > > wait->seqno)) > > rq = wait->request; > > > > - wake_up_process(wait->tsk); > > + if (rq || engine->irq_seqno_barrier) > > + wake_up_process(wait->tsk); > > This also needs to be respinned on top of getting the request ref. > > Were you thinking < gen5 or daydreaming that the next shiny one doesn't > need a barrier? :) execlists+ doesn't use a barrier, and we depend upon that for the guc scheduler. And there's nothing wrong with giving Pineview that little bit of an extra boost! -Chris
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 3f39e36fa566..c902aff61a9d 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1059,7 +1059,8 @@ static void notify_ring(struct intel_engine_cs *engine) wait->seqno)) rq = wait->request; - wake_up_process(wait->tsk); + if (rq || engine->irq_seqno_barrier) + wake_up_process(wait->tsk); } else { __intel_engine_disarm_breadcrumbs(engine); }
As we now check if the seqno is complete in order to signal the fence, we can also decide not to wake up the first_waiter until it is ready (since it is waiting on the same seqno). The only caveat is that if we need the engine->irq_seqno_barrier to enforce some coherency between an interrupt and the seqno read, we have to always wake the waiter into to perform that heavyweight barrier. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_irq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)