/ appendices / VK_EXT_calibrated_timestamps.txt
VK_EXT_calibrated_timestamps.txt
  1  include::meta//VK_EXT_calibrated_timestamps.txt[]
  2  
  3  *Last Modified Date*::
  4      2018-10-04
  5  *IP Status*::
  6      No known IP claims.
  7  *Contributors*::
  8    - Matthaeus G. Chajdas, AMD
  9    - Alan Harrison, AMD
 10    - Derrick Owens, AMD
 11    - Daniel Rakos, AMD
 12    - Jason Ekstrand, Intel
 13    - Keith Packard, Valve
 14  
 15  This extension provides an interface to query calibrated timestamps obtained
 16  quasi simultaneously from two time domains.
 17  
 18  === New Object Types
 19  
 20  None.
 21  
 22  === New Enum Constants
 23  
 24    * Extending elink:VkStructureType:
 25    ** ename:VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT
 26  
 27  === New Enums
 28  
 29    * elink:VkTimeDomainEXT
 30  
 31  === New Structures
 32  
 33    * slink:VkCalibratedTimestampInfoEXT
 34  
 35  === New Functions
 36  
 37    * flink:vkGetPhysicalDeviceCalibrateableTimeDomainsEXT
 38    * flink:vkGetCalibratedTimestampsEXT
 39  
 40  === Issues
 41  
 42  1) Is the device timestamp value returned in the same time domain as the
 43  timestamp values written by flink:vkCmdWriteTimestamp?
 44  
 45  *RESOLVED*: Yes.
 46  
 47  2) What time domain is the host timestamp returned in?
 48  
 49  *RESOLVED*: A query is provided to determine the calibrateable time domains.
 50  The expected host time domain used on Windows is that of
 51  QueryPerformanceCounter, and on Linux that of CLOCK_MONOTONIC.
 52  
 53  3) Should we support other time domain combinations than just one host and
 54  the device time domain?
 55  
 56  *RESOLVED*: Supporting that would need the application to query the set of
 57  supported time domains, while supporting only one host and the device time
 58  domain would only need a query for the host time domain type.
 59  The proposed API chooses the general approach for the sake of extensibility.
 60  
 61  4) Shouldn't we use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC?
 62  
 63  *RESOLVED*: CLOCK_MONOTONIC is usable in a wider set of situations, however,
 64  it is subject to NTP adjustments so some use cases may prefer
 65  CLOCK_MONOTONIC_RAW.
 66  Thus this extension allows both to be exposed.
 67  
 68  5) How can the application extrapolate future device timestamp values from
 69  the calibrated timestamp value?
 70  
 71  *RESOLVED*: slink:VkPhysicalDeviceLimits::pname:timestampPeriod makes it
 72  possible to calculate future device timestamps as follows:
 73  
 74  [source,c]
 75  ---------------------------------------------------
 76  futureTimestamp = calibratedTimestamp + deltaNanoseconds / timestampPeriod
 77  ---------------------------------------------------
 78  
 79  6) Can the host and device timestamp values drift apart over longer periods
 80  of time?
 81  
 82  *RESOLVED*: Yes, especially as some time domains by definition allow for
 83  that to happen (e.g. CLOCK_MONOTONIC is subject to NTP adjustments).
 84  Thus it's recommended that applications re-calibrate from time to time.
 85  
 86  7) Should we add a query for reporting the maximum deviation of the
 87  timestamp values returned by calibrated timestamp queries?
 88  
 89  *RESOLVED*: A global query seems inappropriate and difficult to enforce.
 90  However, it's possible to return the maximum deviation any single calibrated
 91  timestamp query can have by sampling one of the time domains twice as
 92  follows:
 93  
 94  [source,c]
 95  ---------------------------------------------------
 96  timestampX = timestampX_before = SampleTimeDomain(X)
 97  for each time domain Y != X
 98      timestampY = SampleTimeDomain(Y)
 99  timestampX_after = SampleTimeDomain(X)
100  maxDeviation = timestampX_after - timestampX_before
101  ---------------------------------------------------
102  
103  8) Can the maximum deviation reported ever be zero?
104  
105  *RESOLVED*: Unless the tick of each clock corresponding to the set of time
106  domains coincides and all clocks can literally be sampled simutaneously,
107  there isn't really a possibility for the maximum deviation to be zero, so by
108  convention the maximum deviation is always at least the maximum of the
109  length of the ticks of the set of time domains calibrated and thus can never
110  be zero.
111  
112  === Version History
113  
114    * Revision 1, 2018-10-04 (Daniel Rakos)
115      - Internal revisions.