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
>