[Intel-gfx] [PATCH igt] igt/kms_flip: Calibrate timestamp errors

[Chris Wilson]

On Wed, Oct 26, 2016 at 08:18:13AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 10:38:34AM +0100, Chris Wilson wrote:
> > On Mon, Oct 24, 2016 at 11:14:31AM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 24, 2016 at 09:54:52AM +0100, Chris Wilson wrote:
> > > Also with this patch we should be able to throw out the hacks for tv-out.
> > > I only added those because the reported mode-timings are massively off
> > > (due to the magic tv scaler thing) from the real timestamps we receive.
> > > Auto-detecting this is much better.
> > 
> > Not quite just yet, we need to split the timing tests into a subgroup
> > with a subtest per output so that we can skip one without skipping the
> > others. At the moment, this check makes it bail out on my ctg/ilk who
> > have a difference of about 50us between measured and expected vblank
> > interval on LVDS (which is nigh on impossible given our confidence in the
> > measurement, i.e. about 7 sigma).
> 
> Hm, should we be a bit more sloppy in our acceptance? Iirc Ville has made
> changes to make it a bit more strict a while ago, and way, way back this
> stuff worked on my ctg. Haven't fired it up in a while ;-)

Our vblank intervals are pretty stable, so the time compensation for the
interrupt latency is within a scanline. (Of the top of my head, stddev
for the interval is approximately half a scanline.) We are consistent at
least :)

The problem is just that we use the dotclock as our expected value for
the timing tests. I considered changing that but frame_time() wasn't
just used for the TEST_TS pass and I was less confident about the other
uses. But for our subtest, we could get away with using the computed
interval...
 
> > > And another issue: Failing to match the reported mode timings is a driver
> > > bug.
> > 
> > Not quite, remember we override the user for fixed mode panels. But yes,
> > piglit also has a similar expectation that the dotclock we report (via
> > GetMscRate) in someway corresponds to actual vblank interval.
> 
> Yeah, I hope that DRRS would fix that, at least on newer stuff. At least I
> proposed just using the matching dotclock for manual DRRS (mostly to
> perfectly match with the refresh rate of a video). Didn't yet happen :(

Yup, DRRS breaks all the expectations userspace has that MscRate is
fixed. Even a simple mode change leads to trouble.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre