On Fri, Mar 03, 2017 at 07:57:24PM +0200, Mika Kuoppala wrote: > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > --- > > 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 -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
