mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-25 12:35:11 +00:00
5abf83f95d
* Update release number to 107.
Public Issues:
* Fix revision date for the `<<VK_AMD_gpu_shader_half_float>>` appendix
(public issue 617).
* Make <<synchronization-pipeline-barriers-subpass-self-dependencies,
subpass self-dependencies>> less restrictive (public issue 777).
* Fix the `<<VK_EXT_full_screen_exclusive>>` dependency on
`<<VK_KHR_win32_surface>>` in `vk.xml` (public pull request 849).
* Remove single-page (`apispec.html`) refpage sub-targets from the
Makefile `allman` target and the build instructions. The target is still
present in the Makefile, but we have not been actively maintaining the
single-page document and do not promise it will work. The full
Specification and the individual API reference pages are what we support
and publish at present (public issue 949).
Internal Issues:
* De-duplicate common valid usage statements shared by multiple commands
or structures by using asciidoctor includes and dynamically assigning
part of the valid usage ID based on which command or structure they're
being applied to (internal issue 779).
* Add reference pages for constructs not part of the formal API, such as
platform calling convention macros, and script changes supporting them
This required suppressing some check_spec_links warning classes in order
to pass CI, until a more sophisticated fix can be done (internal issue
888).
* Change math notation for the elink:VkPrimitiveTopology descriptions to
use short forms `v` and `p` instead of `vertex` and `primitive`,
increasing legibility (internal issue 1611).
* Rewrite generated file includes relative to a globally specified path,
fixing some issues with refpage generation (internal issue 1630).
* Update contributor list for `<<VK_EXT_calibrated_timestamps>>`.
* Fix use of pathlin in `scripts/generator.py` so the script will work on
Windows under Python 3.5 (internal merge request 3107).
* Add missing conditionals around the
<<descriptorsets-accelerationstructure, Acceleration Structure>>
section (internal merge request 3108).
* More script synchronization with OpenXR spec repository (internal merge
request 3109).
* Mark the `<<VK_AMD_gpu_shader_half_float>>` and
`<<VK_AMD_gpu_shader_int16>>` extensions as deprecated in `vk.xml` and
the corresponding extension appendices (internal merge request 3112).
New Extensions:
* `<<VK_EXT_headless_surface>>`
116 lines
3.7 KiB
Plaintext
116 lines
3.7 KiB
Plaintext
include::meta//VK_EXT_calibrated_timestamps.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2018-10-04
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Contributors*::
|
|
- Matthaeus G. Chajdas, AMD
|
|
- Alan Harrison, AMD
|
|
- Derrick Owens, AMD
|
|
- Daniel Rakos, AMD
|
|
- Jason Ekstrand, Intel
|
|
- Keith Packard, Valve
|
|
|
|
This extension provides an interface to query calibrated timestamps obtained
|
|
quasi simultaneously from two time domains.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
* Extending elink:VkStructureType:
|
|
** ename:VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT
|
|
|
|
=== New Enums
|
|
|
|
* elink:VkTimeDomainEXT
|
|
|
|
=== New Structures
|
|
|
|
* slink:VkCalibratedTimestampInfoEXT
|
|
|
|
=== New Functions
|
|
|
|
* flink:vkGetPhysicalDeviceCalibrateableTimeDomainsEXT
|
|
* flink:vkGetCalibratedTimestampsEXT
|
|
|
|
=== Issues
|
|
|
|
1) Is the device timestamp value returned in the same time domain as the
|
|
timestamp values written by flink:vkCmdWriteTimestamp?
|
|
|
|
*RESOLVED*: Yes.
|
|
|
|
2) What time domain is the host timestamp returned in?
|
|
|
|
*RESOLVED*: A query is provided to determine the calibrateable time domains.
|
|
The expected host time domain used on Windows is that of
|
|
QueryPerformanceCounter, and on Linux that of CLOCK_MONOTONIC.
|
|
|
|
3) Should we support other time domain combinations than just one host and
|
|
the device time domain?
|
|
|
|
*RESOLVED*: Supporting that would need the application to query the set of
|
|
supported time domains, while supporting only one host and the device time
|
|
domain would only need a query for the host time domain type.
|
|
The proposed API chooses the general approach for the sake of extensibility.
|
|
|
|
4) Shouldn't we use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC?
|
|
|
|
*RESOLVED*: CLOCK_MONOTONIC is usable in a wider set of situations, however,
|
|
it is subject to NTP adjustments so some use cases may prefer
|
|
CLOCK_MONOTONIC_RAW.
|
|
Thus this extension allows both to be exposed.
|
|
|
|
5) How can the application extrapolate future device timestamp values from
|
|
the calibrated timestamp value?
|
|
|
|
*RESOLVED*: slink:VkPhysicalDeviceLimits::pname:timestampPeriod makes it
|
|
possible to calculate future device timestamps as follows:
|
|
|
|
[source,c]
|
|
---------------------------------------------------
|
|
futureTimestamp = calibratedTimestamp + deltaNanoseconds / timestampPeriod
|
|
---------------------------------------------------
|
|
|
|
6) Can the host and device timestamp values drift apart over longer periods
|
|
of time?
|
|
|
|
*RESOLVED*: Yes, especially as some time domains by definition allow for
|
|
that to happen (e.g. CLOCK_MONOTONIC is subject to NTP adjustments).
|
|
Thus it's recommended that applications re-calibrate from time to time.
|
|
|
|
7) Should we add a query for reporting the maximum deviation of the
|
|
timestamp values returned by calibrated timestamp queries?
|
|
|
|
*RESOLVED*: A global query seems inappropriate and difficult to enforce.
|
|
However, it's possible to return the maximum deviation any single calibrated
|
|
timestamp query can have by sampling one of the time domains twice as
|
|
follows:
|
|
|
|
[source,c]
|
|
---------------------------------------------------
|
|
timestampX = timestampX_before = SampleTimeDomain(X)
|
|
for each time domain Y != X
|
|
timestampY = SampleTimeDomain(Y)
|
|
timestampX_after = SampleTimeDomain(X)
|
|
maxDeviation = timestampX_after - timestampX_before
|
|
---------------------------------------------------
|
|
|
|
8) Can the maximum deviation reported ever be zero?
|
|
|
|
*RESOLVED*: Unless the tick of each clock corresponding to the set of time
|
|
domains coincides and all clocks can literally be sampled simutaneously,
|
|
there isn't really a possibility for the maximum deviation to be zero, so by
|
|
convention the maximum deviation is always at least the maximum of the
|
|
length of the ticks of the set of time domains calibrated and thus can never
|
|
be zero.
|
|
|
|
=== Version History
|
|
|
|
* Revision 1, 2018-10-04 (Daniel Rakos)
|
|
- Internal revisions.
|