On April 30, 2021 18:00:58 "Dixit, Ashutosh" <ashutosh.dixit@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.

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