[Intel-gfx] [PATCH] drm/i915: Warn when execlists changes context without IRQs

[Chris Wilson]

On Tue, May 12, 2015 at 10:42:41AM +0200, Daniel Vetter wrote:
> On Tue, May 12, 2015 at 09:18:00AM +0100, Chris Wilson wrote:
> > On Tue, May 12, 2015 at 08:42:58AM +0200, Daniel Vetter wrote:
> > > On Mon, May 11, 2015 at 09:26:40PM +0100, Chris Wilson wrote:
> > > > On Mon, May 11, 2015 at 06:37:14PM +0200, Daniel Vetter wrote:
> > > > > On Mon, May 11, 2015 at 04:03:27PM +0100, Peter Antoine wrote:
> > > > > > If an batch ends while the IRQs are not turned on the notification can
> > > > > > go missing and the GPU can hang. So generate a warning in this case.
> > > > > > 
> > > > > > Signed-off-by: Peter Antoine <peter.antoine at intel.com>
> > > > > 
> > > > > Queued for -next, thanks for the patch.
> > > > 
> > > > Please drop this. We already have the test inside the irq handler. The
> > > > instance where you want the guard is during resume, inside
> > > > intel_lr_context_render_state_init() where you can even emit an error
> > > > code!
> > > 
> > > _unqueue is also called from intel_logical_ring_advance_and_submit and
> > > should cover us I hope. And I don't think we should add error handling for
> > > this, that has cost of its own.
> > 
> > Pardon? Your explanation for adding it to the *interrupt* handler after
> > an existing check is that it also catches the initial submission?
> 
> I wanted to add it as low down as possible to increase changes of the
> check surviving refactoring. This way it's as close to possible to the
> writes to the submit ports. Yes that means it's also run from interrupt
> context when requeueing, but I'm fairly meh about that. What's your
> concern?

The interrupt handler + submission is the ratelimiting factor in
execlists throughput. Tests for external factors really should be on the
boundary.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre