Re: [PATCH v3] Idleness DRRS test

["Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>]

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.

-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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx