On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
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.
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
