• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1// Copyright 2018-2021 The Khronos Group Inc.
2//
3// SPDX-License-Identifier: CC-BY-4.0
4
5include::{generated}/meta/{refprefix}VK_EXT_calibrated_timestamps.txt[]
6
7=== Other Extension Metadata
8
9*Last Modified Date*::
10    2018-10-04
11*IP Status*::
12    No known IP claims.
13*Contributors*::
14  - Matthaeus G. Chajdas, AMD
15  - Alan Harrison, AMD
16  - Derrick Owens, AMD
17  - Daniel Rakos, AMD
18  - Jason Ekstrand, Intel
19  - Keith Packard, Valve
20
21=== Description
22
23This extension provides an interface to query calibrated timestamps obtained
24quasi simultaneously from two time domains.
25
26include::{generated}/interfaces/VK_EXT_calibrated_timestamps.txt[]
27
28=== Issues
29
301) Is the device timestamp value returned in the same time domain as the
31timestamp values written by flink:vkCmdWriteTimestamp?
32
33*RESOLVED*: Yes.
34
352) What time domain is the host timestamp returned in?
36
37*RESOLVED*: A query is provided to determine the calibrateable time domains.
38The expected host time domain used on Windows is that of
39QueryPerformanceCounter, and on Linux that of CLOCK_MONOTONIC.
40
413) Should we support other time domain combinations than just one host and
42the device time domain?
43
44*RESOLVED*: Supporting that would need the application to query the set of
45supported time domains, while supporting only one host and the device time
46domain would only need a query for the host time domain type.
47The proposed API chooses the general approach for the sake of extensibility.
48
494) Should we use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC?
50
51*RESOLVED*: CLOCK_MONOTONIC is usable in a wider set of situations, however,
52it is subject to NTP adjustments so some use cases may prefer
53CLOCK_MONOTONIC_RAW.
54Thus this extension allows both to be exposed.
55
565) How can the application extrapolate future device timestamp values from
57the calibrated timestamp value?
58
59*RESOLVED*: slink:VkPhysicalDeviceLimits::pname:timestampPeriod makes it
60possible to calculate future device timestamps as follows:
61
626) In what queue are timestamp values in time domain
63ename:VK_TIME_DOMAIN_DEVICE_EXT captured by
64flink:vkGetCalibratedTimestampsEXT?
65
66*RESOLVED*: An implementation supporting this extension will have all its
67VkQueue share the same time domain.
68
69[source,c]
70---------------------------------------------------
71futureTimestamp = calibratedTimestamp + deltaNanoseconds / timestampPeriod
72---------------------------------------------------
73
746) Can the host and device timestamp values drift apart over longer periods
75of time?
76
77*RESOLVED*: Yes, especially as some time domains by definition allow for
78that to happen (e.g. CLOCK_MONOTONIC is subject to NTP adjustments).
79Thus it is recommended that applications re-calibrate from time to time.
80
817) Should we add a query for reporting the maximum deviation of the
82timestamp values returned by calibrated timestamp queries?
83
84*RESOLVED*: A global query seems inappropriate and difficult to enforce.
85However, it is possible to return the maximum deviation any single
86calibrated timestamp query can have by sampling one of the time domains
87twice as follows:
88
89[source,c]
90---------------------------------------------------
91timestampX = timestampX_before = SampleTimeDomain(X)
92for each time domain Y != X
93    timestampY = SampleTimeDomain(Y)
94timestampX_after = SampleTimeDomain(X)
95maxDeviation = timestampX_after - timestampX_before
96---------------------------------------------------
97
988) Can the maximum deviation reported ever be zero?
99
100*RESOLVED*: Unless the tick of each clock corresponding to the set of time
101domains coincides and all clocks can literally be sampled simutaneously,
102there is not really a possibility for the maximum deviation to be zero, so
103by convention the maximum deviation is always at least the maximum of the
104length of the ticks of the set of time domains calibrated and thus can never
105be zero.
106
107=== Version History
108
109  * Revision 2, 2021-03-16 (Lionel Landwerlin)
110    - Specify requirement on device timestamps
111  * Revision 1, 2018-10-04 (Daniel Rakos)
112    - Internal revisions.
113