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@xxxxxxxxx> > > > > > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
