Quoting Lionel Landwerlin (2020-08-11 16:37:10) > On 11/08/2020 12:17, Chris Wilson wrote: > > We assume that both timestamps are driven off the same clock [reported > > to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is > > so by reading the timestamp registers around a busywait (on an otherwise > > idle engine so there should be no preemptions). > > > > v2: Icelake (not ehl, nor tgl) seems to be using a fixed 80ns interval > > for, and only for, CTX_TIMESTAMP. As far as I can tell, this behaviour > > is undocumented. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > > I really thought the CTX_TIMESTAMP was running 8 times slower : > > > For the 2015 - 2016 Intel CoreTM Processors, CeleronTM Processors, > and PentiumTM Processors based on the "Skylake" Platform > > Volume 2c: Command Reference: Registers > Part 1 – Registers A through L > > May 2016, Revision 1.0 > > CTX_TIMESTAMP - Context Timestamp Count: > > The granularity of this toggle is at the rate of the bit 3 in the > "Reported Timestamp Count" > register(0x2358).. The toggle will be 8 times slower that "Reported > Timestamp Count". The > granularity of the time stamp base unit for "Reported Timestamp Count" > is defined in the > “Timestamp Bases” subsection in Power Management chapter. I read that paragraph in the same way, that the CTX_TIMESTAMP is only being advanced [by 1 tick] on every 8th tick of CS_TIMESTAMP. That turns out to be not what happens... So I guess they mean that CTX_TIMESTAMP increments by 8 every 8th tick. I haven't bothered to check to see if there's anything in the low 2 bits of CTX_TIMESTAMP. Still nothing mentions that Icelake has a completely different behaviour afaict. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
