Appendix E: Layers & Extensions (Informative)
Extensions to the Vulkan API can be defined by authors, groups of authors, and the Khronos Vulkan Working Group. In order not to compromise the readability of the Vulkan Specification, the core Specification does not incorporate most extensions. The online Registry of extensions is available at URL
and allows generating versions of the Specification incorporating different extensions.
Authors creating extensions and layers must follow the mandatory procedures described in the Vulkan Documentation and Extensions document when creating extensions and layers.
The remainder of this appendix documents a set of extensions chosen when this document was built. Versions of the Specification published in the Registry include:
-
Core API + mandatory extensions required of all Vulkan implementations.
-
Core API + all registered and published Khronos (
KHR
) extensions. -
Core API + all registered and published extensions.
Extensions are grouped as Khronos KHR
, multivendor EXT
, and then
alphabetically by author ID.
Within each group, extensions are listed in alphabetical order by their
name.
Extension Dependencies
Extensions which have dependencies on specific core versions or on other extensions will list such dependencies.
For core versions, the specified version must be supported at runtime. All extensions implicitly require support for Vulkan 1.0.
For a device extension, use of any device-level functionality defined by that extension requires that any extensions that extension depends on be enabled.
For any extension, use of any instance-level functionality defined by that extension requires only that any extensions that extension depends on be supported at runtime.
Extension Interactions
Some extensions define APIs which are only supported when other extensions or core versions are supported at runtime. Such interactions are noted as “API Interactions”.
List of Current Extensions
VK_KHR_acceleration_structure
- Name String
-
VK_KHR_acceleration_structure
- Extension Type
-
Device extension
- Registered Extension Number
-
151
- Revision
-
13
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
Version 1.1
and
VK_EXT_descriptor_indexing
and
VK_KHR_buffer_device_address
or
Version 1.2
and
VK_KHR_deferred_host_operations - API Interactions
-
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_EXT_debug_report
-
Interacts with VK_KHR_format_feature_flags2
-
- Contact
-
-
Daniel Koch dgkoch
-
Other Extension Metadata
- Last Modified Date
-
2021-09-30
- Contributors
-
-
Samuel Bourasseau, Adobe
-
Matthäus Chajdas, AMD
-
Greg Grebe, AMD
-
Nicolai Hähnle, AMD
-
Tobias Hector, AMD
-
Dave Oldcorn, AMD
-
Skyler Saleh, AMD
-
Mathieu Robart, Arm
-
Marius Bjorge, Arm
-
Tom Olson, Arm
-
Sebastian Tafuri, EA
-
Henrik Rydgard, Embark
-
Juan Cañada, Epic Games
-
Patrick Kelly, Epic Games
-
Yuriy O’Donnell, Epic Games
-
Michael Doggett, Facebook/Oculus
-
Ricardo Garcia, Igalia
-
Andrew Garrard, Imagination
-
Don Scorgie, Imagination
-
Dae Kim, Imagination
-
Joshua Barczak, Intel
-
Slawek Grajewski, Intel
-
Jeff Bolz, NVIDIA
-
Pascal Gautron, NVIDIA
-
Daniel Koch, NVIDIA
-
Christoph Kubisch, NVIDIA
-
Ashwin Lele, NVIDIA
-
Robert Stepinski, NVIDIA
-
Martin Stich, NVIDIA
-
Nuno Subtil, NVIDIA
-
Eric Werness, NVIDIA
-
Jon Leech, Khronos
-
Jeroen van Schijndel, OTOY
-
Juul Joosten, OTOY
-
Alex Bourd, Qualcomm
-
Roman Larionov, Qualcomm
-
David McAllister, Qualcomm
-
Lewis Gordon, Samsung
-
Ralph Potter, Samsung
-
Jasper Bekkers, Traverse Research
-
Jesse Barker, Unity
-
Baldur Karlsson, Valve
-
Description
In order to be efficient, rendering techniques such as ray tracing need a quick way to identify which primitives may be intersected by a ray traversing the geometries. Acceleration structures are the most common way to represent the geometry spatially sorted, in order to quickly identify such potential intersections.
This extension adds new functionalities:
-
Acceleration structure objects and build commands
-
Structures to describe geometry inputs to acceleration structure builds
-
Acceleration structure copy commands
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkWriteDescriptorSet:
New Enum Constants
-
VK_KHR_ACCELERATION_STRUCTURE_EXTENSION_NAME
-
VK_KHR_ACCELERATION_STRUCTURE_SPEC_VERSION
-
Extending VkAccessFlagBits:
-
VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR
-
VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR
-
VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR
-
-
Extending VkDescriptorType:
-
VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR
-
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR
-
-
Extending VkIndexType:
-
VK_INDEX_TYPE_NONE_KHR
-
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR
-
-
Extending VkPipelineStageFlagBits:
-
VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR
-
-
Extending VkQueryType:
-
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_KHR
-
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_SIZE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_GEOMETRY_INFO_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_DEVICE_ADDRESS_INFO_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_AABBS_DATA_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_INSTANCES_DATA_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_TRIANGLES_DATA_KHR
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR
-
VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_TO_MEMORY_INFO_KHR
-
VK_STRUCTURE_TYPE_COPY_MEMORY_TO_ACCELERATION_STRUCTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_KHR
-
If VK_KHR_format_feature_flags2 or Version 1.3 is supported:
-
Extending VkFormatFeatureFlagBits2:
-
VK_FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR
-
Issues
(1) How does this extension differ from VK_NV_ray_tracing?
DISCUSSION:
The following is a summary of the main functional differences between VK_KHR_acceleration_structure and VK_NV_ray_tracing:
-
added acceleration structure serialization / deserialization (
VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR
,VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR
, vkCmdCopyAccelerationStructureToMemoryKHR, vkCmdCopyMemoryToAccelerationStructureKHR) -
document inactive primitives and instances
-
added VkPhysicalDeviceAccelerationStructureFeaturesKHR structure
-
added indirect and batched acceleration structure builds (vkCmdBuildAccelerationStructuresIndirectKHR)
-
added host acceleration structure commands
-
reworked geometry structures so they could be better shared between device, host, and indirect builds
-
explicitly made VkAccelerationStructureKHR use device addresses
-
added acceleration structure compatibility check function (vkGetDeviceAccelerationStructureCompatibilityKHR)
-
add parameter for requesting memory requirements for host and/or device build
-
added format feature for acceleration structure build vertex formats (
VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR
)
(3) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the internal provisional (VK_KHR_ray_tracing v9) release?
-
added
geometryFlags
toVkAccelerationStructureCreateGeometryTypeInfoKHR
(later reworked to obsolete this) -
added
minAccelerationStructureScratchOffsetAlignment
property to VkPhysicalDeviceRayTracingPropertiesKHR -
fix naming and return enum from vkGetDeviceAccelerationStructureCompatibilityKHR
-
renamed
VkAccelerationStructureVersionKHR
to VkAccelerationStructureVersionInfoKHR -
renamed
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_KHR
toVK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR
-
removed
VK_ERROR_INCOMPATIBLE_VERSION_KHR
-
added VkAccelerationStructureCompatibilityKHR enum
-
remove return value from vkGetDeviceAccelerationStructureCompatibilityKHR and added return enum parameter
-
-
Require Vulkan 1.1
-
added creation time capture and replay flags
-
added VkAccelerationStructureCreateFlagBitsKHR and VkAccelerationStructureCreateFlagsKHR
-
renamed the
flags
member of VkAccelerationStructureCreateInfoKHR tobuildFlags
(later removed) and added thecreateFlags
member
-
-
change vkCmdBuildAccelerationStructuresIndirectKHR to use buffer device address for indirect parameter
-
make
VK_KHR_deferred_host_operations
an interaction instead of a required extension (later went back on this) -
renamed
VkAccelerationStructureBuildOffsetInfoKHR
to VkAccelerationStructureBuildRangeInfoKHR-
renamed the
ppOffsetInfos
parameter of vkCmdBuildAccelerationStructuresKHR toppBuildRangeInfos
-
-
Re-unify geometry description between build and create
-
remove
VkAccelerationStructureCreateGeometryTypeInfoKHR
andVK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_GEOMETRY_TYPE_INFO_KHR
-
added
VkAccelerationStructureCreateSizeInfoKHR
structure (later removed) -
change type of the
pGeometryInfos
member of VkAccelerationStructureCreateInfoKHR fromVkAccelerationStructureCreateGeometryTypeInfoKHR
to VkAccelerationStructureGeometryKHR (later removed) -
added
pCreateSizeInfos
member to VkAccelerationStructureCreateInfoKHR (later removed)
-
-
Fix ppGeometries ambiguity, add pGeometries
-
remove
geometryArrayOfPointers
member of VkAccelerationStructureBuildGeometryInfoKHR -
disambiguate two meanings of
ppGeometries
by explicitly addingpGeometries
to the VkAccelerationStructureBuildGeometryInfoKHR structure and require one of them beNULL
-
-
added
nullDescriptor
support for acceleration structures -
changed the
update
member of VkAccelerationStructureBuildGeometryInfoKHR from a bool to themode
VkBuildAccelerationStructureModeKHR enum which allows future extensibility in update types -
Clarify deferred host ops for pipeline creation
-
VkDeferredOperationKHR is now a top-level parameter for vkBuildAccelerationStructuresKHR, vkCreateRayTracingPipelinesKHR, vkCopyAccelerationStructureToMemoryKHR, vkCopyAccelerationStructureKHR, and vkCopyMemoryToAccelerationStructureKHR
-
removed
VkDeferredOperationInfoKHR
structure -
change deferred host creation/return parameter behavior such that the implementation can modify such parameters until the deferred host operation completes
-
VK_KHR_deferred_host_operations
is required again
-
-
Change acceleration structure build to always be sized
-
de-alias
VkAccelerationStructureMemoryRequirementsTypeNV
andVkAccelerationStructureMemoryRequirementsTypeKHR
, and removeVkAccelerationStructureMemoryRequirementsTypeKHR
-
add vkGetAccelerationStructureBuildSizesKHR command and VkAccelerationStructureBuildSizesInfoKHR structure and
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR
enum to query sizes for acceleration structures and scratch storage -
move size queries for scratch space to vkGetAccelerationStructureBuildSizesKHR
-
remove
compactedSize
,buildFlags
,maxGeometryCount
,pGeometryInfos
,pCreateSizeInfos
members of VkAccelerationStructureCreateInfoKHR and add thesize
member -
add
maxVertex
member to VkAccelerationStructureGeometryTrianglesDataKHR structure -
remove
VkAccelerationStructureCreateSizeInfoKHR
structure
-
(4) What are the changes between the internal provisional (VK_KHR_ray_tracing v9) release and the final (VK_KHR_acceleration_structure v11) release?
-
refactor VK_KHR_ray_tracing into 3 extensions, enabling implementation flexibility and decoupling ray query support from ray pipelines:
-
VK_KHR_acceleration_structure
(for acceleration structure operations) -
VK_KHR_ray_tracing_pipeline
(for ray tracing pipeline and shader stages) -
VK_KHR_ray_query
(for ray queries in existing shader stages)
-
-
clarify buffer usage flags for ray tracing
-
VK_BUFFER_USAGE_RAY_TRACING_BIT_NV
is left alone in
(required onVK_NV_ray_tracing
scratch
andinstanceData
) -
VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR
is added as an alias ofVK_BUFFER_USAGE_RAY_TRACING_BIT_NV
inVK_KHR_ray_tracing_pipeline
and is required on shader binding table buffers -
VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR
is added inVK_KHR_acceleration_structure
for all vertex, index, transform, aabb, and instance buffer data referenced by device build commands -
VK_BUFFER_USAGE_STORAGE_BUFFER_BIT
is used forscratchData
-
-
add max primitive counts (
ppMaxPrimitiveCounts
) to vkCmdBuildAccelerationStructuresIndirectKHR -
Allocate acceleration structures from
VkBuffers
and add a mode to constrain the device address-
de-alias
VkBindAccelerationStructureMemoryInfoNV
andvkBindAccelerationStructureMemoryNV
, and removeVkBindAccelerationStructureMemoryInfoKHR
,VkAccelerationStructureMemoryRequirementsInfoKHR
, andvkGetAccelerationStructureMemoryRequirementsKHR
-
acceleration structures now take a VkBuffer and offset at creation time for memory placement
-
add a new
VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR
buffer usage for such buffers -
add a new
VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR
acceleration structure type for layering
-
-
move
VK_GEOMETRY_TYPE_INSTANCES_KHR
to main enum instead of being added via extension -
make build commands more consistent - all now build multiple acceleration structures and are named plurally (vkCmdBuildAccelerationStructuresIndirectKHR, vkCmdBuildAccelerationStructuresKHR, vkBuildAccelerationStructuresKHR)
-
add interactions with
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT
for acceleration structures, including a new feature (descriptorBindingAccelerationStructureUpdateAfterBind
) and 3 new properties (maxPerStageDescriptorAccelerationStructures
,maxPerStageDescriptorUpdateAfterBindAccelerationStructures
,maxDescriptorSetUpdateAfterBindAccelerationStructures
) -
extension is no longer provisional
-
define synchronization requirements for builds, traces, and copies
-
define synchronization requirements for AS build inputs and indirect build buffer
(5) What is VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR
for?
RESOLVED: It is primarily intended for API layering. In DXR, the acceleration structure is basically just a buffer in a special layout, and you do not know at creation time whether it will be used as a top or bottom level acceleration structure. We thus added a generic acceleration structure type whose type is unknown at creation time, but is specified at build time instead. Applications which are written directly for Vulkan should not use it.
Version History
-
Revision 1, 2019-12-05 (Members of the Vulkan Ray Tracing TSG)
-
Internal revisions (forked from VK_NV_ray_tracing)
-
-
Revision 2, 2019-12-20 (Daniel Koch, Eric Werness)
-
Add const version of DeviceOrHostAddress (!3515)
-
Add VU to clarify that only handles in the current pipeline are valid (!3518)
-
Restore some missing VUs and add in-place update language (#1902, !3522)
-
rename VkAccelerationStructureInstanceKHR member from accelerationStructure to accelerationStructureReference to better match its type (!3523)
-
Allow VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS for pipeline creation if shader group handles cannot be reused (!3523)
-
update documentation for the VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS error code and add missing documentation for new return codes from VK_KHR_deferred_host_operations (!3523)
-
list new query types for VK_KHR_ray_tracing (!3523)
-
Fix VU statements for VkAccelerationStructureGeometryKHR referring to correct union members and update to use more current wording (!3523)
-
-
Revision 3, 2020-01-10 (Daniel Koch, Jon Leech, Christoph Kubisch)
-
Fix 'instance of' and 'that/which contains/defines' markup issues (!3528)
-
factor out VK_KHR_pipeline_library as stand-alone extension (!3540)
-
Resolve Vulkan-hpp issues (!3543)
-
add missing require for VkGeometryInstanceFlagsKHR
-
de-alias VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV since the KHR structure is no longer equivalent
-
add len to pDataSize attribute for vkWriteAccelerationStructuresPropertiesKHR
-
-
-
Revision 4, 2020-01-23 (Daniel Koch, Eric Werness)
-
Improve vkWriteAccelerationStructuresPropertiesKHR, add return value and VUs (#1947)
-
Clarify language to allow multiple raygen shaders (#1959)
-
Various editorial feedback (!3556)
-
Add language to help deal with looped self-intersecting fans (#1901)
-
Change vkCmdTraceRays{,Indirect}KHR args to pointers (!3559)
-
Add scratch address validation language (#1941, !3551)
-
Fix definition and add hierarchy information for shader call scope (#1977, !3571)
-
-
Revision 5, 2020-02-04 (Eric Werness, Jeff Bolz, Daniel Koch)
-
remove vestigial accelerationStructureUUID (!3582)
-
update definition of repack instructions and improve memory model interactions (#1910, #1913, !3584)
-
Fix wrong sType for VkPhysicalDeviceRayTracingFeaturesKHR (#1988)
-
Use provisional SPIR-V capabilities (#1987)
-
require rayTraversalPrimitiveCulling if rayQuery is supported (#1927)
-
Miss shaders do not have object parameters (!3592)
-
Fix missing required types in XML (!3592)
-
clarify matching conditions for update (!3592)
-
add goal that host and device builds be similar (!3592)
-
clarify that
maxPrimitiveCount
limit should apply to triangles and AABBs (!3592) -
Require alignment for instance arrayOfPointers (!3592)
-
Zero is a valid value for instance flags (!3592)
-
Add some alignment VUs that got lost in refactoring (!3592)
-
Recommend TMin epsilon rather than culling (!3592)
-
Get angle from dot product not cross product (!3592)
-
Clarify that AH can access the payload and attributes (!3592)
-
Match DXR behavior for inactive primitive definition (!3592)
-
Use a more generic term than degenerate for inactive to avoid confusion (!3592)
-
-
Revision 6, 2020-02-20 (Daniel Koch)
-
fix some dangling NV references (#1996)
-
rename VkCmdTraceRaysIndirectCommandKHR to VkTraceRaysIndirectCommandKHR (!3607)
-
update contributor list (!3611)
-
use uint64_t instead of VkAccelerationStructureReferenceKHR in VkAccelerationStructureInstanceKHR (#2004)
-
-
Revision 7, 2020-02-28 (Tobias Hector)
-
remove HitTKHR SPIR-V builtin (spirv/spirv-extensions#7)
-
-
Revision 8, 2020-03-06 (Tobias Hector, Dae Kim, Daniel Koch, Jeff Bolz, Eric Werness)
-
explicitly state that Tmax is updated when new closest intersection is accepted (#2020,!3536)
-
Made references to min and max t values consistent (!3644)
-
finish enumerating differences relative to VK_NV_ray_tracing in issues (1) and (2) (#1974,!3642)
-
fix formatting in some math equations (!3642)
-
Restrict the Hit Kind operand of
OpReportIntersectionKHR
to 7-bits (spirv/spirv-extensions#8,!3646) -
Say ray tracing 'should' be watertight (#2008,!3631)
-
Clarify memory requirements for ray tracing buffers (#2005,!3649)
-
Add callable size limits (#1997,!3652)
-
-
Revision 9, 2020-04-15 (Eric Werness, Daniel Koch, Tobias Hector, Joshua Barczak)
-
Add geometry flags to acceleration structure creation (!3672)
-
add build scratch memory alignment (minAccelerationStructureScratchOffsetAlignment) (#2065,!3725)
-
fix naming and return enum from vkGetDeviceAccelerationStructureCompatibilityKHR (#2051,!3726)
-
require SPIR-V 1.4 (#2096,!3777)
-
added creation time capture/replay flags (#2104,!3774)
-
require Vulkan 1.1 (#2133,!3806)
-
use device addresses instead of VkBuffers for ray tracing commands (#2074,!3815)
-
add interactions with Vulkan 1.2 and VK_KHR_vulkan_memory_model (#2133,!3830)
-
make VK_KHR_pipeline_library an interaction instead of required (#2045,#2108,!3830)
-
make VK_KHR_deferred_host_operations an interaction instead of required (#2045,!3830)
-
removed maxCallableSize and added explicit stack size management for ray pipelines (#1997,!3817,!3772,!3844)
-
improved documentation for VkAccelerationStructureVersionInfoKHR (#2135,3835)
-
rename VkAccelerationStructureBuildOffsetInfoKHR to VkAccelerationStructureBuildRangeInfoKHR (#2058,!3754)
-
Re-unify geometry description between build and create (!3754)
-
Fix ppGeometries ambiguity, add pGeometries (#2032,!3811)
-
add interactions with VK_EXT_robustness2 and allow nullDescriptor support for acceleration structures (#1920,!3848)
-
added future extensibility for AS updates (#2114,!3849)
-
Fix VU for dispatchrays and add a limit on the size of the full grid (#2160,!3851)
-
Add shaderGroupHandleAlignment property (#2180,!3875)
-
Clarify deferred host ops for pipeline creation (#2067,!3813)
-
Change acceleration structure build to always be sized (#2131,#2197,#2198,!3854,!3883,!3880)
-
-
Revision 10, 2020-07-03 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)
-
Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_acceleration_structure (#1918,!3912)
-
clarify buffer usage flags for ray tracing (#2181,!3939)
-
add max primitive counts to build indirect command (#2233,!3944)
-
Allocate acceleration structures from VkBuffers and add a mode to constrain the device address (#2131,!3936)
-
Move VK_GEOMETRY_TYPE_INSTANCES_KHR to main enum (#2243,!3952)
-
make build commands more consistent (#2247,!3958)
-
add interactions with UPDATE_AFTER_BIND (#2128,!3986)
-
correct and expand build command VUs (!4020)
-
fix copy command VUs (!4018)
-
added various alignment requirements (#2229,!3943)
-
fix valid usage for arrays of geometryCount items (#2198,!4010)
-
define what is allowed to change on RTAS updates and relevant VUs (#2177,!3961)
-
-
Revision 11, 2020-11-12 (Eric Werness, Josh Barczak, Daniel Koch, Tobias Hector)
-
de-alias NV and KHR acceleration structure types and associated commands (#2271,!4035)
-
specify alignment for host copy commands (#2273,!4037)
-
document
VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR
-
specify that acceleration structures are non-linear (#2289,!4068)
-
add several missing VUs for strides, vertexFormat, and indexType (#2315,!4069)
-
restore VUs for VkAccelerationStructureBuildGeometryInfoKHR (#2337,!4098)
-
ban multi-instance memory for host operations (#2324,!4102)
-
allow dstAccelerationStructure to be null for vkGetAccelerationStructureBuildSizesKHR (#2330,!4111)
-
more build VU cleanup (#2138,#4130)
-
specify host endianness for AS serialization (#2261,!4136)
-
add invertible transform matrix VU (#1710,!4140)
-
require geometryCount to be 1 for TLAS builds (!4145)
-
improved validity conditions for build addresses (#4142)
-
add single statement SPIR-V VUs, build limit VUs (!4158)
-
document limits for vertex and aabb strides (#2390,!4184)
-
specify that
VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR
applies to AS copies (#2382,#4173) -
define sync for AS build inputs and indirect buffer (#2407,!4208)
-
-
Revision 12, 2021-08-06 (Samuel Bourasseau)
-
rename VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_KHR to VK_GEOMETRY_INSTANCE_TRIANGLE_FLIP_FACING_BIT_KHR (keep previous as alias).
-
Clarify description and add note.
-
-
Revision 13, 2021-09-30 (Jon Leech)
-
Add interaction with
VK_KHR_format_feature_flags2
tovk.xml
-
VK_KHR_android_surface
- Name String
-
VK_KHR_android_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
9
- Revision
-
6
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2016-01-14
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Faith Ekstrand, Intel
-
Ian Elliott, LunarG
-
Courtney Goeltzenleuchter, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Antoine Labour, Google
-
Jon Leech, Khronos
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Ray Smith, ARM
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Description
The VK_KHR_android_surface
extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface
extension) that refers to an
ANativeWindow, Android’s native surface type.
The ANativeWindow represents the producer endpoint of any buffer
queue, regardless of consumer endpoint.
Common consumer endpoints for ANativeWindows
are the system window
compositor, video encoders, and application-specific compositors importing
the images through a SurfaceTexture
.
New Enum Constants
-
VK_KHR_ANDROID_SURFACE_EXTENSION_NAME
-
VK_KHR_ANDROID_SURFACE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR
-
Issues
1) Does Android need a way to query for compatibility between a particular physical device (and queue family?) and a specific Android display?
RESOLVED: No. Currently on Android, any physical device is expected to be able to present to the system compositor, and all queue families must support the necessary image layout transitions and synchronization operations.
Version History
-
Revision 1, 2015-09-23 (Jesse Hall)
-
Initial draft.
-
-
Revision 2, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_android_surface to VK_KHR_android_surface.
-
-
Revision 3, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to surface creation function.
-
-
Revision 4, 2015-11-10 (Jesse Hall)
-
Removed VK_ERROR_INVALID_ANDROID_WINDOW_KHR.
-
-
Revision 5, 2015-11-28 (Daniel Rakos)
-
Updated the surface create function to take a pCreateInfo structure.
-
-
Revision 6, 2016-01-14 (James Jones)
-
Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.
-
VK_KHR_calibrated_timestamps
- Name String
-
VK_KHR_calibrated_timestamps
- Extension Type
-
Device extension
- Registered Extension Number
-
544
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Daniel Rakos aqnuep
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-07-12
- IP Status
-
No known IP claims.
- Contributors
-
-
Matthaeus G. Chajdas, AMD
-
Alan Harrison, AMD
-
Derrick Owens, AMD
-
Daniel Rakos, RasterGrid
-
Faith Ekstrand, Intel
-
Keith Packard, Valve
-
Description
This extension provides an interface to query calibrated timestamps obtained quasi simultaneously from two time domains.
New Enum Constants
-
VK_KHR_CALIBRATED_TIMESTAMPS_EXTENSION_NAME
-
VK_KHR_CALIBRATED_TIMESTAMPS_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_KHR
-
VK_KHR_cooperative_matrix
- Name String
-
VK_KHR_cooperative_matrix
- Extension Type
-
Device extension
- Registered Extension Number
-
507
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Kevin Petit kpet
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-05-03
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_KHR_cooperative_matrix
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Markus Tavenrath, NVIDIA
-
Daniel Koch, NVIDIA
-
Kevin Petit, Arm Ltd.
-
Boris Zanin, AMD
-
Description
This extension adds support for using cooperative matrix types in SPIR-V. Cooperative matrix types are medium-sized matrices that are primarily supported in compute shaders, where the storage for the matrix is spread across all invocations in some scope (usually a subgroup) and those invocations cooperate to efficiently perform matrix multiplies.
Cooperative matrix types are defined by the
SPV_KHR_cooperative_matrix
SPIR-V extension and can be used with the
GLSL_KHR_cooperative_matrix
GLSL extension.
This extension includes support for enumerating the matrix types and dimensions that are supported by the implementation.
New Enum Constants
-
VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME
-
VK_KHR_COOPERATIVE_MATRIX_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_KHR
-
VK_KHR_deferred_host_operations
- Name String
-
VK_KHR_deferred_host_operations
- Extension Type
-
Device extension
- Registered Extension Number
-
269
- Revision
-
4
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Josh Barczak jbarczak
-
Other Extension Metadata
- Last Modified Date
-
2020-11-12
- IP Status
-
No known IP claims.
- Contributors
-
-
Joshua Barczak, Intel
-
Jeff Bolz, NVIDIA
-
Daniel Koch, NVIDIA
-
Slawek Grajewski, Intel
-
Tobias Hector, AMD
-
Yuriy O’Donnell, Epic
-
Eric Werness, NVIDIA
-
Baldur Karlsson, Valve
-
Jesse Barker, Unity
-
Contributors to VK_KHR_acceleration_structure, VK_KHR_ray_tracing_pipeline
-
Description
The VK_KHR_deferred_host_operations
extension defines the
infrastructure and usage patterns for deferrable commands, but does not
specify any commands as deferrable.
This is left to additional dependent extensions.
Commands must not be deferred unless the deferral is specifically allowed
by another extension which depends on
VK_KHR_deferred_host_operations
.
New Enum Constants
-
VK_KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME
-
VK_KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR
-
-
Extending VkResult:
-
VK_OPERATION_DEFERRED_KHR
-
VK_OPERATION_NOT_DEFERRED_KHR
-
VK_THREAD_DONE_KHR
-
VK_THREAD_IDLE_KHR
-
Code Examples
The following examples will illustrate the concept of deferrable operations
using a hypothetical example.
The command vkDoSomethingExpensive
denotes a deferrable command.
The following example illustrates how a vulkan application might request deferral of an expensive operation:
// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);
result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );
// operation was deferred. Execute it asynchronously
std::async::launch(
[ hOp ] ( )
{
vkDeferredOperationJoinKHR(device, hOp);
result = vkGetDeferredOperationResultKHR(device, hOp);
// deferred operation is now complete. 'result' indicates success or failure
vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);
}
);
The following example illustrates extracting concurrency from a single deferred operation:
// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);
result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );
// Query the maximum amount of concurrency and clamp to the desired maximum
uint32_t numLaunches = std::min(vkGetDeferredOperationMaxConcurrencyKHR(device, hOp), maxThreads);
std::vector<std::future<void> > joins;
for (uint32_t i = 0; i < numLaunches; i++) {
joins.emplace_back(std::async::launch(
[ hOp ] ( )
{
vkDeferredOperationJoinKHR(device, hOp);
// in a job system, a return of VK_THREAD_IDLE_KHR should queue another
// job, but it is not functionally required
}
));
}
for (auto &f : joins) {
f.get();
}
result = vkGetDeferredOperationResultKHR(device, hOp);
// deferred operation is now complete. 'result' indicates success or failure
vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);
The following example shows a subroutine which guarantees completion of a deferred operation, in the presence of multiple worker threads, and returns the result of the operation.
VkResult FinishDeferredOperation(VkDeferredOperationKHR hOp)
{
// Attempt to join the operation until the implementation indicates that we should stop
VkResult result = vkDeferredOperationJoinKHR(device, hOp);
while( result == VK_THREAD_IDLE_KHR )
{
std::this_thread::yield();
result = vkDeferredOperationJoinKHR(device, hOp);
}
switch( result )
{
case VK_SUCCESS:
{
// deferred operation has finished. Query its result.
result = vkGetDeferredOperationResultKHR(device, hOp);
}
break;
case VK_THREAD_DONE_KHR:
{
// deferred operation is being wrapped up by another thread
// wait for that thread to finish
do
{
std::this_thread::yield();
result = vkGetDeferredOperationResultKHR(device, hOp);
} while( result == VK_NOT_READY );
}
break;
default:
assert(false); // other conditions are illegal.
break;
}
return result;
}
Issues
-
Should this extension have a VkPhysicalDevice*FeaturesKHR structure?
RESOLVED: No. This extension does not add any functionality on its own and requires a dependent extension to actually enable functionality and thus there is no value in adding a feature structure. If necessary, any dependent extension could add a feature boolean if it wanted to indicate that it is adding optional deferral support.
Version History
-
Revision 1, 2019-12-05 (Josh Barczak, Daniel Koch)
-
Initial draft.
-
-
Revision 2, 2020-03-06 (Daniel Koch, Tobias Hector)
-
Add missing VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR enum
-
fix sample code
-
Clarified deferred operation parameter lifetimes (#2018,!3647)
-
-
Revision 3, 2020-05-15 (Josh Barczak)
-
Clarify behavior of vkGetDeferredOperationMaxConcurrencyKHR, allowing it to return 0 if the operation is complete (#2036,!3850)
-
-
Revision 4, 2020-11-12 (Tobias Hector, Daniel Koch)
-
Remove VkDeferredOperationInfoKHR and change return value semantics when deferred host operations are in use (#2067,3813)
-
clarify return value of vkGetDeferredOperationResultKHR (#2339,!4110)
-
VK_KHR_display
- Name String
-
VK_KHR_display
- Extension Type
-
Instance extension
- Registered Extension Number
-
3
- Revision
-
23
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
Other Extension Metadata
- Last Modified Date
-
2017-03-13
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Norbert Nopper, Freescale
-
Jeff Vigil, Qualcomm
-
Daniel Rakos, AMD
-
Description
This extension provides the API to enumerate displays and available modes on a given device.
New Enum Constants
-
VK_KHR_DISPLAY_EXTENSION_NAME
-
VK_KHR_DISPLAY_SPEC_VERSION
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_DISPLAY_KHR
-
VK_OBJECT_TYPE_DISPLAY_MODE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR
-
Issues
1) Which properties of a mode should be fixed in the mode information vs. settable in some other function when setting the mode? E.g., do we need to double the size of the mode pool to include both stereo and non-stereo modes? YUV and RGB scanout even if they both take RGB input images? BGR vs. RGB input? etc.
RESOLVED: Many modern displays support at most a handful of resolutions and timings natively. Other “modes” are expected to be supported using scaling hardware on the display engine or GPU. Other properties, such as rotation and mirroring should not require duplicating hardware modes just to express all combinations. Further, these properties may be implemented on a per-display or per-overlay granularity.
To avoid the exponential growth of modes as mutable properties are added, as
was the case with EGLConfig
/WGL pixel formats/GLXFBConfig
, this
specification should separate out hardware properties and configurable state
into separate objects.
Modes and overlay planes will express capabilities of the hardware, while a
separate structure will allow applications to configure scaling, rotation,
mirroring, color keys, LUT values, alpha masks, etc.
for a given swapchain independent of the mode in use.
Constraints on these settings will be established by properties of the
immutable objects.
Note the resolution of this issue may affect issue 5 as well.
2) What properties of a display itself are useful?
RESOLVED: This issue is too broad. It was meant to prompt general discussion, but resolving this issue amounts to completing this specification. All interesting properties should be included. The issue will remain as a placeholder since removing it would make it hard to parse existing discussion notes that refer to issues by number.
3) How are multiple overlay planes within a display or mode enumerated?
RESOLVED: They are referred to by an index. Each display will report the number of overlay planes it contains.
4) Should swapchains be created relative to a mode or a display?
RESOLVED: When using this extension, swapchains are created relative to a mode and a plane. The mode implies the display object the swapchain will present to. If the specified mode is not the display’s current mode, the new mode will be applied when the first image is presented to the swapchain, and the default operating system mode, if any, will be restored when the swapchain is destroyed.
5) Should users query generic ranges from displays and construct their own modes explicitly using those constraints rather than querying a fixed set of modes (Most monitors only have one real “mode” these days, even though many support relatively arbitrary scaling, either on the monitor side or in the GPU display engine, making “modes” something of a relic/compatibility construct).
RESOLVED: Expose both. Display information structures will expose a set of predefined modes, as well as any attributes necessary to construct a customized mode.
6) Is it fine if we return the display and display mode handles in the structure used to query their properties?
RESOLVED: Yes.
7) Is there a possibility that not all displays of a device work with all of the present queues of a device? If yes, how do we determine which displays work with which present queues?
RESOLVED: No known hardware has such limitations, but determining such
limitations is supported automatically using the existing
VK_KHR_surface
and VK_KHR_swapchain
query mechanisms.
8) Should all presentation need to be done relative to an overlay plane, or can a display mode + display be used alone to target an output?
RESOLVED: Require specifying a plane explicitly.
9) Should displays have an associated window system display, such as an
HDC
or Display*
?
RESOLVED: No.
Displays are independent of any windowing system in use on the system.
Further, neither HDC
nor Display*
refer to a physical display
object.
10) Are displays queried from a physical GPU or from a device instance?
RESOLVED: Developers prefer to query modes directly from the physical GPU so they can use display information as an input to their device selection algorithms prior to device creation. This avoids the need to create placeholder device instances to enumerate displays.
This preference must be weighed against the extra initialization that must be done by driver vendors prior to device instance creation to support this usage.
11) Should displays and/or modes be dispatchable objects? If functions are to take displays, overlays, or modes as their first parameter, they must be dispatchable objects as defined in Khronos bug 13529. If they are not added to the list of dispatchable objects, functions operating on them must take some higher-level object as their first parameter. There is no performance case against making them dispatchable objects, but they would be the first extension objects to be dispatchable.
RESOLVED: Do not make displays or modes dispatchable. They will dispatch based on their associated physical device.
12) Should hardware cursor capabilities be exposed?
RESOLVED: Defer. This could be a separate extension on top of the base WSI specs.
13) How many display objects should be enumerated for "tiled" display devices? There are ongoing design discussions among lower-level display API authors regarding how to expose displays if they are one physical display device to an end user, but may internally be implemented as two side-by-side displays using the same display engine (and sometimes cabling) resources as two physically separate display devices.
RESOLVED: Tiled displays will appear as a single display object in this API.
14) Should the raw EDID data be included in the display information?
RESOLVED: No. A future extension could be added which reports the EDID if necessary. This may be complicated by the outcome of issue 13.
15) Should min and max scaling factor capabilities of overlays be exposed?
RESOLVED: Yes. This is exposed indirectly by allowing applications to query the min/max position and extent of the source and destination regions from which image contents are fetched by the display engine when using a particular mode and overlay pair.
16) Should devices be able to expose planes that can be moved between displays? If so, how?
RESOLVED: Yes. Applications can determine which displays a given plane supports using vkGetDisplayPlaneSupportedDisplaysKHR.
17) Should there be a way to destroy display modes? If so, does it support destroying “built in” modes?
RESOLVED: Not in this extension. A future extension could add this functionality.
18) What should the lifetime of display and built-in display mode objects be?
RESOLVED: The lifetime of the instance. These objects cannot be destroyed. A future extension may be added to expose a way to destroy these objects and/or support display hotplug.
19) Should persistent mode for smart panels be enabled/disabled at swapchain creation time, or on a per-present basis.
RESOLVED: On a per-present basis.
Examples
Note
The example code for the |
Version History
-
Revision 1, 2015-02-24 (James Jones)
-
Initial draft
-
-
Revision 2, 2015-03-12 (Norbert Nopper)
-
Added overlay enumeration for a display.
-
-
Revision 3, 2015-03-17 (Norbert Nopper)
-
Fixed typos and namings as discussed in Bugzilla.
-
Reordered and grouped functions.
-
Added functions to query count of display, mode and overlay.
-
Added native display handle, which may be needed on some platforms to create a native Window.
-
-
Revision 4, 2015-03-18 (Norbert Nopper)
-
Removed primary and virtualPostion members (see comment of James Jones in Bugzilla).
-
Added native overlay handle to information structure.
-
Replaced , with ; in struct.
-
-
Revision 6, 2015-03-18 (Daniel Rakos)
-
Added WSI extension suffix to all items.
-
Made the whole API more “Vulkanish”.
-
Replaced all functions with a single vkGetDisplayInfoKHR function to better match the rest of the API.
-
Made the display, display mode, and overlay objects be first class objects, not subclasses of VkBaseObject as they do not support the common functions anyways.
-
Renamed *Info structures to *Properties.
-
Removed overlayIndex field from VkOverlayProperties as there is an implicit index already as a result of moving to a “Vulkanish” API.
-
Displays are not get through device, but through physical GPU to match the rest of the Vulkan API. Also this is something ISVs explicitly requested.
-
Added issue (6) and (7).
-
-
Revision 7, 2015-03-25 (James Jones)
-
Added an issues section
-
Added rotation and mirroring flags
-
-
Revision 8, 2015-03-25 (James Jones)
-
Combined the duplicate issues sections introduced in last change.
-
Added proposed resolutions to several issues.
-
-
Revision 9, 2015-04-01 (Daniel Rakos)
-
Rebased extension against Vulkan 0.82.0
-
-
Revision 10, 2015-04-01 (James Jones)
-
Added issues (10) and (11).
-
Added more straw-man issue resolutions, and cleaned up the proposed resolution for issue (4).
-
Updated the rotation and mirroring enums to have proper bitmask semantics.
-
-
Revision 11, 2015-04-15 (James Jones)
-
Added proposed resolution for issues (1) and (2).
-
Added issues (12), (13), (14), and (15)
-
Removed pNativeHandle field from overlay structure.
-
Fixed small compilation errors in example code.
-
-
Revision 12, 2015-07-29 (James Jones)
-
Rewrote the guts of the extension against the latest WSI swapchain specifications and the latest Vulkan API.
-
Address overlay planes by their index rather than an object handle and refer to them as “planes” rather than “overlays” to make it slightly clearer that even a display with no “overlays” still has at least one base “plane” that images can be displayed on.
-
Updated most of the issues.
-
Added an “extension type” section to the specification header.
-
Reused the VK_EXT_KHR_surface surface transform enumerations rather than redefining them here.
-
Updated the example code to use the new semantics.
-
-
Revision 13, 2015-08-21 (Ian Elliott)
-
Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.
-
Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.
-
-
Revision 14, 2015-09-01 (James Jones)
-
Restore single-field revision number.
-
-
Revision 15, 2015-09-08 (James Jones)
-
Added alpha flags enum.
-
Added premultiplied alpha support.
-
-
Revision 16, 2015-09-08 (James Jones)
-
Added description section to the spec.
-
Added issues 16 - 18.
-
-
Revision 17, 2015-10-02 (James Jones)
-
Planes are now a property of the entire device rather than individual displays. This allows planes to be moved between multiple displays on devices that support it.
-
Added a function to create a VkSurfaceKHR object describing a display plane and mode to align with the new per-platform surface creation conventions.
-
Removed detailed mode timing data. It was agreed that the mode extents and refresh rate are sufficient for current use cases. Other information could be added back in as an extension if it is needed in the future.
-
Added support for smart/persistent/buffered display devices.
-
-
Revision 18, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_display to VK_KHR_display.
-
-
Revision 19, 2015-11-02 (James Jones)
-
Updated example code to match revision 17 changes.
-
-
Revision 20, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to creation functions.
-
-
Revision 21, 2015-11-10 (Jesse Hall)
-
Added VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR, and use VkDisplayPlaneAlphaFlagBitsKHR for VkDisplayPlanePropertiesKHR::alphaMode instead of VkDisplayPlaneAlphaFlagsKHR, since it only represents one mode.
-
Added reserved flags bitmask to VkDisplayPlanePropertiesKHR.
-
Use VkSurfaceTransformFlagBitsKHR instead of obsolete VkSurfaceTransformKHR.
-
Renamed vkGetDisplayPlaneSupportedDisplaysKHR parameters for clarity.
-
-
Revision 22, 2015-12-18 (James Jones)
-
Added missing “planeIndex” parameter to vkGetDisplayPlaneSupportedDisplaysKHR()
-
-
Revision 23, 2017-03-13 (James Jones)
-
Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.
-
Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.
-
VK_KHR_display_swapchain
- Name String
-
VK_KHR_display_swapchain
- Extension Type
-
Device extension
- Registered Extension Number
-
4
- Revision
-
10
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2017-03-13
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Jeff Vigil, Qualcomm
-
Jesse Hall, Google
-
Description
This extension provides an API to create a swapchain directly on a device’s display without any underlying window system.
New Structures
-
Extending VkPresentInfoKHR:
New Enum Constants
-
VK_KHR_DISPLAY_SWAPCHAIN_EXTENSION_NAME
-
VK_KHR_DISPLAY_SWAPCHAIN_SPEC_VERSION
-
Extending VkResult:
-
VK_ERROR_INCOMPATIBLE_DISPLAY_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR
-
Issues
1) Should swapchains sharing images each hold a reference to the images, or should it be up to the application to destroy the swapchains and images in an order that avoids the need for reference counting?
RESOLVED: Take a reference. The lifetime of presentable images is already complex enough.
2) Should the srcRect
and dstRect
parameters be specified as
part of the presentation command, or at swapchain creation time?
RESOLVED: As part of the presentation command. This allows moving and scaling the image on the screen without the need to respecify the mode or create a new swapchain and presentable images.
3) Should srcRect
and dstRect
be specified as rects, or separate
offset/extent values?
RESOLVED: As rects. Specifying them separately might make it easier for hardware to expose support for one but not the other, but in such cases applications must just take care to obey the reported capabilities and not use non-zero offsets or extents that require scaling, as appropriate.
4) How can applications create multiple swapchains that use the same images?
RESOLVED: By calling vkCreateSharedSwapchainsKHR.
An earlier resolution used vkCreateSwapchainKHR, chaining multiple
VkSwapchainCreateInfoKHR structures through pNext
.
In order to allow each swapchain to also allow other extension structs, a
level of indirection was used: VkSwapchainCreateInfoKHR::pNext
pointed to a different structure, which had both sType
and pNext
members for additional extensions, and also had a pointer to the next
VkSwapchainCreateInfoKHR structure.
The number of swapchains to be created could only be found by walking this
linked list of alternating structures, and the pSwapchains
out
parameter was reinterpreted to be an array of VkSwapchainKHR handles.
Another option considered was a method to specify a “shared” swapchain when creating a new swapchain, such that groups of swapchains using the same images could be built up one at a time. This was deemed unusable because drivers need to know all of the displays an image will be used on when determining which internal formats and layouts to use for that image.
Examples
Note
The example code for the |
Version History
-
Revision 1, 2015-07-29 (James Jones)
-
Initial draft
-
-
Revision 2, 2015-08-21 (Ian Elliott)
-
Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.
-
Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.
-
-
Revision 3, 2015-09-01 (James Jones)
-
Restore single-field revision number.
-
-
Revision 4, 2015-09-08 (James Jones)
-
Allow creating multiple swapchains that share the same images using a single call to vkCreateSwapchainKHR().
-
-
Revision 5, 2015-09-10 (Alon Or-bach)
-
Removed underscores from SWAP_CHAIN in two enums.
-
-
Revision 6, 2015-10-02 (James Jones)
-
Added support for smart panels/buffered displays.
-
-
Revision 7, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_display_swapchain to VK_KHR_display_swapchain.
-
-
Revision 8, 2015-11-03 (Daniel Rakos)
-
Updated sample code based on the changes to VK_KHR_swapchain.
-
-
Revision 9, 2015-11-10 (Jesse Hall)
-
Replaced VkDisplaySwapchainCreateInfoKHR with vkCreateSharedSwapchainsKHR, changing resolution of issue #4.
-
-
Revision 10, 2017-03-13 (James Jones)
-
Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.
-
Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.
-
VK_KHR_dynamic_rendering_local_read
- Name String
-
VK_KHR_dynamic_rendering_local_read
- Extension Type
-
Device extension
- Registered Extension Number
-
233
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Tobias Hector tobski
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-11-03
- Contributors
-
-
Tobias Hector, AMD
-
Hans-Kristian Arntzen, Valve
-
Connor Abbott, Valve
-
Pan Gao, Huawei
-
Lionel Landwerlin, Intel
-
Shahbaz Youssefi, Google
-
Alyssa Rosenzweig, Valve
-
Jan-Harald Fredriksen, Arm
-
Mike Blumenkrantz, Valve
-
Graeme Leese, Broadcom
-
Piers Daniell, Nvidia
-
Stuart Smith, AMD
-
Daniel Story, Nintendo
-
James Fitzpatrick, Imagination
-
Piotr Byszewski, Mobica
-
Spencer Fricke, LunarG
-
Tom Olson, Arm
-
Michal Pietrasiuk, Intel
-
Matthew Netsch, Qualcomm
-
Marty Johnson, Khronos
-
Wyvern Wang, Huawei
-
Jeff Bolz, Nvidia
-
Samuel (Sheng-Wen) Huang, MediaTek
-
Description
This extension enables reads from attachments and resources written by previous fragment shaders within a dynamic render pass.
New Enum Constants
-
VK_KHR_DYNAMIC_RENDERING_LOCAL_READ_EXTENSION_NAME
-
VK_KHR_DYNAMIC_RENDERING_LOCAL_READ_SPEC_VERSION
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_LOCAL_READ_FEATURES_KHR
-
VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_LOCATION_INFO_KHR
-
VK_STRUCTURE_TYPE_RENDERING_INPUT_ATTACHMENT_INDEX_INFO_KHR
-
VK_KHR_external_fence_fd
- Name String
-
VK_KHR_external_fence_fd
- Extension Type
-
Device extension
- Registered Extension Number
-
116
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2017-05-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Cass Everitt, Oculus
-
Contributors to
VK_KHR_external_semaphore_fd
-
Description
An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from POSIX file descriptors.
New Enum Constants
-
VK_KHR_EXTERNAL_FENCE_FD_EXTENSION_NAME
-
VK_KHR_EXTERNAL_FENCE_FD_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FENCE_GET_FD_INFO_KHR
-
VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR
-
Issues
This extension borrows concepts, semantics, and language from
VK_KHR_external_semaphore_fd
.
That extension’s issues apply equally to this extension.
VK_KHR_external_fence_win32
- Name String
-
VK_KHR_external_fence_win32
- Extension Type
-
Device extension
- Registered Extension Number
-
115
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2017-05-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Cass Everitt, Oculus
-
Contributors to
VK_KHR_external_semaphore_win32
-
Description
An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from Windows handles.
New Enum Constants
-
VK_KHR_EXTERNAL_FENCE_WIN32_EXTENSION_NAME
-
VK_KHR_EXTERNAL_FENCE_WIN32_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR
-
Issues
This extension borrows concepts, semantics, and language from
VK_KHR_external_semaphore_win32
.
That extension’s issues apply equally to this extension.
1) Should D3D12 fence handle types be supported, like they are for semaphores?
RESOLVED: No.
Doing so would require extending the fence signal and wait operations to
provide values to signal / wait for, like VkD3D12FenceSubmitInfoKHR
does.
A D3D12 fence can be signaled by importing it into a VkSemaphore
instead of a VkFence, and applications can check status or wait on the
D3D12 fence using non-Vulkan APIs.
The convenience of being able to do these operations on VkFence
objects does not justify the extra API complexity.
VK_KHR_external_memory_fd
- Name String
-
VK_KHR_external_memory_fd
- Extension Type
-
Device extension
- Registered Extension Number
-
75
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Description
An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export POSIX file descriptor handles from Vulkan memory objects and to import Vulkan memory objects from POSIX file descriptor handles exported from other Vulkan memory objects or from similar resources in other APIs.
New Enum Constants
-
VK_KHR_EXTERNAL_MEMORY_FD_EXTENSION_NAME
-
VK_KHR_EXTERNAL_MEMORY_FD_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR
-
Issues
1) Does the application need to close the file descriptor returned by vkGetMemoryFdKHR?
RESOLVED: Yes, unless it is passed back in to a driver instance to import the memory. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original memory object will not close the file descriptor or remove its reference to the underlying memory resource associated with it.
2) Do drivers ever need to expose multiple file descriptors per memory object?
RESOLVED: No. This would indicate there are actually multiple memory objects, rather than a single memory object.
3) How should the valid size and memory type for POSIX file descriptor memory handles created outside of Vulkan be specified?
RESOLVED: The valid memory types are queried directly from the external handle. The size will be specified by future extensions that introduce such external memory handle types.
VK_KHR_external_memory_win32
- Name String
-
VK_KHR_external_memory_win32
- Extension Type
-
Device extension
- Registered Extension Number
-
74
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Carsten Rohde, NVIDIA
-
Description
An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export Windows handles from Vulkan memory objects and to import Vulkan memory objects from Windows handles exported from other Vulkan memory objects or from similar resources in other APIs.
New Enum Constants
-
VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME
-
VK_KHR_EXTERNAL_MEMORY_WIN32_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR
-
Issues
1) Do applications need to call CloseHandle
() on the values returned
from vkGetMemoryWin32HandleKHR when handleType
is
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
?
RESOLVED: Yes. A successful get call transfers ownership of the handle to the application. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource. Unlike file descriptor opaque handles, win32 opaque handle ownership can not be transferred back to a driver by an import operation.
2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?
RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.
3) How should the valid size and memory type for windows memory handles created outside of Vulkan be specified?
RESOLVED: The valid memory types are queried directly from the external handle. The size is determined by the associated image or buffer memory requirements for external handle types that require dedicated allocations, and by the size specified when creating the object from which the handle was exported for other external handle types.
VK_KHR_external_semaphore_fd
- Name String
-
VK_KHR_external_semaphore_fd
- Extension Type
-
Device extension
- Registered Extension Number
-
80
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Carsten Rohde, NVIDIA
-
Description
An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to export semaphore payload to and import semaphore payload from POSIX file descriptors.
New Enum Constants
-
VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME
-
VK_KHR_EXTERNAL_SEMAPHORE_FD_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR
-
Issues
1) Does the application need to close the file descriptor returned by vkGetSemaphoreFdKHR?
RESOLVED: Yes, unless it is passed back in to a driver instance to import the semaphore. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original semaphore object will not close the file descriptor or remove its reference to the underlying semaphore resource associated with it.
VK_KHR_external_semaphore_win32
- Name String
-
VK_KHR_external_semaphore_win32
- Extension Type
-
Device extension
- Registered Extension Number
-
79
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Carsten Rohde, NVIDIA
-
Description
An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to export semaphore payload to and import semaphore payload from Windows handles.
New Enum Constants
-
VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME
-
VK_KHR_EXTERNAL_SEMAPHORE_WIN32_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR
-
VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR
-
Issues
1) Do applications need to call CloseHandle
() on the values returned
from vkGetSemaphoreWin32HandleKHR when handleType
is
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
?
RESOLVED: Yes. A successful get call transfers ownership of the handle to the application. Destroying the semaphore object will not destroy the handle or the handle’s reference to the underlying semaphore resource. Unlike file descriptor opaque handles, win32 opaque handle ownership can not be transferred back to a driver by an import operation.
2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?
RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.
3) Should applications be allowed to specify additional object attributes for shared handles?
RESOLVED: Yes. Applications will be allowed to provide similar attributes to those they would to any other handle creation API.
4) How do applications communicate the desired fence values to use with
D3D12_FENCE
-based Vulkan semaphores?
RESOLVED: There are a couple of options. The values for the signaled and reset states could be communicated up front when creating the object and remain static for the life of the Vulkan semaphore, or they could be specified using auxiliary structures when submitting semaphore signal and wait operations, similar to what is done with the keyed mutex extensions. The latter is more flexible and consistent with the keyed mutex usage, but the former is a much simpler API.
Since Vulkan tends to favor flexibility and consistency over simplicity, a new structure specifying D3D12 fence acquire and release values is added to the vkQueueSubmit function.
VK_KHR_fragment_shader_barycentric
- Name String
-
VK_KHR_fragment_shader_barycentric
- Extension Type
-
Device extension
- Registered Extension Number
-
323
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Stu Smith
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2022-03-10
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_fragment_shader_barycentric
-
- Contributors
-
-
Stu Smith, AMD
-
Tobias Hector, AMD
-
Graeme Leese, Broadcom
-
Jan-Harald Fredriksen, Arm
-
Slawek Grajewski, Intel
-
Pat Brown, NVIDIA
-
Hans-Kristian Arntzen, Valve
-
Contributors to the VK_NV_fragment_shader_barycentric specification
-
Description
This extension is based on the
extension, and adds support for the following SPIR-V extension in Vulkan:VK_NV_fragment_shader_barycentric
The extension provides access to three additional fragment shader variable decorations in SPIR-V:
-
PerVertexKHR
, which indicates that a fragment shader input will not have interpolated values, but instead must be accessed with an extra array index that identifies one of the vertices of the primitive producing the fragment -
BaryCoordKHR
, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using perspective interpolation -
BaryCoordNoPerspKHR
, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using linear interpolation
When using GLSL source-based shader languages, the following variables from
GL_EXT_fragment_shader_barycentric
map to these SPIR-V built-in
decorations:
-
in vec3 gl_BaryCoordEXT;
→BaryCoordKHR
-
in vec3 gl_BaryCoordNoPerspEXT;
→BaryCoordNoPerspKHR
GLSL variables declared using the pervertexEXT
GLSL qualifier are
expected to be decorated with PerVertexKHR
in SPIR-V.
New Enum Constants
-
VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME
-
VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_PROPERTIES_KHR
-
Issues
1) What are the interactions with MSAA and how are BaryCoordKHR
and
BaryCoordNoPerspKHR
interpolated?
RESOLVED: The inputs decorated with BaryCoordKHR
or
BaryCoordNoPerspKHR
may also be decorated with the Centroid
or
Sample
qualifiers to specify interpolation, like any other fragment
shader input.
If shaderSampleRateInterpolationFunctions
is enabled, the extended
instructions InterpolateAtCentroid, InterpolateAtOffset, and
InterpolateAtSample from the GLSL.std.450 may also be used with inputs
decorated with BaryCoordKHR
or BaryCoordNoPerspKHR
.
VK_KHR_fragment_shading_rate
- Name String
-
VK_KHR_fragment_shading_rate
- Extension Type
-
Device extension
- Registered Extension Number
-
227
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_KHR_format_feature_flags2
-
- SPIR-V Dependencies
- Contact
-
-
Tobias Hector tobski
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2021-09-30
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_fragment_shading_rate
-
- Contributors
-
-
Tobias Hector, AMD
-
Guennadi Riguer, AMD
-
Matthaeus Chajdas, AMD
-
Pat Brown, Nvidia
-
Matthew Netsch, Qualcomm
-
Slawomir Grajewski, Intel
-
Jan-Harald Fredriksen, Arm
-
Jeff Bolz, Nvidia
-
Arseny Kapoulkine, Roblox
-
Contributors to the VK_NV_shading_rate_image specification
-
Contributors to the VK_EXT_fragment_density_map specification
-
Description
This extension adds the ability to change the rate at which fragments are shaded. Rather than the usual single fragment invocation for each pixel covered by a primitive, multiple pixels can be shaded by a single fragment shader invocation.
Up to three methods are available to the application to change the fragment shading rate:
-
Pipeline Fragment Shading Rate, which allows the specification of a rate per-draw.
-
Primitive Fragment Shading Rate, which allows the specification of a rate per primitive, specified during shading.
-
Attachment Fragment Shading Rate, which allows the specification of a rate per-region of the framebuffer, specified in a specialized image attachment.
Additionally, these rates can all be specified and combined in order to adjust the overall detail in the image at each point.
This functionality can be used to focus shading efforts where higher levels of detail are needed in some parts of a scene compared to others. This can be particularly useful in high resolution rendering, or for XR contexts.
This extension also adds support for the SPV_KHR_fragment_shading_rate
extension which enables setting the
primitive fragment shading
rate, and allows querying the final shading rate from a fragment shader.
New Structures
-
Extending VkGraphicsPipelineCreateInfo:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkSubpassDescription2:
New Enum Constants
-
VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME
-
VK_KHR_FRAGMENT_SHADING_RATE_SPEC_VERSION
-
Extending VkAccessFlagBits:
-
VK_ACCESS_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR
-
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_FRAGMENT_SHADING_RATE_KHR
-
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_FRAGMENT_SHADING_RATE_ATTACHMENT_OPTIMAL_KHR
-
-
Extending VkImageUsageFlagBits:
-
VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
-
Extending VkPipelineStageFlagBits:
-
VK_PIPELINE_STAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_STATE_CREATE_INFO_KHR
-
If VK_KHR_format_feature_flags2 or Version 1.3 is supported:
-
Extending VkFormatFeatureFlagBits2:
-
VK_FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
Version History
-
Revision 1, 2020-05-06 (Tobias Hector)
-
Initial revision
-
-
Revision 2, 2021-09-30 (Jon Leech)
-
Add interaction with
VK_KHR_format_feature_flags2
tovk.xml
-
VK_KHR_get_display_properties2
- Name String
-
VK_KHR_get_display_properties2
- Extension Type
-
Instance extension
- Registered Extension Number
-
122
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2017-02-21
- IP Status
-
No known IP claims.
- Contributors
-
-
Ian Elliott, Google
-
James Jones, NVIDIA
-
Description
This extension provides new queries for device display properties and
capabilities that can be easily extended by other extensions, without
introducing any further queries.
This extension can be considered the VK_KHR_display
equivalent of
the VK_KHR_get_physical_device_properties2
extension.
New Enum Constants
-
VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME
-
VK_KHR_GET_DISPLAY_PROPERTIES_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DISPLAY_MODE_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_DISPLAY_PLANE_CAPABILITIES_2_KHR
-
VK_STRUCTURE_TYPE_DISPLAY_PLANE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_DISPLAY_PLANE_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_DISPLAY_PROPERTIES_2_KHR
-
Issues
1) What should this extension be named?
RESOLVED: VK_KHR_get_display_properties2
.
Other alternatives:
-
VK_KHR_display2
-
One extension, combined with
VK_KHR_surface_capabilites2
.
2) Should extensible input structs be added for these new functions:
RESOLVED:
-
vkGetPhysicalDeviceDisplayProperties2KHR: No. The only current input is a VkPhysicalDevice. Other inputs would not make sense.
-
vkGetPhysicalDeviceDisplayPlaneProperties2KHR: No. The only current input is a VkPhysicalDevice. Other inputs would not make sense.
-
vkGetDisplayModeProperties2KHR: No. The only current inputs are a VkPhysicalDevice and a VkDisplayModeKHR. Other inputs would not make sense.
3) Should additional display query functions be extended?
RESOLVED:
-
vkGetDisplayPlaneSupportedDisplaysKHR: No. Extensions should instead extend vkGetDisplayPlaneCapabilitiesKHR().
VK_KHR_get_surface_capabilities2
- Name String
-
VK_KHR_get_surface_capabilities2
- Extension Type
-
Instance extension
- Registered Extension Number
-
120
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2017-02-27
- IP Status
-
No known IP claims.
- Contributors
-
-
Ian Elliott, Google
-
James Jones, NVIDIA
-
Alon Or-bach, Samsung
-
Description
This extension provides new queries for device surface capabilities that can
be easily extended by other extensions, without introducing any further
queries.
This extension can be considered the VK_KHR_surface
equivalent of
the VK_KHR_get_physical_device_properties2
extension.
New Enum Constants
-
VK_KHR_GET_SURFACE_CAPABILITIES_2_EXTENSION_NAME
-
VK_KHR_GET_SURFACE_CAPABILITIES_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR
-
VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR
-
Issues
1) What should this extension be named?
RESOLVED: VK_KHR_get_surface_capabilities2
.
Other alternatives:
-
VK_KHR_surface2
-
One extension, combining a separate display-specific query extension.
2) Should additional WSI query functions be extended?
RESOLVED:
-
vkGetPhysicalDeviceSurfaceCapabilitiesKHR: Yes. The need for this motivated the extension.
-
vkGetPhysicalDeviceSurfaceSupportKHR: No. Currently only has boolean output. Extensions should instead extend vkGetPhysicalDeviceSurfaceCapabilities2KHR.
-
vkGetPhysicalDeviceSurfacePresentModesKHR: No. Recent discussion concluded this introduced too much variability for applications to deal with. Extensions should instead extend vkGetPhysicalDeviceSurfaceCapabilities2KHR.
-
vkGetPhysicalDeviceXlibPresentationSupportKHR: Not in this extension.
-
vkGetPhysicalDeviceXcbPresentationSupportKHR: Not in this extension.
-
vkGetPhysicalDeviceWaylandPresentationSupportKHR: Not in this extension.
-
vkGetPhysicalDeviceWin32PresentationSupportKHR: Not in this extension.
VK_KHR_global_priority
- Name String
-
VK_KHR_global_priority
- Extension Type
-
Device extension
- Registered Extension Number
-
189
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Tobias Hector tobski
-
Other Extension Metadata
- Last Modified Date
-
2021-10-22
- Contributors
-
-
Tobias Hector, AMD
-
Contributors to
VK_EXT_global_priority
-
Contributors to
VK_EXT_global_priority_query
-
Description
In Vulkan, users can specify device-scope queue priorities.
In some cases it may be useful to extend this concept to a system-wide
scope.
This device extension allows applications to query the global queue
priorities supported by a queue family, and then set a priority when
creating queues.
The default queue priority is VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT
.
Implementations can report which global priority levels are treated differently by the implementation. It is intended primarily for use in system integration along with certain platform-specific priority enforcement rules.
The driver implementation will attempt to skew hardware resource allocation in favor of the higher-priority task. Therefore, higher-priority work may retain similar latency and throughput characteristics even if the system is congested with lower priority work.
The global priority level of a queue shall take precedence over the
per-process queue priority
(VkDeviceQueueCreateInfo
::pQueuePriorities
).
Abuse of this feature may result in starving the rest of the system from
hardware resources.
Therefore, the driver implementation may deny requests to acquire a priority
above the default priority (VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT
) if
the caller does not have sufficient privileges.
In this scenario VK_ERROR_NOT_PERMITTED_EXT
is returned.
The driver implementation may fail the queue allocation request if resources
required to complete the operation have been exhausted (either by the same
process or a different process).
In this scenario VK_ERROR_INITIALIZATION_FAILED
is returned.
New Enum Constants
-
VK_KHR_GLOBAL_PRIORITY_EXTENSION_NAME
-
VK_KHR_GLOBAL_PRIORITY_SPEC_VERSION
-
VK_MAX_GLOBAL_PRIORITY_SIZE_KHR
-
Extending VkResult:
-
VK_ERROR_NOT_PERMITTED_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_KHR
-
VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_KHR
-
Issues
1) Can we additionally query whether a caller is permitted to acquire a specific global queue priority in this extension?
RESOLVED: No. Whether a caller has enough privilege goes with the OS, and the Vulkan driver cannot really guarantee that the privilege will not change in between this query and the actual queue creation call.
2) If more than 1 queue using global priority is requested, is there a good way to know which queue is failing the device creation?
RESOLVED: No. There is not a good way at this moment, and it is also not quite actionable for the applications to know that because the information may not be accurate. Queue creation can fail because of runtime constraints like insufficient privilege or lack of resource, and the failure is not necessarily tied to that particular queue configuration requested.
VK_KHR_incremental_present
- Name String
-
VK_KHR_incremental_present
- Extension Type
-
Device extension
- Registered Extension Number
-
85
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2016-11-02
- IP Status
-
No known IP claims.
- Contributors
-
-
Ian Elliott, Google
-
Jesse Hall, Google
-
Alon Or-bach, Samsung
-
James Jones, NVIDIA
-
Daniel Rakos, AMD
-
Ray Smith, ARM
-
Mika Isojarvi, Google
-
Jeff Juliano, NVIDIA
-
Jeff Bolz, NVIDIA
-
Description
This device extension extends vkQueuePresentKHR, from the
VK_KHR_swapchain
extension, allowing an application to specify a
list of rectangular, modified regions of each image to present.
This should be used in situations where an application is only changing a
small portion of the presentable images within a swapchain, since it enables
the presentation engine to avoid wasting time presenting parts of the
surface that have not changed.
This extension is leveraged from the EGL_KHR_swap_buffers_with_damage
extension.
New Enum Constants
-
VK_KHR_INCREMENTAL_PRESENT_EXTENSION_NAME
-
VK_KHR_INCREMENTAL_PRESENT_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR
-
Issues
1) How should we handle steroescopic-3D swapchains? We need to add a layer
for each rectangle.
One approach is to create another struct containing the VkRect2D plus
layer, and have VkPresentRegionsKHR point to an array of that struct.
Another approach is to have two parallel arrays, pRectangles
and
pLayers
, where pRectangles
[i] and pLayers
[i] must be used
together.
Which approach should we use, and if the array of a new structure, what
should that be called?
RESOLVED: Create a new structure, which is a VkRect2D plus a layer, and will be called VkRectLayerKHR.
2) Where is the origin of the VkRectLayerKHR?
RESOLVED: The upper left corner of the presentable image(s) of the swapchain, per the definition of framebuffer coordinates.
3) Does the rectangular region, VkRectLayerKHR, specify pixels of the swapchain’s image(s), or of the surface?
RESOLVED: Of the image(s). Some presentation engines may scale the pixels of a swapchain’s image(s) to the size of the surface. The size of the swapchain’s image(s) will be consistent, where the size of the surface may vary over time.
4) What if all of the rectangles for a given swapchain contain a width and/or height of zero?
RESOLVED: The application is indicating that no pixels changed since the last present. The presentation engine may use such a hint and not update any pixels for the swapchain. However, all other semantics of vkQueuePresentKHR must still be honored, including waiting for semaphores to signal.
5) When the swapchain is created with
VkSwapchainCreateInfoKHR
::preTransform
set to a value other than
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
, should the rectangular region,
VkRectLayerKHR, be transformed to align with the preTransform
?
RESOLVED: No. The rectangular region in VkRectLayerKHR should not be transformed. As such, it may not align with the extents of the swapchain’s image(s). It is the responsibility of the presentation engine to transform the rectangular region. This matches the behavior of the Android presentation engine, which set the precedent.
VK_KHR_index_type_uint8
- Name String
-
VK_KHR_index_type_uint8
- Extension Type
-
Device extension
- Registered Extension Number
-
534
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2023-06-06
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Description
This extension allows uint8_t
indices to be used with
vkCmdBindIndexBuffer.
New Enum Constants
-
VK_KHR_INDEX_TYPE_UINT8_EXTENSION_NAME
-
VK_KHR_INDEX_TYPE_UINT8_SPEC_VERSION
-
Extending VkIndexType:
-
VK_INDEX_TYPE_UINT8_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_KHR
-
VK_KHR_line_rasterization
- Name String
-
VK_KHR_line_rasterization
- Extension Type
-
Device extension
- Registered Extension Number
-
535
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2023-06-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Allen Jensen, NVIDIA
-
Faith Ekstrand, Intel
-
Description
This extension adds some line rasterization features that are commonly used in CAD applications and supported in other APIs like OpenGL. Bresenham-style line rasterization is supported, smooth rectangular lines (coverage to alpha) are supported, and stippled lines are supported for all three line rasterization modes.
New Enum Constants
-
VK_KHR_LINE_RASTERIZATION_EXTENSION_NAME
-
VK_KHR_LINE_RASTERIZATION_SPEC_VERSION
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_LINE_STIPPLE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_KHR
-
Issues
1) Do we need to support Bresenham-style and smooth lines with more than one rasterization sample? i.e. the equivalent of glDisable(GL_MULTISAMPLE) in OpenGL when the framebuffer has more than one sample?
RESOLVED: Yes. For simplicity, Bresenham line rasterization carries forward a few restrictions from OpenGL, such as not supporting per-sample shading, alpha to coverage, or alpha to one.
VK_KHR_load_store_op_none
- Name String
-
VK_KHR_load_store_op_none
- Extension Type
-
Device extension
- Registered Extension Number
-
527
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Shahbaz Youssefi syoussefi
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-05-16
- Contributors
-
-
Shahbaz Youssefi, Google
-
Bill Licea-Kane, Qualcomm Technologies, Inc.
-
Tobias Hector, AMD
-
Description
This extension provides VK_ATTACHMENT_LOAD_OP_NONE_KHR
and
VK_ATTACHMENT_STORE_OP_NONE_KHR
, which are identically promoted from
the VK_EXT_load_store_op_none
extension.
New Enum Constants
-
VK_KHR_LOAD_STORE_OP_NONE_EXTENSION_NAME
-
VK_KHR_LOAD_STORE_OP_NONE_SPEC_VERSION
-
Extending VkAttachmentLoadOp:
-
VK_ATTACHMENT_LOAD_OP_NONE_KHR
-
-
Extending VkAttachmentStoreOp:
-
VK_ATTACHMENT_STORE_OP_NONE_KHR
-
VK_KHR_maintenance5
- Name String
-
VK_KHR_maintenance5
- Extension Type
-
Device extension
- Registered Extension Number
-
471
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_1
-
Interacts with VK_VERSION_1_2
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_EXT_attachment_feedback_loop_layout
-
Interacts with VK_EXT_buffer_device_address
-
Interacts with VK_EXT_conditional_rendering
-
Interacts with VK_EXT_descriptor_buffer
-
Interacts with VK_EXT_fragment_density_map
-
Interacts with VK_EXT_graphics_pipeline_library
-
Interacts with VK_EXT_opacity_micromap
-
Interacts with VK_EXT_pipeline_creation_cache_control
-
Interacts with VK_EXT_pipeline_protected_access
-
Interacts with VK_EXT_transform_feedback
-
Interacts with VK_KHR_acceleration_structure
-
Interacts with VK_KHR_buffer_device_address
-
Interacts with VK_KHR_device_group
-
Interacts with VK_KHR_dynamic_rendering
-
Interacts with VK_KHR_fragment_shading_rate
-
Interacts with VK_KHR_pipeline_executable_properties
-
Interacts with VK_KHR_pipeline_library
-
Interacts with VK_KHR_ray_tracing_pipeline
-
Interacts with VK_KHR_video_decode_queue
-
Interacts with VK_KHR_video_encode_queue
-
Interacts with VK_NV_device_generated_commands
-
Interacts with VK_NV_displacement_micromap
-
Interacts with VK_NV_ray_tracing
-
Interacts with VK_NV_ray_tracing_motion_blur
-
- Contact
-
-
Stu Smith stu-s
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-05-02
- Interactions and External Dependencies
- Contributors
-
-
Stu Smith, AMD
-
Tobias Hector, AMD
-
Shahbaz Youssefi, Google
-
Slawomir Cygan, Intel
-
Lionel Landwerlin, Intel
-
James Fitzpatrick, Imagination Technologies
-
Andrew Garrard, Imagination Technologies
-
Ralph Potter, Samsung
-
Pan Gao, Huawei
-
Jan-Harald Fredriksen, ARM
-
Jon Leech, Khronos
-
Mike Blumenkrantz, Valve
-
Description
VK_KHR_maintenance5
adds a collection of minor features, none of which
would warrant an entire extension of their own.
The new features are as follows:
-
A new
VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
format -
A new
VK_FORMAT_A8_UNORM_KHR
format -
A property to indicate that multisample coverage operations are performed after sample counting in EarlyFragmentTests mode
-
Relax VkBufferView creation requirements by allowing subsets of the associated VkBuffer usage using
VkBufferUsageFlags2CreateInfoKHR
-
A new entry point vkCmdBindIndexBuffer2KHR, allowing a range of memory to be bound as an index buffer
-
vkGetDeviceProcAddr must return
NULL
for supported core functions beyond the version requested by the application. -
A property to indicate that the sample mask test is performed after sample counting in EarlyFragmentTests mode
-
vkCmdBindVertexBuffers2
now supports usingVK_WHOLE_SIZE
in thepSizes
parameter. -
A default size of 1.0 is used if
PointSize
is not written -
Shader modules are deprecated - applications can now pass VkShaderModuleCreateInfo as a chained struct to pipeline creation via VkPipelineShaderStageCreateInfo
-
A function vkGetRenderingAreaGranularityKHR to query the optimal render area for a dynamic rendering instance.
-
A property to indicate that depth/stencil texturing operations with
VK_COMPONENT_SWIZZLE_ONE
have defined behavior -
Add vkGetImageSubresourceLayout2KHR and a new function vkGetDeviceImageSubresourceLayoutKHR to allow the application to query the image memory layout without having to create an image object and query it.
-
Allow
VK_REMAINING_ARRAY_LAYERS
as thelayerCount
member of VkImageSubresourceLayers -
Adds stronger guarantees for propagation of
VK_ERROR_DEVICE_LOST
return values -
A property to indicate whether
PointSize
controls the final rasterization of polygons if polygon mode isVK_POLYGON_MODE_POINT
-
Two properties to indicate the non-strict line rasterization algorithm used
-
Two new flags words VkPipelineCreateFlagBits2KHR and VkBufferUsageFlagBits2KHR
-
Physical-device-level functions can now be called with any value in the valid range for a type beyond the defined enumerants, such that applications can avoid checking individual features, extensions, or versions before querying supported properties of a particular enumerant.
-
Clarification that copies between images of any type are allowed, treating 1D images as 2D images with a height of 1.
New Structures
-
Extending VkBufferViewCreateInfo, VkBufferCreateInfo, VkPhysicalDeviceExternalBufferInfo,
VkDescriptorBufferBindingInfoEXT
: -
Extending VkComputePipelineCreateInfo, VkGraphicsPipelineCreateInfo,
VkRayTracingPipelineCreateInfoNV
, VkRayTracingPipelineCreateInfoKHR: -
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
New Enum Constants
-
VK_KHR_MAINTENANCE_5_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_5_SPEC_VERSION
-
Extending VkFormat:
-
VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
-
VK_FORMAT_A8_UNORM_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BUFFER_USAGE_FLAGS_2_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_IMAGE_SUBRESOURCE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_CREATE_FLAGS_2_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_RENDERING_AREA_INFO_KHR
-
VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_KHR
-
If VK_EXT_attachment_feedback_loop_layout is supported:
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
-
VK_PIPELINE_CREATE_2_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
-
If VK_EXT_opacity_micromap is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT
-
VK_BUFFER_USAGE_2_MICROMAP_STORAGE_BIT_EXT
-
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT
-
If VK_EXT_transform_feedback is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT
-
VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT
-
If VK_KHR_acceleration_structure is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR
-
VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR
-
If VK_KHR_pipeline_executable_properties is supported:
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR
-
VK_PIPELINE_CREATE_2_CAPTURE_STATISTICS_BIT_KHR
-
If VK_KHR_pipeline_library is supported:
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_LIBRARY_BIT_KHR
-
If VK_KHR_ray_tracing_pipeline is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_SHADER_BINDING_TABLE_BIT_KHR
-
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_AABBS_BIT_KHR
-
VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR
-
If VK_KHR_video_decode_queue is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_VIDEO_DECODE_DST_BIT_KHR
-
VK_BUFFER_USAGE_2_VIDEO_DECODE_SRC_BIT_KHR
-
If VK_KHR_video_encode_queue is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_VIDEO_ENCODE_DST_BIT_KHR
-
VK_BUFFER_USAGE_2_VIDEO_ENCODE_SRC_BIT_KHR
-
If Version 1.1 or VK_KHR_device_group is supported:
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_DISPATCH_BASE_BIT_KHR
-
VK_PIPELINE_CREATE_2_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR
-
If Version 1.2 or VK_KHR_buffer_device_address or VK_EXT_buffer_device_address
is supported:
-
Extending VkBufferUsageFlagBits2KHR:
-
VK_BUFFER_USAGE_2_SHADER_DEVICE_ADDRESS_BIT_KHR
-
If Version 1.3 or VK_EXT_pipeline_creation_cache_control
is supported:
-
Extending VkPipelineCreateFlagBits2KHR:
-
VK_PIPELINE_CREATE_2_EARLY_RETURN_ON_FAILURE_BIT_KHR
-
VK_PIPELINE_CREATE_2_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_KHR
-
VK_KHR_maintenance6
- Name String
-
VK_KHR_maintenance6
- Extension Type
-
Device extension
- Registered Extension Number
-
546
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_EXT_descriptor_buffer
-
Interacts with VK_KHR_push_descriptor
-
- Contact
-
-
Jon Leech oddhack
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-08-03
- Interactions and External Dependencies
-
-
Interacts with
VK_EXT_robustness2
-
- Contributors
-
-
Jon Leech, Khronos
-
Stu Smith, AMD
-
Mike Blumenkrantz, Valve
-
Ralph Potter, Samsung
-
James Fitzpatrick, Imagination Technologies
-
Piers Daniell, NVIDIA
-
Daniel Story, Nintendo
-
Description
VK_KHR_maintenance6 adds a collection of minor features, none of which would warrant an entire extension of their own.
The new features are as follows:
-
VkBindMemoryStatusKHR may be included in the
pNext
chain of VkBindBufferMemoryInfo and VkBindImageMemoryInfo, allowing applications to identify individual resources for which memory binding failed during calls to vkBindBufferMemory2 and vkBindImageMemory2. -
A new property
fragmentShadingRateClampCombinerInputs
to indicate if an implementation clamps the inputs to fragment shading rate combiner operations. -
VK_NULL_HANDLE is allowed to be used when binding an index buffer, instead of a valid VkBuffer handle. When the
nullDescriptor
feature is enabled, every index fetched results in a value of zero. -
A new property
maxCombinedImageSamplerDescriptorCount
to indicate the maximum number of descriptors needed for any of the formats that require a sampler Y′CBCR conversion supported by the implementation. -
A new property
blockTexelViewCompatibleMultipleLayers
indicating whetherVK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT
is allowed to be used withlayerCount
> 1 -
pNext
extensible *2 versions of all descriptor binding commands.
New Commands
If VK_KHR_push_descriptor is supported:
New Structures
-
Extending VkBindBufferMemoryInfo, VkBindImageMemoryInfo:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
If VK_KHR_push_descriptor is supported:
New Enum Constants
-
VK_KHR_MAINTENANCE_6_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_6_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_SETS_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_MEMORY_STATUS_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PUSH_CONSTANTS_INFO_KHR
-
If VK_KHR_push_descriptor is supported:
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_INFO_KHR
-
VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_WITH_TEMPLATE_INFO_KHR
-
VK_KHR_map_memory2
- Name String
-
VK_KHR_map_memory2
- Extension Type
-
Device extension
- Registered Extension Number
-
272
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Faith Ekstrand gfxstrand
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-03-14
- Interactions and External Dependencies
-
-
None
-
- Contributors
-
-
Faith Ekstrand, Collabora
-
Tobias Hector, AMD
-
Description
This extension provides extensible versions of the Vulkan memory map and unmap entry points. The new entry points are functionally identical to the core entry points, except that their parameters are specified using extensible structures that can be used to pass extension-specific information.
New Enum Constants
-
VK_KHR_MAP_MEMORY_2_EXTENSION_NAME
-
VK_KHR_MAP_MEMORY_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_MEMORY_MAP_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_UNMAP_INFO_KHR
-
VK_KHR_performance_query
- Name String
-
VK_KHR_performance_query
- Extension Type
-
Device extension
- Registered Extension Number
-
117
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Special Use
- Contact
-
-
Alon Or-bach alonorbach
-
Other Extension Metadata
- Last Modified Date
-
2019-10-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Barker, Unity Technologies
-
Kenneth Benzie, Codeplay
-
Jan-Harald Fredriksen, ARM
-
Jeff Leger, Qualcomm
-
Jesse Hall, Google
-
Tobias Hector, AMD
-
Neil Henning, Codeplay
-
Baldur Karlsson
-
Lionel Landwerlin, Intel
-
Peter Lohrmann, AMD
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Niklas Smedberg, Unity Technologies
-
Igor Ostrowski, Intel
-
Description
The VK_KHR_performance_query
extension adds a mechanism to allow querying
of performance counters for use in applications and by profiling tools.
Each queue family may expose counters that can be enabled on a queue of that family. We extend VkQueryType to add a new query type for performance queries, and chain a structure on VkQueryPoolCreateInfo to specify the performance queries to enable.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkQueryPoolCreateInfo:
-
Extending VkSubmitInfo, VkSubmitInfo2:
New Enum Constants
-
VK_KHR_PERFORMANCE_QUERY_EXTENSION_NAME
-
VK_KHR_PERFORMANCE_QUERY_SPEC_VERSION
-
Extending VkQueryType:
-
VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR
-
VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_DESCRIPTION_KHR
-
VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_KHR
-
VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR
-
Issues
1) Should this extension include a mechanism to begin a query in command buffer A and end the query in command buffer B?
RESOLVED No - queries are tied to command buffer creation and thus have to be encapsulated within a single command buffer.
2) Should this extension include a mechanism to begin and end queries globally on the queue, not using the existing command buffer commands?
RESOLVED No - for the same reasoning as the resolution of 1).
3) Should this extension expose counters that require multiple passes?
RESOLVED Yes - users should re-submit a command buffer with the same commands in it multiple times, specifying the pass to count as the query parameter in VkPerformanceQuerySubmitInfoKHR.
4) How to handle counters across parallel workloads?
RESOLVED In the spirit of Vulkan, a counter description flag
VK_PERFORMANCE_COUNTER_DESCRIPTION_CONCURRENTLY_IMPACTED_BIT_KHR
denotes that the accuracy of a counter result is affected by parallel
workloads.
5) How to handle secondary command buffers?
RESOLVED Secondary command buffers inherit any counter pass index specified in the parent primary command buffer. Note: this is no longer an issue after change from issue 10 resolution
6) What commands does the profiling lock have to be held for?
RESOLVED For any command buffer that is being queried with a performance query pool, the profiling lock must be held while that command buffer is in the recording, executable, or pending state.
7) Should we support vkCmdCopyQueryPoolResults?
RESOLVED Yes.
8) Should we allow performance queries to interact with multiview?
RESOLVED Yes, but the performance queries must be performed once for each pass per view.
9) Should a queryCount > 1
be usable for performance queries?
RESOLVED Yes.
Some vendors will have costly performance counter query pool creation, and
would rather if a certain set of counters were to be used multiple times
that a queryCount > 1
can be used to amortize the instantiation cost.
10) Should we introduce an indirect mechanism to set the counter pass index?
RESOLVED Specify the counter pass index at submit time instead, to avoid requiring re-recording of command buffers when multiple counter passes are needed.
Examples
The following example shows how to find what performance counters a queue family supports, setup a query pool to record these performance counters, how to add the query pool to the command buffer to record information, and how to get the results from the query pool.
// A previously created physical device
VkPhysicalDevice physicalDevice;
// One of the queue families our device supports
uint32_t queueFamilyIndex;
uint32_t counterCount;
// Get the count of counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
physicalDevice,
queueFamilyIndex,
&counterCount,
NULL,
NULL);
VkPerformanceCounterKHR* counters =
malloc(sizeof(VkPerformanceCounterKHR) * counterCount);
VkPerformanceCounterDescriptionKHR* counterDescriptions =
malloc(sizeof(VkPerformanceCounterDescriptionKHR) * counterCount);
// Get the counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
physicalDevice,
queueFamilyIndex,
&counterCount,
counters,
counterDescriptions);
// Try to enable the first 8 counters
uint32_t enabledCounters[8];
const uint32_t enabledCounterCount = min(counterCount, 8));
for (uint32_t i = 0; i < enabledCounterCount; i++) {
enabledCounters[i] = i;
}
// A previously created device that had the performanceCounterQueryPools feature
// set to VK_TRUE
VkDevice device;
VkQueryPoolPerformanceCreateInfoKHR performanceQueryCreateInfo = {
.sType = VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR,
.pNext = NULL,
// Specify the queue family that this performance query is performed on
.queueFamilyIndex = queueFamilyIndex,
// The number of counters to enable
.counterIndexCount = enabledCounterCount,
// The array of indices of counters to enable
.pCounterIndices = enabledCounters
};
// Get the number of passes our counters will require.
uint32_t numPasses;
vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR(
physicalDevice,
&performanceQueryCreateInfo,
&numPasses);
VkQueryPoolCreateInfo queryPoolCreateInfo = {
.sType = VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
.pNext = &performanceQueryCreateInfo,
.flags = 0,
// Using our new query type here
.queryType = VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR,
.queryCount = 1,
.pipelineStatistics = 0
};
VkQueryPool queryPool;
VkResult result = vkCreateQueryPool(
device,
&queryPoolCreateInfo,
NULL,
&queryPool);
assert(VK_SUCCESS == result);
// A queue from queueFamilyIndex
VkQueue queue;
// A command buffer we want to record counters on
VkCommandBuffer commandBuffer;
VkCommandBufferBeginInfo commandBufferBeginInfo = {
.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
.pNext = NULL,
.flags = 0,
.pInheritanceInfo = NULL
};
VkAcquireProfilingLockInfoKHR lockInfo = {
.sType = VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR,
.pNext = NULL,
.flags = 0,
.timeout = UINT64_MAX // Wait forever for the lock
};
// Acquire the profiling lock before we record command buffers
// that will use performance queries
result = vkAcquireProfilingLockKHR(device, &lockInfo);
assert(VK_SUCCESS == result);
result = vkBeginCommandBuffer(commandBuffer, &commandBufferBeginInfo);
assert(VK_SUCCESS == result);
vkCmdResetQueryPool(
commandBuffer,
queryPool,
0,
1);
vkCmdBeginQuery(
commandBuffer,
queryPool,
0,
0);
// Perform the commands you want to get performance information on
// ...
// Perform a barrier to ensure all previous commands were complete before
// ending the query
vkCmdPipelineBarrier(commandBuffer,
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
0,
0,
NULL,
0,
NULL,
0,
NULL);
vkCmdEndQuery(
commandBuffer,
queryPool,
0);
result = vkEndCommandBuffer(commandBuffer);
assert(VK_SUCCESS == result);
for (uint32_t counterPass = 0; counterPass < numPasses; counterPass++) {
VkPerformanceQuerySubmitInfoKHR performanceQuerySubmitInfo = {
VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR,
NULL,
counterPass
};
// Submit the command buffer and wait for its completion
// ...
}
// Release the profiling lock after the command buffer is no longer in the
// pending state.
vkReleaseProfilingLockKHR(device);
result = vkResetCommandBuffer(commandBuffer, 0);
assert(VK_SUCCESS == result);
// Create an array to hold the results of all counters
VkPerformanceCounterResultKHR* recordedCounters = malloc(
sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount);
result = vkGetQueryPoolResults(
device,
queryPool,
0,
1,
sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
recordedCounters,
sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
NULL);
// recordedCounters is filled with our counters, we will look at one for posterity
switch (counters[0].storage) {
case VK_PERFORMANCE_COUNTER_STORAGE_INT32:
// use recordCounters[0].int32 to get at the counter result!
break;
case VK_PERFORMANCE_COUNTER_STORAGE_INT64:
// use recordCounters[0].int64 to get at the counter result!
break;
case VK_PERFORMANCE_COUNTER_STORAGE_UINT32:
// use recordCounters[0].uint32 to get at the counter result!
break;
case VK_PERFORMANCE_COUNTER_STORAGE_UINT64:
// use recordCounters[0].uint64 to get at the counter result!
break;
case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT32:
// use recordCounters[0].float32 to get at the counter result!
break;
case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT64:
// use recordCounters[0].float64 to get at the counter result!
break;
}
VK_KHR_pipeline_executable_properties
- Name String
-
VK_KHR_pipeline_executable_properties
- Extension Type
-
Device extension
- Registered Extension Number
-
270
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Special Use
- Contact
-
-
Faith Ekstrand gfxstrand
-
Other Extension Metadata
- Last Modified Date
-
2019-05-28
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
- Contributors
-
-
Faith Ekstrand, Intel
-
Ian Romanick, Intel
-
Kenneth Graunke, Intel
-
Baldur Karlsson, Valve
-
Jesse Hall, Google
-
Jeff Bolz, Nvidia
-
Piers Daniel, Nvidia
-
Tobias Hector, AMD
-
Jan-Harald Fredriksen, ARM
-
Tom Olson, ARM
-
Daniel Koch, Nvidia
-
Spencer Fricke, Samsung
-
Description
When a pipeline is created, its state and shaders are compiled into zero or more device-specific executables, which are used when executing commands against that pipeline. This extension adds a mechanism to query properties and statistics about the different executables produced by the pipeline compilation process. This is intended to be used by debugging and performance tools to allow them to provide more detailed information to the user. Certain compile time shader statistics provided through this extension may be useful to developers for debugging or performance analysis.
New Enum Constants
-
VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_EXTENSION_NAME
-
VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_SPEC_VERSION
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR
-
VK_PIPELINE_CREATE_CAPTURE_STATISTICS_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_EXECUTABLE_PROPERTIES_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INFO_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INTERNAL_REPRESENTATION_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_STATISTIC_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_INFO_KHR
-
Issues
1) What should we call the pieces of the pipeline which are produced by the compilation process and about which you can query properties and statistics?
RESOLVED: Call them “executables”. The name “binary” was used in early drafts of the extension but it was determined that “pipeline binary” could have a fairly broad meaning (such as a binary serialized form of an entire pipeline) and was too big of a namespace for the very specific needs of this extension.
VK_KHR_pipeline_library
- Name String
-
VK_KHR_pipeline_library
- Extension Type
-
Device extension
- Registered Extension Number
-
291
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Christoph Kubisch pixeljetstream
-
Other Extension Metadata
- Last Modified Date
-
2020-01-08
- IP Status
-
No known IP claims.
- Contributors
-
-
See contributors to
VK_KHR_ray_tracing_pipeline
-
Description
A pipeline library is a special pipeline that cannot be bound, instead it defines a set of shaders and shader groups which can be linked into other pipelines. This extension defines the infrastructure for pipeline libraries, but does not specify the creation or usage of pipeline libraries. This is left to additional dependent extensions.
New Enum Constants
-
VK_KHR_PIPELINE_LIBRARY_EXTENSION_NAME
-
VK_KHR_PIPELINE_LIBRARY_SPEC_VERSION
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_LIBRARY_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PIPELINE_LIBRARY_CREATE_INFO_KHR
-
VK_KHR_portability_enumeration
- Name String
-
VK_KHR_portability_enumeration
- Extension Type
-
Instance extension
- Registered Extension Number
-
395
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Charles Giessen charles-lunarg
-
Other Extension Metadata
- Last Modified Date
-
2021-06-02
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_portability_subset
-
- Contributors
-
-
Lenny Komow, LunarG
-
Charles Giessen, LunarG
-
Description
This extension allows applications to control whether devices that expose
the VK_KHR_portability_subset
extension are included in the results
of physical device enumeration.
Since devices which support the VK_KHR_portability_subset
extension
are not fully conformant Vulkan implementations, the Vulkan loader does not
report those devices unless the application explicitly asks for them.
This prevents applications which may not be aware of non-conformant devices
from accidentally using them, as any device which supports the
VK_KHR_portability_subset
extension mandates that the extension
must be enabled if that device is used.
This extension is implemented in the loader.
New Enum Constants
-
VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME
-
VK_KHR_PORTABILITY_ENUMERATION_SPEC_VERSION
-
Extending VkInstanceCreateFlagBits:
-
VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR
-
VK_KHR_present_id
- Name String
-
VK_KHR_present_id
- Extension Type
-
Device extension
- Registered Extension Number
-
295
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Keith Packard keithp
-
Other Extension Metadata
- Last Modified Date
-
2019-05-15
- IP Status
-
No known IP claims.
- Contributors
-
-
Keith Packard, Valve
-
Ian Elliott, Google
-
Alon Or-bach, Samsung
-
Description
This device extension allows an application that uses the
VK_KHR_swapchain
extension to provide an identifier for present
operations on a swapchain.
An application can use this to reference specific present operations in
other extensions.
New Enum Constants
-
VK_KHR_PRESENT_ID_EXTENSION_NAME
-
VK_KHR_PRESENT_ID_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_ID_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PRESENT_ID_KHR
-
VK_KHR_present_wait
- Name String
-
VK_KHR_present_wait
- Extension Type
-
Device extension
- Registered Extension Number
-
249
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Keith Packard keithp
-
Other Extension Metadata
- Last Modified Date
-
2019-05-15
- IP Status
-
No known IP claims.
- Contributors
-
-
Keith Packard, Valve
-
Ian Elliott, Google
-
Tobias Hector, AMD
-
Daniel Stone, Collabora
-
Description
This device extension allows an application that uses the
VK_KHR_swapchain
extension to wait for present operations to
complete.
An application can use this to monitor and control the pacing of the
application by managing the number of outstanding images yet to be
presented.
New Enum Constants
-
VK_KHR_PRESENT_WAIT_EXTENSION_NAME
-
VK_KHR_PRESENT_WAIT_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_FEATURES_KHR
-
Issues
1) When does the wait finish?
RESOLVED. The wait will finish when the present is visible to the user. There is no requirement for any precise timing relationship between the presentation of the image to the user, but implementations should signal the wait as close as possible to the presentation of the first pixel in the new image to the user.
2) Should this use fences or other existing synchronization mechanism.
RESOLVED. Because display and rendering are often implemented in separate drivers, this extension will provide a separate synchronization API.
3) Should this extension share present identification with other extensions?
RESOLVED. Yes. A new extension, VK_KHR_present_id, should be created to provide a shared structure for presentation identifiers.
4) What happens when presentations complete out of order wrt calls to vkQueuePresent? This could happen if the semaphores for the presentations were ready out of order.
OPTION A: Require that when a PresentId is set that the driver ensure that images are always presented in the order of calls to vkQueuePresent.
OPTION B: Finish both waits when the earliest present completes. This will complete the later present wait earlier than the actual presentation. This should be the easiest to implement as the driver need only track the largest present ID completed. This is also the 'natural' consequence of interpreting the existing vkWaitForPresentKHR specificationn.
OPTION C: Finish both waits when both have completed. This will complete the earlier presentation later than the actual presentation time. This is allowed by the current specification as there is no precise timing requirement for when the presentId value is updated. This requires slightly more complexity in the driver as it will need to track all outstanding presentId values.
VK_KHR_push_descriptor
- Name String
-
VK_KHR_push_descriptor
- Extension Type
-
Device extension
- Registered Extension Number
-
81
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_1
-
Interacts with VK_KHR_descriptor_update_template
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2017-09-12
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Michael Worcester, Imagination Technologies
-
Description
This extension allows descriptors to be written into the command buffer, while the implementation is responsible for managing their memory. Push descriptors may enable easier porting from older APIs and in some cases can be more efficient than writing descriptors into descriptor sets.
New Enum Constants
-
VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME
-
VK_KHR_PUSH_DESCRIPTOR_SPEC_VERSION
-
Extending VkDescriptorSetLayoutCreateFlagBits:
-
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES_KHR
-
If VK_KHR_descriptor_update_template is supported:
-
Extending VkDescriptorUpdateTemplateType:
-
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
-
If Version 1.1 is supported:
-
Extending VkDescriptorUpdateTemplateType:
-
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
-
VK_KHR_ray_query
- Name String
-
VK_KHR_ray_query
- Extension Type
-
Device extension
- Registered Extension Number
-
349
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Daniel Koch dgkoch
-
Other Extension Metadata
- Last Modified Date
-
2020-11-12
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_ray_query
-
- Contributors
-
-
Matthäus Chajdas, AMD
-
Greg Grebe, AMD
-
Nicolai Hähnle, AMD
-
Tobias Hector, AMD
-
Dave Oldcorn, AMD
-
Skyler Saleh, AMD
-
Mathieu Robart, Arm
-
Marius Bjorge, Arm
-
Tom Olson, Arm
-
Sebastian Tafuri, EA
-
Henrik Rydgard, Embark
-
Juan Cañada, Epic Games
-
Patrick Kelly, Epic Games
-
Yuriy O’Donnell, Epic Games
-
Michael Doggett, Facebook/Oculus
-
Andrew Garrard, Imagination
-
Don Scorgie, Imagination
-
Dae Kim, Imagination
-
Joshua Barczak, Intel
-
Slawek Grajewski, Intel
-
Jeff Bolz, NVIDIA
-
Pascal Gautron, NVIDIA
-
Daniel Koch, NVIDIA
-
Christoph Kubisch, NVIDIA
-
Ashwin Lele, NVIDIA
-
Robert Stepinski, NVIDIA
-
Martin Stich, NVIDIA
-
Nuno Subtil, NVIDIA
-
Eric Werness, NVIDIA
-
Jon Leech, Khronos
-
Jeroen van Schijndel, OTOY
-
Juul Joosten, OTOY
-
Alex Bourd, Qualcomm
-
Roman Larionov, Qualcomm
-
David McAllister, Qualcomm
-
Spencer Fricke, Samsung
-
Lewis Gordon, Samsung
-
Ralph Potter, Samsung
-
Jasper Bekkers, Traverse Research
-
Jesse Barker, Unity
-
Baldur Karlsson, Valve
-
Description
Rasterization has been the dominant method to produce interactive graphics, but increasing performance of graphics hardware has made ray tracing a viable option for interactive rendering. Being able to integrate ray tracing with traditional rasterization makes it easier for applications to incrementally add ray traced effects to existing applications or to do hybrid approaches with rasterization for primary visibility and ray tracing for secondary queries.
Ray queries are available to all shader types, including graphics, compute and ray tracing pipelines. Ray queries are not able to launch additional shaders, instead returning traversal results to the calling shader.
This extension adds support for the following SPIR-V extension in Vulkan:
-
SPV_KHR_ray_query
New Enum Constants
-
VK_KHR_RAY_QUERY_EXTENSION_NAME
-
VK_KHR_RAY_QUERY_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_QUERY_FEATURES_KHR
-
Sample Code
Example of ray query in a GLSL shader, illustrating how to use ray queries to determine whether a given position (at ray origin) is in shadow or not, by tracing a ray towards the light, and checking for any intersections with geometry occluding the light.
rayQueryEXT rq;
rayQueryInitializeEXT(rq, accStruct, gl_RayFlagsTerminateOnFirstHitEXT, cullMask, origin, tMin, direction, tMax);
// Traverse the acceleration structure and store information about the first intersection (if any)
rayQueryProceedEXT(rq);
if (rayQueryGetIntersectionTypeEXT(rq, true) == gl_RayQueryCommittedIntersectionNoneEXT) {
// Not in shadow
}
Issues
(1) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the final (VK_KHR_acceleration_structure v11 / VK_KHR_ray_query v1) release?
-
refactor VK_KHR_ray_tracing into 3 extensions, enabling implementation flexibility and decoupling ray query support from ray pipelines:
-
VK_KHR_acceleration_structure
(for acceleration structure operations) -
VK_KHR_ray_tracing_pipeline
(for ray tracing pipeline and shader stages) -
VK_KHR_ray_query
(for ray queries in existing shader stages)
-
-
Update SPIRV capabilities to use
RayQueryKHR
-
extension is no longer provisional
Version History
-
Revision 1, 2020-11-12 (Mathieu Robart, Daniel Koch, Andrew Garrard)
-
Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_ray_query (#1918,!3912)
-
update to use
RayQueryKHR
SPIR-V capability -
add numerical limits for ray parameters (#2235,!3960)
-
relax formula for ray intersection candidate determination (#2322,!4080)
-
restrict traces to TLAS (#2239,!4141)
-
require
HitT
to be in ray interval forOpRayQueryGenerateIntersectionKHR
(#2359,!4146) -
add ray query shader stages for AS read bit (#2407,!4203)
-
VK_KHR_ray_tracing_maintenance1
- Name String
-
VK_KHR_ray_tracing_maintenance1
- Extension Type
-
Device extension
- Registered Extension Number
-
387
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_KHR_ray_tracing_pipeline
-
Interacts with VK_KHR_synchronization2
-
- SPIR-V Dependencies
- Contact
-
-
Daniel Koch dgkoch
-
Other Extension Metadata
- Last Modified Date
-
2022-02-21
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_ray_cull_mask
-
Interacts with
VK_KHR_ray_tracing_pipeline
-
Interacts with
VK_KHR_synchronization2
-
- Contributors
-
-
Stu Smith, AMD
-
Tobias Hector, AMD
-
Marius Bjorge, Arm
-
Tom Olson, Arm
-
Yuriy O’Donnell, Epic Games
-
Yunpeng Zhu, Huawei
-
Andrew Garrard, Imagination
-
Dae Kim, Imagination
-
Joshua Barczak, Intel
-
Lionel Landwerlin, Intel
-
Daniel Koch, NVIDIA
-
Eric Werness, NVIDIA
-
Spencer Fricke, Samsung
-
Description
VK_KHR_ray_tracing_maintenance1
adds a collection of minor ray tracing
features, none of which would warrant an entire extension of their own.
The new features are as follows:
-
Adds support for the
SPV_KHR_ray_cull_mask
SPIR-V extension in Vulkan. This extension provides access to built-inCullMaskKHR
shader variable which contains the value of theOpTrace*
Cull Mask
parameter. This new shader variable is accessible in the intersection, any-hit, closest-hit and miss shader stages. -
Adds support for a new pipeline stage and access mask built on top of
VK_KHR_synchronization2
:-
VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR
to specify execution of acceleration structure copy commands -
VK_ACCESS_2_SHADER_BINDING_TABLE_READ_BIT_KHR
to specify read access to a shader binding table in any shader pipeline stage
-
-
Adds two new acceleration structure query parameters:
-
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR
to query the acceleration structure size on the device timeline -
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR
to query the number of bottom level acceleration structure pointers for serialization
-
-
Adds an optional new indirect ray tracing dispatch command, vkCmdTraceRaysIndirect2KHR, which sources the shader binding table parameters as well as the dispatch dimensions from the device. The
rayTracingPipelineTraceRaysIndirect2
feature indicates whether this functionality is supported.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
If VK_KHR_ray_tracing_pipeline is supported:
New Enum Constants
-
VK_KHR_RAY_TRACING_MAINTENANCE_1_EXTENSION_NAME
-
VK_KHR_RAY_TRACING_MAINTENANCE_1_SPEC_VERSION
-
Extending VkQueryType:
-
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR
-
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MAINTENANCE_1_FEATURES_KHR
-
If VK_KHR_synchronization2 or Version 1.3 is supported:
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR
-
VK_KHR_ray_tracing_pipeline
- Name String
-
VK_KHR_ray_tracing_pipeline
- Extension Type
-
Device extension
- Registered Extension Number
-
348
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Daniel Koch dgkoch
-
Other Extension Metadata
- Last Modified Date
-
2020-11-12
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_ray_tracing
-
This extension interacts with Vulkan 1.2 and
VK_KHR_vulkan_memory_model
, adding the shader-call-related relation of invocations, shader-call-order partial order of dynamic instances of instructions, and theShaderCallKHR
scope. -
This extension interacts with
VK_KHR_pipeline_library
, enabling pipeline libraries to be used with ray tracing pipelines and enabling usage of VkRayTracingPipelineInterfaceCreateInfoKHR.
-
- Contributors
-
-
Matthäus Chajdas, AMD
-
Greg Grebe, AMD
-
Nicolai Hähnle, AMD
-
Tobias Hector, AMD
-
Dave Oldcorn, AMD
-
Skyler Saleh, AMD
-
Mathieu Robart, Arm
-
Marius Bjorge, Arm
-
Tom Olson, Arm
-
Sebastian Tafuri, EA
-
Henrik Rydgard, Embark
-
Juan Cañada, Epic Games
-
Patrick Kelly, Epic Games
-
Yuriy O’Donnell, Epic Games
-
Michael Doggett, Facebook/Oculus
-
Andrew Garrard, Imagination
-
Don Scorgie, Imagination
-
Dae Kim, Imagination
-
Joshua Barczak, Intel
-
Slawek Grajewski, Intel
-
Jeff Bolz, NVIDIA
-
Pascal Gautron, NVIDIA
-
Daniel Koch, NVIDIA
-
Christoph Kubisch, NVIDIA
-
Ashwin Lele, NVIDIA
-
Robert Stepinski, NVIDIA
-
Martin Stich, NVIDIA
-
Nuno Subtil, NVIDIA
-
Eric Werness, NVIDIA
-
Jon Leech, Khronos
-
Jeroen van Schijndel, OTOY
-
Juul Joosten, OTOY
-
Alex Bourd, Qualcomm
-
Roman Larionov, Qualcomm
-
David McAllister, Qualcomm
-
Spencer Fricke, Samsung
-
Lewis Gordon, Samsung
-
Ralph Potter, Samsung
-
Jasper Bekkers, Traverse Research
-
Jesse Barker, Unity
-
Baldur Karlsson, Valve
-
Description
Rasterization has been the dominant method to produce interactive graphics, but increasing performance of graphics hardware has made ray tracing a viable option for interactive rendering. Being able to integrate ray tracing with traditional rasterization makes it easier for applications to incrementally add ray traced effects to existing applications or to do hybrid approaches with rasterization for primary visibility and ray tracing for secondary queries.
To enable ray tracing, this extension adds a few different categories of new functionality:
-
A new ray tracing pipeline type with new shader domains: ray generation, intersection, any-hit, closest hit, miss, and callable
-
A shader binding indirection table to link shader groups with acceleration structure items
-
Ray tracing commands which initiate the ray pipeline traversal and invocation of the various new shader domains depending on which traversal conditions are met
This extension adds support for the following SPIR-V extension in Vulkan:
-
SPV_KHR_ray_tracing
New Enum Constants
-
VK_KHR_RAY_TRACING_PIPELINE_EXTENSION_NAME
-
VK_KHR_RAY_TRACING_PIPELINE_SPEC_VERSION
-
VK_SHADER_UNUSED_KHR
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR
-
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR
-
-
Extending VkPipelineBindPoint:
-
VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR
-
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR
-
VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR
-
-
Extending VkPipelineStageFlagBits:
-
VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR
-
-
Extending VkShaderStageFlagBits:
-
VK_SHADER_STAGE_ANY_HIT_BIT_KHR
-
VK_SHADER_STAGE_CALLABLE_BIT_KHR
-
VK_SHADER_STAGE_CLOSEST_HIT_BIT_KHR
-
VK_SHADER_STAGE_INTERSECTION_BIT_KHR
-
VK_SHADER_STAGE_MISS_BIT_KHR
-
VK_SHADER_STAGE_RAYGEN_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_INTERFACE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_KHR
-
Issues
(1) How does this extension differ from VK_NV_ray_tracing?
DISCUSSION:
The following is a summary of the main functional differences between VK_KHR_ray_tracing_pipeline and VK_NV_ray_tracing:
-
added support for indirect ray tracing (vkCmdTraceRaysIndirectKHR)
-
uses SPV_KHR_ray_tracing instead of SPV_NV_ray_tracing
-
refer to KHR SPIR-V enums instead of NV SPIR-V enums (which are functionally equivalent and aliased to the same values).
-
added
RayGeometryIndexKHR
built-in
-
-
removed vkCompileDeferredNV compilation functionality and replaced with deferred host operations interactions for ray tracing
-
added VkPhysicalDeviceRayTracingPipelineFeaturesKHR structure
-
extended VkPhysicalDeviceRayTracingPipelinePropertiesKHR structure
-
renamed
maxRecursionDepth
tomaxRayRecursionDepth
and it has a minimum of 1 instead of 31 -
require
shaderGroupHandleSize
to be 32 bytes -
added
maxRayDispatchInvocationCount
,shaderGroupHandleAlignment
andmaxRayHitAttributeSize
-
-
reworked geometry structures so they could be better shared between device, host, and indirect builds
-
changed SBT parameters to a structure and added size (VkStridedDeviceAddressRegionKHR)
-
add parameter for requesting memory requirements for host and/or device build
-
added pipeline library support for ray tracing
-
added no-null-shader pipeline flags (
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_*_SHADERS_BIT_KHR
) -
added memory model interactions with ray tracing and define how subgroups work and can be repacked
(3) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the internal provisional (VK_KHR_ray_tracing v9) release?
-
Require Vulkan 1.1 and SPIR-V 1.4
-
Added interactions with Vulkan 1.2 and
VK_KHR_vulkan_memory_model
-
added creation time capture and replay flags
-
added
VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR
to VkPipelineCreateFlagBits
-
-
replace
VkStridedBufferRegionKHR
with VkStridedDeviceAddressRegionKHR and change vkCmdTraceRaysKHR, vkCmdTraceRaysIndirectKHR, to take these for the shader binding table and use device addresses instead of buffers. -
require the shader binding table buffers to have the
VK_BUFFER_USAGE_RAY_TRACING_BIT_KHR
set -
make
VK_KHR_pipeline_library
an interaction instead of required extension -
rename the
libraries
member of VkRayTracingPipelineCreateInfoKHR topLibraryInfo
and make it a pointer -
make
VK_KHR_deferred_host_operations
an interaction instead of a required extension (later went back on this) -
added explicit stack size management for ray tracing pipelines
-
removed the
maxCallableSize
member of VkRayTracingPipelineInterfaceCreateInfoKHR -
added the
pDynamicState
member to VkRayTracingPipelineCreateInfoKHR -
added
VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR
dynamic state for ray tracing pipelines -
added vkGetRayTracingShaderGroupStackSizeKHR and vkCmdSetRayTracingPipelineStackSizeKHR commands
-
added VkShaderGroupShaderKHR enum
-
-
Added
maxRayDispatchInvocationCount
limit to VkPhysicalDeviceRayTracingPipelinePropertiesKHR -
Added
shaderGroupHandleAlignment
property to VkPhysicalDeviceRayTracingPipelinePropertiesKHR -
Added
maxRayHitAttributeSize
property to VkPhysicalDeviceRayTracingPipelinePropertiesKHR -
Clarify deferred host ops for pipeline creation
-
VkDeferredOperationKHR is now a top-level parameter for vkCreateRayTracingPipelinesKHR
-
removed
VkDeferredOperationInfoKHR
structure -
change deferred host creation/return parameter behavior such that the implementation can modify such parameters until the deferred host operation completes
-
VK_KHR_deferred_host_operations
is required again
-
(4) What are the changes between the internal provisional (VK_KHR_ray_tracing v9) release and the final (VK_KHR_acceleration_structure v11 / VK_KHR_ray_tracing_pipeline v1) release?
-
refactor VK_KHR_ray_tracing into 3 extensions, enabling implementation flexibility and decoupling ray query support from ray pipelines:
-
VK_KHR_acceleration_structure
(for acceleration structure operations) -
VK_KHR_ray_tracing_pipeline
(for ray tracing pipeline and shader stages) -
VK_KHR_ray_query
(for ray queries in existing shader stages)
-
-
Require
Volatile
for the following builtins in the ray generation, closest hit, miss, intersection, and callable shader stages:-
SubgroupSize
,SubgroupLocalInvocationId
,SubgroupEqMask
,SubgroupGeMask
,SubgroupGtMask
,SubgroupLeMask
,SubgroupLtMask
-
SMIDNV
,WarpIDNV
-
-
clarify buffer usage flags for ray tracing
-
VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR
is added as an alias ofVK_BUFFER_USAGE_RAY_TRACING_BIT_NV
and is required on shader binding table buffers -
VK_BUFFER_USAGE_STORAGE_BUFFER_BIT
is used inVK_KHR_acceleration_structure
forscratchData
-
-
rename
maxRecursionDepth
tomaxRayPipelineRecursionDepth
(pipeline creation) andmaxRayRecursionDepth
(limit) to reduce confusion -
Add queryable
maxRayHitAttributeSize
limit and rename members of VkRayTracingPipelineInterfaceCreateInfoKHR tomaxPipelineRayPayloadSize
andmaxPipelineRayHitAttributeSize
for clarity -
Update SPIRV capabilities to use
RayTracingKHR
-
extension is no longer provisional
-
define synchronization requirements for indirect trace rays and indirect buffer
(5) This extension adds gl_InstanceID for the intersection, any-hit, and closest hit shaders, but in KHR_vulkan_glsl, gl_InstanceID is replaced with gl_InstanceIndex. Which should be used for Vulkan in this extension?
RESOLVED: This extension uses gl_InstanceID and maps it to InstanceId
in SPIR-V.
It is acknowledged that this is different than other shader stages in
Vulkan.
There are two main reasons for the difference here:
-
symmetry with gl_PrimitiveID which is also available in these shaders
-
there is no “baseInstance” relevant for these shaders, and so ID makes it more obvious that this is zero-based.
(6) Why is VK_KHR_pipeline_library
an interaction instead of a
required dependency, particularly when the “Feature Requirements” section
says it is required to be supported anyhow?
RESOLVED: If VK_KHR_pipeline_library
were a required extension
dependency, then every application would need to enable the extension
whether or not they actually want to use the pipeline library functionality.
Developers found this to be annoying and unfriendly behavior.
We do wish to require all implementations to support it though, and thus
it is listed in the feature requirements section.
Sample Code
Example ray generation GLSL shader
#version 450 core
#extension GL_EXT_ray_tracing : require
layout(set = 0, binding = 0, rgba8) uniform image2D image;
layout(set = 0, binding = 1) uniform accelerationStructureEXT as;
layout(location = 0) rayPayloadEXT float payload;
void main()
{
vec4 col = vec4(0, 0, 0, 1);
vec3 origin = vec3(float(gl_LaunchIDEXT.x)/float(gl_LaunchSizeEXT.x), float(gl_LaunchIDEXT.y)/float(gl_LaunchSizeEXT.y), 1.0);
vec3 dir = vec3(0.0, 0.0, -1.0);
traceRayEXT(as, 0, 0xff, 0, 1, 0, origin, 0.0, dir, 1000.0, 0);
col.y = payload;
imageStore(image, ivec2(gl_LaunchIDEXT.xy), col);
}
Version History
-
Revision 1, 2020-11-12 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)
-
Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_ray_tracing_pipeline (#1918,!3912)
-
require certain subgroup and sm_shader_builtin shader builtins to be decorated as volatile in the ray generation, closest hit, miss, intersection, and callable stages (#1924,!3903,!3954)
-
clarify buffer usage flags for ray tracing (#2181,!3939)
-
rename maxRecursionDepth to maxRayPipelineRecursionDepth and maxRayRecursionDepth (#2203,!3937)
-
add queryable maxRayHitAttributeSize and rename members of VkRayTracingPipelineInterfaceCreateInfoKHR (#2102,!3966)
-
update to use
RayTracingKHR
SPIR-V capability -
add VUs for matching hit group type against geometry type (#2245,!3994)
-
require
RayTMaxKHR
be volatile in intersection shaders (#2268,!4030) -
add numerical limits for ray parameters (#2235,!3960)
-
fix SBT indexing rules for device addresses (#2308,!4079)
-
relax formula for ray intersection candidate determination (#2322,!4080)
-
add more details on
ShaderRecordBufferKHR
variables (#2230,!4083) -
clarify valid bits for
InstanceCustomIndexKHR
(GLSL/GLSL#19,!4128) -
allow at most one
IncomingRayPayloadKHR
,IncomingCallableDataKHR
, andHitAttributeKHR
(!4129) -
add minimum for maxShaderGroupStride (#2353,!4131)
-
require VK_KHR_pipeline_library extension to be supported (#2348,!4135)
-
clarify meaning of 'geometry index' (#2272,!4137)
-
restrict traces to TLAS (#2239,!4141)
-
add note about maxPipelineRayPayloadSize (#2383,!4172)
-
do not require raygen shader in pipeline libraries (!4185)
-
define sync for indirect trace rays and indirect buffer (#2407,!4208)
-
VK_KHR_ray_tracing_position_fetch
- Name String
-
VK_KHR_ray_tracing_position_fetch
- Extension Type
-
Device extension
- Registered Extension Number
-
482
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Eric Werness
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-02-17
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_ray_tracing_position_fetch
-
Interacts with
VK_KHR_ray_tracing_pipeline
-
Interacts with
VK_KHR_ray_query
-
- Contributors
-
-
Eric Werness, NVIDIA
-
Stu Smith, AMD
-
Yuriy O’Donnell, Epic Games
-
Ralph Potter, Samsung
-
Joshua Barczak, Intel
-
Lionel Landwerlin, Intel
-
Andrew Garrard, Imagination Technologies
-
Alex Bourd, Qualcomm
-
Yunpeng Zhu, Huawei Technologies
-
Marius Bjorge, Arm
-
Daniel Koch, NVIDIA
-
Description
VK_KHR_ray_tracing_position_fetch
adds the ability to fetch the vertex
positions in the shader from a hit triangle as stored in the acceleration
structure.
An application adds
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR
to the
acceleration structure at build time.
Then, if the hit is a triangle geometry, the shader (any-hit or closest hit
for ray pipelines or using ray query) can fetch the three, three-component
vertex positions in object space, of the triangle which was hit.
New Enum Constants
-
VK_KHR_RAY_TRACING_POSITION_FETCH_EXTENSION_NAME
-
VK_KHR_RAY_TRACING_POSITION_FETCH_SPEC_VERSION
-
Extending VkBuildAccelerationStructureFlagBitsKHR:
-
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_POSITION_FETCH_FEATURES_KHR
-
VK_KHR_shader_clock
- Name String
-
VK_KHR_shader_clock
- Extension Type
-
Device extension
- Registered Extension Number
-
182
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Aaron Hagan ahagan
-
Other Extension Metadata
- Last Modified Date
-
2019-4-25
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_ARB_shader_clock
andGL_EXT_shader_realtime_clock
-
- Contributors
-
-
Aaron Hagan, AMD
-
Daniel Koch, NVIDIA
-
Description
This extension advertises the SPIR-V ShaderClockKHR
capability for
Vulkan, which allows a shader to query a real-time or monotonically
incrementing counter at the subgroup level or across the device level.
The two valid SPIR-V scopes for OpReadClockKHR
are Subgroup
and
Device
.
When using GLSL source-based shading languages, the clockRealtime*EXT
()
timing functions map to the OpReadClockKHR
instruction with a scope of
Device
, and the clock*ARB
() timing functions map to the
OpReadClockKHR
instruction with a scope of Subgroup
.
New Enum Constants
-
VK_KHR_SHADER_CLOCK_EXTENSION_NAME
-
VK_KHR_SHADER_CLOCK_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CLOCK_FEATURES_KHR
-
VK_KHR_shader_expect_assume
- Name String
-
VK_KHR_shader_expect_assume
- Extension Type
-
Device extension
- Registered Extension Number
-
545
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Kevin Petit kpet
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-06
- IP Status
-
No known IP claims.
- Contributors
-
-
Kevin Petit, Arm
-
Tobias Hector, AMD
-
James Fitzpatrick, Imagination Technologies
-
Description
This extension allows the use of the SPV_KHR_expect_assume
extension in
SPIR-V shader modules which enables SPIR-V producers to provide optimization
hints to the Vulkan implementation.
New Enum Constants
-
VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME
-
VK_KHR_SHADER_EXPECT_ASSUME_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EXPECT_ASSUME_FEATURES_KHR
-
VK_KHR_shader_float_controls2
- Name String
-
VK_KHR_shader_float_controls2
- Extension Type
-
Device extension
- Registered Extension Number
-
529
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Graeme Leese gnl21
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-05-16
- Interactions and External Dependencies
-
-
This extension requires
SPV_KHR_float_controls2
.
-
- Contributors
-
-
Graeme Leese, Broadcom
-
Description
This extension enables use of the more expressive fast floating-point math flags in the SPV_KHR_float_controls2 extension. These flags give finer- grained control over which optimizations compilers may apply, potentially speeding up execution while retaining correct results.
The extension also adds control over the fast-math modes to the GLSL extended instruction set, making these operations more consistent with SPIR-V and allowing their use in situations where floating-point conformance is important.
New Enum Constants
-
VK_KHR_SHADER_FLOAT_CONTROLS_2_EXTENSION_NAME
-
VK_KHR_SHADER_FLOAT_CONTROLS_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT_CONTROLS_2_FEATURES_KHR
-
VK_KHR_shader_maximal_reconvergence
- Name String
-
VK_KHR_shader_maximal_reconvergence
- Extension Type
-
Device extension
- Registered Extension Number
-
435
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Alan Baker alan-baker
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2021-11-12
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Requires SPIR-V 1.3.
-
This extension requires
SPV_KHR_maximal_reconvergence
-
- Contributors
-
-
Alan Baker, Google
-
Description
This extension allows the use of the SPV_KHR_maximal_reconvergence
SPIR-V
extension in shader modules.
SPV_KHR_maximal_reconvergence
provides stronger guarantees that diverged
subgroups will reconverge.
These guarantees should match shader author intuition about divergence and
reconvergence of invocations based on the structure of the code in the HLL.
Developers should utilize this extension if they require stronger guarantees about reconvergence than either the core spec or SPV_KHR_subgroup_uniform_control_flow. This extension will define the rules that govern how invocations diverge and reconverge in a way that should match developer intuition. It allows robust programs to be written relying on subgroup operations and other tangled instructions.
New Enum Constants
-
VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_EXTENSION_NAME
-
VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MAXIMAL_RECONVERGENCE_FEATURES_KHR
-
VK_KHR_shader_quad_control
- Name String
-
VK_KHR_shader_quad_control
- Extension Type
-
Device extension
- Registered Extension Number
-
236
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Tobias Hector tobski
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-11-01
- IP Status
-
No known IP claims.
- Contributors
-
-
Tobias Hector, AMD
-
Bill Licea-Kane, Qualcomm
-
Graeme Leese, Broadcom
-
Jan-Harald Fredriksen, Arm
-
Nicolai Hähnle, AMD
-
Jeff Bolz, NVidia
-
Alan Baker, Google
-
Hans-Kristian Arntzen, Valve
-
Description
This extension adds new quad any/all operations, requires that derivatives are well-defined in quad-uniform control flow, and adds the ability to require helper invocations participate in group operations.
New Enum Constants
-
VK_KHR_SHADER_QUAD_CONTROL_EXTENSION_NAME
-
VK_KHR_SHADER_QUAD_CONTROL_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_QUAD_CONTROL_FEATURES_KHR
-
VK_KHR_shader_subgroup_rotate
- Name String
-
VK_KHR_shader_subgroup_rotate
- Extension Type
-
Device extension
- Registered Extension Number
-
417
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- SPIR-V Dependencies
- Contact
-
-
Kevin Petit kpet
-
- Extension Proposal
- Last Modified Date
-
2024-01-29
- IP Status
-
No known IP claims.
- Contributors
-
-
Kévin Petit, Arm Ltd.
-
Tobias Hector, AMD
-
John Leech, Khronos
-
Matthew Netsch, Qualcomm
-
Jan-Harald Fredriksen, Arm Ltd.
-
Graeme Leese, Broadcom
-
Tom Olson, Arm Ltd.
-
Spencer Fricke, LunarG Inc.
-
This extension adds support for the subgroup rotate instruction defined in SPV_KHR_subgroup_rotate.
New Enum Constants
-
VK_KHR_SHADER_SUBGROUP_ROTATE_EXTENSION_NAME
-
VK_KHR_SHADER_SUBGROUP_ROTATE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_ROTATE_FEATURES_KHR
-
-
Extending VkSubgroupFeatureFlagBits:
-
VK_SUBGROUP_FEATURE_ROTATE_BIT_KHR
-
VK_SUBGROUP_FEATURE_ROTATE_CLUSTERED_BIT_KHR
-
VK_KHR_shader_subgroup_uniform_control_flow
- Name String
-
VK_KHR_shader_subgroup_uniform_control_flow
- Extension Type
-
Device extension
- Registered Extension Number
-
324
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Alan Baker alan-baker
-
Other Extension Metadata
- Last Modified Date
-
2020-08-27
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Requires SPIR-V 1.3.
-
This extension provides API support for
GL_EXT_subgroupuniform_qualifier
-
- Contributors
-
-
Alan Baker, Google
-
Jeff Bolz, NVIDIA
-
Description
This extension allows the use of the SPV_KHR_subgroup_uniform_control_flow
SPIR-V extension in shader modules.
SPV_KHR_subgroup_uniform_control_flow
provides stronger guarantees that
diverged subgroups will reconverge.
Developers should utilize this extension if they use subgroup operations to reduce the work performed by a uniform subgroup. This extension will guarantee that uniform subgroup will reconverge in the same manner as invocation groups (see “Uniform Control Flow” in the Khronos SPIR-V Specification).
New Enum Constants
-
VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_EXTENSION_NAME
-
VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR
-
VK_KHR_shared_presentable_image
- Name String
-
VK_KHR_shared_presentable_image
- Extension Type
-
Device extension
- Registered Extension Number
-
112
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Alon Or-bach alonorbach
-
Other Extension Metadata
- Last Modified Date
-
2017-03-20
- IP Status
-
No known IP claims.
- Contributors
-
-
Alon Or-bach, Samsung Electronics
-
Ian Elliott, Google
-
Jesse Hall, Google
-
Pablo Ceballos, Google
-
Chris Forbes, Google
-
Jeff Juliano, NVIDIA
-
James Jones, NVIDIA
-
Daniel Rakos, AMD
-
Tobias Hector, Imagination Technologies
-
Graham Connor, Imagination Technologies
-
Michael Worcester, Imagination Technologies
-
Cass Everitt, Oculus
-
Johannes Van Waveren, Oculus
-
Description
This extension extends VK_KHR_swapchain
to enable creation of a
shared presentable image.
This allows the application to use the image while the presention engine is
accessing it, in order to reduce the latency between rendering and
presentation.
New Enum Constants
-
VK_KHR_SHARED_PRESENTABLE_IMAGE_EXTENSION_NAME
-
VK_KHR_SHARED_PRESENTABLE_IMAGE_SPEC_VERSION
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR
-
-
Extending VkPresentModeKHR:
-
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
-
VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR
-
Issues
1) Should we allow a Vulkan WSI swapchain to toggle between normal usage and shared presentation usage?
RESOLVED: No. WSI swapchains are typically recreated with new properties instead of having their properties changed. This can also save resources, assuming that fewer images are needed for shared presentation, and assuming that most VR applications do not need to switch between normal and shared usage.
2) Should we have a query for determining how the presentation engine refresh is triggered?
RESOLVED: Yes. This is done via which presentation modes a surface supports.
3) Should the object representing a shared presentable image be an extension of a VkSwapchainKHR or a separate object?
RESOLVED: Extension of a swapchain due to overlap in creation properties and to allow common functionality between shared and normal presentable images and swapchains.
4) What should we call the extension and the new structures it creates?
RESOLVED: Shared presentable image / shared present.
5) Should the minImageCount
and presentMode
values of the
VkSwapchainCreateInfoKHR be ignored, or required to be compatible
values?
RESOLVED: minImageCount
must be set to 1, and presentMode
should be set to either VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR
or
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
.
6) What should the layout of the shared presentable image be?
RESOLVED: After acquiring the shared presentable image, the application
must transition it to the VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR
layout
prior to it being used.
After this initial transition, any image usage that was requested during
swapchain creation can be performed on the image without layout transitions
being performed.
7) Do we need a new API for the trigger to refresh new content?
RESOLVED: vkQueuePresentKHR to act as API to trigger a refresh, as will allow combination with other compatible extensions to vkQueuePresentKHR.
8) How should an application detect a VK_ERROR_OUT_OF_DATE_KHR
error
on a swapchain using the VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
present mode?
RESOLVED: Introduce vkGetSwapchainStatusKHR to allow applications to query the status of a swapchain using a shared presentation mode.
9) What should subsequent calls to vkQueuePresentKHR for
VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR
swapchains be defined to
do?
RESOLVED: State that implementations may use it as a hint for updated content.
10) Can the ownership of a shared presentable image be transferred to a different queue?
RESOLVED: No.
It is not possible to transfer ownership of a shared presentable image
obtained from a swapchain created using VK_SHARING_MODE_EXCLUSIVE
after it has been presented.
11) How should vkQueueSubmit behave if a command buffer uses an image
from a VK_ERROR_OUT_OF_DATE_KHR
swapchain?
RESOLVED: vkQueueSubmit is expected to return the
VK_ERROR_DEVICE_LOST
error.
12) Can Vulkan provide any guarantee on the order of rendering, to enable beam chasing?
RESOLVED: This could be achieved via use of render passes to ensure strip rendering.
VK_KHR_surface
- Name String
-
VK_KHR_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
1
- Revision
-
25
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
James Jones cubanismo
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2016-08-25
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Ian Elliott, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Faith Ekstrand, Intel
-
Description
The VK_KHR_surface
extension is an instance extension.
It introduces VkSurfaceKHR objects, which abstract native platform
surface or window objects for use with Vulkan.
It also provides a way to determine whether a queue family in a physical
device supports presenting to particular surface.
Separate extensions for each platform provide the mechanisms for creating
VkSurfaceKHR objects, but once created they may be used in this and
other platform-independent extensions, in particular the
VK_KHR_swapchain
extension.
New Enum Constants
-
VK_KHR_SURFACE_EXTENSION_NAME
-
VK_KHR_SURFACE_SPEC_VERSION
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_SURFACE_KHR
-
-
Extending VkResult:
-
VK_ERROR_NATIVE_WINDOW_IN_USE_KHR
-
VK_ERROR_SURFACE_LOST_KHR
-
Examples
Note
The example code for the |
Issues
1) Should this extension include a method to query whether a physical device supports presenting to a specific window or native surface on a given platform?
RESOLVED: Yes. Without this, applications would need to create a device instance to determine whether a particular window can be presented to. Knowing that a device supports presentation to a platform in general is not sufficient, as a single machine might support multiple seats, or instances of the platform that each use different underlying physical devices. Additionally, on some platforms, such as the X Window System, different drivers and devices might be used for different windows depending on which section of the desktop they exist on.
2) Should the vkGetPhysicalDeviceSurfaceCapabilitiesKHR,
vkGetPhysicalDeviceSurfaceFormatsKHR, and
vkGetPhysicalDeviceSurfacePresentModesKHR functions be in this
extension and operate on physical devices, rather than being in
VK_KHR_swapchain
(i.e. device extension) and being dependent on
VkDevice?
RESOLVED: Yes.
While it might be useful to depend on VkDevice
(and therefore on
enabled extensions and features) for the queries, Vulkan was released only
with the VkPhysicalDevice versions.
Many cases can be resolved by a Valid Usage statement, and/or by a separate
pNext
chain version of the query struct specific to a given extension
or parameters, via extensible versions of the queries:
vkGetPhysicalDeviceSurfaceCapabilities2KHR, and
vkGetPhysicalDeviceSurfaceFormats2KHR.
3) Should Vulkan support Xlib or XCB as the API for accessing the X Window System platform?
RESOLVED: Both. XCB is a more modern and efficient API, but Xlib usage is deeply ingrained in many applications and likely will remain in use for the foreseeable future. Not all drivers necessarily need to support both, but including both as options in the core specification will probably encourage support, which should in turn ease adoption of the Vulkan API in older codebases. Additionally, the performance improvements possible with XCB likely will not have a measurable impact on the performance of Vulkan presentation and other minimal window system interactions defined here.
4) Should the GBM platform be included in the list of platform enums?
RESOLVED: Deferred, and will be addressed with a platform-specific extension to be written in the future.
Version History
-
Revision 1, 2015-05-20 (James Jones)
-
Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.
-
-
Revision 2, 2015-05-22 (Ian Elliott)
-
Created initial Description section.
-
Removed query for whether a platform requires the use of a queue for presentation, since it was decided that presentation will always be modeled as being part of the queue.
-
Fixed typos and other minor mistakes.
-
-
Revision 3, 2015-05-26 (Ian Elliott)
-
Improved the Description section.
-
-
Revision 4, 2015-05-27 (James Jones)
-
Fixed compilation errors in example code.
-
-
Revision 5, 2015-06-01 (James Jones)
-
Added issues 1 and 2 and made related spec updates.
-
-
Revision 6, 2015-06-01 (James Jones)
-
Merged the platform type mappings table previously removed from VK_KHR_swapchain with the platform description table in this spec.
-
Added issues 3 and 4 documenting choices made when building the initial list of native platforms supported.
-
-
Revision 7, 2015-06-11 (Ian Elliott)
-
Updated table 1 per input from the KHR TSG.
-
Updated issue 4 (GBM) per discussion with Daniel Stone. He will create a platform-specific extension sometime in the future.
-
-
Revision 8, 2015-06-17 (James Jones)
-
Updated enum-extending values using new convention.
-
Fixed the value of VK_SURFACE_PLATFORM_INFO_TYPE_SUPPORTED_KHR.
-
-
Revision 9, 2015-06-17 (James Jones)
-
Rebased on Vulkan API version 126.
-
-
Revision 10, 2015-06-18 (James Jones)
-
Marked issues 2 and 3 resolved.
-
-
Revision 11, 2015-06-23 (Ian Elliott)
-
Examples now show use of function pointers for extension functions.
-
Eliminated extraneous whitespace.
-
-
Revision 12, 2015-07-07 (Daniel Rakos)
-
Added error section describing when each error is expected to be reported.
-
Replaced the term “queue node index” with “queue family index” in the spec as that is the agreed term to be used in the latest version of the core header and spec.
-
Replaced bool32_t with VkBool32.
-
-
Revision 13, 2015-08-06 (Daniel Rakos)
-
Updated spec against latest core API header version.
-
-
Revision 14, 2015-08-20 (Ian Elliott)
-
Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.
-
Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.
-
Did miscellaneous cleanup, etc.
-
-
Revision 15, 2015-08-20 (Ian Elliott—porting a 2015-07-29 change from James Jones)
-
Moved the surface transform enums here from VK_WSI_swapchain so they could be reused by VK_WSI_display.
-
-
Revision 16, 2015-09-01 (James Jones)
-
Restore single-field revision number.
-
-
Revision 17, 2015-09-01 (James Jones)
-
Fix example code compilation errors.
-
-
Revision 18, 2015-09-26 (Jesse Hall)
-
Replaced VkSurfaceDescriptionKHR with the VkSurfaceKHR object, which is created via layered extensions. Added VkDestroySurfaceKHR.
-
-
Revision 19, 2015-09-28 (Jesse Hall)
-
Renamed from VK_EXT_KHR_swapchain to VK_EXT_KHR_surface.
-
-
Revision 20, 2015-09-30 (Jeff Vigil)
-
Add error result VK_ERROR_SURFACE_LOST_KHR.
-
-
Revision 21, 2015-10-15 (Daniel Rakos)
-
Updated the resolution of issue #2 and include the surface capability queries in this extension.
-
Renamed SurfaceProperties to SurfaceCapabilities as it better reflects that the values returned are the capabilities of the surface on a particular device.
-
Other minor cleanup and consistency changes.
-
-
Revision 22, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_surface to VK_KHR_surface.
-
-
Revision 23, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to vkDestroySurfaceKHR.
-
-
Revision 24, 2015-11-10 (Jesse Hall)
-
Removed VkSurfaceTransformKHR. Use VkSurfaceTransformFlagBitsKHR instead.
-
Rename VkSurfaceCapabilitiesKHR member maxImageArraySize to maxImageArrayLayers.
-
-
Revision 25, 2016-01-14 (James Jones)
-
Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.
-
-
2016-08-23 (Ian Elliott)
-
Update the example code, to not have so many characters per line, and to split out a new example to show how to obtain function pointers.
-
-
2016-08-25 (Ian Elliott)
-
A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.
-
VK_KHR_surface_protected_capabilities
- Name String
-
VK_KHR_surface_protected_capabilities
- Extension Type
-
Instance extension
- Registered Extension Number
-
240
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Sandeep Shinde sashinde
-
Other Extension Metadata
- Last Modified Date
-
2018-12-18
- IP Status
-
No known IP claims.
- Contributors
-
-
Sandeep Shinde, NVIDIA
-
James Jones, NVIDIA
-
Daniel Koch, NVIDIA
-
Description
This extension extends VkSurfaceCapabilities2KHR, providing
applications a way to query whether swapchains can be created with the
VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR
flag set.
Vulkan 1.1 added (optional) support for protect memory and protected
resources including buffers (VK_BUFFER_CREATE_PROTECTED_BIT
), images
(VK_IMAGE_CREATE_PROTECTED_BIT
), and swapchains
(VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR
).
However, on implementations which support multiple windowing systems, not
all window systems may be able to provide a protected display path.
This extension provides a way to query if a protected swapchain created for a surface (and thus a specific windowing system) can be displayed on screen. It extends the existing VkSurfaceCapabilities2KHR structure with a new VkSurfaceProtectedCapabilitiesKHR structure from which the application can obtain information about support for protected swapchain creation through vkGetPhysicalDeviceSurfaceCapabilities2KHR.
New Enum Constants
-
VK_KHR_SURFACE_PROTECTED_CAPABILITIES_EXTENSION_NAME
-
VK_KHR_SURFACE_PROTECTED_CAPABILITIES_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_SURFACE_PROTECTED_CAPABILITIES_KHR
-
VK_KHR_swapchain
- Name String
-
VK_KHR_swapchain
- Extension Type
-
Device extension
- Registered Extension Number
-
2
- Revision
-
70
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_1
-
- Contact
-
-
James Jones cubanismo
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2017-10-06
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Interacts with Vulkan 1.1
-
- Contributors
-
-
Patrick Doane, Blizzard
-
Ian Elliott, LunarG
-
Jesse Hall, Google
-
Mathias Heyer, NVIDIA
-
James Jones, NVIDIA
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Faith Ekstrand, Intel
-
Matthaeus G. Chajdas, AMD
-
Ray Smith, ARM
-
Description
The VK_KHR_swapchain
extension is the device-level companion to the
VK_KHR_surface
extension.
It introduces VkSwapchainKHR objects, which provide the ability to
present rendering results to a surface.
New Structures
If Version 1.1 is supported:
-
Extending VkBindImageMemoryInfo:
-
Extending VkImageCreateInfo:
-
Extending VkPresentInfoKHR:
-
Extending VkSwapchainCreateInfoKHR:
New Enums
If Version 1.1 is supported:
New Bitmasks
If Version 1.1 is supported:
New Enum Constants
-
VK_KHR_SWAPCHAIN_EXTENSION_NAME
-
VK_KHR_SWAPCHAIN_SPEC_VERSION
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR
-
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_SWAPCHAIN_KHR
-
-
Extending VkResult:
-
VK_ERROR_OUT_OF_DATE_KHR
-
VK_SUBOPTIMAL_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PRESENT_INFO_KHR
-
VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR
-
If Version 1.1 is supported:
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR
-
-
Extending VkSwapchainCreateFlagBitsKHR:
-
VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR
-
VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
-
Issues
1) Does this extension allow the application to specify the memory backing of the presentable images?
RESOLVED: No. Unlike standard images, the implementation will allocate the memory backing of the presentable image.
2) What operations are allowed on presentable images?
RESOLVED: This is determined by the image usage flags specified when creating the presentable image’s swapchain.
3) Does this extension support MSAA presentable images?
RESOLVED: No. Presentable images are always single-sampled. Multi-sampled rendering must use regular images. To present the rendering results the application must manually resolve the multi- sampled image to a single-sampled presentable image prior to presentation.
4) Does this extension support stereo/multi-view presentable images?
RESOLVED: Yes.
The number of views associated with a presentable image is determined by the
imageArrayLayers
specified when creating a swapchain.
All presentable images in a given swapchain use the same array size.
5) Are the layers of stereo presentable images half-sized?
RESOLVED: No. The image extents always match those requested by the application.
6) Do the “present” and “acquire next image” commands operate on a queue? If not, do they need to include explicit semaphore objects to interlock them with queue operations?
RESOLVED: The present command operates on a queue. The image ownership operation it represents happens in order with other operations on the queue, so no explicit semaphore object is required to synchronize its actions.
Applications may want to acquire the next image in separate threads from those in which they manage their queue, or in multiple threads. To make such usage easier, the acquire next image command takes a semaphore to signal as a method of explicit synchronization. The application must later queue a wait for this semaphore before queuing execution of any commands using the image.
7) Does vkAcquireNextImageKHR block if no images are available?
RESOLVED: The command takes a timeout parameter.
Special values for the timeout are 0, which makes the call a non-blocking
operation, and UINT64_MAX
, which blocks indefinitely.
Values in between will block for up to the specified time.
The call will return when an image becomes available or an error occurs.
It may, but is not required to, return before the specified timeout expires
if the swapchain becomes out of date.
8) Can multiple presents be queued using one vkQueuePresentKHR call?
RESOLVED: Yes. VkPresentInfoKHR contains a list of swapchains and corresponding image indices that will be presented. When supported, all presentations queued with a single vkQueuePresentKHR call will be applied atomically as one operation. The same swapchain must not appear in the list more than once. Later extensions may provide applications stronger guarantees of atomicity for such present operations, and/or allow them to query whether atomic presentation of a particular group of swapchains is possible.
9) How do the presentation and acquire next image functions notify the application the targeted surface has changed?
RESOLVED: Two new result codes are introduced for this purpose:
-
VK_SUBOPTIMAL_KHR
- Presentation will still succeed, subject to the window resize behavior, but the swapchain is no longer configured optimally for the surface it targets. Applications should query updated surface information and recreate their swapchain at the next convenient opportunity. -
VK_ERROR_OUT_OF_DATE_KHR
- Failure. The swapchain is no longer compatible with the surface it targets. The application must query updated surface information and recreate the swapchain before presentation will succeed.
These can be returned by both vkAcquireNextImageKHR and vkQueuePresentKHR.
10) Does the vkAcquireNextImageKHR command return a semaphore to the application via an output parameter, or accept a semaphore to signal from the application as an object handle parameter?
RESOLVED: Accept a semaphore to signal as an object handle. This avoids the need to specify whether the application must destroy the semaphore or whether it is owned by the swapchain, and if the latter, what its lifetime is and whether it can be reused for other operations once it is received from vkAcquireNextImageKHR.
11) What types of swapchain queuing behavior should be exposed? Options include swap interval specification, mailbox/most recent vs. FIFO queue management, targeting specific vertical blank intervals or absolute times for a given present operation, and probably others. For some of these, whether they are specified at swapchain creation time or as per-present parameters needs to be decided as well.
RESOLVED: The base swapchain extension will expose 3 possible behaviors (of which, FIFO will always be supported):
-
Immediate present: Does not wait for vertical blanking period to update the current image, likely resulting in visible tearing. No internal queue is used. Present requests are applied immediately.
-
Mailbox queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal single-entry queue is used to hold pending presentation requests. If the queue is full when a new presentation request is received, the new request replaces the existing entry, and any images associated with the prior entry become available for reuse by the application.
-
FIFO queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal queue containing
numSwapchainImages
- 1 entries is used to hold pending presentation requests. New requests are appended to the end of the queue, and one request is removed from the beginning of the queue and processed during each vertical blanking period in which the queue is non-empty
Not all surfaces will support all of these modes, so the modes supported will be returned using a surface information query. All surfaces must support the FIFO queue mode. Applications must choose one of these modes up front when creating a swapchain. Switching modes can be accomplished by recreating the swapchain.
12) Can VK_PRESENT_MODE_MAILBOX_KHR
provide non-blocking guarantees
for vkAcquireNextImageKHR? If so, what is the proper criteria?
RESOLVED: Yes. The difficulty is not immediately obvious here. Naively, if at least 3 images are requested, mailbox mode should always have an image available for the application if the application does not own any images when the call to vkAcquireNextImageKHR was made. However, some presentation engines may have more than one “current” image, and would still need to block in some cases. The right requirement appears to be that if the application allocates the surface’s minimum number of images + 1 then it is guaranteed non-blocking behavior when it does not currently own any images.
13) Is there a way to create and initialize a new swapchain for a surface
that has generated a VK_SUBOPTIMAL_KHR
return code while still using
the old swapchain?
RESOLVED: Not as part of this specification. This could be useful to allow the application to create an “optimal” replacement swapchain and rebuild all its command buffers using it in a background thread at a low priority while continuing to use the “suboptimal” swapchain in the main thread. It could probably use the same “atomic replace” semantics proposed for recreating direct-to-device swapchains without incurring a mode switch. However, after discussion, it was determined some platforms probably could not support concurrent swapchains for the same surface though, so this will be left out of the base KHR extensions. A future extension could add this for platforms where it is supported.
14) Should there be a special value for
VkSurfaceCapabilitiesKHR::maxImageCount
to indicate there are no
practical limits on the number of images in a swapchain?
RESOLVED: Yes. There will often be cases where there is no practical limit to the number of images in a swapchain other than the amount of available resources (i.e., memory) in the system. Trying to derive a hard limit from things like memory size is prone to failure. It is better in such cases to leave it to applications to figure such soft limits out via trial/failure iterations.
15) Should there be a special value for
VkSurfaceCapabilitiesKHR::currentExtent
to indicate the size of
the platform surface is undefined?
RESOLVED: Yes. On some platforms (Wayland, for example), the surface size is defined by the images presented to it rather than the other way around.
16) Should there be a special value for
VkSurfaceCapabilitiesKHR::maxImageExtent
to indicate there is no
practical limit on the surface size?
RESOLVED: No. It seems unlikely such a system would exist. 0 could be used to indicate the platform places no limits on the extents beyond those imposed by Vulkan for normal images, but this query could just as easily return those same limits, so a special “unlimited” value does not seem useful for this field.
17) How should surface rotation and mirroring be exposed to applications? How do they specify rotation and mirroring transforms applied prior to presentation?
RESOLVED: Applications can query both the supported and current transforms
of a surface.
Both are specified relative to the device’s “natural” display rotation and
direction.
The supported transforms indicate which orientations the presentation engine
accepts images in.
For example, a presentation engine that does not support transforming
surfaces as part of presentation, and which is presenting to a surface that
is displayed with a 90-degree rotation, would return only one supported
transform bit: VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR
.
Applications must transform their rendering by the transform they specify
when creating the swapchain in preTransform
field.
18) Can surfaces ever not support VK_MIRROR_NONE
? Can they support
vertical and horizontal mirroring simultaneously? Relatedly, should
VK_MIRROR_NONE
[_BIT] be zero, or bit one, and should applications be
allowed to specify multiple pre and current mirror transform bits, or
exactly one?
RESOLVED: Since some platforms may not support presenting with a transform
other than the native window’s current transform, and prerotation/mirroring
are specified relative to the device’s natural rotation and direction,
rather than relative to the surface’s current rotation and direction, it is
necessary to express lack of support for no mirroring.
To allow this, the MIRROR_NONE
enum must occupy a bit in the flags.
Since MIRROR_NONE
must be a bit in the bitmask rather than a bitmask
with no values set, allowing more than one bit to be set in the bitmask
would make it possible to describe undefined transforms such as
VK_MIRROR_NONE_BIT
| VK_MIRROR_HORIZONTAL_BIT
, or a transform
that includes both “no mirroring” and “horizontal mirroring”
simultaneously.
Therefore, it is desirable to allow specifying all supported mirroring
transforms using only one bit.
The question then becomes, should there be a
VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT
to represent a simultaneous
horizontal and vertical mirror transform? However, such a transform is
equivalent to a 180 degree rotation, so presentation engines and
applications that wish to support or use such a transform can express it
through rotation instead.
Therefore, 3 exclusive bits are sufficient to express all needed mirroring
transforms.
19) Should support for sRGB be required?
RESOLVED: In the advent of UHD and HDR display devices, proper color space information is vital to the display pipeline represented by the swapchain. The app can discover the supported format/color-space pairs and select a pair most suited to its rendering needs. Currently only the sRGB color space is supported, future extensions may provide support for more color spaces. See issues 23 and 24.
20) Is there a mechanism to modify or replace an existing swapchain with one targeting the same surface?
RESOLVED: Yes. This is described above in the text.
21) Should there be a way to set prerotation and mirroring using native APIs when presenting using a Vulkan swapchain?
RESOLVED: Yes.
The transforms that can be expressed in this extension are a subset of those
possible on native platforms.
If a platform exposes a method to specify the transform of presented images
for a given surface using native methods and exposes more transforms or
other properties for surfaces than Vulkan supports, it might be impossible,
difficult, or inconvenient to set some of those properties using Vulkan KHR
extensions and some using the native interfaces.
To avoid overwriting properties set using native commands when presenting
using a Vulkan swapchain, the application can set the pretransform to
“inherit”, in which case the current native properties will be used, or if
none are available, a platform-specific default will be used.
Platforms that do not specify a reasonable default or do not provide native
mechanisms to specify such transforms should not include the inherit bits in
the supportedTransforms
bitmask they return in
VkSurfaceCapabilitiesKHR.
22) Should the content of presentable images be clipped by objects obscuring their target surface?
RESOLVED: Applications can choose which behavior they prefer. Allowing the content to be clipped could enable more efficient presentation methods on some platforms, but some applications might rely on the content of presentable images to perform techniques such as partial updates or motion blurs.
23) What is the purpose of specifying a VkColorSpaceKHR along with VkFormat when creating a swapchain?
RESOLVED: While Vulkan itself is color space agnostic (e.g. even the
meaning of R, G, B and A can be freely defined by the rendering
application), the swapchain eventually will have to present the images on a
display device with specific color reproduction characteristics.
If any color space transformations are necessary before an image can be
displayed, the color space of the presented image must be known to the
swapchain.
A swapchain will only support a restricted set of color format and -space
pairs.
This set can be discovered via vkGetPhysicalDeviceSurfaceFormatsKHR.
As it can be expected that most display devices support the sRGB color
space, at least one format/color-space pair has to be exposed, where the
color space is VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
.
24) How are sRGB formats and the sRGB color space related?
RESOLVED: While Vulkan exposes a number of SRGB texture formats, using
such formats does not guarantee working in a specific color space.
It merely means that the hardware can directly support applying the
non-linear transfer functions defined by the sRGB standard color space when
reading from or writing to images of those formats.
Still, it is unlikely that a swapchain will expose a *_SRGB
format
along with any color space other than
VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
.
On the other hand, non-*_SRGB
formats will be very likely exposed in
pair with a SRGB color space.
This means, the hardware will not apply any transfer function when reading
from or writing to such images, yet they will still be presented on a device
with sRGB display characteristics.
In this case the application is responsible for applying the transfer
function, for instance by using shader math.
25) How are the lifetimes of surfaces and swapchains targeting them related?
RESOLVED: A surface must outlive any swapchains targeting it. A VkSurfaceKHR owns the binding of the native window to the Vulkan driver.
26) How can the client control the way the alpha component of swapchain images is treated by the presentation engine during compositing?
RESOLVED: We should add new enum values to allow the client to negotiate
with the presentation engine on how to treat image alpha values during the
compositing process.
Since not all platforms can practically control this through the Vulkan
driver, a value of VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
is provided like
for surface transforms.
27) Is vkCreateSwapchainKHR the right function to return
VK_ERROR_NATIVE_WINDOW_IN_USE_KHR
, or should the various
platform-specific VkSurfaceKHR factory functions catch this error
earlier?
RESOLVED: For most platforms, the VkSurfaceKHR structure is a simple container holding the data that identifies a native window or other object representing a surface on a particular platform. For the surface factory functions to return this error, they would likely need to register a reference on the native objects with the native display server somehow, and ensure no other such references exist. Surfaces were not intended to be that heavyweight.
Swapchains are intended to be the objects that directly manipulate native windows and communicate with the native presentation mechanisms. Swapchains will already need to communicate with the native display server to negotiate allocation and/or presentation of presentable images for a native surface. Therefore, it makes more sense for swapchain creation to be the point at which native object exclusivity is enforced. Platforms may choose to enforce further restrictions on the number of VkSurfaceKHR objects that may be created for the same native window if such a requirement makes sense on a particular platform, but a global requirement is only sensible at the swapchain level.
Examples
Note
The example code for the |
Version History
-
Revision 1, 2015-05-20 (James Jones)
-
Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.
-
-
Revision 2, 2015-05-22 (Ian Elliott)
-
Made many agreed-upon changes from 2015-05-21 KHR TSG meeting. This includes using only a queue for presentation, and having an explicit function to acquire the next image.
-
Fixed typos and other minor mistakes.
-
-
Revision 3, 2015-05-26 (Ian Elliott)
-
Improved the Description section.
-
Added or resolved issues that were found in improving the Description. For example, pSurfaceDescription is used consistently, instead of sometimes using pSurface.
-
-
Revision 4, 2015-05-27 (James Jones)
-
Fixed some grammatical errors and typos
-
Filled in the description of imageUseFlags when creating a swapchain.
-
Added a description of swapInterval.
-
Replaced the paragraph describing the order of operations on a queue for image ownership and presentation.
-
-
Revision 5, 2015-05-27 (James Jones)
-
Imported relevant issues from the (abandoned) vk_wsi_persistent_swapchain_images extension.
-
Added issues 6 and 7, regarding behavior of the acquire next image and present commands with respect to queues.
-
Updated spec language and examples to align with proposed resolutions to issues 6 and 7.
-
-
Revision 6, 2015-05-27 (James Jones)
-
Added issue 8, regarding atomic presentation of multiple swapchains
-
Updated spec language and examples to align with proposed resolution to issue 8.
-
-
Revision 7, 2015-05-27 (James Jones)
-
Fixed compilation errors in example code, and made related spec fixes.
-
-
Revision 8, 2015-05-27 (James Jones)
-
Added issue 9, and the related VK_SUBOPTIMAL_KHR result code.
-
Renamed VK_OUT_OF_DATE_KHR to VK_ERROR_OUT_OF_DATE_KHR.
-
-
Revision 9, 2015-05-27 (James Jones)
-
Added inline proposed resolutions (marked with [JRJ]) to some XXX questions/issues. These should be moved to the issues section in a subsequent update if the proposals are adopted.
-
-
Revision 10, 2015-05-28 (James Jones)
-
Converted vkAcquireNextImageKHR back to a non-queue operation that uses a VkSemaphore object for explicit synchronization.
-
Added issue 10 to determine whether vkAcquireNextImageKHR generates or returns semaphores, or whether it operates on a semaphore provided by the application.
-
-
Revision 11, 2015-05-28 (James Jones)
-
Marked issues 6, 7, and 8 resolved.
-
Renamed VkSurfaceCapabilityPropertiesKHR to VkSurfacePropertiesKHR to better convey the mutable nature of the information it contains.
-
-
Revision 12, 2015-05-28 (James Jones)
-
Added issue 11 with a proposed resolution, and the related issue 12.
-
Updated various sections of the spec to match the proposed resolution to issue 11.
-
-
Revision 13, 2015-06-01 (James Jones)
-
Moved some structures to VK_EXT_KHR_swap_chain to resolve the specification’s issues 1 and 2.
-
-
Revision 14, 2015-06-01 (James Jones)
-
Added code for example 4 demonstrating how an application might make use of the two different present and acquire next image KHR result codes.
-
Added issue 13.
-
-
Revision 15, 2015-06-01 (James Jones)
-
Added issues 14 - 16 and related spec language.
-
Fixed some spelling errors.
-
Added language describing the meaningful return values for vkAcquireNextImageKHR and vkQueuePresentKHR.
-
-
Revision 16, 2015-06-02 (James Jones)
-
Added issues 17 and 18, as well as related spec language.
-
Removed some erroneous text added by mistake in the last update.
-
-
Revision 17, 2015-06-15 (Ian Elliott)
-
Changed special value from “-1” to “0” so that the data types can be unsigned.
-
-
Revision 18, 2015-06-15 (Ian Elliott)
-
Clarified the values of VkSurfacePropertiesKHR::minImageCount and the timeout parameter of the vkAcquireNextImageKHR function.
-
-
Revision 19, 2015-06-17 (James Jones)
-
Misc. cleanup. Removed resolved inline issues and fixed typos.
-
Fixed clarification of VkSurfacePropertiesKHR::minImageCount made in version 18.
-
Added a brief “Image Ownership” definition to the list of terms used in the spec.
-
-
Revision 20, 2015-06-17 (James Jones)
-
Updated enum-extending values using new convention.
-
-
Revision 21, 2015-06-17 (James Jones)
-
Added language describing how to use VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.
-
Cleaned up an XXX comment regarding the description of which queues vkQueuePresentKHR can be used on.
-
-
Revision 22, 2015-06-17 (James Jones)
-
Rebased on Vulkan API version 126.
-
-
Revision 23, 2015-06-18 (James Jones)
-
Updated language for issue 12 to read as a proposed resolution.
-
Marked issues 11, 12, 13, 16, and 17 resolved.
-
Temporarily added links to the relevant bugs under the remaining unresolved issues.
-
Added issues 19 and 20 as well as proposed resolutions.
-
-
Revision 24, 2015-06-19 (Ian Elliott)
-
Changed special value for VkSurfacePropertiesKHR::currentExtent back to “-1” from “0”. This value will never need to be unsigned, and “0” is actually a legal value.
-
-
Revision 25, 2015-06-23 (Ian Elliott)
-
Examples now show use of function pointers for extension functions.
-
Eliminated extraneous whitespace.
-
-
Revision 26, 2015-06-25 (Ian Elliott)
-
Resolved Issues 9 & 10 per KHR TSG meeting.
-
-
Revision 27, 2015-06-25 (James Jones)
-
Added oldSwapchain member to VkSwapchainCreateInfoKHR.
-
-
Revision 28, 2015-06-25 (James Jones)
-
Added the “inherit” bits to the rotation and mirroring flags and the associated issue 21.
-
-
Revision 29, 2015-06-25 (James Jones)
-
Added the “clipped” flag to VkSwapchainCreateInfoKHR, and the associated issue 22.
-
Specified that presenting an image does not modify it.
-
-
Revision 30, 2015-06-25 (James Jones)
-
Added language to the spec that clarifies the behavior of vkCreateSwapchainKHR() when the oldSwapchain field of VkSwapchainCreateInfoKHR is not NULL.
-
-
Revision 31, 2015-06-26 (Ian Elliott)
-
Example of new VkSwapchainCreateInfoKHR members, “oldSwapchain” and “clipped”.
-
Example of using VkSurfacePropertiesKHR::{min|max}ImageCount to set VkSwapchainCreateInfoKHR::minImageCount.
-
Rename vkGetSurfaceInfoKHR()'s 4th parameter to “pDataSize”, for consistency with other functions.
-
Add macro with C-string name of extension (just to header file).
-
-
Revision 32, 2015-06-26 (James Jones)
-
Minor adjustments to the language describing the behavior of “oldSwapchain”
-
Fixed the version date on my previous two updates.
-
-
Revision 33, 2015-06-26 (Jesse Hall)
-
Add usage flags to VkSwapchainCreateInfoKHR
-
-
Revision 34, 2015-06-26 (Ian Elliott)
-
Rename vkQueuePresentKHR()'s 2nd parameter to “pPresentInfo”, for consistency with other functions.
-
-
Revision 35, 2015-06-26 (Faith Ekstrand)
-
Merged the VkRotationFlagBitsKHR and VkMirrorFlagBitsKHR enums into a single VkSurfaceTransformFlagBitsKHR enum.
-
-
Revision 36, 2015-06-26 (Faith Ekstrand)
-
Added a VkSurfaceTransformKHR enum that is not a bitmask. Each value in VkSurfaceTransformKHR corresponds directly to one of the bits in VkSurfaceTransformFlagBitsKHR so transforming from one to the other is easy. Having a separate enum means that currentTransform and preTransform are now unambiguous by definition.
-
-
Revision 37, 2015-06-29 (Ian Elliott)
-
Corrected one of the signatures of vkAcquireNextImageKHR, which had the last two parameters switched from what it is elsewhere in the specification and header files.
-
-
Revision 38, 2015-06-30 (Ian Elliott)
-
Corrected a typo in description of the vkGetSwapchainInfoKHR() function.
-
Corrected a typo in header file comment for VkPresentInfoKHR::sType.
-
-
Revision 39, 2015-07-07 (Daniel Rakos)
-
Added error section describing when each error is expected to be reported.
-
Replaced bool32_t with VkBool32.
-
-
Revision 40, 2015-07-10 (Ian Elliott)
-
Updated to work with version 138 of the
vulkan.h
header. This includes declaring the VkSwapchainKHR type using the new VK_DEFINE_NONDISP_HANDLE macro, and no longer extending VkObjectType (which was eliminated).
-
-
Revision 41 2015-07-09 (Mathias Heyer)
-
Added color space language.
-
-
Revision 42, 2015-07-10 (Daniel Rakos)
-
Updated query mechanism to reflect the convention changes done in the core spec.
-
Removed “queue” from the name of VK_STRUCTURE_TYPE_QUEUE_PRESENT_INFO_KHR to be consistent with the established naming convention.
-
Removed reference to the no longer existing VkObjectType enum.
-
-
Revision 43, 2015-07-17 (Daniel Rakos)
-
Added support for concurrent sharing of swapchain images across queue families.
-
Updated sample code based on recent changes
-
-
Revision 44, 2015-07-27 (Ian Elliott)
-
Noted that support for VK_PRESENT_MODE_FIFO_KHR is required. That is ICDs may optionally support IMMEDIATE and MAILBOX, but must support FIFO.
-
-
Revision 45, 2015-08-07 (Ian Elliott)
-
Corrected a typo in spec file (type and variable name had wrong case for the imageColorSpace member of the VkSwapchainCreateInfoKHR struct).
-
Corrected a typo in header file (last parameter in PFN_vkGetSurfacePropertiesKHR was missing “KHR” at the end of type: VkSurfacePropertiesKHR).
-
-
Revision 46, 2015-08-20 (Ian Elliott)
-
Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.
-
Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.
-
Made improvements to several descriptions.
-
Changed the status of several issues from PROPOSED to RESOLVED, leaving no unresolved issues.
-
Resolved several TODOs, did miscellaneous cleanup, etc.
-
-
Revision 47, 2015-08-20 (Ian Elliott—porting a 2015-07-29 change from James Jones)
-
Moved the surface transform enums to VK_WSI_swapchain so they could be reused by VK_WSI_display.
-
-
Revision 48, 2015-09-01 (James Jones)
-
Various minor cleanups.
-
-
Revision 49, 2015-09-01 (James Jones)
-
Restore single-field revision number.
-
-
Revision 50, 2015-09-01 (James Jones)
-
Update Example #4 to include code that illustrates how to use the oldSwapchain field.
-
-
Revision 51, 2015-09-01 (James Jones)
-
Fix example code compilation errors.
-
-
Revision 52, 2015-09-08 (Matthaeus G. Chajdas)
-
Corrected a typo.
-
-
Revision 53, 2015-09-10 (Alon Or-bach)
-
Removed underscore from SWAP_CHAIN left in VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR.
-
-
Revision 54, 2015-09-11 (Jesse Hall)
-
Described the execution and memory coherence requirements for image transitions to and from VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.
-
-
Revision 55, 2015-09-11 (Ray Smith)
-
Added errors for destroying and binding memory to presentable images
-
-
Revision 56, 2015-09-18 (James Jones)
-
Added fence argument to vkAcquireNextImageKHR
-
Added example of how to meter a host thread based on presentation rate.
-
-
Revision 57, 2015-09-26 (Jesse Hall)
-
Replace VkSurfaceDescriptionKHR with VkSurfaceKHR.
-
Added issue 25 with agreed resolution.
-
-
Revision 58, 2015-09-28 (Jesse Hall)
-
Renamed from VK_EXT_KHR_device_swapchain to VK_EXT_KHR_swapchain.
-
-
Revision 59, 2015-09-29 (Ian Elliott)
-
Changed vkDestroySwapchainKHR() to return void.
-
-
Revision 60, 2015-10-01 (Jeff Vigil)
-
Added error result VK_ERROR_SURFACE_LOST_KHR.
-
-
Revision 61, 2015-10-05 (Faith Ekstrand)
-
Added the VkCompositeAlpha enum and corresponding structure fields.
-
-
Revision 62, 2015-10-12 (Daniel Rakos)
-
Added VK_PRESENT_MODE_FIFO_RELAXED_KHR.
-
-
Revision 63, 2015-10-15 (Daniel Rakos)
-
Moved surface capability queries to VK_EXT_KHR_surface.
-
-
Revision 64, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_swapchain to VK_KHR_swapchain.
-
-
Revision 65, 2015-10-28 (Ian Elliott)
-
Added optional pResult member to VkPresentInfoKHR, so that per-swapchain results can be obtained from vkQueuePresentKHR().
-
-
Revision 66, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to create and destroy functions.
-
Updated resource transition language.
-
Updated sample code.
-
-
Revision 67, 2015-11-10 (Jesse Hall)
-
Add reserved flags bitmask to VkSwapchainCreateInfoKHR.
-
Modify naming and member ordering to match API style conventions, and so the VkSwapchainCreateInfoKHR image property members mirror corresponding VkImageCreateInfo members but with an 'image' prefix.
-
Make VkPresentInfoKHR::pResults non-const; it is an output array parameter.
-
Make pPresentInfo parameter to vkQueuePresentKHR const.
-
-
Revision 68, 2016-04-05 (Ian Elliott)
-
Moved the “validity” include for vkAcquireNextImage to be in its proper place, after the prototype and list of parameters.
-
Clarified language about presentable images, including how they are acquired, when applications can and cannot use them, etc. As part of this, removed language about “ownership” of presentable images, and replaced it with more-consistent language about presentable images being “acquired” by the application.
-
-
2016-08-23 (Ian Elliott)
-
Update the example code, to use the final API command names, to not have so many characters per line, and to split out a new example to show how to obtain function pointers. This code is more similar to the LunarG “cube” demo program.
-
-
2016-08-25 (Ian Elliott)
-
A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.
-
-
Revision 69, 2017-09-07 (Tobias Hector)
-
Added interactions with Vulkan 1.1
-
-
Revision 70, 2017-10-06 (Ian Elliott)
-
Corrected interactions with Vulkan 1.1
-
VK_KHR_swapchain_mutable_format
- Name String
-
VK_KHR_swapchain_mutable_format
- Extension Type
-
Device extension
- Registered Extension Number
-
201
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Daniel Rakos drakos-amd
-
Other Extension Metadata
- Last Modified Date
-
2018-03-28
- IP Status
-
No known IP claims.
- Contributors
-
-
Faith Ekstrand, Intel
-
Jan-Harald Fredriksen, ARM
-
Jesse Hall, Google
-
Daniel Rakos, AMD
-
Ray Smith, ARM
-
Description
This extension allows processing of swapchain images as different formats to that used by the window system, which is particularly useful for switching between sRGB and linear RGB formats.
It adds a new swapchain creation flag that enables creating image views from presentable images with a different format than the one used to create the swapchain.
New Enum Constants
-
VK_KHR_SWAPCHAIN_MUTABLE_FORMAT_EXTENSION_NAME
-
VK_KHR_SWAPCHAIN_MUTABLE_FORMAT_SPEC_VERSION
-
Extending VkSwapchainCreateFlagBitsKHR:
-
VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR
-
Issues
1) Are there any new capabilities needed?
RESOLVED: No. It is expected that all implementations exposing this extension support swapchain image format mutability.
2) Do we need a separate VK_SWAPCHAIN_CREATE_EXTENDED_USAGE_BIT_KHR
?
RESOLVED: No.
This extension requires VK_KHR_maintenance2
and presentable images of
swapchains created with VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR
are
created internally in a way equivalent to specifying both
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
and
VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR
.
3) Do we need a separate structure to allow specifying an image format list for swapchains?
RESOLVED: No.
We simply use the same VkImageFormatListCreateInfoKHR structure
introduced by VK_KHR_image_format_list
.
The structure is required to be included in the pNext
chain of
VkSwapchainCreateInfoKHR for swapchains created with
VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR
.
VK_KHR_vertex_attribute_divisor
- Name String
-
VK_KHR_vertex_attribute_divisor
- Extension Type
-
Device extension
- Registered Extension Number
-
526
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Shahbaz Youssefi syoussefi
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-09-20
- IP Status
-
No known IP claims.
- Contributors
-
-
Shahbaz Youssefi, Google
-
Contributors to
VK_EXT_vertex_attribute_divisor
-
Description
This extension is based on the
extension.
The only difference is the new property VK_EXT_vertex_attribute_divisor
supportsNonZeroFirstInstance
,
which indicates support for non-zero values in firstInstance
.
This allows the extension to be supported on implementations that have
traditionally only supported OpenGL ES.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkPipelineVertexInputStateCreateInfo:
New Enum Constants
-
VK_KHR_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME
-
VK_KHR_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_KHR
-
VK_KHR_video_decode_av1
- Name String
-
VK_KHR_video_decode_av1
- Extension Type
-
Device extension
- Registered Extension Number
-
513
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Daniel Rakos aqnuep
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2024-01-02
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
Benjamin Cheng, AMD
-
Ho Hin Lau, AMD
-
Lynne Iribarren, Independent
-
David Airlie, Red Hat, Inc.
-
Ping Liu, Intel
-
Srinath Kumarapuram, NVIDIA
-
Vassili Nikolaev, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Charlie Turner, Igalia
-
Daniel Almeida, Collabora
-
Nicolas Dufresne, Collabora
-
Daniel Rakos, RasterGrid
-
Description
This extension builds upon the VK_KHR_video_decode_queue
extension
by adding support for decoding elementary video stream sequences compliant
with the AV1 video compression standard.
New Structures
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoDecodeInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
-
Extending VkVideoReferenceSlotInfoKHR:
-
Extending VkVideoSessionParametersCreateInfoKHR:
New Enum Constants
-
VK_KHR_VIDEO_DECODE_AV1_EXTENSION_NAME
-
VK_KHR_VIDEO_DECODE_AV1_SPEC_VERSION
-
VK_MAX_VIDEO_AV1_REFERENCES_PER_FRAME_KHR
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_DPB_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_PICTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_SESSION_PARAMETERS_CREATE_INFO_KHR
-
-
Extending VkVideoCodecOperationFlagBitsKHR:
-
VK_VIDEO_CODEC_OPERATION_DECODE_AV1_BIT_KHR
-
VK_KHR_video_decode_h264
- Name String
-
VK_KHR_video_decode_h264
- Extension Type
-
Device extension
- Registered Extension Number
-
41
- Revision
-
9
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
Chunbo Chen, Intel
-
HoHin Lau, AMD
-
Jake Beju, AMD
-
Peter Fang, AMD
-
Ping Liu, Intel
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Daniel Rakos, RasterGrid
-
Description
This extension builds upon the VK_KHR_video_decode_queue
extension
by adding support for decoding elementary video stream sequences compliant
with the H.264/AVC video compression standard.
Note
This extension was promoted to |
New Structures
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoDecodeInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
-
Extending VkVideoReferenceSlotInfoKHR:
-
Extending VkVideoSessionParametersCreateInfoKHR:
-
Extending VkVideoSessionParametersUpdateInfoKHR:
New Enum Constants
-
VK_KHR_VIDEO_DECODE_H264_EXTENSION_NAME
-
VK_KHR_VIDEO_DECODE_H264_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_DPB_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PICTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_ADD_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_CREATE_INFO_KHR
-
-
Extending VkVideoCodecOperationFlagBitsKHR:
-
VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR
-
Version History
-
Revision 1, 2018-6-11 (Peter Fang)
-
Initial draft
-
-
Revision 2, March 29 2021 (Tony Zlatinski)
-
Spec and API Updates
-
-
Revision 3, August 1 2021 (Srinath Kumarapuram)
-
Rename
VkVideoDecodeH264FieldLayoutFlagsEXT
toVkVideoDecodeH264PictureLayoutFlagsEXT
,VkVideoDecodeH264FieldLayoutFlagBitsEXT
toVkVideoDecodeH264PictureLayoutFlagBitsEXT
(along with the names of enumerants it defines), andVkVideoDecodeH264ProfileEXT.fieldLayout
toVkVideoDecodeH264ProfileEXT.pictureLayout
, following Vulkan naming conventions.
-
-
Revision 4, 2022-03-16 (Ahmed Abdelkhalek)
-
Relocate Std header version reporting/requesting from this extension to VK_KHR_video_queue extension.
-
Remove the now empty VkVideoDecodeH264SessionCreateInfoEXT.
-
-
Revision 5, 2022-03-31 (Ahmed Abdelkhalek)
-
Use type StdVideoH264Level for VkVideoDecodeH264Capabilities.maxLevel
-
-
Revision 6, 2022-08-09 (Daniel Rakos)
-
Rename
VkVideoDecodeH264ProfileEXT
toVkVideoDecodeH264ProfileInfoEXT
-
Rename
VkVideoDecodeH264MvcEXT
toVkVideoDecodeH264MvcInfoEXT
-
-
Revision 7, 2022-09-18 (Daniel Rakos)
-
Change type of
VkVideoDecodeH264ProfileInfoEXT::pictureLayout
toVkVideoDecodeH264PictureLayoutFlagBitsEXT
-
Remove MVC support and related
VkVideoDecodeH264MvcInfoEXT
structure -
Rename
spsStdCount
,pSpsStd
,ppsStdCount
, andpPpsStd
tostdSPSCount
,pStdSPSs
,stdPPSCount
, andpStdPPSs
, respectively, inVkVideoDecodeH264SessionParametersAddInfoEXT
-
Rename
maxSpsStdCount
andmaxPpsStdCount
tomaxStdSPSCount
andmaxStdPPSCount
, respectively, inVkVideoDecodeH264SessionParametersCreateInfoEXT
-
Rename
slicesCount
andpSlicesDataOffsets
tosliceCount
andpSliceOffsets
, respectively, inVkVideoDecodeH264PictureInfoEXT
-
-
Revision 8, 2022-09-29 (Daniel Rakos)
-
Change extension from
EXT
toKHR
-
Extension is no longer provisional
-
-
Revision 9, 2023-12-05 (Daniel Rakos)
-
Condition reference picture setup based on the value of
StdVideoDecodeH264PictureInfo::flags.is_reference
-
VK_KHR_video_decode_h265
- Name String
-
VK_KHR_video_decode_h265
- Extension Type
-
Device extension
- Registered Extension Number
-
188
- Revision
-
8
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
HoHin Lau, AMD
-
Jake Beju, AMD
-
Peter Fang, AMD
-
Ping Liu, Intel
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Daniel Rakos, RasterGrid
-
Description
This extension builds upon the VK_KHR_video_decode_queue
extension
by adding support for decoding elementary video stream sequences compliant
with the H.265/HEVC video compression standard.
Note
This extension was promoted to |
New Structures
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoDecodeInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
-
Extending VkVideoReferenceSlotInfoKHR:
-
Extending VkVideoSessionParametersCreateInfoKHR:
-
Extending VkVideoSessionParametersUpdateInfoKHR:
New Enum Constants
-
VK_KHR_VIDEO_DECODE_H265_EXTENSION_NAME
-
VK_KHR_VIDEO_DECODE_H265_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_DPB_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PICTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_ADD_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_CREATE_INFO_KHR
-
-
Extending VkVideoCodecOperationFlagBitsKHR:
-
VK_VIDEO_CODEC_OPERATION_DECODE_H265_BIT_KHR
-
Version History
-
Revision 1, 2018-6-11 (Peter Fang)
-
Initial draft
-
-
Revision 1.6, March 29 2021 (Tony Zlatinski)
-
Spec and API updates.
-
-
Revision 2, 2022-03-16 (Ahmed Abdelkhalek)
-
Relocate Std header version reporting/requesting from this extension to VK_KHR_video_queue extension.
-
Remove the now empty VkVideoDecodeH265SessionCreateInfoEXT.
-
-
Revision 3, 2022-03-31 (Ahmed Abdelkhalek)
-
Use type StdVideoH265Level for VkVideoDecodeH265Capabilities.maxLevel
-
-
Revision 4, 2022-08-09 (Daniel Rakos)
-
Rename
VkVideoDecodeH265ProfileEXT
toVkVideoDecodeH265ProfileInfoEXT
-
-
Revision 5, 2022-09-18 (Daniel Rakos)
-
Rename
vpsStdCount
,pVpsStd
,spsStdCount
,pSpsStd
,ppsStdCount
, andpPpsStd
tostdVPSCount
,pStdVPSs
,stdSPSCount
,pStdSPSs
,stdPPSCount
, andpStdPPSs
, respectively, inVkVideoDecodeH265SessionParametersAddInfoEXT
-
Rename
maxVpsStdCount
,maxSpsStdCount
, andmaxPpsStdCount
tomaxStdVPSCount
,maxStdSPSCount
andmaxStdPPSCount
, respectively, inVkVideoDecodeH265SessionParametersCreateInfoEXT
-
Rename
slicesCount
andpSlicesDataOffsets
tosliceCount
andpSliceOffsets
, respectively, inVkVideoDecodeH265PictureInfoEXT
-
-
Revision 6, 2022-11-14 (Daniel Rakos)
-
Rename
slice
tosliceSegment
in the APIs for better clarity
-
-
Revision 7, 2022-11-14 (Daniel Rakos)
-
Change extension from
EXT
toKHR
-
Extension is no longer provisional
-
-
Revision 8, 2023-12-05 (Daniel Rakos)
-
Condition reference picture setup based on the value of
StdVideoDecodeH265PictureInfo::flags.IsReference
-
VK_KHR_video_decode_queue
- Name String
-
VK_KHR_video_decode_queue
- Extension Type
-
Device extension
- Registered Extension Number
-
25
- Revision
-
8
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_KHR_format_feature_flags2
-
- Contact
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
Jake Beju, AMD
-
Olivier Lapicque, NVIDIA
-
Peter Fang, AMD
-
Piers Daniell, NVIDIA
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Daniel Rakos, RasterGrid
-
Description
This extension builds upon the VK_KHR_video_queue
extension by
adding common APIs specific to video decoding and thus enabling
implementations to expose queue families supporting video decode operations.
More specifically, it adds video decode specific capabilities and a new command buffer command that allows recording video decode operations against a video session.
This extension is to be used in conjunction with other codec specific video decode extensions that enable decoding video sequences of specific video compression standards.
New Enum Constants
-
VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME
-
VK_KHR_VIDEO_DECODE_QUEUE_SPEC_VERSION
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_VIDEO_DECODE_READ_BIT_KHR
-
VK_ACCESS_2_VIDEO_DECODE_WRITE_BIT_KHR
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_VIDEO_DECODE_DST_BIT_KHR
-
VK_BUFFER_USAGE_VIDEO_DECODE_SRC_BIT_KHR
-
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_VIDEO_DECODE_DPB_BIT_KHR
-
VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR
-
VK_IMAGE_LAYOUT_VIDEO_DECODE_DST_KHR
-
VK_IMAGE_LAYOUT_VIDEO_DECODE_SRC_KHR
-
-
Extending VkImageUsageFlagBits:
-
VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR
-
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR
-
VK_IMAGE_USAGE_VIDEO_DECODE_SRC_BIT_KHR
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_VIDEO_DECODE_BIT_KHR
-
-
Extending VkQueueFlagBits:
-
VK_QUEUE_VIDEO_DECODE_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_DECODE_USAGE_INFO_KHR
-
If VK_KHR_format_feature_flags2 or Version 1.3 is supported:
-
Extending VkFormatFeatureFlagBits2:
-
VK_FORMAT_FEATURE_2_VIDEO_DECODE_DPB_BIT_KHR
-
VK_FORMAT_FEATURE_2_VIDEO_DECODE_OUTPUT_BIT_KHR
-
Version History
-
Revision 1, 2018-6-11 (Peter Fang)
-
Initial draft
-
-
Revision 1.5, Nov 09 2018 (Tony Zlatinski)
-
API Updates
-
-
Revision 1.6, Jan 08 2020 (Tony Zlatinski)
-
API unify with the video_encode_queue spec
-
-
Revision 1.7, March 29 2021 (Tony Zlatinski)
-
Spec and API updates.
-
-
Revision 2, September 30 2021 (Jon Leech)
-
Add interaction with
VK_KHR_format_feature_flags2
tovk.xml
-
-
Revision 3, 2022-02-25 (Ahmed Abdelkhalek)
-
Add VkVideoDecodeCapabilitiesKHR with new flags to report support for decode DPB and output coinciding in the same image, or in distinct images.
-
-
Revision 4, 2022-03-31 (Ahmed Abdelkhalek)
-
Remove redundant VkVideoDecodeInfoKHR.coded{Offset|Extent}
-
-
Revision 5, 2022-07-18 (Daniel Rakos)
-
Remove
VkVideoDecodeFlagBitsKHR
as it contains no defined flags for now
-
-
Revision 6, 2022-08-12 (Daniel Rakos)
-
Add VkVideoDecodeUsageInfoKHR structure and related flags
-
-
Revision 7, 2022-09-29 (Daniel Rakos)
-
Extension is no longer provisional
-
-
Revision 8, 2023-12-05 (Daniel Rakos)
-
Require the specification of a reconstructed picture in all cases, except when the video session was created with no DPB slots to match shipping implementations
-
Make DPB slot activation behavior codec-specific to continue allowing application control over reference picture setup now that a reconstructed picture is always mandatory
-
VK_KHR_video_encode_h264
- Name String
-
VK_KHR_video_encode_h264
- Extension Type
-
Device extension
- Registered Extension Number
-
39
- Revision
-
14
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Ahmed Abdelkhalek aabdelkh
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
George Hao, AMD
-
Jake Beju, AMD
-
Peter Fang, AMD
-
Ping Liu, Intel
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Ravi Chaudhary, NVIDIA
-
Yang Liu, AMD
-
Daniel Rakos, RasterGrid
-
Aidan Fabius, Core Avionics & Industrial Inc.
-
Lynne Iribarren, Independent
-
Description
This extension builds upon the VK_KHR_video_encode_queue
extension
by adding support for encoding elementary video stream sequences compliant
with the H.264/AVC video compression standard.
Note
This extension was promoted to |
New Structures
-
Extending VkVideoBeginCodingInfoKHR:
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoCodingControlInfoKHR, VkVideoBeginCodingInfoKHR:
-
Extending VkVideoEncodeInfoKHR:
-
Extending VkVideoEncodeQualityLevelPropertiesKHR:
-
Extending VkVideoEncodeRateControlLayerInfoKHR:
-
Extending VkVideoEncodeSessionParametersGetInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
-
Extending VkVideoReferenceSlotInfoKHR:
-
Extending VkVideoSessionCreateInfoKHR:
-
Extending VkVideoSessionParametersCreateInfoKHR:
-
Extending VkVideoSessionParametersUpdateInfoKHR:
New Enum Constants
-
VK_KHR_VIDEO_ENCODE_H264_EXTENSION_NAME
-
VK_KHR_VIDEO_ENCODE_H264_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_DPB_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_GOP_REMAINING_FRAME_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_NALU_SLICE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PICTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_QUALITY_LEVEL_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_LAYER_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_ADD_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_FEEDBACK_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_GET_INFO_KHR
-
-
Extending VkVideoCodecOperationFlagBitsKHR:
-
VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_KHR
-
Version History
-
Revision 0, 2018-7-23 (Ahmed Abdelkhalek)
-
Initial draft
-
-
Revision 0.5, 2020-02-13 (Tony Zlatinski)
-
General Spec cleanup
-
Added DPB structures
-
Change the VCL frame encode structure
-
Added a common Non-VCL Picture Paramarameters structure
-
-
Revision 1, 2021-03-29 (Tony Zlatinski)
-
Spec and API updates
-
-
Revision 2, August 1 2021 (Srinath Kumarapuram)
-
Rename
VkVideoEncodeH264CapabilitiesFlagsEXT
toVkVideoEncodeH264CapabilityFlagsEXT
andVkVideoEncodeH264CapabilitiesFlagsEXT
toVkVideoEncodeH264CapabilityFlagsEXT
, following Vulkan naming conventions.
-
-
Revision 3, 2021-12-08 (Ahmed Abdelkhalek)
-
Rate control updates
-
-
Revision 4, 2022-02-04 (Ahmed Abdelkhalek)
-
Align VkVideoEncodeH264VclFrameInfoEXT structure to similar one in VK_EXT_video_encode_h265 extension
-
-
Revision 5, 2022-02-10 (Ahmed Abdelkhalek)
-
Updates to encode capability interface
-
-
Revision 6, 2022-03-16 (Ahmed Abdelkhalek)
-
Relocate Std header version reporting/requesting from this extension to VK_KHR_video_queue extension.
-
Remove redundant maxPictureSizeInMbs from VkVideoEncodeH264SessionCreateInfoEXT.
-
Remove the now empty VkVideoEncodeH264SessionCreateInfoEXT.
-
-
Revision 7, 2022-04-06 (Ahmed Abdelkhalek)
-
Add capability flag to report support to use B frame in L1 reference list.
-
Add capability flag to report support for disabling SPS direct_8x8_inference_flag.
-
-
Revision 8, 2022-07-18 (Daniel Rakos)
-
Replace
VkVideoEncodeH264RateControlStructureFlagBitsEXT
bit enum withVkVideoEncodeH264RateControlStructureEXT
enum -
Rename
VkVideoEncodeH264ProfileEXT
toVkVideoEncodeH264ProfileInfoEXT
-
Rename
VkVideoEncodeH264ReferenceListsEXT
toVkVideoEncodeH264ReferenceListsInfoEXT
-
Rename
VkVideoEncodeH264EmitPictureParametersEXT
toVkVideoEncodeH264EmitPictureParametersInfoEXT
-
Rename
VkVideoEncodeH264NaluSliceEXT
toVkVideoEncodeH264NaluSliceInfoEXT
-
-
Revision 9, 2022-09-18 (Daniel Rakos)
-
Rename
spsStdCount
,pSpsStd
,ppsStdCount
, andpPpsStd
tostdSPSCount
,pStdSPSs
,stdPPSCount
, andpStdPPSs
, respectively, inVkVideoEncodeH264SessionParametersAddInfoEXT
-
Rename
maxSpsStdCount
andmaxPpsStdCount
tomaxStdSPSCount
andmaxStdPPSCount
, respectively, inVkVideoEncodeH264SessionParametersCreateInfoEXT
-
-
Revision 10, 2023-03-06 (Daniel Rakos)
-
Removed
VkVideoEncodeH264EmitPictureParametersInfoEXT
-
Changed member types in
VkVideoEncodeH264CapabilitiesEXT
andVkVideoEncodeH264ReferenceListsInfoEXT
fromuint8_t
touint32_t
-
Changed the type of
VkVideoEncodeH264RateControlInfoEXT::temporalLayerCount
andVkVideoEncodeH264RateControlLayerInfoEXT::temporalLayerId
fromuint8_t
touint32_t
-
Removed
VkVideoEncodeH264InputModeFlagsEXT
andVkVideoEncodeH264OutputModeFlagsEXT
as we only support frame-in-frame-out mode for now -
Rename
pCurrentPictureInfo
inVkVideoEncodeH264VclFrameInfoEXT
topStdPictureInfo
-
Rename
pSliceHeaderStd
inVkVideoEncodeH264NaluSliceInfoEXT
topStdSliceHeader
-
Rename
pReferenceFinalLists
inVkVideoEncodeH264VclFrameInfoEXT
andVkVideoEncodeH264NaluSliceInfoEXT
topStdReferenceFinalLists
-
Removed the
slotIndex
member ofVkVideoEncodeH264DpbSlotInfoEXT
and changed it to be chained toVkVideoReferenceSlotInfoKHR
-
Replaced
VkVideoEncodeH264ReferenceListsInfoEXT
with the new Video Std header structureStdVideoEncodeH264ReferenceLists
that also includes data previously part of the now removedStdVideoEncodeH264RefMemMgmtCtrlOperations
structure -
Added new capability flag
VK_VIDEO_ENCODE_H264_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
-
-
Revision 11, 2023-05-22 (Daniel Rakos)
-
Renamed
VkVideoEncodeH264VclFrameInfoEXT
toVkVideoEncodeH264PictureInfoEXT
-
Added
VkVideoEncodeH264PictureInfoEXT::generatePrefixNalu
andVK_VIDEO_ENCODE_H264_CAPABILITY_GENERATE_PREFIX_NALU_BIT_EXT
to enable the generation of H.264 prefix NALUs when supported by the implementation -
Removed
VkVideoEncodeH264RateControlLayerInfoEXT::temporalLayerId
-
Added
expectDyadicTemporalLayerPattern
capability -
Added the
VkVideoEncodeH264SessionParametersGetInfoEXT
structure to identify the H.264 parameter sets to retrieve encoded parameter data for, and theVkVideoEncodeH264SessionParametersFeedbackInfoEXT
structure to retrieve H.264 parameter set override information when using the newvkGetEncodedVideoSessionParametersKHR
command -
Added
VkVideoEncodeH264NaluSliceInfoEXT::constantQp
to specify per-slice constant QP when rate control mode isVK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR
-
Added
VkVideoEncodeH264QualityLevelPropertiesEXT
for retrieving H.264 specific quality level recommendations -
Replaced
VkVideoEncodeH264RateControlStructureEXT
enum with the flags typeVkVideoEncodeH264RateControlFlagsEXT
and bits defined inVkVideoEncodeH264RateControlFlagBitsEXT
and added HRD compliance flag -
Removed
useInitialRcQp
andinitialRcQp
members ofVkVideoEncodeH264RateControlLayerInfoEXT
-
Added
prefersGopRemainingFrames
andrequiresGopRemainingFrames
, and the newVkVideoEncodeH264GopRemainingFrameInfoEXT
structure to allow specifying remaining frames of each type in the rate control GOP -
Added
maxTemporalLayers
,maxQp
, andminQp
capabilities -
Added
maxLevelIdc
capability and newVkVideoEncodeH264SessionCreateInfoEXT
structure to specify upper bounds on the H.264 level of the produced video bitstream -
Moved capability flags specific to codec syntax restrictions from
VkVideoEncodeH264CapabilityFlagsEXT
to the newVkVideoEncodeH264StdFlagsEXT
which is now included as a separatestdSyntaxFlags
member inVkVideoEncodeH264CapabilitiesEXT
-
Removed codec syntax override values from
VkVideoEncodeH264CapabilitiesEXT
-
Removed
VkVideoEncodeH264NaluSliceInfoEXT::mbCount
andVK_VIDEO_ENCODE_H264_CAPABILITY_SLICE_MB_COUNT_BIT_EXT
-
Replaced
VK_VIDEO_ENCODE_H264_CAPABILITY_MULTIPLE_SLICES_PER_FRAME_BIT_EXT
with the newmaxSliceCount
capability -
Removed capability flag
VK_VIDEO_ENCODE_H264_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
and removedpStdReferenceFinalLists
members from theVkVideoEncodeH264PictureInfoEXT
andVkVideoEncodeH264NaluSliceInfoEXT
structures as reference lists info is now included inpStdPictureInfo
-
Added capability flag
VK_VIDEO_ENCODE_H264_CAPABILITY_B_FRAME_IN_L0_LIST_BIT_EXT
-
-
Revision 12, 2023-07-19 (Daniel Rakos)
-
Added video std capability flags
VK_VIDEO_ENCODE_H264_STD_SLICE_QP_DELTA_BIT_EXT
andVK_VIDEO_ENCODE_H264_STD_DIFFERENT_SLICE_QP_DELTA_BIT_EXT
-
Fixed optionality of the array members of
VkVideoEncodeH264SessionParametersAddInfoEXT
-
Fixed optionality of
VkVideoEncodeH264RateControlInfoEXT::flags
-
-
Revision 13, 2023-09-04 (Daniel Rakos)
-
Change extension from
EXT
toKHR
-
Extension is no longer provisional
-
-
Revision 14, 2023-12-05 (Daniel Rakos)
-
Condition reference picture setup based on the value of
StdVideoEncodeH264PictureInfo::flags.is_reference
-
VK_KHR_video_encode_h265
- Name String
-
VK_KHR_video_encode_h265
- Extension Type
-
Device extension
- Registered Extension Number
-
40
- Revision
-
14
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Ahmed Abdelkhalek aabdelkh
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
George Hao, AMD
-
Jake Beju, AMD
-
Chunbo Chen, Intel
-
Ping Liu, Intel
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Ravi Chaudhary, NVIDIA
-
Daniel Rakos, RasterGrid
-
Aidan Fabius, Core Avionics & Industrial Inc.
-
Lynne Iribarren, Independent
-
Description
This extension builds upon the VK_KHR_video_encode_queue
extension
by adding support for encoding elementary video stream sequences compliant
with the H.265/HEVC video compression standard.
Note
This extension was promoted to |
New Structures
-
Extending VkVideoBeginCodingInfoKHR:
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoCodingControlInfoKHR, VkVideoBeginCodingInfoKHR:
-
Extending VkVideoEncodeInfoKHR:
-
Extending VkVideoEncodeQualityLevelPropertiesKHR:
-
Extending VkVideoEncodeRateControlLayerInfoKHR:
-
Extending VkVideoEncodeSessionParametersGetInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
-
Extending VkVideoReferenceSlotInfoKHR:
-
Extending VkVideoSessionCreateInfoKHR:
-
Extending VkVideoSessionParametersCreateInfoKHR:
-
Extending VkVideoSessionParametersUpdateInfoKHR:
New Enum Constants
-
VK_KHR_VIDEO_ENCODE_H265_EXTENSION_NAME
-
VK_KHR_VIDEO_ENCODE_H265_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_DPB_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_GOP_REMAINING_FRAME_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_NALU_SLICE_SEGMENT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PICTURE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_QUALITY_LEVEL_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_LAYER_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_ADD_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_FEEDBACK_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_GET_INFO_KHR
-
-
Extending VkVideoCodecOperationFlagBitsKHR:
-
VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_KHR
-
Version History
-
Revision 0, 2019-11-14 (Ahmed Abdelkhalek)
-
Initial draft
-
-
Revision 0.5, 2020-02-13 (Tony Zlatinski)
-
General Spec cleanup
-
Added DPB structures
-
Change the VCL frame encode structure
-
Added a common Non-VCL Picture Paramarameters structure
-
-
Revision 2, Oct 10 2021 (Srinath Kumarapuram)
-
Vulkan Video Encode h.265 update and spec edits
-
-
Revision 3, 2021-12-08 (Ahmed Abdelkhalek)
-
Rate control updates
-
-
Revision 4, 2022-01-11 (Ahmed Abdelkhalek)
-
Replace occurrences of “slice” by “slice segment” and rename structures/enums to reflect this.
-
-
Revision 5, 2022-02-10 (Ahmed Abdelkhalek)
-
Updates to encode capability interface
-
-
Revision 6, 2022-03-16 (Ahmed Abdelkhalek)
-
Relocate Std header version reporting/requesting from this extension to VK_KHR_video_queue extension.
-
Remove the now empty VkVideoEncodeH265SessionCreateInfoEXT.
-
-
Revision 7, 2022-03-24 (Ahmed Abdelkhalek)
-
Add capability flags to report support to disable transform skip and support to use B frame in L1 reference list.
-
-
Revision 8, 2022-07-18 (Daniel Rakos)
-
Replace
VkVideoEncodeH265RateControlStructureFlagBitsEXT
bit enum withVkVideoEncodeH265RateControlStructureEXT
enum -
Rename
VkVideoEncodeH265ProfileEXT
toVkVideoEncodeH265ProfileInfoEXT
-
Rename
VkVideoEncodeH265ReferenceListsEXT
toVkVideoEncodeH265ReferenceListsInfoEXT
-
Rename
VkVideoEncodeH265EmitPictureParametersEXT
toVkVideoEncodeH265EmitPictureParametersInfoEXT
-
Rename
VkVideoEncodeH265NaluSliceSegmentEXT
toVkVideoEncodeH265NaluSliceSegmentInfoEXT
-
-
Revision 9, 2022-09-18 (Daniel Rakos)
-
Rename
vpsStdCount
,pVpsStd
,spsStdCount
,pSpsStd
,ppsStdCount
, andpPpsStd
tostdVPSCount
,pStdVPSs
,stdSPSCount
,pStdSPSs
,stdPPSCount
, andpStdPPSs
, respectively, inVkVideoEncodeH265SessionParametersAddInfoEXT
-
Rename
maxVpsStdCount
,maxSpsStdCount
, andmaxPpsStdCount
tomaxStdVPSCount
,maxStdSPSCount
andmaxStdPPSCount
, respectively, inVkVideoEncodeH265SessionParametersCreateInfoEXT
-
-
Revision 10, 2023-03-06 (Daniel Rakos)
-
Removed
VkVideoEncodeH265EmitPictureParametersInfoEXT
-
Changed member types in
VkVideoEncodeH265CapabilitiesEXT
andVkVideoEncodeH265ReferenceListsInfoEXT
fromuint8_t
touint32_t
-
Changed the type of
VkVideoEncodeH265RateControlInfoEXT::subLayerCount
andVkVideoEncodeH265RateControlLayerInfoEXT::temporalId
fromuint8_t
touint32_t
-
Removed
VkVideoEncodeH265InputModeFlagsEXT
andVkVideoEncodeH265OutputModeFlagsEXT
as we only support frame-in-frame-out mode for now -
Rename
pCurrentPictureInfo
inVkVideoEncodeH265VclFrameInfoEXT
topStdPictureInfo
-
Rename
pSliceSegmentHeaderStd
inVkVideoEncodeH265NaluSliceSegmentInfoEXT
topStdSliceSegmentHeader
-
Rename
pReferenceFinalLists
inVkVideoEncodeH265VclFrameInfoEXT
andVkVideoEncodeH265NaluSliceSegmentInfoEXT
topStdReferenceFinalLists
-
Removed the
slotIndex
member ofVkVideoEncodeH265DpbSlotInfoEXT
and changed it to be chained toVkVideoReferenceSlotInfoKHR
-
Replaced
VkVideoEncodeH265ReferenceListsInfoEXT
with the new Video Std header structureStdVideoEncodeH265ReferenceLists
-
Added new capability flag
VK_VIDEO_ENCODE_H265_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
-
-
Revision 11, 2023-05-26 (Daniel Rakos)
-
Renamed
VkVideoEncodeH265VclFrameInfoEXT
toVkVideoEncodeH265PictureInfoEXT
-
Removed
VkVideoEncodeH265RateControlLayerInfoEXT::temporalId
-
Added
expectDyadicTemporalSubLayerPattern
capability -
Added the
VkVideoEncodeH265SessionParametersGetInfoEXT
structure to identify the H.265 parameter sets to retrieve encoded parameter data for, and theVkVideoEncodeH265SessionParametersFeedbackInfoEXT
structure to retrieve H.265 parameter set override information when using the newvkGetEncodedVideoSessionParametersKHR
command -
Added
VkVideoEncodeH265NaluSliceSegmentInfoEXT::constantQp
to specify per-slice segment constant QP when rate control mode isVK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR
-
Added
VkVideoEncodeH265QualityLevelPropertiesEXT
for retrieving H.265 specific quality level recommendations -
Replaced
VkVideoEncodeH265RateControlStructureEXT
enum with the flags typeVkVideoEncodeH265RateControlFlagsEXT
and bits defined inVkVideoEncodeH265RateControlFlagBitsEXT
and added HRD compliance flag -
Removed
useInitialRcQp
andinitialRcQp
members ofVkVideoEncodeH265RateControlLayerInfoEXT
-
Added
prefersGopRemainingFrames
andrequiresGopRemainingFrames
, and the newVkVideoEncodeH265GopRemainingFrameInfoEXT
structure to allow specifying remaining frames of each type in the rate control GOP -
Renamed
maxSubLayersCount
capability tomaxSubLayerCount
-
Added
maxQp
, andminQp
capabilities -
Added
maxLevelIdc
capability and newVkVideoEncodeH265SessionCreateInfoEXT
structure to specify upper bounds on the H.265 level of the produced video bitstream -
Moved capability flags specific to codec syntax restrictions from
VkVideoEncodeH265CapabilityFlagsEXT
to the newVkVideoEncodeH265StdFlagsEXT
which is now included as a separatestdSyntaxFlags
member inVkVideoEncodeH265CapabilitiesEXT
-
Added
std
prefix to codec syntax capabilities inVkVideoEncodeH265CapabilitiesEXT
-
Removed
VkVideoEncodeH265NaluSliceSegmentInfoEXT::ctbCount
andVK_VIDEO_ENCODE_H265_CAPABILITY_SLICE_SEGMENT_CTB_COUNT_BIT_EXT
-
Replaced
VK_VIDEO_ENCODE_H265_CAPABILITY_MULTIPLE_SLICE_SEGMENTS_PER_FRAME_BIT_EXT
with the newmaxSliceSegmentCount
capability -
Added
maxTiles
capability -
Removed codec syntax min/max capabilities from
VkVideoEncodeH265CapabilitiesEXT
-
Removed capability flag
VK_VIDEO_ENCODE_H265_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
and removedpStdReferenceFinalLists
members from theVkVideoEncodeH265PictureInfoEXT
andVkVideoEncodeH265NaluSliceSegmentInfoEXT
structures as reference lists info is now included inpStdPictureInfo
-
Added capability flag
VK_VIDEO_ENCODE_H265_CAPABILITY_B_FRAME_IN_L0_LIST_BIT_EXT
-
-
Revision 12, 2023-07-19 (Daniel Rakos)
-
Added video std capability flags
VK_VIDEO_ENCODE_H265_STD_SLICE_QP_DELTA_BIT_EXT
andVK_VIDEO_ENCODE_H265_STD_DIFFERENT_SLICE_QP_DELTA_BIT_EXT
-
Fixed optionality of the array members of
VkVideoEncodeH265SessionParametersAddInfoEXT
-
Fixed optionality of
VkVideoEncodeH265RateControlInfoEXT::flags
-
-
Revision 13, 2023-09-04 (Daniel Rakos)
-
Change extension from
EXT
toKHR
-
Extension is no longer provisional
-
-
Revision 14, 2023-12-05 (Daniel Rakos)
-
Condition reference picture setup based on the value of
StdVideoEncodeH265PictureInfo::flags.is_reference
-
VK_KHR_video_encode_queue
- Name String
-
VK_KHR_video_encode_queue
- Extension Type
-
Device extension
- Registered Extension Number
-
300
- Revision
-
12
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_KHR_format_feature_flags2
-
- Contact
-
-
Ahmed Abdelkhalek aabdelkh
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-12-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
Damien Kessler, NVIDIA
-
George Hao, AMD
-
Jake Beju, AMD
-
Peter Fang, AMD
-
Piers Daniell, NVIDIA
-
Srinath Kumarapuram, NVIDIA
-
Thomas J. Meier, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Ravi Chaudhary, NVIDIA
-
Yang Liu, AMD
-
Daniel Rakos, RasterGrid
-
Ping Liu, Intel
-
Aidan Fabius, Core Avionics & Industrial Inc.
-
Lynne Iribarren, Independent
-
Description
This extension builds upon the VK_KHR_video_queue
extension by
adding common APIs specific to video encoding and thus enabling
implementations to expose queue families supporting video encode operations.
More specifically, it adds video encode specific capabilities and a new command buffer command that allows recording video encode operations against a video session.
This extension is to be used in conjunction with other codec specific video encode extensions that enable encoding video sequences of specific video compression standards.
New Structures
-
Extending VkQueryPoolCreateInfo:
-
Extending VkVideoCapabilitiesKHR:
-
Extending VkVideoCodingControlInfoKHR, VkVideoBeginCodingInfoKHR:
-
Extending VkVideoCodingControlInfoKHR, VkVideoSessionParametersCreateInfoKHR:
-
Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:
New Enum Constants
-
VK_KHR_VIDEO_ENCODE_QUEUE_EXTENSION_NAME
-
VK_KHR_VIDEO_ENCODE_QUEUE_SPEC_VERSION
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_VIDEO_ENCODE_READ_BIT_KHR
-
VK_ACCESS_2_VIDEO_ENCODE_WRITE_BIT_KHR
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_VIDEO_ENCODE_DST_BIT_KHR
-
VK_BUFFER_USAGE_VIDEO_ENCODE_SRC_BIT_KHR
-
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_VIDEO_ENCODE_DPB_BIT_KHR
-
VK_FORMAT_FEATURE_VIDEO_ENCODE_INPUT_BIT_KHR
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_VIDEO_ENCODE_DPB_KHR
-
VK_IMAGE_LAYOUT_VIDEO_ENCODE_DST_KHR
-
VK_IMAGE_LAYOUT_VIDEO_ENCODE_SRC_KHR
-
-
Extending VkImageUsageFlagBits:
-
VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR
-
VK_IMAGE_USAGE_VIDEO_ENCODE_DST_BIT_KHR
-
VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_VIDEO_ENCODE_BIT_KHR
-
-
Extending VkQueryResultStatusKHR:
-
VK_QUERY_RESULT_STATUS_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_KHR
-
-
Extending VkQueryType:
-
VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR
-
-
Extending VkQueueFlagBits:
-
VK_QUEUE_VIDEO_ENCODE_BIT_KHR
-
-
Extending VkResult:
-
VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR
-
VK_STRUCTURE_TYPE_QUERY_POOL_VIDEO_ENCODE_FEEDBACK_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUALITY_LEVEL_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_RATE_CONTROL_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_RATE_CONTROL_LAYER_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_PARAMETERS_FEEDBACK_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_PARAMETERS_GET_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_ENCODE_USAGE_INFO_KHR
-
-
Extending VkVideoCodingControlFlagBitsKHR:
-
VK_VIDEO_CODING_CONTROL_ENCODE_QUALITY_LEVEL_BIT_KHR
-
VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR
-
-
Extending VkVideoSessionCreateFlagBitsKHR:
-
VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_PARAMETER_OPTIMIZATIONS_BIT_KHR
-
If VK_KHR_format_feature_flags2 or Version 1.3 is supported:
-
Extending VkFormatFeatureFlagBits2:
-
VK_FORMAT_FEATURE_2_VIDEO_ENCODE_DPB_BIT_KHR
-
VK_FORMAT_FEATURE_2_VIDEO_ENCODE_INPUT_BIT_KHR
-
Version History
-
Revision 1, 2018-07-23 (Ahmed Abdelkhalek)
-
Initial draft
-
-
Revision 1.1, 10/29/2019 (Tony Zlatinski)
-
Updated the reserved spec tokens and renamed VkVideoEncoderKHR to VkVideoSessionKHR
-
-
Revision 1.6, Jan 08 2020 (Tony Zlatinski)
-
API unify with the video_decode_queue spec
-
-
Revision 2, March 29 2021 (Tony Zlatinski)
-
Spec and API updates.
-
-
Revision 3, 2021-09-30 (Jon Leech)
-
Add interaction with
VK_KHR_format_feature_flags2
tovk.xml
-
-
Revision 4, 2022-02-10 (Ahmed Abdelkhalek)
-
Updates to encode capability interface
-
-
Revision 5, 2022-03-31 (Ahmed Abdelkhalek)
-
Remove redundant VkVideoEncodeInfoKHR.codedExtent
-
-
Revision 6, 2022-07-18 (Daniel Rakos)
-
Remove
VkVideoEncodeRateControlFlagBitsKHR
andVkVideoEncodeFlagBitsKHR
as they contain no defined flags for now -
Add
VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR
andVK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_BIT_KHR
to indicate rate control and rate control layer change requests, respectively, in video coding control operations
-
-
Revision 7, 2022-08-12 (Daniel Rakos)
-
Add VkVideoEncodeUsageInfoKHR structure and related flags
-
-
Revision 8, 2023-03-06 (Daniel Rakos)
-
Replace
VK_QUERY_TYPE_VIDEO_ENCODE_BITSTREAM_BUFFER_RANGE_KHR
queries with more genericVK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR
queries that can be extended in the future with more feedback values -
Rename
dstBitstreamBuffer
,dstBitstreamBufferOffset
, anddstBitstreamBufferMaxRange
inVkVideoEncodeInfoKHR
todstBuffer
,dstBufferOffset
, anddstBufferRange
, respectively, for consistency with the naming convention in the video decode extensions -
Change the type of
rateControlLayerCount
andqualityLevelCount
inVkVideoEncodeCapabilitiesKHR
fromuint8_t
touint32_t
and rename them tomaxRateControlLayers
andmaxQualityLevels
, respectively -
Change the type of
averageBitrate
andmaxBitrate
inVkVideoEncodeRateControlLayerInfoKHR`
fromuint32_t
touint64_t
-
Fixed the definition of rate control flag bits and added the new
VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DEFAULT_KHR
constant to indicate implementation-specific automatic rate control -
Change the type of
VkVideoEncodeRateControlInfoKHR::layerCount
fromuint8_t
touint32_t
-
Rename
pLayerConfigs
topLayers
inVkVideoEncodeRateControlInfoKHR
-
-
Revision 9, 2023-03-28 (Daniel Rakos)
-
Removed
VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_BIT_KHR
and the ability to change the state of individual rate control layers -
Added new
VK_VIDEO_ENCODE_FEEDBACK_BITSTREAM_HAS_OVERRIDES_BIT_KHR
flag to video encode feedback queries -
Added new video session create flag
VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_PARAMETER_OPTIMIZATIONS_BIT_KHR
to opt-in to video session and encoding parameter optimizations -
Added the
vkGetEncodedVideoSessionParametersKHR
command to enable retrieving encoded video session parameter data -
Moved
virtualBufferSizeInMs
andinitialVirtualBufferSizeInMs
fromVkVideoEncodeRateControlLayerInfoKHR
toVkVideoEncodeRateControlInfoKHR
-
Added
maxBitrate
capability -
Renamed
inputImageDataFillAlignment
capability toencodeInputPictureGranularity
to better reflect its purpose -
Added new
vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR
command and related structures to enable querying recommended settings for video encode quality levels -
Added
VK_VIDEO_CODING_CONTROL_ENCODE_QUALITY_LEVEL_BIT_KHR
flag andVkVideoEncodeQualityLevelInfoKHR
structure to allow controlling video encode quality level and removedqualityLevel
from the encode operation parameters
-
-
Revision 10, 2023-07-19 (Daniel Rakos)
-
Added
VK_QUERY_RESULT_STATUS_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_KHR
query result status code and the related capability flagVK_VIDEO_ENCODE_CAPABILITY_INSUFFICIENT_BITSTREAM_BUFFER_RANGE_DETECTION_BIT_KHR
-
-
Revision 11, 2023-09-04 (Daniel Rakos)
-
Extension is no longer provisional
-
-
Revision 12, 2023-12-05 (Daniel Rakos)
-
Require the specification of a reconstructed picture in all cases, except when the video session was created with no DPB slots to match shipping implementations
-
Make DPB slot activation behavior codec-specific to continue allowing application control over reference picture setup now that a reconstructed picture is always mandatory
-
VK_KHR_video_maintenance1
- Name String
-
VK_KHR_video_maintenance1
- Extension Type
-
Device extension
- Registered Extension Number
-
516
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Daniel Rakos aqnuep
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-07-27
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
Aidan Fabius, Core Avionics & Industrial Inc.
-
Ping Liu, Intel
-
Lynne Iribarren, Independent
-
Srinath Kumarapuram, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Daniel Rakos, RasterGrid
-
Description
VK_KHR_video_maintenance1
adds a collection of minor video coding
features, none of which would warrant an entire extension of their own.
The new features are as follows:
-
Allow creating buffers that can be used in video coding operations, independent of the used video profile, using the new buffer creation flag
VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR
. -
Allow creating images that can be used as decode output or encode input pictures, independent of the used video profile, using the new image creation flag
VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR
. -
Allow specifying queries used by video coding operations as part of the video coding command parameters, instead of using begin/end query when the video session is created using the new video session creation flag
VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR
.
New Enum Constants
-
VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME
-
VK_KHR_VIDEO_MAINTENANCE_1_SPEC_VERSION
-
Extending VkBufferCreateFlagBits:
-
VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR
-
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_INLINE_QUERY_INFO_KHR
-
-
Extending VkVideoSessionCreateFlagBitsKHR:
-
VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR
-
VK_KHR_video_queue
- Name String
-
VK_KHR_video_queue
- Extension Type
-
Device extension
- Registered Extension Number
-
24
- Revision
-
8
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Tony Zlatinski tzlatinski
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2022-09-29
- IP Status
-
No known IP claims.
- Contributors
-
-
Ahmed Abdelkhalek, AMD
-
George Hao, AMD
-
Jake Beju, AMD
-
Piers Daniell, NVIDIA
-
Srinath Kumarapuram, NVIDIA
-
Tobias Hector, AMD
-
Tony Zlatinski, NVIDIA
-
Daniel Rakos, RasterGrid
-
Description
This extension provides common APIs to enable exposing queue families with support for video codec operations by introducing the following new object types and related functionalities:
-
Video session objects that represent and maintain the state needed to perform video codec operations.
-
Video session parameters objects that act as a container for codec specific parameters.
In addition, it also introduces query commands that allow applications to determine video coding related capabilities, and command buffer commands that enable recording video coding operations against a video session.
This extension is to be used in conjunction with other extensions that enable specific video coding operations.
New Structures
-
Extending VkPhysicalDeviceImageFormatInfo2, VkPhysicalDeviceVideoFormatInfoKHR, VkImageCreateInfo, VkBufferCreateInfo:
-
Extending VkQueryPoolCreateInfo:
-
Extending VkQueueFamilyProperties2:
New Enum Constants
-
VK_KHR_VIDEO_QUEUE_EXTENSION_NAME
-
VK_KHR_VIDEO_QUEUE_SPEC_VERSION
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_VIDEO_SESSION_KHR
-
VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR
-
-
Extending VkQueryResultFlagBits:
-
VK_QUERY_RESULT_WITH_STATUS_BIT_KHR
-
-
Extending VkQueryType:
-
VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR
-
-
Extending VkResult:
-
VK_ERROR_IMAGE_USAGE_NOT_SUPPORTED_KHR
-
VK_ERROR_VIDEO_PICTURE_LAYOUT_NOT_SUPPORTED_KHR
-
VK_ERROR_VIDEO_PROFILE_CODEC_NOT_SUPPORTED_KHR
-
VK_ERROR_VIDEO_PROFILE_FORMAT_NOT_SUPPORTED_KHR
-
VK_ERROR_VIDEO_PROFILE_OPERATION_NOT_SUPPORTED_KHR
-
VK_ERROR_VIDEO_STD_VERSION_NOT_SUPPORTED_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BIND_VIDEO_SESSION_MEMORY_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_FORMAT_INFO_KHR
-
VK_STRUCTURE_TYPE_QUEUE_FAMILY_QUERY_RESULT_STATUS_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_QUEUE_FAMILY_VIDEO_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_BEGIN_CODING_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_CODING_CONTROL_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_END_CODING_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_VIDEO_PICTURE_RESOURCE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_PROFILE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_PROFILE_LIST_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_REFERENCE_SLOT_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_SESSION_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_SESSION_MEMORY_REQUIREMENTS_KHR
-
VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_UPDATE_INFO_KHR
-
Version History
-
Revision 0.1, 2019-11-21 (Tony Zlatinski)
-
Initial draft
-
-
Revision 0.2, 2019-11-27 (Tony Zlatinski)
-
Make vulkan video core common between decode and encode
-
-
Revision 1, March 29 2021 (Tony Zlatinski)
-
Spec and API updates.
-
-
Revision 2, August 1 2021 (Srinath Kumarapuram)
-
Rename
VkVideoCapabilitiesFlagBitsKHR
toVkVideoCapabilityFlagBitsKHR
(along with the names of enumerants it defines) andVkVideoCapabilitiesFlagsKHR
toVkVideoCapabilityFlagsKHR
, following Vulkan naming conventions.
-
-
Revision 3, 2022-03-16 (Ahmed Abdelkhalek)
-
Relocate Std header version reporting/requesting from codec-operation specific extensions to this extension.
-
Make Std header versions codec-operation specific instead of only codec-specific.
-
-
Revision 4, 2022-05-30 (Daniel Rakos)
-
Refactor the video format query APIs and related language
-
Extend VkResult with video-specific error codes
-
-
Revision 5, 2022-08-11 (Daniel Rakos)
-
Add
VkVideoSessionParametersCreateFlagsKHR
-
Remove
VkVideoCodingQualityPresetFlagsKHR
-
Rename
VkQueueFamilyQueryResultStatusProperties2KHR
toVkQueueFamilyQueryResultStatusPropertiesKHR
-
Rename
VkVideoQueueFamilyProperties2KHR
toVkQueueFamilyVideoPropertiesKHR
-
Rename
VkVideoProfileKHR
toVkVideoProfileInfoKHR
-
Rename
VkVideoProfilesKHR
toVkVideoProfileListInfoKHR
-
Rename
VkVideoGetMemoryPropertiesKHR
toVkVideoSessionMemoryRequirementsKHR
-
Rename
VkVideoBindMemoryKHR
toVkBindVideoSessionMemoryInfoKHR
-
Fix
pNext
constness ofVkPhysicalDeviceVideoFormatInfoKHR
andVkVideoSessionMemoryRequirementsKHR
-
Fix incorrectly named value enums in bit enum types
VkVideoCodecOperationFlagBitsKHR
andVkVideoChromaSubsamplingFlagBitsKHR
-
Remove unnecessary default values from
VkVideoSessionCreateFlagBitsKHR
andVkVideoCodingControlFlagBitsKHR
-
Eliminate nested pointer in
VkVideoSessionMemoryRequirementsKHR
-
Rename
VkVideoPictureResourceKHR
toVkVideoPictureResourceInfoKHR
-
Rename
VkVideoReferenceSlotKHR
toVkVideoReferenceSlotInfoKHR
-
-
Revision 6, 2022-09-18 (Daniel Rakos)
-
Rename the
maxReferencePicturesSlotsCount
andmaxReferencePicturesActiveCount
fields ofVkVideoCapabilitiesKHR
andVkVideoSessionCreateInfoKHR
tomaxDpbSlots
andmaxActiveReferencePictures
, respectively, to clarify their meaning -
Rename
capabilityFlags
toflags
inVkVideoCapabilitiesKHR
-
Rename
videoPictureExtentGranularity
topictureAccessGranularity
inVkVideoCapabilitiesKHR
-
Rename
minExtent
andmaxExtent
tominCodedExtent
andmaxCodedExtent
, respectively, inVkVideoCapabilitiesKHR
-
Rename
referencePicturesFormat
toreferencePictureFormat
inVkVideoSessionCreateInfoKHR
-
-
Revision 7, 2022-09-26 (Daniel Rakos)
-
Change type of
VkVideoReferenceSlotInfoKHR::slotIndex
fromint8_t
toint32_t
-
-
Revision 8, 2022-09-29 (Daniel Rakos)
-
Extension is no longer provisional
-
VK_KHR_wayland_surface
- Name String
-
VK_KHR_wayland_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
7
- Revision
-
6
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2015-11-28
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Faith Ekstrand, Intel
-
Ian Elliott, LunarG
-
Courtney Goeltzenleuchter, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Antoine Labour, Google
-
Jon Leech, Khronos
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Ray Smith, ARM
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Description
The VK_KHR_wayland_surface
extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface
extension) that refers to a Wayland
wl_surface
, as well as a query to determine support for rendering to a
Wayland compositor.
New Enum Constants
-
VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME
-
VK_KHR_WAYLAND_SURFACE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR
-
Issues
1) Does Wayland need a way to query for compatibility between a particular
physical device and a specific Wayland display? This would be a more general
query than vkGetPhysicalDeviceSurfaceSupportKHR: if the
Wayland-specific query returned VK_TRUE
for a (VkPhysicalDevice,
struct wl_display*
) pair, then the physical device could be assumed to
support presentation to any VkSurfaceKHR for surfaces on the display.
RESOLVED: Yes. vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address this issue.
2) Should we require surfaces created with vkCreateWaylandSurfaceKHR
to support the VK_PRESENT_MODE_MAILBOX_KHR
present mode?
RESOLVED: Yes.
Wayland is an inherently mailbox window system and mailbox support is
required for some Wayland compositor interactions to work as expected.
While handling these interactions may be possible with
VK_PRESENT_MODE_FIFO_KHR
, it is much more difficult to do without
deadlock and requiring all Wayland applications to be able to support
implementations which only support VK_PRESENT_MODE_FIFO_KHR
would be
an onerous restriction on application developers.
Version History
-
Revision 1, 2015-09-23 (Jesse Hall)
-
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).
-
-
Revision 2, 2015-10-02 (James Jones)
-
Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve issue #1.
-
Adjusted wording of issue #1 to match the agreed-upon solution.
-
Renamed “window” parameters to “surface” to match Wayland conventions.
-
-
Revision 3, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface.
-
-
Revision 4, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to vkCreateWaylandSurfaceKHR.
-
-
Revision 5, 2015-11-28 (Daniel Rakos)
-
Updated the surface create function to take a pCreateInfo structure.
-
-
Revision 6, 2017-02-08 (Faith Ekstrand)
-
Added the requirement that implementations support
VK_PRESENT_MODE_MAILBOX_KHR
. -
Added wording about interactions between vkQueuePresentKHR and the Wayland requests sent to the compositor.
-
VK_KHR_win32_keyed_mutex
- Name String
-
VK_KHR_win32_keyed_mutex
- Extension Type
-
Device extension
- Registered Extension Number
-
76
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Carsten Rohde crohde
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Carsten Rohde, NVIDIA
-
Description
Applications that wish to import Direct3D 11 memory objects into the Vulkan API may wish to use the native keyed mutex mechanism to synchronize access to the memory between Vulkan and Direct3D. This extension provides a way for an application to access the keyed mutex associated with an imported Vulkan memory object when submitting command buffers to a queue.
New Enum Constants
-
VK_KHR_WIN32_KEYED_MUTEX_EXTENSION_NAME
-
VK_KHR_WIN32_KEYED_MUTEX_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_KHR
-
VK_KHR_win32_surface
- Name String
-
VK_KHR_win32_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
10
- Revision
-
6
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2017-04-24
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Faith Ekstrand, Intel
-
Ian Elliott, LunarG
-
Courtney Goeltzenleuchter, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Antoine Labour, Google
-
Jon Leech, Khronos
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Ray Smith, ARM
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Description
The VK_KHR_win32_surface
extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface
extension) that refers to a Win32 HWND
, as
well as a query to determine support for rendering to the windows desktop.
New Enum Constants
-
VK_KHR_WIN32_SURFACE_EXTENSION_NAME
-
VK_KHR_WIN32_SURFACE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR
-
Issues
1) Does Win32 need a way to query for compatibility between a particular physical device and a specific screen? Compatibility between a physical device and a window generally only depends on what screen the window is on. However, there is not an obvious way to identify a screen without already having a window on the screen.
RESOLVED: No. While it may be useful, there is not a clear way to do this on Win32. However, a method was added to query support for presenting to the windows desktop as a whole.
2) If a native window object (HWND
) is used by one graphics API, and
then is later used by a different graphics API (one of which is Vulkan), can
these uses interfere with each other?
RESOLVED: Yes.
Uses of a window object by multiple graphics APIs results in undefined behavior. Such behavior may succeed when using one Vulkan implementation but fail when using a different Vulkan implementation. Potential failures include:
-
Creating then destroying a flip presentation model DXGI swapchain on a window object can prevent vkCreateSwapchainKHR from succeeding on the same window object.
-
Creating then destroying a VkSwapchainKHR on a window object can prevent creation of a bitblt model DXGI swapchain on the same window object.
-
Creating then destroying a VkSwapchainKHR on a window object can effectively
SetPixelFormat
to a different format than the format chosen by an OpenGL application. -
Creating then destroying a VkSwapchainKHR on a window object on one VkPhysicalDevice can prevent vkCreateSwapchainKHR from succeeding on the same window object, but on a different VkPhysicalDevice that is associated with a different Vulkan ICD.
In all cases the problem can be worked around by creating a new window object.
Technical details include:
-
Creating a DXGI swapchain over a window object can alter the object for the remainder of its lifetime. The alteration persists even after the DXGI swapchain has been destroyed. This alteration can make it impossible for a conformant Vulkan implementation to create a VkSwapchainKHR over the same window object. Mention of this alteration can be found in the remarks section of the MSDN documentation for
DXGI_SWAP_EFFECT
. -
Calling GDI’s
SetPixelFormat
(needed by OpenGL’s WGL layer) on a window object alters the object for the remainder of its lifetime. The MSDN documentation forSetPixelFormat
explains that a window object’s pixel format can be set only one time. -
Creating a VkSwapchainKHR over a window object can alter the object for its remaining lifetime. Either of the above alterations may occur as a side effect of vkCreateSwapchainKHR.
Version History
-
Revision 1, 2015-09-23 (Jesse Hall)
-
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).
-
-
Revision 2, 2015-10-02 (James Jones)
-
Added presentation support query for win32 desktops.
-
-
Revision 3, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_win32_surface to VK_KHR_win32_surface.
-
-
Revision 4, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to vkCreateWin32SurfaceKHR.
-
-
Revision 5, 2015-11-28 (Daniel Rakos)
-
Updated the surface create function to take a pCreateInfo structure.
-
-
Revision 6, 2017-04-24 (Jeff Juliano)
-
Add issue 2 addressing reuse of a native window object in a different Graphics API, or by a different Vulkan ICD.
-
VK_KHR_workgroup_memory_explicit_layout
- Name String
-
VK_KHR_workgroup_memory_explicit_layout
- Extension Type
-
Device extension
- Registered Extension Number
-
337
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Caio Marcelo de Oliveira Filho cmarcelo
-
Other Extension Metadata
- Last Modified Date
-
2020-06-01
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_shared_memory_block
-
- Contributors
-
-
Caio Marcelo de Oliveira Filho, Intel
-
Jeff Bolz, NVIDIA
-
Graeme Leese, Broadcom
-
Faith Ekstrand, Intel
-
Daniel Koch, NVIDIA
-
Description
This extension adds Vulkan support for the
SPV_KHR_workgroup_memory_explicit_layout
SPIR-V extension, which allows shaders to explicitly define the layout of
Workgroup
storage class memory and create aliases between variables
from that storage class in a compute shader.
The aliasing feature allows different “views” on the same data, so the shader can bulk copy data from another storage class using one type (e.g. an array of large vectors), and then use the data with a more specific type. It also enables reducing the amount of workgroup memory consumed by allowing the shader to alias data whose lifetimes do not overlap.
The explicit layout support and some form of aliasing is also required for layering OpenCL on top of Vulkan.
New Enum Constants
-
VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_EXTENSION_NAME
-
VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_FEATURES_KHR
-
VK_KHR_xcb_surface
- Name String
-
VK_KHR_xcb_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
6
- Revision
-
6
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2015-11-28
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Faith Ekstrand, Intel
-
Ian Elliott, LunarG
-
Courtney Goeltzenleuchter, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Antoine Labour, Google
-
Jon Leech, Khronos
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Ray Smith, ARM
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Description
The VK_KHR_xcb_surface
extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface
extension) that refers to an X11 Window
,
using the XCB client-side library, as well as a query to determine support
for rendering via XCB.
New Enum Constants
-
VK_KHR_XCB_SURFACE_EXTENSION_NAME
-
VK_KHR_XCB_SURFACE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR
-
Issues
1) Does XCB need a way to query for compatibility between a particular
physical device and a specific screen? This would be a more general query
than vkGetPhysicalDeviceSurfaceSupportKHR: If it returned
VK_TRUE
, then the physical device could be assumed to support
presentation to any window on that screen.
RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.
Version History
-
Revision 1, 2015-09-23 (Jesse Hall)
-
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).
-
-
Revision 2, 2015-10-02 (James Jones)
-
Added presentation support query for an (xcb_connection_t*, xcb_visualid_t) pair.
-
Removed “root” parameter from CreateXcbSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.
-
Adjusted wording of issue #1 and added agreed upon resolution.
-
-
Revision 3, 2015-10-14 (Ian Elliott)
-
Removed “root” parameter from CreateXcbSurfaceKHR() in one more place.
-
-
Revision 4, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_xcb_surface to VK_KHR_xcb_surface.
-
-
Revision 5, 2015-10-23 (Daniel Rakos)
-
Added allocation callbacks to vkCreateXcbSurfaceKHR.
-
-
Revision 6, 2015-11-28 (Daniel Rakos)
-
Updated the surface create function to take a pCreateInfo structure.
-
VK_KHR_xlib_surface
- Name String
-
VK_KHR_xlib_surface
- Extension Type
-
Instance extension
- Registered Extension Number
-
5
- Revision
-
6
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Jesse Hall critsec
-
Ian Elliott ianelliottus
-
Other Extension Metadata
- Last Modified Date
-
2015-11-28
- IP Status
-
No known IP claims.
- Contributors
-
-
Patrick Doane, Blizzard
-
Faith Ekstrand, Intel
-
Ian Elliott, LunarG
-
Courtney Goeltzenleuchter, LunarG
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Antoine Labour, Google
-
Jon Leech, Khronos
-
David Mao, AMD
-
Norbert Nopper, Freescale
-
Alon Or-bach, Samsung
-
Daniel Rakos, AMD
-
Graham Sellers, AMD
-
Ray Smith, ARM
-
Jeff Vigil, Qualcomm
-
Chia-I Wu, LunarG
-
Description
The VK_KHR_xlib_surface
extension is an instance extension.
It provides a mechanism to create a VkSurfaceKHR object (defined by
the VK_KHR_surface
extension) that refers to an X11 Window
,
using the Xlib client-side library, as well as a query to determine support
for rendering via Xlib.
New Enum Constants
-
VK_KHR_XLIB_SURFACE_EXTENSION_NAME
-
VK_KHR_XLIB_SURFACE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR
-
Issues
1) Does X11 need a way to query for compatibility between a particular
physical device and a specific screen? This would be a more general query
than vkGetPhysicalDeviceSurfaceSupportKHR; if it returned
VK_TRUE
, then the physical device could be assumed to support
presentation to any window on that screen.
RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.
Version History
-
Revision 1, 2015-09-23 (Jesse Hall)
-
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).
-
-
Revision 2, 2015-10-02 (James Jones)
-
Added presentation support query for (Display*, VisualID) pair.
-
Removed “root” parameter from CreateXlibSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.
-
Added appropriate X errors.
-
Adjusted wording of issue #1 and added agreed upon resolution.
-
-
Revision 3, 2015-10-14 (Ian Elliott)
-
Renamed this extension from VK_EXT_KHR_x11_surface to VK_EXT_KHR_xlib_surface.
-
-
Revision 4, 2015-10-26 (Ian Elliott)
-
Renamed from VK_EXT_KHR_xlib_surface to VK_KHR_xlib_surface.
-
-
Revision 5, 2015-11-03 (Daniel Rakos)
-
Added allocation callbacks to vkCreateXlibSurfaceKHR.
-
-
Revision 6, 2015-11-28 (Daniel Rakos)
-
Updated the surface create function to take a pCreateInfo structure.
-
VK_EXT_attachment_feedback_loop_dynamic_state
- Name String
-
VK_EXT_attachment_feedback_loop_dynamic_state
- Extension Type
-
Device extension
- Registered Extension Number
-
525
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Mike Blumenkrantz zmike
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-04-28
- IP Status
-
No known IP claims.
- Contributors
-
-
Mike Blumenkrantz, Valve
-
Daniel Story, Nintendo
-
Stu Smith, AMD
-
Samuel Pitoiset, Valve
-
Ricardo Garcia, Igalia
-
Description
This extension adds support for setting attachment feedback loops dynamically on command buffers.
New Enum Constants
-
VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_EXTENSION_NAME
-
VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_SPEC_VERSION
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_ATTACHMENT_FEEDBACK_LOOP_ENABLE_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_FEATURES_EXT
-
VK_EXT_attachment_feedback_loop_layout
- Name String
-
VK_EXT_attachment_feedback_loop_layout
- Extension Type
-
Device extension
- Registered Extension Number
-
340
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Joshua Ashton Joshua-Ashton
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2022-04-04
- IP Status
-
No known IP claims.
- Contributors
-
-
Joshua Ashton, Valve
-
Faith Ekstrand, Collabora
-
Bas Nieuwenhuizen, Google
-
Samuel Iglesias Gonsálvez, Igalia
-
Ralph Potter, Samsung
-
Jan-Harald Fredriksen, Arm
-
Ricardo Garcia, Igalia
-
Description
This extension adds a new image layout,
VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT
, which allows
applications to have an image layout in which they are able to both render
to and sample/fetch from the same subresource of an image in a given render
pass.
New Enum Constants
-
VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_EXTENSION_NAME
-
VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_SPEC_VERSION
-
Extending VkDependencyFlagBits:
-
VK_DEPENDENCY_FEEDBACK_LOOP_BIT_EXT
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT
-
-
Extending VkImageUsageFlagBits:
-
VK_IMAGE_USAGE_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
-
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
-
VK_PIPELINE_CREATE_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_FEATURES_EXT
-
VK_EXT_depth_bias_control
- Name String
-
VK_EXT_depth_bias_control
- Extension Type
-
Device extension
- Registered Extension Number
-
284
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Special Use
- Contact
-
-
Joshua Ashton Joshua-Ashton
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-02-15
- IP Status
-
No known IP claims.
- Contributors
-
-
Joshua Ashton, VALVE
-
Hans-Kristian Arntzen, VALVE
-
Mike Blumenkrantz, VALVE
-
Georg Lehmann, VALVE
-
Piers Daniell, NVIDIA
-
Lionel Landwerlin, INTEL
-
Tobias Hector, AMD
-
Ricardo Garcia, IGALIA
-
Jan-Harald Fredriksen, ARM
-
Shahbaz Youssefi, GOOGLE
-
Tom Olson, ARM
-
Description
This extension adds a new structure, VkDepthBiasRepresentationInfoEXT
,
that can be added to a pNext
chain of
VkPipelineRasterizationStateCreateInfo
and allows setting the scaling
and representation of depth bias for a pipeline.
This state can also be set dynamically by using the new structure mentioned
above in combination with the new vkCmdSetDepthBias2EXT
command.
New Enum Constants
-
VK_EXT_DEPTH_BIAS_CONTROL_EXTENSION_NAME
-
VK_EXT_DEPTH_BIAS_CONTROL_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEPTH_BIAS_INFO_EXT
-
VK_STRUCTURE_TYPE_DEPTH_BIAS_REPRESENTATION_INFO_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_BIAS_CONTROL_FEATURES_EXT
-
VK_EXT_depth_clip_enable
- Name String
-
VK_EXT_depth_clip_enable
- Extension Type
-
Device extension
- Registered Extension Number
-
103
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Special Use
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2018-12-20
- Contributors
-
-
Daniel Rakos, AMD
-
Henri Verbeet, CodeWeavers
-
Jeff Bolz, NVIDIA
-
Philip Rebohle, DXVK
-
Tobias Hector, AMD
-
Description
This extension allows the depth clipping operation, that is normally
implicitly controlled by
VkPipelineRasterizationStateCreateInfo::depthClampEnable
, to
instead be controlled explicitly by
VkPipelineRasterizationDepthClipStateCreateInfoEXT::depthClipEnable
.
This is useful for translating DX content which assumes depth clamping is always enabled, but depth clip can be controlled by the DepthClipEnable rasterization state (D3D12_RASTERIZER_DESC).
New Enum Constants
-
VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME
-
VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT
-
VK_EXT_depth_range_unrestricted
- Name String
-
VK_EXT_depth_range_unrestricted
- Extension Type
-
Device extension
- Registered Extension Number
-
14
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2017-06-22
- Contributors
-
-
Daniel Koch, NVIDIA
-
Jeff Bolz, NVIDIA
-
Description
This extension removes the VkViewport minDepth
and
maxDepth
restrictions that the values must be between 0.0
and 1.0
,
inclusive.
It also removes the same restriction on
VkPipelineDepthStencilStateCreateInfo minDepthBounds
and
maxDepthBounds
.
Finally it removes the restriction on the depth
value in
VkClearDepthStencilValue.
New Enum Constants
-
VK_EXT_DEPTH_RANGE_UNRESTRICTED_EXTENSION_NAME
-
VK_EXT_DEPTH_RANGE_UNRESTRICTED_SPEC_VERSION
Issues
1) How do VkViewport minDepth
and maxDepth
values outside
of the 0.0
to 1.0
range interact with
Primitive Clipping?
RESOLVED: The behavior described in Primitive
Clipping still applies.
If depth clamping is disabled the depth values are still clipped to 0
≤ zc ≤ wc before the viewport transform.
If depth clamping is enabled the above equation is ignored and the depth
values are instead clamped to the VkViewport minDepth
and
maxDepth
values, which in the case of this extension can be outside of
the 0.0
to 1.0
range.
2) What happens if a resulting depth fragment is outside of the 0.0
to
1.0
range and the depth buffer is fixed-point rather than floating-point?
RESOLVED: This situation can also arise without this extension (when fragment shaders replace depth values, for example), and this extension does not change the behavior, which is defined in the Depth Test section of the Fragment Operations chapter.
VK_EXT_discard_rectangles
- Name String
-
VK_EXT_discard_rectangles
- Extension Type
-
Device extension
- Registered Extension Number
-
100
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2023-01-18
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_device_group
-
Interacts with Vulkan 1.1
-
- Contributors
-
-
Daniel Koch, NVIDIA
-
Jeff Bolz, NVIDIA
-
Description
This extension provides additional orthogonally aligned “discard rectangles” specified in framebuffer-space coordinates that restrict rasterization of all points, lines and triangles.
From zero to an implementation-dependent limit (specified by
maxDiscardRectangles
) number of discard rectangles can be operational
at once.
When one or more discard rectangles are active, rasterized fragments can
either survive if the fragment is within any of the operational discard
rectangles (VK_DISCARD_RECTANGLE_MODE_INCLUSIVE_EXT
mode) or be
rejected if the fragment is within any of the operational discard rectangles
(VK_DISCARD_RECTANGLE_MODE_EXCLUSIVE_EXT
mode).
These discard rectangles operate orthogonally to the existing scissor test functionality. The discard rectangles can be different for each physical device in a device group by specifying the device mask and setting discard rectangle dynamic state.
Version 2 of this extension introduces new dynamic states
VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT
and
VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT
, and the corresponding
functions vkCmdSetDiscardRectangleEnableEXT and
vkCmdSetDiscardRectangleModeEXT.
Applications that use these dynamic states must ensure the implementation
advertises at least specVersion
2
of this extension.
New Enum Constants
-
VK_EXT_DISCARD_RECTANGLES_EXTENSION_NAME
-
VK_EXT_DISCARD_RECTANGLES_SPEC_VERSION
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT
-
VK_DYNAMIC_STATE_DISCARD_RECTANGLE_EXT
-
VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISCARD_RECTANGLE_PROPERTIES_EXT
-
VK_STRUCTURE_TYPE_PIPELINE_DISCARD_RECTANGLE_STATE_CREATE_INFO_EXT
-
VK_EXT_dynamic_rendering_unused_attachments
- Name String
-
VK_EXT_dynamic_rendering_unused_attachments
- Extension Type
-
Device extension
- Registered Extension Number
-
500
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Piers Daniell pdaniell-nv
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-05-22
- IP Status
-
No known IP claims.
- Contributors
-
-
Daniel Story, Nintendo
-
Hans-Kristian Arntzen, Valve
-
Jan-Harald Fredriksen, Arm
-
James Fitzpatrick, Imagination Technologies
-
Pan Gao, Huawei Technologies
-
Ricardo Garcia, Igalia
-
Stu Smith, AMD
-
Description
This extension lifts some restrictions in the
VK_KHR_dynamic_rendering
extension to allow render pass instances
and bound pipelines within those render pass instances to have an unused
attachment specified in one but not the other.
It also allows pipelines to use different formats in a render pass as long
the attachment is NULL.
New Enum Constants
-
VK_EXT_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_EXTENSION_NAME
-
VK_EXT_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_UNUSED_ATTACHMENTS_FEATURES_EXT
-
VK_EXT_extended_dynamic_state3
- Name String
-
VK_EXT_extended_dynamic_state3
- Extension Type
-
Device extension
- Registered Extension Number
-
456
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_1
-
Interacts with VK_EXT_blend_operation_advanced
-
Interacts with VK_EXT_conservative_rasterization
-
Interacts with VK_EXT_depth_clip_control
-
Interacts with VK_EXT_depth_clip_enable
-
Interacts with VK_EXT_line_rasterization
-
Interacts with VK_EXT_provoking_vertex
-
Interacts with VK_EXT_sample_locations
-
Interacts with VK_EXT_transform_feedback
-
Interacts with VK_KHR_maintenance2
-
Interacts with VK_NV_clip_space_w_scaling
-
Interacts with VK_NV_coverage_reduction_mode
-
Interacts with VK_NV_fragment_coverage_to_color
-
Interacts with VK_NV_framebuffer_mixed_samples
-
Interacts with VK_NV_representative_fragment_test
-
Interacts with VK_NV_shading_rate_image
-
Interacts with VK_NV_viewport_swizzle
-
- Contact
-
-
Piers Daniell pdaniell-nv
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2022-09-02
- IP Status
-
No known IP claims.
- Contributors
-
-
Daniel Story, Nintendo
-
Jamie Madill, Google
-
Jan-Harald Fredriksen, Arm
-
Faith Ekstrand, Collabora
-
Mike Blumenkrantz, Valve
-
Ricardo Garcia, Igalia
-
Samuel Pitoiset, Valve
-
Shahbaz Youssefi, Google
-
Stu Smith, AMD
-
Tapani Pälli, Intel
-
Description
This extension adds almost all of the remaining pipeline state as dynamic state to help applications further reduce the number of monolithic pipelines they need to create and bind.
New Commands
If VK_EXT_depth_clip_enable is supported:
If VK_EXT_transform_feedback is supported:
If VK_KHR_maintenance2 or Version 1.1 is supported:
New Enum Constants
-
VK_EXT_EXTENDED_DYNAMIC_STATE_3_EXTENSION_NAME
-
VK_EXT_EXTENDED_DYNAMIC_STATE_3_SPEC_VERSION
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_ALPHA_TO_COVERAGE_ENABLE_EXT
-
VK_DYNAMIC_STATE_ALPHA_TO_ONE_ENABLE_EXT
-
VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT
-
VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT
-
VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT
-
VK_DYNAMIC_STATE_DEPTH_CLAMP_ENABLE_EXT
-
VK_DYNAMIC_STATE_LOGIC_OP_ENABLE_EXT
-
VK_DYNAMIC_STATE_POLYGON_MODE_EXT
-
VK_DYNAMIC_STATE_RASTERIZATION_SAMPLES_EXT
-
VK_DYNAMIC_STATE_SAMPLE_MASK_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_PROPERTIES_EXT
-
If VK_EXT_depth_clip_enable is supported:
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_DEPTH_CLIP_ENABLE_EXT
-
If VK_EXT_transform_feedback is supported:
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_RASTERIZATION_STREAM_EXT
-
If VK_KHR_maintenance2 or Version 1.1 is supported:
-
Extending VkDynamicState:
-
VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT
-
Issues
1) What about the VkPipelineMultisampleStateCreateInfo state
sampleShadingEnable
and minSampleShading
?
- UNRESOLVED
-
-
sampleShadingEnable
andminSampleShading
are required when compiling the fragment shader, and it is not meaningful to set them dynamically since they always need to match the fragment shader state, so this hardware state may as well just come from the pipeline with the fragment shader.
-
VK_EXT_external_memory_acquire_unmodified
- Name String
-
VK_EXT_external_memory_acquire_unmodified
- Extension Type
-
Device extension
- Registered Extension Number
-
454
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Lina Versace versalinyaa
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-03-09
- Contributors
-
-
Lina Versace, Google
-
Chia-I Wu, Google
-
James Jones, NVIDIA
-
Yiwei Zhang, Google
-
Description
A memory barrier may have a performance penalty when acquiring ownership of a subresource range from an external queue family. This extension provides API that may reduce the performance penalty if ownership of the subresource range was previously released to the external queue family and if the resource’s memory has remained unmodified between the release and acquire operations.
New Enum Constants
-
VK_EXT_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_EXTENSION_NAME
-
VK_EXT_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_ACQUIRE_UNMODIFIED_EXT
-
VK_EXT_frame_boundary
- Name String
-
VK_EXT_frame_boundary
- Extension Type
-
Device extension
- Registered Extension Number
-
376
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
James Fitzpatrick jamesfitzpatrick
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-06-14
- Contributors
-
-
James Fitzpatrick, Imagination Technologies
-
Hugues Evrard, Google
-
Melih Yasin Yalcin, Google
-
Andrew Garrard, Imagination Technologies
-
Jan-Harald Fredriksen, Arm
-
Vassili Nikolaev, NVIDIA
-
Ting Wei, Huawei
-
Description
VK_EXT_frame_boundary is a device extension that helps tools (such as debuggers) to group queue submissions per frames in non-trivial scenarios, typically when vkQueuePresentKHR is not a relevant frame boundary delimiter.
New Enum Constants
-
VK_EXT_FRAME_BOUNDARY_EXTENSION_NAME
-
VK_EXT_FRAME_BOUNDARY_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FRAME_BOUNDARY_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAME_BOUNDARY_FEATURES_EXT
-
VK_EXT_hdr_metadata
- Name String
-
VK_EXT_hdr_metadata
- Extension Type
-
Device extension
- Registered Extension Number
-
106
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Courtney Goeltzenleuchter courtney-g
-
Other Extension Metadata
- Last Modified Date
-
2018-12-19
- IP Status
-
No known IP claims.
- Contributors
-
-
Courtney Goeltzenleuchter, Google
-
Description
This extension defines two new structures and a function to assign SMPTE
(the Society of Motion Picture and Television Engineers) 2086 metadata and
CTA (Consumer Technology Association) 861.3 metadata to a swapchain.
The metadata includes the color primaries, white point, and luminance range
of the reference monitor, which all together define the color volume
containing all the possible colors the reference monitor can produce.
The reference monitor is the display where creative work is done and
creative intent is established.
To preserve such creative intent as much as possible and achieve consistent
color reproduction on different viewing displays, it is useful for the
display pipeline to know the color volume of the original reference monitor
where content was created or tuned.
This avoids performing unnecessary mapping of colors that are not
displayable on the original reference monitor.
The metadata also includes the maxContentLightLevel
and
maxFrameAverageLightLevel
as defined by CTA 861.3.
While the intended purpose of the metadata is to assist in the transformation between different color volumes of different displays and help achieve better color reproduction, it is not in the scope of this extension to define how exactly the metadata should be used in such a process. It is up to the implementation to determine how to make use of the metadata.
New Enum Constants
-
VK_EXT_HDR_METADATA_EXTENSION_NAME
-
VK_EXT_HDR_METADATA_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_HDR_METADATA_EXT
-
VK_EXT_host_image_copy
- Name String
-
VK_EXT_host_image_copy
- Extension Type
-
Device extension
- Registered Extension Number
-
271
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Shahbaz Youssefi syoussefi
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-04-26
- Contributors
-
-
Shahbaz Youssefi, Google
-
Faith Ekstrand, Collabora
-
Hans-Kristian Arntzen, Valve
-
Piers Daniell, NVIDIA
-
Jan-Harald Fredriksen, Arm
-
James Fitzpatrick, Imagination
-
Daniel Story, Nintendo
-
Description
This extension allows applications to copy data between host memory and images on the host processor, without staging the data through a GPU-accessible buffer. This removes the need to allocate and manage the buffer and its associated memory. On some architectures it may also eliminate an extra copy operation. This extension additionally allows applications to copy data between images on the host.
To support initializing a new image in preparation for a host copy, it is
now possible to transition a new image to VK_IMAGE_LAYOUT_GENERAL
or
other host-copyable layouts via vkTransitionImageLayoutEXT.
Additionally, it is possible to perform copies that preserve the swizzling
layout of the image by using the VK_HOST_IMAGE_COPY_MEMCPY_EXT
flag.
In that case, the memory size needed for copies to or from a buffer can be
retrieved by chaining VkSubresourceHostMemcpySizeEXT to pLayout
in vkGetImageSubresourceLayout2EXT.
New Structures
-
Extending VkImageFormatProperties2:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkSubresourceLayout2KHR:
New Enum Constants
-
VK_EXT_HOST_IMAGE_COPY_EXTENSION_NAME
-
VK_EXT_HOST_IMAGE_COPY_SPEC_VERSION
-
Extending VkFormatFeatureFlagBits2:
-
VK_FORMAT_FEATURE_2_HOST_IMAGE_TRANSFER_BIT_EXT
-
-
Extending VkImageUsageFlagBits:
-
VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_COPY_IMAGE_TO_IMAGE_INFO_EXT
-
VK_STRUCTURE_TYPE_COPY_IMAGE_TO_MEMORY_INFO_EXT
-
VK_STRUCTURE_TYPE_COPY_MEMORY_TO_IMAGE_INFO_EXT
-
VK_STRUCTURE_TYPE_HOST_IMAGE_COPY_DEVICE_PERFORMANCE_QUERY_EXT
-
VK_STRUCTURE_TYPE_HOST_IMAGE_LAYOUT_TRANSITION_INFO_EXT
-
VK_STRUCTURE_TYPE_IMAGE_TO_MEMORY_COPY_EXT
-
VK_STRUCTURE_TYPE_MEMORY_TO_IMAGE_COPY_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_PROPERTIES_EXT
-
VK_STRUCTURE_TYPE_SUBRESOURCE_HOST_MEMCPY_SIZE_EXT
-
Issues
1) When uploading data to an image, the data is usually loaded from disk.
Why not have the application load the data directly into a VkDeviceMemory
bound to a buffer (instead of host memory), and use
vkCmdCopyBufferToImage? The same could be done when downloading data
from an image.
RESOLVED: This may not always be possible. Complicated Vulkan applications such as game engines often have decoupled subsystems for streaming data and rendering. It may be unreasonable to require the streaming subsystem to coordinate with the rendering subsystem to allocate memory on its behalf, especially as Vulkan may not be the only API supported by the engine. In emulation layers, the image data is necessarily provided by the application in host memory, so an optimization as suggested is not possible. Most importantly, the device memory may not be mappable by an application, but still accessible to the driver.
2) Are optimalBufferCopyOffsetAlignment
and
optimalBufferCopyRowPitchAlignment
applicable to host memory as well with
the functions introduced by this extension? Or should there be new limits?
RESOLVED: No alignment requirements for the host memory pointer.
3) Should there be granularity requirements for image offsets and extents?
RESOLVED: No granularity requirements, i.e. a granularity of 1 pixel (for non-compressed formats) and 1 texel block (for compressed formats) is assumed.
4) How should the application deal with layout transitions before or after copying to or from images?
RESOLVED: An existing issue with linear images is that when emulating other APIs, it is impossible to know when to transition them as they are written to by the host and then used bindlessly. The copy operations in this extension are affected by the same limitation. A new command is thus introduced by this extension to address this problem by allowing the host to perform an image layout transition between a handful of layouts.
VK_EXT_layer_settings
- Name String
-
VK_EXT_layer_settings
- Extension Type
-
Instance extension
- Registered Extension Number
-
497
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Contact
-
-
Christophe Riccio christophe
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-09-23
- IP Status
-
No known IP claims.
- Contributors
-
-
Christophe Riccio, LunarG
-
Mark Lobodzinski, LunarG
-
Charles Giessen, LunarG
-
Spencer Fricke, LunarG
-
Juan Ramos, LunarG
-
Daniel Rakos, RasterGrid
-
Shahbaz Youssefi, Google
-
Lina Versace, Google
-
Bill Hollings, The Brenwill Workshop
-
Jon Leech, Khronos
-
Tom Olson, Arm
-
Description
This extension provides a mechanism for configuring programmatically through the Vulkan API the behavior of layers.
This extension provides the VkLayerSettingsCreateInfoEXT struct that
can be included in the pNext
chain of the VkInstanceCreateInfo
structure passed as the pCreateInfo
parameter of
vkCreateInstance.
The structure contains an array of VkLayerSettingEXT structure values that configure specific features of layers.
Example
VK_EXT_layer_settings
is implemented by the Vulkan Profiles layer.
It allows the profiles layer tests used by the profiles layer C.I. to programmatically configure the layer for each test without affecting the C.I. environment, allowing to run multiple tests concurrently.
const char* profile_file_data = JSON_TEST_FILES_PATH "VP_KHR_roadmap_2022.json";
const char* profile_name_data = "VP_KHR_roadmap_2022";
VkBool32 emulate_portability_data = VK_TRUE;
const char* simulate_capabilities[] = {
"SIMULATE_API_VERSION_BIT",
"SIMULATE_FEATURES_BIT",
"SIMULATE_PROPERTIES_BIT",
"SIMULATE_EXTENSIONS_BIT",
"SIMULATE_FORMATS_BIT",
"SIMULATE_QUEUE_FAMILY_PROPERTIES_BIT"
};
const char* debug_reports[] = {
"DEBUG_REPORT_ERROR_BIT",
"DEBUG_REPORT_WARNING_BIT",
"DEBUG_REPORT_NOTIFICATION_BIT",
"DEBUG_REPORT_DEBUG_BIT"
};
const VkLayerSettingEXT settings[] = {
{kLayerName, kLayerSettingsProfileFile, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_file_data},
{kLayerName, kLayerSettingsProfileName, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_name_data},
{kLayerName, kLayerSettingsEmulatePortability, VK_LAYER_SETTING_TYPE_BOOL32_EXT, 1, &emulate_portability_data},
{kLayerName, kLayerSettingsSimulateCapabilities, VK_LAYER_SETTING_TYPE_STRING_EXT,
static_cast<uint32_t>(std::size(simulate_capabilities)), simulate_capabilities},
{kLayerName, kLayerSettingsDebugReports, VK_LAYER_SETTING_TYPE_STRING_EXT,
static_cast<uint32_t>(std::size(debug_reports)), debug_reports}
};
const VkLayerSettingsCreateInfoEXT layer_settings_create_info{
VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT, nullptr,
static_cast<uint32_t>(std::size(settings)), settings};
VkInstanceCreateInfo inst_create_info = {};
...
inst_create_info.pNext = &layer_settings_create_info;
vkCreateInstance(&inst_create_info, nullptr, &_instances);
Note
The |
New Enum Constants
-
VK_EXT_LAYER_SETTINGS_EXTENSION_NAME
-
VK_EXT_LAYER_SETTINGS_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT
-
VK_EXT_nested_command_buffer
- Name String
-
VK_EXT_nested_command_buffer
- Extension Type
-
Device extension
- Registered Extension Number
-
452
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2023-09-18
- Contributors
-
-
Daniel Story, Nintendo
-
Peter Kohaut, NVIDIA
-
Shahbaz Youssefi, Google
-
Slawomir Grajewski, Intel
-
Stu Smith, AMD
-
Description
With core Vulkan it is not legal to call vkCmdExecuteCommands when recording a secondary command buffer. This extension relaxes that restriction, allowing secondary command buffers to execute other secondary command buffers.
New Enum Constants
-
VK_EXT_NESTED_COMMAND_BUFFER_EXTENSION_NAME
-
VK_EXT_NESTED_COMMAND_BUFFER_SPEC_VERSION
-
Extending VkRenderingFlagBits:
-
VK_RENDERING_CONTENTS_INLINE_BIT_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_PROPERTIES_EXT
-
-
Extending VkSubpassContents:
-
VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_EXT
-
Issues
1) The Command Buffer Levels property for the Vulkan commands comes from the
cmdbufferlevel
attribute in vk.xml
for the command, and it is currently
not possible to modify this attribute based on whether an extension is
enabled.
For this extension we want the cmdbufferlevel
attribute for
vkCmdExecuteCommands to be primary,secondary
when this extension is
enabled and primary
otherwise.
RESOLVED: The cmdbufferlevel
attribute for vkCmdExecuteCommands
has been changed to primary,secondary
and a new VUID added to prohibit
recording this command in a secondary command buffer unless this extension
is enabled.
VK_EXT_opacity_micromap
- Name String
-
VK_EXT_opacity_micromap
- Extension Type
-
Device extension
- Registered Extension Number
-
397
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Christoph Kubisch pixeljetstream
-
Eric Werness
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2022-08-24
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_opacity_micromap
-
- Contributors
-
-
Christoph Kubisch, NVIDIA
-
Eric Werness, NVIDIA
-
Josh Barczak, Intel
-
Stu Smith, AMD
-
Description
When adding transparency to a ray traced scene, an application can choose between further tessellating the geometry or using an any-hit shader to allow the ray through specific parts of the geometry. These options have the downside of either significantly increasing memory consumption or adding runtime overhead to run shader code in the middle of traversal, respectively.
This extension adds the ability to add an opacity micromap to geometry when building an acceleration structure. The opacity micromap compactly encodes opacity information which can be read by the implementation to mark parts of triangles as opaque or transparent. The format is externally visible to allow the application to compress its internal geometry and surface representations into the compressed format ahead of time. The compressed format subdivides each triangle into a set of subtriangles, each of which can be assigned either two or four opacity values. These opacity values can control if a ray hitting that subtriangle is treated as an opaque hit, complete miss, or possible hit, depending on the controls described in Ray Opacity Micromap.
This extension provides:
-
a VkMicromapEXT structure to store the micromap,
-
functions similar to acceleration structure build functions to build the opacity micromap array, and
-
a structure to extend VkAccelerationStructureGeometryTrianglesDataKHR to attach a micromap to the geometry of the acceleration structure.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
New Enum Constants
-
VK_EXT_OPACITY_MICROMAP_EXTENSION_NAME
-
VK_EXT_OPACITY_MICROMAP_SPEC_VERSION
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_MICROMAP_READ_BIT_EXT
-
VK_ACCESS_2_MICROMAP_WRITE_BIT_EXT
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT
-
VK_BUFFER_USAGE_MICROMAP_STORAGE_BIT_EXT
-
-
Extending VkBuildAccelerationStructureFlagBitsKHR:
-
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISABLE_OPACITY_MICROMAPS_EXT
-
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_EXT
-
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_EXT
-
-
Extending VkGeometryInstanceFlagBitsKHR:
-
VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_EXT
-
VK_GEOMETRY_INSTANCE_FORCE_OPACITY_MICROMAP_2_STATE_EXT
-
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_MICROMAP_EXT
-
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT
-
-
Extending VkQueryType:
-
VK_QUERY_TYPE_MICROMAP_COMPACTED_SIZE_EXT
-
VK_QUERY_TYPE_MICROMAP_SERIALIZATION_SIZE_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_OPACITY_MICROMAP_EXT
-
VK_STRUCTURE_TYPE_COPY_MEMORY_TO_MICROMAP_INFO_EXT
-
VK_STRUCTURE_TYPE_COPY_MICROMAP_INFO_EXT
-
VK_STRUCTURE_TYPE_COPY_MICROMAP_TO_MEMORY_INFO_EXT
-
VK_STRUCTURE_TYPE_MICROMAP_BUILD_INFO_EXT
-
VK_STRUCTURE_TYPE_MICROMAP_BUILD_SIZES_INFO_EXT
-
VK_STRUCTURE_TYPE_MICROMAP_CREATE_INFO_EXT
-
VK_STRUCTURE_TYPE_MICROMAP_VERSION_INFO_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_PROPERTIES_EXT
-
Reference Code
uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level)
{
u = clamp(u, 0.0f, 1.0f);
v = clamp(v, 0.0f, 1.0f);
uint32_t iu, iv, iw;
// Quantize barycentric coordinates
float fu = u * (1u << level);
float fv = v * (1u << level);
iu = (uint32_t)fu;
iv = (uint32_t)fv;
float uf = fu - float(iu);
float vf = fv - float(iv);
if (iu >= (1u << level)) iu = (1u << level) - 1u;
if (iv >= (1u << level)) iv = (1u << level) - 1u;
uint32_t iuv = iu + iv;
if (iuv >= (1u << level))
iu -= iuv - (1u << level) + 1u;
iw = ~(iu + iv);
if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw;
uint32_t b0 = ~(iu ^ iw);
b0 &= ((1u << level) - 1u);
uint32_t t = (iu ^ iv) & b0;
uint32_t f = t;
f ^= f >> 1u;
f ^= f >> 2u;
f ^= f >> 4u;
f ^= f >> 8u;
uint32_t b1 = ((f ^ iu) & ~b0) | t;
// Interleave bits
b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu;
b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu;
b0 = (b0 | (b0 << 2u)) & 0x33333333u;
b0 = (b0 | (b0 << 1u)) & 0x55555555u;
b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu;
b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu;
b1 = (b1 | (b1 << 2u)) & 0x33333333u;
b1 = (b1 | (b1 << 1u)) & 0x55555555u;
return b0 | (b1 << 1u);
}
Issues
(1) Is the build actually similar to an acceleration structure build?
-
Resolved: The build should be much lighter-weight than an acceleration structure build, but the infrastructure is similar enough that it makes sense to keep the concepts compatible.
(2) Why does VkMicromapUsageEXT not have type/pNext?
-
Resolved: There can be a very large number of these structures, so doubling the size of these can be significant memory consumption. Also, an application may be loading these directly from a file which is more compatible with it being a flat structure. The including structures are extensible and are probably a more suitable place to add extensibility.
(3) Why is there a SPIR-V extension?
-
Resolved: There is a ray flag. To be consistent with how the existing ray tracing extensions work that ray flag needs its own extension.
(4) Should there be indirect micromap build?
-
Resolved: Not for now. There is more in-depth usage metadata required and it seems less likely that something like a GPU culling system would need to change the counts for a micromap.
(5) Should micromaps have a micromap device address?
-
Resolved: There is no need right now (can just use the handle) but that is a bit different from acceleration structures, though the two are not completely parallel in their usage.
(6) Why are the alignment requirements defined as a mix of hardcoded values and caps?
-
Resolved: This is most parallel with the definition of
VK_KHR_acceleration_structure
and maintaining commonality makes it easier for applications to share memory.
VK_EXT_queue_family_foreign
- Name String
-
VK_EXT_queue_family_foreign
- Extension Type
-
Device extension
- Registered Extension Number
-
127
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Contact
-
-
Lina Versace versalinyaa
-
Other Extension Metadata
- Last Modified Date
-
2017-11-01
- IP Status
-
No known IP claims.
- Contributors
-
-
Lina Versace, Google
-
James Jones, NVIDIA
-
Faith Ekstrand, Intel
-
Jesse Hall, Google
-
Daniel Rakos, AMD
-
Ray Smith, ARM
-
Description
This extension defines a special queue family,
VK_QUEUE_FAMILY_FOREIGN_EXT
, which can be used to transfer ownership
of resources backed by external memory to foreign, external queues.
This is similar to VK_QUEUE_FAMILY_EXTERNAL_KHR
, defined in
VK_KHR_external_memory
.
The key differences between the two are:
-
The queues represented by
VK_QUEUE_FAMILY_EXTERNAL_KHR
must share the same physical device and the same driver version as the current VkInstance.VK_QUEUE_FAMILY_FOREIGN_EXT
has no such restrictions. It can represent devices and drivers from other vendors, and can even represent non-Vulkan-capable devices. -
All resources backed by external memory support
VK_QUEUE_FAMILY_EXTERNAL_KHR
. Support forVK_QUEUE_FAMILY_FOREIGN_EXT
is more restrictive. -
Applications should expect transitions to/from
VK_QUEUE_FAMILY_FOREIGN_EXT
to be more expensive than transitions to/fromVK_QUEUE_FAMILY_EXTERNAL_KHR
.
VK_EXT_shader_object
- Name String
-
VK_EXT_shader_object
- Extension Type
-
Device extension
- Registered Extension Number
-
483
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_VERSION_1_1
-
Interacts with VK_VERSION_1_3
-
Interacts with VK_EXT_blend_operation_advanced
-
Interacts with VK_EXT_conservative_rasterization
-
Interacts with VK_EXT_depth_clip_control
-
Interacts with VK_EXT_depth_clip_enable
-
Interacts with VK_EXT_fragment_density_map
-
Interacts with VK_EXT_line_rasterization
-
Interacts with VK_EXT_mesh_shader
-
Interacts with VK_EXT_provoking_vertex
-
Interacts with VK_EXT_sample_locations
-
Interacts with VK_EXT_subgroup_size_control
-
Interacts with VK_EXT_transform_feedback
-
Interacts with VK_KHR_device_group
-
Interacts with VK_KHR_fragment_shading_rate
-
Interacts with VK_NV_clip_space_w_scaling
-
Interacts with VK_NV_coverage_reduction_mode
-
Interacts with VK_NV_fragment_coverage_to_color
-
Interacts with VK_NV_framebuffer_mixed_samples
-
Interacts with VK_NV_mesh_shader
-
Interacts with VK_NV_representative_fragment_test
-
Interacts with VK_NV_shading_rate_image
-
Interacts with VK_NV_viewport_swizzle
-
- Contact
-
-
Daniel Story daniel-story
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-03-30
- Interactions and External Dependencies
-
-
Interacts with
VK_EXT_extended_dynamic_state
-
Interacts with
VK_EXT_extended_dynamic_state2
-
Interacts with
VK_EXT_extended_dynamic_state3
-
Interacts with
VK_EXT_vertex_input_dynamic_state
-
- IP Status
-
No known IP claims.
- Contributors
-
-
Piers Daniell, NVIDIA
-
Sandy Jamieson, Nintendo
-
Žiga Markuš, LunarG
-
Tobias Hector, AMD
-
Alex Walters, Imagination
-
Shahbaz Youssefi, Google
-
Ralph Potter, Samsung
-
Jan-Harald Fredriksen, ARM
-
Connor Abott, Valve
-
Arseny Kapoulkine, Roblox
-
Patrick Doane, Activision
-
Jeff Leger, Qualcomm
-
Stu Smith, AMD
-
Chris Glover, Google
-
Ricardo Garcia, Igalia
-
Faith Ekstrand, Collabora
-
Timur Kristóf, Valve
-
Constantine Shablya, Collabora
-
Daniel Koch, NVIDIA
-
Alyssa Rosenzweig, Collabora
-
Mike Blumenkrantz, Valve
-
Samuel Pitoiset, Valve
-
Qun Lin, AMD
-
Spencer Fricke, LunarG
-
Soroush Faghihi Kashani, Imagination
-
Description
This extension introduces a new VkShaderEXT object type which represents a single compiled shader stage. Shader objects provide a more flexible alternative to VkPipeline objects, which may be helpful in certain use cases.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkPipelineShaderStageCreateInfo, VkShaderCreateInfoEXT:
New Enum Constants
-
VK_EXT_SHADER_OBJECT_EXTENSION_NAME
-
VK_EXT_SHADER_OBJECT_SPEC_VERSION
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_SHADER_EXT
-
-
Extending VkResult:
-
VK_ERROR_INCOMPATIBLE_SHADER_BINARY_EXT
-
VK_INCOMPATIBLE_SHADER_BINARY_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_PROPERTIES_EXT
-
VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT
-
VK_STRUCTURE_TYPE_SHADER_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT
-
VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT
-
VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT
-
If VK_EXT_subgroup_size_control
or Version 1.3 is supported:
-
Extending VkShaderCreateFlagBitsEXT:
-
VK_SHADER_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT
-
VK_SHADER_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT
-
If VK_KHR_device_group or Version 1.1 is supported:
-
Extending VkShaderCreateFlagBitsEXT:
-
VK_SHADER_CREATE_DISPATCH_BASE_BIT_EXT
-
If VK_KHR_fragment_shading_rate is supported:
-
Extending VkShaderCreateFlagBitsEXT:
-
VK_SHADER_CREATE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_EXT
-
Examples
Example 1
Create linked pair of vertex and fragment shaders.
// Logical device created with the shaderObject feature enabled
VkDevice device;
// SPIR-V shader code for a vertex shader, along with its size in bytes
void* pVertexSpirv;
size_t vertexSpirvSize;
// SPIR-V shader code for a fragment shader, along with its size in bytes
void* pFragmentSpirv;
size_t fragmentSpirvSize;
// Descriptor set layout compatible with the shaders
VkDescriptorSetLayout descriptorSetLayout;
VkShaderCreateInfoEXT shaderCreateInfos[2] =
{
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = VK_SHADER_CREATE_LINK_STAGE_BIT_EXT,
.stage = VK_SHADER_STAGE_VERTEX_BIT,
.nextStage = VK_SHADER_STAGE_FRAGMENT_BIT,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = vertexSpirvSize,
.pCode = pVertexSpirv,
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
},
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = VK_SHADER_CREATE_LINK_STAGE_BIT_EXT,
.stage = VK_SHADER_STAGE_FRAGMENT_BIT,
.nextStage = 0,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = fragmentSpirvSize,
.pCode = pFragmentSpirv,
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
}
};
VkResult result;
VkShaderEXT shaders[2];
result = vkCreateShadersEXT(device, 2, &shaderCreateInfos, NULL, shaders);
if (result != VK_SUCCESS)
{
// Handle error
}
Later, during command buffer recording, bind the linked shaders and draw.
// Command buffer in the recording state
VkCommandBuffer commandBuffer;
// Vertex and fragment shader objects created above
VkShaderEXT shaders[2];
// Assume vertex buffers, descriptor sets, etc. have been bound, and existing
// state setting commands have been called to set all required state
const VkShaderStageFlagBits stages[2] =
{
VK_SHADER_STAGE_VERTEX_BIT,
VK_SHADER_STAGE_FRAGMENT_BIT
};
// Bind linked shaders
vkCmdBindShadersEXT(commandBuffer, 2, stages, shaders);
// Equivalent to the previous line. Linked shaders can be bound one at a time,
// in any order:
// vkCmdBindShadersEXT(commandBuffer, 1, &stages[1], &shaders[1]);
// vkCmdBindShadersEXT(commandBuffer, 1, &stages[0], &shaders[0]);
// The above is sufficient to draw if the device was created with the
// tessellationShader and geometryShader features disabled. Otherwise, since
// those stages should not execute, vkCmdBindShadersEXT() must be called at
// least once with each of their stages in pStages before drawing:
const VkShaderStageFlagBits unusedStages[3] =
{
VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT,
VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT,
VK_SHADER_STAGE_GEOMETRY_BIT
};
// NULL pShaders is equivalent to an array of stageCount VK_NULL_HANDLE values,
// meaning no shaders are bound to those stages, and that any previously bound
// shaders are unbound
vkCmdBindShadersEXT(commandBuffer, 3, unusedStages, NULL);
// Graphics shader objects may only be used to draw inside dynamic render pass
// instances begun with vkCmdBeginRendering(), assume one has already been begun
// Draw a triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);
Example 2
Create unlinked vertex, geometry, and fragment shaders.
// Logical device created with the shaderObject feature enabled
VkDevice device;
// SPIR-V shader code for vertex shaders, along with their sizes in bytes
void* pVertexSpirv[2];
size_t vertexSpirvSize[2];
// SPIR-V shader code for a geometry shader, along with its size in bytes
void pGeometrySpirv;
size_t geometrySpirvSize;
// SPIR-V shader code for fragment shaders, along with their sizes in bytes
void* pFragmentSpirv[2];
size_t fragmentSpirvSize[2];
// Descriptor set layout compatible with the shaders
VkDescriptorSetLayout descriptorSetLayout;
VkShaderCreateInfoEXT shaderCreateInfos[5] =
{
// Stage order does not matter
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.stage = VK_SHADER_STAGE_GEOMETRY_BIT,
.nextStage = VK_SHADER_STAGE_FRAGMENT_BIT,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = pGeometrySpirv,
.pCode = geometrySpirvSize,
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
},
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.stage = VK_SHADER_STAGE_VERTEX_BIT,
.nextStage = VK_SHADER_STAGE_GEOMETRY_BIT,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = vertexSpirvSize[0],
.pCode = pVertexSpirv[0],
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
},
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.stage = VK_SHADER_STAGE_FRAGMENT_BIT,
.nextStage = 0,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = fragmentSpirvSize[0],
.pCode = pFragmentSpirv[0],
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
},
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.stage = VK_SHADER_STAGE_FRAGMENT_BIT,
.nextStage = 0,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = fragmentSpirvSize[1],
.pCode = pFragmentSpirv[1],
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
},
{
.sType = VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.stage = VK_SHADER_STAGE_VERTEX_BIT,
// Suppose we want this vertex shader to be able to be followed by
// either a geometry shader or fragment shader:
.nextStage = VK_SHADER_STAGE_GEOMETRY_BIT | VK_SHADER_STAGE_FRAGMENT_BIT,
.codeType = VK_SHADER_CODE_TYPE_SPIRV_EXT,
.codeSize = vertexSpirvSize[1],
.pCode = pVertexSpirv[1],
.pName = "main",
.setLayoutCount = 1,
.pSetLayouts = &descriptorSetLayout;
.pushConstantRangeCount = 0,
.pPushConstantRanges = NULL,
.pSpecializationInfo = NULL
}
};
VkResult result;
VkShaderEXT shaders[5];
result = vkCreateShadersEXT(device, 5, &shaderCreateInfos, NULL, shaders);
if (result != VK_SUCCESS)
{
// Handle error
}
Later, during command buffer recording, bind the linked shaders in different combinations and draw.
// Command buffer in the recording state
VkCommandBuffer commandBuffer;
// Vertex, geometry, and fragment shader objects created above
VkShaderEXT shaders[5];
// Assume vertex buffers, descriptor sets, etc. have been bound, and existing
// state setting commands have been called to set all required state
const VkShaderStageFlagBits stages[3] =
{
// Any order is allowed
VK_SHADER_STAGE_FRAGMENT_BIT,
VK_SHADER_STAGE_VERTEX_BIT,
VK_SHADER_STAGE_GEOMETRY_BIT,
};
VkShaderEXT bindShaders[3] =
{
shaders[2], // FS
shaders[1], // VS
shaders[0] // GS
};
// Bind unlinked shaders
vkCmdBindShadersEXT(commandBuffer, 3, stages, bindShaders);
// Assume the tessellationShader feature is disabled, so vkCmdBindShadersEXT()
// need not have been called with either tessellation stage
// Graphics shader objects may only be used to draw inside dynamic render pass
// instances begun with vkCmdBeginRendering(), assume one has already been begun
// Draw a triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);
// Bind a different unlinked fragment shader
const VkShaderStageFlagBits fragmentStage = VK_SHADER_STAGE_FRAGMENT_BIT;
vkCmdBindShadersEXT(commandBuffer, 1, &fragmentStage, &shaders[3]);
// Draw another triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);
// Bind a different unlinked vertex shader
const VkShaderStageFlagBits vertexStage = VK_SHADER_STAGE_VERTEX_BIT;
vkCmdBindShadersEXT(commandBuffer, 1, &vertexStage, &shaders[4]);
// Draw another triangle
vkCmdDraw(commandBuffer, 3, 1, 0, 0);
VK_EXT_shader_tile_image
- Name String
-
VK_EXT_shader_tile_image
- Extension Type
-
Device extension
- Registered Extension Number
-
396
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Contact
-
-
Jan-Harald Fredriksen janharaldfredriksen-arm
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2023-03-23
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_shader_tile_image
-
- Contributors
-
-
Sandeep Kakarlapudi, Arm
-
Jan-Harald Fredriksen, Arm
-
James Fitzpatrick, Imagination
-
Andrew Garrard, Imagination
-
Jeff Leger, Qualcomm
-
Huilong Wang, Huawei
-
Graeme Leese, Broadcom
-
Hans-Kristian Arntzen, Valve
-
Tobias Hector, AMD
-
Jeff Bolz, NVIDIA
-
Shahbaz Youssefi, Google
-
Description
This extension allows fragment shader invocations to read color, depth and stencil values at their pixel location in rasterization order. The functionality is only available when using dynamic render passes introduced by VK_KHR_dynamic_rendering. Example use cases are programmable blending and deferred shading.
See fragment shader tile image reads for more information.
New Enum Constants
-
VK_EXT_SHADER_TILE_IMAGE_EXTENSION_NAME
-
VK_EXT_SHADER_TILE_IMAGE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_PROPERTIES_EXT
-
Examples
Color read example.
layout( location = 0 /* aliased to color attachment 0 */ ) tileImageEXT highp attachmentEXT color0;
layout( location = 1 /* aliased to color attachment 1 */ ) tileImageEXT highp attachmentEXT color1;
layout( location = 0 ) out vec4 fragColor;
void main()
{
vec4 value = colorAttachmentReadEXT(color0) + colorAttachmentReadEXT(color1);
fragColor = value;
}
Depth & Stencil read example.
void main()
{
// read sample 0: works for non-MSAA or MSAA targets
highp float last_depth = depthAttachmentReadEXT();
lowp uint last_stencil = stencilAttachmentReadEXT();
//..
}
VK_EXT_transform_feedback
- Name String
-
VK_EXT_transform_feedback
- Extension Type
-
Device extension
- Registered Extension Number
-
29
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Special Uses
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2018-10-09
- Contributors
-
-
Baldur Karlsson, Valve
-
Boris Zanin, Mobica
-
Daniel Rakos, AMD
-
Donald Scorgie, Imagination
-
Henri Verbeet, CodeWeavers
-
Jan-Harald Fredriksen, Arm
-
Faith Ekstrand, Intel
-
Jeff Bolz, NVIDIA
-
Jesse Barker, Unity
-
Jesse Hall, Google
-
Pierre-Loup Griffais, Valve
-
Philip Rebohle, DXVK
-
Ruihao Zhang, Qualcomm
-
Samuel Pitoiset, Valve
-
Slawomir Grajewski, Intel
-
Stu Smith, Imagination Technologies
-
Description
This extension adds transform feedback to the Vulkan API by exposing the
SPIR-V TransformFeedback
and GeometryStreams
capabilities to
capture vertex, tessellation or geometry shader outputs to one or more
buffers.
It adds API functionality to bind transform feedback buffers to capture the
primitives emitted by the graphics pipeline from SPIR-V outputs decorated
for transform feedback.
The transform feedback capture can be paused and resumed by way of storing
and retrieving a byte counter.
The captured data can be drawn again where the vertex count is derived from
the byte counter without CPU intervention.
If the implementation is capable, a vertex stream other than zero can be
rasterized.
All these features are designed to match the full capabilities of OpenGL core transform feedback functionality and beyond. Many of the features are optional to allow base OpenGL ES GPUs to also implement this extension.
The primary purpose of the functionality exposed by this extension is to support translation layers from other 3D APIs. This functionality is not considered forward looking, and is not expected to be promoted to a KHR extension or to core Vulkan. Unless this is needed for translation, it is recommended that developers use alternative techniques of using the GPU to process and capture vertex data.
New Enum Constants
-
VK_EXT_TRANSFORM_FEEDBACK_EXTENSION_NAME
-
VK_EXT_TRANSFORM_FEEDBACK_SPEC_VERSION
-
Extending VkAccessFlagBits:
-
VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT
-
VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT
-
VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT
-
VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT
-
-
Extending VkPipelineStageFlagBits:
-
VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT
-
-
Extending VkQueryType:
-
VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT
-
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT
-
Issues
1) Should we include pause/resume functionality?
RESOLVED: Yes, this is needed to ease layering other APIs which have this
functionality.
To pause use vkCmdEndTransformFeedbackEXT
and provide valid buffer
handles in the pCounterBuffers
array and offsets in the
pCounterBufferOffsets
array for the implementation to save the resume
points.
Then to resume use vkCmdBeginTransformFeedbackEXT
with the previous
pCounterBuffers
and pCounterBufferOffsets
values.
Between the pause and resume there needs to be a memory barrier for the
counter buffers with a source access of
VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT
at pipeline stage
VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT
to a destination access
of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT
at pipeline stage
VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT
.
2) How does this interact with multiview?
RESOLVED: Transform feedback cannot be made active in a render pass with multiview enabled.
3) How should queries be done?
RESOLVED: There is a new query type
VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT
.
A query pool created with this type will capture 2 integers -
numPrimitivesWritten and numPrimitivesNeeded - for the specified vertex
stream output from the last
pre-rasterization shader
stage.
The vertex stream output queried is zero by default, but can be specified
with the new vkCmdBeginQueryIndexedEXT
and
vkCmdEndQueryIndexedEXT
commands.
List of Provisional Extensions
VK_KHR_portability_subset
- Name String
-
VK_KHR_portability_subset
- Extension Type
-
Device extension
- Registered Extension Number
-
164
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
-
This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.
-
- Contact
-
-
Bill Hollings billhollings
-
Other Extension Metadata
- Last Modified Date
-
2020-07-21
- IP Status
-
No known IP claims.
- Contributors
-
-
Bill Hollings, The Brenwill Workshop Ltd.
-
Daniel Koch, NVIDIA
-
Dzmitry Malyshau, Mozilla
-
Chip Davis, CodeWeavers
-
Dan Ginsburg, Valve
-
Mike Weiblen, LunarG
-
Neil Trevett, NVIDIA
-
Alexey Knyazev, Independent
-
Description
The VK_KHR_portability_subset
extension allows a non-conformant
Vulkan implementation to be built on top of another non-Vulkan graphics API,
and identifies differences between that implementation and a
fully-conformant native Vulkan implementation.
This extension provides Vulkan implementations with the ability to mark otherwise-required capabilities as unsupported, or to establish additional properties and limits that the application should adhere to in order to guarantee portable behavior and operation across platforms, including platforms where Vulkan is not natively supported.
The goal of this specification is to document, and make queryable, capabilities which are required to be supported by a fully-conformant Vulkan 1.0 implementation, but may be optional for an implementation of the Vulkan 1.0 Portability Subset.
The intent is that this extension will be advertised only on implementations of the Vulkan 1.0 Portability Subset, and not on conformant implementations of Vulkan 1.0. Fully-conformant Vulkan implementations provide all the required capabilities, and so will not provide this extension. Therefore, the existence of this extension can be used to determine that an implementation is likely not fully conformant with the Vulkan spec.
If this extension is supported by the Vulkan implementation, the application must enable this extension.
This extension defines several new structures that can be chained to the existing structures used by certain standard Vulkan calls, in order to query for non-conformant portable behavior.
New Enum Constants
-
VK_KHR_PORTABILITY_SUBSET_EXTENSION_NAME
-
VK_KHR_PORTABILITY_SUBSET_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_PROPERTIES_KHR
-
List of Deprecated Extensions
VK_KHR_16bit_storage
- Name String
-
VK_KHR_16bit_storage
- Extension Type
-
Device extension
- Registered Extension Number
-
84
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jan-Harald Fredriksen janharaldfredriksen-arm
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_shader_16bit_storage
-
- Contributors
-
-
Alexander Galazin, ARM
-
Jan-Harald Fredriksen, ARM
-
Joerg Wagner, ARM
-
Neil Henning, Codeplay
-
Jeff Bolz, Nvidia
-
Daniel Koch, Nvidia
-
David Neto, Google
-
John Kessenich, Google
-
Description
The VK_KHR_16bit_storage
extension allows use of 16-bit types in shader
input and output interfaces, and push constant blocks.
This extension introduces several new optional features which map to SPIR-V
capabilities and allow access to 16-bit data in Block
-decorated objects
in the Uniform
and the StorageBuffer
storage classes, and objects
in the PushConstant
storage class.
This extension allows 16-bit variables to be declared and used as
user-defined shader inputs and outputs but does not change location
assignment and component assignment rules.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted.
However, if Vulkan 1.1 is supported and this extension is not, the
storageBuffer16BitAccess
capability is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_16BIT_STORAGE_EXTENSION_NAME
-
VK_KHR_16BIT_STORAGE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR
-
VK_KHR_8bit_storage
- Name String
-
VK_KHR_8bit_storage
- Extension Type
-
Device extension
- Registered Extension Number
-
178
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Alexander Galazin alegal-arm
-
Other Extension Metadata
- Last Modified Date
-
2018-02-05
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_shader_16bit_storage
-
- IP Status
-
No known IP claims.
- Contributors
-
-
Alexander Galazin, Arm
-
Description
The VK_KHR_8bit_storage
extension allows use of 8-bit types in uniform and
storage buffers, and push constant blocks.
This extension introduces several new optional features which map to SPIR-V
capabilities and allow access to 8-bit data in Block
-decorated objects
in the Uniform
and the StorageBuffer
storage classes, and objects
in the PushConstant
storage class.
The StorageBuffer8BitAccess
capability must be supported by all
implementations of this extension.
The other capabilities are optional.
Promotion to Vulkan 1.2
Functionality in this extension is included in core Vulkan 1.2, with the KHR
suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
StorageBuffer8BitAccess
capability is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_8BIT_STORAGE_EXTENSION_NAME
-
VK_KHR_8BIT_STORAGE_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR
-
VK_KHR_bind_memory2
- Name String
-
VK_KHR_bind_memory2
- Extension Type
-
Device extension
- Registered Extension Number
-
158
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Tobias Hector tobski
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Tobias Hector, Imagination Technologies
-
Description
This extension provides versions of vkBindBufferMemory and vkBindImageMemory that allow multiple bindings to be performed at once, and are extensible.
This extension also introduces VK_IMAGE_CREATE_ALIAS_BIT_KHR
, which
allows “identical” images that alias the same memory to interpret the
contents consistently, even across image layout changes.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_BIND_MEMORY_2_EXTENSION_NAME
-
VK_KHR_BIND_MEMORY_2_SPEC_VERSION
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_ALIAS_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR
-
VK_KHR_buffer_device_address
- Name String
-
VK_KHR_buffer_device_address
- Extension Type
-
Device extension
- Registered Extension Number
-
258
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2019-06-24
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_buffer_reference
andGL_EXT_buffer_reference2
andGL_EXT_buffer_reference_uvec2
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Neil Henning, AMD
-
Tobias Hector, AMD
-
Faith Ekstrand, Intel
-
Baldur Karlsson, Valve
-
Jan-Harald Fredriksen, Arm
-
Description
This extension allows the application to query a 64-bit buffer device
address value for a buffer, which can be used to access the buffer memory
via the PhysicalStorageBuffer
storage class in the
GL_EXT_buffer_reference
GLSL extension and
SPV_KHR_physical_storage_buffer
SPIR-V extension.
Another way to describe this extension is that it adds “pointers to buffer
memory in shaders”.
By calling vkGetBufferDeviceAddress with a VkBuffer
, it will
return a VkDeviceAddress value which represents the address of the
start of the buffer.
vkGetBufferOpaqueCaptureAddress and
vkGetDeviceMemoryOpaqueCaptureAddress allow opaque addresses for
buffers and memory objects to be queried for the current process.
A trace capture and replay tool can then supply these addresses to be used
at replay time to match the addresses used when the trace was captured.
To enable tools to insert these queries, new memory allocation flags must be
specified for memory objects that will be bound to buffers accessed via the
PhysicalStorageBuffer
storage class.
Note that this mechanism is intended only to support capture/replay tools,
and is not recommended for use in other applications.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
KHR suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
bufferDeviceAddress
feature is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
Promotion to Vulkan 1.3
Support for the bufferDeviceAddress
feature is mandatory in Vulkan 1.3,
regardless of whether this extension is supported.
New Structures
-
Extending VkBufferCreateInfo:
-
Extending VkMemoryAllocateInfo:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
New Enum Constants
-
VK_KHR_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME
-
VK_KHR_BUFFER_DEVICE_ADDRESS_SPEC_VERSION
-
Extending VkBufferCreateFlagBits:
-
VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR
-
-
Extending VkBufferUsageFlagBits:
-
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR
-
-
Extending VkMemoryAllocateFlagBits:
-
VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT_KHR
-
VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR
-
-
Extending VkResult:
-
VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_KHR
-
VK_STRUCTURE_TYPE_BUFFER_OPAQUE_CAPTURE_ADDRESS_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_MEMORY_OPAQUE_CAPTURE_ADDRESS_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_OPAQUE_CAPTURE_ADDRESS_ALLOCATE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_KHR
-
VK_KHR_copy_commands2
- Name String
-
VK_KHR_copy_commands2
- Extension Type
-
Device extension
- Registered Extension Number
-
338
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Jeff Leger jackohound
-
Other Extension Metadata
- Last Modified Date
-
2020-07-06
- Contributors
-
-
Jeff Leger, Qualcomm
-
Tobias Hector, AMD
-
Jan-Harald Fredriksen, ARM
-
Tom Olson, ARM
-
Description
This extension provides extensible versions of the Vulkan buffer and image copy commands. The new commands are functionally identical to the core commands, except that their copy parameters are specified using extensible structures that can be used to pass extension-specific information.
The following extensible copy commands are introduced with this extension:
vkCmdCopyBuffer2KHR, vkCmdCopyImage2KHR,
vkCmdCopyBufferToImage2KHR, vkCmdCopyImageToBuffer2KHR,
vkCmdBlitImage2KHR, and vkCmdResolveImage2KHR.
Each command contains an *Info2KHR
structure parameter that includes
sType
/pNext
members.
Lower level structures describing each region to be copied are also extended
with sType
/pNext
members.
New Enum Constants
-
VK_KHR_COPY_COMMANDS_2_EXTENSION_NAME
-
VK_KHR_COPY_COMMANDS_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BLIT_IMAGE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_BUFFER_COPY_2_KHR
-
VK_STRUCTURE_TYPE_BUFFER_IMAGE_COPY_2_KHR
-
VK_STRUCTURE_TYPE_COPY_BUFFER_INFO_2_KHR
-
VK_STRUCTURE_TYPE_COPY_BUFFER_TO_IMAGE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_COPY_IMAGE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_COPY_IMAGE_TO_BUFFER_INFO_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_BLIT_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_COPY_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR
-
VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR
-
VK_KHR_create_renderpass2
- Name String
-
VK_KHR_create_renderpass2
- Extension Type
-
Device extension
- Registered Extension Number
-
110
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Tobias Hector tobias
-
Description
This extension provides a new entry point to create render passes in a way
that can be easily extended by other extensions through the substructures of
render pass creation.
The Vulkan 1.0 render pass creation sub-structures do not include
sType
/pNext
members.
Additionally, the render pass begin/next/end commands have been augmented
with new extensible structures for passing additional subpass information.
The VkRenderPassMultiviewCreateInfo and VkInputAttachmentAspectReference structures that extended the original VkRenderPassCreateInfo are not accepted into the new creation functions, and instead their parameters are folded into this extension as follows:
-
Elements of VkRenderPassMultiviewCreateInfo::
pViewMasks
are now specified in VkSubpassDescription2KHR::viewMask
. -
Elements of VkRenderPassMultiviewCreateInfo::
pViewOffsets
are now specified in VkSubpassDependency2KHR::viewOffset
. -
VkRenderPassMultiviewCreateInfo::
correlationMaskCount
and VkRenderPassMultiviewCreateInfo::pCorrelationMasks
are directly specified in VkRenderPassCreateInfo2KHR. -
VkInputAttachmentAspectReference::
aspectMask
is now specified in the relevant input attachment reference in VkAttachmentReference2KHR::aspectMask
The details of these mappings are explained fully in the new structures.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME
-
VK_KHR_CREATE_RENDERPASS_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR
-
VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR
-
VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR
-
VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR
-
VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR
-
VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR
-
VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR
-
VK_KHR_dedicated_allocation
- Name String
-
VK_KHR_dedicated_allocation
- Extension Type
-
Device extension
- Registered Extension Number
-
128
- Revision
-
3
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Faith Ekstrand, Intel
-
Description
This extension enables resources to be bound to a dedicated allocation,
rather than suballocated.
For any particular resource, applications can query whether a dedicated
allocation is recommended, in which case using a dedicated allocation may
improve the performance of access to that resource.
Normal device memory allocations must support multiple resources per
allocation, memory aliasing and sparse binding, which could interfere with
some optimizations.
Applications should query the implementation for when a dedicated allocation
may be beneficial by adding a VkMemoryDedicatedRequirementsKHR
structure to the pNext
chain of the VkMemoryRequirements2
structure passed as the pMemoryRequirements
parameter of a call to
vkGetBufferMemoryRequirements2
or vkGetImageMemoryRequirements2
.
Certain external handle types and external images or buffers may also
depend on dedicated allocations on implementations that associate image or
buffer metadata with OS-level memory objects.
This extension adds a two small structures to memory requirements querying and memory allocation: a new structure that flags whether an image/buffer should have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME
-
VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR
-
Examples
// Create an image with a dedicated allocation based on the
// implementation's preference
VkImageCreateInfo imageCreateInfo =
{
// Image creation parameters
};
VkImage image;
VkResult result = vkCreateImage(
device,
&imageCreateInfo,
NULL, // pAllocator
&image);
VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
{
.sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
.pNext = NULL,
};
VkMemoryRequirements2 memoryRequirements =
{
.sType = VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
.pNext = &dedicatedRequirements,
};
const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
{
.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
.pNext = NULL,
.image = image
};
vkGetImageMemoryRequirements2(
device,
&imageRequirementsInfo,
&memoryRequirements);
if (dedicatedRequirements.prefersDedicatedAllocation) {
// Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
// pointing to the image we are allocating the memory for
VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
{
.sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
.pNext = NULL,
.image = image,
.buffer = VK_NULL_HANDLE,
};
VkMemoryAllocateInfo memoryAllocateInfo =
{
.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
.pNext = &dedicatedInfo,
.allocationSize = memoryRequirements.size,
.memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
};
VkDeviceMemory memory;
vkAllocateMemory(
device,
&memoryAllocateInfo,
NULL, // pAllocator
&memory);
// Bind the image to the memory
vkBindImageMemory(
device,
image,
memory,
0);
} else {
// Take the normal memory sub-allocation path
}
Version History
-
Revision 1, 2017-02-27 (James Jones)
-
Copy content from VK_NV_dedicated_allocation
-
Add some references to external object interactions to the overview.
-
-
Revision 2, 2017-03-27 (Faith Ekstrand)
-
Rework the extension to be query-based
-
-
Revision 3, 2017-07-31 (Faith Ekstrand)
-
Clarify that memory objects allocated with VkMemoryDedicatedAllocateInfoKHR can only have the specified resource bound and no others.
-
VK_KHR_depth_stencil_resolve
- Name String
-
VK_KHR_depth_stencil_resolve
- Extension Type
-
Device extension
- Registered Extension Number
-
200
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Jan-Harald Fredriksen janharald
-
Other Extension Metadata
- Last Modified Date
-
2018-04-09
- Contributors
-
-
Jan-Harald Fredriksen, Arm
-
Andrew Garrard, Samsung Electronics
-
Soowan Park, Samsung Electronics
-
Jeff Bolz, NVIDIA
-
Daniel Rakos, AMD
-
Description
This extension adds support for automatically resolving multisampled depth/stencil attachments in a subpass in a similar manner as for color attachments.
Multisampled color attachments can be resolved at the end of a subpass by
specifying pResolveAttachments
entries corresponding to the
pColorAttachments
array entries.
This does not allow for a way to map the resolve attachments to the
depth/stencil attachment.
The vkCmdResolveImage command does not allow for depth/stencil images.
While there are other ways to resolve the depth/stencil attachment, they can
give sub-optimal performance.
Extending the VkSubpassDescription2
in this extension allows an
application to add a pDepthStencilResolveAttachment
, that is similar
to the color pResolveAttachments
, that the
pDepthStencilAttachment
can be resolved into.
Depth and stencil samples are resolved to a single value based on the
resolve mode.
The set of possible resolve modes is defined in the
VkResolveModeFlagBits enum.
The VK_RESOLVE_MODE_SAMPLE_ZERO_BIT
mode is the only mode that is
required of all implementations (that support the extension or support
Vulkan 1.2 or higher).
Some implementations may also support averaging (the same as color sample
resolve) or taking the minimum or maximum sample, which may be more suitable
for depth/stencil resolve.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_DEPTH_STENCIL_RESOLVE_EXTENSION_NAME
-
VK_KHR_DEPTH_STENCIL_RESOLVE_SPEC_VERSION
-
Extending VkResolveModeFlagBits:
-
VK_RESOLVE_MODE_AVERAGE_BIT_KHR
-
VK_RESOLVE_MODE_MAX_BIT_KHR
-
VK_RESOLVE_MODE_MIN_BIT_KHR
-
VK_RESOLVE_MODE_NONE_KHR
-
VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR
-
VK_KHR_descriptor_update_template
- Name String
-
VK_KHR_descriptor_update_template
- Extension Type
-
Device extension
- Registered Extension Number
-
86
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- API Interactions
-
-
Interacts with VK_EXT_debug_report
-
Interacts with VK_KHR_push_descriptor
-
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Markus Tavenrath mtavenrath
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_push_descriptor
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Michael Worcester, Imagination Technologies
-
Description
Applications may wish to update a fixed set of descriptors in a large number of descriptor sets very frequently, i.e. during initialization phase or if it is required to rebuild descriptor sets for each frame. For those cases it is also not unlikely that all information required to update a single descriptor set is stored in a single struct. This extension provides a way to update a fixed set of descriptors in a single VkDescriptorSet with a pointer to a user defined data structure describing the new descriptors.
Promotion to Vulkan 1.1
vkCmdPushDescriptorSetWithTemplateKHR is included as an interaction
with VK_KHR_push_descriptor
.
If Vulkan 1.1 and VK_KHR_push_descriptor
are supported, this is included
by VK_KHR_push_descriptor
.
The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME
-
VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_SPEC_VERSION
-
Extending VkDescriptorUpdateTemplateType:
-
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET_KHR
-
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR
-
If VK_KHR_push_descriptor is supported:
-
Extending VkDescriptorUpdateTemplateType:
-
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
-
VK_KHR_device_group
- Name String
-
VK_KHR_device_group
- Extension Type
-
Device extension
- Registered Extension Number
-
61
- Revision
-
4
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_KHR_bind_memory2
-
Interacts with VK_KHR_surface
-
Interacts with VK_KHR_swapchain
-
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2017-10-10
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Tobias Hector, Imagination Technologies
-
Description
This extension provides functionality to use a logical device that consists
of multiple physical devices, as created with the
VK_KHR_device_group_creation
extension.
A device group can allocate memory across the subdevices, bind memory from
one subdevice to a resource on another subdevice, record command buffers
where some work executes on an arbitrary subset of the subdevices, and
potentially present a swapchain image from one or more subdevices.
Promotion to Vulkan 1.1
The following enums, types and commands are included as interactions with
VK_KHR_swapchain
:
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR
-
VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR
-
VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR
-
VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
If Vulkan 1.1 and VK_KHR_swapchain
are supported, these are
included by VK_KHR_swapchain
.
The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Structures
-
Extending VkBindSparseInfo:
-
Extending VkCommandBufferBeginInfo:
-
Extending VkMemoryAllocateInfo:
-
Extending VkRenderPassBeginInfo, VkRenderingInfo:
-
Extending VkSubmitInfo:
If VK_KHR_bind_memory2 is supported:
-
Extending VkBindBufferMemoryInfo:
-
Extending VkBindImageMemoryInfo:
If VK_KHR_surface is supported:
If VK_KHR_swapchain is supported:
New Enums
If VK_KHR_surface is supported:
New Bitmasks
If VK_KHR_surface is supported:
New Enum Constants
-
VK_KHR_DEVICE_GROUP_EXTENSION_NAME
-
VK_KHR_DEVICE_GROUP_SPEC_VERSION
-
Extending VkDependencyFlagBits:
-
VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR
-
-
Extending VkMemoryAllocateFlagBits:
-
VK_MEMORY_ALLOCATE_DEVICE_MASK_BIT_KHR
-
-
Extending VkPeerMemoryFeatureFlagBits:
-
VK_PEER_MEMORY_FEATURE_COPY_DST_BIT_KHR
-
VK_PEER_MEMORY_FEATURE_COPY_SRC_BIT_KHR
-
VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT_KHR
-
VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT_KHR
-
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_DISPATCH_BASE_KHR
-
VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR
-
VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR
-
If VK_KHR_bind_memory2 is supported:
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR
-
If VK_KHR_surface is supported:
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR
-
If VK_KHR_swapchain is supported:
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR
-
VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR
-
-
Extending VkSwapchainCreateFlagBitsKHR:
-
VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR
-
Version History
-
Revision 1, 2016-10-19 (Jeff Bolz)
-
Internal revisions
-
-
Revision 2, 2017-05-19 (Tobias Hector)
-
Removed extended memory bind functions to VK_KHR_bind_memory2, added dependency on that extension, and device-group-specific structs for those functions.
-
-
Revision 3, 2017-10-06 (Ian Elliott)
-
Corrected Vulkan 1.1 interactions with the WSI extensions. All Vulkan 1.1 WSI interactions are with the VK_KHR_swapchain extension.
-
-
Revision 4, 2017-10-10 (Jeff Bolz)
-
Rename “SFR” bits and structure members to use the phrase “split instance bind regions”.
-
VK_KHR_device_group_creation
- Name String
-
VK_KHR_device_group_creation
- Extension Type
-
Instance extension
- Registered Extension Number
-
71
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2016-10-19
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Description
This extension provides instance-level commands to enumerate groups of
physical devices, and to create a logical device from a subset of one of
those groups.
Such a logical device can then be used with new features in the
VK_KHR_device_group
extension.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_DEVICE_GROUP_CREATION_EXTENSION_NAME
-
VK_KHR_DEVICE_GROUP_CREATION_SPEC_VERSION
-
VK_MAX_DEVICE_GROUP_SIZE_KHR
-
Extending VkMemoryHeapFlagBits:
-
VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR
-
Examples
VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
// (not shown) fill out devCreateInfo as usual.
uint32_t deviceGroupCount = 0;
VkPhysicalDeviceGroupPropertiesKHR *props = NULL;
// Query the number of device groups
vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);
// Allocate and initialize structures to query the device groups
props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
for (i = 0; i < deviceGroupCount; ++i) {
props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
props[i].pNext = NULL;
}
vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);
// If the first device group has more than one physical device. create
// a logical device using all of the physical devices.
VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
if (props[0].physicalDeviceCount > 1) {
deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
devCreateInfo.pNext = &deviceGroupInfo;
}
vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
free(props);
VK_KHR_draw_indirect_count
- Name String
-
VK_KHR_draw_indirect_count
- Extension Type
-
Device extension
- Registered Extension Number
-
170
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2017-08-25
- IP Status
-
No known IP claims.
- Contributors
-
-
Matthaeus G. Chajdas, AMD
-
Derrick Owens, AMD
-
Graham Sellers, AMD
-
Daniel Rakos, AMD
-
Dominik Witczak, AMD
-
Piers Daniell, NVIDIA
-
Description
This extension is based on the
extension.
This extension allows an application to source the number of draws for
indirect drawing calls from a buffer.VK_AMD_draw_indirect_count
Applications might want to do culling on the GPU via a compute shader prior to drawing. This enables the application to generate an arbitrary number of drawing commands and execute them without host intervention.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the entry points vkCmdDrawIndirectCount and vkCmdDrawIndexedIndirectCount are optional. The original type, enum and command names are still available as aliases of the core functionality.
VK_KHR_driver_properties
- Name String
-
VK_KHR_driver_properties
- Extension Type
-
Device extension
- Registered Extension Number
-
197
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Daniel Rakos drakos-amd
-
Other Extension Metadata
- Last Modified Date
-
2018-04-11
- IP Status
-
No known IP claims.
- Contributors
-
-
Baldur Karlsson
-
Matthaeus G. Chajdas, AMD
-
Piers Daniell, NVIDIA
-
Alexander Galazin, Arm
-
Jesse Hall, Google
-
Daniel Rakos, AMD
-
Description
This extension provides a new physical device query which allows retrieving information about the driver implementation, allowing applications to determine which physical device corresponds to which particular vendor’s driver, and which conformance test suite version the driver implementation is compliant with.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME
-
VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION
-
VK_MAX_DRIVER_INFO_SIZE_KHR
-
VK_MAX_DRIVER_NAME_SIZE_KHR
-
Extending VkDriverId:
-
VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR
-
VK_DRIVER_ID_AMD_PROPRIETARY_KHR
-
VK_DRIVER_ID_ARM_PROPRIETARY_KHR
-
VK_DRIVER_ID_BROADCOM_PROPRIETARY_KHR
-
VK_DRIVER_ID_GGP_PROPRIETARY_KHR
-
VK_DRIVER_ID_GOOGLE_SWIFTSHADER_KHR
-
VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR
-
VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR
-
VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR
-
VK_DRIVER_ID_MESA_RADV_KHR
-
VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR
-
VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR
-
VK_KHR_dynamic_rendering
- Name String
-
VK_KHR_dynamic_rendering
- Extension Type
-
Device extension
- Registered Extension Number
-
45
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_AMD_mixed_attachment_samples
-
Interacts with VK_EXT_fragment_density_map
-
Interacts with VK_KHR_fragment_shading_rate
-
Interacts with VK_NVX_multiview_per_view_attributes
-
Interacts with VK_NV_framebuffer_mixed_samples
-
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Tobias Hector tobski
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2021-10-06
- Contributors
-
-
Tobias Hector, AMD
-
Arseny Kapoulkine, Roblox
-
François Duranleau, Gameloft
-
Stuart Smith, AMD
-
Hai Nguyen, Google
-
Jean-François Roy, Google
-
Jeff Leger, Qualcomm
-
Jan-Harald Fredriksen, Arm
-
Piers Daniell, Nvidia
-
James Fitzpatrick, Imagination
-
Piotr Byszewski, Mobica
-
Jesse Hall, Google
-
Mike Blumenkrantz, Valve
-
Description
This extension allows applications to create single-pass render pass instances without needing to create render pass objects or framebuffers. Dynamic render passes can also span across multiple primary command buffers, rather than relying on secondary command buffers.
This extension also incorporates VK_ATTACHMENT_STORE_OP_NONE_KHR
from
, enabling applications to avoid
unnecessary synchronization when an attachment is not written during a
render pass.VK_QCOM_render_pass_store_ops
New Structures
-
Extending VkCommandBufferInheritanceInfo:
-
Extending VkGraphicsPipelineCreateInfo:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
If VK_KHR_fragment_shading_rate is supported:
New Enum Constants
-
VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME
-
VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION
-
Extending VkAttachmentStoreOp:
-
VK_ATTACHMENT_STORE_OP_NONE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO_KHR
-
VK_STRUCTURE_TYPE_RENDERING_INFO_KHR
-
If VK_KHR_fragment_shading_rate is supported:
-
Extending VkPipelineCreateFlagBits:
-
VK_PIPELINE_CREATE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR
-
VK_KHR_external_fence
- Name String
-
VK_KHR_external_fence
- Extension Type
-
Device extension
- Registered Extension Number
-
114
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2017-05-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Cass Everitt, Oculus
-
Contributors to
VK_KHR_external_semaphore
-
Description
An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to create fences from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Structures
-
Extending VkFenceCreateInfo:
New Enum Constants
-
VK_KHR_EXTERNAL_FENCE_EXTENSION_NAME
-
VK_KHR_EXTERNAL_FENCE_SPEC_VERSION
-
Extending VkFenceImportFlagBits:
-
VK_FENCE_IMPORT_TEMPORARY_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR
-
Issues
This extension borrows concepts, semantics, and language from
VK_KHR_external_semaphore
.
That extension’s issues apply equally to this extension.
VK_KHR_external_fence_capabilities
- Name String
-
VK_KHR_external_fence_capabilities
- Extension Type
-
Instance extension
- Registered Extension Number
-
113
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2017-05-08
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Cass Everitt, Oculus
-
Contributors to
VK_KHR_external_semaphore_capabilities
-
Description
An application may wish to reference device fences in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” fence handles an implementation supports for a given set of use cases.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME
-
VK_KHR_EXTERNAL_FENCE_CAPABILITIES_SPEC_VERSION
-
VK_LUID_SIZE_KHR
-
Extending VkExternalFenceFeatureFlagBits:
-
VK_EXTERNAL_FENCE_FEATURE_EXPORTABLE_BIT_KHR
-
VK_EXTERNAL_FENCE_FEATURE_IMPORTABLE_BIT_KHR
-
-
Extending VkExternalFenceHandleTypeFlagBits:
-
VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR
-
VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
-
VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR
-
VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR
-
VK_KHR_external_memory
- Name String
-
VK_KHR_external_memory
- Extension Type
-
Device extension
- Registered Extension Number
-
73
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-20
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_dedicated_allocation
. -
Interacts with
.VK_NV_dedicated_allocation
-
- Contributors
-
-
Faith Ekstrand, Intel
-
Ian Elliott, Google
-
Jesse Hall, Google
-
Tobias Hector, Imagination Technologies
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Matthew Netsch, Qualcomm Technologies, Inc.
-
Daniel Rakos, AMD
-
Carsten Rohde, NVIDIA
-
Ray Smith, ARM
-
Lina Versace, Google
-
Description
An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export non-Vulkan handles from Vulkan memory objects such that the underlying resources can be referenced outside the scope of the Vulkan logical device that created them.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME
-
VK_KHR_EXTERNAL_MEMORY_SPEC_VERSION
-
VK_QUEUE_FAMILY_EXTERNAL_KHR
-
Extending VkResult:
-
VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR
-
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR
-
Issues
1) How do applications correlate two physical devices across process or Vulkan instance boundaries?
RESOLVED: New device ID fields have been introduced by
VK_KHR_external_memory_capabilities
.
These fields, combined with the existing
VkPhysicalDeviceProperties::driverVersion
field can be used to
identify compatible devices across processes, drivers, and APIs.
VkPhysicalDeviceProperties::pipelineCacheUUID
is not sufficient
for this purpose because despite its description in the specification, it
need only identify a unique pipeline cache format in practice.
Multiple devices may be able to use the same pipeline cache data, and hence
it would be desirable for all of them to have the same pipeline cache UUID.
However, only the same concrete physical device can be used when sharing
memory, so an actual unique device ID was introduced.
Further, the pipeline cache UUID was specific to Vulkan, but correlation
with other, non-extensible APIs is required to enable interoperation with
those APIs.
2) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?
RESOLVED: Yes. Applications must take care to obey all restrictions imposed on aliased resources when using memory across multiple Vulkan instances or other APIs.
3) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?
RESOLVED: Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan- compatible, and those that are Vulkan-incompatible. Vulkan-incompatible APIs will require the image to be in the GENERAL layout whenever they are accessing them.
Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.
4) Is a new barrier flag or operation of some type needed to prepare external memory for handoff to another Vulkan instance or API and/or receive it from another instance or API?
RESOLVED: Yes. Some implementations need to perform additional cache management when transitioning memory between address spaces and other APIs, instances, or processes which may operate in a separate address space. Options for defining this transition include:
-
A new structure that can be added to the
pNext
list in VkMemoryBarrier, VkBufferMemoryBarrier, and VkImageMemoryBarrier. -
A new bit in VkAccessFlags that can be set to indicate an “external” access.
-
A new bit in VkDependencyFlags
-
A new special queue family that represents an “external” queue.
A new structure has the advantage that the type of external transition can
be described in as much detail as necessary.
However, there is not currently a known need for anything beyond
differentiating between external and internal accesses, so this is likely an
over-engineered solution.
The access flag bit has the advantage that it can be applied at buffer,
image, or global granularity, and semantically it maps pretty well to the
operation being described.
Additionally, the API already includes VK_ACCESS_MEMORY_READ_BIT
and
VK_ACCESS_MEMORY_WRITE_BIT
which appear to be intended for this
purpose.
However, there is no obvious pipeline stage that would correspond to an
external access, and therefore no clear way to use
VK_ACCESS_MEMORY_READ_BIT
or VK_ACCESS_MEMORY_WRITE_BIT
.
VkDependencyFlags and VkPipelineStageFlags operate at command
granularity rather than image or buffer granularity, which would make an
entire pipeline barrier an internal→external or external→internal barrier.
This may not be a problem in practice, but seems like the wrong scope.
Another downside of VkDependencyFlags is that it lacks inherent
directionality: there are no src
and dst
variants of it in the
barrier or dependency description semantics, so two bits might need to be
added to describe both internal→external and external→internal
transitions.
Transitioning a resource to a special queue family corresponds well with the
operation of transitioning to a separate Vulkan instance, in that both
operations ideally include scheduling a barrier on both sides of the
transition: Both the releasing and the acquiring queue or process.
Using a special queue family requires adding an additional reserved queue
family index.
Re-using VK_QUEUE_FAMILY_IGNORED
would have left it unclear how to
transition a concurrent usage resource from one process to another, since
the semantics would have likely been equivalent to the currently-ignored
transition of
VK_QUEUE_FAMILY_IGNORED
→ VK_QUEUE_FAMILY_IGNORED
.
Fortunately, creating a new reserved queue family index is not invasive.
Based on the above analysis, the approach of transitioning to a special “external” queue family was chosen.
5) Do internal driver memory arrangements and/or other internal driver image properties need to be exported and imported when sharing images across processes or APIs.
RESOLVED: Some vendors claim this is necessary on their implementations, but it was determined that the security risks of allowing opaque metadata to be passed from applications to the driver were too high. Therefore, implementations which require metadata will need to associate it with the objects represented by the external handles, and rely on the dedicated allocation mechanism to associate the exported and imported memory objects with a single image or buffer.
6) Most prior interoperation and cross-process sharing APIs have been based on image-level sharing. Should Vulkan sharing be based on memory-object sharing or image sharing?
RESOLVED: These extensions have assumed memory-level sharing is the correct granularity. Vulkan is a lower-level API than most prior APIs, and as such attempts to closely align with to the underlying primitives of the hardware and system-level drivers it abstracts. In general, the resource that holds the backing store for both images and buffers of various types is memory. Images and buffers are merely metadata containing brief descriptions of the layout of bits within that memory.
Because memory object-based sharing is aligned with the overall Vulkan API design, it enables the full range of Vulkan capabilities with external objects. External memory can be used as backing for sparse images, for example, whereas such usage would be awkward at best with a sharing mechanism based on higher-level primitives such as images. Further, aligning the mechanism with the API in this way provides some hope of trivial compatibility with future API enhancements. If new objects backed by memory objects are added to the API, they too can be used across processes with minimal additions to the base external memory APIs.
Earlier APIs implemented interop at a higher level, and this necessitated entirely separate sharing APIs for images and buffers. To co-exist and interoperate with those APIs, the Vulkan external sharing mechanism must accommodate their model. However, if it can be agreed that memory-based sharing is the more desirable and forward-looking design, legacy interoperation constraints can be considered another reason to favor memory-based sharing: while native and legacy driver primitives that may be used to implement sharing may not be as low-level as the API here suggests, raw memory is still the least common denominator among the types. Image-based sharing can be cleanly derived from a set of base memory- object sharing APIs with minimal effort, whereas image-based sharing does not generalize well to buffer or raw-memory sharing. Therefore, following the general Vulkan design principle of minimalism, it is better to expose interopability with image-based native and external primitives via the memory sharing API, and place sufficient limits on their usage to ensure they can be used only as backing for equivalent Vulkan images. This provides a consistent API for applications regardless of which platform or external API they are targeting, which makes development of multi-API and multi-platform applications simpler.
7) Should Vulkan define a common external handle type and provide Vulkan functions to facilitate cross-process sharing of such handles rather than relying on native handles to define the external objects?
RESOLVED: No. Cross-process sharing of resources is best left to native platforms. There are myriad security and extensibility issues with such a mechanism, and attempting to re-solve all those issues within Vulkan does not align with Vulkan’s purpose as a graphics API. If desired, such a mechanism could be built as a layer or helper library on top of the opaque native handle defined in this family of extensions.
8) Must implementations provide additional guarantees about state implicitly included in memory objects for those memory objects that may be exported?
RESOLVED: Implementations must ensure that sharing memory objects does not transfer any information between the exporting and importing instances and APIs other than that required to share the data contained in the memory objects explicitly shared. As specific examples, data from previously freed memory objects that used the same underlying physical memory, and data from memory objects using adjacent physical memory must not be visible to applications importing an exported memory object.
9) Must implementations validate external handles the application provides as inputs to memory import operations?
RESOLVED: Implementations must return an error to the application if the provided memory handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.
VK_KHR_external_memory_capabilities
- Name String
-
VK_KHR_external_memory_capabilities
- Extension Type
-
Instance extension
- Registered Extension Number
-
72
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-17
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_dedicated_allocation
. -
Interacts with
.VK_NV_dedicated_allocation
-
- Contributors
-
-
Ian Elliott, Google
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Description
An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” memory handles an implementation supports for a given set of use cases.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME
-
VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION
-
VK_LUID_SIZE_KHR
-
Extending VkExternalMemoryFeatureFlagBits:
-
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR
-
VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR
-
VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR
-
-
Extending VkExternalMemoryHandleTypeFlagBits:
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
-
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR
-
Issues
1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?
PROPOSED RESOLUTION: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.
2) Do the VkExternalImageFormatPropertiesKHR and VkExternalBufferPropertiesKHR structs need to include a list of memory type bits that support the given handle type?
PROPOSED RESOLUTION: No. The memory types that do not support the handle types will simply be filtered out of the results returned by vkGetImageMemoryRequirements and vkGetBufferMemoryRequirements when a set of handle types was specified at image or buffer creation time.
3) Should the non-opaque handle types be moved to their own extension?
PROPOSED RESOLUTION: Perhaps. However, defining the handle type bits does very little and does not require any platform-specific types on its own, and it is easier to maintain the bitfield values in a single extension for now. Presumably more handle types could be added by separate extensions though, and it would be midly weird to have some platform-specific ones defined in the core spec and some in extensions
4) Do we need a D3D11_TILEPOOL
type?
PROPOSED RESOLUTION: No. This is technically possible, but the synchronization is awkward. D3D11 surfaces must be synchronized using shared mutexes, and these synchronization primitives are shared by the entire memory object, so D3D11 shared allocations divided among multiple buffer and image bindings may be difficult to synchronize.
5) Should the Windows 7-compatible handle types be named “KMT” handles or “GLOBAL_SHARE” handles?
PROPOSED RESOLUTION: KMT, simply because it is more concise.
6) How do applications identify compatible devices and drivers across instance, process, and API boundaries when sharing memory?
PROPOSED RESOLUTION: New device properties are exposed that allow applications to correctly correlate devices and drivers. A device and driver UUID that must both match to ensure sharing compatibility between two Vulkan instances, or a Vulkan instance and an extensible external API are added. To allow correlating with Direct3D devices, a device LUID is added that corresponds to a DXGI adapter LUID. A driver ID is not needed for Direct3D because mismatched driver component versions are not currently supported on the Windows OS. Should support for such configurations be introduced at the OS level, further Vulkan extensions would be needed to correlate userspace component builds.
VK_KHR_external_semaphore
- Name String
-
VK_KHR_external_semaphore
- Extension Type
-
Device extension
- Registered Extension Number
-
78
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-21
- IP Status
-
No known IP claims.
- Contributors
-
-
Faith Ekstrand, Intel
-
Jesse Hall, Google
-
Tobias Hector, Imagination Technologies
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Matthew Netsch, Qualcomm Technologies, Inc.
-
Ray Smith, ARM
-
Lina Versace, Google
-
Description
An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to create semaphores from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME
-
VK_KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION
-
Extending VkSemaphoreImportFlagBits:
-
VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR
-
Issues
1) Should there be restrictions on what side effects can occur when waiting on imported semaphores that are in an invalid state?
RESOLVED: Yes. Normally, validating such state would be the responsibility of the application, and the implementation would be free to enter an undefined state if valid usage rules were violated. However, this could cause security concerns when using imported semaphores, as it would require the importing application to trust the exporting application to ensure the state is valid. Requiring this level of trust is undesirable for many potential use cases.
2) Must implementations validate external handles the application provides as input to semaphore state import operations?
RESOLVED: Implementations must return an error to the application if the provided semaphore state handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.
VK_KHR_external_semaphore_capabilities
- Name String
-
VK_KHR_external_semaphore_capabilities
- Extension Type
-
Instance extension
- Registered Extension Number
-
77
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
James Jones cubanismo
-
Other Extension Metadata
- Last Modified Date
-
2016-10-20
- IP Status
-
No known IP claims.
- Contributors
-
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Description
An application may wish to reference device semaphores in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” semaphore handles an implementation supports for a given set of use cases.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME
-
VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_SPEC_VERSION
-
VK_LUID_SIZE_KHR
-
Extending VkExternalSemaphoreFeatureFlagBits:
-
VK_EXTERNAL_SEMAPHORE_FEATURE_EXPORTABLE_BIT_KHR
-
VK_EXTERNAL_SEMAPHORE_FEATURE_IMPORTABLE_BIT_KHR
-
-
Extending VkExternalSemaphoreHandleTypeFlagBits:
-
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR
-
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR
-
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR
-
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR
-
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_SEMAPHORE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR
-
VK_KHR_format_feature_flags2
- Name String
-
VK_KHR_format_feature_flags2
- Extension Type
-
Device extension
- Registered Extension Number
-
361
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Lionel Landwerlin llandwerlin
-
Other Extension Metadata
- Last Modified Date
-
2021-07-01
- IP Status
-
No known IP claims.
- Contributors
-
-
Lionel Landwerlin, Intel
-
Faith Ekstrand, Intel
-
Tobias Hector, AMD
-
Spencer Fricke, Samsung Electronics
-
Graeme Leese, Broadcom
-
Jan-Harald Fredriksen, ARM
-
Description
This extension adds a new VkFormatFeatureFlagBits2KHR 64bits format feature flag type to extend the existing VkFormatFeatureFlagBits which is limited to 31 flags. At the time of this writing 29 bits of VkFormatFeatureFlagBits are already used.
Because VkFormatProperties2 is already defined to extend the Vulkan 1.0 vkGetPhysicalDeviceFormatProperties entry point, this extension defines a new VkFormatProperties3KHR to extend the VkFormatProperties.
On top of replicating all the bits from VkFormatFeatureFlagBits, VkFormatFeatureFlagBits2KHR adds the following bits :
-
VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR
andVK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR
indicate that an implementation supports respectively reading and writing a given VkFormat through storage operations without specifying the format in the shader. -
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR
indicates that an implementation supports depth comparison performed byOpImage*Dref*
instructions on a given VkFormat. Previously the result of executing aOpImage*Dref*
instruction on an image view, where theformat
was not one of the depth/stencil formats with a depth component, was undefined. This bit clarifies on which formats such instructions can be used.
Prior to version 2 of this extension, implementations exposing the
shaderStorageImageReadWithoutFormat
and
shaderStorageImageWriteWithoutFormat
features may not report
VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR
and
VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR
in
VkFormatProperties3KHR::bufferFeatures
.
Despite this, buffer reads/writes are supported as intended by the original
features.
New Structures
-
Extending VkFormatProperties2:
New Enum Constants
-
VK_KHR_FORMAT_FEATURE_FLAGS_2_EXTENSION_NAME
-
VK_KHR_FORMAT_FEATURE_FLAGS_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3_KHR
-
VK_KHR_get_memory_requirements2
- Name String
-
VK_KHR_get_memory_requirements2
- Extension Type
-
Device extension
- Registered Extension Number
-
147
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Faith Ekstrand gfxstrand
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Faith Ekstrand, Intel
-
Jeff Bolz, NVIDIA
-
Jesse Hall, Google
-
Description
This extension provides new queries for memory requirements of images and
buffers that can be easily extended by other extensions, without introducing
any further entry points.
The Vulkan 1.0 VkMemoryRequirements and
VkSparseImageMemoryRequirements structures do not include sType
and pNext
members.
This extension wraps them in new structures with these members, so an
application can query a chain of memory requirements structures by
constructing the chain and letting the implementation fill them in.
A new command is added for each vkGet*MemoryRequrements
command in
core Vulkan 1.0.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME
-
VK_KHR_GET_MEMORY_REQUIREMENTS_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BUFFER_MEMORY_REQUIREMENTS_INFO_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_SPARSE_MEMORY_REQUIREMENTS_INFO_2_KHR
-
VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR
-
VK_STRUCTURE_TYPE_SPARSE_IMAGE_MEMORY_REQUIREMENTS_2_KHR
-
VK_KHR_get_physical_device_properties2
- Name String
-
VK_KHR_get_physical_device_properties2
- Extension Type
-
Instance extension
- Registered Extension Number
-
60
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Ian Elliott, Google
-
Description
This extension provides new queries for device features, device properties,
and format properties that can be easily extended by other extensions,
without introducing any further queries.
The Vulkan 1.0 feature/limit/formatproperty structures do not include
sType
/pNext
members.
This extension wraps them in new structures with sType
/pNext
members, so an application can query a chain of feature/limit/formatproperty
structures by constructing the chain and letting the implementation fill
them in.
A new command is added for each vkGetPhysicalDevice*
command in core
Vulkan 1.0.
The new feature structure (and a pNext
chain of extending structures)
can also be passed in to device creation to enable features.
This extension also allows applications to use the physical-device components of device extensions before vkCreateDevice is called.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME
-
VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SPARSE_IMAGE_FORMAT_INFO_2_KHR
-
VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2_KHR
-
VK_STRUCTURE_TYPE_SPARSE_IMAGE_FORMAT_PROPERTIES_2_KHR
-
Examples
// Get features with a hypothetical future extension.
VkHypotheticalExtensionFeaturesKHR hypotheticalFeatures =
{
.sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
.pNext = NULL,
};
VkPhysicalDeviceFeatures2KHR features =
{
.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
.pNext = &hypotheticalFeatures,
};
// After this call, features and hypotheticalFeatures have been filled out.
vkGetPhysicalDeviceFeatures2KHR(physicalDevice, &features);
// Properties/limits can be chained and queried similarly.
// Enable some features:
VkHypotheticalExtensionFeaturesKHR enabledHypotheticalFeatures =
{
.sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
.pNext = NULL,
};
VkPhysicalDeviceFeatures2KHR enabledFeatures =
{
.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
.pNext = &enabledHypotheticalFeatures,
};
enabledFeatures.features.xyz = VK_TRUE;
enabledHypotheticalFeatures.abc = VK_TRUE;
VkDeviceCreateInfo deviceCreateInfo =
{
.sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
.pNext = &enabledFeatures,
...
.pEnabledFeatures = NULL,
};
VkDevice device;
vkCreateDevice(physicalDevice, &deviceCreateInfo, NULL, &device);
VK_KHR_image_format_list
- Name String
-
VK_KHR_image_format_list
- Extension Type
-
Device extension
- Registered Extension Number
-
148
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Faith Ekstrand gfxstrand
-
Other Extension Metadata
- Last Modified Date
-
2017-03-20
- IP Status
-
No known IP claims.
- Contributors
-
-
Faith Ekstrand, Intel
-
Jan-Harald Fredriksen, ARM
-
Jeff Bolz, NVIDIA
-
Jeff Leger, Qualcomm
-
Neil Henning, Codeplay
-
Description
On some implementations, setting the
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
on image creation can cause access
to that image to perform worse than an equivalent image created without
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
because the implementation does not
know what view formats will be paired with the image.
This extension allows an application to provide the list of all formats that can be used with an image when it is created. The implementation may then be able to create a more efficient image that supports the subset of formats required by the application without having to support all formats in the format compatibility class of the image format.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_IMAGE_FORMAT_LIST_EXTENSION_NAME
-
VK_KHR_IMAGE_FORMAT_LIST_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_IMAGE_FORMAT_LIST_CREATE_INFO_KHR
-
VK_KHR_imageless_framebuffer
- Name String
-
VK_KHR_imageless_framebuffer
- Extension Type
-
Device extension
- Registered Extension Number
-
109
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Tobias Hector tobias
-
Description
This extension allows framebuffers to be created without the need for creating images first, allowing more flexibility in how they are used, and avoiding the need for many of the confusing compatibility rules.
Framebuffers are now created with a small amount of additional metadata about the image views that will be used in VkFramebufferAttachmentsCreateInfoKHR, and the actual image views are provided at render pass begin time via VkRenderPassAttachmentBeginInfoKHR.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_IMAGELESS_FRAMEBUFFER_EXTENSION_NAME
-
VK_KHR_IMAGELESS_FRAMEBUFFER_SPEC_VERSION
-
Extending VkFramebufferCreateFlagBits:
-
VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENTS_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENT_IMAGE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES_KHR
-
VK_STRUCTURE_TYPE_RENDER_PASS_ATTACHMENT_BEGIN_INFO_KHR
-
VK_KHR_maintenance1
- Name String
-
VK_KHR_maintenance1
- Extension Type
-
Device extension
- Registered Extension Number
-
70
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2018-03-13
- Contributors
-
-
Dan Ginsburg, Valve
-
Daniel Koch, NVIDIA
-
Daniel Rakos, AMD
-
Jan-Harald Fredriksen, ARM
-
Faith Ekstrand, Intel
-
Jeff Bolz, NVIDIA
-
Jesse Hall, Google
-
John Kessenich, Google
-
Michael Worcester, Imagination Technologies
-
Neil Henning, Codeplay Software Ltd.
-
Piers Daniell, NVIDIA
-
Slawomir Grajewski, Intel
-
Tobias Hector, Imagination Technologies
-
Tom Olson, ARM
-
Description
VK_KHR_maintenance1
adds a collection of minor features that were
intentionally left out or overlooked from the original Vulkan 1.0 release.
The new features are as follows:
-
Allow 2D and 2D array image views to be created from 3D images, which can then be used as color framebuffer attachments. This allows applications to render to slices of a 3D image.
-
Support vkCmdCopyImage between 2D array layers and 3D slices. This extension allows copying from layers of a 2D array image to slices of a 3D image and vice versa.
-
Allow negative height to be specified in the VkViewport::
height
field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to usegl_Position.y = -gl_Position.y
in shaders also targeting other APIs. -
Allow implementations to express support for doing just transfers and clears of image formats that they otherwise support no other format features for. This is done by adding new format feature flags
VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
andVK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR
. -
Support vkCmdFillBuffer on transfer-only queues. Previously vkCmdFillBuffer was defined to only work on command buffers allocated from command pools which support graphics or compute queues. It is now allowed on queues that just support transfer operations.
-
Fix the inconsistency of how error conditions are returned between the vkCreateGraphicsPipelines and vkCreateComputePipelines functions and the vkAllocateDescriptorSets and vkAllocateCommandBuffers functions.
-
Add new
VK_ERROR_OUT_OF_POOL_MEMORY_KHR
error so implementations can give a more precise reason for vkAllocateDescriptorSets failures. -
Add a new command vkTrimCommandPoolKHR which gives the implementation an opportunity to release any unused command pool memory back to the system.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_MAINTENANCE1_EXTENSION_NAME
-
VK_KHR_MAINTENANCE1_SPEC_VERSION
-
VK_KHR_MAINTENANCE_1_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_1_SPEC_VERSION
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR
-
VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR
-
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT_KHR
-
-
Extending VkResult:
-
VK_ERROR_OUT_OF_POOL_MEMORY_KHR
-
VK_KHR_maintenance2
- Name String
-
VK_KHR_maintenance2
- Extension Type
-
Device extension
- Registered Extension Number
-
118
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Michael Worcester michaelworcester
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- Contributors
-
-
Michael Worcester, Imagination Technologies
-
Stuart Smith, Imagination Technologies
-
Jeff Bolz, NVIDIA
-
Daniel Koch, NVIDIA
-
Jan-Harald Fredriksen, ARM
-
Daniel Rakos, AMD
-
Neil Henning, Codeplay
-
Piers Daniell, NVIDIA
-
Description
VK_KHR_maintenance2
adds a collection of minor features that were
intentionally left out or overlooked from the original Vulkan 1.0 release.
The new features are as follows:
-
Allow the application to specify which aspect of an input attachment might be read for a given subpass.
-
Allow implementations to express the clipping behavior of points.
-
Allow creating images with usage flags that may not be supported for the base image’s format, but are supported for image views of the image that have a different but compatible format.
-
Allow creating uncompressed image views of compressed images.
-
Allow the application to select between an upper-left and lower-left origin for the tessellation domain space.
-
Adds two new image layouts for depth stencil images to allow either the depth or stencil aspect to be read-only while the other aspect is writable.
Input Attachment Specification
Input attachment specification allows an application to specify which aspect
of a multi-aspect image (e.g. a depth/stencil format) will be accessed via a
subpassLoad
operation.
On some implementations there may be a performance penalty if the implementation does not know (at vkCreateRenderPass time) which aspect(s) of multi-aspect images can be accessed as input attachments.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Structures
-
Extending VkImageViewCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkPipelineTessellationStateCreateInfo:
-
Extending VkRenderPassCreateInfo:
New Enum Constants
-
VK_KHR_MAINTENANCE2_EXTENSION_NAME
-
VK_KHR_MAINTENANCE2_SPEC_VERSION
-
VK_KHR_MAINTENANCE_2_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_2_SPEC_VERSION
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR
-
VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR
-
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR
-
-
Extending VkPointClippingBehavior:
-
VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR
-
VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR
-
-
Extending VkTessellationDomainOrigin:
-
VK_TESSELLATION_DOMAIN_ORIGIN_LOWER_LEFT_KHR
-
VK_TESSELLATION_DOMAIN_ORIGIN_UPPER_LEFT_KHR
-
Input Attachment Specification Example
Consider the case where a render pass has two subpasses and two attachments.
Attachment 0 has the format VK_FORMAT_D24_UNORM_S8_UINT
, attachment 1
has some color format.
Subpass 0 writes to attachment 0, subpass 1 reads only the depth information from attachment 0 (using inputAttachmentRead) and writes to attachment 1.
VkInputAttachmentAspectReferenceKHR references[] = {
{
.subpass = 1,
.inputAttachmentIndex = 0,
.aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
}
};
VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
.sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
.pNext = NULL,
.aspectReferenceCount = 1,
.pAspectReferences = references
};
VkRenderPassCreateInfo createInfo = {
...
.pNext = &specifyAspects,
...
};
vkCreateRenderPass(...);
Issues
1) What is the default tessellation domain origin?
RESOLVED: Vulkan 1.0 originally inadvertently documented a lower-left origin, but the conformance tests and all implementations implemented an upper-left origin. This extension adds a control to select between lower-left (for compatibility with OpenGL) and upper-left, and we retroactively fix unextended Vulkan to have a default of an upper-left origin.
VK_KHR_maintenance3
- Name String
-
VK_KHR_maintenance3
- Extension Type
-
Device extension
- Registered Extension Number
-
169
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Description
VK_KHR_maintenance3
adds a collection of minor features that were
intentionally left out or overlooked from the original Vulkan 1.0 release.
The new features are as follows:
-
A limit on the maximum number of descriptors that are supported in a single descriptor set layout. Some implementations have a limit on the total size of descriptors in a set, which cannot be expressed in terms of the limits in Vulkan 1.0.
-
A limit on the maximum size of a single memory allocation. Some platforms have kernel interfaces that limit the maximum size of an allocation.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_MAINTENANCE3_EXTENSION_NAME
-
VK_KHR_MAINTENANCE3_SPEC_VERSION
-
VK_KHR_MAINTENANCE_3_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_3_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_SUPPORT_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES_KHR
-
VK_KHR_maintenance4
- Name String
-
VK_KHR_maintenance4
- Extension Type
-
Device extension
- Registered Extension Number
-
414
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2021-10-25
- Interactions and External Dependencies
-
-
Requires SPIR-V 1.2 for
LocalSizeId
-
- Contributors
-
-
Lionel Duc, NVIDIA
-
Faith Ekstrand, Intel
-
Spencer Fricke, Samsung
-
Tobias Hector, AMD
-
Lionel Landwerlin, Intel
-
Graeme Leese, Broadcom
-
Tom Olson, Arm
-
Stu Smith, AMD
-
Yiwei Zhang, Google
-
Description
VK_KHR_maintenance4
adds a collection of minor features, none of which
would warrant an entire extension of their own.
The new features are as follows:
-
Allow the application to destroy their VkPipelineLayout object immediately after it was used to create another object. It is no longer necessary to keep its handle valid while the created object is in use.
-
Add a new
maxBufferSize
implementation-defined limit for the maximum sizeVkBuffer
that can be created. -
Add support for the SPIR-V 1.2
LocalSizeId
execution mode, which can be used as an alternative toLocalSize
to specify the local workgroup size with specialization constants. -
Add a guarantee that images created with identical creation parameters will always have the same alignment requirements.
-
Add new vkGetDeviceBufferMemoryRequirementsKHR, vkGetDeviceImageMemoryRequirementsKHR, and vkGetDeviceImageSparseMemoryRequirementsKHR to allow the application to query the image memory requirements without having to create an image object and query it.
-
Relax the requirement that push constants must be initialized before they are dynamically accessed.
-
Relax the interface matching rules to allow a larger output vector to match with a smaller input vector, with additional values being discarded.
-
Add a guarantee for buffer memory requirement that the size memory requirement is never greater than the result of aligning create size with the alignment memory requirement.
New Enum Constants
-
VK_KHR_MAINTENANCE_4_EXTENSION_NAME
-
VK_KHR_MAINTENANCE_4_SPEC_VERSION
-
Extending VkImageAspectFlagBits:
-
VK_IMAGE_ASPECT_NONE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_DEVICE_BUFFER_MEMORY_REQUIREMENTS_KHR
-
VK_STRUCTURE_TYPE_DEVICE_IMAGE_MEMORY_REQUIREMENTS_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_PROPERTIES_KHR
-
VK_KHR_multiview
- Name String
-
VK_KHR_multiview
- Extension Type
-
Device extension
- Registered Extension Number
-
54
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2016-10-28
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_EXT_multiview
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Description
This extension has the same goal as the OpenGL ES GL_OVR_multiview
extension.
Multiview is a rendering technique originally designed for VR where it is
more efficient to record a single set of commands to be executed with
slightly different behavior for each “view”.
It includes a concise way to declare a render pass with multiple views, and
gives implementations freedom to render the views in the most efficient way
possible.
This is done with a multiview configuration specified during render pass creation with the VkRenderPassMultiviewCreateInfo passed
into VkRenderPassCreateInfo::pNext
.
This extension enables the use of the
SPV_KHR_multiview
shader extension,
which adds a new ViewIndex
built-in type that allows shaders to control
what to do for each view.
If using GLSL there is also the
GL_EXT_multiview
extension that
introduces a highp int gl_ViewIndex;
built-in variable for vertex,
tessellation, geometry, and fragment shaders.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_MULTIVIEW_EXTENSION_NAME
-
VK_KHR_MULTIVIEW_SPEC_VERSION
-
Extending VkDependencyFlagBits:
-
VK_DEPENDENCY_VIEW_LOCAL_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR
-
VK_KHR_relaxed_block_layout
- Name String
-
VK_KHR_relaxed_block_layout
- Extension Type
-
Device extension
- Registered Extension Number
-
145
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
John Kessenich johnkslang
-
Other Extension Metadata
- Last Modified Date
-
2017-03-26
- IP Status
-
No known IP claims.
- Contributors
-
-
John Kessenich, Google
-
Description
The VK_KHR_relaxed_block_layout
extension allows implementations to
indicate they can support more variation in block Offset
decorations.
For example, placing a vector of three floats at an offset of
16×N + 4.
See Offset and Stride Assignment for details.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
VK_KHR_sampler_mirror_clamp_to_edge
- Name String
-
VK_KHR_sampler_mirror_clamp_to_edge
- Extension Type
-
Device extension
- Registered Extension Number
-
15
- Revision
-
3
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Tobias Hector tobski
-
Other Extension Metadata
- Last Modified Date
-
2019-08-17
- Contributors
-
-
Tobias Hector, Imagination Technologies
-
Jon Leech, Khronos
-
Description
VK_KHR_sampler_mirror_clamp_to_edge
extends the set of sampler address
modes to include an additional mode
(VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
) that effectively uses a
texture map twice as large as the original image in which the additional
half of the new image is a mirror image of the original image.
This new mode relaxes the need to generate images whose opposite edges match by using the original image to generate a matching “mirror image”. This mode allows the texture to be mirrored only once in the negative s, t, and r directions.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2.
However, if Vulkan 1.2 is supported and this extension is not, the
VkSamplerAddressMode
VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
is optional.
Since the original extension did not use an author suffix on the enum
VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
, it is used by both core
and extension implementations.
New Enum Constants
-
VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_EXTENSION_NAME
-
VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_SPEC_VERSION
-
Extending VkSamplerAddressMode:
-
VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
-
VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE_KHR
-
Example
Creating a sampler with the new address mode in each dimension
VkSamplerCreateInfo createInfo =
{
.sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
// Other members set to application-desired values
};
createInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
createInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
createInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
VkSampler sampler;
VkResult result = vkCreateSampler(
device,
&createInfo,
&sampler);
Issues
1) Why are both KHR and core versions of the
VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE
token present?
RESOLVED: This functionality was intended to be required in Vulkan 1.0. We realized shortly before public release that not all implementations could support it, and moved the functionality into an optional extension, but did not apply the KHR extension suffix. Adding a KHR-suffixed alias of the non-suffixed enum has been done to comply with our own naming rules.
In a related change, before spec revision 1.1.121 this extension was hardwiring into the spec Makefile so it was always included with the Specification, even in the core-only versions. This has now been reverted, and it is treated as any other extension.
VK_KHR_sampler_ycbcr_conversion
- Name String
-
VK_KHR_sampler_ycbcr_conversion
- Extension Type
-
Device extension
- Registered Extension Number
-
157
- Revision
-
14
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_EXT_debug_report
-
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Andrew Garrard fluppeteer
-
Other Extension Metadata
- Last Modified Date
-
2017-08-11
- IP Status
-
No known IP claims.
- Contributors
-
-
Andrew Garrard, Samsung Electronics
-
Tobias Hector, Imagination Technologies
-
James Jones, NVIDIA
-
Daniel Koch, NVIDIA
-
Daniel Rakos, AMD
-
Romain Guy, Google
-
Jesse Hall, Google
-
Tom Cooksey, ARM Ltd
-
Jeff Leger, Qualcomm Technologies, Inc
-
Jan-Harald Fredriksen, ARM Ltd
-
Jan Outters, Samsung Electronics
-
Alon Or-bach, Samsung Electronics
-
Michael Worcester, Imagination Technologies
-
Jeff Bolz, NVIDIA
-
Tony Zlatinski, NVIDIA
-
Matthew Netsch, Qualcomm Technologies, Inc
-
Description
The use of Y′CBCR sampler conversion is an area in 3D graphics not used by most Vulkan developers. It is mainly used for processing inputs from video decoders and cameras. The use of the extension assumes basic knowledge of Y′CBCR concepts.
This extension provides the ability to perform specified color space conversions during texture sampling operations for the Y′CBCR color space natively. It also adds a selection of multi-planar formats, image aspect plane, and the ability to bind memory to the planes of an image collectively or separately.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted.
However, if Vulkan 1.1 is supported and this extension is not, the
samplerYcbcrConversion
capability is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Structures
-
Extending VkBindImageMemoryInfo:
-
Extending VkImageFormatProperties2:
-
Extending VkImageMemoryRequirementsInfo2:
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkSamplerCreateInfo, VkImageViewCreateInfo:
New Enum Constants
-
VK_KHR_SAMPLER_YCBCR_CONVERSION_EXTENSION_NAME
-
VK_KHR_SAMPLER_YCBCR_CONVERSION_SPEC_VERSION
-
Extending VkChromaLocation:
-
VK_CHROMA_LOCATION_COSITED_EVEN_KHR
-
VK_CHROMA_LOCATION_MIDPOINT_KHR
-
-
Extending VkFormat:
-
VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16_KHR
-
VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16_KHR
-
VK_FORMAT_B16G16R16G16_422_UNORM_KHR
-
VK_FORMAT_B8G8R8G8_422_UNORM_KHR
-
VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16_KHR
-
VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16_KHR
-
VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16_KHR
-
VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16_KHR
-
VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16_KHR
-
VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16_KHR
-
VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16_KHR
-
VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16_KHR
-
VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16_KHR
-
VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16_KHR
-
VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16_KHR
-
VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16_KHR
-
VK_FORMAT_G16B16G16R16_422_UNORM_KHR
-
VK_FORMAT_G16_B16R16_2PLANE_420_UNORM_KHR
-
VK_FORMAT_G16_B16R16_2PLANE_422_UNORM_KHR
-
VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM_KHR
-
VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM_KHR
-
VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM_KHR
-
VK_FORMAT_G8B8G8R8_422_UNORM_KHR
-
VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR
-
VK_FORMAT_G8_B8R8_2PLANE_422_UNORM_KHR
-
VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM_KHR
-
VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM_KHR
-
VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM_KHR
-
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16_KHR
-
VK_FORMAT_R10X6G10X6_UNORM_2PACK16_KHR
-
VK_FORMAT_R10X6_UNORM_PACK16_KHR
-
VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16_KHR
-
VK_FORMAT_R12X4G12X4_UNORM_2PACK16_KHR
-
VK_FORMAT_R12X4_UNORM_PACK16_KHR
-
-
Extending VkFormatFeatureFlagBits:
-
VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT_KHR
-
VK_FORMAT_FEATURE_DISJOINT_BIT_KHR
-
VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT_KHR
-
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR
-
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR
-
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR
-
VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR
-
-
Extending VkImageAspectFlagBits:
-
VK_IMAGE_ASPECT_PLANE_0_BIT_KHR
-
VK_IMAGE_ASPECT_PLANE_1_BIT_KHR
-
VK_IMAGE_ASPECT_PLANE_2_BIT_KHR
-
-
Extending VkImageCreateFlagBits:
-
VK_IMAGE_CREATE_DISJOINT_BIT_KHR
-
-
Extending VkObjectType:
-
VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR
-
-
Extending VkSamplerYcbcrModelConversion:
-
VK_SAMPLER_YCBCR_MODEL_CONVERSION_RGB_IDENTITY_KHR
-
VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020_KHR
-
VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601_KHR
-
VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_709_KHR
-
VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_IDENTITY_KHR
-
-
Extending VkSamplerYcbcrRange:
-
VK_SAMPLER_YCBCR_RANGE_ITU_FULL_KHR
-
VK_SAMPLER_YCBCR_RANGE_ITU_NARROW_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BIND_IMAGE_PLANE_MEMORY_INFO_KHR
-
VK_STRUCTURE_TYPE_IMAGE_PLANE_MEMORY_REQUIREMENTS_INFO_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES_KHR
-
VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_IMAGE_FORMAT_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO_KHR
-
Version History
-
Revision 1, 2017-01-24 (Andrew Garrard)
-
Initial draft
-
-
Revision 2, 2017-01-25 (Andrew Garrard)
-
After initial feedback
-
-
Revision 3, 2017-01-27 (Andrew Garrard)
-
Higher bit depth formats, renaming, swizzle
-
-
Revision 4, 2017-02-22 (Andrew Garrard)
-
Added query function, formats as RGB, clarifications
-
-
Revision 5, 2017-04-?? (Andrew Garrard)
-
Simplified query and removed output conversions
-
-
Revision 6, 2017-04-24 (Andrew Garrard)
-
Tidying, incorporated new image query, restored transfer functions
-
-
Revision 7, 2017-04-25 (Andrew Garrard)
-
Added cosited option/midpoint requirement for formats, “bypassConversion”
-
-
Revision 8, 2017-04-25 (Andrew Garrard)
-
Simplified further
-
-
Revision 9, 2017-04-27 (Andrew Garrard)
-
Disjoint no more
-
-
Revision 10, 2017-04-28 (Andrew Garrard)
-
Restored disjoint
-
-
Revision 11, 2017-04-29 (Andrew Garrard)
-
Now Ycbcr conversion, and KHR
-
-
Revision 12, 2017-06-06 (Andrew Garrard)
-
Added conversion to image view creation
-
-
Revision 13, 2017-07-13 (Andrew Garrard)
-
Allowed cosited-only chroma samples for formats
-
-
Revision 14, 2017-08-11 (Andrew Garrard)
-
Reflected quantization changes in BT.2100-1
-
VK_KHR_separate_depth_stencil_layouts
- Name String
-
VK_KHR_separate_depth_stencil_layouts
- Extension Type
-
Device extension
- Registered Extension Number
-
242
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Piers Daniell pdaniell-nv
-
Other Extension Metadata
- Last Modified Date
-
2019-06-25
- Contributors
-
-
Daniel Koch, NVIDIA
-
Jeff Bolz, NVIDIA
-
Jesse Barker, Unity
-
Tobias Hector, AMD
-
Description
This extension allows image memory barriers for depth/stencil images to have
just one of the VK_IMAGE_ASPECT_DEPTH_BIT
or
VK_IMAGE_ASPECT_STENCIL_BIT
aspect bits set, rather than require both.
This allows their layouts to be set independently.
To support depth/stencil images with different layouts for the depth and
stencil aspects, the depth/stencil attachment interface has been updated to
support a separate layout for stencil.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_EXTENSION_NAME
-
VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_SPEC_VERSION
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL_KHR
-
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR
-
VK_IMAGE_LAYOUT_STENCIL_ATTACHMENT_OPTIMAL_KHR
-
VK_IMAGE_LAYOUT_STENCIL_READ_ONLY_OPTIMAL_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_STENCIL_LAYOUT_KHR
-
VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_STENCIL_LAYOUT_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SEPARATE_DEPTH_STENCIL_LAYOUTS_FEATURES_KHR
-
VK_KHR_shader_atomic_int64
- Name String
-
VK_KHR_shader_atomic_int64
- Extension Type
-
Device extension
- Registered Extension Number
-
181
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Aaron Hagan ahagan
-
Other Extension Metadata
- Last Modified Date
-
2018-07-05
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_ARB_gpu_shader_int64
andGL_EXT_shader_atomic_int64
-
- Contributors
-
-
Aaron Hagan, AMD
-
Daniel Rakos, AMD
-
Jeff Bolz, NVIDIA
-
Neil Henning, Codeplay
-
Description
This extension advertises the SPIR-V Int64Atomics capability for Vulkan, which allows a shader to contain 64-bit atomic operations on signed and unsigned integers. The supported operations include OpAtomicMin, OpAtomicMax, OpAtomicAnd, OpAtomicOr, OpAtomicXor, OpAtomicAdd, OpAtomicExchange, and OpAtomicCompareExchange.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
KHR suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
shaderBufferInt64Atomics
capability is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME
-
VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR
-
VK_KHR_shader_draw_parameters
- Name String
-
VK_KHR_shader_draw_parameters
- Extension Type
-
Device extension
- Registered Extension Number
-
64
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Daniel Koch dgkoch
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_ARB_shader_draw_parameters
-
- Contributors
-
-
Daniel Koch, NVIDIA Corporation
-
Jeff Bolz, NVIDIA
-
Daniel Rakos, AMD
-
Jan-Harald Fredriksen, ARM
-
John Kessenich, Google
-
Stuart Smith, IMG
-
Description
This extension adds support for the following SPIR-V extension in Vulkan:
-
SPV_KHR_shader_draw_parameters
The extension provides access to three additional built-in shader variables in Vulkan:
-
BaseInstance
, containing thefirstInstance
parameter passed to drawing commands, -
BaseVertex
, containing thefirstVertex
orvertexOffset
parameter passed to drawing commands, and -
DrawIndex
, containing the index of the draw call currently being processed from an indirect drawing call.
When using GLSL source-based shader languages, the following variables from
GL_ARB_shader_draw_parameters
can map to these SPIR-V built-in
decorations:
-
in int gl_BaseInstanceARB;
→BaseInstance
, -
in int gl_BaseVertexARB;
→BaseVertex
, and -
in int gl_DrawIDARB;
→DrawIndex
.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1.
However, the shaderDrawParameters
feature bit was added to distinguish whether it is actually available or
not.
New Enum Constants
-
VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME
-
VK_KHR_SHADER_DRAW_PARAMETERS_SPEC_VERSION
Issues
1) Is this the same functionality as GL_ARB_shader_draw_parameters
?
RESOLVED: It is actually a superset, as it also adds in support for arrayed drawing commands.
In GL for GL_ARB_shader_draw_parameters
, gl_BaseVertexARB
holds the
integer value passed to the parameter to the command that resulted in the
current shader invocation.
In the case where the command has no baseVertex
parameter, the value of
gl_BaseVertexARB
is zero.
This means that gl_BaseVertexARB
= baseVertex
(for
glDrawElements
commands with baseVertex
) or 0.
In particular there are no glDrawArrays
commands that take a
baseVertex
parameter.
Now in Vulkan, we have BaseVertex
= vertexOffset
(for indexed
drawing commands) or firstVertex
(for arrayed drawing commands), and
so Vulkan’s version is really a superset of GL functionality.
VK_KHR_shader_float16_int8
- Name String
-
VK_KHR_shader_float16_int8
- Extension Type
-
Device extension
- Registered Extension Number
-
83
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Alexander Galazin alegal-arm
-
Other Extension Metadata
- Last Modified Date
-
2018-03-07
- Interactions and External Dependencies
-
-
This extension interacts with
VK_KHR_8bit_storage
-
This extension interacts with
VK_KHR_16bit_storage
-
This extension interacts with
VK_KHR_shader_float_controls
-
This extension provides API support for
GL_EXT_shader_explicit_arithmetic_types
-
- IP Status
-
No known IP claims.
- Contributors
-
-
Alexander Galazin, Arm
-
Jan-Harald Fredriksen, Arm
-
Jeff Bolz, NVIDIA
-
Graeme Leese, Broadcom
-
Daniel Rakos, AMD
-
Description
The VK_KHR_shader_float16_int8
extension allows use of 16-bit
floating-point types and 8-bit integer types in shaders for arithmetic
operations.
It introduces two new optional features shaderFloat16
and
shaderInt8
which directly map to the Float16
and the Int8
SPIR-V capabilities.
The VK_KHR_shader_float16_int8
extension also specifies precision
requirements for half-precision floating-point SPIR-V operations.
This extension does not enable use of 8-bit integer types or 16-bit
floating-point types in any shader input and
output interfaces and therefore does not supersede the
VK_KHR_8bit_storage
or VK_KHR_16bit_storage
extensions.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
KHR suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, both the
shaderFloat16
and shaderInt8
capabilities are optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_SHADER_FLOAT16_INT8_EXTENSION_NAME
-
VK_KHR_SHADER_FLOAT16_INT8_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT16_INT8_FEATURES_KHR
-
VK_KHR_shader_float_controls
- Name String
-
VK_KHR_shader_float_controls
- Extension Type
-
Device extension
- Registered Extension Number
-
198
- Revision
-
4
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Alexander Galazin alegal-arm
-
Other Extension Metadata
- Last Modified Date
-
2018-09-11
- IP Status
-
No known IP claims.
- Contributors
-
-
Alexander Galazin, Arm
-
Jan-Harald Fredriksen, Arm
-
Jeff Bolz, NVIDIA
-
Graeme Leese, Broadcom
-
Daniel Rakos, AMD
-
Description
The VK_KHR_shader_float_controls
extension enables efficient use of
floating-point computations through the ability to query and override the
implementation’s default behavior for rounding modes, denormals, signed
zero, and infinity.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_SHADER_FLOAT_CONTROLS_EXTENSION_NAME
-
VK_KHR_SHADER_FLOAT_CONTROLS_SPEC_VERSION
-
Extending VkShaderFloatControlsIndependence:
-
VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY_KHR
-
VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_ALL_KHR
-
VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_NONE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
-
Issues
1) Which instructions must flush denorms?
RESOLVED: Only floating-point conversion, floating-point arithmetic,
floating-point relational (except OpIsNaN
, OpIsInf
), and
floating-point GLSL.std.450 extended instructions must flush denormals.
2) What is the denorm behavior for intermediate results?
RESOLVED: When a SPIR-V instruction is implemented as a sequence of other instructions:
-
in the
DenormFlushToZero
execution mode, the intermediate instructions may flush denormals, the final result of the sequence must not be denormal. -
in the
DenormPreserve
execution mode, denormals must be preserved throughout the whole sequence.
3) Do denorm and rounding mode controls apply to OpSpecConstantOp
?
RESOLVED: Yes, except when the opcode is OpQuantizeToF16
.
4) The SPIR-V specification says that OpConvertFToU
and
OpConvertFToS
unconditionally round towards zero.
Do the rounding mode controls specified through the execution modes apply to
them?
RESOLVED: No, these instructions unconditionally round towards zero.
5) Do any of the “Pack” GLSL.std.450 instructions count as conversion instructions and have the rounding mode applied?
RESOLVED: No, only instructions listed in “section 3.32.11. Conversion Instructions” of the SPIR-V specification count as conversion instructions.
6) When using inf/nan-ignore mode, what is expected of OpIsNan
and
OpIsInf
?
RESOLVED: These instructions must always accurately detect inf/nan if it is passed to them.
Version 4 API Incompatibility
The original versions of VK_KHR_shader_float_controls
shipped with
booleans named “separateDenormSettings” and
“separateRoundingModeSettings”, which at first glance could have indicated
“they can all be set independently, or not”.
However the spec language as written indicated that the 32-bit value could
always be set independently, and only the 16- and 64-bit controls needed to
be the same if these values were VK_FALSE
.
As a result of this slight disparity, and lack of test coverage for this facet of the extension, we ended up with two different behaviors in the wild, where some implementations worked as written, and others worked based on the naming. As these are hard limits in hardware with reasons for exposure as written, it was not possible to standardize on a single way to make this work within the existing API.
No known users of this part of the extension exist in the wild, and as such the Vulkan WG took the unusual step of retroactively changing the once boolean value into a tri-state enum, breaking source compatibility. This was however done in such a way as to retain ABI compatibility, in case any code using this did exist; with the numerical values 0 and 1 retaining their original specified meaning, and a new value signifying the additional “all need to be set together” state. If any applications exist today, compiled binaries will continue to work as written in most cases, but will need changes before the code can be recompiled.
Version History
-
Revision 4, 2019-06-18 (Tobias Hector)
-
Modified settings restrictions, see Version 4 API incompatibility
-
-
Revision 3, 2018-09-11 (Alexander Galazin)
-
Minor restructuring
-
-
Revision 2, 2018-04-17 (Alexander Galazin)
-
Added issues and resolutions
-
-
Revision 1, 2018-04-11 (Alexander Galazin)
-
Initial draft
-
VK_KHR_shader_integer_dot_product
- Name String
-
VK_KHR_shader_integer_dot_product
- Extension Type
-
Device extension
- Registered Extension Number
-
281
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Kevin Petit kpet
-
- Extension Proposal
Other Extension Metadata
- Last Modified Date
-
2021-06-16
- Interactions and External Dependencies
-
-
This extension interacts with
VK_KHR_shader_float16_int8
.
-
- IP Status
-
No known IP claims.
- Contributors
-
-
Kévin Petit, Arm Ltd.
-
Jeff Bolz, NVidia
-
Spencer Fricke, Samsung
-
Jesse Hall, Google
-
John Kessenich, Google
-
Graeme Leese, Broadcom
-
Einar Hov, Arm Ltd.
-
Stuart Brady, Arm Ltd.
-
Pablo Cascon, Arm Ltd.
-
Tobias Hector, AMD
-
Jeff Leger, Qualcomm
-
Ruihao Zhang, Qualcomm
-
Pierre Boudier, NVidia
-
Jon Leech, The Khronos Group
-
Tom Olson, Arm Ltd.
-
Description
This extension adds support for the integer dot product SPIR-V instructions defined in SPV_KHR_integer_dot_product. These instructions are particularly useful for neural network inference and training but find uses in other general-purpose compute applications as well.
New Enum Constants
-
VK_KHR_SHADER_INTEGER_DOT_PRODUCT_EXTENSION_NAME
-
VK_KHR_SHADER_INTEGER_DOT_PRODUCT_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_PROPERTIES_KHR
-
Promotion to Vulkan 1.3
Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
VK_KHR_shader_non_semantic_info
- Name String
-
VK_KHR_shader_non_semantic_info
- Extension Type
-
Device extension
- Registered Extension Number
-
294
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Baldur Karlsson baldurk
-
Other Extension Metadata
- Last Modified Date
-
2019-10-16
- IP Status
-
No known IP claims.
- Contributors
-
-
Baldur Karlsson, Valve
-
Description
This extension allows the use of the SPV_KHR_non_semantic_info
extension
in SPIR-V shader modules.
New Enum Constants
-
VK_KHR_SHADER_NON_SEMANTIC_INFO_EXTENSION_NAME
-
VK_KHR_SHADER_NON_SEMANTIC_INFO_SPEC_VERSION
Promotion to Vulkan 1.3
Functionality in this extension is included in core Vulkan 1.3 Because the extension has no API controlling its functionality, this results only in a change to the SPIR-V Extensions table.
VK_KHR_shader_subgroup_extended_types
- Name String
-
VK_KHR_shader_subgroup_extended_types
- Extension Type
-
Device extension
- Registered Extension Number
-
176
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Neil Henning sheredom
-
Other Extension Metadata
- Last Modified Date
-
2019-01-08
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GLSL_EXT_shader_subgroup_extended_types
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Jan-Harald Fredriksen, Arm
-
Neil Henning, AMD
-
Daniel Koch, NVIDIA
-
Jeff Leger, Qualcomm
-
Graeme Leese, Broadcom
-
David Neto, Google
-
Daniel Rakos, AMD
-
Description
This extension enables the Non Uniform Group Operations in SPIR-V to support 8-bit integer, 16-bit integer, 64-bit integer, 16-bit floating-point, and vectors of these types.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_EXTENSION_NAME
-
VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_EXTENDED_TYPES_FEATURES_KHR
-
VK_KHR_shader_terminate_invocation
- Name String
-
VK_KHR_shader_terminate_invocation
- Extension Type
-
Device extension
- Registered Extension Number
-
216
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2020-08-11
- IP Status
-
No known IP claims.
- Contributors
-
-
Alan Baker, Google
-
Jeff Bolz, NVIDIA
-
Jesse Hall, Google
-
Ralph Potter, Samsung
-
Tom Olson, Arm
-
Description
This extension adds Vulkan support for the
SPV_KHR_terminate_invocation
SPIR-V extension.
That SPIR-V extension provides a new instruction,
OpTerminateInvocation
, which causes a shader invocation to immediately
terminate and sets the coverage of shaded samples to 0
; only previously
executed instructions will have observable effects.
The OpTerminateInvocation
instruction, along with the
OpDemoteToHelperInvocation
instruction from the
extension, together
replace the VK_EXT_shader_demote_to_helper_invocation
OpKill
instruction, which could behave like either of these
instructions.
OpTerminateInvocation
provides the behavior required by the GLSL
discard
statement, and should be used when available by GLSL compilers
and applications that need the GLSL discard
behavior.
New Enum Constants
-
VK_KHR_SHADER_TERMINATE_INVOCATION_EXTENSION_NAME
-
VK_KHR_SHADER_TERMINATE_INVOCATION_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TERMINATE_INVOCATION_FEATURES_KHR
-
VK_KHR_spirv_1_4
- Name String
-
VK_KHR_spirv_1_4
- Extension Type
-
Device extension
- Registered Extension Number
-
237
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2019-04-01
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
Requires SPIR-V 1.4.
-
- Contributors
-
-
Alexander Galazin, Arm
-
David Neto, Google
-
Jesse Hall, Google
-
John Kessenich, Google
-
Neil Henning, AMD
-
Tom Olson, Arm
-
Description
This extension allows the use of SPIR-V 1.4 shader modules. SPIR-V 1.4’s new features primarily make it an easier target for compilers from high-level languages, rather than exposing new hardware functionality.
SPIR-V 1.4 incorporates features that are also available separately as
extensions.
SPIR-V 1.4 shader modules do not need to enable those extensions with the
OpExtension
opcode, since they are integral parts of SPIR-V 1.4.
SPIR-V 1.4 introduces new floating point execution mode capabilities, also
available via SPV_KHR_float_controls
.
Implementations are not required to support all of these new capabilities;
support can be queried using
VkPhysicalDeviceFloatControlsPropertiesKHR from the
VK_KHR_shader_float_controls
extension.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
Issues
1. Should we have an extension specific to this SPIR-V version, or add a version-generic query for SPIR-V version? SPIR-V 1.4 does not need any other API changes.
RESOLVED: Just expose SPIR-V 1.4.
Most new SPIR-V versions introduce optionally-required capabilities or have implementation-defined limits, and would need more API and specification changes specific to that version to make them available in Vulkan. For example, to support the subgroup capabilities added in SPIR-V 1.3 required introducing VkPhysicalDeviceSubgroupProperties to allow querying the supported group operation categories, maximum supported subgroup size, etc. While we could expose the parts of a new SPIR-V version that do not need accompanying changes generically, we will still end up writing extensions specific to each version for the remaining parts. Thus the generic mechanism will not reduce future spec-writing effort. In addition, making it clear which parts of a future version are supported by the generic mechanism and which cannot be used without specific support would be difficult to get right ahead of time.
2. Can different stages of the same pipeline use shaders with different SPIR-V versions?
RESOLVED: Yes.
Mixing SPIR-V versions 1.0-1.3 in the same pipeline has not been disallowed, so it would be inconsistent to disallow mixing 1.4 with previous versions. SPIR-V 1.4 does not introduce anything that should cause new difficulties here.
3. Must Vulkan extensions corresponding to SPIR-V extensions that were promoted to core in 1.4 be enabled in order to use that functionality in a SPIR-V 1.4 module?
RESOLVED: No, with caveats.
The SPIR-V 1.4 module does not need to declare the SPIR-V extensions, since the functionality is now part of core, so there is no need to enable the Vulkan extension that allows SPIR-V modules to declare the SPIR-V extension. However, when the functionality that is now core in SPIR-V 1.4 is optionally supported, the query for support is provided by a Vulkan extension, and that query can only be used if the extension is enabled.
This applies to any SPIR-V version; specifically for SPIR-V 1.4 this only
applies to the functionality from SPV_KHR_float_controls
, which was made
available in Vulkan by VK_KHR_shader_float_controls
.
Even though the extension was promoted in SPIR-V 1.4, the capabilities are
still optional in implementations that support VK_KHR_spirv_1_4
.
A SPIR-V 1.4 module does not need to enable SPV_KHR_float_controls
in
order to use the capabilities, so if the application has a priori
knowledge that the implementation supports the capabilities, it does not
need to enable VK_KHR_shader_float_controls
.
However, if it does not have this knowledge and has to query for support at
runtime, it must enable VK_KHR_shader_float_controls
in order to
use VkPhysicalDeviceFloatControlsPropertiesKHR.
VK_KHR_storage_buffer_storage_class
- Name String
-
VK_KHR_storage_buffer_storage_class
- Extension Type
-
Device extension
- Registered Extension Number
-
132
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Alexander Galazin alegal-arm
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
Alexander Galazin, ARM
-
David Neto, Google
-
Description
This extension adds support for the following SPIR-V extension in Vulkan:
-
SPV_KHR_storage_buffer_storage_class
This extension provides a new SPIR-V StorageBuffer
storage class.
A Block
-decorated object in this class is equivalent to a
BufferBlock
-decorated object in the Uniform
storage class.
VK_KHR_synchronization2
- Name String
-
VK_KHR_synchronization2
- Extension Type
-
Device extension
- Registered Extension Number
-
315
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- API Interactions
-
-
Interacts with VK_AMD_buffer_marker
-
Interacts with VK_EXT_blend_operation_advanced
-
Interacts with VK_EXT_conditional_rendering
-
Interacts with VK_EXT_fragment_density_map
-
Interacts with VK_EXT_mesh_shader
-
Interacts with VK_EXT_transform_feedback
-
Interacts with VK_KHR_acceleration_structure
-
Interacts with VK_KHR_fragment_shading_rate
-
Interacts with VK_KHR_ray_tracing_pipeline
-
Interacts with VK_NV_device_diagnostic_checkpoints
-
Interacts with VK_NV_device_generated_commands
-
Interacts with VK_NV_mesh_shader
-
Interacts with VK_NV_ray_tracing
-
Interacts with VK_NV_shading_rate_image
-
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Tobias Hector tobski
-
Other Extension Metadata
- Last Modified Date
-
2020-12-03
- Interactions and External Dependencies
-
-
Interacts with
VK_KHR_create_renderpass2
-
- Contributors
-
-
Tobias Hector
-
Description
This extension modifies the original core synchronization APIs to simplify the interface and improve usability of these APIs. It also adds new pipeline stage and access flag types that extend into the 64-bit range, as we have run out within the 32-bit range. The new flags are identical to the old values within the 32-bit range, with new stages and bits beyond that.
Pipeline stages and access flags are now specified together in memory
barrier structures, making the connection between the two more obvious.
Additionally, scoping the pipeline stages into the barrier structs allows
the use of the MEMORY_READ
and MEMORY_WRITE
flags without
sacrificing precision.
The per-stage access flags should be used to disambiguate specific accesses
in a given stage or set of stages - for instance, between uniform reads and
sampling operations.
Layout transitions have been simplified as well; rather than requiring a
different set of layouts for depth/stencil/color attachments, there are
generic VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR
and
VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR
layouts which are contextually
applied based on the image format.
For example, for a depth format image,
VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR
is equivalent to
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR
.
VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR
also functionally replaces
VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL
.
Events are now more efficient, because they include memory dependency information when you set them on the device. Previously, this information was only known when waiting on an event, so the dependencies could not be satisfied until the wait occurred. That sometimes meant stalling the pipeline when the wait occurred. The new API provides enough information for implementations to satisfy these dependencies in parallel with other tasks.
Queue submission has been changed to wrap command buffers and semaphores in
extensible structures, which incorporate changes from Vulkan 1.1,
VK_KHR_device_group
, and VK_KHR_timeline_semaphore
.
This also adds a pipeline stage to the semaphore signal operation, mirroring
the existing pipeline stage specification for wait operations.
Other miscellaneous changes include:
-
Events can now be specified as interacting only with the device, allowing more efficient access to the underlying object.
-
Image memory barriers that do not perform an image layout transition can be specified by setting
oldLayout
equal tonewLayout
.-
E.g. the old and new layout can both be set to
VK_IMAGE_LAYOUT_UNDEFINED
, without discarding data in the image.
-
-
Queue family ownership transfer parameters are simplified in some cases.
-
Where two synchronization commands need to be matched up (queue transfer operations, events), the dependency information specified in each place must now match completely for consistency.
-
Extensions with commands or functions with a VkPipelineStageFlags or VkPipelineStageFlagBits parameter have had those APIs replaced with equivalents using VkPipelineStageFlags2KHR.
-
The new event and barrier interfaces are now more extensible for future changes.
-
Relevant pipeline stage masks can now be specified as empty with the new
VK_PIPELINE_STAGE_NONE_KHR
andVK_PIPELINE_STAGE_2_NONE_KHR
values. -
VkMemoryBarrier2KHR can be chained to VkSubpassDependency2, overriding the original 32-bit stage and access masks.
New Enum Constants
-
VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME
-
VK_KHR_SYNCHRONIZATION_2_SPEC_VERSION
-
Extending VkAccessFlagBits:
-
VK_ACCESS_NONE_KHR
-
-
Extending VkEventCreateFlagBits:
-
VK_EVENT_CREATE_DEVICE_ONLY_BIT_KHR
-
-
Extending VkImageLayout:
-
VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR
-
VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR
-
-
Extending VkPipelineStageFlagBits:
-
VK_PIPELINE_STAGE_NONE_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER_2_KHR
-
VK_STRUCTURE_TYPE_COMMAND_BUFFER_SUBMIT_INFO_KHR
-
VK_STRUCTURE_TYPE_DEPENDENCY_INFO_KHR
-
VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER_2_KHR
-
VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SYNCHRONIZATION_2_FEATURES_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO_KHR
-
VK_STRUCTURE_TYPE_SUBMIT_INFO_2_KHR
-
If VK_EXT_transform_feedback is supported:
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT
-
VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT
-
VK_ACCESS_2_TRANSFORM_FEEDBACK_WRITE_BIT_EXT
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_TRANSFORM_FEEDBACK_BIT_EXT
-
If VK_KHR_acceleration_structure is supported:
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_KHR
-
VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_KHR
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_KHR
-
If VK_KHR_fragment_shading_rate is supported:
-
Extending VkAccessFlagBits2:
-
VK_ACCESS_2_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR
-
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
-
If VK_KHR_ray_tracing_pipeline is supported:
-
Extending VkPipelineStageFlagBits2:
-
VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_KHR
-
VK_KHR_timeline_semaphore
- Name String
-
VK_KHR_timeline_semaphore
- Extension Type
-
Device extension
- Registered Extension Number
-
208
- Revision
-
2
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Faith Ekstrand gfxstrand
-
Other Extension Metadata
- Last Modified Date
-
2019-06-12
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension interacts with
VK_KHR_external_semaphore_capabilities
-
This extension interacts with
VK_KHR_external_semaphore
-
This extension interacts with
VK_KHR_external_semaphore_win32
-
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Yuriy O’Donnell, Epic Games
-
Faith Ekstrand, Intel
-
Jesse Hall, Google
-
James Jones, NVIDIA
-
Jeff Juliano, NVIDIA
-
Daniel Rakos, AMD
-
Ray Smith, Arm
-
Description
This extension introduces a new type of semaphore that has an integer payload identifying a point in a timeline. Such timeline semaphores support the following operations:
-
Host query - A host operation that allows querying the payload of the timeline semaphore.
-
Host wait - A host operation that allows a blocking wait for a timeline semaphore to reach a specified value.
-
Host signal - A host operation that allows advancing the timeline semaphore to a specified value.
-
Device wait - A device operation that allows waiting for a timeline semaphore to reach a specified value.
-
Device signal - A device operation that allows advancing the timeline semaphore to a specified value.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Structures
-
Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:
-
Extending VkPhysicalDeviceProperties2:
-
Extending VkSemaphoreCreateInfo, VkPhysicalDeviceExternalSemaphoreInfo:
-
Extending VkSubmitInfo, VkBindSparseInfo:
New Enum Constants
-
VK_KHR_TIMELINE_SEMAPHORE_EXTENSION_NAME
-
VK_KHR_TIMELINE_SEMAPHORE_SPEC_VERSION
-
Extending VkSemaphoreType:
-
VK_SEMAPHORE_TYPE_BINARY_KHR
-
VK_SEMAPHORE_TYPE_TIMELINE_KHR
-
-
Extending VkSemaphoreWaitFlagBits:
-
VK_SEMAPHORE_WAIT_ANY_BIT_KHR
-
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_PROPERTIES_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_SIGNAL_INFO_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO_KHR
-
VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO_KHR
-
VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO_KHR
-
Issues
1) Do we need a new object type for this?
RESOLVED: No, we just introduce a new type of semaphore object, as
VK_KHR_external_semaphore_win32
already uses semaphores as the destination
for importing D3D12 fence objects, which are semantically close/identical to
the proposed synchronization primitive.
2) What type of payload the new synchronization primitive has?
RESOLVED: A 64-bit unsigned integer that can only be set to strictly increasing values by signal operations and is not changed by wait operations.
3) Does the new synchronization primitive have the same signal-before-wait requirement as the existing semaphores do?
RESOLVED: No. Timeline semaphores support signaling and waiting entirely asynchronously. It is the responsibility of the client to avoid deadlock.
4) Does the new synchronization primitive allow resetting its payload?
RESOLVED: No, allowing the payload value to “go backwards” is problematic. Applications looking for reset behavior should create a new instance of the synchronization primitive instead.
5) How do we enable host waits on the synchronization primitive?
RESOLVED: Both a non-blocking query of the current payload value of the synchronization primitive, and a blocking wait operation are provided.
6) How do we enable device waits and signals on the synchronization primitive?
RESOLVED: Similar to VK_KHR_external_semaphore_win32
, this extension
introduces a new structure that can be chained to VkSubmitInfo to
specify the values signaled semaphores should be set to, and the values
waited semaphores need to reach.
7) Can the new synchronization primitive be used to synchronize presentation and swapchain image acquisition operations?
RESOLVED: Some implementations may have problems with supporting that directly, thus it is not allowed in this extension.
8) Do we want to support external sharing of the new synchronization primitive type?
RESOLVED: Yes.
Timeline semaphore specific external sharing capabilities can be queried
using vkGetPhysicalDeviceExternalSemaphoreProperties by chaining the
new VkSemaphoreTypeCreateInfoKHR structure to its
pExternalSemaphoreInfo
structure.
This allows having a different set of external semaphore handle types
supported for timeline semaphores vs. binary semaphores.
9) Do we need to add a host signal operation for the new synchronization primitive type?
RESOLVED: Yes. This helps in situations where one host thread submits a workload but another host thread has the information on when the workload is ready to be executed.
10) How should the new synchronization primitive interact with the ordering
requirements of the original VkSemaphore
?
RESOLVED: Prior to calling any command which may cause a wait operation on a binary semaphore, the client must ensure that the semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution.
11) Should we have separate feature bits for different sub-features of timeline semaphores?
RESOLVED: No.
The only feature which cannot be supported universally is timeline semaphore
import/export.
For import/export, the client is already required to query available
external handle types via
vkGetPhysicalDeviceExternalSemaphoreProperties and provide the
semaphore type by adding a VkSemaphoreTypeCreateInfoKHR structure to
the pNext
chain of VkPhysicalDeviceExternalSemaphoreInfo so no
new feature bit is required.
VK_KHR_uniform_buffer_standard_layout
- Name String
-
VK_KHR_uniform_buffer_standard_layout
- Extension Type
-
Device extension
- Registered Extension Number
-
254
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Graeme Leese gnl21
-
Other Extension Metadata
- Last Modified Date
-
2019-01-25
- Contributors
-
-
Graeme Leese, Broadcom
-
Jeff Bolz, NVIDIA
-
Tobias Hector, AMD
-
Faith Ekstrand, Intel
-
Neil Henning, AMD
-
Description
This extension enables tighter array and struct packing to be used with uniform buffers.
It modifies the alignment rules for uniform buffers, allowing for tighter packing of arrays and structures. This allows, for example, the std430 layout, as defined in GLSL to be supported in uniform buffers.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.
New Enum Constants
-
VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_EXTENSION_NAME
-
VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFORM_BUFFER_STANDARD_LAYOUT_FEATURES_KHR
-
VK_KHR_variable_pointers
- Name String
-
VK_KHR_variable_pointers
- Extension Type
-
Device extension
- Registered Extension Number
-
121
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.1
-
- Contact
-
-
Jesse Hall critsec
-
Other Extension Metadata
- Last Modified Date
-
2017-09-05
- IP Status
-
No known IP claims.
- Contributors
-
-
John Kessenich, Google
-
Neil Henning, Codeplay
-
David Neto, Google
-
Daniel Koch, Nvidia
-
Graeme Leese, Broadcom
-
Weifeng Zhang, Qualcomm
-
Stephen Clarke, Imagination Technologies
-
Faith Ekstrand, Intel
-
Jesse Hall, Google
-
Description
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.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1, with the
KHR suffix omitted, however support for the
variablePointersStorageBuffer
feature is made optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME
-
VK_KHR_VARIABLE_POINTERS_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTERS_FEATURES_KHR
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR
-
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.
VK_KHR_vulkan_memory_model
- Name String
-
VK_KHR_vulkan_memory_model
- Extension Type
-
Device extension
- Registered Extension Number
-
212
- Revision
-
3
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- SPIR-V Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.2
-
- Contact
-
-
Jeff Bolz jeffbolznv
-
Other Extension Metadata
- Last Modified Date
-
2018-12-10
- IP Status
-
No known IP claims.
- Contributors
-
-
Jeff Bolz, NVIDIA
-
Alan Baker, Google
-
Tobias Hector, AMD
-
David Neto, Google
-
Robert Simpson, Qualcomm Technologies, Inc.
-
Brian Sumner, AMD
-
Description
The VK_KHR_vulkan_memory_model extension allows use of the features
guarded by the VulkanMemoryModel
, VulkanMemoryModelDeviceScope
,
and VulkanMemoryModelAvailabilityVisibilityChains
capabilities in
shader modules.
The Vulkan Memory Model formally defines how to synchronize
memory accesses to the same memory locations performed by multiple shader
invocations.
Note
Version 3 of the spec added a member
( |
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
KHR suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
vulkanMemoryModel
capability is optional.
The original type, enum and command names are still available as aliases of
the core functionality.
New Enum Constants
-
VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME
-
VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR
-
VK_KHR_zero_initialize_workgroup_memory
- Name String
-
VK_KHR_zero_initialize_workgroup_memory
- Extension Type
-
Device extension
- Registered Extension Number
-
326
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
- Deprecation State
-
-
Promoted to Vulkan 1.3
-
- Contact
-
-
Alan Baker alan-baker
-
Other Extension Metadata
- Last Modified Date
-
2020-11-18
- IP Status
-
No known IP claims.
- Contributors
-
-
Alan Baker, Google
-
Jeff Bolz, Nvidia
-
Faith Ekstrand, Intel
-
Description
This extension allows the use of a null constant initializer on shader Workgroup memory variables, allowing implementations to expose any special hardware or instructions they may have. Zero initialization is commonly used by applications running untrusted content (e.g. web browsers) as way of defeating memory-scraping attacks.
New Enum Constants
-
VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_EXTENSION_NAME
-
VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_SPEC_VERSION
-
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_WORKGROUP_MEMORY_FEATURES_KHR
-
VK_EXT_load_store_op_none
- Name String
-
VK_EXT_load_store_op_none
- Extension Type
-
Device extension
- Registered Extension Number
-
401
- Revision
-
1
- Ratification Status
-
Ratified
- Extension and Version Dependencies
-
None
- Deprecation State
-
-
Promoted to VK_KHR_load_store_op_none extension
-
- Contact
-
-
Shahbaz Youssefi syoussefi
-
Other Extension Metadata
- Last Modified Date
-
2021-06-06
- Contributors
-
-
Shahbaz Youssefi, Google
-
Bill Licea-Kane, Qualcomm Technologies, Inc.
-
Tobias Hector, AMD
-
Description
This extension incorporates VK_ATTACHMENT_STORE_OP_NONE_EXT
from
, enabling applications to avoid
unnecessary synchronization when an attachment is not written during a
render pass.VK_QCOM_render_pass_store_ops
Additionally, VK_ATTACHMENT_LOAD_OP_NONE_EXT
is introduced to avoid
unnecessary synchronization when an attachment is not used during a render
pass at all.
In combination with VK_ATTACHMENT_STORE_OP_NONE_EXT
, this is useful as
an alternative to preserve attachments in applications that cannot decide if
an attachment will be used in a render pass until after the necessary
pipelines have been created.
Promotion to VK_KHR_load_store_op_none
All functionality in this extension is included in
VK_KHR_load_store_op_none
, with the suffix changed to KHR.
The original enum names are still available as aliases of the KHR
functionality.
New Enum Constants
-
VK_EXT_LOAD_STORE_OP_NONE_EXTENSION_NAME
-
VK_EXT_LOAD_STORE_OP_NONE_SPEC_VERSION
-
Extending VkAttachmentLoadOp:
-
VK_ATTACHMENT_LOAD_OP_NONE_EXT
-
-
Extending VkAttachmentStoreOp:
-
VK_ATTACHMENT_STORE_OP_NONE_EXT
-