[Intel-gfx] [PATCH] drm/i915/selftests: Measure CS_TIMESTAMP

[Ville Syrjälä]

On Tue, May 19, 2020 at 11:46:54AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-05-19 11:42:45)
> > On Sat, May 16, 2020 at 02:31:02PM +0100, Chris Wilson wrote:
> > > Count the number of CS_TIMESTAMP ticks and check that it matches our
> > > expectations.
> > 
> > Looks ok for everything except g4x/ilk. Those would need something
> > like
> > https://patchwork.freedesktop.org/patch/355944/?series=74145&rev=1
> > + read TIMESTAMP_UDW instead of TIMESTAMP.
> > 
> > bw/cl still needs
> > https://patchwork.freedesktop.org/patch/355946/?series=74145&rev=1
> > though the test seems a bit flaky on my cl. Sometimes the cycle count
> > comes up short. Never seen it exceed the expected value, but it can 
> > come up significantly short. And curiously it does seem to have a
> > tendency to come out as roughly some nice fraction (seen at least
> > 1/2 and 1/4 quite a few times). Dunno if the tick rate actually
> > changes due to some unknown circumstances, or if the counter just
> > updates somehow lazily. Certainly polling the counter over a longer
> > period does show it to tick at the expected rate.
> 
> Any guestimate at how short a period is long enough?

After a bit more debugging it looks like the read just sometimes returns
a stale value:
[ 5248.749794] rcs0: 0: TIMESTAMP 75->123 (48) cycles [1013808ns]
[ 5248.749817] rcs0: 1: TIMESTAMP 202859->202859 (0) cycles [1031688ns]
[ 5248.749818] rcs0: 2: TIMESTAMP 409179->613179 (204000) cycles [1020234ns]
[ 5248.749820] rcs0: 3: TIMESTAMP 613227->825083 (211856) cycles [1059623ns]
[ 5248.749821] rcs0: 4: TIMESTAMP 825163->1036491 (211328) cycles [1057109ns]

So far it looks like doing a double read is sufficient to get
an up to date value.

-- 
Ville Syrjälä
Intel