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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
