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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux