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
