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