[PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

[Umesh Nerlige Ramappa]

On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
>   On April 30, 2021 18:00:58 "Dixit, Ashutosh" <ashutosh.dixit at intel.com>
>   wrote:
>
>     On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
>
>       Looks like the engine can be dropped since all timestamps are in sync.
>       I
>       just have one more question here. The timestamp itself is 36 bits.
>        Should
>       the uapi also report the timestamp width to the user OR should I just
>       return the lower 32 bits of the timestamp?
>
>   Yeah, I think reporting the timestamp width is a good idea since we're
>   reporting the period/frequency here.

Actually, I forgot that we are handling the overflow before returning 
the cs_cycles to the user and overflow handling was the only reason I 
thought user should know the width. Would you stil recommend returning 
the width in the uapi?

Thanks,
Umesh


>
>     How would exposing only the lower 32 bits of the timestamp work?
>     The way to avoid exposing the width would be to expose the timestamp as
>     a
>     regular 64 bit value. In the kernel engine state, have a variable for
>     the
>     counter and keep on accumulating that (on each query) to full 64 bits in
>     spite of the 36 bit HW counter overflow.
>
>   That's doesn't actually work since you can query the 64-bit timestamp
>   value from the GPU. The way this is handled in Vulkan is that the number
>   of timestamp bits is reported to the application as a queue property.
>   --Jason