mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-12 06:54:14 +00:00
dbfd1b68c4
* Bump API patch number and header version number to 54 for this update.
Github Issues:
Internal Issues:
* Fix tessellation domain to have an upper-left origin in the
<<img-tessellation-topology-ul, tessellation toplogy image>> and related
language. CTS and all implementations were already doing this, it was
just a documentation bug that it was flipped to lower-left (internal
issue 603).
* Add a section to the style guide describing how VUID tags are changed
and removed when the corresponding Valid Usage statements are modified
(internal issue 829).
* Add explicit Valid Usage statement to
slink:VkPipelineDynamicStateCreateInfo to require that members of
pname:pDynamicStates must be unique (internal issue 851).
New Extensions:
* `VK_KHR_16bit_storage`
* `VK_KHR_dedicated_allocation`
* `VK_KHR_external_fence`
* `VK_KHR_external_fence_capabilities`
* `VK_KHR_external_fence_fd`
* `VK_KHR_external_fence_win32`
* `VK_KHR_get_memory_requirements2`
* `VK_KHR_storage_buffer_storage_class`
* `VK_KHR_variable_pointers`
Extensions Promoted From KHX To KHR Status:
* `VK_KHR_external_memory`
* `VK_KHR_external_memory_capabilities`
* `VK_KHR_external_memory_fd`
* `VK_KHR_external_memory_win32`
* `VK_KHR_external_semaphore`
* `VK_KHR_external_semaphore_capabilities`
* `VK_KHR_external_semaphore_fd`
* `VK_KHR_external_semaphore_win32`
* `VK_KHR_win32_keyed_mutex`
97 lines
3.1 KiB
Plaintext
97 lines
3.1 KiB
Plaintext
// Copyright (c) 2016-2017 Khronos Group. This work is licensed under a
|
|
// Creative Commons Attribution 4.0 International License; see
|
|
// http://creativecommons.org/licenses/by/4.0/
|
|
|
|
[[VK_KHR_variable_pointers]]
|
|
== VK_KHR_variable_pointers
|
|
|
|
*Name String*::
|
|
VK_KHR_variable_pointers
|
|
*Extension Type*::
|
|
Device extension
|
|
*Registered Extension Number*::
|
|
121
|
|
*Status*::
|
|
Draft
|
|
*Last Modified Date*::
|
|
2017-03-14
|
|
*Revision*::
|
|
1
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Dependencies*::
|
|
- Written against version 1.0 of the Vulkan API
|
|
- Requires Vulkan 1.0
|
|
- Requires the
|
|
<<VK_KHR_get_physical_device_properties2,VK_KHR_get_physical_device_properties2>>
|
|
extension
|
|
- Requires the
|
|
<<VK_KHR_storage_buffer_storage_class,VK_KHR_storage_buffer_storage_class>>
|
|
extension
|
|
- Requires the
|
|
https://www.khronos.org/registry/spir-v/extensions/KHR/SPV_KHR_variable_pointers.html[+SPV_KHR_variable_pointers+]
|
|
SPIR-V extension.
|
|
*Contributors*::
|
|
- John Kessenich, Google
|
|
- Neil Henning, Codeplay
|
|
- David Neto, Google
|
|
- Daniel Koch, Nvidia
|
|
- Graeme Leese, Broadcom
|
|
- Weifeng Zhang, Qualcomm
|
|
- Stephen Clarke, Imagination Technologies
|
|
- Jason Ekstrand, Intel
|
|
- Jesse Hall, Google
|
|
*Contacts*::
|
|
- Jesse Hall (jessehall 'at' google.com)
|
|
- John Kessenich (johnkessenich 'at' google.com)
|
|
|
|
The +VK_KHR_variable_pointers+ extension allows implementations to indicate
|
|
their level of support for the +SPV_KHR_variable_pointers+ SPIR-V extension.
|
|
The SPIR-V extension allows shader modules to use invocation-private
|
|
pointers into uniform and/or storage buffers, where the pointer values can
|
|
be dynamic and non-uniform.
|
|
|
|
The +SPV_KHR_variable_pointers+ extension introduces two capabilities.
|
|
The first, +VariablePointersStorageBuffer+, must: be supported by all
|
|
implementations of this extension.
|
|
The second, +VariablePointers+, is optional.
|
|
|
|
=== New Enum Constants
|
|
* Extending elink:VkStructureType:
|
|
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR
|
|
|
|
=== New Structures
|
|
* slink:VkPhysicalDeviceVariablePointerFeaturesKHR
|
|
|
|
=== New SPIR-V Capabilities
|
|
|
|
* <<spirvenv-capabilities-table-variablepointers,VariablePointersStorageBuffer>>
|
|
* <<spirvenv-capabilities-table-variablepointers,VariablePointers>>
|
|
|
|
=== Issues
|
|
|
|
1) Do we need an optional property for the SPIR-V
|
|
+VariablePointersStorageBuffer+ capability or should it be mandatory when
|
|
this extension is advertised?
|
|
|
|
*RESOLVED*: Add it as a distinct feature, but make support mandatory.
|
|
Adding it as a feature makes the extension easier to include in a future
|
|
core API version.
|
|
In the extension, the feature is mandatory, so that presence of the
|
|
extension guarantees some functionality.
|
|
When included in a core API version, the feature would be optional.
|
|
|
|
2) Can support for these capabilities vary between shader stages?
|
|
|
|
*RESOLVED*: No, if the capability is supported in any stage it must be
|
|
supported in all stages.
|
|
|
|
3) Should the capabilities be features or limits?
|
|
|
|
*RESOLVED*: Features, primarily for consistency with other similar
|
|
extensions.
|
|
|
|
=== Version History
|
|
* Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)
|
|
- Internal revisions
|