[PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

[Keith Packard]

Pekka Paalanen <ppaalanen at gmail.com> writes:

> On Sat, 23 Jun 2018 12:13:53 -0500
> Jason Ekstrand <jason at jlekstrand.net> wrote:
>
>> I haven't thought through this comment all that hard but would it make 
>> sense to have three timestamps, CPU, GPU, CPU so that you have error bars 
>> on the GPU timestamp?  At the very least, two timestamps would be better 
>> than one so that, when we pull it into the kernel, it can provide something 
>> more accurate than userspace trying to grab a snapshot.
>
> Hi,
>
> three timestamps sounds like a good idea to me, but you might want to
> reach out to media developers (e.g. gstreamer) who have experience in
> synchronizing different clocks and what that will actually take.

Oh, I know that's really hard, and I don't want to solve that problem
here. I explicitly *don't* solve it though -- I simply expose the
ability to get correlated values in the two application-visible time
domains that the Vulkan API already exposes (surface time and GPU
time). How to synchronize the application as those two clocks drift
around is outside the domain of this extension.

> When reading the CPU timestamp, I believe it would be necessary for
> userspace to tell which clock it should be reading. I'm not sure all
> userspace is always using CLOCK_MONOTONIC. But if you have a better
> rationale, that would be interesting to record and document.

The extension doesn't state which clock is returned, you provide a
device and a surface and get timestamps for both of them. This allows
applications to translate between the two Vulkan time domains.

As far as the implementation goes, it asks the device driver to get
correlated GPU and CLOCK_MONOTONIC values and then asks the WSI layer to
translate between CLOCK_MONOTONIC and surface time. Right now, all three
surface types already operate in CLOCK_MONOTONIC natively, so there
isn't any translation needed to surface time.

The anv and radv driver implementations are simplistic and could easily
be improved; they both simply fetch the GPU clock and then
CLOCK_MONOTONIC sequentially without attempting to bound the error
between them.

The entire reason for this extension is to allow me to implement the
GOOGLE_display_timing extension using only public interfaces into the
drivers. That patch is blocked on getting this functionality landed.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180710/abffabed/attachment.sig>