[Intel-gfx] [RFC 03/11] drm/i915: Add reset stats entry point for per-engine reset.

Chris Wilson chris at chris-wilson.co.uk
Tue Jun 16 06:54:49 PDT 2015


On Tue, Jun 16, 2015 at 03:48:09PM +0200, Daniel Vetter wrote:
> On Mon, Jun 08, 2015 at 06:33:59PM +0100, Chris Wilson wrote:
> > On Mon, Jun 08, 2015 at 06:03:21PM +0100, Tomas Elf wrote:
> > > In preparation for per-engine reset add way for setting context reset stats.
> > > 
> > > OPEN QUESTIONS:
> > > 1. How do we deal with get_reset_stats and the GL robustness interface when
> > > introducing per-engine resets?
> > > 
> > > 	a. Do we set context that cause per-engine resets as guilty? If so, how
> > > 	does this affect context banning?
> > 
> > Yes. If the reset works quicker, then we can set a higher threshold for
> > DoS detection, but we still do need Dos detection?
> >  
> > > 	b. Do we extend the publically available reset stats to also contain
> > > 	per-engine reset statistics? If so, would this break the ABI?
> > 
> > No. The get_reset_stats is targetted at the GL API and describing it in
> > terms of whether my context is guilty or has been affected. That is
> > orthogonal to whether the reset was on a single ring or the entire GPU -
> > the question is how broad do want the "affected" to be. Ideally a
> > per-context reset wouldn't necessarily impact others, except for the
> > surfaces shared between them...
> 
> gl computes sharing sets itself, the kernel only tells it whether a given
> context has been victimized, i.e. one of it's batches was not properly
> executed due to reset after a hang.

So you don't think we should delete all pending requests that depend
upon state from the hung request?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list