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

Jason Ekstrand jason at jlekstrand.net
Sat May 1 00:35:41 UTC 2021


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.

>>
> 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
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20210430/6d040e47/attachment-0001.htm>


More information about the Intel-gfx mailing list