[Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

Daniel Vetter daniel at ffwll.ch
Thu Oct 13 15:17:40 UTC 2016


On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote:
> On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote:
> > 
> > 
> > On 10/12/2016 03:07 PM, Chris Wilson wrote:
> > > On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote:
> > >> Signed-off-by: Abdiel Janulgue <abdiel.janulgue at linux.intel.com>
> > >> ---
> > >>  tests/gem_wait.c | 77 +++++++++-----------------------------------------------
> > >>  1 file changed, 12 insertions(+), 65 deletions(-)
> > > 
> > > We can do so much better than a dummy load here. We can precisely
> > > control how long we want the object to be busy by using a recursive
> > > batch buffer (and terminating that batch at the exact moment we require).
> > > -Chris
> > > 
> > Hi Chris, I see you've posted a better solution to gem_wait. I could
> > drop this one and defer to yours instead. So for now, igt_dummyload has
> > dropped to only 1 customer at the moment: kms_flip.  Let me know whether
> > it's possible to upstream this dummyload api.
> 
> kms_flip would probably be better with a specific load rather than a
> dummy as well. The challenge is whether the flip works given various
> input states of the framebuffers, and the more control we have over
> those inputs the better.

Oh yeah, this is a pretty sweet idea with a spinning batch that we
manually terminate. Assuming it works everywhere I think this is a much
better approach, and by submitting different workloads we can always put
the delay workload exactly where we want.

Abdiel, can you pls update the JIRA to instead extract Chris' trick into a
library (pretty sure Chris can help with bikeshedding the interface to
make it all pretty) and then roll that one out? Being able to control the
time used by delay tasks down to jiffies is real sweet.

Also there might be some space to reuse this with Mika's hangcheck stuff,
not sure.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list