[Intel-gfx] [PATCH v3] Idleness DRRS test

[Daniel Vetter]

On Tue, Nov 29, 2016 at 03:06:17PM +0530, Nautiyal, Ankit K wrote:
> As per discussion with Chris, on IRC following were the suggestions :
> 
> - Chris has suggested an event based approach to avoid using pthreads.
> 
> - Avoid using kernel-specific info like transitional delays and instead use
> either polling or wait-for-event approach. Need to focus on user-observable
> behavior rather than the kernel standpoint.
> 
> - Check for transition latency is unnecessary in this test, as this is more
> of a performance/power benchmark.
> 
> 
> I will try the event based mechanism to do away with pthreads, and
> incorporate these suggestions in the next patch-set.

Again, why is kms_frontbuffer_tracking not considered? Reinventing wheels
is not good, and kms_frontbuffer_tracking implements all of the above
stuff afaik.
-Daniel

> 
> -Ankit
> 
> 
> On 11/15/2016 2:28 PM, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 01:06:09PM +0000, Chris Wilson wrote:
> > > On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> > > > Chris, happy with this revision?
> > > Me? No. It still uses a thread instead of events, so I don't think it
> > > qualifies as a good example for anyone else wanting to do the same thing.
> > > Lots of hardcoded expectations (specific sleep patterns, rather than
> > > waiting for the kernel to change with a timeout for failure). It doesn't
> > > check all the possible ways that the output maybe changed (and if they
> > > are irrelevent, that too also needs to be tested to establish expected
> > > behaviour and catch future regressions). Important question, how is
> > > userspace expected to know that the vrefresh changed? How do get around
> > > that userspace is expecting a fixed vblank frequency?
> > for display power testing we already have the kms_frontbuffer_tracking
> > testcase, adding a DRRS variants to that one should resolve all this.
> > 
> > And then kms_drrs would be empty, except when we (if ever) do explicit
> > drrs through modeset requests. And that would just be checking that the
> > observed timings match the requested timings.
> > -Daniel
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch