Re: [PATH i-g-t v12 2/2] tests: add slice power programming test

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tursulin@ursulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	igt-dev@lists.freedesktop.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATH i-g-t v12 2/2] tests: add slice power programming test
Date: Thu, 13 Sep 2018 11:48:00 +0100	[thread overview]
Message-ID: <153683568037.31648.14665328939907661004@skylake-alporthouse-com> (raw)
In-Reply-To: <ad7750a8-3820-6f2b-8cbd-ed59901b3bb5@linux.intel.com>

Quoting Tvrtko Ursulin (2018-09-13 11:38:47)
> 
> On 12/09/2018 12:53, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-09-11 15:42:10)
> > I would also suggest a reset test here. Both reset when idle, and by
> > hangcheck/forced-reset of the spinner & active context.
> > 
> > And across suspend.
> 
> Reset & suspsend after set param but before execbuf? Or after execbuf 
> and then re-read rpcs?

My concern is making sure that after the reset/suspend the adjusted sseu
is still in effect.

For reset, I think the hardest case is if the spinning batch (causing us
to use the MI_STORE_DATA_IMM path) itself hangs. An idle/reset is only
borderline interesting. For that it's just the question of whether
resetting the gpu breaks everything -- but we reset the gpu frequently
enough (on load, on resume) that there's no getting away from it :)

Argh, there's another dilemma here... The wedged driver. In that case,
it should still work as although we may lose the request to set the sseu
in flight, if we ever use the gpu again, we will repin the context and
so reset the sseu.

For suspend, I can see an argument for both idle/suspend and
active/suspend to check that the settings are preserved across the
suspend. In the first case, the path we take will apply them afterwards,
in the latter case, we will apply the settings again on resume. So maybe
there isn't much point to the second case. However, it does all presume
that we do remember to repin the context (so probably worth exercising).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx