Layers & Extensions (Informative) :: Vul

Layers & Extensions (Informative) :: Vulkan Documentation Project
Vulkan Specification
latest
Khronos Vulkan Tutorial
latest
OpenGL Shading Language Specification
latest
Vulkan API Reference Pages
latest
Vulkan Feature Descriptions
latest
Vulkan Guide
latest
Vulkan Samples
latest
Vulkan Specification
latest
Layers & Extensions (Informative)
Extensions to the Vulkan API
can
be defined by authors, groups of authors,
and the Khronos Vulkan
Working Group.
The online Registry of extensions is available at URL
Authors creating extensions and layers
must
follow the mandatory procedures
described in the
Vulkan Documentation and Extensions
document when creating extensions and layers.
The version of the Vulkan specification published
on the
Vulkan Documentation
site and
in the Registry includes all registered and published extensions.
It is also possible to build the specification with an arbitrary set of
extensions included, and the specification you are viewing may not include
all extensions.
In the remainder of this appendix, 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
Vulkan Version 1.1
and
VK_EXT_descriptor_indexing
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
and
VK_KHR_deferred_host_operations
API Interactions
Interacts with VK_VERSION_1_2
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 Object Types
VkAccelerationStructureKHR
New Commands
vkBuildAccelerationStructuresKHR
vkCmdBuildAccelerationStructuresIndirectKHR
vkCmdBuildAccelerationStructuresKHR
vkCmdCopyAccelerationStructureKHR
vkCmdCopyAccelerationStructureToMemoryKHR
vkCmdCopyMemoryToAccelerationStructureKHR
vkCmdWriteAccelerationStructuresPropertiesKHR
vkCopyAccelerationStructureKHR
vkCopyAccelerationStructureToMemoryKHR
vkCopyMemoryToAccelerationStructureKHR
vkCreateAccelerationStructureKHR
vkDestroyAccelerationStructureKHR
vkGetAccelerationStructureBuildSizesKHR
vkGetAccelerationStructureDeviceAddressKHR
vkGetDeviceAccelerationStructureCompatibilityKHR
vkWriteAccelerationStructuresPropertiesKHR
New Structures
VkAabbPositionsKHR
VkAccelerationStructureBuildGeometryInfoKHR
VkAccelerationStructureBuildRangeInfoKHR
VkAccelerationStructureBuildSizesInfoKHR
VkAccelerationStructureCreateInfoKHR
VkAccelerationStructureDeviceAddressInfoKHR
VkAccelerationStructureGeometryAabbsDataKHR
VkAccelerationStructureGeometryInstancesDataKHR
VkAccelerationStructureGeometryKHR
VkAccelerationStructureGeometryTrianglesDataKHR
VkAccelerationStructureInstanceKHR
VkAccelerationStructureVersionInfoKHR
VkCopyAccelerationStructureInfoKHR
VkCopyAccelerationStructureToMemoryInfoKHR
VkCopyMemoryToAccelerationStructureInfoKHR
VkTransformMatrixKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAccelerationStructureFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceAccelerationStructurePropertiesKHR
Extending
VkWriteDescriptorSet
VkWriteDescriptorSetAccelerationStructureKHR
New Unions
VkAccelerationStructureGeometryDataKHR
VkDeviceOrHostAddressConstKHR
VkDeviceOrHostAddressKHR
New Enums
VkAccelerationStructureBuildTypeKHR
VkAccelerationStructureCompatibilityKHR
VkAccelerationStructureCreateFlagBitsKHR
VkAccelerationStructureTypeKHR
VkBuildAccelerationStructureFlagBitsKHR
VkBuildAccelerationStructureModeKHR
VkCopyAccelerationStructureModeKHR
VkGeometryFlagBitsKHR
VkGeometryInstanceFlagBitsKHR
VkGeometryTypeKHR
New Bitmasks
VkAccelerationStructureCreateFlagsKHR
VkBuildAccelerationStructureFlagsKHR
VkGeometryFlagsKHR
VkGeometryInstanceFlagsKHR
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
VkCopyAccelerationStructureModeKHR
VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR
VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_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_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR_EXT
If
VK_KHR_format_feature_flags2
or
Vulkan 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
(2) Can you give a more detailed comparison of differences and similarities
between VK_NV_ray_tracing and VK_KHR_acceleration_structure?
DISCUSSION
The following is a more detailed comparison of which commands, structures,
and enums are aliased, changed, or removed.
Aliased functionality — enums, structures, and commands that are
considered equivalent:
VkGeometryTypeNV
VkGeometryTypeKHR
VkAccelerationStructureTypeNV
VkAccelerationStructureTypeKHR
VkCopyAccelerationStructureModeNV
VkCopyAccelerationStructureModeKHR
VkGeometryFlagsNV
VkGeometryFlagsKHR
VkGeometryFlagBitsNV
VkGeometryFlagBitsKHR
VkGeometryInstanceFlagsNV
VkGeometryInstanceFlagsKHR
VkGeometryInstanceFlagBitsNV
VkGeometryInstanceFlagBitsKHR
VkBuildAccelerationStructureFlagsNV
VkBuildAccelerationStructureFlagsKHR
VkBuildAccelerationStructureFlagBitsNV
VkBuildAccelerationStructureFlagBitsKHR
VkTransformMatrixNV
VkTransformMatrixKHR
(added to
VK_NV_ray_tracing for descriptive purposes)
VkAabbPositionsNV
VkAabbPositionsKHR
(added to
VK_NV_ray_tracing for descriptive purposes)
VkAccelerationStructureInstanceNV
VkAccelerationStructureInstanceKHR
(added to VK_NV_ray_tracing
for descriptive purposes)
Changed enums, structures, and commands:
renamed
VK_GEOMETRY_INSTANCE_TRIANGLE_CULL_DISABLE_BIT_NV
VK_GEOMETRY_INSTANCE_TRIANGLE_FACING_CULL_DISABLE_BIT_KHR
in
VkGeometryInstanceFlagBitsKHR
VkGeometryTrianglesNV
VkAccelerationStructureGeometryTrianglesDataKHR
(device or host
address instead of buffer+offset)
VkGeometryAABBNV
VkAccelerationStructureGeometryAabbsDataKHR
(device or host
address instead of buffer+offset)
VkGeometryDataNV
VkAccelerationStructureGeometryDataKHR
(union of triangle/aabbs/instances)
VkGeometryNV
VkAccelerationStructureGeometryKHR
(changed
type of geometry)
VkAccelerationStructureCreateInfoNV
VkAccelerationStructureCreateInfoKHR
(reshuffle geometry
layout/information)
VkPhysicalDeviceRayTracingPropertiesNV
VkPhysicalDeviceAccelerationStructurePropertiesKHR
(for
acceleration structure properties, renamed
maxTriangleCount
to
maxPrimitiveCount
, added per stage and update after bind limits)
and
VkPhysicalDeviceRayTracingPipelinePropertiesKHR
(for ray
tracing pipeline properties)
VkAccelerationStructureMemoryRequirementsInfoNV
(deleted -
replaced by allocating on top of
VkBuffer
VkWriteDescriptorSetAccelerationStructureNV
VkWriteDescriptorSetAccelerationStructureKHR
(different
acceleration structure type)
vkCreateAccelerationStructureNV
vkCreateAccelerationStructureKHR
(device address, different
geometry layout/information)
vkGetAccelerationStructureMemoryRequirementsNV
(deleted -
replaced by allocating on top of
VkBuffer
vkCmdBuildAccelerationStructureNV
vkCmdBuildAccelerationStructuresKHR
(params moved to structs,
layout differences)
vkCmdCopyAccelerationStructureNV
vkCmdCopyAccelerationStructureKHR
(params to struct, extendable)
vkGetAccelerationStructureHandleNV
vkGetAccelerationStructureDeviceAddressKHR
(device address
instead of handle)
VkAccelerationStructureMemoryRequirementsTypeNV
→ size queries
for scratch space moved to
vkGetAccelerationStructureBuildSizesKHR
vkDestroyAccelerationStructureNV
vkDestroyAccelerationStructureKHR
(different acceleration
structure types)
vkCmdWriteAccelerationStructuresPropertiesNV
vkCmdWriteAccelerationStructuresPropertiesKHR
(different
acceleration structure types)
Added enums, structures, and commands:
VK_GEOMETRY_TYPE_INSTANCES_KHR
to
VkGeometryTypeKHR
enum
VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR
VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR
to
VkCopyAccelerationStructureModeKHR
enum
VkPhysicalDeviceAccelerationStructureFeaturesKHR
structure
VkAccelerationStructureBuildTypeKHR
enum
VkBuildAccelerationStructureModeKHR
enum
VkDeviceOrHostAddressKHR
and
VkDeviceOrHostAddressConstKHR
unions
VkAccelerationStructureBuildRangeInfoKHR
struct
VkAccelerationStructureGeometryInstancesDataKHR
struct
VkAccelerationStructureDeviceAddressInfoKHR
struct
VkAccelerationStructureVersionInfoKHR
struct
VkStridedDeviceAddressRegionKHR
struct
VkCopyAccelerationStructureToMemoryInfoKHR
struct
VkCopyMemoryToAccelerationStructureInfoKHR
struct
VkCopyAccelerationStructureInfoKHR
struct
vkBuildAccelerationStructuresKHR
command (host build)
vkCopyAccelerationStructureKHR
command (host copy)
vkCopyAccelerationStructureToMemoryKHR
(host serialize)
vkCopyMemoryToAccelerationStructureKHR
(host deserialize)
vkWriteAccelerationStructuresPropertiesKHR
(host properties)
vkCmdCopyAccelerationStructureToMemoryKHR
(device serialize)
vkCmdCopyMemoryToAccelerationStructureKHR
(device deserialize)
vkGetDeviceAccelerationStructureCompatibilityKHR
(serialization)
(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
to
VkAccelerationStructureCreateGeometryTypeInfoKHR
(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
to
VK_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
to
buildFlags
(later
removed) and added the
createFlags
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
to
ppBuildRangeInfos
Re-unify geometry description between build and create
remove
VkAccelerationStructureCreateGeometryTypeInfoKHR
and
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_GEOMETRY_TYPE_INFO_KHR
added
VkAccelerationStructureCreateSizeInfoKHR
structure (later
removed)
change type of the
pGeometryInfos
member of
VkAccelerationStructureCreateInfoKHR
from
VkAccelerationStructureCreateGeometryTypeInfoKHR
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 adding
pGeometries
to the
VkAccelerationStructureBuildGeometryInfoKHR
structure and require
one of them be
NULL
added
nullDescriptor
support for
acceleration structures
changed the
update
member of
VkAccelerationStructureBuildGeometryInfoKHR
from a bool to the
mode
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
and
VkAccelerationStructureMemoryRequirementsTypeKHR
, and remove
VkAccelerationStructureMemoryRequirementsTypeKHR
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 the
size
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
VK_NV_ray_tracing
(required on
scratch
and
instanceData
VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR
is added as an alias
of
VK_BUFFER_USAGE_RAY_TRACING_BIT_NV
in
VK_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 in
VK_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 for
scratchData
add max primitive counts (
ppMaxPrimitiveCounts
) to
vkCmdBuildAccelerationStructuresIndirectKHR
Allocate acceleration structures from
VkBuffers
and add a mode to
constrain the device address
de-alias
VkBindAccelerationStructureMemoryInfoNV
and
vkBindAccelerationStructureMemoryNV
, and remove
VkBindAccelerationStructureMemoryInfoKHR
VkAccelerationStructureMemoryRequirementsInfoKHR
, and
vkGetAccelerationStructureMemoryRequirementsKHR
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
to
vk.xml
VK_KHR_android_surface
Name String
VK_KHR_android_surface
Extension Type
Instance extension
Registered Extension Number
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Base Types
ANativeWindow
New Commands
vkCreateAndroidSurfaceKHR
New Structures
VkAndroidSurfaceCreateInfoKHR
New Bitmasks
VkAndroidSurfaceCreateFlagsKHR
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Daniel Rakos
aqnuep
Extension Proposal
VK_EXT_calibrated_timestamps
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 Commands
vkGetCalibratedTimestampsKHR
vkGetPhysicalDeviceCalibrateableTimeDomainsKHR
New Structures
VkCalibratedTimestampInfoKHR
New Enums
VkTimeDomainKHR
New Enum Constants
VK_KHR_CALIBRATED_TIMESTAMPS_EXTENSION_NAME
VK_KHR_CALIBRATED_TIMESTAMPS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_KHR
Version History
Revision 1, 2023-07-12 (Daniel Rakos)
Initial draft.
VK_KHR_compute_shader_derivatives
Name String
VK_KHR_compute_shader_derivatives
Extension Type
Device extension
Registered Extension Number
512
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_compute_shader_derivatives
Contact
Jean-Noe Morissette
MagicPoncho
Extension Proposal
VK_KHR_compute_shader_derivatives
Other Extension Metadata
Last Modified Date
2024-06-26
IP Status
No known IP claims.
Interactions and External Dependencies
This extension requires
SPV_KHR_compute_shader_derivatives
This extension provides API support for
GL_KHR_compute_shader_derivatives
Contributors
Jean-Noe Morissette, Epic Games
Daniel Koch, NVIDIA
Pat Brown, NVIDIA
Stu Smith, AMD
Jan-Harald Fredriksen, Arm
Tobias Hector, AMD
Ralph Potter, Samsung
Pan Gao, Huawei
Samuel (Sheng-Wen) Huang, MediaTek
Graeme Leese, Broadcom
Hans-Kristian Arntzen, Valve
Matthew Netsch, Qualcomm
Description
This extension adds Vulkan support for the
SPV_KHR_compute_shader_derivatives
SPIR-V extension.
The SPIR-V extension provides two new execution modes, both of which allow
execution models with defined workgroups to use built-ins that evaluate
derivatives explicitly or implicitly.
Derivatives will be computed via differencing over a 2x2 group of shader
invocations.
The
DerivativeGroupQuadsKHR
execution mode assembles shader invocations
into 2x2 groups, where each group has x and y coordinates of the local
invocation ID of the form (2m+{0,1}, 2n+{0,1}).
The
DerivativeGroupLinearKHR
execution mode assembles shader
invocations into 2x2 groups, where each group has local invocation index
values of the form 4m+{0,1,2,3}.
The new execution modes are supported in compute shaders and optionally (see
meshAndTaskShaderDerivatives
) in
mesh and task shaders.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceComputeShaderDerivativesFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceComputeShaderDerivativesPropertiesKHR
New Enum Constants
VK_KHR_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME
VK_KHR_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_PROPERTIES_KHR
New SPIR-V Capability
ComputeDerivativeGroupQuadsKHR
ComputeDerivativeGroupLinearKHR
Examples
None.
Version History
Revision 1, 2023-02-27 (Jean-Noe Morissette)
Initial draft
Add properties and clarify mesh and task support (Daniel Koch)
VK_KHR_cooperative_matrix
Name String
VK_KHR_cooperative_matrix
Extension Type
Device extension
Registered Extension Number
507
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_cooperative_matrix
Contact
Kevin Petit
kpet
Extension Proposal
VK_KHR_cooperative_matrix
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 Commands
vkGetPhysicalDeviceCooperativeMatrixPropertiesKHR
New Structures
VkCooperativeMatrixPropertiesKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCooperativeMatrixFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCooperativeMatrixPropertiesKHR
New Enums
VkComponentTypeKHR
VkScopeKHR
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
New SPIR-V Capabilities
CooperativeMatrixKHR
Issues
1.) How does cooperativeMatrixRobustBufferAccess interact with
nullDescriptor?
RESOLVED
: nullDescriptor is not allowed here While drivers can handle
going OOB into a buffer, if there is not buffer, via nullDescriptor, it is
invalid to load/store from the cooperative matrix.
Version History
Revision 2, 2023-05-03 (Kevin Petit)
First KHR revision
Revision 1, 2019-02-05 (Jeff Bolz)
NVIDIA vendor extension
VK_KHR_copy_memory_indirect
Name String
VK_KHR_copy_memory_indirect
Extension Type
Device extension
Registered Extension Number
550
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
Contact
Vikram Kushwaha
vkushwaha-nv
Extension Proposal
VK_KHR_copy_memory_indirect
Other Extension Metadata
Last Modified Date
2025-01-25
Contributors
Daniel Koch, NVIDIA
Vikram Kushwaha, NVIDIA
Jeff Bolz, NVIDIA
Christoph Kubisch, NVIDIA
Stuart Smith, AMD
Faith Ekstrand, Collabora
Caterina Shablia, Collabora
Spencer Fricke, LunarG
Matthew Netsch, Qualcomm Technologies, Inc
Mike Blumenkrantz, Valve
Alyssa Rosenzweig, Valve
Description
This extension adds support for performing copies between memory and image
regions using indirect parameters that are read by the device from a buffer
during execution.
This functionality may be useful for performing copies where the copy
parameters are not known during the command buffer creation time.
New Commands
vkCmdCopyMemoryIndirectKHR
vkCmdCopyMemoryToImageIndirectKHR
New Structures
VkCopyMemoryIndirectCommandKHR
VkCopyMemoryIndirectInfoKHR
VkCopyMemoryToImageIndirectCommandKHR
VkCopyMemoryToImageIndirectInfoKHR
VkStridedDeviceAddressRangeKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCopyMemoryIndirectFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCopyMemoryIndirectPropertiesKHR
New Enums
VkAddressCopyFlagBitsKHR
New Bitmasks
VkAddressCopyFlagsKHR
New Enum Constants
VK_KHR_COPY_MEMORY_INDIRECT_EXTENSION_NAME
VK_KHR_COPY_MEMORY_INDIRECT_SPEC_VERSION
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_COPY_IMAGE_INDIRECT_DST_BIT_KHR
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_COPY_INDIRECT_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_COPY_MEMORY_INDIRECT_INFO_KHR
VK_STRUCTURE_TYPE_COPY_MEMORY_TO_IMAGE_INDIRECT_INFO_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_PROPERTIES_KHR
Version History
Revision 1, 2025-01-25 (Daniel Koch, Vikram Kushwaha)
Initial external release
VK_KHR_deferred_host_operations
Name String
VK_KHR_deferred_host_operations
Extension Type
Device extension
Registered Extension Number
269
Revision
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 Object Types
VkDeferredOperationKHR
New Commands
vkCreateDeferredOperationKHR
vkDeferredOperationJoinKHR
vkDestroyDeferredOperationKHR
vkGetDeferredOperationMaxConcurrencyKHR
vkGetDeferredOperationResultKHR
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 > 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_depth_clamp_zero_one
Name String
VK_KHR_depth_clamp_zero_one
Extension Type
Device extension
Registered Extension Number
605
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Graeme Leese
gnl21
Other Extension Metadata
Last Modified Date
2024-09-10
Contributors
Graeme Leese, Broadcom
Description
This extension is based on the
VK_EXT_depth_clamp_zero_one
extension.
This extension gives defined behavior to fragment depth values which end up
outside the conventional [0, 1] range.
It can be used to ensure portability in edge cases of features like
depthBias.
The particular behavior is chosen to match OpenGL to aid porting or
emulation.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthClampZeroOneFeaturesKHR
New Enum Constants
VK_KHR_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME
VK_KHR_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_KHR
Version History
Revision 1, 2024-09-10 (Graeme Leese)
Internal revisions
VK_KHR_device_address_commands
Name String
VK_KHR_device_address_commands
Extension Type
Device extension
Registered Extension Number
319
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
and
VK_KHR_synchronization2
and
VK_EXT_extended_dynamic_state
or
Vulkan Version 1.3
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_AMD_buffer_marker
Interacts with VK_EXT_conditional_rendering
Interacts with VK_EXT_mesh_shader
Interacts with VK_EXT_transform_feedback
Interacts with VK_KHR_acceleration_structure
Interacts with VK_KHR_draw_indirect_count
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_device_address_commands
Other Extension Metadata
Last Modified Date
2026-03-10
Contributors
Tobias Hector, AMD
Matthew Netsch, Qualcomm Technologies, Inc
Jan-Harald Fredriksen, Arm
Mike Blumenkrantz, Valve
Allan MacKinnon, Google
Daniel Koch, NVIDIA
Autumn Ashton, Valve
Piers Daniell, NVIDIA
Stuart Smith, AMD
Caterina Shablia, Collabora
Piotr Byszewski, Cognizant
James Fitzpatrick, Imagination
Daniel Story, Nintendo
Baldur Karlsson, Valve
Jon Leech, Khronos
Samuel Pitoiset, Valve
Lionel Landwerlin, Intel
Hans-Kristian Arntzen, Valve
Žiga Markuš, LunarG
Spencer Fricke, Lunarg
Per Inge Mathisen, Arm
Vikram Kushwaha, NVIDIA
Ralph Potter, Samsung
Marijn Suijten, Traverse Research
Ricard Garcia, Igalia
Mengyang Liu, AMD
Artem Kharytoniuk, LunarG
Marty Johnson, Khronos
Alyssa Rosenzweig, Valve
Description
This extension enables applications to use device addresses in place of
buffer objects for most functionality.
New Commands
vkCmdBindIndexBuffer3KHR
vkCmdBindVertexBuffers3KHR
vkCmdCopyImageToMemoryKHR
vkCmdCopyMemoryKHR
vkCmdCopyMemoryToImageKHR
vkCmdCopyQueryPoolResultsToMemoryKHR
vkCmdDispatchIndirect2KHR
vkCmdDrawIndexedIndirect2KHR
vkCmdDrawIndirect2KHR
vkCmdFillMemoryKHR
vkCmdUpdateMemoryKHR
If
VK_KHR_draw_indirect_count
or
Vulkan Version 1.2
and
VK_EXT_mesh_shader
is supported:
vkCmdDrawMeshTasksIndirectCount2EXT
If
VK_AMD_buffer_marker
is supported:
vkCmdWriteMarkerToMemoryAMD
If
VK_EXT_conditional_rendering
is supported:
vkCmdBeginConditionalRendering2EXT
If
VK_EXT_mesh_shader
is supported:
vkCmdDrawMeshTasksIndirect2EXT
If
VK_EXT_transform_feedback
is supported:
vkCmdBeginTransformFeedback2EXT
vkCmdBindTransformFeedbackBuffers2EXT
vkCmdDrawIndirectByteCount2EXT
vkCmdEndTransformFeedback2EXT
If
VK_KHR_acceleration_structure
is supported:
vkCreateAccelerationStructure2KHR
If
VK_KHR_draw_indirect_count
or
Vulkan Version 1.2
is supported:
vkCmdDrawIndexedIndirectCount2KHR
vkCmdDrawIndirectCount2KHR
New Structures
VkBindIndexBuffer3InfoKHR
VkBindVertexBuffer3InfoKHR
VkCopyDeviceMemoryImageInfoKHR
VkCopyDeviceMemoryInfoKHR
VkDeviceAddressRangeKHR
VkDeviceMemoryCopyKHR
VkDeviceMemoryImageCopyKHR
VkDispatchIndirect2InfoKHR
VkDrawIndirect2InfoKHR
VkDrawIndirectCount2InfoKHR
VkMemoryRangeBarrierKHR
VkStridedDeviceAddressRangeKHR
Extending
VkDependencyInfo
VkMemoryRangeBarriersInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDeviceAddressCommandsFeaturesKHR
If
VK_AMD_buffer_marker
is supported:
VkMemoryMarkerInfoAMD
If
VK_EXT_conditional_rendering
is supported:
VkConditionalRenderingBeginInfo2EXT
If
VK_EXT_transform_feedback
is supported:
VkBindTransformFeedbackBuffer2InfoEXT
If
VK_KHR_acceleration_structure
is supported:
VkAccelerationStructureCreateInfo2KHR
New Enums
VkAddressCommandFlagBitsKHR
New Bitmasks
VkAddressCommandFlagsKHR
New Enum Constants
VK_KHR_DEVICE_ADDRESS_COMMANDS_EXTENSION_NAME
VK_KHR_DEVICE_ADDRESS_COMMANDS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_INDEX_BUFFER_3_INFO_KHR
VK_STRUCTURE_TYPE_BIND_VERTEX_BUFFER_3_INFO_KHR
VK_STRUCTURE_TYPE_COPY_DEVICE_MEMORY_IMAGE_INFO_KHR
VK_STRUCTURE_TYPE_COPY_DEVICE_MEMORY_INFO_KHR
VK_STRUCTURE_TYPE_DEVICE_MEMORY_COPY_KHR
VK_STRUCTURE_TYPE_DEVICE_MEMORY_IMAGE_COPY_KHR
VK_STRUCTURE_TYPE_DISPATCH_INDIRECT_2_INFO_KHR
VK_STRUCTURE_TYPE_DRAW_INDIRECT_2_INFO_KHR
VK_STRUCTURE_TYPE_DRAW_INDIRECT_COUNT_2_INFO_KHR
VK_STRUCTURE_TYPE_MEMORY_RANGE_BARRIERS_INFO_KHR
VK_STRUCTURE_TYPE_MEMORY_RANGE_BARRIER_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_ADDRESS_COMMANDS_FEATURES_KHR
If
VK_AMD_buffer_marker
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_MEMORY_MARKER_INFO_AMD
If
VK_EXT_conditional_rendering
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_CONDITIONAL_RENDERING_BEGIN_INFO_2_EXT
If
VK_EXT_transform_feedback
is supported:
Extending
VkAddressCommandFlagBitsKHR
VK_ADDRESS_COMMAND_TRANSFORM_FEEDBACK_BUFFER_USAGE_BIT_KHR
VK_ADDRESS_COMMAND_UNKNOWN_TRANSFORM_FEEDBACK_BUFFER_USAGE_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_TRANSFORM_FEEDBACK_BUFFER_2_INFO_EXT
If
VK_KHR_acceleration_structure
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_2_KHR
Version History
Revision 1, 2026-03-10 (Tobias Hector)
Initial revision
VK_KHR_device_fault
Name String
VK_KHR_device_fault
Extension Type
Device extension
Registered Extension Number
574
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
Contact
Ralph Potter
r_potter
Extension Proposal
VK_KHR_device_fault
Other Extension Metadata
Last Modified Date
2026-03-18
IP Status
No known IP claims.
Contributors
Ralph Potter, Samsung
Craig Graham, Samsung
Stuart Smith, AMD
Jan-Harald Fredriksen, ARM
Mark Bellamy, ARM
Andrew Ellem, Google
Alex Walters, IMG
Jeff Bolz, NVIDIA
Baldur Karlsson, Valve
Adrian Ravai, Samsung
Peter Gal, Samsung
Matthew Netsch, QUALCOMM
Tobias Hector, AMD
Alan Harrison, AMD
Vikram Tarikere, IMG
Jon Leech, Khronos
Samuel Pitoiset, Valve
Description
Device loss can be triggered by a variety of issues, including invalid API
usage, implementation errors, or hardware failures.
This extension introduces two new commands:
vkGetDeviceFaultReportsKHR
vkGetDeviceFaultDebugInfoKHR
vkGetDeviceFaultReportsKHR
allows developers to query for additional
information on GPU faults which may have caused device loss, and to generate
binary crash dumps, which may be loaded into external tools for further
diagnosis.
Additionally this command allows developers to query for additional
information on GPU faults which were internally recovered by the
implementation.
vkGetDeviceFaultReportsKHR
differs from
vkGetDeviceFaultInfoEXT
in that it can be called at any time, is able to report faults which do not
result in
VK_ERROR_DEVICE_LOST
and allows the caller to wait for such
an error to occur.
vkGetDeviceFaultDebugInfoKHR
provides a separate interface which
must
only be called when a device loss has occurred to provide extended GPU
vendor specific crash post-mortem information.
New Commands
vkGetDeviceFaultDebugInfoKHR
vkGetDeviceFaultReportsKHR
New Structures
VkDeviceFaultAddressInfoKHR
VkDeviceFaultDebugInfoKHR
VkDeviceFaultInfoKHR
VkDeviceFaultVendorBinaryHeaderVersionOneKHR
VkDeviceFaultVendorInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFaultFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFaultPropertiesKHR
New Enums
VkDeviceFaultAddressTypeKHR
VkDeviceFaultFlagBitsKHR
VkDeviceFaultVendorBinaryHeaderVersionKHR
New Bitmasks
VkDeviceFaultFlagsKHR
New Enum Constants
VK_KHR_DEVICE_FAULT_EXTENSION_NAME
VK_KHR_DEVICE_FAULT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_FAULT_DEBUG_INFO_KHR
VK_STRUCTURE_TYPE_DEVICE_FAULT_INFO_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FAULT_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FAULT_PROPERTIES_KHR
Version History
Revision 0, 2024-03-01 (Ralph Potter)
Internal Revision
Revision 1, 2025-06-10 (Craig Graham)
Revised API to support async fault queries.
VK_KHR_display
Name String
VK_KHR_display
Extension Type
Instance extension
Registered Extension Number
Revision
23
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
James Jones
cubanismo
Norbert Nopper
FslNopper
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 Object Types
VkDisplayKHR
VkDisplayModeKHR
New Commands
vkCreateDisplayModeKHR
vkCreateDisplayPlaneSurfaceKHR
vkGetDisplayModePropertiesKHR
vkGetDisplayPlaneCapabilitiesKHR
vkGetDisplayPlaneSupportedDisplaysKHR
vkGetPhysicalDeviceDisplayPlanePropertiesKHR
vkGetPhysicalDeviceDisplayPropertiesKHR
New Structures
VkDisplayModeCreateInfoKHR
VkDisplayModeParametersKHR
VkDisplayModePropertiesKHR
VkDisplayPlaneCapabilitiesKHR
VkDisplayPlanePropertiesKHR
VkDisplayPropertiesKHR
VkDisplaySurfaceCreateInfoKHR
New Enums
VkDisplayPlaneAlphaFlagBitsKHR
New Bitmasks
VkDisplayModeCreateFlagsKHR
VkDisplayPlaneAlphaFlagsKHR
VkDisplaySurfaceCreateFlagsKHR
VkSurfaceTransformFlagsKHR
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
The example code for the
VK_KHR_display
and
VK_KHR_display_swapchain
extensions was removed from the appendix
after revision 1.0.43.
The display enumeration example code was ported to the cube demo that is
shipped with the official Khronos SDK, and is being kept up-to-date in that
location (see:
).
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
Revision
10
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_display
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 Commands
vkCreateSharedSwapchainsKHR
New Structures
Extending
VkPresentInfoKHR
VkDisplayPresentInfoKHR
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.
5) Can
VkDisplayPresentInfoKHR
be used without calling
vkCreateSharedSwapchainsKHR
RESOLVED
: Yes.
The two bits of functionality were meant to be independent.
If the extension was created today, there would likely be two feature bits
for
VkDisplayPresentInfoKHR
and
vkCreateSharedSwapchainsKHR
Examples
The example code for the
VK_KHR_display
and
VK_KHR_display_swapchain
extensions was removed from the appendix after
revision 1.0.43.
The display swapchain creation example code was ported to the cube demo that
is shipped with the official Khronos SDK, and is being kept up-to-date in
that location (see:
).
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_external_fence_fd
Name String
VK_KHR_external_fence_fd
Extension Type
Device extension
Registered Extension Number
116
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_fence
or
Vulkan Version 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_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 Commands
vkGetFenceFdKHR
vkImportFenceFdKHR
New Structures
VkFenceGetFdInfoKHR
VkImportFenceFdInfoKHR
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.
Version History
Revision 1, 2017-05-08 (Jesse Hall)
Initial revision
VK_KHR_external_fence_win32
Name String
VK_KHR_external_fence_win32
Extension Type
Device extension
Registered Extension Number
115
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_fence
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 Commands
vkGetFenceWin32HandleKHR
vkImportFenceWin32HandleKHR
New Structures
VkFenceGetWin32HandleInfoKHR
VkImportFenceWin32HandleInfoKHR
Extending
VkFenceCreateInfo
VkExportFenceWin32HandleInfoKHR
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.
Version History
Revision 1, 2017-05-08 (Jesse Hall)
Initial revision
VK_KHR_external_memory_fd
Name String
VK_KHR_external_memory_fd
Extension Type
Device extension
Registered Extension Number
75
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
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 Commands
vkGetMemoryFdKHR
vkGetMemoryFdPropertiesKHR
New Structures
VkMemoryFdPropertiesKHR
VkMemoryGetFdInfoKHR
Extending
VkMemoryAllocateInfo
VkImportMemoryFdInfoKHR
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.
Version History
Revision 1, 2016-10-21 (James Jones)
Initial revision
VK_KHR_external_memory_win32
Name String
VK_KHR_external_memory_win32
Extension Type
Device extension
Registered Extension Number
74
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
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 Commands
vkGetMemoryWin32HandleKHR
vkGetMemoryWin32HandlePropertiesKHR
New Structures
VkMemoryGetWin32HandleInfoKHR
VkMemoryWin32HandlePropertiesKHR
Extending
VkMemoryAllocateInfo
VkExportMemoryWin32HandleInfoKHR
VkImportMemoryWin32HandleInfoKHR
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.
Version History
Revision 1, 2016-10-21 (James Jones)
Initial revision
VK_KHR_external_semaphore_fd
Name String
VK_KHR_external_semaphore_fd
Extension Type
Device extension
Registered Extension Number
80
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_semaphore
or
Vulkan Version 1.1
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 Commands
vkGetSemaphoreFdKHR
vkImportSemaphoreFdKHR
New Structures
VkImportSemaphoreFdInfoKHR
VkSemaphoreGetFdInfoKHR
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.
Version History
Revision 1, 2016-10-21 (Jesse Hall)
Initial revision
VK_KHR_external_semaphore_win32
Name String
VK_KHR_external_semaphore_win32
Extension Type
Device extension
Registered Extension Number
79
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_semaphore
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 Commands
vkGetSemaphoreWin32HandleKHR
vkImportSemaphoreWin32HandleKHR
New Structures
VkImportSemaphoreWin32HandleInfoKHR
VkSemaphoreGetWin32HandleInfoKHR
Extending
VkSemaphoreCreateInfo
VkExportSemaphoreWin32HandleInfoKHR
Extending
VkSubmitInfo
VkD3D12FenceSubmitInfoKHR
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.
Version History
Revision 1, 2016-10-21 (James Jones)
Initial revision
VK_KHR_fragment_shader_barycentric
Name String
VK_KHR_fragment_shader_barycentric
Extension Type
Device extension
Registered Extension Number
323
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_fragment_shader_barycentric
Contact
Stu Smith
Extension Proposal
VK_KHR_fragment_shader_barycentric
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
VK_NV_fragment_shader_barycentric
extension, and adds support for the following SPIR-V extension in Vulkan:
SPV_KHR_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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentShaderBarycentricFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentShaderBarycentricPropertiesKHR
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
New Built-In Variables
BaryCoordKHR
BaryCoordNoPerspKHR
New SPIR-V Decorations
PerVertexKHR
New SPIR-V Capabilities
FragmentBarycentricKHR
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 the
shaderSampleRateInterpolationFunctions
feature 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
Version History
Revision 1, 2022-03-10 (Stu Smith)
Initial revision
VK_KHR_fragment_shading_rate
Name String
VK_KHR_fragment_shading_rate
Extension Type
Device extension
Registered Extension Number
227
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_create_renderpass2
or
Vulkan Version 1.2
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Interacts with VK_KHR_format_feature_flags2
SPIR-V Dependencies
SPV_KHR_fragment_shading_rate
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_fragment_shading_rate
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 Commands
vkCmdSetFragmentShadingRateKHR
vkGetPhysicalDeviceFragmentShadingRatesKHR
New Structures
VkPhysicalDeviceFragmentShadingRateKHR
Extending
VkGraphicsPipelineCreateInfo
VkPipelineFragmentShadingRateStateCreateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentShadingRateFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentShadingRatePropertiesKHR
Extending
VkSubpassDescription2
VkFragmentShadingRateAttachmentInfoKHR
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkRenderingInfo
VkRenderingFragmentShadingRateAttachmentInfoKHR
New Enums
VkFragmentShadingRateCombinerOpKHR
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
Vulkan Version 1.3
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
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
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
to
vk.xml
VK_KHR_get_display_properties2
Name String
VK_KHR_get_display_properties2
Extension Type
Instance extension
Registered Extension Number
122
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_display
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 Commands
vkGetDisplayModeProperties2KHR
vkGetDisplayPlaneCapabilities2KHR
vkGetPhysicalDeviceDisplayPlaneProperties2KHR
vkGetPhysicalDeviceDisplayProperties2KHR
New Structures
VkDisplayModeProperties2KHR
VkDisplayPlaneCapabilities2KHR
VkDisplayPlaneInfo2KHR
VkDisplayPlaneProperties2KHR
VkDisplayProperties2KHR
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
().
Version History
Revision 1, 2017-02-21 (James Jones)
Initial draft.
VK_KHR_get_surface_capabilities2
Name String
VK_KHR_get_surface_capabilities2
Extension Type
Instance extension
Registered Extension Number
120
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Commands
vkGetPhysicalDeviceSurfaceCapabilities2KHR
vkGetPhysicalDeviceSurfaceFormats2KHR
New Structures
VkPhysicalDeviceSurfaceInfo2KHR
VkSurfaceCapabilities2KHR
VkSurfaceFormat2KHR
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
vkGetPhysicalDeviceSurfaceFormatsKHR
: Yes.
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.
Version History
Revision 1, 2017-02-27 (James Jones)
Initial draft.
VK_KHR_incremental_present
Name String
VK_KHR_incremental_present
Extension Type
Device extension
Registered Extension Number
85
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
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 Structures
VkPresentRegionKHR
VkRectLayerKHR
Extending
VkPresentInfoKHR
VkPresentRegionsKHR
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 structure 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.
Version History
Revision 1, 2016-11-02 (Ian Elliott)
Internal revisions
Revision 2, 2021-03-18 (Ian Elliott)
Clarified alignment of rectangles for presentation engines that support
transformed swapchains.
VK_KHR_internally_synchronized_queues
Name String
VK_KHR_internally_synchronized_queues
Extension Type
Device extension
Registered Extension Number
505
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_internally_synchronized_queues
Other Extension Metadata
Last Modified Date
2025-02-04
Contributors
Shahbaz Youssefi, Google
Daniel Rakos, RasterGrid
Jeff Bolz, Nvidia
Hans-Kristian Arntzen, Valve
Description
VK_KHR_internally_synchronized_queues
allows queues to opt into being
internally synchronized via the
VK_DEVICE_QUEUE_CREATE_INTERNALLY_SYNCHRONIZED_BIT_KHR
flag.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceInternallySynchronizedQueuesFeaturesKHR
New Enum Constants
VK_KHR_INTERNALLY_SYNCHRONIZED_QUEUES_EXTENSION_NAME
VK_KHR_INTERNALLY_SYNCHRONIZED_QUEUES_SPEC_VERSION
Extending
VkDeviceQueueCreateFlagBits
VK_DEVICE_QUEUE_CREATE_INTERNALLY_SYNCHRONIZED_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INTERNALLY_SYNCHRONIZED_QUEUES_FEATURES_KHR
Issues
None.
Version History
Revision 0, 2025-01-07 (Daniel Rakos)
Initial proposal
Revision 1, 2025-02-04 (Shahbaz Youssefi)
Initial revision
VK_KHR_maintenance10
Name String
VK_KHR_maintenance10
Extension Type
Device extension
Registered Extension Number
631
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_VERSION_1_4
Interacts with VK_KHR_copy_commands2
Interacts with VK_KHR_dynamic_rendering
Interacts with VK_KHR_dynamic_rendering_local_read
Interacts with VK_KHR_format_feature_flags2
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_KHR_maintenance10
Other Extension Metadata
Last Modified Date
2025-05-13
Interactions and External Dependencies
This extension interacts with
VK_KHR_format_feature_flags2
This extension interacts with
VK_EXT_extended_dynamic_state3
This extension interacts with
VK_KHR_dynamic_rendering_local_read
This extension interacts with
VK_KHR_depth_stencil_resolve
Contributors
Mike Blumenkrantz, Valve
Piers Daniell, NVIDIA
Hans-Kristian Arntzen, Valve
Description
VK_KHR_maintenance10
adds a collection of minor features, none of
which would warrant an entire extension of their own.
The new features are as follows:
New image format feature bits that indicate support for copying depth or
stencil aspects using non-graphics queue families
If
vkCmdSetSampleMaskEXT
is called with
pSampleMask
set to
NULL
, it is treated as if the mask has all bits set to
Add vkCmdEndRendering2KHR as an extensible version of vkCmdEndRendering
Add input attachment information to dynamic rendering
Require that vertex inputs follow sRGB encoding when those formats are
used, instead of being underspecified.
Add a query to determine if sRGB images are resolved in nonlinear or
linear space by default
Add an optional feature to allow applications to override the default
sRGB resolve behavior
Add resolve mode and depth-stencil resolve support to
vkCmdResolveImage2
to bring it in-line with render pass attachment
resolves
New Commands
vkCmdEndRendering2KHR
New Structures
VkRenderingEndInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance10FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance10PropertiesKHR
Extending
VkRenderingAttachmentInfo
VkRenderingAttachmentFlagsInfoKHR
Extending
VkResolveImageInfo2
VkResolveImageModeInfoKHR
New Enums
VkRenderingAttachmentFlagBitsKHR
VkResolveImageFlagBitsKHR
New Bitmasks
VkRenderingAttachmentFlagsKHR
VkResolveImageFlagsKHR
New Enum Constants
VK_KHR_MAINTENANCE_10_EXTENSION_NAME
VK_KHR_MAINTENANCE_10_SPEC_VERSION
Extending
VkAttachmentDescriptionFlagBits
VK_ATTACHMENT_DESCRIPTION_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR
VK_ATTACHMENT_DESCRIPTION_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_10_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_10_PROPERTIES_KHR
VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_FLAGS_INFO_KHR
VK_STRUCTURE_TYPE_RENDERING_END_INFO_KHR
VK_STRUCTURE_TYPE_RESOLVE_IMAGE_MODE_INFO_KHR
If
Vulkan Version 1.4
or
VK_KHR_dynamic_rendering_local_read
and
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkRenderingAttachmentFlagBitsKHR
VK_RENDERING_ATTACHMENT_INPUT_ATTACHMENT_FEEDBACK_BIT_KHR
Extending
VkRenderingFlagBits
VK_RENDERING_LOCAL_READ_CONCURRENT_ACCESS_CONTROL_BIT_KHR
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_DEPTH_COPY_ON_COMPUTE_QUEUE_BIT_KHR
VK_FORMAT_FEATURE_2_DEPTH_COPY_ON_TRANSFER_QUEUE_BIT_KHR
VK_FORMAT_FEATURE_2_STENCIL_COPY_ON_COMPUTE_QUEUE_BIT_KHR
VK_FORMAT_FEATURE_2_STENCIL_COPY_ON_TRANSFER_QUEUE_BIT_KHR
If
Vulkan Version 1.3
or
VK_KHR_copy_commands2
is supported:
Extending
VkResolveImageFlagBitsKHR
VK_RESOLVE_IMAGE_ENABLE_TRANSFER_FUNCTION_BIT_KHR
VK_RESOLVE_IMAGE_SKIP_TRANSFER_FUNCTION_BIT_KHR
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkRenderingAttachmentFlagBitsKHR
VK_RENDERING_ATTACHMENT_RESOLVE_ENABLE_TRANSFER_FUNCTION_BIT_KHR
VK_RENDERING_ATTACHMENT_RESOLVE_SKIP_TRANSFER_FUNCTION_BIT_KHR
Issues
None.
Version History
Revision 1, 2025-05-13 (Mike Blumenkrantz)
Initial revision
VK_KHR_maintenance7
Name String
VK_KHR_maintenance7
Extension Type
Device extension
Registered Extension Number
563
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_KHR_maintenance7
Other Extension Metadata
Last Modified Date
2024-01-30
Interactions and External Dependencies
Contributors
Mike Blumenkrantz, Valve
Hans-Kristian Arntzen, Valve
Pan Gao, Huawei
Tobias Hector, AMD
Jon Leech, Khronos
Daniel Story, Nintendo
Shahbaz Youssefi, Google
Yiwei Zhang, Google
Matthew Netsch, Qualcomm
Description
VK_KHR_maintenance7
adds a collection of minor features, none of
which would warrant an entire extension of their own.
The proposed new features are as follows:
Add a property query to determine if a framebuffer writes to depth or
stencil aspect does not trigger a write access in the sibling aspect.
For example, this allows sampling stencil aspect as a texture while
rendering to the sibling depth attachment and vice-versa given
appropriate image layouts.
Add a way to query information regarding the underlying devices in
environments where the Vulkan implementation is provided through layered
implementations.
For example, running on Mesa/Venus, driver ID is returned as
VK_DRIVER_ID_MESA_VENUS
, but it can be necessary to know what the
real driver under the hood is.
The new
VkPhysicalDeviceLayeredApiPropertiesKHR
structure can be
used to gather information regarding layers underneath the top-level
physical device.
Promote
VK_RENDERING_CONTENTS_INLINE_BIT_EXT
and
VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_EXT
to
KHR
Add a limit to report the maximum total count of dynamic uniform buffers
and dynamic storage buffers that can be included in a pipeline layout.
Require that for an unsigned integer query, the 32-bit result value
must
be equal to the 32 least significant bits of the equivalent 64-bit
result value.
Add query for robust access support when using fragment shading rate
attachments
New Structures
VkPhysicalDeviceLayeredApiPropertiesKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance7FeaturesKHR
Extending
VkPhysicalDeviceLayeredApiPropertiesKHR
VkPhysicalDeviceLayeredApiVulkanPropertiesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceLayeredApiPropertiesListKHR
VkPhysicalDeviceMaintenance7PropertiesKHR
New Enums
VkPhysicalDeviceLayeredApiKHR
New Enum Constants
VK_KHR_MAINTENANCE_7_EXTENSION_NAME
VK_KHR_MAINTENANCE_7_SPEC_VERSION
Extending
VkRenderingFlagBits
VK_RENDERING_CONTENTS_INLINE_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_PROPERTIES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_PROPERTIES_LIST_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_API_VULKAN_PROPERTIES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_7_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_7_PROPERTIES_KHR
Extending
VkSubpassContents
VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_KHR
Issues
None.
Version History
Revision 1, 2024-01-30 (Jon Leech)
Initial revision
VK_KHR_maintenance8
Name String
VK_KHR_maintenance8
Extension Type
Device extension
Registered Extension Number
575
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_KHR_maintenance8
Other Extension Metadata
Last Modified Date
2025-01-07
Interactions and External Dependencies
Contributors
Jon Leech, Khronos
Mike Blumenkrantz, Valve
Spencer Fricke, LunarG
Jan-Harald Fredriksen, ARM
Piers Daniell, NVIDIA
Matthew Netsch, Qualcomm
Ricardo Garcia, Igalia
Lionel Landwerlin, Intel
Rick Hammerstone, Qualcomm
Daniel Story, Nintendo
Hans-Kristian Arntzen, Valve
Caterina Shablia, Collabora
Georg Lehmann, Valve
Shahbaz Youssefi, Google
Tobias Hector, AMD
Description
VK_KHR_maintenance8
adds a collection of minor features, none of
which would warrant an entire extension of their own.
The new features are as follows:
Allow copies between depth/stencil and “matching” color attachments
Allow
dstCache
in
vkMergePipelineCaches
to be implicitly
synchronized.
Require src/dst sync scopes to work when doing queue family ownership
transfers
Support
Offset
(as an alternative to
ConstOffset
) image operand in
texture sampling and fetch operations
Use the SPIR-V definition of
OpSRem
and
OpSMod
, making these
operations produce well-defined results for negative operands
Loosen layer restrictions when blitting from 3D images to other image
types
Add space for an additional 64 access flags for use with
VkMemoryBarrier2, VkBufferMemoryBarrier2, and VkImageMemoryBarrier2
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance8FeaturesKHR
Extending
VkSubpassDependency2
VkBufferMemoryBarrier2
VkImageMemoryBarrier2
VkMemoryRangeBarriersInfoKHR
VkMemoryBarrierAccessFlags3KHR
New Enums
VkAccessFlagBits3KHR
VkPipelineCacheCreateFlagBits
New Bitmasks
VkAccessFlags3KHR
New Enum Constants
VK_KHR_MAINTENANCE_8_EXTENSION_NAME
VK_KHR_MAINTENANCE_8_SPEC_VERSION
Extending
VkDependencyFlagBits
VK_DEPENDENCY_QUEUE_FAMILY_OWNERSHIP_TRANSFER_USE_ALL_STAGES_BIT_KHR
Extending
VkPipelineCacheCreateFlagBits
VK_PIPELINE_CACHE_CREATE_INTERNALLY_SYNCHRONIZED_MERGE_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_MEMORY_BARRIER_ACCESS_FLAGS_3_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_8_FEATURES_KHR
Issues
None.
Version History
Revision 1, 2024-06-20 (Jon Leech)
Initial revision
VK_KHR_maintenance9
Name String
VK_KHR_maintenance9
Extension Type
Device extension
Registered Extension Number
585
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_KHR_maintenance9
Other Extension Metadata
Last Modified Date
2025-05-29
Interactions and External Dependencies
Contributors
Mike Blumenkrantz, Valve
Shahbaz Youssefi, Google
Hans-Kristian Arntzen, Valve
Piers Daniell, NVIDIA
Daniel Story, Nintendo
Jeff Bolz, NVIDIA
Description
VK_KHR_maintenance9
adds a collection of minor features, none of
which would warrant an entire extension of their own.
The new features are as follows:
Support VkDevice with no queues.
These can be used as effectively an offline compiler to prepopulate
pipeline caches, without expensive queue creation or internal memory
allocations.
Allow
vkCmdSetEvent2
to not provide a dependency, providing
vkCmdSetEvent
-style usage using enums from
VK_KHR_synchronization2
Add a
VkQueryPoolCreateFlagBits
::
VK_QUERY_POOL_CREATE_RESET_BIT_KHR
flag to create a query pool with all queries initialized to the reset
state.
Allow any integer bit width for specific bit-wise operations.
Add a property to enable sparse support with
VK_EXT_image_2d_view_of_3d
Add a property to indicate the implementation will return (0,0,0,0) or
(0,0,0,1) to vertex shaders that read unassigned attributes.
The effects of image memory barriers and image layout transitions on 3D
images created with VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT are scoped
to the slices specified by the user-provided VkImageSubresourceRange.
Queue family ownership transfers are no longer required for buffers and
linear images, and a new physical device queue family property is
exposed to indicate whether queue family ownership transfers are
required for optimal images.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance9FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance9PropertiesKHR
Extending
VkQueueFamilyProperties2
VkQueueFamilyOwnershipTransferPropertiesKHR
New Enums
VkDefaultVertexAttributeValueKHR
New Enum Constants
VK_KHR_MAINTENANCE_9_EXTENSION_NAME
VK_KHR_MAINTENANCE_9_SPEC_VERSION
Extending
VkDependencyFlagBits
VK_DEPENDENCY_ASYMMETRIC_EVENT_BIT_KHR
Extending
VkQueryPoolCreateFlagBits
VK_QUERY_POOL_CREATE_RESET_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_9_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_9_PROPERTIES_KHR
VK_STRUCTURE_TYPE_QUEUE_FAMILY_OWNERSHIP_TRANSFER_PROPERTIES_KHR
Issues
None.
Version History
Revision 1, 2025-05-29 (Contributors)
Internal revisions
VK_KHR_performance_query
Name String
VK_KHR_performance_query
Extension Type
Device extension
Registered Extension Number
117
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
Developer tools
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 Commands
vkAcquireProfilingLockKHR
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR
vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR
vkReleaseProfilingLockKHR
New Structures
VkAcquireProfilingLockInfoKHR
VkPerformanceCounterDescriptionKHR
VkPerformanceCounterKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePerformanceQueryFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePerformanceQueryPropertiesKHR
Extending
VkQueryPoolCreateInfo
VkQueryPoolPerformanceCreateInfoKHR
Extending
VkSubmitInfo
VkSubmitInfo2
VkPerformanceQuerySubmitInfoKHR
New Unions
VkPerformanceCounterResultKHR
New Enums
VkAcquireProfilingLockFlagBitsKHR
VkPerformanceCounterDescriptionFlagBitsKHR
VkPerformanceCounterScopeKHR
VkPerformanceCounterStorageKHR
VkPerformanceCounterUnitKHR
New Bitmasks
VkAcquireProfilingLockFlagsKHR
VkPerformanceCounterDescriptionFlagsKHR
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
and end the query in command buffer
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;
Version History
Revision 1, 2019-10-08
VK_KHR_pipeline_binary
Name String
VK_KHR_pipeline_binary
Extension Type
Device extension
Registered Extension Number
484
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_maintenance5
or
Vulkan Version 1.4
Contact
Stu Smith
stu-s
Extension Proposal
VK_KHR_pipeline_binary
Other Extension Metadata
Last Modified Date
2024-07-01
Contributors
Stu Smith, AMD
Tobias Hector, AMD
Alan Harrison, AMD
Maciej Jesionowski, AMD
Younggwan Kim, Arm
Jan-Harald Fredriksen, Arm
Ting Wei, Arm
Chris Glover, Google
Shahbaz Youssefi, Google
Jakub Kuderski, Google
Piotr Byszewski, Mobica
Piers Daniell, NVIDIA
Ralph Potter, Samsung
Matthew Netsch, Qualcomm
Hans-Kristian Arntzen, Valve
Samuel Pitoiset, Valve
Tatsuyuki Ishi, Valve
Description
This extension provides a method to obtain binary data associated with
individual pipelines such that applications can manage caching themselves
instead of using VkPipelineCache objects.
New Object Types
VkPipelineBinaryKHR
New Commands
vkCreatePipelineBinariesKHR
vkDestroyPipelineBinaryKHR
vkGetPipelineBinaryDataKHR
vkGetPipelineKeyKHR
vkReleaseCapturedPipelineDataKHR
New Structures
VkPipelineBinaryCreateInfoKHR
VkPipelineBinaryDataInfoKHR
VkPipelineBinaryDataKHR
VkPipelineBinaryHandlesInfoKHR
VkPipelineBinaryKeyKHR
VkPipelineBinaryKeysAndDataKHR
VkPipelineCreateInfoKHR
VkReleaseCapturedPipelineDataInfoKHR
Extending
VkDeviceCreateInfo
VkDevicePipelineBinaryInternalCacheControlKHR
Extending
VkGraphicsPipelineCreateInfo
VkComputePipelineCreateInfo
VkRayTracingPipelineCreateInfoKHR
VkPipelineBinaryInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineBinaryFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePipelineBinaryPropertiesKHR
New Enum Constants
VK_KHR_PIPELINE_BINARY_EXTENSION_NAME
VK_KHR_PIPELINE_BINARY_SPEC_VERSION
VK_MAX_PIPELINE_BINARY_KEY_SIZE_KHR
Extending
VkObjectType
VK_OBJECT_TYPE_PIPELINE_BINARY_KHR
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_CAPTURE_DATA_BIT_KHR
Extending
VkResult
VK_ERROR_NOT_ENOUGH_SPACE_KHR
VK_PIPELINE_BINARY_MISSING_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_PIPELINE_BINARY_INTERNAL_CACHE_CONTROL_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_BINARY_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_BINARY_PROPERTIES_KHR
VK_STRUCTURE_TYPE_PIPELINE_BINARY_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_PIPELINE_BINARY_DATA_INFO_KHR
VK_STRUCTURE_TYPE_PIPELINE_BINARY_HANDLES_INFO_KHR
VK_STRUCTURE_TYPE_PIPELINE_BINARY_INFO_KHR
VK_STRUCTURE_TYPE_PIPELINE_BINARY_KEY_KHR
VK_STRUCTURE_TYPE_PIPELINE_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_RELEASE_CAPTURED_PIPELINE_DATA_INFO_KHR
Version History
Revision 1, 2021-12-10 (Chris Glover)
Initial draft.
VK_KHR_pipeline_executable_properties
Name String
VK_KHR_pipeline_executable_properties
Extension Type
Device extension
Registered Extension Number
270
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
Developer tools
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 Commands
vkGetPipelineExecutableInternalRepresentationsKHR
vkGetPipelineExecutablePropertiesKHR
vkGetPipelineExecutableStatisticsKHR
New Structures
VkPipelineExecutableInfoKHR
VkPipelineExecutableInternalRepresentationKHR
VkPipelineExecutablePropertiesKHR
VkPipelineExecutableStatisticKHR
VkPipelineInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineExecutablePropertiesFeaturesKHR
New Unions
VkPipelineExecutableStatisticValueKHR
New Enums
VkPipelineExecutableStatisticFormatKHR
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.
Version History
Revision 1, 2019-05-28 (Faith Ekstrand)
Initial draft
VK_KHR_pipeline_library
Name String
VK_KHR_pipeline_library
Extension Type
Device extension
Registered Extension Number
291
Revision
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 Structures
Extending
VkGraphicsPipelineCreateInfo
VkPipelineLibraryCreateInfoKHR
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
Version History
Revision 1, 2020-01-08 (Christoph Kubisch)
Initial draft.
VK_KHR_portability_enumeration
Name String
VK_KHR_portability_enumeration
Extension Type
Instance extension
Registered Extension Number
395
Revision
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
Version History
Revision 1, 2021-06-02 (Lenny Komow)
Initial version
VK_KHR_present_id
Name String
VK_KHR_present_id
Extension Type
Device extension
Registered Extension Number
295
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentIdFeaturesKHR
Extending
VkPresentInfoKHR
VkPresentIdKHR
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
Issues
None.
Examples
Version History
Revision 1, 2019-05-15 (Keith Packard)
Initial version
VK_KHR_present_id2
Name String
VK_KHR_present_id2
Extension Type
Device extension
Registered Extension Number
480
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_surface_capabilities2
and
VK_KHR_surface
and
VK_KHR_swapchain
Contact
Daniel Stone
Extension Proposal
VK_KHR_present_id2
Other Extension Metadata
Last Modified Date
2025-01-06
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
James Jones, NVIDIA
Daniel Stone, Collabora
Derek Foreman, Collabora
contributors to `
VK_KHR_present_id
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentId2FeaturesKHR
Extending
VkPresentInfoKHR
VkPresentId2KHR
Extending
VkSurfaceCapabilities2KHR
VkSurfaceCapabilitiesPresentId2KHR
New Enum Constants
VK_KHR_PRESENT_ID_2_EXTENSION_NAME
VK_KHR_PRESENT_ID_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_ID_2_FEATURES_KHR
VK_STRUCTURE_TYPE_PRESENT_ID_2_KHR
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_PRESENT_ID_2_KHR
Extending
VkSwapchainCreateFlagBitsKHR
VK_SWAPCHAIN_CREATE_PRESENT_ID_2_BIT_KHR
Issues
None.
Examples
Version History
Revision 1, 2022-05-10 (Daniel Stone)
Repurposed VK_KHR_present_id to be driven by surface capabilities
VK_KHR_present_mode_fifo_latest_ready
Name String
VK_KHR_present_mode_fifo_latest_ready
Extension Type
Device extension
Registered Extension Number
622
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
Contact
Lionel Duc
nvlduc
Extension Proposal
VK_KHR_present_mode_fifo_latest_ready
Other Extension Metadata
Last Modified Date
2025-03-18
IP Status
No known IP claims.
Contributors
James Jones, NVIDIA
Lionel Duc, NVIDIA
Lina Versace, Google
Description
This extension is based on
VK_EXT_present_mode_fifo_latest_ready
and provides equivalent functionality.
This extension adds a new present mode,
VK_PRESENT_MODE_FIFO_LATEST_READY_KHR
This tear-free present mode behaves much like
VK_PRESENT_MODE_FIFO_KHR
, except that each vertical blanking period
dequeues consecutive present requests until the latest ready is found to
update the current image.
While this seems similar in concept to
VK_PRESENT_MODE_MAILBOX_KHR
the fundamental difference is that the processing of the present requests is
done during vblank.
From the application perspective, this means for example, that in a
flip-based model, a single vblank
may
cause multiple swapchain images to be
released at once, while
VK_PRESENT_MODE_MAILBOX_KHR
may
continuously
be releasing images as new requests become ready.
This additional present mode is useful when using a time-based present API.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentModeFifoLatestReadyFeaturesKHR
New Enum Constants
VK_KHR_PRESENT_MODE_FIFO_LATEST_READY_EXTENSION_NAME
VK_KHR_PRESENT_MODE_FIFO_LATEST_READY_SPEC_VERSION
Extending
VkPresentModeKHR
VK_PRESENT_MODE_FIFO_LATEST_READY_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_MODE_FIFO_LATEST_READY_FEATURES_KHR
Version History
Revision 1, 2025-03-18 (Lina Versace)
Internal revisions
VK_KHR_present_wait
Name String
VK_KHR_present_wait
Extension Type
Device extension
Registered Extension Number
249
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_present_id
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 Commands
vkWaitForPresentKHR
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentWaitFeaturesKHR
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 specification.
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.
Examples
Version History
Revision 1, 2019-02-19 (Keith Packard)
Initial version
VK_KHR_present_wait2
Name String
VK_KHR_present_wait2
Extension Type
Device extension
Registered Extension Number
481
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_surface_capabilities2
and
VK_KHR_surface
and
VK_KHR_swapchain
and
VK_KHR_present_id2
Contact
Daniel Stone
Extension Proposal
VK_KHR_present_wait2
Other Extension Metadata
Last Modified Date
2025-05-30
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
James Jones, NVIDIA
Daniel Stone, Collabora
Derek Foreman, Collabora
contributors to `
VK_KHR_present_wait
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 Commands
vkWaitForPresent2KHR
New Structures
VkPresentWait2InfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentWait2FeaturesKHR
Extending
VkSurfaceCapabilities2KHR
VkSurfaceCapabilitiesPresentWait2KHR
New Enum Constants
VK_KHR_PRESENT_WAIT_2_EXTENSION_NAME
VK_KHR_PRESENT_WAIT_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_2_FEATURES_KHR
VK_STRUCTURE_TYPE_PRESENT_WAIT_2_INFO_KHR
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_PRESENT_WAIT_2_KHR
Extending
VkSwapchainCreateFlagBitsKHR
VK_SWAPCHAIN_CREATE_PRESENT_WAIT_2_BIT_KHR
Issues
1) When does the wait finish?
RESOLVED
The wait request will complete when the timeout expires, or after the
corresponding presentation request has either taken effect within the
presentation engine or has been replaced without presentation.
Additionally, a wait may complete immediately if the swapchain becomes out
of date.
In circumstances outside the application’s control, this wait may be
particularly long.
For example, a user session may have the display locked and switched off for
multiple days.
During this time, the latest image presented through the WSI will never be
presented to the user (because nothing is being presented), or replaced
(because nothing newer has been queued by the application).
Each operating system may have a separate mechanism to inform the
application of states such as these, however it is out of scope of the
Vulkan WSI.
There is no requirement for any precise timing relationship between the
presentation of the image to the user and the end of the wait.
This extension is not intended for time-to-light estimation, which is better
solved by a separate extension dedicated to present-timing feedback for
audio/visual/input synchronization.
2) Should this use fences or other existing synchronization mechanism?
RESOLVED
VkFence is a legacy primitive.
Building a new API around a legacy primitive is undesirable.
Other existing synchronization mechanisms may lack a platform-provided
framework for sharing synchronization objects between display and render
drivers.
For these reasons, 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_id2
, should be created to provide a
shared structure for presentation identifiers.
4) What happens when presentations complete out of order with respect to
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 specification.
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.
OPTION D
: The order of completion between outstanding
vkWaitForPresent2KHR
calls is always undefined.
However, a
VK_SUCCESS
return value in
VkPresentWait2InfoKHR
::
presentId
implies that future calls to
vkWaitForPresent2KHR
where
VkPresentWait2InfoKHR
::
presentId
is less than or equal to N will
complete immediately.
RESOLVED
OPTION D
: This option ensures implementations do not need to create
complex internal queues to generate signals in the right order.
5) Should this extension deviate from
VK_KHR_present_wait
and
require the presentation engine to provide the presentId values?
RESOLVED
No.
This extension is intended to be a bugfix of
VK_KHR_present_wait
and existing low-latency apis require an application provided id.
At least on some platforms, a mapping mechanism would be required to
translate between presentation engine and application ids.
This exceeds the intended scope of this extension.
When needed in the future, we can introduce an independent presentation
engine driven id and a mechanism for mapping presentation engine ids to
application provided ids.
Examples
Version History
Revision 1, 2022-10-05 (Daniel Stone)
Repurposed from VK_KHR_present_wait to be based on surface capabilities
Reworded wait finish section to avoid time-to-light
VK_KHR_ray_query
Name String
VK_KHR_ray_query
Extension Type
Device extension
Registered Extension Number
349
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_spirv_1_4
or
Vulkan Version 1.2
and
VK_KHR_acceleration_structure
SPIR-V Dependencies
SPV_KHR_ray_query
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayQueryFeaturesKHR
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
New SPIR-V Capabilities
RayQueryKHR
RayTraversalPrimitiveCullingKHR
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 for
OpRayQueryGenerateIntersectionKHR
(#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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_EXT_device_generated_commands
Interacts with VK_KHR_ray_tracing_pipeline
Interacts with VK_KHR_synchronization2
SPIR-V Dependencies
SPV_KHR_ray_cull_mask
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-in
CullMaskKHR
shader
variable which contains the value of the
OpTrace*
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 Commands
If
VK_KHR_ray_tracing_pipeline
is supported:
vkCmdTraceRaysIndirect2KHR
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingMaintenance1FeaturesKHR
If
VK_KHR_ray_tracing_pipeline
is supported:
VkTraceRaysIndirectCommand2KHR
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
Vulkan Version 1.3
and
VK_KHR_ray_tracing_pipeline
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_SHADER_BINDING_TABLE_READ_BIT_KHR
If
VK_EXT_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeEXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_TRACE_RAYS2_EXT
If
VK_KHR_synchronization2
or
Vulkan Version 1.3
is supported:
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR
New Built-In Variables
CullMaskKHR
New SPIR-V Capabilities
RayCullMaskKHR
Issues
None Yet!
Version History
Revision 1, 2022-02-21 (Members of the Vulkan Ray Tracing TSG)
internal revisions
VK_KHR_ray_tracing_pipeline
Name String
VK_KHR_ray_tracing_pipeline
Extension Type
Device extension
Registered Extension Number
348
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_spirv_1_4
or
Vulkan Version 1.2
and
VK_KHR_acceleration_structure
API Interactions
Interacts with VK_KHR_ray_query
SPIR-V Dependencies
SPV_KHR_ray_tracing
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 the
ShaderCallKHR
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 Commands
vkCmdSetRayTracingPipelineStackSizeKHR
vkCmdTraceRaysIndirectKHR
vkCmdTraceRaysKHR
vkCreateRayTracingPipelinesKHR
vkGetRayTracingCaptureReplayShaderGroupHandlesKHR
vkGetRayTracingShaderGroupHandlesKHR
vkGetRayTracingShaderGroupStackSizeKHR
New Structures
VkRayTracingPipelineCreateInfoKHR
VkRayTracingPipelineInterfaceCreateInfoKHR
VkRayTracingShaderGroupCreateInfoKHR
VkStridedDeviceAddressRegionKHR
VkTraceRaysIndirectCommandKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingPipelineFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRayTracingPipelinePropertiesKHR
New Enums
VkRayTracingShaderGroupTypeKHR
VkShaderGroupShaderKHR
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
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_BUILT_IN_PRIMITIVES_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
New or Modified Built-In Variables
LaunchIdKHR
LaunchSizeKHR
WorldRayOriginKHR
WorldRayDirectionKHR
ObjectRayOriginKHR
ObjectRayDirectionKHR
RayTminKHR
RayTmaxKHR
InstanceCustomIndexKHR
InstanceId
ObjectToWorldKHR
WorldToObjectKHR
HitKindKHR
IncomingRayFlagsKHR
RayGeometryIndexKHR
(modified)
PrimitiveId
New SPIR-V Capabilities
RayTracingKHR
RayTraversalPrimitiveCullingKHR
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
to
maxRayRecursionDepth
and it
has a minimum of 1 instead of 31
require
shaderGroupHandleSize
to be 32 bytes
added
maxRayDispatchInvocationCount
shaderGroupHandleAlignment
and
maxRayHitAttributeSize
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
watertightness guarantees
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
(2) Can you give a more detailed comparison of differences and similarities
between VK_NV_ray_tracing and VK_KHR_ray_tracing_pipeline?
DISCUSSION
The following is a more detailed comparison of which commands, structures,
and enums are aliased, changed, or removed.
Aliased functionality — enums, structures, and commands that are
considered equivalent:
VkRayTracingShaderGroupTypeNV
VkRayTracingShaderGroupTypeKHR
vkGetRayTracingShaderGroupHandlesNV
vkGetRayTracingShaderGroupHandlesKHR
Changed enums, structures, and commands:
VkRayTracingShaderGroupCreateInfoNV
VkRayTracingShaderGroupCreateInfoKHR
(added
pShaderGroupCaptureReplayHandle
VkRayTracingPipelineCreateInfoNV
VkRayTracingPipelineCreateInfoKHR
(changed type of
pGroups
added
libraries
pLibraryInterface
, and
pDynamicState
VkPhysicalDeviceRayTracingPropertiesNV
VkPhysicalDeviceRayTracingPipelinePropertiesKHR
(renamed
maxTriangleCount
to
maxPrimitiveCount
, added
shaderGroupHandleCaptureReplaySize
vkCmdTraceRaysNV
vkCmdTraceRaysKHR
(params to struct)
vkCreateRayTracingPipelinesNV
vkCreateRayTracingPipelinesKHR
(different struct, changed
functionality)
Added enums, structures, and commands:
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_MISS_SHADERS_BIT_KHR
VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR
VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR
VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR
to
VkPipelineCreateFlagBits
VkPhysicalDeviceRayTracingPipelineFeaturesKHR
structure
VkDeviceOrHostAddressKHR
and
VkDeviceOrHostAddressConstKHR
unions
VkPipelineLibraryCreateInfoKHR
struct
VkRayTracingPipelineInterfaceCreateInfoKHR
struct
VkStridedDeviceAddressRegionKHR
struct
vkCmdTraceRaysIndirectKHR
command and
VkTraceRaysIndirectCommandKHR
struct
vkGetRayTracingCaptureReplayShaderGroupHandlesKHR
(shader group
capture/replay)
vkCmdSetRayTracingPipelineStackSizeKHR
and
vkGetRayTracingShaderGroupStackSizeKHR
commands for stack size
control
Functionality removed:
VK_PIPELINE_CREATE_DEFER_COMPILE_BIT_NV
vkCompileDeferredNV
command (replaced with
VK_KHR_deferred_host_operations
(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
to
pLibraryInfo
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
of
VK_BUFFER_USAGE_RAY_TRACING_BIT_NV
and is required on shader
binding table buffers
VK_BUFFER_USAGE_STORAGE_BUFFER_BIT
is used in
VK_KHR_acceleration_structure
for
scratchData
rename
maxRecursionDepth
to
maxRayPipelineRecursionDepth
(pipeline creation) and
maxRayRecursionDepth
(limit) to reduce
confusion
Add queryable
maxRayHitAttributeSize
limit and rename members of
VkRayTracingPipelineInterfaceCreateInfoKHR
to
maxPipelineRayPayloadSize
and
maxPipelineRayHitAttributeSize
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 “Device Extensions” section
says it is required to be supported anyhow?
RESOLVED
: If the
VK_KHR_pipeline_library
extension were a
required 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 as a requirement in device extensions 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
, and
HitAttributeKHR
(!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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
SPIR-V Dependencies
SPV_KHR_ray_tracing_position_fetch
Contact
Eric Werness
Extension Proposal
VK_KHR_ray_tracing_position_fetch
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_BIT_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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingPositionFetchFeaturesKHR
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_BIT_KHR
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_POSITION_FETCH_FEATURES_KHR
New Built-In Variables
HitTriangleVertexPositionsKHR
New SPIR-V Capabilities
RayTracingPositionFetchKHR
RayQueryPositionFetchKHR
Issues
None Yet!
Version History
Revision 1, 2023-02-17 (Eric Werness)
internal revisions
VK_KHR_robustness2
Name String
VK_KHR_robustness2
Extension Type
Device extension
Registered Extension Number
613
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2025-01-10
IP Status
No known IP claims.
Contributors
Liam Middlebrook, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension is based on the
VK_EXT_robustness2
extension.
This extension adds stricter requirements for how out of bounds reads and
writes are handled.
Most accesses
must
be tightly bounds-checked, out of bounds writes
must
be
discarded, out of bound reads
must
return zero.
Rather than allowing multiple possible
(0,0,0,x)
vectors, the out of
bounds values are treated as zero, and then missing components are inserted
based on the format as described in
Component Substitution
and
vertex input attribute extraction
These additional requirements
may
be expensive on some implementations, and
should only be enabled when truly necessary.
This extension also adds support for “null descriptors”, where
VK_NULL_HANDLE
can
be used instead of a valid handle.
Accesses to null descriptors have well-defined behavior, and do not rely on
robustness.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRobustness2FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRobustness2PropertiesKHR
New Enum Constants
VK_KHR_ROBUSTNESS_2_EXTENSION_NAME
VK_KHR_ROBUSTNESS_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_KHR
Issues
Why do
VkPhysicalDeviceRobustness2PropertiesKHR
::
robustUniformBufferAccessSizeAlignment
and
VkPhysicalDeviceRobustness2PropertiesKHR
::
robustStorageBufferAccessSizeAlignment
exist?
RESOLVED
: Some implementations cannot efficiently tightly bounds-check all
buffer accesses.
Rather, the size of the bound range is padded to some power of two multiple,
up to 256 bytes for uniform buffers and up to 4 bytes for storage buffers,
and that padded size is bounds-checked.
This is sufficient to implement D3D-like behavior, because D3D only allows
binding whole uniform buffers or ranges that are a multiple of 256 bytes,
and D3D raw and structured buffers only support 32-bit accesses.
Version History
Revision 1, 2025-01-10 (Piers Daniell)
Internal revisions
VK_KHR_shader_abort
Name String
VK_KHR_shader_abort
Extension Type
Device extension
Registered Extension Number
234
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_device_fault
and
VK_KHR_shader_constant_data
SPIR-V Dependencies
SPV_KHR_abort
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_shader_abort
Other Extension Metadata
Last Modified Date
2026-03-18
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Piers Daniell, Nvidia
Craig Graham, Samsung
Erik Hogeman, ARM
Ralph Potter, Samsung
Vikram Tarikere, IMG
Description
This extension enables the use of the
OpAbortKHR
instruction in
shaders.
New Structures
Extending
VkDeviceFaultDebugInfoKHR
VkDeviceFaultShaderAbortMessageInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderAbortFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderAbortPropertiesKHR
New Enum Constants
VK_KHR_SHADER_ABORT_EXTENSION_NAME
VK_KHR_SHADER_ABORT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_FAULT_SHADER_ABORT_MESSAGE_INFO_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ABORT_FEATURES_KHR
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ABORT_PROPERTIES_KHR
Version History
Revision 1, 2024-08-22 (Tobias Hector)
Initial revision
VK_KHR_shader_bfloat16
Name String
VK_KHR_shader_bfloat16
Extension Type
Device extension
Registered Extension Number
142
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_KHR_cooperative_matrix
SPIR-V Dependencies
SPV_KHR_bfloat16
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_shader_bfloat16
Other Extension Metadata
Last Modified Date
2024-04-09
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Stu Smith, AMD
Jeff Bolz, Nvidia
Kévin Petit, Arm
David Neto, Google
Graeme Leese, Broadcom
Ruihao Zhang, Qualcomm
Mark Sheppard, Imagination
Ben Ashbaugh, Intel
Dmitry Sidorov, Intel
Victor Mustya, Intel
Description
This extension enables support for bfloat16 (“brain float”) operations in
shaders as defined in
SPV_KHR_bfloat16
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderBfloat16FeaturesKHR
New Enum Constants
VK_KHR_SHADER_BFLOAT16_EXTENSION_NAME
VK_KHR_SHADER_BFLOAT16_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_BFLOAT16_FEATURES_KHR
If
VK_KHR_cooperative_matrix
is supported:
Extending
VkComponentTypeKHR
VK_COMPONENT_TYPE_BFLOAT16_KHR
New SPIR-V Capabilities
BFloat16TypeKHR
BFloat16DotProductKHR
BFloat16CooperativeMatrixKHR
Version History
Revision 1, 2024-04-09 (Stu Smith)
Initial draft
VK_KHR_shader_clock
Name String
VK_KHR_shader_clock
Extension Type
Device extension
Registered Extension Number
182
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_shader_clock
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
and
GL_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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderClockFeaturesKHR
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
New SPIR-V Capabilities
ShaderClockKHR
Version History
Revision 1, 2019-4-25 (Aaron Hagan)
Initial revision
VK_KHR_shader_constant_data
Name String
VK_KHR_shader_constant_data
Extension Type
Device extension
Registered Extension Number
232
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_constant_data
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_shader_constant_data
Other Extension Metadata
Last Modified Date
2026-03-18
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Piers Daniell, Nvidia
Craig Graham, Samsung
Vikram Tarikere, IMG
Description
This extension allows the use of the
SPV_KHR_constant_data
extension in
SPIR-V shader modules which enables the specification and specialization of
arrays of constant data.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderConstantDataFeaturesKHR
New Enum Constants
VK_KHR_SHADER_CONSTANT_DATA_EXTENSION_NAME
VK_KHR_SHADER_CONSTANT_DATA_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CONSTANT_DATA_FEATURES_KHR
New SPIR-V Capabilities
ConstantDataKHR
Version History
Revision 1, 2024-10-30 (Tobias Hector)
Initial revision
VK_KHR_shader_fma
Name String
VK_KHR_shader_fma
Extension Type
Device extension
Registered Extension Number
580
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_fma
Contact
Graeme Leese
gnl21
Extension Proposal
VK_KHR_shader_fma
Other Extension Metadata
Last Modified Date
2025-06-10
Contributors
Graeme Leese, Broadcom
Description
This extension allows applications to use the SPV_KHR_fma extension to
obtain correctly-rounded results for fused-multiply add (fma) operations.
Fused-multiply add is a building block of many high-precision numerical
functions.
It provides better accuracy than separate operations, because of the removal
of the intermediate rounding step, and often costs less than the pair of
separate operations.
Vulkan currently exposes an fma primitive that can give the reduced cost,
but it is not guaranteed to be a fused operation, so the accuracy cannot be
relied on.
For applications which require the high accuracy, therefore, the operation
must be emulated or the algorithm changed so as not to require fma.
This is often vastly more costly, even though fma is supported in much of
the underlying hardware.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderFmaFeaturesKHR
New Enum Constants
VK_KHR_SHADER_FMA_EXTENSION_NAME
VK_KHR_SHADER_FMA_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FMA_FEATURES_KHR
Version History
Revision 1, 2025-06-10 (Graeme Leese)
Initial draft
VK_KHR_shader_maximal_reconvergence
Name String
VK_KHR_shader_maximal_reconvergence
Extension Type
Device extension
Registered Extension Number
435
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_maximal_reconvergence
Contact
Alan Baker
alan-baker
Extension Proposal
VK_KHR_shader_maximal_reconvergence
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR
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
Version History
Revision 1, 2021-11-12 (Alan Baker)
Internal draft version
VK_KHR_shader_quad_control
Name String
VK_KHR_shader_quad_control
Extension Type
Device extension
Registered Extension Number
236
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_vulkan_memory_model
or
Vulkan Version 1.2
and
VK_KHR_shader_maximal_reconvergence
SPIR-V Dependencies
SPV_KHR_quad_control
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_shader_quad_control
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderQuadControlFeaturesKHR
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
New SPIR-V Capabilities
QuadControlKHR
Version History
Revision 1, 2023-11-01 (Tobias Hector)
Initial draft
VK_KHR_shader_relaxed_extended_instruction
Name String
VK_KHR_shader_relaxed_extended_instruction
Extension Type
Device extension
Registered Extension Number
559
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_relaxed_extended_instruction
Contact
Nathan Gauër
Keenuts
Extension Proposal
VK_KHR_shader_relaxed_extended_instruction
Other Extension Metadata
Last Modified Date
2024-01-24
IP Status
No known IP claims.
Contributors
Alan Baker, Google LLC
Nathan Gauër, Google LLC
Description
This extension allows the use of the
SPV_KHR_relaxed_extended_instruction
extension in SPIR-V shader modules.
It adds a new SPIR-V instruction, which allows some usage of forward
references in non-semantic instruction sets.
This extensions interacts with the
SPV_KHR_non_semantic_info
extension,
hence with
VK_KHR_shader_non_semantic_info
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderRelaxedExtendedInstructionFeaturesKHR
New Enum Constants
VK_KHR_SHADER_RELAXED_EXTENDED_INSTRUCTION_EXTENSION_NAME
VK_KHR_SHADER_RELAXED_EXTENDED_INSTRUCTION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_RELAXED_EXTENDED_INSTRUCTION_FEATURES_KHR
Version History
Revision 1, 2024-01-24 (Nathan Gauër)
Initial revision
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
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_subgroup_uniform_control_flow
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderSubgroupUniformControlFlowFeaturesKHR
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
Version History
Revision 1, 2020-08-27 (Alan Baker)
Internal draft version
VK_KHR_shader_untyped_pointers
Name String
VK_KHR_shader_untyped_pointers
Extension Type
Device extension
Registered Extension Number
388
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
SPIR-V Dependencies
SPV_KHR_untyped_pointers
Contact
Alan Baker
alan-baker
Extension Proposal
VK_KHR_shader_untyped_pointers
Last Modified Date
2024-03-26
IP Status
No known IP claims.
Interactions and External Dependencies
Requires the
SPV_KHR_untyped_pointers
SPIR-V extension.
Contributors
Alan Baker, Google
Jan-Harald Fredriksen, Arm
Tom Olson, Arm
Spencer Fricke, LunarG
Shahbaz Youssefi, Google
Tobias Hector, AMD
This extension adds Vulkan support for the
SPV_KHR_untyped_pointers
SPIR-V
extension.
It provides an alternative to strongly-typed pointers.
Untyped pointers allow shader authors to reinterpret data accessed through
memory and atomic instructions versus the data type declared in the variable
without extra conversion instructions.
Untyped pointers also provide an efficient translation from templated
load/store operations in high-level languages and simplify shaders that
support operations, but not storage, on smaller data types (e.g. 16-bit
floating-point types).
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderUntypedPointersFeaturesKHR
New Enum Constants
VK_KHR_SHADER_UNTYPED_POINTERS_EXTENSION_NAME
VK_KHR_SHADER_UNTYPED_POINTERS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_UNTYPED_POINTERS_FEATURES_KHR
Version History
Revision 1, 2024-03-26 (Alan Baker)
Internal draft version
VK_KHR_shared_presentable_image
Name String
VK_KHR_shared_presentable_image
Extension Type
Device extension
Registered Extension Number
112
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_get_surface_capabilities2
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Commands
vkGetSwapchainStatusKHR
New Structures
Extending
VkSurfaceCapabilities2KHR
VkSharedPresentSurfaceCapabilitiesKHR
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 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.
Version History
Revision 1, 2017-03-20 (Alon Or-bach)
Internal revisions
VK_KHR_surface
Name String
VK_KHR_surface
Extension Type
Instance extension
Registered Extension Number
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 Object Types
VkSurfaceKHR
New Commands
vkDestroySurfaceKHR
vkGetPhysicalDeviceSurfaceCapabilitiesKHR
vkGetPhysicalDeviceSurfaceFormatsKHR
vkGetPhysicalDeviceSurfacePresentModesKHR
vkGetPhysicalDeviceSurfaceSupportKHR
New Structures
VkSurfaceCapabilitiesKHR
VkSurfaceFormatKHR
New Enums
VkColorSpaceKHR
VkCompositeAlphaFlagBitsKHR
VkPresentModeKHR
VkSurfaceTransformFlagBitsKHR
New Bitmasks
VkCompositeAlphaFlagsKHR
VkSurfaceTransformFlagsKHR
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
The example code for the
VK_KHR_surface
and
VK_KHR_swapchain
extensions was removed from the appendix after revision 1.0.29.
This WSI example code was ported to the cube demo that is shipped with the
official Khronos SDK, and is being kept up-to-date in that location (see:
).
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 structure specific to a given
extension or parameters, via extensible versions of the queries:
vkGetPhysicalDeviceSurfacePresentModes2EXT
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_maintenance1
Name String
VK_KHR_surface_maintenance1
Extension Type
Instance extension
Registered Extension Number
487
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
and
VK_KHR_get_surface_capabilities2
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_surface_maintenance1
Other Extension Metadata
Last Modified Date
2025-03-31
Contributors
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Lionel Landwerlin, Intel
Shahbaz Youssefi, Google
Chris Forbes, Google
Ian Elliott, Google
Hans-Kristian Arntzen, Valve
Daniel Stone, Collabora
Description
This extension is based off the
VK_EXT_surface_maintenance1
extension.
VK_KHR_surface_maintenance1
adds a collection of window system
integration features that were intentionally left out or overlooked in the
original
VK_KHR_surface
extension.
The new features are as follows:
Allow querying number of min/max images from a surface for a particular
presentation mode.
Allow querying a surface’s scaled presentation capabilities.
Allow querying a surface for the set of presentation modes which can be
easily switched between without requiring swapchain recreation.
New Structures
Extending
VkPhysicalDeviceSurfaceInfo2KHR
VkSurfacePresentModeKHR
Extending
VkSurfaceCapabilities2KHR
VkSurfacePresentModeCompatibilityKHR
VkSurfacePresentScalingCapabilitiesKHR
New Enums
VkPresentGravityFlagBitsKHR
VkPresentScalingFlagBitsKHR
New Bitmasks
VkPresentGravityFlagsKHR
VkPresentScalingFlagsKHR
New Enum Constants
VK_KHR_SURFACE_MAINTENANCE_1_EXTENSION_NAME
VK_KHR_SURFACE_MAINTENANCE_1_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_COMPATIBILITY_KHR
VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_KHR
VK_STRUCTURE_TYPE_SURFACE_PRESENT_SCALING_CAPABILITIES_KHR
Version History
Revision 1, 2025-03-31 (Shahbaz Youssefi)
Based on VK_EXT_surface_maintenance1
VK_KHR_surface_protected_capabilities
Name String
VK_KHR_surface_protected_capabilities
Extension Type
Instance extension
Registered Extension Number
240
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_get_surface_capabilities2
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 Structures
Extending
VkSurfaceCapabilities2KHR
VkSurfaceProtectedCapabilitiesKHR
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
Version History
Revision 1, 2018-12-18 (Sandeep Shinde, Daniel Koch)
Internal revisions.
VK_KHR_swapchain
Name String
VK_KHR_swapchain
Extension Type
Device extension
Registered Extension Number
Revision
70
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Object Types
VkSwapchainKHR
New Commands
vkAcquireNextImageKHR
vkCreateSwapchainKHR
vkDestroySwapchainKHR
vkGetSwapchainImagesKHR
vkQueuePresentKHR
If
Vulkan Version 1.1
is supported:
vkAcquireNextImage2KHR
vkGetDeviceGroupPresentCapabilitiesKHR
vkGetDeviceGroupSurfacePresentModesKHR
vkGetPhysicalDevicePresentRectanglesKHR
New Structures
VkPresentInfoKHR
VkSwapchainCreateInfoKHR
If
Vulkan Version 1.1
is supported:
VkAcquireNextImageInfoKHR
VkDeviceGroupPresentCapabilitiesKHR
Extending
VkBindImageMemoryInfo
VkBindImageMemorySwapchainInfoKHR
Extending
VkImageCreateInfo
VkImageSwapchainCreateInfoKHR
Extending
VkPresentInfoKHR
VkDeviceGroupPresentInfoKHR
Extending
VkSwapchainCreateInfoKHR
VkDeviceGroupSwapchainCreateInfoKHR
New Enums
VkSwapchainCreateFlagBitsKHR
If
Vulkan Version 1.1
is supported:
VkDeviceGroupPresentModeFlagBitsKHR
New Bitmasks
VkSwapchainCreateFlagsKHR
If
Vulkan Version 1.1
is supported:
VkDeviceGroupPresentModeFlagsKHR
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
Vulkan 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 application 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.
VkSurfaceKHR
owns the binding of the native window to the Vulkan
driver.
26) How can the application 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 application 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
The example code for the
VK_KHR_surface
and
VK_KHR_swapchain
extensions was removed from the appendix after revision 1.0.29.
This WSI example code was ported to the cube demo that is shipped with the
official Khronos SDK, and is being kept up-to-date in that location (see:
).
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, 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_maintenance1
Name String
VK_KHR_swapchain_maintenance1
Extension Type
Device extension
Registered Extension Number
488
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_surface_maintenance1
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_swapchain_maintenance1
Other Extension Metadata
Last Modified Date
2025-03-31
Contributors
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Shahbaz Youssefi, Google
Chris Forbes, Google
Ian Elliott, Google
Yiwei Zhang, Google
Charlie Lao, Google
Lina Versace, Google
Ralph Potter, Samsung
Igor Nazarov, Samsung
Hyunchang Kim, Samsung
Suenghwan Lee, Samsung
Munseong Kang, Samsung
Joonyong Park, Samsung
Hans-Kristian Arntzen, Valve
Lisa Wu, Arm
Daniel Stone, Collabora
Pan Gao, Huawei
Description
This extension is based off the
VK_EXT_swapchain_maintenance1
extension.
VK_KHR_swapchain_maintenance1
adds a collection of window system
integration features that were intentionally left out or overlooked in the
original
VK_KHR_swapchain
extension.
The new features are as follows:
Specify a fence that will be signaled when the resources associated with
a present operation
can
be safely destroyed.
Allow changing the present mode a swapchain is using at per-present
granularity.
Allow applications to define the behavior when presenting a swapchain
image to a surface with different dimensions than the image.
Using this feature
may
allow implementations to avoid returning
VK_ERROR_OUT_OF_DATE_KHR
in this situation.
Allow applications to defer swapchain memory allocation for improved
startup time and memory footprint.
Allow applications to release previously acquired images without
presenting them.
New Commands
vkReleaseSwapchainImagesKHR
New Structures
VkReleaseSwapchainImagesInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSwapchainMaintenance1FeaturesKHR
Extending
VkPresentInfoKHR
VkSwapchainPresentFenceInfoKHR
VkSwapchainPresentModeInfoKHR
Extending
VkSwapchainCreateInfoKHR
VkSwapchainPresentModesCreateInfoKHR
VkSwapchainPresentScalingCreateInfoKHR
New Enum Constants
VK_KHR_SWAPCHAIN_MAINTENANCE_1_EXTENSION_NAME
VK_KHR_SWAPCHAIN_MAINTENANCE_1_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SWAPCHAIN_MAINTENANCE_1_FEATURES_KHR
VK_STRUCTURE_TYPE_RELEASE_SWAPCHAIN_IMAGES_INFO_KHR
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_KHR
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODES_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODE_INFO_KHR
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_SCALING_CREATE_INFO_KHR
Extending
VkSwapchainCreateFlagBitsKHR
VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_KHR
Version History
Revision 1, 2025-03-31 (Shahbaz Youssefi)
Based on VK_EXT_swapchain_maintenance1
VK_KHR_swapchain_mutable_format
Name String
VK_KHR_swapchain_mutable_format
Extension Type
Device extension
Registered Extension Number
201
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_maintenance2
or
Vulkan Version 1.1
and
VK_KHR_image_format_list
or
Vulkan Version 1.2
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
Version History
Revision 1, 2018-03-28 (Daniel Rakos)
Internal revisions.
VK_KHR_unified_image_layouts
Name String
VK_KHR_unified_image_layouts
Extension Type
Device extension
Registered Extension Number
528
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_EXT_attachment_feedback_loop_layout
Interacts with VK_KHR_dynamic_rendering
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_unified_image_layouts
Other Extension Metadata
Last Modified Date
2024-10-15
Interactions and External Dependencies
This extension interacts with
VK_EXT_attachment_feedback_loop_layout
This extension interacts with
VK_KHR_video_decode_queue
This extension interacts with
VK_KHR_video_encode_queue
This extension interacts with
VK_KHR_video_encode_quantization_map
Contributors
Ahmed Abdelkhalek, AMD
Tobias Hector, AMD
Jan-Harald Fredriksen, ARM
Ting Wei, ARM
Faith Ekstrand, Collabora
Lina Versace, Google
Shahbaz Youssefi, Google
James Fitzpatrick, Imagination
Daniel Story, Nintendo
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Piers Daniell, NVIDIA
Tony Zlatinski, NVIDIA
Matthew Netsch, Qualcomm
Patrick Boyle, Qualcomm
Daniel Rakos, RasterGrid
Ralph Potter, Samsung
Hans-Kristian Arntzen, VALVE
Samuel Pitoiset, VALVE
Description
This extension significantly simplifies synchronization in Vulkan by
removing the need for image layout transitions in most cases.
In particular, it guarantees that using the
VK_IMAGE_LAYOUT_GENERAL
layout
everywhere possible is just as efficient as using the other layouts.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceUnifiedImageLayoutsFeaturesKHR
If
VK_EXT_attachment_feedback_loop_layout
and
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkRenderingAttachmentInfo
VkAttachmentFeedbackLoopInfoEXT
New Enum Constants
VK_KHR_UNIFIED_IMAGE_LAYOUTS_EXTENSION_NAME
VK_KHR_UNIFIED_IMAGE_LAYOUTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFIED_IMAGE_LAYOUTS_FEATURES_KHR
If
VK_EXT_attachment_feedback_loop_layout
and
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ATTACHMENT_FEEDBACK_LOOP_INFO_EXT
Version History
Revision 1, 2024-10-15 (Shahbaz Youssefi)
Initial revision
VK_KHR_video_decode_av1
Name String
VK_KHR_video_decode_av1
Extension Type
Device extension
Registered Extension Number
513
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_decode_queue
Contact
Daniel Rakos
aqnuep
Extension Proposal
VK_KHR_video_decode_av1
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
VkVideoDecodeAV1CapabilitiesKHR
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeAV1PictureInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoDecodeAV1ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoDecodeAV1DpbSlotInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoDecodeAV1SessionParametersCreateInfoKHR
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
Version History
Revision 1, 2024-01-02 (Daniel Rakos)
Internal revisions
VK_KHR_video_decode_h264
Name String
VK_KHR_video_decode_h264
Extension Type
Device extension
Registered Extension Number
41
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_decode_queue
Contact
[email protected]
Extension Proposal
VK_KHR_video_decode_h264
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.
This extension was promoted to
KHR
from the provisional extension
VK_EXT_video_decode_h264
New Structures
Extending
VkVideoCapabilitiesKHR
VkVideoDecodeH264CapabilitiesKHR
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeH264PictureInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoDecodeH264ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoDecodeH264DpbSlotInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoDecodeH264SessionParametersCreateInfoKHR
Extending
VkVideoSessionParametersUpdateInfoKHR
VkVideoDecodeH264SessionParametersAddInfoKHR
New Enums
VkVideoDecodeH264PictureLayoutFlagBitsKHR
New Bitmasks
VkVideoDecodeH264PictureLayoutFlagsKHR
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
to
VkVideoDecodeH264PictureLayoutFlagsEXT
VkVideoDecodeH264FieldLayoutFlagBitsEXT
to
VkVideoDecodeH264PictureLayoutFlagBitsEXT
(along with the names of
enumerants it defines), and
VkVideoDecodeH264ProfileEXT.fieldLayout
to
VkVideoDecodeH264ProfileEXT.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
to
VkVideoDecodeH264ProfileInfoEXT
Rename
VkVideoDecodeH264MvcEXT
to
VkVideoDecodeH264MvcInfoEXT
Revision 7, 2022-09-18 (Daniel Rakos)
Change type of
VkVideoDecodeH264ProfileInfoEXT::pictureLayout
to
VkVideoDecodeH264PictureLayoutFlagBitsEXT
Remove MVC support and related
VkVideoDecodeH264MvcInfoEXT
structure
Rename
spsStdCount
pSpsStd
ppsStdCount
, and
pPpsStd
to
stdSPSCount
pStdSPSs
stdPPSCount
, and
pStdPPSs
, respectively,
in
VkVideoDecodeH264SessionParametersAddInfoEXT
Rename
maxSpsStdCount
and
maxPpsStdCount
to
maxStdSPSCount
and
maxStdPPSCount
, respectively, in
VkVideoDecodeH264SessionParametersCreateInfoEXT
Rename
slicesCount
and
pSlicesDataOffsets
to
sliceCount
and
pSliceOffsets
, respectively, in
VkVideoDecodeH264PictureInfoEXT
Revision 8, 2022-09-29 (Daniel Rakos)
Change extension from
EXT
to
KHR
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_decode_queue
Contact
[email protected]
Extension Proposal
VK_KHR_video_decode_h265
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.
This extension was promoted to
KHR
from the provisional extension
VK_EXT_video_decode_h265
New Structures
Extending
VkVideoCapabilitiesKHR
VkVideoDecodeH265CapabilitiesKHR
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeH265PictureInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoDecodeH265ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoDecodeH265DpbSlotInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoDecodeH265SessionParametersCreateInfoKHR
Extending
VkVideoSessionParametersUpdateInfoKHR
VkVideoDecodeH265SessionParametersAddInfoKHR
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
to
VkVideoDecodeH265ProfileInfoEXT
Revision 5, 2022-09-18 (Daniel Rakos)
Rename
vpsStdCount
pVpsStd
spsStdCount
pSpsStd
ppsStdCount
, and
pPpsStd
to
stdVPSCount
pStdVPSs
stdSPSCount
pStdSPSs
stdPPSCount
, and
pStdPPSs
, respectively,
in
VkVideoDecodeH265SessionParametersAddInfoEXT
Rename
maxVpsStdCount
maxSpsStdCount
, and
maxPpsStdCount
to
maxStdVPSCount
maxStdSPSCount
and
maxStdPPSCount
, respectively,
in
VkVideoDecodeH265SessionParametersCreateInfoEXT
Rename
slicesCount
and
pSlicesDataOffsets
to
sliceCount
and
pSliceOffsets
, respectively, in
VkVideoDecodeH265PictureInfoEXT
Revision 6, 2022-11-14 (Daniel Rakos)
Rename
slice
to
sliceSegment
in the APIs for better clarity
Revision 7, 2022-11-14 (Daniel Rakos)
Change extension from
EXT
to
KHR
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_queue
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
Contact
[email protected]
Extension Proposal
VK_KHR_video_decode_queue
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 Commands
vkCmdDecodeVideoKHR
New Structures
VkVideoDecodeInfoKHR
Extending
VkVideoCapabilitiesKHR
VkVideoDecodeCapabilitiesKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoDecodeUsageInfoKHR
New Enums
VkVideoDecodeCapabilityFlagBitsKHR
VkVideoDecodeUsageFlagBitsKHR
New Bitmasks
VkVideoDecodeCapabilityFlagsKHR
VkVideoDecodeFlagsKHR
VkVideoDecodeUsageFlagsKHR
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
Vulkan 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
to
vk.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_decode_vp9
Name String
VK_KHR_video_decode_vp9
Extension Type
Device extension
Registered Extension Number
515
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_decode_queue
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_decode_vp9
Other Extension Metadata
Last Modified Date
2025-04-11
IP Status
No known IP claims.
Contributors
Ahmed Abdelkhalek, AMD
Benjamin Cheng, AMD
Lynne Iribarren, Independent
David Airlie, Red Hat, Inc.
Ping Liu, Intel
Srinath Kumarapuram, NVIDIA
Vassili Nikolaev, NVIDIA
Tony Zlatinski, NVIDIA
Konda Raju, NVIDIA
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 VP9 video compression standard.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoDecodeVP9FeaturesKHR
Extending
VkVideoCapabilitiesKHR
VkVideoDecodeVP9CapabilitiesKHR
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeVP9PictureInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoDecodeVP9ProfileInfoKHR
New Enum Constants
VK_KHR_VIDEO_DECODE_VP9_EXTENSION_NAME
VK_KHR_VIDEO_DECODE_VP9_SPEC_VERSION
VK_MAX_VIDEO_VP9_REFERENCES_PER_FRAME_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_DECODE_VP9_FEATURES_KHR
VK_STRUCTURE_TYPE_VIDEO_DECODE_VP9_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_DECODE_VP9_PICTURE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_DECODE_VP9_PROFILE_INFO_KHR
Extending
VkVideoCodecOperationFlagBitsKHR
VK_VIDEO_CODEC_OPERATION_DECODE_VP9_BIT_KHR
Version History
Revision 1, 2025-04-11 (Daniel Rakos)
Internal revisions
VK_KHR_video_encode_av1
Name String
VK_KHR_video_encode_av1
Extension Type
Device extension
Registered Extension Number
514
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_encode_queue
Contact
Daniel Rakos
aqnuep
Extension Proposal
VK_KHR_video_encode_av1
Other Extension Metadata
Last Modified Date
2024-09-23
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
Konda Raju, NVIDIA
Charlie Turner, Igalia
Daniel Almeida, Collabora
Nicolas Dufresne, Collabora
Daniel Rakos, RasterGrid
Description
This extension builds upon the
VK_KHR_video_encode_queue
extension
by adding support for encoding elementary video stream sequences compliant
with the AV1 video compression standard.
New Structures
VkVideoEncodeAV1FrameSizeKHR
VkVideoEncodeAV1QIndexKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoEncodeAV1FeaturesKHR
Extending
VkVideoBeginCodingInfoKHR
VkVideoEncodeAV1GopRemainingFrameInfoKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeAV1CapabilitiesKHR
Extending
VkVideoCodingControlInfoKHR
VkVideoBeginCodingInfoKHR
VkVideoEncodeAV1RateControlInfoKHR
Extending
VkVideoEncodeInfoKHR
VkVideoEncodeAV1PictureInfoKHR
Extending
VkVideoEncodeQualityLevelPropertiesKHR
VkVideoEncodeAV1QualityLevelPropertiesKHR
Extending
VkVideoEncodeRateControlLayerInfoKHR
VkVideoEncodeAV1RateControlLayerInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoEncodeAV1ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoEncodeAV1DpbSlotInfoKHR
Extending
VkVideoSessionCreateInfoKHR
VkVideoEncodeAV1SessionCreateInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoEncodeAV1SessionParametersCreateInfoKHR
New Enums
VkVideoEncodeAV1CapabilityFlagBitsKHR
VkVideoEncodeAV1PredictionModeKHR
VkVideoEncodeAV1RateControlFlagBitsKHR
VkVideoEncodeAV1RateControlGroupKHR
VkVideoEncodeAV1StdFlagBitsKHR
VkVideoEncodeAV1SuperblockSizeFlagBitsKHR
New Bitmasks
VkVideoEncodeAV1CapabilityFlagsKHR
VkVideoEncodeAV1RateControlFlagsKHR
VkVideoEncodeAV1StdFlagsKHR
VkVideoEncodeAV1SuperblockSizeFlagsKHR
New Enum Constants
VK_KHR_VIDEO_ENCODE_AV1_EXTENSION_NAME
VK_KHR_VIDEO_ENCODE_AV1_SPEC_VERSION
VK_MAX_VIDEO_AV1_REFERENCES_PER_FRAME_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_AV1_FEATURES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_DPB_SLOT_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_GOP_REMAINING_FRAME_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_PICTURE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_PROFILE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_QUALITY_LEVEL_PROPERTIES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_RATE_CONTROL_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_RATE_CONTROL_LAYER_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_SESSION_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_SESSION_PARAMETERS_CREATE_INFO_KHR
Extending
VkVideoCodecOperationFlagBitsKHR
VK_VIDEO_CODEC_OPERATION_ENCODE_AV1_BIT_KHR
Version History
Revision 1, 2024-09-23 (Daniel Rakos)
Internal revisions
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
VK_KHR_video_encode_queue
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_encode_h264
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, Lynx
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.
This extension was promoted to
KHR
from the provisional extension
VK_EXT_video_encode_h264
New Structures
VkVideoEncodeH264FrameSizeKHR
VkVideoEncodeH264NaluSliceInfoKHR
VkVideoEncodeH264QpKHR
Extending
VkVideoBeginCodingInfoKHR
VkVideoEncodeH264GopRemainingFrameInfoKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeH264CapabilitiesKHR
Extending
VkVideoCodingControlInfoKHR
VkVideoBeginCodingInfoKHR
VkVideoEncodeH264RateControlInfoKHR
Extending
VkVideoEncodeInfoKHR
VkVideoEncodeH264PictureInfoKHR
Extending
VkVideoEncodeQualityLevelPropertiesKHR
VkVideoEncodeH264QualityLevelPropertiesKHR
Extending
VkVideoEncodeRateControlLayerInfoKHR
VkVideoEncodeH264RateControlLayerInfoKHR
Extending
VkVideoEncodeSessionParametersFeedbackInfoKHR
VkVideoEncodeH264SessionParametersFeedbackInfoKHR
Extending
VkVideoEncodeSessionParametersGetInfoKHR
VkVideoEncodeH264SessionParametersGetInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoEncodeH264ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoEncodeH264DpbSlotInfoKHR
Extending
VkVideoSessionCreateInfoKHR
VkVideoEncodeH264SessionCreateInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoEncodeH264SessionParametersCreateInfoKHR
Extending
VkVideoSessionParametersUpdateInfoKHR
VkVideoEncodeH264SessionParametersAddInfoKHR
New Enums
VkVideoEncodeH264CapabilityFlagBitsKHR
VkVideoEncodeH264RateControlFlagBitsKHR
VkVideoEncodeH264StdFlagBitsKHR
New Bitmasks
VkVideoEncodeH264CapabilityFlagsKHR
VkVideoEncodeH264RateControlFlagsKHR
VkVideoEncodeH264StdFlagsKHR
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
to
VkVideoEncodeH264CapabilityFlagsEXT
and
VkVideoEncodeH264CapabilitiesFlagsEXT
to
VkVideoEncodeH264CapabilityFlagsEXT
, 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
with
VkVideoEncodeH264RateControlStructureEXT
enum
Rename
VkVideoEncodeH264ProfileEXT
to
VkVideoEncodeH264ProfileInfoEXT
Rename
VkVideoEncodeH264ReferenceListsEXT
to
VkVideoEncodeH264ReferenceListsInfoEXT
Rename
VkVideoEncodeH264EmitPictureParametersEXT
to
VkVideoEncodeH264EmitPictureParametersInfoEXT
Rename
VkVideoEncodeH264NaluSliceEXT
to
VkVideoEncodeH264NaluSliceInfoEXT
Revision 9, 2022-09-18 (Daniel Rakos)
Rename
spsStdCount
pSpsStd
ppsStdCount
, and
pPpsStd
to
stdSPSCount
pStdSPSs
stdPPSCount
, and
pStdPPSs
, respectively,
in
VkVideoEncodeH264SessionParametersAddInfoEXT
Rename
maxSpsStdCount
and
maxPpsStdCount
to
maxStdSPSCount
and
maxStdPPSCount
, respectively, in
VkVideoEncodeH264SessionParametersCreateInfoEXT
Revision 10, 2023-03-06 (Daniel Rakos)
Removed
VkVideoEncodeH264EmitPictureParametersInfoEXT
Changed member types in
VkVideoEncodeH264CapabilitiesEXT
and
VkVideoEncodeH264ReferenceListsInfoEXT
from
uint8_t
to
uint32_t
Changed the type of
VkVideoEncodeH264RateControlInfoEXT::temporalLayerCount
and
VkVideoEncodeH264RateControlLayerInfoEXT::temporalLayerId
from
uint8_t
to
uint32_t
Removed
VkVideoEncodeH264InputModeFlagsEXT
and
VkVideoEncodeH264OutputModeFlagsEXT
as we only support
frame-in-frame-out mode for now
Rename
pCurrentPictureInfo
in
VkVideoEncodeH264VclFrameInfoEXT
to
pStdPictureInfo
Rename
pSliceHeaderStd
in
VkVideoEncodeH264NaluSliceInfoEXT
to
pStdSliceHeader
Rename
pReferenceFinalLists
in
VkVideoEncodeH264VclFrameInfoEXT
and
VkVideoEncodeH264NaluSliceInfoEXT
to
pStdReferenceFinalLists
Removed the
slotIndex
member of
VkVideoEncodeH264DpbSlotInfoEXT
and
changed it to be chained to
VkVideoReferenceSlotInfoKHR
Replaced
VkVideoEncodeH264ReferenceListsInfoEXT
with the new Video
Std header structure
StdVideoEncodeH264ReferenceLists
that also
includes data previously part of the now removed
StdVideoEncodeH264RefMemMgmtCtrlOperations
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
to
VkVideoEncodeH264PictureInfoEXT
Added
VkVideoEncodeH264PictureInfoEXT::generatePrefixNalu
and
VK_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 the
VkVideoEncodeH264SessionParametersFeedbackInfoEXT
structure to retrieve H.264 parameter set override information when
using the new
vkGetEncodedVideoSessionParametersKHR
command
Added
VkVideoEncodeH264NaluSliceInfoEXT::constantQp
to specify
per-slice constant QP when rate control mode is
VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR
Added
VkVideoEncodeH264QualityLevelPropertiesEXT
for retrieving H.264
specific quality level recommendations
Replaced
VkVideoEncodeH264RateControlStructureEXT
enum with the flags
type
VkVideoEncodeH264RateControlFlagsEXT
and bits defined in
VkVideoEncodeH264RateControlFlagBitsEXT
and added HRD compliance flag
Removed
useInitialRcQp
and
initialRcQp
members of
VkVideoEncodeH264RateControlLayerInfoEXT
Added
prefersGopRemainingFrames
and
requiresGopRemainingFrames
, and
the new
VkVideoEncodeH264GopRemainingFrameInfoEXT
structure to allow
specifying remaining frames of each type in the rate control GOP
Added
maxTemporalLayers
maxQp
, and
minQp
capabilities
Added
maxLevelIdc
capability and new
VkVideoEncodeH264SessionCreateInfoEXT
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 new
VkVideoEncodeH264StdFlagsEXT
which is now included as a separate
stdSyntaxFlags
member in
VkVideoEncodeH264CapabilitiesEXT
Removed codec syntax override values from
VkVideoEncodeH264CapabilitiesEXT
Removed
VkVideoEncodeH264NaluSliceInfoEXT::mbCount
and
VK_VIDEO_ENCODE_H264_CAPABILITY_SLICE_MB_COUNT_BIT_EXT
Replaced
VK_VIDEO_ENCODE_H264_CAPABILITY_MULTIPLE_SLICES_PER_FRAME_BIT_EXT
with the new
maxSliceCount
capability
Removed capability flag
VK_VIDEO_ENCODE_H264_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
and removed
pStdReferenceFinalLists
members from the
VkVideoEncodeH264PictureInfoEXT
and
VkVideoEncodeH264NaluSliceInfoEXT
structures as reference lists info
is now included in
pStdPictureInfo
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
and
VK_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
to
KHR
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
VK_KHR_video_encode_queue
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_encode_h265
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, Lynx
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.
This extension was promoted to
KHR
from the provisional extension
VK_EXT_video_encode_h265
New Structures
VkVideoEncodeH265FrameSizeKHR
VkVideoEncodeH265NaluSliceSegmentInfoKHR
VkVideoEncodeH265QpKHR
Extending
VkVideoBeginCodingInfoKHR
VkVideoEncodeH265GopRemainingFrameInfoKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeH265CapabilitiesKHR
Extending
VkVideoCodingControlInfoKHR
VkVideoBeginCodingInfoKHR
VkVideoEncodeH265RateControlInfoKHR
Extending
VkVideoEncodeInfoKHR
VkVideoEncodeH265PictureInfoKHR
Extending
VkVideoEncodeQualityLevelPropertiesKHR
VkVideoEncodeH265QualityLevelPropertiesKHR
Extending
VkVideoEncodeRateControlLayerInfoKHR
VkVideoEncodeH265RateControlLayerInfoKHR
Extending
VkVideoEncodeSessionParametersFeedbackInfoKHR
VkVideoEncodeH265SessionParametersFeedbackInfoKHR
Extending
VkVideoEncodeSessionParametersGetInfoKHR
VkVideoEncodeH265SessionParametersGetInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoEncodeH265ProfileInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoEncodeH265DpbSlotInfoKHR
Extending
VkVideoSessionCreateInfoKHR
VkVideoEncodeH265SessionCreateInfoKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoEncodeH265SessionParametersCreateInfoKHR
Extending
VkVideoSessionParametersUpdateInfoKHR
VkVideoEncodeH265SessionParametersAddInfoKHR
New Enums
VkVideoEncodeH265CapabilityFlagBitsKHR
VkVideoEncodeH265CtbSizeFlagBitsKHR
VkVideoEncodeH265RateControlFlagBitsKHR
VkVideoEncodeH265StdFlagBitsKHR
VkVideoEncodeH265TransformBlockSizeFlagBitsKHR
New Bitmasks
VkVideoEncodeH265CapabilityFlagsKHR
VkVideoEncodeH265CtbSizeFlagsKHR
VkVideoEncodeH265RateControlFlagsKHR
VkVideoEncodeH265StdFlagsKHR
VkVideoEncodeH265TransformBlockSizeFlagsKHR
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
with
VkVideoEncodeH265RateControlStructureEXT
enum
Rename
VkVideoEncodeH265ProfileEXT
to
VkVideoEncodeH265ProfileInfoEXT
Rename
VkVideoEncodeH265ReferenceListsEXT
to
VkVideoEncodeH265ReferenceListsInfoEXT
Rename
VkVideoEncodeH265EmitPictureParametersEXT
to
VkVideoEncodeH265EmitPictureParametersInfoEXT
Rename
VkVideoEncodeH265NaluSliceSegmentEXT
to
VkVideoEncodeH265NaluSliceSegmentInfoEXT
Revision 9, 2022-09-18 (Daniel Rakos)
Rename
vpsStdCount
pVpsStd
spsStdCount
pSpsStd
ppsStdCount
, and
pPpsStd
to
stdVPSCount
pStdVPSs
stdSPSCount
pStdSPSs
stdPPSCount
, and
pStdPPSs
, respectively,
in
VkVideoEncodeH265SessionParametersAddInfoEXT
Rename
maxVpsStdCount
maxSpsStdCount
, and
maxPpsStdCount
to
maxStdVPSCount
maxStdSPSCount
and
maxStdPPSCount
, respectively,
in
VkVideoEncodeH265SessionParametersCreateInfoEXT
Revision 10, 2023-03-06 (Daniel Rakos)
Removed
VkVideoEncodeH265EmitPictureParametersInfoEXT
Changed member types in
VkVideoEncodeH265CapabilitiesEXT
and
VkVideoEncodeH265ReferenceListsInfoEXT
from
uint8_t
to
uint32_t
Changed the type of
VkVideoEncodeH265RateControlInfoEXT::subLayerCount
and
VkVideoEncodeH265RateControlLayerInfoEXT::temporalId
from
uint8_t
to
uint32_t
Removed
VkVideoEncodeH265InputModeFlagsEXT
and
VkVideoEncodeH265OutputModeFlagsEXT
as we only support
frame-in-frame-out mode for now
Rename
pCurrentPictureInfo
in
VkVideoEncodeH265VclFrameInfoEXT
to
pStdPictureInfo
Rename
pSliceSegmentHeaderStd
in
VkVideoEncodeH265NaluSliceSegmentInfoEXT
to
pStdSliceSegmentHeader
Rename
pReferenceFinalLists
in
VkVideoEncodeH265VclFrameInfoEXT
and
VkVideoEncodeH265NaluSliceSegmentInfoEXT
to
pStdReferenceFinalLists
Removed the
slotIndex
member of
VkVideoEncodeH265DpbSlotInfoEXT
and
changed it to be chained to
VkVideoReferenceSlotInfoKHR
Replaced
VkVideoEncodeH265ReferenceListsInfoEXT
with the new Video
Std header structure
StdVideoEncodeH265ReferenceLists
Added new capability flag
VK_VIDEO_ENCODE_H265_CAPABILITY_DIFFERENT_REFERENCE_FINAL_LISTS_BIT_EXT
Revision 11, 2023-05-26 (Daniel Rakos)
Renamed
VkVideoEncodeH265VclFrameInfoEXT
to
VkVideoEncodeH265PictureInfoEXT
Removed
VkVideoEncodeH265RateControlLayerInfoEXT::temporalId
Added
expectDyadicTemporalSubLayerPattern
capability
Added the
VkVideoEncodeH265SessionParametersGetInfoEXT
structure to
identify the H.265 parameter sets to retrieve encoded parameter data
for, and the
VkVideoEncodeH265SessionParametersFeedbackInfoEXT
structure to retrieve H.265 parameter set override information when
using the new
vkGetEncodedVideoSessionParametersKHR
command
Added
VkVideoEncodeH265NaluSliceSegmentInfoEXT::constantQp
to specify
per-slice segment constant QP when rate control mode is
VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR
Added
VkVideoEncodeH265QualityLevelPropertiesEXT
for retrieving H.265
specific quality level recommendations
Replaced
VkVideoEncodeH265RateControlStructureEXT
enum with the flags
type
VkVideoEncodeH265RateControlFlagsEXT
and bits defined in
VkVideoEncodeH265RateControlFlagBitsEXT
and added HRD compliance flag
Removed
useInitialRcQp
and
initialRcQp
members of
VkVideoEncodeH265RateControlLayerInfoEXT
Added
prefersGopRemainingFrames
and
requiresGopRemainingFrames
, and
the new
VkVideoEncodeH265GopRemainingFrameInfoEXT
structure to allow
specifying remaining frames of each type in the rate control GOP
Renamed
maxSubLayersCount
capability to
maxSubLayerCount
Added
maxQp
, and
minQp
capabilities
Added
maxLevelIdc
capability and new
VkVideoEncodeH265SessionCreateInfoEXT
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 new
VkVideoEncodeH265StdFlagsEXT
which is now included as a separate
stdSyntaxFlags
member in
VkVideoEncodeH265CapabilitiesEXT
Added
std
prefix to codec syntax capabilities in
VkVideoEncodeH265CapabilitiesEXT
Removed
VkVideoEncodeH265NaluSliceSegmentInfoEXT::ctbCount
and
VK_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 new
maxSliceSegmentCount
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 removed
pStdReferenceFinalLists
members from the
VkVideoEncodeH265PictureInfoEXT
and
VkVideoEncodeH265NaluSliceSegmentInfoEXT
structures as reference
lists info is now included in
pStdPictureInfo
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
and
VK_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
to
KHR
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_intra_refresh
Name String
VK_KHR_video_encode_intra_refresh
Extension Type
Device extension
Registered Extension Number
553
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_encode_queue
API Interactions
Interacts with VK_KHR_video_encode_av1
Interacts with VK_KHR_video_encode_h264
Interacts with VK_KHR_video_encode_h265
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_encode_intra_refresh
Other Extension Metadata
Last Modified Date
2025-03-28
IP Status
No known IP claims.
Contributors
Ahmed Abdelkhalek, AMD
Benjamin Cheng, AMD
Srinath Kumarapuram, NVIDIA
Tony Zlatinski, NVIDIA
Ping Liu, Intel
Daniel Rakos, RasterGrid
Lynne Iribarren, Independent
Description
This extension builds upon the
VK_KHR_video_encode_queue
extension
by enabling the application to perform intra refresh in video encode
operations.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoEncodeIntraRefreshFeaturesKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeIntraRefreshCapabilitiesKHR
Extending
VkVideoEncodeInfoKHR
VkVideoEncodeIntraRefreshInfoKHR
Extending
VkVideoReferenceSlotInfoKHR
VkVideoReferenceIntraRefreshInfoKHR
Extending
VkVideoSessionCreateInfoKHR
VkVideoEncodeSessionIntraRefreshCreateInfoKHR
New Enums
VkVideoEncodeIntraRefreshModeFlagBitsKHR
New Bitmasks
VkVideoEncodeIntraRefreshModeFlagsKHR
New Enum Constants
VK_KHR_VIDEO_ENCODE_INTRA_REFRESH_EXTENSION_NAME
VK_KHR_VIDEO_ENCODE_INTRA_REFRESH_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_INTRA_REFRESH_FEATURES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_INTRA_REFRESH_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_INTRA_REFRESH_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_INTRA_REFRESH_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_REFERENCE_INTRA_REFRESH_INFO_KHR
Extending
VkVideoEncodeFlagBitsKHR
VK_VIDEO_ENCODE_INTRA_REFRESH_BIT_KHR
If
VK_KHR_video_encode_av1
is supported:
Extending
VkVideoEncodeAV1CapabilityFlagBitsKHR
VK_VIDEO_ENCODE_AV1_CAPABILITY_COMPOUND_PREDICTION_INTRA_REFRESH_BIT_KHR
If
VK_KHR_video_encode_h264
is supported:
Extending
VkVideoEncodeH264CapabilityFlagBitsKHR
VK_VIDEO_ENCODE_H264_CAPABILITY_B_PICTURE_INTRA_REFRESH_BIT_KHR
If
VK_KHR_video_encode_h265
is supported:
Extending
VkVideoEncodeH265CapabilityFlagBitsKHR
VK_VIDEO_ENCODE_H265_CAPABILITY_B_PICTURE_INTRA_REFRESH_BIT_KHR
Version History
Revision 1, 2025-03-28 (Daniel Rakos)
Internal revisions
VK_KHR_video_encode_quantization_map
Name String
VK_KHR_video_encode_quantization_map
Extension Type
Device extension
Registered Extension Number
554
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_encode_queue
and
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
API Interactions
Interacts with VK_KHR_video_encode_av1
Interacts with VK_KHR_video_encode_h264
Interacts with VK_KHR_video_encode_h265
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_encode_quantization_map
Other Extension Metadata
Last Modified Date
2024-09-23
IP Status
No known IP claims.
Contributors
Ahmed Abdelkhalek, AMD
Benjamin Cheng, AMD
Srinath Kumarapuram, NVIDIA
Tony Zlatinski, NVIDIA
Ping Liu, Intel
Daniel Rakos, RasterGrid
Lynne Iribarren, Independent
Description
This extension builds upon the
VK_KHR_video_encode_queue
extension
by enabling fine grained control of codec-specific quantization parameters
in video encode operations.
More specifically, it adds support for quantization maps:
Quantization delta maps to directly control the relative value of
quantization parameter values on a per-block basis for all rate control
modes (including when rate control is disabled).
Emphasis maps to indirectly control the relative quantization parameter
values on a per-block basis when rate control is not disabled and the
rate control mode is not configured to the implementation-defined
default mode.
This extension is to be used in conjunction with other codec specific video
encode extensions that specify the codec specific quantization parameters
these maps control.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoEncodeQuantizationMapFeaturesKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeQuantizationMapCapabilitiesKHR
Extending
VkVideoEncodeInfoKHR
VkVideoEncodeQuantizationMapInfoKHR
Extending
VkVideoFormatPropertiesKHR
VkVideoFormatQuantizationMapPropertiesKHR
Extending
VkVideoSessionParametersCreateInfoKHR
VkVideoEncodeQuantizationMapSessionParametersCreateInfoKHR
If
VK_KHR_video_encode_av1
is supported:
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeAV1QuantizationMapCapabilitiesKHR
Extending
VkVideoFormatPropertiesKHR
VkVideoFormatAV1QuantizationMapPropertiesKHR
If
VK_KHR_video_encode_h264
is supported:
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeH264QuantizationMapCapabilitiesKHR
If
VK_KHR_video_encode_h265
is supported:
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeH265QuantizationMapCapabilitiesKHR
Extending
VkVideoFormatPropertiesKHR
VkVideoFormatH265QuantizationMapPropertiesKHR
New Enums
VkVideoEncodeFlagBitsKHR
VkVideoSessionParametersCreateFlagBitsKHR
New Enum Constants
VK_KHR_VIDEO_ENCODE_QUANTIZATION_MAP_EXTENSION_NAME
VK_KHR_VIDEO_ENCODE_QUANTIZATION_MAP_SPEC_VERSION
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_VIDEO_ENCODE_EMPHASIS_MAP_BIT_KHR
VK_FORMAT_FEATURE_2_VIDEO_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR
Extending
VkImageLayout
VK_IMAGE_LAYOUT_VIDEO_ENCODE_QUANTIZATION_MAP_KHR
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_VIDEO_ENCODE_EMPHASIS_MAP_BIT_KHR
VK_IMAGE_USAGE_VIDEO_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_QUANTIZATION_MAP_FEATURES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_ENCODE_QUANTIZATION_MAP_SESSION_PARAMETERS_CREATE_INFO_KHR
VK_STRUCTURE_TYPE_VIDEO_FORMAT_QUANTIZATION_MAP_PROPERTIES_KHR
Extending
VkVideoEncodeCapabilityFlagBitsKHR
VK_VIDEO_ENCODE_CAPABILITY_EMPHASIS_MAP_BIT_KHR
VK_VIDEO_ENCODE_CAPABILITY_QUANTIZATION_DELTA_MAP_BIT_KHR
Extending
VkVideoEncodeFlagBitsKHR
VK_VIDEO_ENCODE_WITH_EMPHASIS_MAP_BIT_KHR
VK_VIDEO_ENCODE_WITH_QUANTIZATION_DELTA_MAP_BIT_KHR
Extending
VkVideoSessionCreateFlagBitsKHR
VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_EMPHASIS_MAP_BIT_KHR
VK_VIDEO_SESSION_CREATE_ALLOW_ENCODE_QUANTIZATION_DELTA_MAP_BIT_KHR
Extending
VkVideoSessionParametersCreateFlagBitsKHR
VK_VIDEO_SESSION_PARAMETERS_CREATE_QUANTIZATION_MAP_COMPATIBLE_BIT_KHR
If
VK_KHR_video_encode_av1
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_ENCODE_AV1_QUANTIZATION_MAP_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_FORMAT_AV1_QUANTIZATION_MAP_PROPERTIES_KHR
If
VK_KHR_video_encode_h264
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_QUANTIZATION_MAP_CAPABILITIES_KHR
Extending
VkVideoEncodeH264CapabilityFlagBitsKHR
VK_VIDEO_ENCODE_H264_CAPABILITY_MB_QP_DIFF_WRAPAROUND_BIT_KHR
If
VK_KHR_video_encode_h265
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_QUANTIZATION_MAP_CAPABILITIES_KHR
VK_STRUCTURE_TYPE_VIDEO_FORMAT_H265_QUANTIZATION_MAP_PROPERTIES_KHR
Extending
VkVideoEncodeH265CapabilityFlagBitsKHR
VK_VIDEO_ENCODE_H265_CAPABILITY_CU_QP_DIFF_WRAPAROUND_BIT_KHR
Version History
Revision 1, 2024-08-21 (Daniel Rakos)
Internal revisions
Revision 2, 2024-09-23 (Daniel Rakos)
Added interactions with VK_KHR_video_encode_av1
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
VK_KHR_video_queue
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
Contact
Ahmed Abdelkhalek
aabdelkh
Extension Proposal
VK_KHR_video_encode_queue
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, Lynx
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 Commands
vkCmdEncodeVideoKHR
vkGetEncodedVideoSessionParametersKHR
vkGetPhysicalDeviceVideoEncodeQualityLevelPropertiesKHR
New Structures
VkPhysicalDeviceVideoEncodeQualityLevelInfoKHR
VkVideoEncodeInfoKHR
VkVideoEncodeQualityLevelPropertiesKHR
VkVideoEncodeRateControlLayerInfoKHR
VkVideoEncodeSessionParametersFeedbackInfoKHR
VkVideoEncodeSessionParametersGetInfoKHR
Extending
VkQueryPoolCreateInfo
VkQueryPoolVideoEncodeFeedbackCreateInfoKHR
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeCapabilitiesKHR
Extending
VkVideoCodingControlInfoKHR
VkVideoBeginCodingInfoKHR
VkVideoEncodeRateControlInfoKHR
Extending
VkVideoCodingControlInfoKHR
VkVideoSessionParametersCreateInfoKHR
VkVideoEncodeQualityLevelInfoKHR
Extending
VkVideoProfileInfoKHR
VkQueryPoolCreateInfo
VkVideoEncodeUsageInfoKHR
New Enums
VkVideoEncodeCapabilityFlagBitsKHR
VkVideoEncodeContentFlagBitsKHR
VkVideoEncodeFeedbackFlagBitsKHR
VkVideoEncodeRateControlModeFlagBitsKHR
VkVideoEncodeTuningModeKHR
VkVideoEncodeUsageFlagBitsKHR
New Bitmasks
VkVideoEncodeCapabilityFlagsKHR
VkVideoEncodeContentFlagsKHR
VkVideoEncodeFeedbackFlagsKHR
VkVideoEncodeFlagsKHR
VkVideoEncodeRateControlFlagsKHR
VkVideoEncodeRateControlModeFlagsKHR
VkVideoEncodeUsageFlagsKHR
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
Vulkan 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
to
vk.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
and
VkVideoEncodeFlagBitsKHR
as they contain no defined flags for now
Add
VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR
and
VK_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 generic
VK_QUERY_TYPE_VIDEO_ENCODE_FEEDBACK_KHR
queries
that can be extended in the future with more feedback values
Rename
dstBitstreamBuffer
dstBitstreamBufferOffset
, and
dstBitstreamBufferMaxRange
in
VkVideoEncodeInfoKHR
to
dstBuffer
dstBufferOffset
, and
dstBufferRange
, respectively, for consistency
with the naming convention in the video decode extensions
Change the type of
rateControlLayerCount
and
qualityLevelCount
in
VkVideoEncodeCapabilitiesKHR
from
uint8_t
to
uint32_t
and rename
them to
maxRateControlLayers
and
maxQualityLevels
, respectively
Change the type of
averageBitrate
and
maxBitrate
in
VkVideoEncodeRateControlLayerInfoKHR
from
uint32_t
to
uint64_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
from
uint8_t
to
uint32_t
Rename
pLayerConfigs
to
pLayers
in
VkVideoEncodeRateControlInfoKHR
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
and
initialVirtualBufferSizeInMs
from
VkVideoEncodeRateControlLayerInfoKHR
to
VkVideoEncodeRateControlInfoKHR
Added
maxBitrate
capability
Renamed
inputImageDataFillAlignment
capability to
encodeInputPictureGranularity
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 and
VkVideoEncodeQualityLevelInfoKHR
structure to allow controlling video
encode quality level and removed
qualityLevel
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 flag
VK_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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_queue
Contact
Daniel Rakos
aqnuep
Extension Proposal
VK_KHR_video_maintenance1
Other Extension Metadata
Last Modified Date
2023-07-27
IP Status
No known IP claims.
Contributors
Ahmed Abdelkhalek, AMD
Aidan Fabius, Lynx
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoMaintenance1FeaturesKHR
Extending
VkVideoDecodeInfoKHR
VkVideoEncodeInfoKHR
VkVideoInlineQueryInfoKHR
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
Version History
Revision 1, 2023-07-27 (Daniel Rakos)
internal revisions
VK_KHR_video_maintenance2
Name String
VK_KHR_video_maintenance2
Extension Type
Device extension
Registered Extension Number
587
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_video_queue
API Interactions
Interacts with VK_KHR_video_decode_av1
Interacts with VK_KHR_video_decode_h264
Interacts with VK_KHR_video_decode_h265
Interacts with VK_KHR_video_decode_queue
Contact
Daniel Rakos
aqnuep
Extension Proposal
VK_KHR_video_maintenance2
Other Extension Metadata
Last Modified Date
2024-10-14
IP Status
No known IP claims.
Contributors
Ahmed Abdelkhalek, AMD
Benjamin Cheng, AMD
Aidan Fabius, Lynx
Ping Liu, Intel
Lynne Iribarren, Independent
Srinath Kumarapuram, NVIDIA
Tony Zlatinski, NVIDIA
Daniel Rakos, RasterGrid
Description
VK_KHR_video_maintenance2
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 video coding control commands (such as video session reset) to be
issued without the need for a bound video session parameters object for
video decode operations that would otherwise require the use of video
session parameters objects.
Allow applications to specify codec-specific parameter sets inline for
each decode operation instead of having to construct video session
parameters objects.
Require support for
VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR
in all
applicable video encode profiles.
Provide additional guarantees on Video Std parameters that the encoder
implementation will not override.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoMaintenance2FeaturesKHR
If
VK_KHR_video_decode_av1
is supported:
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeAV1InlineSessionParametersInfoKHR
If
VK_KHR_video_decode_h264
is supported:
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeH264InlineSessionParametersInfoKHR
If
VK_KHR_video_decode_h265
is supported:
Extending
VkVideoDecodeInfoKHR
VkVideoDecodeH265InlineSessionParametersInfoKHR
New Enum Constants
VK_KHR_VIDEO_MAINTENANCE_2_EXTENSION_NAME
VK_KHR_VIDEO_MAINTENANCE_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_2_FEATURES_KHR
If
VK_KHR_video_decode_av1
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_INLINE_SESSION_PARAMETERS_INFO_KHR
If
VK_KHR_video_decode_h264
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_INLINE_SESSION_PARAMETERS_INFO_KHR
If
VK_KHR_video_decode_h265
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_INLINE_SESSION_PARAMETERS_INFO_KHR
If
VK_KHR_video_decode_queue
is supported:
Extending
VkVideoSessionCreateFlagBitsKHR
VK_VIDEO_SESSION_CREATE_INLINE_SESSION_PARAMETERS_BIT_KHR
Version History
Revision 1, 2024-10-14 (Daniel Rakos)
internal revisions
VK_KHR_video_queue
Name String
VK_KHR_video_queue
Extension Type
Device extension
Registered Extension Number
24
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
Contact
Tony Zlatinski
tzlatinski
Extension Proposal
VK_KHR_video_queue
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 Object Types
VkVideoSessionKHR
VkVideoSessionParametersKHR
New Commands
vkBindVideoSessionMemoryKHR
vkCmdBeginVideoCodingKHR
vkCmdControlVideoCodingKHR
vkCmdEndVideoCodingKHR
vkCreateVideoSessionKHR
vkCreateVideoSessionParametersKHR
vkDestroyVideoSessionKHR
vkDestroyVideoSessionParametersKHR
vkGetPhysicalDeviceVideoCapabilitiesKHR
vkGetPhysicalDeviceVideoFormatPropertiesKHR
vkGetVideoSessionMemoryRequirementsKHR
vkUpdateVideoSessionParametersKHR
New Structures
VkBindVideoSessionMemoryInfoKHR
VkPhysicalDeviceVideoFormatInfoKHR
VkVideoBeginCodingInfoKHR
VkVideoCapabilitiesKHR
VkVideoCodingControlInfoKHR
VkVideoEndCodingInfoKHR
VkVideoFormatPropertiesKHR
VkVideoPictureResourceInfoKHR
VkVideoReferenceSlotInfoKHR
VkVideoSessionCreateInfoKHR
VkVideoSessionMemoryRequirementsKHR
VkVideoSessionParametersCreateInfoKHR
VkVideoSessionParametersUpdateInfoKHR
Extending
VkPhysicalDeviceImageFormatInfo2
VkPhysicalDeviceVideoFormatInfoKHR
VkImageCreateInfo
VkBufferCreateInfo
VkVideoProfileListInfoKHR
Extending
VkQueryPoolCreateInfo
VkVideoProfileInfoKHR
Extending
VkQueueFamilyProperties2
VkQueueFamilyQueryResultStatusPropertiesKHR
VkQueueFamilyVideoPropertiesKHR
New Enums
VkQueryResultStatusKHR
VkVideoCapabilityFlagBitsKHR
VkVideoChromaSubsamplingFlagBitsKHR
VkVideoCodecOperationFlagBitsKHR
VkVideoCodingControlFlagBitsKHR
VkVideoComponentBitDepthFlagBitsKHR
VkVideoSessionCreateFlagBitsKHR
New Bitmasks
VkVideoBeginCodingFlagsKHR
VkVideoCapabilityFlagsKHR
VkVideoChromaSubsamplingFlagsKHR
VkVideoCodecOperationFlagsKHR
VkVideoCodingControlFlagsKHR
VkVideoComponentBitDepthFlagsKHR
VkVideoEndCodingFlagsKHR
VkVideoSessionCreateFlagsKHR
VkVideoSessionParametersCreateFlagsKHR
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
to
VkVideoCapabilityFlagBitsKHR
(along with the names of enumerants it
defines) and
VkVideoCapabilitiesFlagsKHR
to
VkVideoCapabilityFlagsKHR
, 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
to
VkQueueFamilyQueryResultStatusPropertiesKHR
Rename
VkVideoQueueFamilyProperties2KHR
to
VkQueueFamilyVideoPropertiesKHR
Rename
VkVideoProfileKHR
to
VkVideoProfileInfoKHR
Rename
VkVideoProfilesKHR
to
VkVideoProfileListInfoKHR
Rename
VkVideoGetMemoryPropertiesKHR
to
VkVideoSessionMemoryRequirementsKHR
Rename
VkVideoBindMemoryKHR
to
VkBindVideoSessionMemoryInfoKHR
Fix
pNext
constness of
VkPhysicalDeviceVideoFormatInfoKHR
and
VkVideoSessionMemoryRequirementsKHR
Fix incorrectly named value enums in bit enum types
VkVideoCodecOperationFlagBitsKHR
and
VkVideoChromaSubsamplingFlagBitsKHR
Remove unnecessary default values from
VkVideoSessionCreateFlagBitsKHR
and
VkVideoCodingControlFlagBitsKHR
Eliminate nested pointer in
VkVideoSessionMemoryRequirementsKHR
Rename
VkVideoPictureResourceKHR
to
VkVideoPictureResourceInfoKHR
Rename
VkVideoReferenceSlotKHR
to
VkVideoReferenceSlotInfoKHR
Revision 6, 2022-09-18 (Daniel Rakos)
Rename the
maxReferencePicturesSlotsCount
and
maxReferencePicturesActiveCount
fields of
VkVideoCapabilitiesKHR
and
VkVideoSessionCreateInfoKHR
to
maxDpbSlots
and
maxActiveReferencePictures
, respectively, to clarify their meaning
Rename
capabilityFlags
to
flags
in
VkVideoCapabilitiesKHR
Rename
videoPictureExtentGranularity
to
pictureAccessGranularity
in
VkVideoCapabilitiesKHR
Rename
minExtent
and
maxExtent
to
minCodedExtent
and
maxCodedExtent
, respectively, in
VkVideoCapabilitiesKHR
Rename
referencePicturesFormat
to
referencePictureFormat
in
VkVideoSessionCreateInfoKHR
Revision 7, 2022-09-26 (Daniel Rakos)
Change type of
VkVideoReferenceSlotInfoKHR::slotIndex
from
int8_t
to
int32_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
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Commands
vkCreateWaylandSurfaceKHR
vkGetPhysicalDeviceWaylandPresentationSupportKHR
New Structures
VkWaylandSurfaceCreateInfoKHR
New Bitmasks
VkWaylandSurfaceCreateFlagsKHR
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory_win32
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 Structures
Extending
VkSubmitInfo
VkSubmitInfo2
VkWin32KeyedMutexAcquireReleaseInfoKHR
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
Version History
Revision 1, 2016-10-21 (James Jones)
Initial revision
VK_KHR_win32_surface
Name String
VK_KHR_win32_surface
Extension Type
Instance extension
Registered Extension Number
10
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Commands
vkCreateWin32SurfaceKHR
vkGetPhysicalDeviceWin32PresentationSupportKHR
New Structures
VkWin32SurfaceCreateInfoKHR
New Bitmasks
VkWin32SurfaceCreateFlagsKHR
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 for
SetPixelFormat
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_workgroup_memory_explicit_layout
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceWorkgroupMemoryExplicitLayoutFeaturesKHR
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
New SPIR-V Capabilities
WorkgroupMemoryExplicitLayoutKHR
WorkgroupMemoryExplicitLayout8BitAccessKHR
WorkgroupMemoryExplicitLayout16BitAccessKHR
Version History
Revision 1, 2020-06-01 (Caio Marcelo de Oliveira Filho)
Initial version
VK_KHR_xcb_surface
Name String
VK_KHR_xcb_surface
Extension Type
Instance extension
Registered Extension Number
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Commands
vkCreateXcbSurfaceKHR
vkGetPhysicalDeviceXcbPresentationSupportKHR
New Structures
VkXcbSurfaceCreateInfoKHR
New Bitmasks
VkXcbSurfaceCreateFlagsKHR
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
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
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 Commands
vkCreateXlibSurfaceKHR
vkGetPhysicalDeviceXlibPresentationSupportKHR
New Structures
VkXlibSurfaceCreateInfoKHR
New Bitmasks
VkXlibSurfaceCreateFlagsKHR
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_acquire_drm_display
Name String
VK_EXT_acquire_drm_display
Extension Type
Instance extension
Registered Extension Number
286
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_direct_mode_display
Contact
Drew DeVault
[email protected]
Other Extension Metadata
Last Modified Date
2021-06-09
IP Status
No known IP claims.
Contributors
Simon Zeni, Status Holdings, Ltd.
Description
This extension allows an application to take exclusive control of a display
using the Direct Rendering Manager (DRM) interface.
When acquired, the display will be under full control of the application
until the display is either released or the connector is unplugged.
New Commands
vkAcquireDrmDisplayEXT
vkGetDrmDisplayEXT
New Enum Constants
VK_EXT_ACQUIRE_DRM_DISPLAY_EXTENSION_NAME
VK_EXT_ACQUIRE_DRM_DISPLAY_SPEC_VERSION
Issues
None.
Version History
Revision 1, 2021-05-11 (Simon Zeni)
Initial draft
VK_EXT_acquire_xlib_display
Name String
VK_EXT_acquire_xlib_display
Extension Type
Instance extension
Registered Extension Number
90
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_direct_mode_display
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-12-13
IP Status
No known IP claims.
Contributors
Dave Airlie, Red Hat
Pierre Boudier, NVIDIA
James Jones, NVIDIA
Damien Leone, NVIDIA
Pierre-Loup Griffais, Valve
Liam Middlebrook, NVIDIA
Daniel Vetter, Intel
Description
This extension allows an application to take exclusive control on a display
currently associated with an X11 screen.
When control is acquired, the display will be deassociated from the X11
screen until control is released or the specified display connection is
closed.
Essentially, the X11 screen will behave as if the monitor has been unplugged
until control is released.
New Commands
vkAcquireXlibDisplayEXT
vkGetRandROutputDisplayEXT
New Enum Constants
VK_EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME
VK_EXT_ACQUIRE_XLIB_DISPLAY_SPEC_VERSION
Issues
1) Should
vkAcquireXlibDisplayEXT
take an RandR display ID, or a
Vulkan display handle as input?
RESOLVED
: A Vulkan display handle.
Otherwise there would be no way to specify handles to displays that had been
prevented from being included in the X11 display list by some native
platform or vendor-specific mechanism.
2) How does an application figure out which RandR display corresponds to a
Vulkan display?
RESOLVED
: A new function,
vkGetRandROutputDisplayEXT
, is introduced
for this purpose.
3) Should
vkGetRandROutputDisplayEXT
be part of this extension, or a
general Vulkan / RandR or Vulkan / Xlib extension?
RESOLVED
: To avoid yet another extension, include it in this extension.
Version History
Revision 1, 2016-12-13 (James Jones)
Initial draft
VK_EXT_astc_decode_mode
Name String
VK_EXT_astc_decode_mode
Extension Type
Device extension
Registered Extension Number
68
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2018-08-07
Contributors
Jan-Harald Fredriksen, Arm
Description
The existing specification requires that low dynamic range (LDR) ASTC
textures are decompressed to FP16 values per component.
In many cases, decompressing LDR textures to a lower precision intermediate
result gives acceptable image quality.
Source material for LDR textures is typically authored as 8-bit UNORM
values, so decoding to FP16 values adds little value.
On the other hand, reducing precision of the decoded result reduces the size
of the decompressed data, potentially improving texture cache performance
and saving power.
The goal of this extension is to enable this efficiency gain on existing
ASTC texture data.
This is achieved by giving the application the ability to select the
intermediate decoding precision.
Three decoding options are provided:
Decode to
VK_FORMAT_R16G16B16A16_SFLOAT
precision: This is the
default, and matches the required behavior in the core API.
Decode to
VK_FORMAT_R8G8B8A8_UNORM
precision: This is provided as
an option in LDR mode.
Decode to
VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
precision: This is
provided as an option in both LDR and HDR mode.
In this mode, negative values cannot be represented and are clamped to
zero.
The alpha component is ignored, and the results are as if alpha was 1.0.
This decode mode is optional and support can be queried via the physical
device properties.
New Structures
Extending
VkImageViewCreateInfo
VkImageViewASTCDecodeModeEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceASTCDecodeFeaturesEXT
New Enum Constants
VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME
VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT
Issues
1) Are implementations allowed to decode at a higher precision than what is
requested?
RESOLUTION: No.
If we allow this, then this extension could be exposed on all
implementations that support ASTC.
But developers would have no way of knowing what precision was actually
used, and thus whether the image quality is sufficient at reduced
precision.
2) Should the decode mode be image view state and/or sampler state?
RESOLUTION: Image view state only.
Some implementations treat the different decode modes as different
texture formats.
Example
Create an image view that decodes to
VK_FORMAT_R8G8B8A8_UNORM
precision:
VkImageViewASTCDecodeModeEXT decodeMode =
.sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT,
.pNext = NULL,
.decodeMode = VK_FORMAT_R8G8B8A8_UNORM
};

VkImageViewCreateInfo createInfo =
.sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
.pNext = &decodeMode,
// flags, image, viewType set to application-desired values
.format = VK_FORMAT_ASTC_8x8_UNORM_BLOCK,
// components, subresourceRange set to application-desired values
};

VkImageView imageView;
VkResult result = vkCreateImageView(
device,
&createInfo,
NULL,
&imageView);
Version History
Revision 1, 2018-08-07 (Jan-Harald Fredriksen)
Initial revision
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_attachment_feedback_loop_layout
Special Uses
OpenGL / ES support
D3D support
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_attachment_feedback_loop_dynamic_state
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 Commands
vkCmdSetAttachmentFeedbackLoopEnableEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAttachmentFeedbackLoopDynamicStateFeaturesEXT
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
Version History
Revision 1, 2023-04-28 (Mike Blumenkrantz)
Initial revision
VK_EXT_attachment_feedback_loop_layout
Name String
VK_EXT_attachment_feedback_loop_layout
Extension Type
Device extension
Registered Extension Number
340
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Uses
OpenGL / ES support
D3D support
Contact
Joshua Ashton
Joshua-Ashton
Extension Proposal
VK_EXT_attachment_feedback_loop_layout
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAttachmentFeedbackLoopLayoutFeaturesEXT
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
Version History
Revision 2, 2022-04-04 (Joshua Ashton)
Renamed from VALVE to EXT.
Revision 1, 2021-03-09 (Joshua Ashton)
Initial draft.
VK_EXT_blend_operation_advanced
Name String
VK_EXT_blend_operation_advanced
Extension Type
Device extension
Registered Extension Number
149
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-06-12
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds a number of “advanced” blending operations that
can
be used to perform new color blending operations, many of which are more
complex than the standard blend modes provided by unextended Vulkan.
This extension requires different styles of usage, depending on the level of
hardware support and the enabled features:
If
VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT
::
advancedBlendCoherentOperations
is
VK_FALSE
, the new blending operations are supported, but a
memory dependency
must
separate each advanced blend operation on a
given sample.
VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT
is used to
synchronize reads using advanced blend operations.
If
VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT
::
advancedBlendCoherentOperations
is
VK_TRUE
, advanced blend operations obey primitive order just
like basic blend operations.
In unextended Vulkan, the set of blending operations is limited, and
can
be
expressed very simply.
The
VK_BLEND_OP_MIN
and
VK_BLEND_OP_MAX
blend operations simply
compute component-wise minimums or maximums of source and destination color
components.
The
VK_BLEND_OP_ADD
VK_BLEND_OP_SUBTRACT
, and
VK_BLEND_OP_REVERSE_SUBTRACT
modes multiply the source and destination
colors by source and destination factors and either add the two products
together or subtract one from the other.
This limited set of operations supports many common blending operations but
precludes the use of more sophisticated transparency and blending operations
commonly available in many dedicated imaging APIs.
This extension provides a number of new “advanced” blending operations.
Unlike traditional blending operations using
VK_BLEND_OP_ADD
, these
blending equations do not use source and destination factors specified by
VkBlendFactor
Instead, each blend operation specifies a complete equation based on the
source and destination colors.
These new blend operations are used for both RGB and alpha components; they
must
not be used to perform separate RGB and alpha blending (via different
values of color and alpha
VkBlendOp
).
These blending operations are performed using premultiplied colors, where
RGB colors
can
be considered premultiplied or non-premultiplied by alpha,
according to the
srcPremultiplied
and
dstPremultiplied
members
of
VkPipelineColorBlendAdvancedStateCreateInfoEXT
If a color is considered non-premultiplied, the (R,G,B) color components are
multiplied by the alpha component prior to blending.
For non-premultiplied color components in the range
[0,1]
, the
corresponding premultiplied color component would have values in the range
[0 × A, 1 × A]
Many of these advanced blending equations are formulated where the result of
blending source and destination colors with partial coverage have three
separate contributions: from the portions covered by both the source and the
destination, from the portion covered only by the source, and from the
portion covered only by the destination.
The blend parameter
VkPipelineColorBlendAdvancedStateCreateInfoEXT
::
blendOverlap
can
be used to specify a correlation between source and destination pixel
coverage.
If set to
VK_BLEND_OVERLAP_CONJOINT_EXT
, the source and destination
are considered to have maximal overlap, as would be the case if drawing two
objects on top of each other.
If set to
VK_BLEND_OVERLAP_DISJOINT_EXT
, the source and destination
are considered to have minimal overlap, as would be the case when rendering
a complex polygon tessellated into individual non-intersecting triangles.
If set to
VK_BLEND_OVERLAP_UNCORRELATED_EXT
, the source and
destination coverage are assumed to have no spatial correlation within the
pixel.
In addition to the coherency issues on implementations not supporting
advancedBlendCoherentOperations
, this extension has several
limitations worth noting.
First, the new blend operations have a limit on the number of color
attachments they
can
be used with, as indicated by
VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT
::
advancedBlendMaxColorAttachments
Additionally, blending precision
may
be limited to 16-bit floating-point,
which
may
result in a loss of precision and dynamic range for framebuffer
formats with 32-bit floating-point components, and in a loss of precision
for formats with 12- and 16-bit signed or unsigned normalized integer
components.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT
Extending
VkPipelineColorBlendStateCreateInfo
VkPipelineColorBlendAdvancedStateCreateInfoEXT
New Enums
VkBlendOverlapEXT
New Enum Constants
VK_EXT_BLEND_OPERATION_ADVANCED_EXTENSION_NAME
VK_EXT_BLEND_OPERATION_ADVANCED_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT
Extending
VkBlendOp
VK_BLEND_OP_BLUE_EXT
VK_BLEND_OP_COLORBURN_EXT
VK_BLEND_OP_COLORDODGE_EXT
VK_BLEND_OP_CONTRAST_EXT
VK_BLEND_OP_DARKEN_EXT
VK_BLEND_OP_DIFFERENCE_EXT
VK_BLEND_OP_DST_ATOP_EXT
VK_BLEND_OP_DST_EXT
VK_BLEND_OP_DST_IN_EXT
VK_BLEND_OP_DST_OUT_EXT
VK_BLEND_OP_DST_OVER_EXT
VK_BLEND_OP_EXCLUSION_EXT
VK_BLEND_OP_GREEN_EXT
VK_BLEND_OP_HARDLIGHT_EXT
VK_BLEND_OP_HARDMIX_EXT
VK_BLEND_OP_HSL_COLOR_EXT
VK_BLEND_OP_HSL_HUE_EXT
VK_BLEND_OP_HSL_LUMINOSITY_EXT
VK_BLEND_OP_HSL_SATURATION_EXT
VK_BLEND_OP_INVERT_EXT
VK_BLEND_OP_INVERT_OVG_EXT
VK_BLEND_OP_INVERT_RGB_EXT
VK_BLEND_OP_LIGHTEN_EXT
VK_BLEND_OP_LINEARBURN_EXT
VK_BLEND_OP_LINEARDODGE_EXT
VK_BLEND_OP_LINEARLIGHT_EXT
VK_BLEND_OP_MINUS_CLAMPED_EXT
VK_BLEND_OP_MINUS_EXT
VK_BLEND_OP_MULTIPLY_EXT
VK_BLEND_OP_OVERLAY_EXT
VK_BLEND_OP_PINLIGHT_EXT
VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT
VK_BLEND_OP_PLUS_CLAMPED_EXT
VK_BLEND_OP_PLUS_DARKER_EXT
VK_BLEND_OP_PLUS_EXT
VK_BLEND_OP_RED_EXT
VK_BLEND_OP_SCREEN_EXT
VK_BLEND_OP_SOFTLIGHT_EXT
VK_BLEND_OP_SRC_ATOP_EXT
VK_BLEND_OP_SRC_EXT
VK_BLEND_OP_SRC_IN_EXT
VK_BLEND_OP_SRC_OUT_EXT
VK_BLEND_OP_SRC_OVER_EXT
VK_BLEND_OP_VIVIDLIGHT_EXT
VK_BLEND_OP_XOR_EXT
VK_BLEND_OP_ZERO_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT
Issues
None.
Version History
Revision 1, 2017-06-12 (Jeff Bolz)
Internal revisions
Revision 2, 2017-06-12 (Jeff Bolz)
Internal revisions
VK_EXT_border_color_swizzle
Name String
VK_EXT_border_color_swizzle
Extension Type
Device extension
Registered Extension Number
412
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_custom_border_color
Special Uses
OpenGL / ES support
D3D support
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2021-10-12
IP Status
No known IP claims.
Contributors
Graeme Leese, Broadcom
Jan-Harald Fredriksen, Arm
Ricardo Garcia, Igalia
Shahbaz Youssefi, Google
Stu Smith, AMD
Description
After the publication of VK_EXT_custom_border_color, it was discovered that
some implementations had undefined behavior when combining a sampler that
uses a custom border color with image views whose component mapping is not
the identity mapping.
Since VK_EXT_custom_border_color has already shipped, this new extension
VK_EXT_border_color_swizzle was created to define the interaction between
custom border colors and non-identity image view swizzles, and provide a
work-around for implementations that must pre-swizzle the sampler border
color to match the image view component mapping it is combined with.
This extension also defines the behavior between samplers with an opaque
black border color and image views with a non-identity component swizzle,
which was previously left undefined.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceBorderColorSwizzleFeaturesEXT
Extending
VkSamplerCreateInfo
VkSamplerBorderColorComponentMappingCreateInfoEXT
New Enum Constants
VK_EXT_BORDER_COLOR_SWIZZLE_EXTENSION_NAME
VK_EXT_BORDER_COLOR_SWIZZLE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BORDER_COLOR_SWIZZLE_FEATURES_EXT
VK_STRUCTURE_TYPE_SAMPLER_BORDER_COLOR_COMPONENT_MAPPING_CREATE_INFO_EXT
Issues
None.
Version History
Revision 1, 2021-10-12 (Piers Daniell)
Internal revisions.
VK_EXT_color_write_enable
Name String
VK_EXT_color_write_enable
Extension Type
Device extension
Registered Extension Number
382
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Sharif Elcott
selcott
Other Extension Metadata
Last Modified Date
2020-02-25
IP Status
No known IP claims.
Contributors
Sharif Elcott, Google
Tobias Hector, AMD
Piers Daniell, NVIDIA
Description
This extension allows for selectively enabling and disabling writes to
output color attachments via a pipeline dynamic state.
The intended use cases for this new state are mostly identical to those of
colorWriteMask, such as selectively disabling writes to avoid feedback loops
between subpasses or bandwidth savings for unused outputs.
By making the state dynamic, one additional benefit is the ability to reduce
pipeline counts and pipeline switching via shaders that write a superset of
the desired data of which subsets are selected dynamically.
The reason for a new state, colorWriteEnable, rather than making
colorWriteMask dynamic is that, on many implementations, the more flexible
per-component semantics of the colorWriteMask state cannot be made dynamic
in a performant manner.
New Commands
vkCmdSetColorWriteEnableEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceColorWriteEnableFeaturesEXT
Extending
VkPipelineColorBlendStateCreateInfo
VkPipelineColorWriteCreateInfoEXT
New Enum Constants
VK_EXT_COLOR_WRITE_ENABLE_EXTENSION_NAME
VK_EXT_COLOR_WRITE_ENABLE_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COLOR_WRITE_ENABLE_FEATURES_EXT
VK_STRUCTURE_TYPE_PIPELINE_COLOR_WRITE_CREATE_INFO_EXT
Version History
Revision 1, 2020-01-25 (Sharif Elcott)
Internal revisions
VK_EXT_conditional_rendering
Name String
VK_EXT_conditional_rendering
Extension Type
Device extension
Registered Extension Number
82
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Vikram Kushwaha
vkushwaha
Other Extension Metadata
Last Modified Date
2018-05-21
IP Status
No known IP claims.
Contributors
Vikram Kushwaha, NVIDIA
Daniel Rakos, AMD
Jesse Hall, Google
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Stuart Smith, Imagination Technologies
Description
This extension allows the execution of one or more rendering commands to be
conditional on a value in buffer memory.
This may help an application reduce the latency by conditionally discarding
rendering commands without application intervention.
The conditional rendering commands are limited to draws, compute dispatches
and clearing attachments within a conditional rendering block.
New Commands
vkCmdBeginConditionalRenderingEXT
vkCmdEndConditionalRenderingEXT
New Structures
VkConditionalRenderingBeginInfoEXT
Extending
VkCommandBufferInheritanceInfo
VkCommandBufferInheritanceConditionalRenderingInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceConditionalRenderingFeaturesEXT
New Enums
VkConditionalRenderingFlagBitsEXT
New Bitmasks
VkConditionalRenderingFlagsEXT
New Enum Constants
VK_EXT_CONDITIONAL_RENDERING_EXTENSION_NAME
VK_EXT_CONDITIONAL_RENDERING_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_CONDITIONAL_RENDERING_READ_BIT_EXT
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_CONDITIONAL_RENDERING_BIT_EXT
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_CONDITIONAL_RENDERING_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_CONDITIONAL_RENDERING_INFO_EXT
VK_STRUCTURE_TYPE_CONDITIONAL_RENDERING_BEGIN_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONDITIONAL_RENDERING_FEATURES_EXT
Issues
1) Should conditional rendering affect copy and blit commands?
RESOLVED
: Conditional rendering should not affect copies and blits.
2) Should secondary command buffers be allowed to execute while conditional
rendering is active in the primary command buffer?
RESOLVED
: The rendering commands in secondary command buffer will be
affected by an active conditional rendering in primary command buffer if the
conditionalRenderingEnable
is set to
VK_TRUE
Conditional rendering
must
not be active in the primary command buffer if
conditionalRenderingEnable
is
VK_FALSE
Examples
None.
Version History
Revision 1, 2018-04-19 (Vikram Kushwaha)
First Version
Revision 2, 2018-05-21 (Vikram Kushwaha)
Add new pipeline stage, access flags and limit conditional rendering to
a subpass or entire render pass.
VK_EXT_conservative_rasterization
Name String
VK_EXT_conservative_rasterization
Extension Type
Device extension
Registered Extension Number
102
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_fragment_fully_covered
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2020-06-09
Interactions and External Dependencies
This extension requires
SPV_EXT_fragment_fully_covered
if the
VkPhysicalDeviceConservativeRasterizationPropertiesEXT
::
fullyCoveredFragmentShaderInputVariable
feature is used.
This extension requires
SPV_KHR_post_depth_coverage
if
the
VkPhysicalDeviceConservativeRasterizationPropertiesEXT
::
conservativeRasterizationPostDepthCoverage
feature is used.
This extension provides API support for
GL_NV_conservative_raster_underestimation
if the
VkPhysicalDeviceConservativeRasterizationPropertiesEXT
::
fullyCoveredFragmentShaderInputVariable
feature is used.
Contributors
Daniel Koch, NVIDIA
Daniel Rakos, AMD
Jeff Bolz, NVIDIA
Slawomir Grajewski, Intel
Stu Smith, Imagination Technologies
Description
This extension adds a new rasterization mode called conservative
rasterization.
There are two modes of conservative rasterization; overestimation and
underestimation.
When overestimation is enabled, if any part of the primitive, including its
edges, covers any part of the rectangular pixel area, including its sides,
then a fragment is generated with all coverage samples turned on.
This extension allows for some variation in implementations by accounting
for differences in overestimation, where the generating primitive size is
increased at each of its edges by some sub-pixel amount to further increase
conservative pixel coverage.
Implementations can allow the application to specify an extra overestimation
beyond the base overestimation the implementation already does.
It also allows implementations to either cull degenerate primitives or
rasterize them.
When underestimation is enabled, fragments are only generated if the
rectangular pixel area is fully covered by the generating primitive.
If supported by the implementation, when a pixel rectangle is fully covered
the fragment shader input variable builtin called FullyCoveredEXT is set to
true.
The shader variable works in either overestimation or underestimation mode.
Implementations can process degenerate triangles and lines by either
discarding them or generating conservative fragments for them.
Degenerate triangles are those that end up with zero area after the
rasterizer quantizes them to the fixed-point pixel grid.
Degenerate lines are those with zero length after quantization.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceConservativeRasterizationPropertiesEXT
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationConservativeStateCreateInfoEXT
New Enums
VkConservativeRasterizationModeEXT
New Bitmasks
VkPipelineRasterizationConservativeStateCreateFlagsEXT
New Enum Constants
VK_EXT_CONSERVATIVE_RASTERIZATION_EXTENSION_NAME
VK_EXT_CONSERVATIVE_RASTERIZATION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONSERVATIVE_RASTERIZATION_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT
New Built-In Variables
FullyCoveredEXT
New SPIR-V Capabilities
FragmentFullyCoveredEXT
Version History
Revision 1.1, 2020-09-06 (Piers Daniell)
Add missing SPIR-V and GLSL dependencies.
Revision 1, 2017-08-28 (Piers Daniell)
Internal revisions
VK_EXT_custom_border_color
Name String
VK_EXT_custom_border_color
Extension Type
Device extension
Registered Extension Number
288
Revision
12
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Uses
OpenGL / ES support
D3D support
Contact
Liam Middlebrook
liam-middlebrook
Other Extension Metadata
Last Modified Date
2020-04-16
IP Status
No known IP claims.
Contributors
Joshua Ashton, Valve
Hans-Kristian Arntzen, Valve
Philip Rebohle, Valve
Liam Middlebrook, NVIDIA
Jeff Bolz, NVIDIA
Tobias Hector, AMD
Faith Ekstrand, Intel
Spencer Fricke, Samsung Electronics
Graeme Leese, Broadcom
Jesse Hall, Google
Jan-Harald Fredriksen, ARM
Tom Olson, ARM
Stuart Smith, Imagination Technologies
Donald Scorgie, Imagination Technologies
Alex Walters, Imagination Technologies
Peter Quayle, Imagination Technologies
Description
This extension provides cross-vendor functionality to specify a custom
border color for use when the sampler address mode
VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER
is used.
To create a sampler which uses a custom border color set
VkSamplerCreateInfo
::
borderColor
to one of:
VK_BORDER_COLOR_FLOAT_CUSTOM_EXT
VK_BORDER_COLOR_INT_CUSTOM_EXT
When
VK_BORDER_COLOR_FLOAT_CUSTOM_EXT
or
VK_BORDER_COLOR_INT_CUSTOM_EXT
is used, applications must provide a
VkSamplerCustomBorderColorCreateInfoEXT
in the
pNext
chain for
VkSamplerCreateInfo
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCustomBorderColorFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCustomBorderColorPropertiesEXT
Extending
VkSamplerCreateInfo
VkSamplerCustomBorderColorCreateInfoEXT
New Enum Constants
VK_EXT_CUSTOM_BORDER_COLOR_EXTENSION_NAME
VK_EXT_CUSTOM_BORDER_COLOR_SPEC_VERSION
Extending
VkBorderColor
VK_BORDER_COLOR_FLOAT_CUSTOM_EXT
VK_BORDER_COLOR_INT_CUSTOM_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_PROPERTIES_EXT
VK_STRUCTURE_TYPE_SAMPLER_CUSTOM_BORDER_COLOR_CREATE_INFO_EXT
Issues
1) Should VkClearColorValue be used for the border color value, or should we
have our own struct/union? Do we need to specify the type of the input
values for the components? This is more of a concern if VkClearColorValue is
used here because it provides a union of float,int,uint types.
RESOLVED
: Will reuse existing VkClearColorValue structure in order to
easily take advantage of float,int,uint borderColor types.
2) For hardware which supports a limited number of border colors what
happens if that number is exceeded? Should this be handled by the driver
unbeknownst to the application? In Revision 1 we had solved this issue using
a new Object type, however that may have lead to additional system resource
consumption which would otherwise not be required.
RESOLVED
: Added
VkPhysicalDeviceCustomBorderColorPropertiesEXT
::
maxCustomBorderColorSamplers
for tracking implementation-specific limit, and Valid Usage statement
handling overflow.
3) Should this be supported for immutable samplers at all, or by a feature
bit? Some implementations may not be able to support custom border colors on
immutable samplers — is it worthwhile enabling this to work on them for
implementations that can support it, or forbidding it entirely.
RESOLVED
: Samplers created with a custom border color are forbidden from
being immutable.
This resolves concerns for implementations where the custom border color is
an index to a LUT instead of being directly embedded into sampler state.
4) Should UINT and SINT (unsigned integer and signed integer) border color
types be separated or should they be combined into one generic INT (integer)
type?
RESOLVED
: Separating these does not make much sense as the existing fixed
border color types do not have this distinction, and there is no reason in
hardware to do so.
This separation would also create unnecessary work and considerations for
the application.
Version History
Revision 1, 2019-10-10 (Joshua Ashton)
Internal revisions.
Revision 2, 2019-10-11 (Liam Middlebrook)
Remove VkCustomBorderColor object and associated functions
Add issues concerning HW limitations for custom border color count
Revision 3, 2019-10-12 (Joshua Ashton)
Re-expose the limits for the maximum number of unique border colors
Add extra details about border color tracking
Fix typos
Revision 4, 2019-10-12 (Joshua Ashton)
Changed maxUniqueCustomBorderColors to a uint32_t from a VkDeviceSize
Revision 5, 2019-10-14 (Liam Middlebrook)
Added features bit
Revision 6, 2019-10-15 (Joshua Ashton)
Type-ize VK_BORDER_COLOR_CUSTOM
Fix const-ness on
pNext
of
VkSamplerCustomBorderColorCreateInfoEXT
Revision 7, 2019-11-26 (Liam Middlebrook)
Renamed maxUniqueCustomBorderColors to maxCustomBorderColors
Revision 8, 2019-11-29 (Joshua Ashton)
Renamed borderColor member of VkSamplerCustomBorderColorCreateInfoEXT
to customBorderColor
Revision 9, 2020-02-19 (Joshua Ashton)
Renamed maxCustomBorderColors to maxCustomBorderColorSamplers
Revision 10, 2020-02-21 (Joshua Ashton)
Added format to VkSamplerCustomBorderColorCreateInfoEXT and feature bit
Revision 11, 2020-04-07 (Joshua Ashton)
Dropped UINT/SINT border color differences, consolidated types
Revision 12, 2020-04-16 (Joshua Ashton)
Renamed VK_BORDER_COLOR_CUSTOM_FLOAT_EXT to
VK_BORDER_COLOR_FLOAT_CUSTOM_EXT for consistency
VK_EXT_custom_resolve
Name String
VK_EXT_custom_resolve
Extension Type
Device extension
Registered Extension Number
629
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_custom_resolve
Other Extension Metadata
Last Modified Date
2025-05-13
IP Status
No known IP claims.
Interactions and External Dependencies
This extension interacts with
VK_KHR_dynamic_rendering
This extension interacts with
VK_EXT_dynamic_rendering_unused_attachments
This extension interacts with
VK_EXT_fragment_density_map
This extension interacts with
VK_EXT_graphics_pipeline_library
This extension interacts with
VK_EXT_shader_object
Contributors
Mike Blumenkrantz, Valve
Connor Abbott, Valve
Samuel Pitoiset, Valve
Matthew Netsch, Qualcomm
Jan-Harald Fredriksen, ARM
Ting Wei, ARM
Ricardo Garcia, Igalia
Spencer Fricke, LunarG
Piers Daniell, Nvidia
Description
This extension provides functionality for using shaders to resolve
multisample rendering attachments.
It builds upon mechanics introduced by VK_QCOM_render_pass_shader_resolve,
additionally adding support for dynamic rendering.
New Commands
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
is supported:
vkCmdBeginCustomResolveEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCustomResolveFeaturesEXT
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
is supported:
VkBeginCustomResolveInfoEXT
Extending
VkGraphicsPipelineCreateInfo
VkCommandBufferInheritanceInfo
VkShaderCreateInfoEXT
VkCustomResolveCreateInfoEXT
New Enum Constants
VK_EXT_CUSTOM_RESOLVE_EXTENSION_NAME
VK_EXT_CUSTOM_RESOLVE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_RESOLVE_FEATURES_EXT
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_CUSTOM_RESOLVE_BIT_EXT
VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_EXT
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
is supported:
Extending
VkRenderingFlagBits
VK_RENDERING_CUSTOM_RESOLVE_BIT_EXT
VK_RENDERING_FRAGMENT_REGION_BIT_EXT
Extending
VkResolveModeFlagBits
VK_RESOLVE_MODE_CUSTOM_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_BEGIN_CUSTOM_RESOLVE_INFO_EXT
VK_STRUCTURE_TYPE_CUSTOM_RESOLVE_CREATE_INFO_EXT
Issues
1) How will this work with shader objects?
Some vendors emit an epilog at the end of the FS that stores each
color/depth/stencil attachment to the appropriate tilebuffer location, and
to do that they need to know the layout of the tilebuffer which depends on
the attachment formats/sample counts.
We agreed that for shader object the FS epilog is emitted dynamically when
the draw happens.
Version History
Revision 1, 2025-05-13 (Mike Blumenkrantz)
Initial draft
VK_EXT_debug_utils
Name String
VK_EXT_debug_utils
Extension Type
Instance extension
Registered Extension Number
129
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Special Use
Debugging tools
Contact
Mark Young
marky-lunarg
Other Extension Metadata
Last Modified Date
2020-04-03
Revision
IP Status
No known IP claims.
Dependencies
This extension is written against version 1.0 of the Vulkan API.
Requires
VkObjectType
Contributors
Mark Young, LunarG
Baldur Karlsson
Ian Elliott, Google
Courtney Goeltzenleuchter, Google
Karl Schultz, LunarG
Mark Lobodzinski, LunarG
Mike Schuchardt, LunarG
Jaakko Konttinen, AMD
Dan Ginsburg, Valve Software
Rolando Olivares, Epic Games
Dan Baker, Oxide Games
Kyle Spagnoli, NVIDIA
Jon Ashburn, LunarG
Piers Daniell, NVIDIA
Description
Due to the nature of the Vulkan interface, there is very little error
information available to the developer and application.
By using the
VK_EXT_debug_utils
extension, developers
can
obtain more
information.
When combined with validation layers, even more detailed feedback on the
application’s use of Vulkan will be provided.
This extension provides the following capabilities:
The ability to create a debug messenger which will pass along debug
messages to an application supplied callback.
The ability to identify specific Vulkan objects using a name or tag to
improve tracking.
The ability to identify specific sections within a
VkQueue
or
VkCommandBuffer
using labels to aid organization and offline
analysis in external tools.
The main difference between this extension and
VK_EXT_debug_report
and
VK_EXT_debug_marker
is that those extensions use
VkDebugReportObjectTypeEXT
to identify objects.
This extension uses the core
VkObjectType
in place of
VkDebugReportObjectTypeEXT
The primary reason for this move is that no future object type handle
enumeration values will be added to
VkDebugReportObjectTypeEXT
since
the creation of
VkObjectType
In addition, this extension combines the functionality of both
VK_EXT_debug_report
and
VK_EXT_debug_marker
by allowing
object name and debug markers (now called labels) to be returned to the
application’s callback function.
This should assist in clarifying the details of a debug message including:
what objects are involved and potentially which location within a
VkQueue
or
VkCommandBuffer
the message occurred.
New Object Types
VkDebugUtilsMessengerEXT
New Commands
vkCmdBeginDebugUtilsLabelEXT
vkCmdEndDebugUtilsLabelEXT
vkCmdInsertDebugUtilsLabelEXT
vkCreateDebugUtilsMessengerEXT
vkDestroyDebugUtilsMessengerEXT
vkQueueBeginDebugUtilsLabelEXT
vkQueueEndDebugUtilsLabelEXT
vkQueueInsertDebugUtilsLabelEXT
vkSetDebugUtilsObjectNameEXT
vkSetDebugUtilsObjectTagEXT
vkSubmitDebugUtilsMessageEXT
New Structures
VkDebugUtilsLabelEXT
VkDebugUtilsMessengerCallbackDataEXT
VkDebugUtilsObjectTagInfoEXT
Extending
VkInstanceCreateInfo
VkDebugUtilsMessengerCreateInfoEXT
Extending
VkPipelineShaderStageCreateInfo
VkResourceDescriptorInfoEXT
VkSamplerCreateInfo
VkDebugUtilsObjectNameInfoEXT
New Function Pointers
PFN_vkDebugUtilsMessengerCallbackEXT
New Enums
VkDebugUtilsMessageSeverityFlagBitsEXT
VkDebugUtilsMessageTypeFlagBitsEXT
New Bitmasks
VkDebugUtilsMessageSeverityFlagsEXT
VkDebugUtilsMessageTypeFlagsEXT
VkDebugUtilsMessengerCallbackDataFlagsEXT
VkDebugUtilsMessengerCreateFlagsEXT
New Enum Constants
VK_EXT_DEBUG_UTILS_EXTENSION_NAME
VK_EXT_DEBUG_UTILS_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT
VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CALLBACK_DATA_EXT
VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT
VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_TAG_INFO_EXT
Examples
Example 1
VK_EXT_debug_utils
allows an application to register multiple callbacks
with any Vulkan component wishing to report debug information.
Some callbacks may log the information to a file, others may cause a debug
break point or other application-defined behavior.
An application
can
register callbacks even when no validation layers are
enabled, but they will only be called for loader and, if implemented, driver
events.
To capture events that occur while creating or destroying an instance an
application
can
link a
VkDebugUtilsMessengerCreateInfoEXT
structure
to the
pNext
chain of the
VkInstanceCreateInfo
structure passed
to
vkCreateInstance
Example uses: Create three callback objects.
One will log errors and warnings to the debug console using Windows
OutputDebugString
The second will cause the debugger to break at that callback when an error
happens and the third will log warnings to stdout.
extern VkInstance instance;
VkResult res;
VkDebugUtilsMessengerEXT cb1, cb2, cb3;

// Must call extension functions through a function pointer:
PFN_vkCreateDebugUtilsMessengerEXT pfnCreateDebugUtilsMessengerEXT = (PFN_vkCreateDebugUtilsMessengerEXT)vkGetInstanceProcAddr(instance, "vkCreateDebugUtilsMessengerEXT");
PFN_vkDestroyDebugUtilsMessengerEXT pfnDestroyDebugUtilsMessengerEXT = (PFN_vkDestroyDebugUtilsMessengerEXT)vkGetInstanceProcAddr(instance, "vkDestroyDebugUtilsMessengerEXT");

VkDebugUtilsMessengerCreateInfoEXT callback1 = {
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT |
VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
.messageType= VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
.pfnUserCallback = myOutputDebugString,
.pUserData = NULL
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb1);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY

callback1.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT;
callback1.pfnUserCallback = myDebugBreak;
callback1.pUserData = NULL;
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback1, NULL, &cb2);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY

VkDebugUtilsMessengerCreateInfoEXT callback3 = {
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,
.pNext = NULL,
.flags = 0,
.messageSeverity = VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
.messageType = VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |
VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
.pfnUserCallback = mystdOutLogger,
.pUserData = NULL
};
res = pfnCreateDebugUtilsMessengerEXT(instance, &callback3, NULL, &cb3);
if (res != VK_SUCCESS) {
// Do error handling for VK_ERROR_OUT_OF_MEMORY

...

// Remove callbacks when cleaning up
pfnDestroyDebugUtilsMessengerEXT(instance, cb1, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb2, NULL);
pfnDestroyDebugUtilsMessengerEXT(instance, cb3, NULL);
Example 2
Associate a name with an image, for easier debugging in external tools or
with validation layers that can print a friendly name when referring to
objects in error messages.
extern VkInstance instance;
extern VkDevice device;
extern VkImage image;

// Must call extension functions through a function pointer:
PFN_vkSetDebugUtilsObjectNameEXT pfnSetDebugUtilsObjectNameEXT = (PFN_vkSetDebugUtilsObjectNameEXT)vkGetInstanceProcAddr(instance, "vkSetDebugUtilsObjectNameEXT");

// Set a name on the image
const VkDebugUtilsObjectNameInfoEXT imageNameInfo =
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT,
.pNext = NULL,
.objectType = VK_OBJECT_TYPE_IMAGE,
.objectHandle = (uint64_t)image,
.pObjectName = "Brick Diffuse Texture",
};

pfnSetDebugUtilsObjectNameEXT(device, &imageNameInfo);

// A subsequent error might print:
// Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
// command buffer with no memory bound to it.
Example 3
Annotating regions of a workload with naming information so that offline
analysis tools can display a more usable visualization of the commands
submitted.
extern VkInstance instance;
extern VkCommandBuffer commandBuffer;

// Must call extension functions through a function pointer:
PFN_vkQueueBeginDebugUtilsLabelEXT pfnQueueBeginDebugUtilsLabelEXT = (PFN_vkQueueBeginDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkQueueBeginDebugUtilsLabelEXT");
PFN_vkQueueEndDebugUtilsLabelEXT pfnQueueEndDebugUtilsLabelEXT = (PFN_vkQueueEndDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkQueueEndDebugUtilsLabelEXT");
PFN_vkCmdBeginDebugUtilsLabelEXT pfnCmdBeginDebugUtilsLabelEXT = (PFN_vkCmdBeginDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdBeginDebugUtilsLabelEXT");
PFN_vkCmdEndDebugUtilsLabelEXT pfnCmdEndDebugUtilsLabelEXT = (PFN_vkCmdEndDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdEndDebugUtilsLabelEXT");
PFN_vkCmdInsertDebugUtilsLabelEXT pfnCmdInsertDebugUtilsLabelEXT = (PFN_vkCmdInsertDebugUtilsLabelEXT)vkGetInstanceProcAddr(instance, "vkCmdInsertDebugUtilsLabelEXT");

// Describe the area being rendered
const VkDebugUtilsLabelEXT houseLabel =
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
.pNext = NULL,
.pLabelName = "Brick House",
.color = { 1.0f, 0.0f, 0.0f, 1.0f },
};

// Start an annotated group of calls under the 'Brick House' name
pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &houseLabel);
// A mutable structure for each part being rendered
VkDebugUtilsLabelEXT housePartLabel =
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
.pNext = NULL,
.pLabelName = NULL,
.color = { 0.0f, 0.0f, 0.0f, 0.0f },
};

// Set the name and insert the marker
housePartLabel.pLabelName = "Walls";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

// Insert the drawcall for the walls
vkCmdDrawIndexed(commandBuffer, 1000, 1, 0, 0, 0);

// Insert a recursive region for two sets of windows
housePartLabel.pLabelName = "Windows";
pfnCmdBeginDebugUtilsLabelEXT(commandBuffer, &housePartLabel);
vkCmdDrawIndexed(commandBuffer, 75, 6, 1000, 0, 0);
vkCmdDrawIndexed(commandBuffer, 100, 2, 1450, 0, 0);
pfnCmdEndDebugUtilsLabelEXT(commandBuffer);

housePartLabel.pLabelName = "Front Door";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

vkCmdDrawIndexed(commandBuffer, 350, 1, 1650, 0, 0);

housePartLabel.pLabelName = "Roof";
pfnCmdInsertDebugUtilsLabelEXT(commandBuffer, &housePartLabel);

vkCmdDrawIndexed(commandBuffer, 500, 1, 2000, 0, 0);
// End the house annotation started above
pfnCmdEndDebugUtilsLabelEXT(commandBuffer);

// Do other work

vkEndCommandBuffer(commandBuffer);

// Describe the queue being used
const VkDebugUtilsLabelEXT queueLabel =
.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT,
.pNext = NULL,
.pLabelName = "Main Render Work",
.color = { 0.0f, 1.0f, 0.0f, 1.0f },
};

// Identify the queue label region
pfnQueueBeginDebugUtilsLabelEXT(queue, &queueLabel);

// Submit the work for the main render thread
const VkCommandBuffer cmd_bufs[] = {commandBuffer};
VkSubmitInfo submit_info =
.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO,
.pNext = NULL,
.waitSemaphoreCount = 0,
.pWaitSemaphores = NULL,
.pWaitDstStageMask = NULL,
.commandBufferCount = 1,
.pCommandBuffers = cmd_bufs,
.signalSemaphoreCount = 0,
.pSignalSemaphores = NULL
};
vkQueueSubmit(queue, 1, &submit_info, fence);

// End the queue label region
pfnQueueEndDebugUtilsLabelEXT(queue);
Issues
1) Should we just name this extension
VK_EXT_debug_report2
RESOLVED
: No.
There is enough additional changes to the structures to break backwards
compatibility.
So, a new name was decided that would not indicate any interaction with the
previous extension.
2) Will validation layers immediately support all the new features.
RESOLVED
: Not immediately.
As one can imagine, there is a lot of work involved with converting the
validation layer logging over to the new functionality.
Basic logging, as seen in the origin
VK_EXT_debug_report
extension
will be made available immediately.
However, adding the labels and object names will take time.
Since the priority for Khronos at this time is to continue focusing on Valid
Usage statements, it may take a while before the new functionality is fully
exposed.
3) If the validation layers will not expose the new functionality
immediately, then what is the point of this extension?
RESOLVED
: We needed a replacement for
VK_EXT_debug_report
because
the
VkDebugReportObjectTypeEXT
enumeration will no longer be updated
and any new objects will need to be debugged using the new functionality
provided by this extension.
4) Should this extension be split into two separate parts (1 extension that
is an instance extension providing the callback functionality, and another
device extension providing the general debug marker and annotation
functionality)?
RESOLVED
: No, the functionality for this extension is too closely related.
If we did split up the extension, where would the structures and enums live,
and how would you define that the device behavior in the instance extension
is really only valid if the device extension is enabled, and the
functionality is passed in.
It is cleaner to just define this all as an instance extension, plus it
allows the application to enable all debug functionality provided with one
enable string during
vkCreateInstance
Version History
Revision 1, 2017-09-14 (Mark Young and all listed Contributors)
Initial draft, based on
VK_EXT_debug_report
and
VK_EXT_debug_marker
in addition to previous feedback supplied
from various companies including Valve, Epic, and Oxide games.
Revision 2, 2020-04-03 (Mark Young and Piers Daniell)
Updated to allow either
NULL
or an empty string to be passed in for
pObjectName
in
VkDebugUtilsObjectNameInfoEXT
, because the
loader and various drivers support
NULL
already.
VK_EXT_depth_bias_control
Name String
VK_EXT_depth_bias_control
Extension Type
Device extension
Registered Extension Number
284
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
D3D support
Contact
Joshua Ashton
Joshua-Ashton
Extension Proposal
VK_EXT_depth_bias_control
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 Commands
vkCmdSetDepthBias2EXT
New Structures
VkDepthBiasInfoEXT
Extending
VkDepthBiasInfoEXT
VkPipelineRasterizationStateCreateInfo
VkDepthBiasRepresentationInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthBiasControlFeaturesEXT
New Enums
VkDepthBiasRepresentationEXT
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
Version History
Revision 1, 2022-09-22 (Joshua Ashton)
Initial draft.
VK_EXT_depth_clamp_control
Name String
VK_EXT_depth_clamp_control
Extension Type
Device extension
Registered Extension Number
583
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jules Blok
jules
Extension Proposal
VK_EXT_depth_clamp_control
Other Extension Metadata
Last Modified Date
2024-07-15
Contributors
Jules Blok, Independent
Description
This extension allows the application to control the viewport depth clamp
range separately from the viewport
minDepth
and
maxDepth
This gives the ability for the application to restrict depth values to an
application-defined range rather than
the viewport depth range or the range defined in the
VK_EXT_depth_clamp_zero_one
extension.
It can be used to set a smaller or larger clamping range than the viewport
depth range without affecting the depth mapping of the viewport transform.
Another possible use of this extension is to restrict depth values beyond
the viewport depth range to a clamping range other than the [0, 1] range
defined in the
VK_EXT_depth_clamp_zero_one
extension.
New Commands
vkCmdSetDepthClampRangeEXT
New Structures
VkDepthClampRangeEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthClampControlFeaturesEXT
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportDepthClampControlCreateInfoEXT
New Enums
VkDepthClampModeEXT
New Enum Constants
VK_EXT_DEPTH_CLAMP_CONTROL_EXTENSION_NAME
VK_EXT_DEPTH_CLAMP_CONTROL_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_DEPTH_CLAMP_RANGE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_CONTROL_FEATURES_EXT
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLAMP_CONTROL_CREATE_INFO_EXT
Issues
1) Should the depth clamp range be a per-viewport parameter?
RESOLVED
: No.
Because the depth clamp range was previously defined to be equal to the
viewport depth range, conformant runtimes are already handling the depth
clamp range as a per-viewport parameter.
However because of complexities from interactions with multiple viewports a
per-viewport clamp range is left to a future extensions if a use case
arises.
2) Should this pipeline state be dynamic?
RESOLVED
: Yes.
Since the viewport depth range can already be a dynamic state conformant
runtimes are already able to handle the depth clamp range as a dynamic
state.
3) Can the depth clamp range be ignored when depth clamping is disabled?
RESOLVED
: Yes.
This extension overrides the clamping range used only when depth clamping is
enabled.
The alternative would be highly unintuitive.
As a consequence the
VK_EXT_depth_clip_enable
extension is required
if depth clipping is desired in combination with this extension.
Version History
Revision 1, 2024-02-13 (Jules Blok)
Initial draft
VK_EXT_depth_clip_control
Name String
VK_EXT_depth_clip_control
Extension Type
Device extension
Registered Extension Number
356
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
Shahbaz Youssefi
syoussefi
Other Extension Metadata
Last Modified Date
2021-11-09
Contributors
Spencer Fricke, Samsung Electronics
Shahbaz Youssefi, Google
Ralph Potter, Samsung Electronics
Description
This extension allows the application to use the OpenGL depth range in NDC,
i.e. with depth in range
[-1, 1]
, as opposed to Vulkan’s default of
[0, 1]
The purpose of this extension is to allow efficient layering of OpenGL over
Vulkan, by avoiding emulation in the pre-rasterization shader stages.
This emulation, which effectively duplicates gl_Position but with a
different depth value, costs ALU and consumes shader output components that
the implementation may not have to spare to meet OpenGL minimum
requirements.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthClipControlFeaturesEXT
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportDepthClipControlCreateInfoEXT
New Enum Constants
VK_EXT_DEPTH_CLIP_CONTROL_EXTENSION_NAME
VK_EXT_DEPTH_CLIP_CONTROL_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_CONTROL_FEATURES_EXT
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLIP_CONTROL_CREATE_INFO_EXT
Issues
1) Should this extension include an origin control option to match
GL_LOWER_LEFT found in ARB_clip_control?
RESOLVED
: No.
The fix for porting over the origin is a simple y-axis flip.
The depth clip control is a much harder problem to solve than what this
extension is aimed to solve.
Adding an equivalent to GL_LOWER_LEFT would require more testing.
2) Should this pipeline state be dynamic?
RESOLVED
: Yes.
The purpose of this extension is to emulate the OpenGL depth range, which is
expected to be globally fixed (in case of OpenGL ES) or very infrequently
changed (with
glClipControl
in OpenGL).
3) Should the control provided in this extension be an enum that could be
extended in the future?
RESOLVED
: No.
It is highly unlikely that the depth range is changed to anything other than
[0, 1]
in the future.
Should that happen a new extension will be required to extend such an enum,
and that extension might as well add a new structure to chain to
VkPipelineViewportStateCreateInfo
::
pNext
instead.
Version History
Revision 0, 2020-10-01 (Spencer Fricke)
Internal revisions
Revision 1, 2020-11-26 (Shahbaz Youssefi)
Language fixes
VK_EXT_depth_clip_enable
Name String
VK_EXT_depth_clip_enable
Extension Type
Device extension
Registered Extension Number
103
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
D3D support
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthClipEnableFeaturesEXT
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationDepthClipStateCreateInfoEXT
New Bitmasks
VkPipelineRasterizationDepthClipStateCreateFlagsEXT
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
Version History
Revision 1, 2018-12-20 (Piers Daniell)
Internal revisions
VK_EXT_depth_range_unrestricted
Name String
VK_EXT_depth_range_unrestricted
Extension Type
Device extension
Registered Extension Number
14
Revision
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
≤ z
≤ w
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.
Version History
Revision 1, 2017-06-22 (Piers Daniell)
Internal revisions
VK_EXT_descriptor_heap
Name String
VK_EXT_descriptor_heap
Extension Type
Device extension
Registered Extension Number
136
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_maintenance5
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
API Interactions
Interacts with VK_ARM_tensors
Interacts with VK_EXT_custom_border_color
Interacts with VK_EXT_device_generated_commands
Interacts with VK_EXT_fragment_density_map
Interacts with VK_EXT_shader_object
Interacts with VK_KHR_ray_tracing_pipeline
Interacts with VK_NV_device_generated_commands
Interacts with VK_NV_ray_tracing
SPIR-V Dependencies
SPV_EXT_descriptor_heap
Contact
Tobias Hector
tobski
Extension Proposal
VK_EXT_descriptor_heap
Other Extension Metadata
Last Modified Date
2024-06-12
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Jan-Harald Fredriksen, Arm
Daniel Story, Nintendo
Connor Abbot, Valve
Hans-Kristian Arntzen, Valve
Matthew Netsch, Qualcomm
Jeff Bolz, NVIDIA
Alyssa Rosenzweig, Valve
Lionel Landerwerlin, Intel
Baldur Karlsson, Valve
Faith Ekstrand, Collabora
Slawomir Grajewski, Intel
Mike Blumenkrantz, Valve
Yiwei Zhang, Google
Stu Smith, AMD
Piers Daniell, NVIDIA
Jon Leech, Khronos
Rodrigo Locatti, NVIDIA
Krzysztof Niski, NVIDIA
Alan Baker, Google
James Fitzpatrick, Imagination
Samuel (Sheng-Wen) Huang, Mediatek
Hai Nguyen, Google
Jeff Leger, Qualcomm
Marty Johnson, Khronos
Tom Olson, Arm
Chris Glover, Google
Daniel Koch, NVIDIA
Robert Simpson, Qualcomm
Dan Ginsburg, Valve
Andreas Süßenbach, NVIDIA
Anna Maniscalco, Valve
Artem Kharytoniuk, LunarG
Younggwan Kim, Arm
Konstantin Seurer, Valve
Catarina Shablia, Collabora
Spencer Fricke, LunarG
Chris Bieneman, Microsoft
Ting Wei, Arm
Boris Zanin, AMD
Samuel Pitoiset, Valve
Erik Hogeman, Arm
Jesse Natalie, Microsoft
Guang Xu, AMD
Embla Flatlandsmo, Arm
Interactions and External Dependencies
VK_KHR_shader_untyped_pointers
must be supported, but it does not
need to be enabled for applications using only the
binding interface
Description
This extension allows explicit management of descriptors, and the memory
used to store descriptors, conceptualised as descriptor heaps.
Descriptor heap memory can be accessed as any other memory, enabling
management of descriptors on both CPU and the GPU.
This extension was developed based on issues discovered with
VK_EXT_descriptor_buffer
There are more constraints on how it is implemented, to provide more
portable guarantees and more predictable performance characteristics.
For instance, rather than an arbitrary number of sampler or resource
buffers, there is exactly one sampler heap and exactly one resource heap.
This extension also eliminates descriptor sets and pipeline layouts
completely; instead applications can look descriptors up solely by their
offset into a heap.
Shaders still using descriptor set and binding decorations can still be
mapped to heaps through an API that maps set and binding decorations to heap
offsets, either as constants or through push data.
This new mapping API also enables a much more straightforward mapping to
HLSL shaders using the root signature and descriptor table interfaces.
The push constant API has also been replaced with the
push data
interface,
which aims to provide much more clarity about how data is passed to the
shader, without requiring any mapping information to be provided during
pipeline or shader creation.
Mappings are still available for shaders written for the legacy interface.
There is also a much clearer path for mapping shader constant data, with two
recommended options for mapping constant data through push data; either
directly in push data, or through a device address stored in push data, both
of which can be mapped to shaders with set and binding interfaces.
New Object Types
VkTensorARM
New Commands
vkCmdBindResourceHeapEXT
vkCmdBindSamplerHeapEXT
vkCmdPushDataEXT
vkGetImageOpaqueCaptureDataEXT
vkGetPhysicalDeviceDescriptorSizeEXT
vkWriteResourceDescriptorsEXT
vkWriteSamplerDescriptorsEXT
If
VK_ARM_tensors
is supported:
vkGetTensorOpaqueCaptureDataARM
If
VK_EXT_custom_border_color
is supported:
vkRegisterCustomBorderColorEXT
vkUnregisterCustomBorderColorEXT
New Structures
VkBindHeapInfoEXT
VkDescriptorMappingSourceConstantOffsetEXT
VkDescriptorMappingSourceHeapDataEXT
VkDescriptorMappingSourceIndirectAddressEXT
VkDescriptorMappingSourceIndirectIndexArrayEXT
VkDescriptorMappingSourceIndirectIndexEXT
VkDescriptorMappingSourcePushIndexEXT
VkDescriptorMappingSourceShaderRecordIndexEXT
VkDescriptorSetAndBindingMappingEXT
VkDeviceAddressRangeEXT
VkHostAddressRangeConstEXT
VkHostAddressRangeEXT
VkImageDescriptorInfoEXT
VkPushDataInfoEXT
VkResourceDescriptorInfoEXT
VkTensorViewCreateInfoARM
VkTexelBufferDescriptorInfoEXT
Extending
VkCommandBufferInheritanceInfo
VkCommandBufferInheritanceDescriptorHeapInfoEXT
Extending
VkImageCreateInfo
VkTensorCreateInfoARM
VkOpaqueCaptureDataCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorHeapFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorHeapPropertiesEXT
Extending
VkPipelineShaderStageCreateInfo
VkShaderCreateInfoEXT
VkShaderDescriptorSetAndBindingMappingInfoEXT
If
VK_ARM_tensors
is supported:
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorHeapTensorPropertiesARM
If
VK_EXT_custom_border_color
is supported:
Extending
VkSamplerCreateInfo
VkSamplerCustomBorderColorIndexCreateInfoEXT
If
VK_EXT_fragment_density_map
is supported:
Extending
VkImageFormatProperties2
VkSubsampledImageFormatPropertiesEXT
If
VK_NV_device_generated_commands
is supported:
Extending
VkIndirectCommandsLayoutTokenNV
VkIndirectCommandsLayoutPushDataTokenNV
New Unions
VkDescriptorMappingSourceDataEXT
VkResourceDescriptorDataEXT
New Enums
VkDescriptorMappingSourceEXT
VkSpirvResourceTypeFlagBitsEXT
New Bitmasks
VkSpirvResourceTypeFlagsEXT
VkTensorViewCreateFlagsARM
New Enum Constants
VK_EXT_DESCRIPTOR_HEAP_EXTENSION_NAME
VK_EXT_DESCRIPTOR_HEAP_SPEC_VERSION
Extending
VkAccessFlagBits2
VK_ACCESS_2_RESOURCE_HEAP_READ_BIT_EXT
VK_ACCESS_2_SAMPLER_HEAP_READ_BIT_EXT
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_DESCRIPTOR_HEAP_BIT_EXT
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_DESCRIPTOR_HEAP_BIT_EXT
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_DESCRIPTOR_HEAP_CAPTURE_REPLAY_BIT_EXT
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_DESCRIPTOR_HEAP_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_HEAP_INFO_EXT
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_DESCRIPTOR_HEAP_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_AND_BINDING_MAPPING_EXT
VK_STRUCTURE_TYPE_IMAGE_DESCRIPTOR_INFO_EXT
VK_STRUCTURE_TYPE_OPAQUE_CAPTURE_DATA_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_HEAP_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_HEAP_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PUSH_DATA_INFO_EXT
VK_STRUCTURE_TYPE_RESOURCE_DESCRIPTOR_INFO_EXT
VK_STRUCTURE_TYPE_SHADER_DESCRIPTOR_SET_AND_BINDING_MAPPING_INFO_EXT
VK_STRUCTURE_TYPE_TEXEL_BUFFER_DESCRIPTOR_INFO_EXT
If
VK_ARM_tensors
is supported:
Extending
VkSpirvResourceTypeFlagBitsEXT
VK_SPIRV_RESOURCE_TYPE_TENSOR_BIT_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_HEAP_TENSOR_PROPERTIES_ARM
Extending
VkTensorCreateFlagBitsARM
VK_TENSOR_CREATE_DESCRIPTOR_HEAP_CAPTURE_REPLAY_BIT_ARM
If
VK_EXT_custom_border_color
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_SAMPLER_CUSTOM_BORDER_COLOR_INDEX_CREATE_INFO_EXT
If
VK_EXT_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeEXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_PUSH_DATA_EXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_PUSH_DATA_SEQUENCE_INDEX_EXT
If
VK_EXT_fragment_density_map
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_SUBSAMPLED_IMAGE_FORMAT_PROPERTIES_EXT
If
VK_EXT_shader_object
is supported:
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_DESCRIPTOR_HEAP_BIT_EXT
If
VK_KHR_ray_tracing_pipeline
or
VK_NV_ray_tracing
is supported:
Extending
VkDescriptorMappingSourceEXT
VK_DESCRIPTOR_MAPPING_SOURCE_HEAP_WITH_SHADER_RECORD_INDEX_EXT
VK_DESCRIPTOR_MAPPING_SOURCE_SHADER_RECORD_ADDRESS_EXT
VK_DESCRIPTOR_MAPPING_SOURCE_SHADER_RECORD_DATA_EXT
Extending
VkSpirvResourceTypeFlagBitsEXT
VK_SPIRV_RESOURCE_TYPE_ACCELERATION_STRUCTURE_BIT_EXT
If
VK_NV_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeNV
VK_INDIRECT_COMMANDS_TOKEN_TYPE_PUSH_DATA_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_PUSH_DATA_TOKEN_NV
Version History
Revision 1, 2024-06-12 (Tobias Hector)
Initial revision.
VK_EXT_device_address_binding_report
Name String
VK_EXT_device_address_binding_report
Extension Type
Device extension
Registered Extension Number
355
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_debug_utils
Special Uses
Debugging tools
Developer tools
Contact
Ralph Potter
r_potter
Other Extension Metadata
Last Modified Date
2020-11-23
Interactions and External Dependencies
This extension requires
VK_EXT_debug_utils
Contributors
Ralph Potter, Samsung
Spencer Fricke, Samsung
Jan-Harald Fredriksen, ARM
Andrew Ellem, Google
Alex Walters, IMG
Jeff Bolz, NVIDIA
Description
This extension enables applications to track the binding of regions of the
GPU virtual address space, and to associate those regions with Vulkan
objects.
This extension is primarily intended to aid in crash postmortem, where
applications may wish to map a faulting GPU address to a Vulkan object.
For example, a page fault triggered by accessing an address located within a
region of the GPU virtual address space that was previously reported as
bound and then unbound may indicate a use-after-free error.
Similarly, faults generated by accessing virtual addresses outside the
limits of a bound region of GPU virtual address space may indicate indexing
beyond the bounds of a resource.
New Structures
Extending
VkDebugUtilsMessengerCallbackDataEXT
VkDeviceAddressBindingCallbackDataEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAddressBindingReportFeaturesEXT
New Enums
VkDeviceAddressBindingFlagBitsEXT
VkDeviceAddressBindingTypeEXT
New Bitmasks
VkDeviceAddressBindingFlagsEXT
New Enum Constants
VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_EXTENSION_NAME
VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_SPEC_VERSION
Extending
VkDebugUtilsMessageTypeFlagBitsEXT
VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_ADDRESS_BINDING_CALLBACK_DATA_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ADDRESS_BINDING_REPORT_FEATURES_EXT
Issues
1.) Should this extend VK_EXT_debug_utils or VK_EXT_device_memory_report?
RESOLVED
: Extend VK_EXT_debug_utils.
VK_EXT_device_memory_report focuses on memory allocations and would not
normally trigger callbacks in all of the situations where
VK_EXT_device_address_binding_report is expected to.
2.) Should this extension cover all Vulkan object types, or only resources
such as buffers and images?
RESOLVED
: The extension covers all Vulkan objects, and is not restricted
to objects backed by VkDeviceMemory objects.
3.) Should reallocation be identified explicitly, or as an unbind/bind pair?
RESOLVED
: Reallocation should be represented as an unbind/bind pair.
4.) Can multiple Vulkan objects share an overlapping virtual address range?
RESOLVED
: Yes.
This can be expected to occur due to resources aliasing.
5.) Can a single Vulkan object be associated with multiple virtual address
ranges concurrently?
RESOLVED
: Yes.
These should be reported via multiple calls to the reporting callback.
6.) Should the virtual address ranges associated with internal allocations
such as memory pools be reported?
RESOLVED
: Virtual address ranges associated with internal allocations
should only be reported when they become associated with a specific Vulkan
object.
In the case of internal pool allocations, a bind event should be reported
when resources from the pool are assigned to a Vulkan object, and an unbind
event should be reported when those resources are returned to the pool.
Implementations should not report the binding or unbinding of virtual
address ranges for which there are no related API objects visible to the
application developer.
7.) Can an implementation report binding a virtual address range at VkImage
or VkImageView creation, rather than in response to vkBindImageMemory?
RESOLVED
: Yes.
Virtual address range binding should be reported at the appropriate point at
which it occurs within the implementation.
This extension does not mandate when that should occur, and applications
should anticipate receiving callback events at any point after registering
callbacks.
8.) Can reporting of binding/unbinding be deferred until a resource is
referenced by an executing command buffer?
RESOLVED
: Changes to the virtual address ranges associated with a Vulkan
object should be reported as close as possible to where they occur within
the implementation.
If virtual address binding is deferred, then the callback should also be
deferred to match.
9.) Do bind/unbind callbacks have to form matched pairs? Can a large region
be bound, and then subregions unbound, resulting in fragmentation?
RESOLVED
: Splitting of virtual address regions, and unmatched bind/unbind
callbacks may occur.
Developers should anticipate that sparse memory may exhibit this behavior.
10.) The specification mandates that a callback
must
be triggered whenever
a GPU virtual address range associated with any Vulkan object is bound or
unbound.
Do we need queries or properties indicating which Vulkan objects will report
binding modifications?
RESOLVED
: No.
This extension is not intended to mandate how and when implementations bind
virtual ranges to objects.
Adding queries or properties would constrain implementations, which might
otherwise vary how virtual address bindings occur based on usage.
11.) Should vkAllocateMemory and vkFreeMemory trigger reporting callbacks?
RESOLVED
: If an implementation binds a GPU virtual address range when
vkAllocateMemory is called, then the callbacks must be triggered associating
the virtual address range with the VkDeviceMemory object.
If the device memory is subsequently bound to a buffer or image via
vkBind*Memory, the callbacks should be triggered a second time, reporting
the association between virtual address range and the buffer/image.
12.) Should binding reports be emitted for vkQueueBindSparse() operations?
RESOLVED
: binding reports for sparse objects are best effort, some
implementations might report events on vkQueueBindSparse() other
implementations might report events on sparse object creation/destruction.
Version History
Revision 1, 2020-09-23 (Ralph Potter)
Internal revisions
VK_EXT_device_generated_commands
Name String
VK_EXT_device_generated_commands
Extension Type
Device extension
Registered Extension Number
573
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
and
VK_KHR_maintenance5
or
Vulkan Version 1.3
API Interactions
Interacts with VK_EXT_shader_object
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_device_generated_commands
Other Extension Metadata
Last Modified Date
2024-02-23
Interactions and External Dependencies
This extension requires Vulkan 1.1
This extension requires
VK_EXT_buffer_device_address
or
VK_KHR_buffer_device_address
or Vulkan 1.2 for the ability to bind
vertex and index buffers on the device.
This extension requires
VK_KHR_maintenance5
for the ability to use
VkPipelineCreateFlags2KHR.
This extension interacts with
VK_NV_mesh_shader
If the latter extension is not supported, remove the command tokens to
initiate NV mesh tasks drawing in this extension.
This extension interacts with
VK_EXT_mesh_shader
If the latter extension is not supported, remove the command tokens to
initiate EXT mesh tasks drawing in this extension.
This extension interacts with
VK_KHR_ray_tracing_pipeline
If the latter extension is not supported, remove the command tokens to
initiate ray tracing in this extension.
This extension interacts with
VK_EXT_shader_object
If the latter extension is not supported, remove references to shader
objects in this extension.
Contributors
Mike Blumenkrantz, VALVE
Hans-Kristian Arntzen, VALVE
Jan-Harald Fredriksen, ARM
Spencer Fricke, LunarG
Ricardo Garcia, Igalia
Tobias Hector, AMD
Baldur Karlsson, VALVE
Christoph Kubisch, NVIDIA
Lionel Landwerlin, INTEL
Jon Leech, Khronos
Ting Wei, ARM
Ken Shanyi Zhang, AMD
Faith Ekstrand, Collabora
Vikram Kushwaha, NVIDIA
Connor Abbott, VALVE
Samuel Pitoiset, VALVE
Description
This extension allows the device to generate a number of commands for
command buffers.
It provides a subset of functionality from both
VK_NV_device_generated_commands
and
VK_NV_device_generated_commands_compute
as well as some new features.
When rendering a large number of objects, the device can be leveraged to
implement a number of critical functions, like updating matrices, or
implementing occlusion culling, frustum culling, front to back sorting, etc.
Implementing those on the device does not require any special extension,
since an application is free to define its own data structures, and just
process them using shaders.
To render objects which have been processed on the device, Vulkan has
several ways to perform indirect rendering, from the most basic
vkCmdDrawIndirect
with one indirect draw to
vkCmdDrawIndirectCount
which
supports multiple indirect draws batched together, with a way to determine
number of draws at device execution time.
However, if rendering state needs to change between the indirect draws, then
unextended Vulkan forces the application to speculatively record a
prohibitive number of redundant indirect commands covering all possible
state combinations -
which could end up processing nothing after culling -
or read back the processed stream and issue graphics command from the host.
For very large scenes, the synchronization overhead and cost to generate the
command buffer can become the bottleneck.
This extension allows an application to generate a device side stream of
state changes and commands, and convert it efficiently into a command buffer
without having to read it back to the host.
Furthermore, it allows incremental changes to such command buffers by
manipulating only partial sections of a command stream — for example
pipeline and shader object bindings.
Unextended Vulkan requires re-creation of entire command buffers in such a
scenario, or updates synchronized on the host.
The intended usage for this extension is for the application to:
create
VkBuffer
objects and retrieve physical addresses from them
via
vkGetBufferDeviceAddress
create a
VkIndirectExecutionSetEXT
for the ability to change
shaders on the device.
create a
VkIndirectCommandsLayoutEXT
, which lists the
VkIndirectCommandsTokenTypeEXT
it wants to dynamically execute as
an atomic command sequence.
This step likely involves some internal device code compilation, since
the intent is for the GPU to generate the command buffer based on the
layout.
fill the input stream buffers with the data for each of the inputs it
needs.
Each input is an array that will be filled with token-dependent data.
set up a preprocess
VkBuffer
that uses memory according to the
information retrieved via
vkGetGeneratedCommandsMemoryRequirementsEXT
optionally preprocess the generated content using
vkCmdPreprocessGeneratedCommandsEXT
, for example on an
asynchronous compute queue, or for the purpose of reusing the data in
multiple executions.
call
vkCmdExecuteGeneratedCommandsEXT
to create and execute the
actual device commands for all sequences based on the inputs provided.
For each draw in a sequence, the following can be specified:
a number of vertex buffer bindings
a different index buffer, with an optional dynamic offset and index type
a number of different push constants
updates to bound shader stages
For each dispatch in a sequence, the following can be specified:
a number of different push constants
updates to bound shader stages
For each trace rays in a sequence, the following can be specified:
a number of different push constants
updates to bound shader stages
While the GPU can be faster than a CPU to generate the commands, it will not
happen asynchronously to the device, therefore the primary use case is
generating “less” total work (occlusion culling, classification to use
specialized shaders, etc.).
New Object Types
VkIndirectCommandsLayoutEXT
VkIndirectExecutionSetEXT
New Commands
vkCmdExecuteGeneratedCommandsEXT
vkCmdPreprocessGeneratedCommandsEXT
vkCreateIndirectCommandsLayoutEXT
vkCreateIndirectExecutionSetEXT
vkDestroyIndirectCommandsLayoutEXT
vkDestroyIndirectExecutionSetEXT
vkGetGeneratedCommandsMemoryRequirementsEXT
vkUpdateIndirectExecutionSetPipelineEXT
vkUpdateIndirectExecutionSetShaderEXT
New Structures
VkBindIndexBufferIndirectCommandEXT
VkBindVertexBufferIndirectCommandEXT
VkDrawIndirectCountIndirectCommandEXT
VkGeneratedCommandsInfoEXT
VkGeneratedCommandsMemoryRequirementsInfoEXT
VkIndirectCommandsExecutionSetTokenEXT
VkIndirectCommandsIndexBufferTokenEXT
VkIndirectCommandsLayoutCreateInfoEXT
VkIndirectCommandsLayoutTokenEXT
VkIndirectCommandsPushConstantTokenEXT
VkIndirectCommandsVertexBufferTokenEXT
VkIndirectExecutionSetCreateInfoEXT
VkIndirectExecutionSetPipelineInfoEXT
VkIndirectExecutionSetShaderInfoEXT
VkIndirectExecutionSetShaderLayoutInfoEXT
VkWriteIndirectExecutionSetPipelineEXT
Extending
VkGeneratedCommandsInfoEXT
VkGeneratedCommandsMemoryRequirementsInfoEXT
VkGeneratedCommandsPipelineInfoEXT
VkGeneratedCommandsShaderInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDeviceGeneratedCommandsFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDeviceGeneratedCommandsPropertiesEXT
If
VK_EXT_shader_object
is supported:
VkWriteIndirectExecutionSetShaderEXT
New Unions
VkIndirectCommandsTokenDataEXT
VkIndirectExecutionSetInfoEXT
New Enums
VkIndirectCommandsInputModeFlagBitsEXT
VkIndirectCommandsLayoutUsageFlagBitsEXT
VkIndirectCommandsTokenTypeEXT
VkIndirectExecutionSetInfoTypeEXT
New Bitmasks
VkIndirectCommandsInputModeFlagsEXT
VkIndirectCommandsLayoutUsageFlagsEXT
New Enum Constants
VK_EXT_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME
VK_EXT_DEVICE_GENERATED_COMMANDS_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_EXT
VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_EXT
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_PREPROCESS_BUFFER_BIT_EXT
Extending
VkObjectType
VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_EXT
VK_OBJECT_TYPE_INDIRECT_EXECUTION_SET_EXT
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_INDIRECT_BINDABLE_BIT_EXT
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_EXT
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_INDIRECT_BINDABLE_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_EXT
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_EXT
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_PIPELINE_INFO_EXT
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_SHADER_INFO_EXT
VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_EXT
VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_PIPELINE_INFO_EXT
VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_SHADER_INFO_EXT
VK_STRUCTURE_TYPE_INDIRECT_EXECUTION_SET_SHADER_LAYOUT_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_EXT
VK_STRUCTURE_TYPE_WRITE_INDIRECT_EXECUTION_SET_PIPELINE_EXT
VK_STRUCTURE_TYPE_WRITE_INDIRECT_EXECUTION_SET_SHADER_EXT
Example Code
TODO
Version History
Revision 1, 2024-02-23 (Mike Blumenkrantz)
Initial version
VK_EXT_device_memory_report
Name String
VK_EXT_device_memory_report
Extension Type
Device extension
Registered Extension Number
285
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
Developer tools
Contact
Yiwei Zhang
zzyiwei
Other Extension Metadata
Last Modified Date
2021-01-06
IP Status
No known IP claims.
Contributors
Yiwei Zhang, Google
Jesse Hall, Google
Description
This device extension allows registration of device memory event callbacks
upon device creation, so that applications or middleware can obtain detailed
information about memory usage and how memory is associated with Vulkan
objects.
This extension exposes the actual underlying device memory usage, including
allocations that are not normally visible to the application, such as memory
consumed by
vkCreateGraphicsPipelines
It is intended primarily for use by debug tooling rather than for production
applications.
New Structures
VkDeviceMemoryReportCallbackDataEXT
Extending
VkDeviceCreateInfo
VkDeviceDeviceMemoryReportCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDeviceMemoryReportFeaturesEXT
New Function Pointers
PFN_vkDeviceMemoryReportCallbackEXT
New Enums
VkDeviceMemoryReportEventTypeEXT
New Bitmasks
VkDeviceMemoryReportFlagsEXT
New Enum Constants
VK_EXT_DEVICE_MEMORY_REPORT_EXTENSION_NAME
VK_EXT_DEVICE_MEMORY_REPORT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_DEVICE_MEMORY_REPORT_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_DEVICE_MEMORY_REPORT_CALLBACK_DATA_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_MEMORY_REPORT_FEATURES_EXT
Issues
1) Should this be better expressed as an extension to VK_EXT_debug_utils and
its general-purpose messenger construct?
RESOLVED
: No.
The intended lifecycle is quite different.
We want to make this extension tied to the device’s lifecycle.
Each ICD just handles its own implementation of this extension, and this
extension will only be directly exposed from the ICD.
So we can avoid the extra implementation complexity used to accommodate the
flexibility of
VK_EXT_debug_utils
extension.
2) Can we extend and use the existing internal allocation callbacks instead
of adding the new callback structure in this extension?
RESOLVED
: No.
Our memory reporting layer that combines this information with other memory
information it collects directly (e.g. bindings of resources to
VkDeviceMemory
) would have to intercept all entry points that take a
VkAllocationCallbacks
parameter and inject its own
pfnInternalAllocation
and
pfnInternalFree
That may be doable for the extensions we know about, but not for ones we do
not.
The proposal would work fine in the face of most unknown extensions.
But even for ones we know about, since apps can provide a different set of
callbacks and userdata and those can be retained by the driver and used
later (esp.
for pool object, but not just those), we would have to dynamically allocate
the interception trampoline every time.
That is getting to be an unreasonably large amount of complexity and
(possibly) overhead.
We are interested in both alloc/free and import/unimport.
The latter is fairly important for tracking (and avoiding double-counting)
of swapchain images (still true with “native swapchains” based on external
memory) and media/camera interop.
Though we might be able to handle this with additional
VkInternalAllocationType
values, for import/export we do want to be
able to tie this to the external resource, which is one thing that the
memoryObjectId
is for.
The internal alloc/free callbacks are not extensible except via new
VkInternalAllocationType
values.
The
VkDeviceMemoryReportCallbackDataEXT
in this extension is
extensible.
That was deliberate: there is a real possibility we will want to get extra
information in the future.
As one example, currently this reports only physical allocations, but we
believe there are interesting cases for tracking how populated that VA
region is.
The callbacks are clearly specified as only callable within the context of a
call from the application into Vulkan.
We believe there are some cases where drivers can allocate device memory
asynchronously.
This was one of the sticky issues that derailed the internal device memory
allocation reporting design (which is essentially what this extension is
trying to do) leading up to 1.0.
VkAllocationCallbacks
is described in a section called “Host memory”
and the intro to it is very explicitly about host memory.
The other callbacks are all inherently about host memory.
But this extension is very focused on device memory.
3) Should the callback be reporting which heap is used?
RESOLVED
: Yes.
It is important for non-UMA systems to have all the device memory
allocations attributed to the corresponding device memory heaps.
For internally-allocated device memory,
heapIndex
will always
correspond to an advertised heap, rather than having a magic value
indicating a non-advertised heap.
Drivers can advertise heaps that do not have any corresponding memory types
if they need to.
4) Should we use an array of callback for the layers to intercept instead of
chaining multiple of the
VkDeviceDeviceMemoryReportCreateInfoEXT
structures in the
pNext
of
VkDeviceCreateInfo
RESOLVED
No.
The pointer to the
VkDeviceDeviceMemoryReportCreateInfoEXT
structure
itself is const and you cannot just cast it away.
Thus we cannot update the callback array inside the structure.
In addition, we cannot drop this
pNext
chain either, so making a copy
of this whole structure does not work either.
5) Should we track bulk allocations shared among multiple objects?
RESOLVED
No.
Take the shader heap as an example.
Some implementations will let multiple
VkPipeline
objects share the
same shader heap.
We are not asking the implementation to report
VK_OBJECT_TYPE_PIPELINE
along with a
VK_NULL_HANDLE
for this bulk allocation.
Instead, this bulk allocation is considered as a layer below what this
extension is interested in.
Later, when the actual
VkPipeline
objects are created by suballocating
from the bulk allocation, we ask the implementation to report the valid
handles of the
VkPipeline
objects along with the actual suballocated
sizes and different
memoryObjectId
6) Can we require the callbacks to be always called in the same thread with
the Vulkan commands?
RESOLVED
No.
Some implementations might choose to multiplex work from multiple
application threads into a single backend thread and perform JIT allocations
as a part of that flow.
Since this behavior is theoretically legit, we cannot require the callbacks
to be always called in the same thread with the Vulkan commands, and the
note is to remind the applications to handle this case properly.
7) Should we add an additional “allocation failed” event type with things
like size and heap index reported?
RESOLVED
Yes.
This fits in well with the callback infrastructure added in this extension,
and implementation touches the same code and has the same overheads as the
rest of the extension.
It could help debugging things like getting a
VK_ERROR_OUT_OF_HOST_MEMORY
error when ending a command buffer.
Right now the allocation failure could have happened anywhere during
recording, and a callback would be really useful to understand where and
why.
Version History
Revision 1, 2020-08-26 (Yiwei Zhang)
Initial version
Revision 2, 2021-01-06 (Yiwei Zhang)
Minor description update
VK_EXT_direct_mode_display
Name String
VK_EXT_direct_mode_display
Extension Type
Instance extension
Registered Extension Number
89
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_display
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-12-13
IP Status
No known IP claims.
Contributors
Pierre Boudier, NVIDIA
James Jones, NVIDIA
Damien Leone, NVIDIA
Pierre-Loup Griffais, Valve
Liam Middlebrook, NVIDIA
Description
This is extension, along with related platform extensions, allows
applications to take exclusive control of displays associated with a native
windowing system.
This is especially useful for virtual reality applications that wish to hide
HMDs (head mounted displays) from the native platform’s display management
system, desktop, and/or other applications.
New Commands
vkReleaseDisplayEXT
New Enum Constants
VK_EXT_DIRECT_MODE_DISPLAY_EXTENSION_NAME
VK_EXT_DIRECT_MODE_DISPLAY_SPEC_VERSION
Issues
1) Should this extension and its related platform-specific extensions
leverage
VK_KHR_display
, or provide separate equivalent interfaces.
RESOLVED
: Use
VK_KHR_display
concepts and objects.
VK_KHR_display
can be used to enumerate all displays on the system,
including those attached to/in use by a window system or native platform,
but
VK_KHR_display_swapchain
will fail to create a swapchain on
in-use displays.
This extension and its platform-specific children will allow applications to
grab in-use displays away from window systems and/or native platforms,
allowing them to be used with
VK_KHR_display_swapchain
2) Are separate calls needed to acquire displays and enable direct mode?
RESOLVED
: No, these operations happen in one combined command.
Acquiring a display puts it into direct mode.
Version History
Revision 1, 2016-12-13 (James Jones)
Initial draft
VK_EXT_directfb_surface
Name String
VK_EXT_directfb_surface
Extension Type
Instance extension
Registered Extension Number
347
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Nicolas Caramelli
caramelli
Other Extension Metadata
Last Modified Date
2020-06-16
IP Status
No known IP claims.
Contributors
Nicolas Caramelli
Description
The
VK_EXT_directfb_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 DirectFB
IDirectFBSurface
, as well as a query to determine support for rendering
via DirectFB.
New Commands
vkCreateDirectFBSurfaceEXT
vkGetPhysicalDeviceDirectFBPresentationSupportEXT
New Structures
VkDirectFBSurfaceCreateInfoEXT
New Bitmasks
VkDirectFBSurfaceCreateFlagsEXT
New Enum Constants
VK_EXT_DIRECTFB_SURFACE_EXTENSION_NAME
VK_EXT_DIRECTFB_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DIRECTFB_SURFACE_CREATE_INFO_EXT
Version History
Revision 1, 2020-06-16 (Nicolas Caramelli)
Initial version
VK_EXT_discard_rectangles
Name String
VK_EXT_discard_rectangles
Extension Type
Device extension
Registered Extension Number
100
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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
of this extension.
New Commands
vkCmdSetDiscardRectangleEXT
vkCmdSetDiscardRectangleEnableEXT
vkCmdSetDiscardRectangleModeEXT
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkPipelineDiscardRectangleStateCreateInfoEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDiscardRectanglePropertiesEXT
New Enums
VkDiscardRectangleModeEXT
New Bitmasks
VkPipelineDiscardRectangleStateCreateFlagsEXT
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
Version History
Revision 2, 2023-01-18 (Piers Daniell)
Add dynamic states for discard rectangle enable/disable and mode.
Revision 1, 2016-12-22 (Piers Daniell)
Internal revisions
VK_EXT_display_control
Name String
VK_EXT_display_control
Extension Type
Device extension
Registered Extension Number
92
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_display_surface_counter
and
VK_KHR_swapchain
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-12-13
IP Status
No known IP claims.
Contributors
Pierre Boudier, NVIDIA
James Jones, NVIDIA
Damien Leone, NVIDIA
Pierre-Loup Griffais, Valve
Daniel Vetter, Intel
Description
This extension defines a set of utility functions for use with the
VK_KHR_display
and
VK_KHR_display_swapchain
extensions.
New Commands
vkDisplayPowerControlEXT
vkGetSwapchainCounterEXT
vkRegisterDeviceEventEXT
vkRegisterDisplayEventEXT
New Structures
VkDeviceEventInfoEXT
VkDisplayEventInfoEXT
VkDisplayPowerInfoEXT
Extending
VkSwapchainCreateInfoKHR
VkSwapchainCounterCreateInfoEXT
New Enums
VkDeviceEventTypeEXT
VkDisplayEventTypeEXT
VkDisplayPowerStateEXT
New Enum Constants
VK_EXT_DISPLAY_CONTROL_EXTENSION_NAME
VK_EXT_DISPLAY_CONTROL_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_EVENT_INFO_EXT
VK_STRUCTURE_TYPE_DISPLAY_EVENT_INFO_EXT
VK_STRUCTURE_TYPE_DISPLAY_POWER_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_COUNTER_CREATE_INFO_EXT
Issues
1) Should this extension add an explicit “WaitForVsync” API or a fence
signaled at vsync that the application can wait on?
RESOLVED
: A fence.
A separate API could later be provided that allows exporting the fence to a
native object that could be inserted into standard run loops on POSIX and
Windows systems.
2) Should callbacks be added for a vsync event, or in general to monitor
events in Vulkan?
RESOLVED
: No, fences should be used.
Some events are generated by interrupts which are managed in the kernel.
In order to use a callback provided by the application, drivers would need
to have the userspace driver spawn threads that would wait on the kernel
event, and hence the callbacks could be difficult for the application to
synchronize with its other work given they would arrive on a foreign thread.
3) Should vblank or scanline events be exposed?
RESOLVED
: Vblank events.
Scanline events could be added by a separate extension, but the latency of
processing an interrupt and waking up a userspace event is high enough that
the accuracy of a scanline event would be rather low.
Further, per-scanline interrupts are not supported by all hardware.
Version History
Revision 1, 2016-12-13 (James Jones)
Initial draft
VK_EXT_display_surface_counter
Name String
VK_EXT_display_surface_counter
Extension Type
Instance extension
Registered Extension Number
91
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_display
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-12-13
IP Status
No known IP claims.
Contributors
Pierre Boudier, NVIDIA
James Jones, NVIDIA
Damien Leone, NVIDIA
Pierre-Loup Griffais, Valve
Daniel Vetter, Intel
Description
This extension defines a vertical blanking period counter associated with
display surfaces.
It provides a mechanism to query support for such a counter from a
VkSurfaceKHR
object.
New Commands
vkGetPhysicalDeviceSurfaceCapabilities2EXT
New Structures
VkSurfaceCapabilities2EXT
New Enums
VkSurfaceCounterFlagBitsEXT
New Bitmasks
VkSurfaceCounterFlagsEXT
New Enum Constants
VK_EXT_DISPLAY_SURFACE_COUNTER_EXTENSION_NAME
VK_EXT_DISPLAY_SURFACE_COUNTER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT
Version History
Revision 1, 2016-12-13 (James Jones)
Initial draft
VK_EXT_dynamic_rendering_unused_attachments
Name String
VK_EXT_dynamic_rendering_unused_attachments
Extension Type
Device extension
Registered Extension Number
500
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
Contact
Piers Daniell
pdaniell-nv
Extension Proposal
VK_EXT_dynamic_rendering_unused_attachments
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDynamicRenderingUnusedAttachmentsFeaturesEXT
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
Issues
None.
Version History
Revision 1, 2023-05-22 (Piers Daniell)
Internal revisions
VK_EXT_extended_dynamic_state3
Name String
VK_EXT_extended_dynamic_state3
Extension Type
Device extension
Registered Extension Number
456
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3AlphaToOneEnable
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3DepthClampEnable
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3LogicOpEnable
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3PolygonMode
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3RasterizationStream
Interacts with VkPhysicalDeviceExtendedDynamicState3FeaturesEXT::extendedDynamicState3TessellationDomainOrigin
Contact
Piers Daniell
pdaniell-nv
Extension Proposal
VK_EXT_extended_dynamic_state3
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
vkCmdSetAlphaToCoverageEnableEXT
vkCmdSetAlphaToOneEnableEXT
vkCmdSetColorBlendEnableEXT
vkCmdSetColorBlendEquationEXT
vkCmdSetColorWriteMaskEXT
vkCmdSetDepthClampEnableEXT
vkCmdSetLogicOpEnableEXT
vkCmdSetPolygonModeEXT
vkCmdSetRasterizationSamplesEXT
vkCmdSetSampleMaskEXT
If
VK_EXT_blend_operation_advanced
is supported:
vkCmdSetColorBlendAdvancedEXT
If
VK_EXT_conservative_rasterization
is supported:
vkCmdSetConservativeRasterizationModeEXT
vkCmdSetExtraPrimitiveOverestimationSizeEXT
If
VK_EXT_depth_clip_control
is supported:
vkCmdSetDepthClipNegativeOneToOneEXT
If
VK_EXT_depth_clip_enable
is supported:
vkCmdSetDepthClipEnableEXT
If
VK_EXT_line_rasterization
is supported:
vkCmdSetLineRasterizationModeEXT
vkCmdSetLineStippleEnableEXT
If
VK_EXT_provoking_vertex
is supported:
vkCmdSetProvokingVertexModeEXT
If
VK_EXT_sample_locations
is supported:
vkCmdSetSampleLocationsEnableEXT
If
VK_EXT_transform_feedback
is supported:
vkCmdSetRasterizationStreamEXT
If
VK_KHR_maintenance2
or
Vulkan Version 1.1
is supported:
vkCmdSetTessellationDomainOriginEXT
If
VK_NV_clip_space_w_scaling
is supported:
vkCmdSetViewportWScalingEnableNV
If
VK_NV_coverage_reduction_mode
is supported:
vkCmdSetCoverageReductionModeNV
If
VK_NV_fragment_coverage_to_color
is supported:
vkCmdSetCoverageToColorEnableNV
vkCmdSetCoverageToColorLocationNV
If
VK_NV_framebuffer_mixed_samples
is supported:
vkCmdSetCoverageModulationModeNV
vkCmdSetCoverageModulationTableEnableNV
vkCmdSetCoverageModulationTableNV
If
VK_NV_representative_fragment_test
is supported:
vkCmdSetRepresentativeFragmentTestEnableNV
If
VK_NV_shading_rate_image
is supported:
vkCmdSetShadingRateImageEnableNV
If
VK_NV_viewport_swizzle
is supported:
vkCmdSetViewportSwizzleNV
New Structures
VkColorBlendAdvancedEXT
VkColorBlendEquationEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExtendedDynamicState3FeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceExtendedDynamicState3PropertiesEXT
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_blend_operation_advanced
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_COLOR_BLEND_ADVANCED_EXT
If
VK_EXT_conservative_rasterization
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_CONSERVATIVE_RASTERIZATION_MODE_EXT
VK_DYNAMIC_STATE_EXTRA_PRIMITIVE_OVERESTIMATION_SIZE_EXT
If
VK_EXT_depth_clip_control
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_DEPTH_CLIP_NEGATIVE_ONE_TO_ONE_EXT
If
VK_EXT_depth_clip_enable
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_DEPTH_CLIP_ENABLE_EXT
If
VK_EXT_line_rasterization
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT
VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT
If
VK_EXT_provoking_vertex
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_PROVOKING_VERTEX_MODE_EXT
If
VK_EXT_sample_locations
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_ENABLE_EXT
If
VK_EXT_transform_feedback
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_RASTERIZATION_STREAM_EXT
If
VK_KHR_maintenance2
or
Vulkan Version 1.1
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT
If
VK_NV_clip_space_w_scaling
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_ENABLE_NV
If
VK_NV_coverage_reduction_mode
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_COVERAGE_REDUCTION_MODE_NV
If
VK_NV_fragment_coverage_to_color
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_ENABLE_NV
VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_LOCATION_NV
If
VK_NV_framebuffer_mixed_samples
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_COVERAGE_MODULATION_MODE_NV
VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_ENABLE_NV
VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_NV
If
VK_NV_representative_fragment_test
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_REPRESENTATIVE_FRAGMENT_TEST_ENABLE_NV
If
VK_NV_shading_rate_image
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_SHADING_RATE_IMAGE_ENABLE_NV
If
VK_NV_viewport_swizzle
is supported:
Extending
VkDynamicState
VK_DYNAMIC_STATE_VIEWPORT_SWIZZLE_NV
Issues
1) What about the VkPipelineMultisampleStateCreateInfo state
sampleShadingEnable
and
minSampleShading
sampleShadingEnable
and
minSampleShading
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.
Version History
Revision 2, 2022-07-18 (Piers Daniell)
Added rasterizationSamples
Revision 1, 2022-05-18 (Piers Daniell)
Internal revisions
VK_EXT_external_memory_acquire_unmodified
Name String
VK_EXT_external_memory_acquire_unmodified
Extension Type
Device extension
Registered Extension Number
454
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
James Jones
cubanismo
Extension Proposal
VK_EXT_external_memory_acquire_unmodified
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 Structures
Extending
VkBufferMemoryBarrier
VkBufferMemoryBarrier2
VkImageMemoryBarrier
VkImageMemoryBarrier2
VkExternalMemoryAcquireUnmodifiedEXT
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
Version History
Revision 1, 2023-03-09 (Lina Versace)
Initial revision
VK_EXT_external_memory_dma_buf
Name String
VK_EXT_external_memory_dma_buf
Extension Type
Device extension
Registered Extension Number
126
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory_fd
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2017-10-10
IP Status
No known IP claims.
Contributors
Lina Versace, Google
James Jones, NVIDIA
Faith Ekstrand, Intel
Description
dma_buf
is a type of file descriptor, defined by the Linux kernel,
that allows sharing memory across kernel device drivers and across
processes.
This extension enables applications to import a
dma_buf
as
VkDeviceMemory
, to export
VkDeviceMemory
as a
dma_buf
, and
to create
VkBuffer
objects that
can
be bound to that memory.
New Enum Constants
VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME
VK_EXT_EXTERNAL_MEMORY_DMA_BUF_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
Issues
1) How does the application, when creating a
VkImage
that it intends
to bind to
dma_buf
VkDeviceMemory
containing an externally
produced image, specify the memory layout (such as row pitch and DRM format
modifier) of the
VkImage
? In other words, how does the application
achieve behavior comparable to that provided by
EGL_EXT_image_dma_buf_import
and
EGL_EXT_image_dma_buf_import_modifiers
RESOLVED
: Features comparable to those in
EGL_EXT_image_dma_buf_import
and
EGL_EXT_image_dma_buf_import_modifiers
will be provided by an extension layered atop this one.
2) Without the ability to specify the memory layout of external
dma_buf
images, how is this extension useful?
RESOLVED
: This extension provides exactly one new feature: the ability to
import/export between
dma_buf
and
VkDeviceMemory
This feature, together with features provided by
VK_KHR_external_memory_fd
, is sufficient to bind a
VkBuffer
to
dma_buf
Version History
Revision 1, 2017-10-10 (Lina Versace)
Squashed internal revisions
VK_EXT_external_memory_host
Name String
VK_EXT_external_memory_host
Extension Type
Device extension
Registered Extension Number
179
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2017-11-10
IP Status
No known IP claims.
Contributors
Jaakko Konttinen, AMD
David Mao, AMD
Daniel Rakos, AMD
Tobias Hector, Imagination Technologies
Faith Ekstrand, Intel
James Jones, NVIDIA
Description
This extension enables an application to import host allocations and host
mapped foreign device memory to Vulkan memory objects.
New Commands
vkGetMemoryHostPointerPropertiesEXT
New Structures
VkMemoryHostPointerPropertiesEXT
Extending
VkMemoryAllocateInfo
VkImportMemoryHostPointerInfoEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceExternalMemoryHostPropertiesEXT
New Enum Constants
VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME
VK_EXT_EXTERNAL_MEMORY_HOST_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT
VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT
VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT
Issues
1) What memory type has to be used to import host pointers?
RESOLVED
: Depends on the implementation.
Applications have to use the new
vkGetMemoryHostPointerPropertiesEXT
command to query the supported memory types for a particular host pointer.
The reported memory types may include memory types that come from a memory
heap that is otherwise not usable for regular memory object allocation and
thus such a heap’s size may be zero.
2) Can the application still access the contents of the host allocation
after importing?
RESOLVED
: Yes.
However, usual synchronization requirements apply.
3) Can the application free the host allocation?
RESOLVED
: No, it violates valid usage conditions.
Using the memory object imported from a host allocation that is already
freed thus results in
undefined
behavior.
4) Is
vkMapMemory
expected to return the same host address which was
specified when importing it to the memory object?
RESOLVED
: No.
Implementations are allowed to return the same address but it is not
required.
Some implementations might return a different virtual mapping of the
allocation, although the same physical pages will be used.
5) Is there any limitation on the alignment of the host pointer and/or size?
RESOLVED
: Yes.
Both the address and the size have to be an integer multiple of
minImportedHostPointerAlignment
In addition, some platforms and foreign devices may have additional
restrictions.
6) Can the same host allocation be imported multiple times into a given
physical device?
RESOLVED
: No, at least not guaranteed by this extension.
Some platforms do not allow locking the same physical pages for device
access multiple times, so attempting to do it may result in
undefined
behavior.
7) Does this extension support exporting the new handle type?
RESOLVED
: No.
8) Should we include the possibility to import host mapped foreign device
memory using this API?
RESOLVED
: Yes, through a separate handle type.
Implementations are still allowed to support only one of the handle types
introduced by this extension by not returning import support for a
particular handle type as returned in
VkExternalMemoryPropertiesKHR
Version History
Revision 1, 2017-11-10 (Daniel Rakos)
Internal revisions
VK_EXT_external_memory_metal
Name String
VK_EXT_external_memory_metal
Extension Type
Device extension
Registered Extension Number
603
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
Aitor Camacho Larrondo
aitor-lunarg
Extension Proposal
VK_EXT_external_memory_metal
Other Extension Metadata
Last Modified Date
2024-07-18
IP Status
No known IP claims.
Contributors
Aitor Camacho Larrondo, LunarG Inc.
Description
An application may wish to reference device memory in multiple Vulkan device
instances, in multiple processes, and/or in Metal API.
This extension enables an application to export and import Metal handles
from Vulkan memory objects such that the underlying resources can be
referenced outside the scope of the Vulkan device instance that created
them.
New Commands
vkGetMemoryMetalHandleEXT
vkGetMemoryMetalHandlePropertiesEXT
New Structures
VkMemoryGetMetalHandleInfoEXT
VkMemoryMetalHandlePropertiesEXT
Extending
VkMemoryAllocateInfo
VkImportMemoryMetalHandleInfoEXT
New Enum Constants
VK_EXT_EXTERNAL_MEMORY_METAL_EXTENSION_NAME
VK_EXT_EXTERNAL_MEMORY_METAL_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT
VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT
VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMPORT_MEMORY_METAL_HANDLE_INFO_EXT
VK_STRUCTURE_TYPE_MEMORY_GET_METAL_HANDLE_INFO_EXT
VK_STRUCTURE_TYPE_MEMORY_METAL_HANDLE_PROPERTIES_EXT
Version History
Revision 1, 2024-07-18 (Aitor Camacho Larrondo)
Initial revision
VK_EXT_filter_cubic
Name String
VK_EXT_filter_cubic
Extension Type
Device extension
Registered Extension Number
171
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2019-12-13
Contributors
Bill Licea-Kane, Qualcomm Technologies, Inc.
Andrew Garrard, Samsung
Daniel Koch, NVIDIA
Donald Scorgie, Imagination Technologies
Graeme Leese, Broadcom
Jan-Harald Fredriksen, ARM
Jeff Leger, Qualcomm Technologies, Inc.
Tobias Hector, AMD
Tom Olson, ARM
Stuart Smith, Imagination Technologies
Description
VK_EXT_filter_cubic
extends
VK_IMG_filter_cubic
It documents cubic filtering of other image view types.
It adds new structures that
can
be added to the
pNext
chain of
VkPhysicalDeviceImageFormatInfo2
and
VkImageFormatProperties2
that
can
be used to determine which image types and which image view types
support cubic filtering.
New Structures
Extending
VkImageFormatProperties2
VkFilterCubicImageViewImageFormatPropertiesEXT
Extending
VkPhysicalDeviceImageFormatInfo2
VkPhysicalDeviceImageViewImageFormatInfoEXT
New Enum Constants
VK_EXT_FILTER_CUBIC_EXTENSION_NAME
VK_EXT_FILTER_CUBIC_SPEC_VERSION
Extending
VkFilter
VK_FILTER_CUBIC_EXT
Extending
VkFormatFeatureFlagBits
VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_FILTER_CUBIC_IMAGE_VIEW_IMAGE_FORMAT_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_IMAGE_FORMAT_INFO_EXT
Version History
Revision 3, 2019-12-13 (wwlk)
Delete requirement to cubic filter the formats USCALED_PACKED32,
SSCALED_PACKED32, UINT_PACK32, and SINT_PACK32 (cut/paste error)
Revision 2, 2019-06-05 (wwlk)
Clarify 1D optional
Revision 1, 2019-01-24 (wwlk)
Initial version
VK_EXT_fragment_density_map
Name String
VK_EXT_fragment_density_map
Extension Type
Device extension
Registered Extension Number
219
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Interacts with VK_KHR_format_feature_flags2
SPIR-V Dependencies
SPV_EXT_fragment_invocation_density
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2025-05-20
Interactions and External Dependencies
This extension provides API support for
GL_EXT_fragment_invocation_density
Contributors
Matthew Netsch, Qualcomm Technologies, Inc.
Robert VanReenen, Qualcomm Technologies, Inc.
Jonathan Wicks, Qualcomm Technologies, Inc.
Tate Hornbeck, Qualcomm Technologies, Inc.
Sam Holmes, Qualcomm Technologies, Inc.
Jeff Leger, Qualcomm Technologies, Inc.
Jan-Harald Fredriksen, ARM
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
Daniel Rakos, AMD
Piers Daniell, NVIDIA
Description
This extension allows an application to specify areas of the render target
where the fragment shader may be invoked fewer times.
These fragments are broadcasted out to multiple pixels to cover the render
target.
The primary use of this extension is to reduce workloads in areas where
lower quality may not be perceived such as the distorted edges of a lens or
the periphery of a user’s gaze.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentDensityMapFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentDensityMapPropertiesEXT
Extending
VkRenderPassCreateInfo
VkRenderPassCreateInfo2
VkRenderPassFragmentDensityMapCreateInfoEXT
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkRenderingInfo
VkRenderingFragmentDensityMapAttachmentInfoEXT
New Enum Constants
VK_EXT_FRAGMENT_DENSITY_MAP_EXTENSION_NAME
VK_EXT_FRAGMENT_DENSITY_MAP_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_FRAGMENT_DENSITY_MAP_READ_BIT_EXT
Extending
VkFormatFeatureFlagBits
VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_SUBSAMPLED_BIT_EXT
Extending
VkImageLayout
VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT
Extending
VkImageViewCreateFlagBits
VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DYNAMIC_BIT_EXT
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT
Extending
VkSamplerCreateFlagBits
VK_SAMPLER_CREATE_SUBSAMPLED_BIT_EXT
VK_SAMPLER_CREATE_SUBSAMPLED_COARSE_RECONSTRUCTION_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIES_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXT
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT
VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_INFO_EXT
New or Modified Built-In Variables
FragInvocationCountEXT
FragSizeEXT
New SPIR-V Capabilities
FragmentDensityEXT
Version History
Revision 1, 2018-09-25 (Matthew Netsch)
Initial version
Revision 2, 2021-09-30 (Jon Leech)
Add interaction with
VK_KHR_format_feature_flags2
to
vk.xml
Revision 3, 2025-05-20 (Matthew Netsch)
Fixes fragmentDensityTexelSize calculation equation
VK_EXT_fragment_density_map2
Name String
VK_EXT_fragment_density_map2
Extension Type
Device extension
Registered Extension Number
333
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_fragment_density_map
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2020-06-16
Interactions and External Dependencies
Interacts with Vulkan 1.1
Contributors
Matthew Netsch, Qualcomm Technologies, Inc.
Jonathan Tinkham, Qualcomm Technologies, Inc.
Jonathan Wicks, Qualcomm Technologies, Inc.
Jan-Harald Fredriksen, ARM
Description
This extension adds additional features and properties to
VK_EXT_fragment_density_map
in order to reduce fragment density map
host latency as well as improved queries for subsampled sampler
implementation-dependent behavior.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentDensityMap2FeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentDensityMap2PropertiesEXT
New Enum Constants
VK_EXT_FRAGMENT_DENSITY_MAP_2_EXTENSION_NAME
VK_EXT_FRAGMENT_DENSITY_MAP_2_SPEC_VERSION
Extending
VkImageViewCreateFlagBits
VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DEFERRED_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_PROPERTIES_EXT
Version History
Revision 1, 2020-06-16 (Matthew Netsch)
Initial version
VK_EXT_fragment_density_map_offset
Name String
VK_EXT_fragment_density_map_offset
Extension Type
Device extension
Registered Extension Number
620
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_fragment_density_map
and
VK_KHR_create_renderpass2
or
Vulkan Version 1.2
and
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
Contact
Connor Abbott
cwabbott0
Extension Proposal
VK_EXT_fragment_density_map_offset
Other Extension Metadata
Last Modified Date
2025-02-14
Contributors
Connor Abbott, Valve Corporation
Matthew Netsch, Qualcomm Technologies, Inc.
Jonathan Wicks, Qualcomm Technologies, Inc.
Jonathan Tinkham, Qualcomm Technologies, Inc.
Jeff Leger, Qualcomm Technologies, Inc.
Manan Katwala, Qualcomm Technologies, Inc.
Mike Blumenkrantz, Valve Corporation
Description
This extension allows an application to specify offsets to a fragment
density map attachment, changing the framebuffer location where density
values are applied to without having to regenerate the fragment density map.
New Commands
vkCmdEndRendering2EXT
New Structures
VkRenderingEndInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentDensityMapOffsetFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentDensityMapOffsetPropertiesEXT
Extending
VkSubpassEndInfo
VkRenderingEndInfoKHR
VkRenderPassFragmentDensityMapOffsetEndInfoEXT
New Enum Constants
VK_EXT_FRAGMENT_DENSITY_MAP_OFFSET_EXTENSION_NAME
VK_EXT_FRAGMENT_DENSITY_MAP_OFFSET_SPEC_VERSION
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_PROPERTIES_EXT
VK_STRUCTURE_TYPE_RENDERING_END_INFO_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_EXT
Version History
Revision 1, 2025-02-14 (Connor Abbott)
Initial version
VK_EXT_fragment_shader_interlock
Name String
VK_EXT_fragment_shader_interlock
Extension Type
Device extension
Registered Extension Number
252
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_fragment_shader_interlock
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2019-05-02
Interactions and External Dependencies
This extension provides API support for
GL_ARB_fragment_shader_interlock
Contributors
Daniel Koch, NVIDIA
Graeme Leese, Broadcom
Jan-Harald Fredriksen, Arm
Faith Ekstrand, Intel
Jeff Bolz, NVIDIA
Ruihao Zhang, Qualcomm
Slawomir Grajewski, Intel
Spencer Fricke, Samsung
Description
This extension adds support for the
FragmentShaderPixelInterlockEXT
FragmentShaderSampleInterlockEXT
, and
FragmentShaderShadingRateInterlockEXT
capabilities from the
SPV_EXT_fragment_shader_interlock
extension to Vulkan.
Enabling these capabilities provides a critical section for fragment shaders
to avoid overlapping pixels being processed at the same time, and certain
guarantees about the ordering of fragment shader invocations of fragments of
overlapping pixels.
This extension can be useful for algorithms that need to access per-pixel
data structures via shader loads and stores.
Algorithms using this extension can access per-pixel data structures in
critical sections without other invocations accessing the same per-pixel
data.
Additionally, the ordering guarantees are useful for cases where the API
ordering of fragments is meaningful.
For example, applications may be able to execute programmable blending
operations in the fragment shader, where the destination buffer is read via
image loads and the final value is written via image stores.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentShaderInterlockFeaturesEXT
New Enum Constants
VK_EXT_FRAGMENT_SHADER_INTERLOCK_EXTENSION_NAME
VK_EXT_FRAGMENT_SHADER_INTERLOCK_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_INTERLOCK_FEATURES_EXT
New SPIR-V Capabilities
FragmentShaderInterlockEXT
FragmentShaderPixelInterlockEXT
FragmentShaderShadingRateInterlockEXT
Version History
Revision 1, 2019-05-24 (Piers Daniell)
Internal revisions
VK_EXT_frame_boundary
Name String
VK_EXT_frame_boundary
Extension Type
Device extension
Registered Extension Number
376
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
James Fitzpatrick
jamesfitzpatrick
Extension Proposal
VK_EXT_frame_boundary
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFrameBoundaryFeaturesEXT
Extending
VkSubmitInfo
VkSubmitInfo2
VkPresentInfoKHR
VkBindSparseInfo
VkFrameBoundaryEXT
New Enums
VkFrameBoundaryFlagBitsEXT
New Bitmasks
VkFrameBoundaryFlagsEXT
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
Version History
Revision 0, 2022-01-14 (Hugues Evard)
Initial proposal
Revision 1, 2023-06-14 (James Fitzpatrick)
Initial draft
VK_EXT_full_screen_exclusive
Name String
VK_EXT_full_screen_exclusive
Extension Type
Device extension
Registered Extension Number
256
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_surface
and
VK_KHR_get_surface_capabilities2
and
VK_KHR_swapchain
API Interactions
Interacts with VK_VERSION_1_1
Interacts with VK_KHR_device_group
Interacts with VK_KHR_win32_surface
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2019-03-12
IP Status
No known IP claims.
Interactions and External Dependencies
Interacts with Vulkan 1.1
Interacts with
VK_KHR_device_group
Interacts with
VK_KHR_win32_surface
Contributors
Hans-Kristian Arntzen, ARM
Slawomir Grajewski, Intel
Tobias Hector, AMD
James Jones, NVIDIA
Daniel Rakos, AMD
Jeff Juliano, NVIDIA
Joshua Schnarr, NVIDIA
Aaron Hagan, AMD
Description
This extension allows applications to set the policy for swapchain creation
and presentation mechanisms relating to full-screen access.
Implementations may be able to acquire exclusive access to a particular
display for an application window that covers the whole screen.
This can increase performance on some systems by bypassing composition,
however it can also result in disruptive or expensive transitions in the
underlying windowing system when a change occurs.
Applications can choose between explicitly disallowing or allowing this
behavior, letting the implementation decide, or managing this mode of
operation directly using the new
vkAcquireFullScreenExclusiveModeEXT
and
vkReleaseFullScreenExclusiveModeEXT
commands.
New Commands
vkAcquireFullScreenExclusiveModeEXT
vkGetPhysicalDeviceSurfacePresentModes2EXT
vkReleaseFullScreenExclusiveModeEXT
If
VK_KHR_device_group
or
Vulkan Version 1.1
is supported:
vkGetDeviceGroupSurfacePresentModes2EXT
New Structures
Extending
VkPhysicalDeviceSurfaceInfo2KHR
VkSwapchainCreateInfoKHR
VkSurfaceFullScreenExclusiveInfoEXT
Extending
VkSurfaceCapabilities2KHR
VkSurfaceCapabilitiesFullScreenExclusiveEXT
If
VK_KHR_win32_surface
is supported:
Extending
VkPhysicalDeviceSurfaceInfo2KHR
VkSwapchainCreateInfoKHR
VkSurfaceFullScreenExclusiveWin32InfoEXT
New Enums
VkFullScreenExclusiveEXT
New Enum Constants
VK_EXT_FULL_SCREEN_EXCLUSIVE_EXTENSION_NAME
VK_EXT_FULL_SCREEN_EXCLUSIVE_SPEC_VERSION
Extending
VkResult
VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_FULL_SCREEN_EXCLUSIVE_EXT
VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_INFO_EXT
If
VK_KHR_win32_surface
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_WIN32_INFO_EXT
Issues
1) What should the extension & flag be called?
RESOLVED
: VK_EXT_full_screen_exclusive.
Other options considered (prior to the app-controlled mode) were:
VK_EXT_smooth_fullscreen_transition
VK_EXT_fullscreen_behavior
VK_EXT_fullscreen_preference
VK_EXT_fullscreen_hint
VK_EXT_fast_fullscreen_transition
VK_EXT_avoid_fullscreen_exclusive
2) Do we need more than a boolean toggle?
RESOLVED
: Yes.
Using an enum with default/allowed/disallowed/app-controlled enables
applications to accept driver default behavior, specifically override it in
either direction without implying the driver is ever required to use
full-screen exclusive mechanisms, or manage this mode explicitly.
3) Should this be a KHR or EXT extension?
RESOLVED
: EXT, in order to allow it to be shipped faster.
4) Can the fullscreen hint affect the surface capabilities, and if so,
should the hint also be specified as input when querying the surface
capabilities?
RESOLVED
: Yes on both accounts.
While the hint does not guarantee a particular fullscreen mode will be used
when the swapchain is created, it can sometimes imply particular modes will
NOT be used.
If the driver determines that it will opt-out of using a particular mode
based on the policy, and knows it can only support certain capabilities if
that mode is used, it would be confusing at best to the application to
report those capabilities in such cases.
Not allowing implementations to report this state to applications could
result in situations where applications are unable to determine why
swapchain creation fails when they specify certain hint values, which could
result in never- terminating surface creation loops.
5) Should full-screen be one word or two?
RESOLVED
: Two words.
"Fullscreen" is not in my dictionary, and web searches did not turn up
definitive proof that it is a colloquially accepted compound word.
Documentation for the corresponding Windows API mechanisms dithers.
The text consistently uses a hyphen, but none-the-less, there is a
SetFullscreenState method in the DXGI swapchain object.
Given this inconclusive external guidance, it is best to adhere to the
Vulkan style guidelines and avoid inventing new compound words.
Version History
Revision 4, 2019-03-12 (Tobias Hector)
Added application-controlled mode, and related functions
Tidied up appendix
Revision 3, 2019-01-03 (James Jones)
Renamed to VK_EXT_full_screen_exclusive
Made related adjustments to the tri-state enumerant names.
Revision 2, 2018-11-27 (James Jones)
Renamed to VK_KHR_fullscreen_behavior
Switched from boolean flag to tri-state enum
Revision 1, 2018-11-06 (James Jones)
Internal revision
VK_EXT_graphics_pipeline_library
Name String
VK_EXT_graphics_pipeline_library
Extension Type
Device extension
Registered Extension Number
321
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_pipeline_library
Contact
Tobias Hector
tobski
Extension Proposal
VK_EXT_graphics_pipeline_library
Other Extension Metadata
Last Modified Date
2021-08-17
Contributors
Tobias Hector, AMD
Chris Glover, Google
Jeff Leger, Qualcomm
Jan-Harald Fredriksen, Arm
Piers Daniell, NVidia
Boris Zanin, Mobica
Krzysztof Niski, NVidia
Dan Ginsburg, Valve
Sebastian Aaltonen, Unity
Arseny Kapoulkine, Roblox
Calle Lejdfors, Ubisoft
Tiago Rodrigues, Ubisoft
Francois Duranleau, Gameloft
Description
This extension allows the separate compilation of four distinct parts of
graphics pipelines, with the intent of allowing faster pipeline loading for
applications reusing the same shaders or state in multiple pipelines.
Each part can be independently compiled into a graphics pipeline library,
with a final link step required to create an executable pipeline that can be
bound to a command buffer.
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkGraphicsPipelineLibraryCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceGraphicsPipelineLibraryFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceGraphicsPipelineLibraryPropertiesEXT
New Enums
VkGraphicsPipelineLibraryFlagBitsEXT
VkPipelineLayoutCreateFlagBits
New Bitmasks
VkGraphicsPipelineLibraryFlagsEXT
New Enum Constants
VK_EXT_GRAPHICS_PIPELINE_LIBRARY_EXTENSION_NAME
VK_EXT_GRAPHICS_PIPELINE_LIBRARY_SPEC_VERSION
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT
VK_PIPELINE_CREATE_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT
Extending
VkPipelineLayoutCreateFlagBits
VK_PIPELINE_LAYOUT_CREATE_INDEPENDENT_SETS_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_LIBRARY_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_PROPERTIES_EXT
Version History
Revision 1, 2021-08-17 (Tobias Hector)
Initial draft.
VK_EXT_hdr_metadata
Name String
VK_EXT_hdr_metadata
Extension Type
Device extension
Registered Extension Number
106
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
Contact
Courtney Goeltzenleuchter
courtney-g
Other Extension Metadata
Last Modified Date
2024-03-26
IP Status
No known IP claims.
Contributors
Courtney Goeltzenleuchter, Google
Sebastian Wick, Red Hat Inc.
Tobias Hector, AMD
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.
SMPTE 2086 metadata defines the color volume of the display on which the
content was optimized for viewing and includes the color primaries, white
point, and luminance range.
When such content is reproduced on another display, this metadata can be
used by the presentation engine to improve processing of images.
For instance, values in the image can first be clamped to the color volume
described in the metadata, and then what remains can be remapped to the
color volume of the presentation engine.
CTA 861.3 metadata additionally includes the maximum intended luminance for
the content and the maximum average light level across frames.
This extension does not define exactly how this metadata is used, however,
it simply provides a mechanism to provide it to the presentation engine.
Presentation engines may process the image based on the metadata before
displaying it, resulting in the image being modified outside of Vulkan.
For example, the clamping of colors in the image to the color volume may
change those values in the image itself.
The metadata does not override or otherwise influence the color space and
color encoding.
New Commands
vkSetHdrMetadataEXT
New Structures
VkHdrMetadataEXT
VkXYColorEXT
New Enum Constants
VK_EXT_HDR_METADATA_EXTENSION_NAME
VK_EXT_HDR_METADATA_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_HDR_METADATA_EXT
Issues
1) Do we need a query function for the currently specified metadata?
No, Vulkan does not provide queries for state that the application can track
on its own.
2) Should we specify default metadata if not specified by the application?
No, the metadata is optional and the absence of the metadata is
well-defined.
Version History
Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)
Initial version
Revision 2, 2018-12-19 (Courtney Goeltzenleuchter)
Correct implicit validity for VkHdrMetadataEXT structure
Revision 3, 2024-03-26 (Tobias Hector & Sebastian Wick)
Clarifications and removal of erroneous “reference monitor” term
VK_EXT_headless_surface
Name String
VK_EXT_headless_surface
Extension Type
Instance extension
Registered Extension Number
257
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Lisa Wu
chengtianww
Other Extension Metadata
Last Modified Date
2019-03-21
IP Status
No known IP claims.
Contributors
Ray Smith, Arm
Description
The
VK_EXT_headless_surface
extension is an instance extension.
It provides a mechanism to create
VkSurfaceKHR
objects independently
of any window system or display device.
The presentation operation for a swapchain created from a headless surface
is by default a no-op, resulting in no externally-visible result.
Because there is no real presentation target, future extensions can layer on
top of the headless surface to introduce arbitrary or customizable sets of
restrictions or features.
These could include features like saving to a file or restrictions to
emulate a particular presentation target.
This functionality is expected to be useful for application and driver
development because it allows any platform to expose an arbitrary or
customizable set of restrictions and features of a presentation engine.
This makes it a useful portable test target for applications targeting a
wide range of presentation engines where the actual target presentation
engines might be scarce, unavailable, or otherwise undesirable or
inconvenient to use for general Vulkan application development.
New Commands
vkCreateHeadlessSurfaceEXT
New Structures
VkHeadlessSurfaceCreateInfoEXT
New Bitmasks
VkHeadlessSurfaceCreateFlagsEXT
New Enum Constants
VK_EXT_HEADLESS_SURFACE_EXTENSION_NAME
VK_EXT_HEADLESS_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_HEADLESS_SURFACE_CREATE_INFO_EXT
Version History
Revision 1, 2019-03-21 (Ray Smith)
Initial draft
VK_EXT_image_2d_view_of_3d
Name String
VK_EXT_image_2d_view_of_3d
Extension Type
Device extension
Registered Extension Number
394
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_maintenance1
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_image_2d_view_of_3d
Other Extension Metadata
Last Modified Date
2022-02-22
IP Status
No known IP claims.
Contributors
Mike Blumenkrantz, Valve
Piers Daniell, NVIDIA
Spencer Fricke, Samsung
Ricardo Garcia, Igalia
Graeme Leese, Broadcom
Ralph Potter, Samsung
Stu Smith, AMD
Shahbaz Youssefi, Google
Alex Walters, Imagination
Description
This extension allows a single slice of a 3D image to be used as a 2D view
in image descriptors, matching both the functionality of glBindImageTexture
in OpenGL with the
layer
parameter set to true and 2D view binding
provided by the extension EGL_KHR_gl_texture_3D_image.
It is primarily intended to support GL emulation.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImage2DViewOf3DFeaturesEXT
New Enum Constants
VK_EXT_IMAGE_2D_VIEW_OF_3D_EXTENSION_NAME
VK_EXT_IMAGE_2D_VIEW_OF_3D_SPEC_VERSION
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_2D_VIEW_OF_3D_FEATURES_EXT
Version History
Revision 1, 2022-03-25 (Mike Blumenkrantz)
Internal revisions
VK_EXT_image_compression_control
Name String
VK_EXT_image_compression_control
Extension Type
Device extension
Registered Extension Number
339
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_EXT_image_compression_control
Other Extension Metadata
Last Modified Date
2022-05-02
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm
Graeme Leese, Broadcom
Andrew Garrard, Imagination
Lisa Wu, Arm
Peter Kohaut, Arm
Description
This extension enables fixed-rate image compression and adds the ability to
control when this kind of compression can be applied.
Many implementations support some form of framebuffer compression.
This is typically transparent to applications as lossless compression
schemes are used.
With fixed-rate compression, the compression is done at a defined bitrate.
Such compression algorithms generally produce results that are visually
lossless, but the results are typically not bit-exact when compared to a
non-compressed result.
The implementation may not be able to use the requested compression rate in
all cases.
This extension adds a query that can be used to determine the compression
scheme and rate that was applied to an image.
New Commands
vkGetImageSubresourceLayout2EXT
New Structures
VkImageSubresource2EXT
VkSubresourceLayout2EXT
Extending
VkImageCreateInfo
VkSwapchainCreateInfoKHR
VkPhysicalDeviceImageFormatInfo2
VkImageCompressionControlEXT
Extending
VkImageFormatProperties2
VkSurfaceFormat2KHR
VkSubresourceLayout2
VkImageCompressionPropertiesEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageCompressionControlFeaturesEXT
New Enums
VkImageCompressionFixedRateFlagBitsEXT
VkImageCompressionFlagBitsEXT
New Bitmasks
VkImageCompressionFixedRateFlagsEXT
VkImageCompressionFlagsEXT
New Enum Constants
VK_EXT_IMAGE_COMPRESSION_CONTROL_EXTENSION_NAME
VK_EXT_IMAGE_COMPRESSION_CONTROL_SPEC_VERSION
Extending
VkResult
VK_ERROR_COMPRESSION_EXHAUSTED_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_CONTROL_EXT
VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_PROPERTIES_EXT
VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_FEATURES_EXT
VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_EXT
Version History
Revision 1, 2022-05-02 (Jan-Harald Fredriksen)
Initial draft
VK_EXT_image_compression_control_swapchain
Name String
VK_EXT_image_compression_control_swapchain
Extension Type
Device extension
Registered Extension Number
438
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_image_compression_control
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2022-05-02
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm
Graeme Leese, Broadcom
Andrew Garrard, Imagination
Lisa Wu, Arm
Peter Kohaut, Arm
Ian Elliott, Google
Description
This extension enables fixed-rate image compression and adds the ability to
control when this kind of compression can be applied to swapchain images.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageCompressionControlSwapchainFeaturesEXT
New Enum Constants
VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_EXTENSION_NAME
VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_FEATURES_EXT
Version History
Revision 1, 2022-05-02 (Jan-Harald Fredriksen)
Initial draft
VK_EXT_image_drm_format_modifier
Name String
VK_EXT_image_drm_format_modifier
Extension Type
Device extension
Registered Extension Number
159
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_bind_memory2
and
VK_KHR_get_physical_device_properties2
and
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
and
VK_KHR_image_format_list
or
Vulkan Version 1.2
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2021-09-30
IP Status
No known IP claims.
Contributors
Antoine Labour, Google
Bas Nieuwenhuizen, Google
Lina Versace, Google
James Jones, NVIDIA
Faith Ekstrand, Intel
Jőrg Wagner, ARM
Kristian Høgsberg Kristensen, Google
Ray Smith, ARM
Description
This extension provides the ability to use
DRM format modifiers
with
images, enabling Vulkan to better integrate with the Linux ecosystem of
graphics, video, and display APIs.
Its functionality closely overlaps with
EGL_EXT_image_dma_buf_import_modifiers
and
EGL_MESA_image_dma_buf_export
Unlike the EGL extensions, this extension does not require the use of a
specific handle type (such as a dma_buf) for external memory and provides
more explicit control of image creation.
Introduction to DRM Format Modifiers
DRM format modifier
is a 64-bit, vendor-prefixed, semi-opaque unsigned
integer.
Most
modifiers
represent a concrete, vendor-specific tiling format for
images.
Some exceptions are
DRM_FORMAT_MOD_LINEAR
(which is not
vendor-specific);
DRM_FORMAT_MOD_NONE
(which is an alias of
DRM_FORMAT_MOD_LINEAR
due to historical accident); and
DRM_FORMAT_MOD_INVALID
(which does not represent a tiling format).
The
modifier’s
vendor prefix consists of the 8 most significant bits.
The canonical list of
modifiers
and vendor prefixes is found in
drm_fourcc.h
in the Linux kernel source.
The other dominant source of
modifiers
are vendor kernel trees.
One goal of
modifiers
in the Linux ecosystem is to enumerate for each
vendor a reasonably sized set of tiling formats that are appropriate for
images shared across processes, APIs, and/or devices, where each
participating component may possibly be from different vendors.
A non-goal is to enumerate all tiling formats supported by all vendors.
Some tiling formats used internally by vendors are inappropriate for
sharing; no
modifiers
should be assigned to such tiling formats.
Modifier values typically do not
describe
memory layouts.
More precisely, a
modifier
's lower 56 bits usually have no structure.
Instead, modifiers
name
memory layouts; they name a small set of
vendor-preferred layouts for image sharing.
As a consequence, in each vendor namespace the modifier values are often
sequentially allocated starting at 1.
Each
modifier
is usually supported by a single vendor and its name matches
the pattern
{VENDOR}_FORMAT_MOD_*
or
DRM_FORMAT_MOD_{VENDOR}_*
Examples are
I915_FORMAT_MOD_X_TILED
and
DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED
An exception is
DRM_FORMAT_MOD_LINEAR
, which is supported by most
vendors.
Many APIs in Linux use
modifiers
to negotiate and specify the memory
layout of shared images.
For example, a Wayland compositor and Wayland client may, by relaying
modifiers
over the Wayland protocol
zwp_linux_dmabuf_v1
, negotiate a
vendor-specific tiling format for a shared
wl_buffer
The client may allocate the underlying memory for the
wl_buffer
with
GBM, providing the chosen
modifier
to
gbm_bo_create_with_modifiers
The client may then import the
wl_buffer
into Vulkan for producing
image content, providing the resource’s dma_buf to
VkImportMemoryFdInfoKHR
and its
modifier
to
VkImageDrmFormatModifierExplicitCreateInfoEXT
The compositor may then import the
wl_buffer
into OpenGL for sampling,
providing the resource’s dma_buf and
modifier
to
eglCreateImage
The compositor may also bypass OpenGL and submit the
wl_buffer
directly
to the kernel’s display API, providing the dma_buf and
modifier
through
drm_mode_fb_cmd2
Format Translation
Modifier
-capable APIs often pair
modifiers
with DRM formats, which are
defined in
drm_fourcc.h
However,
VK_EXT_image_drm_format_modifier
uses
VkFormat
instead of
DRM formats.
The application must convert between
VkFormat
and DRM format when it
sends or receives a DRM format to or from an external API.
The mapping from
VkFormat
to DRM format is lossy.
Therefore, when receiving a DRM format from an external API, often the
application must use information from the external API to accurately map the
DRM format to a
VkFormat
For example, DRM formats do not distinguish between RGB and sRGB (as of
2018-03-28); external information is required to identify the image’s color
space.
The mapping between
VkFormat
and DRM format is also incomplete.
For some DRM formats there exist no corresponding Vulkan format, and for
some Vulkan formats there exist no corresponding DRM format.
Usage Patterns
Three primary usage patterns are intended for this extension:
Negotiation.
The application negotiates with
modifier
-aware,
external components to determine sets of image creation parameters
supported among all components.
In the Linux ecosystem, the negotiation usually assumes the image is a 2D,
single-sampled, non-mipmapped, non-array image; this extension permits that
assumption but does not require it.
The result of the negotiation usually resembles a set of tuples such as
(drmFormat, drmFormatModifier)
, where each participating component
supports all tuples in the set.
Many details of this negotiation - such as the protocol used during
negotiation, the set of image creation parameters expressible in the
protocol, and how the protocol chooses which process and which API will
create the image - are outside the scope of this specification.
In this extension,
vkGetPhysicalDeviceFormatProperties2
with
VkDrmFormatModifierPropertiesListEXT
serves a primary role during the
negotiation, and
vkGetPhysicalDeviceImageFormatProperties2
with
VkPhysicalDeviceImageDrmFormatModifierInfoEXT
serves a secondary role.
Import.
The application imports an image with a
modifier
In this pattern, the application receives from an external source the
image’s memory and its creation parameters, which are often the result of
the negotiation described above.
Some image creation parameters are implicitly defined by the external
source; for example,
VK_IMAGE_TYPE_2D
is often assumed.
Some image creation parameters are usually explicit, such as the image’s
format
drmFormatModifier
, and
extent
; and each plane’s
offset
and
rowPitch
Before creating the image, the application first verifies that the physical
device supports the received creation parameters by querying
vkGetPhysicalDeviceFormatProperties2
with
VkDrmFormatModifierPropertiesListEXT
and
vkGetPhysicalDeviceImageFormatProperties2
with
VkPhysicalDeviceImageDrmFormatModifierInfoEXT
Then the application creates the image by chaining
VkImageDrmFormatModifierExplicitCreateInfoEXT
and
VkExternalMemoryImageCreateInfo
onto
VkImageCreateInfo
Export.
The application creates an image and allocates its memory.
Then the application exports to
modifier
-aware consumers the image’s
memory handles; its creation parameters; its
modifier
; and the
offset
size
, and
rowPitch
of each
memory plane
In this pattern, the Vulkan device is the authority for the image; it is the
allocator of the image’s memory and the decider of the image’s creation
parameters.
When choosing the image’s creation parameters, the application usually
chooses a tuple
(format, drmFormatModifier)
from the result of the
negotiation described above.
The negotiation’s result often contains multiple tuples that share the same
format but differ in their
modifier
In this case, the application should defer the choice of the image’s
modifier
to the Vulkan implementation by providing all such
modifiers
to
VkImageDrmFormatModifierListCreateInfoEXT
::
pDrmFormatModifiers
and the implementation should choose from
pDrmFormatModifiers
the
optimal
modifier
in consideration with the other image parameters.
The application creates the image by chaining
VkImageDrmFormatModifierListCreateInfoEXT
and
VkExternalMemoryImageCreateInfo
onto
VkImageCreateInfo
The protocol and APIs by which the application will share the image with
external consumers will likely determine the value of
VkExternalMemoryImageCreateInfo
::
handleTypes
The implementation chooses for the image an optimal
modifier
from
VkImageDrmFormatModifierListCreateInfoEXT
::
pDrmFormatModifiers
The application then queries the implementation-chosen
modifier
with
vkGetImageDrmFormatModifierPropertiesEXT
, and queries the memory
layout of each plane with
vkGetImageSubresourceLayout
The application then allocates the image’s memory with
VkMemoryAllocateInfo
, adding chained extending structures for external
memory; binds it to the image; and exports the memory, for example, with
vkGetMemoryFdKHR
Finally, the application sends the image’s creation parameters, its
modifier
, its per-plane memory layout, and the exported memory handle to
the external consumers.
The details of how the application transmits this information to external
consumers is outside the scope of this specification.
Prior Art
Extension
EGL_EXT_image_dma_buf_import
introduced the ability to create an
EGLImage
by importing for each
plane a dma_buf, offset, and row pitch.
Later, extension
EGL_EXT_image_dma_buf_import_modifiers
introduced the ability to query which combination of formats and
modifiers
the implementation supports and to specify
modifiers
during creation of
the
EGLImage
Extension
EGL_MESA_image_dma_buf_export
is the inverse of
EGL_EXT_image_dma_buf_import_modifiers
The Linux kernel modesetting API (KMS), when configuring the display’s
framebuffer with
struct
drm_mode_fb_cmd2
, allows one to
specify the framebuffer’s
modifier
as well as a per-plane memory handle,
offset, and row pitch.
GBM, a graphics buffer manager for Linux, allows creation of a
gbm_bo
(that is, a graphics
buffer object
) by importing data similar to that in
EGL_EXT_image_dma_buf_import_modifiers
and symmetrically allows exporting the same data from the
gbm_bo
See the references to
modifier
and
plane
in
gbm.h
New Commands
vkGetImageDrmFormatModifierPropertiesEXT
New Structures
VkDrmFormatModifierPropertiesEXT
VkImageDrmFormatModifierPropertiesEXT
Extending
VkFormatProperties2
VkDrmFormatModifierPropertiesListEXT
Extending
VkImageCreateInfo
VkImageDrmFormatModifierExplicitCreateInfoEXT
VkImageDrmFormatModifierListCreateInfoEXT
Extending
VkPhysicalDeviceImageFormatInfo2
VkPhysicalDeviceImageDrmFormatModifierInfoEXT
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
VkDrmFormatModifierProperties2EXT
Extending
VkFormatProperties2
VkDrmFormatModifierPropertiesList2EXT
New Enum Constants
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION
Extending
VkImageAspectFlagBits
VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT
VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT
VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT
VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT
Extending
VkImageTiling
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
Extending
VkResult
VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_2_EXT
Issues
1) Should this extension define a single DRM format modifier per
VkImage
? Or define one per plane?
RESOLVED
: There exists a single DRM format modifier per
VkImage
DISCUSSION
: Prior art, such as
EGL_EXT_image_dma_buf_import_modifiers
struct drm_mode_fb_cmd2
, and
struct
gbm_import_fd_modifier_data
allows defining one
modifier
per plane.
However, developers of the GBM and kernel APIs concede it was a mistake.
Beginning in Linux 4.10, the kernel requires that the application provide
the same DRM format
modifier
for each plane.
(See Linux commit
bae781b259269590109e8a4a8227331362b88212
).
And GBM provides an entry point,
gbm_bo_get_modifier
, for querying the
modifier
of the image but does not provide one to query the modifier of
individual planes.
2) When creating an image with
VkImageDrmFormatModifierExplicitCreateInfoEXT
, which is typically used
when
importing
an image, should the application explicitly provide the
size of each plane?
RESOLVED
: No.
The application
must
not provide the size.
To enforce this, the API requires that
VkImageDrmFormatModifierExplicitCreateInfoEXT
::
pPlaneLayouts->size
must
be 0.
DISCUSSION
: Prior art, such as
EGL_EXT_image_dma_buf_import_modifiers
struct drm_mode_fb_cmd2
, and
struct
gbm_import_fd_modifier_data
omits from the API the size of each plane.
Instead, the APIs infer each plane’s size from the import parameters, which
include the image’s pixel format and a dma_buf, offset, and row pitch for
each plane.
However, Vulkan differs from EGL and GBM with regards to image creation in
the following ways:
Differences in Image Creation
Undedicated allocation by default.
When importing or exporting a set
of dma_bufs as an
EGLImage
or
gbm_bo
, common practice mandates
that each dma_buf’s memory be dedicated (in the sense of
VK_KHR_dedicated_allocation
) to the image (though not necessarily
dedicated to a single plane).
In particular, neither the GBM documentation nor the EGL extension
specifications explicitly state this requirement, but in light of common
practice this is likely due to under-specification rather than
intentional omission.
In contrast,
VK_EXT_image_drm_format_modifier
permits, but does not
require, the implementation to require dedicated allocations for images
created with
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
Separation of image creation and memory allocation.
When importing a
set of dma_bufs as an
EGLImage
or
gbm_bo
, EGL and GBM create
the image resource and bind it to memory (the dma_bufs) simultaneously.
This allows EGL and GBM to query each dma_buf’s size during image
creation.
In Vulkan, image creation and memory allocation are independent unless a
dedicated allocation is used (as in
VK_KHR_dedicated_allocation
).
Therefore, without requiring dedicated allocation, Vulkan cannot query
the size of each dma_buf (or other external handle) when calculating the
image’s memory layout.
Even if dedication allocation were required, Vulkan cannot calculate the
image’s memory layout until after the image is bound to its dma_ufs.
The above differences complicate the potential inference of plane size in
Vulkan.
Consider the following problematic cases:
Problematic Plane Size Calculations
Padding.
Some plane of the image may require implementation-dependent
padding.
Metadata.
For some
modifiers
, the image may have a metadata plane
which requires a non-trivial calculation to determine its size.
Mipmapped, array, and 3D images.
The implementation may support
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT
for images whose
mipLevels
arrayLayers
, or
depth
is greater than 1.
For such images with certain
modifiers
, the calculation of each
plane’s size may be non-trivial.
However, an application-provided plane size solves none of the above
problems.
For simplicity, consider an external image with a single memory plane.
The implementation is obviously capable calculating the image’s size when
its tiling is
VK_IMAGE_TILING_OPTIMAL
Likewise, any reasonable implementation is capable of calculating the
image’s size when its tiling uses a supported
modifier
Suppose that the external image’s size is smaller than the
implementation-calculated size.
If the application provided the external image’s size to
vkCreateImage
, the implementation would observe the mismatched size
and recognize its inability to comprehend the external image’s layout
(unless the implementation used the application-provided size to select a
refinement of the tiling layout indicated by the
modifier
, which is
strongly discouraged).
The implementation would observe the conflict, and reject image creation
with
VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT
On the other hand, if the application did not provide the external image’s
size to
vkCreateImage
, then the application would observe after
calling
vkGetImageMemoryRequirements
that the external image’s size is
less than the size required by the implementation.
The application would observe the conflict and refuse to bind the
VkImage
to the external memory.
In both cases, the result is explicit failure.
Suppose that the external image’s size is larger than the
implementation-calculated size.
If the application provided the external image’s size to
vkCreateImage
, for reasons similar to above the implementation would
observe the mismatched size and recognize its inability to comprehend the
image data residing in the extra size.
The implementation, however, must assume that image data resides in the
entire size provided by the application.
The implementation would observe the conflict and reject image creation with
VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT
On the other hand, if the application did not provide the external image’s
size to
vkCreateImage
, then the application would observe after
calling
vkGetImageMemoryRequirements
that the external image’s size is
larger than the implementation-usable size.
The application would observe the conflict and refuse to bind the
VkImage
to the external memory.
In both cases, the result is explicit failure.
Therefore, an application-provided size provides no benefit, and this
extension should not require it.
This decision renders
VkSubresourceLayout
::
size
an unused field
during image creation, and thus introduces a risk that implementations may
require applications to submit sideband creation parameters in the unused
field.
To prevent implementations from relying on sideband data, this extension
requires
the application to set
size
to 0.
References
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers
EGL_MESA_image_dma_buf_export
struct
drm_mode_fb_cmd2
gbm.h
Version History
Revision 1, 2018-08-29 (Lina Versace)
First stable revision
Revision 2, 2021-09-30 (Jon Leech)
Add interaction with
VK_KHR_format_feature_flags2
to
vk.xml
VK_EXT_image_sliced_view_of_3d
Name String
VK_EXT_image_sliced_view_of_3d
Extension Type
Device extension
Registered Extension Number
419
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_maintenance1
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
D3D support
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_image_sliced_view_of_3d
Other Extension Metadata
Last Modified Date
2023-01-24
IP Status
No known IP claims.
Contributors
Mike Blumenkrantz, Valve
Hans-Kristian Arntzen, Valve
Ricardo Garcia, Igalia
Shahbaz Youssefi, Google
Piers Daniell, NVIDIA
Description
This extension allows creating 3D views of 3D images such that the views
contain a subset of the slices in the image, using a Z offset and range, for
the purpose of using the views as storage image descriptors.
This matches functionality in D3D12 and is primarily intended to support
D3D12 emulation.
New Structures
Extending
VkImageViewCreateInfo
VkImageViewSlicedCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageSlicedViewOf3DFeaturesEXT
New Enum Constants
VK_EXT_IMAGE_SLICED_VIEW_OF_3D_EXTENSION_NAME
VK_EXT_IMAGE_SLICED_VIEW_OF_3D_SPEC_VERSION
VK_REMAINING_3D_SLICES_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_VIEW_SLICED_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_SLICED_VIEW_OF_3D_FEATURES_EXT
Version History
Revision 1, 2022-10-21 (Mike Blumenkrantz)
Initial revision
VK_EXT_image_view_min_lod
Name String
VK_EXT_image_view_min_lod
Extension Type
Device extension
Registered Extension Number
392
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Joshua Ashton
Joshua-Ashton
Other Extension Metadata
Last Modified Date
2021-11-09
IP Status
No known IP claims.
Contributors
Joshua Ashton, Valve
Hans-Kristian Arntzen, Valve
Samuel Iglesias Gonsalvez, Igalia
Tobias Hector, AMD
Faith Ekstrand, Intel
Tom Olson, ARM
Description
This extension allows applications to clamp the minimum LOD value during
Image Level(s) Selection
Texel Gathering
and
Integer Texel Coordinate Operations
with a given
VkImageView
by
VkImageViewMinLodCreateInfoEXT
::
minLod
This extension may be useful to restrict a
VkImageView
to only mips
which have been uploaded, and the use of fractional
minLod
can be
useful for smoothly introducing new mip levels when using linear mipmap
filtering.
New Structures
Extending
VkImageViewCreateInfo
VkImageViewMinLodCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageViewMinLodFeaturesEXT
New Enum Constants
VK_EXT_IMAGE_VIEW_MIN_LOD_EXTENSION_NAME
VK_EXT_IMAGE_VIEW_MIN_LOD_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_VIEW_MIN_LOD_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_MIN_LOD_FEATURES_EXT
Version History
Revision 1, 2021-07-06 (Joshua Ashton)
Initial version
VK_EXT_layer_settings
Name String
VK_EXT_layer_settings
Extension Type
Instance extension
Registered Extension Number
497
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Contact
Christophe Riccio
christophe
Extension Proposal
VK_EXT_layer_settings
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
structure
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.
The
VK_EXT_layer_settings
extension subsumes all the functionality
provided in the
VK_EXT_validation_flags
extension and the
VK_EXT_validation_features
extension.
New Structures
VkLayerSettingEXT
Extending
VkInstanceCreateInfo
VkLayerSettingsCreateInfoEXT
New Enums
VkLayerSettingTypeEXT
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
Example
One example usage of
VK_EXT_layer_settings
is as 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(std::size(simulate_capabilities)), simulate_capabilities},
{kLayerName, kLayerSettingsDebugReports, VK_LAYER_SETTING_TYPE_STRING_EXT,
static_cast(std::size(debug_reports)), debug_reports}
};

const VkLayerSettingsCreateInfoEXT layer_settings_create_info{
VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT, nullptr,
static_cast(std::size(settings)), settings};

VkInstanceCreateInfo inst_create_info = {};
...
inst_create_info.pNext = &layer_settings_create_info;
vkCreateInstance(&inst_create_info, nullptr, &_instances);
Issues
How should application developers figure out the list of available
settings?
This extension does not provide a reflection API for layer settings.
Layer settings are described in each layer JSON manifest and the
documentation of each layer which implements this extension.
Version History
Revision 1, 2020-06-17 (Mark Lobodzinski)
Initial revision for Validation layer internal usages
Revision 2, 2023-09-26 (Christophe Riccio)
Refactor APIs for any layer usages and public release
VK_EXT_legacy_dithering
Name String
VK_EXT_legacy_dithering
Extension Type
Device extension
Registered Extension Number
466
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_VERSION_1_4
Interacts with VK_KHR_dynamic_rendering
Interacts with VK_KHR_maintenance5
Special Use
OpenGL / ES support
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_legacy_dithering
Other Extension Metadata
Last Modified Date
2024-02-22
Contributors
Shahbaz Youssefi, Google
Graeme Leese, Broadcom
Jan-Harald Fredriksen, Arm
Description
This extension exposes a hardware feature used by some vendors to implement
OpenGL’s dithering.
The purpose of this extension is to support layering OpenGL over Vulkan, by
allowing the layer to take advantage of the same hardware feature and
provide equivalent dithering to OpenGL applications.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceLegacyDitheringFeaturesEXT
New Enum Constants
VK_EXT_LEGACY_DITHERING_EXTENSION_NAME
VK_EXT_LEGACY_DITHERING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_DITHERING_FEATURES_EXT
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_ENABLE_LEGACY_DITHERING_BIT_EXT
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
and
VK_KHR_maintenance5
or
Vulkan Version 1.4
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_ENABLE_LEGACY_DITHERING_BIT_EXT
Extending
VkRenderingFlagBits
VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT
Version History
Revision 1, 2022-03-31 (Shahbaz Youssefi)
Internal revisions
Revision 2, 2024-02-22 (Shahbaz Youssefi)
Added pipeline create flag to support dynamic rendering
Issues
1) In OpenGL, the dither state can change dynamically.
Should this extension add a pipeline state for dither?
RESOLVED
: No.
Changing dither state is rarely, if ever, done during rendering.
Every surveyed Android application either entirely disables dither,
explicitly enables it, or uses the default state (which is enabled).
Additionally, on some hardware dither can only be specified in a render pass
granularity, so a change in dither state would necessarily need to cause a
render pass break.
This extension considers dynamic changes in OpenGL dither state a
theoretical situation, and expects the layer to break the render pass in
such a situation without any practical downsides.
VK_EXT_legacy_vertex_attributes
Name String
VK_EXT_legacy_vertex_attributes
Extension Type
Device extension
Registered Extension Number
496
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_vertex_input_dynamic_state
Special Use
OpenGL / ES support
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_legacy_vertex_attributes
Other Extension Metadata
Last Modified Date
2024-02-23
IP Status
No known IP claims.
Contributors
Mike Blumenkrantz, Valve
Piers Daniell, NVIDIA
Spencer Fricke, LunarG
Alyssa Rosenzweig, Valve
Description
This extension adds support for legacy features of (non-64-bit) vertex
attributes as found in OpenGL:
Vertex attributes loaded from arbitrary buffer alignments
Vertex attributes using arbitrary strides
Vertex attributes where the component data type of the binding does not
match the component numeric type of the shader input
These features are only usable with dynamic vertex input.
Unaligned loads of vertex attributes may incur performance penalties,
indicated with a property.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceLegacyVertexAttributesFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceLegacyVertexAttributesPropertiesEXT
New Enum Constants
VK_EXT_LEGACY_VERTEX_ATTRIBUTES_EXTENSION_NAME
VK_EXT_LEGACY_VERTEX_ATTRIBUTES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_VERTEX_ATTRIBUTES_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_VERTEX_ATTRIBUTES_PROPERTIES_EXT
Issues
1.) Should implementations convert float/integer values?
RESOLVED
: No.
When fetching an integer data type from float values or float data types
from integer values, the resulting shader values are
implementation-dependent.
Version History
Revision 1, 2024-02-16 (Mike Blumenkrantz)
Initial revision
VK_EXT_map_memory_placed
Name String
VK_EXT_map_memory_placed
Extension Type
Device extension
Registered Extension Number
273
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_map_memory2
or
Vulkan Version 1.4
Contact
Faith Ekstrand
gfxstrand
Extension Proposal
VK_EXT_map_memory_placed
Other Extension Metadata
Last Modified Date
2023-03-21
IP Status
No known IP claims.
Interactions and External Dependencies
Depends on apitext:VK_KHR_map_memory2
Interacts with apitext:VK_EXT_external_memory_host
Contributors
Faith Ekstrand, Collabora
Tobias Hector, AMD
James Jones, NVIDIA
Georg Lehmann, Valve
Derek Lesho, Codeweavers
Description
This extension allows an application to request that
vkMapMemory2KHR
attempt to place the memory map at a particular virtual address.
New Structures
Extending
VkMemoryMapInfo
VkMemoryMapPlacedInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMapMemoryPlacedFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMapMemoryPlacedPropertiesEXT
New Enum Constants
VK_EXT_MAP_MEMORY_PLACED_EXTENSION_NAME
VK_EXT_MAP_MEMORY_PLACED_SPEC_VERSION
Extending
VkMemoryMapFlagBits
VK_MEMORY_MAP_PLACED_BIT_EXT
Extending
VkMemoryUnmapFlagBits
VK_MEMORY_UNMAP_RESERVE_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_MEMORY_MAP_PLACED_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAP_MEMORY_PLACED_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAP_MEMORY_PLACED_PROPERTIES_EXT
Version History
Revision 1, 2024-01-14 (Faith Ekstrand)
Internal revisions
VK_EXT_memory_budget
Name String
VK_EXT_memory_budget
Extension Type
Device extension
Registered Extension Number
238
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2018-10-08
Contributors
Jeff Bolz, NVIDIA
Jeff Juliano, NVIDIA
Description
While running a Vulkan application, other processes on the machine might
also be attempting to use the same device memory, which can pose problems.
This extension adds support for querying the amount of memory used and the
total memory budget for a memory heap.
The values returned by this query are implementation-dependent and can
depend on a variety of factors including operating system and system load.
The
VkPhysicalDeviceMemoryBudgetPropertiesEXT
::
heapBudget
values
can be used as a guideline for how much total memory from each heap the
current process
can use at any given time, before allocations may start
failing or causing performance degradation.
The values may change based on other activity in the system that is outside
the scope and control of the Vulkan implementation.
The
VkPhysicalDeviceMemoryBudgetPropertiesEXT
::
heapUsage
will
display the
current process
estimated heap usage.
With this information, the idea is for an application at some interval (once
per frame, per few seconds, etc) to query
heapBudget
and
heapUsage
From here the application can notice if it is over budget and decide how it
wants to handle the memory situation (free it, move to host memory, changing
mipmap levels, etc).
This extension is designed to be used in concert with
VK_EXT_memory_priority
to help with this part of memory management.
New Structures
Extending
VkPhysicalDeviceMemoryProperties2
VkPhysicalDeviceMemoryBudgetPropertiesEXT
New Enum Constants
VK_EXT_MEMORY_BUDGET_EXTENSION_NAME
VK_EXT_MEMORY_BUDGET_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT
Version History
Revision 1, 2018-10-08 (Jeff Bolz)
Initial revision
VK_EXT_memory_decompression
Name String
VK_EXT_memory_decompression
Extension Type
Device extension
Registered Extension Number
551
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_buffer_device_address
Contact
Vikram Kushwaha
vkushwaha-nv
Extension Proposal
VK_EXT_memory_decompression
Other Extension Metadata
Last Modified Date
2025-01-23
Contributors
Vikram Kushwaha, NVIDIA
Daniel Koch, NVIDIA
Jeff Bolz, NVIDIA
Christoph Kubisch, NVIDIA
Piers Daniell, NVIDIA
Spencer Fricke, LunarG
Description
This extension adds support for performing memory to memory decompression.
New Commands
vkCmdDecompressMemoryEXT
vkCmdDecompressMemoryIndirectCountEXT
New Structures
VkDecompressMemoryInfoEXT
VkDecompressMemoryRegionEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMemoryDecompressionFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMemoryDecompressionPropertiesEXT
New Enums
VkMemoryDecompressionMethodFlagBitsEXT
New Bitmasks
VkMemoryDecompressionMethodFlagsEXT
New Enum Constants
VK_EXT_MEMORY_DECOMPRESSION_EXTENSION_NAME
VK_EXT_MEMORY_DECOMPRESSION_SPEC_VERSION
Extending
VkAccessFlagBits2
VK_ACCESS_2_MEMORY_DECOMPRESSION_READ_BIT_EXT
VK_ACCESS_2_MEMORY_DECOMPRESSION_WRITE_BIT_EXT
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_MEMORY_DECOMPRESSION_BIT_EXT
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_MEMORY_DECOMPRESSION_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DECOMPRESS_MEMORY_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_PROPERTIES_EXT
Issues
1) How does an app know the minimum size that
decompressedSize
should
be set to?
RESOLVED
: When decompressing, data is typically processed in chunks.
For example, with GDeflate 1.0, data is streamed in 64 KB blocks, but the
final block may be smaller.
The exact size of this last block depends on the compression method and
original data size and so it must be stored in the compressed bitstream so
that the decompressor can set
decompressedSize
correctly.
It is still ok for the last block to take up all 64 KB, but setting it too
low will cause issues and is undefined behavior.
It is a known limitation that the validation layers will not be able to
detect the minimum size of
decompressedSize
unless it decides to
implement each decompression method specification.
Version History
Revision 1, 2025-01-23 (Daniel Koch)
Initial draft
VK_EXT_memory_priority
Name String
VK_EXT_memory_priority
Extension Type
Device extension
Registered Extension Number
239
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2018-10-08
Contributors
Jeff Bolz, NVIDIA
Jeff Juliano, NVIDIA
Description
This extension adds a
priority
value specified at memory allocation
time.
On some systems with both device-local and non-device-local memory heaps,
the implementation may transparently move memory from one heap to another
when a heap becomes full (for example, when the total memory used across all
processes exceeds the size of the heap).
In such a case, this priority value may be used to determine which
allocations are more likely to remain in device-local memory.
New Structures
Extending
VkMemoryAllocateInfo
VkMemoryPriorityAllocateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMemoryPriorityFeaturesEXT
New Enum Constants
VK_EXT_MEMORY_PRIORITY_EXTENSION_NAME
VK_EXT_MEMORY_PRIORITY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT
Version History
Revision 1, 2018-10-08 (Jeff Bolz)
Initial revision
VK_EXT_mesh_shader
Name String
VK_EXT_mesh_shader
Extension Type
Device extension
Registered Extension Number
329
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_spirv_1_4
or
Vulkan Version 1.2
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_AMD_draw_indirect_count
Interacts with VK_EXT_device_generated_commands
Interacts with VK_KHR_draw_indirect_count
Interacts with VK_KHR_fragment_shading_rate
Interacts with VK_NV_device_generated_commands
Interacts with VkPhysicalDeviceMeshShaderFeaturesEXT::primitiveFragmentShadingRateMeshShader
SPIR-V Dependencies
SPV_EXT_mesh_shader
Contact
Christoph Kubisch
pixeljetstream
Extension Proposal
VK_EXT_mesh_shader
Other Extension Metadata
Last Modified Date
2022-01-20
Interactions and External Dependencies
This extension provides API support for
GLSL_EXT_mesh_shader
Interacts with Vulkan 1.1
Interacts with
VK_KHR_multiview
Interacts with
VK_KHR_fragment_shading_rate
Contributors
Christoph Kubisch, NVIDIA
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Piers Daniell, NVIDIA
Pierre Boudier, NVIDIA
Patrick Mours, NVIDIA
David Zhao Akeley, NVIDIA
Kedarnath Thangudu, NVIDIA
Timur Kristóf, Valve
Hans-Kristian Arntzen, Valve
Philip Rebohle, Valve
Mike Blumenkrantz, Valve
Slawomir Grajewski, Intel
Michal Pietrasiuk, Intel
Mariusz Merecki, Intel
Tom Olson, ARM
Jan-Harald Fredriksen, ARM
Sandeep Kakarlapudi, ARM
Ruihao Zhang, QUALCOMM
Ricardo Garcia, Igalia, S.L.
Tobias Hector, AMD
Stu Smith, AMD
Description
This extension provides a new mechanism allowing applications to generate
collections of geometric primitives via programmable mesh shading.
It is an alternative to the existing programmable primitive shading
pipeline, which relied on generating input primitives by a fixed function
assembler as well as fixed function vertex fetch.
This extension also adds support for the following SPIR-V extension in
Vulkan:
SPV_EXT_mesh_shader
New Commands
vkCmdDrawMeshTasksEXT
vkCmdDrawMeshTasksIndirectEXT
If
Vulkan Version 1.2
or
VK_KHR_draw_indirect_count
or
VK_AMD_draw_indirect_count
is supported:
vkCmdDrawMeshTasksIndirectCountEXT
New Structures
VkDrawMeshTasksIndirectCommandEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMeshShaderFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMeshShaderPropertiesEXT
New Enum Constants
VK_EXT_MESH_SHADER_EXTENSION_NAME
VK_EXT_MESH_SHADER_SPEC_VERSION
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_MESH_SHADER_BIT_EXT
VK_PIPELINE_STAGE_TASK_SHADER_BIT_EXT
Extending
VkQueryPipelineStatisticFlagBits
VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT
VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT
Extending
VkQueryType
VK_QUERY_TYPE_MESH_PRIMITIVES_GENERATED_EXT
Extending
VkShaderStageFlagBits
VK_SHADER_STAGE_MESH_BIT_EXT
VK_SHADER_STAGE_TASK_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_EXT
If
VK_EXT_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeEXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_COUNT_EXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_EXT
If
VK_NV_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeNV
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_NV
New or Modified Built-In Variables
CullPrimitiveEXT
PrimitivePointIndicesEXT
PrimitiveLineIndicesEXT
PrimitiveTriangleIndicesEXT
(modified)
Position
(modified)
PointSize
(modified)
ClipDistance
(modified)
CullDistance
(modified)
PrimitiveId
(modified)
Layer
(modified)
ViewportIndex
(modified)
NumWorkgroups
(modified)
WorkgroupSize
(modified)
WorkgroupId
(modified)
LocalInvocationId
(modified)
GlobalInvocationId
(modified)
LocalInvocationIndex
(modified)
NumSubgroups
(modified)
SubgroupId
(modified)
DrawIndex
(modified)
PrimitiveShadingRateKHR
(modified)
ViewIndex
New SPIR-V Capability
MeshShadingEXT
Version History
Revision 1, 2022-03-08 (Christoph Kubisch, Daniel Koch, Patrick Mours)
Initial revision
VK_EXT_metal_objects
Name String
VK_EXT_metal_objects
Extension Type
Device extension
Registered Extension Number
312
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Contact
Bill Hollings
billhollings
Extension Proposal
VK_EXT_metal_objects
Other Extension Metadata
Last Modified Date
2024-04-04
IP Status
No known IP claims.
Contributors
Bill Hollings, The Brenwill Workshop Ltd.
Dzmitry Malyshau, Mozilla Corp.
Description
In a Vulkan implementation that is layered on top of Metal on Apple device
platforms, this extension provides the ability to import and export the
underlying Metal objects associated with specific Vulkan objects.
As detailed in the
extension
proposal document
, this extension adds one new Vulkan command,
vkExportMetalObjectsEXT
, to export underlying Metal objects from
Vulkan objects, and supports importing the appropriate existing Metal
objects when creating Vulkan objects of types
VkDeviceMemory
VkImage
VkSemaphore
, and
VkEvent
The intent is that this extension will be advertised and supported only on
implementations that are layered on top of Metal on Apple device platforms.
New Base Types
IOSurfaceRef
MTLBuffer_id
MTLCommandQueue_id
MTLDevice_id
MTLSharedEvent_id
MTLTexture_id
New Commands
vkExportMetalObjectsEXT
New Structures
VkExportMetalObjectsInfoEXT
Extending
VkExportMetalObjectsInfoEXT
VkExportMetalBufferInfoEXT
VkExportMetalCommandQueueInfoEXT
VkExportMetalDeviceInfoEXT
VkExportMetalIOSurfaceInfoEXT
VkExportMetalSharedEventInfoEXT
VkExportMetalTextureInfoEXT
Extending
VkImageCreateInfo
VkImportMetalIOSurfaceInfoEXT
VkImportMetalTextureInfoEXT
Extending
VkInstanceCreateInfo
VkMemoryAllocateInfo
VkImageCreateInfo
VkImageViewCreateInfo
VkBufferViewCreateInfo
VkSemaphoreCreateInfo
VkEventCreateInfo
VkExportMetalObjectCreateInfoEXT
Extending
VkMemoryAllocateInfo
VkImportMetalBufferInfoEXT
Extending
VkSemaphoreCreateInfo
VkEventCreateInfo
VkImportMetalSharedEventInfoEXT
New Enums
VkExportMetalObjectTypeFlagBitsEXT
New Bitmasks
VkExportMetalObjectTypeFlagsEXT
New Enum Constants
VK_EXT_METAL_OBJECTS_EXTENSION_NAME
VK_EXT_METAL_OBJECTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXPORT_METAL_BUFFER_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_COMMAND_QUEUE_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_DEVICE_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_IO_SURFACE_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECTS_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECT_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_SHARED_EVENT_INFO_EXT
VK_STRUCTURE_TYPE_EXPORT_METAL_TEXTURE_INFO_EXT
VK_STRUCTURE_TYPE_IMPORT_METAL_BUFFER_INFO_EXT
VK_STRUCTURE_TYPE_IMPORT_METAL_IO_SURFACE_INFO_EXT
VK_STRUCTURE_TYPE_IMPORT_METAL_SHARED_EVENT_INFO_EXT
VK_STRUCTURE_TYPE_IMPORT_METAL_TEXTURE_INFO_EXT
Issues
None.
Version History
Revision 1, 2022-05-28 (Bill Hollings)
Initial draft.
Incorporated feedback from review by the Vulkan Working Group.
Renamed many structures, moved import/export of MTLBuffer to
VkDeviceMemory, added export of MTLSharedEvent, added import of
MTLSharedEvent for VkSemaphore and VkEvent, and changed used bit mask
fields to individual bit fields to simplify Valid Usage rules.
Revision 2, 2024-04-04 (Bill Hollings)
Add an
__unsafe_unretained
ownership qualifier to all Metal object
declarations, to support Automatic Reference Counting (ARC) on Apple
devices.
VK_EXT_metal_surface
Name String
VK_EXT_metal_surface
Extension Type
Instance extension
Registered Extension Number
218
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Dzmitry Malyshau
kvark
Other Extension Metadata
Last Modified Date
2018-10-01
IP Status
No known IP claims.
Contributors
Dzmitry Malyshau, Mozilla Corp.
Description
The
VK_EXT_metal_surface
extension is an instance extension.
It provides a mechanism to create a
VkSurfaceKHR
object (defined by
the
VK_KHR_surface
extension) from
CAMetalLayer
, which is
the native rendering surface of Apple’s Metal framework.
New Base Types
CAMetalLayer
New Commands
vkCreateMetalSurfaceEXT
New Structures
VkMetalSurfaceCreateInfoEXT
New Bitmasks
VkMetalSurfaceCreateFlagsEXT
New Enum Constants
VK_EXT_METAL_SURFACE_EXTENSION_NAME
VK_EXT_METAL_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_METAL_SURFACE_CREATE_INFO_EXT
Version History
Revision 1, 2018-10-01 (Dzmitry Malyshau)
Initial version
VK_EXT_multi_draw
Name String
VK_EXT_multi_draw
Extension Type
Device extension
Registered Extension Number
393
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Mike Blumenkrantz
zmike
Other Extension Metadata
Last Modified Date
2021-05-19
Interactions and External Dependencies
Interacts with Vulkan 1.1.
Interacts with
VK_KHR_shader_draw_parameters
IP Status
No known IP claims.
Contributors
Mike Blumenkrantz, VALVE
Piers Daniell, NVIDIA
Faith Ekstrand, INTEL
Spencer Fricke, SAMSUNG
Ricardo Garcia, IGALIA
Jon Leech, KHRONOS
Stu Smith, AMD
Description
Processing multiple draw commands in sequence incurs measurable overhead
within drivers due to repeated state checks and updates during dispatch.
This extension enables passing the entire sequence of draws directly to the
driver in order to avoid any such overhead, using an array of
VkMultiDrawInfoEXT
or
VkMultiDrawIndexedInfoEXT
structs with
vkCmdDrawMultiEXT
or
vkCmdDrawMultiIndexedEXT
, respectively.
These functions could be used any time multiple draw commands are being
recorded without any state changes between them in order to maximize
performance.
New Commands
vkCmdDrawMultiEXT
vkCmdDrawMultiIndexedEXT
New Structures
VkMultiDrawIndexedInfoEXT
VkMultiDrawInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMultiDrawFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMultiDrawPropertiesEXT
New Enum Constants
VK_EXT_MULTI_DRAW_EXTENSION_NAME
VK_EXT_MULTI_DRAW_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_PROPERTIES_EXT
New or Modified Built-In Variables
(modified)
DrawIndex
Version History
Revision 1, 2021-01-20 (Mike Blumenkrantz)
Initial version
VK_EXT_multisampled_render_to_single_sampled
Name String
VK_EXT_multisampled_render_to_single_sampled
Extension Type
Device extension
Registered Extension Number
377
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_create_renderpass2
and
VK_KHR_depth_stencil_resolve
or
Vulkan Version 1.2
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_multisampled_render_to_single_sampled
Other Extension Metadata
Last Modified Date
2021-04-16
IP Status
No known IP claims.
Contributors
Shahbaz Youssefi, Google
Jan-Harald Fredriksen, Arm
Jörg Wagner, Arm
Matthew Netsch, Qualcomm Technologies, Inc.
Jarred Davies, Imagination Technologies
Description
With careful usage of resolve attachments, multisampled image memory
allocated with
VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT
loadOp
not equal to
VK_ATTACHMENT_LOAD_OP_LOAD
and
storeOp
not equal to
VK_ATTACHMENT_STORE_OP_STORE
, a Vulkan application is able to
efficiently perform multisampled rendering without incurring any additional
memory penalty on some implementations.
Under certain circumstances however, the application may not be able to
complete its multisampled rendering within a single render pass; for example
if it does partial rasterization from frame to frame, blending on an image
from a previous frame, or in emulation of
GL_EXT_multisampled_render_to_texture.
In such cases, the application can use an initial subpass to effectively
load single-sampled data from the next subpass’s resolve attachment and fill
in the multisampled attachment which otherwise uses
loadOp
equal to
VK_ATTACHMENT_LOAD_OP_DONT_CARE
However, this is not always possible (for example for stencil in the absence
of VK_EXT_shader_stencil_export) and has multiple drawbacks.
Some implementations are able to perform said operation efficiently in
hardware, effectively loading a multisampled attachment from the contents of
a single sampled one.
Together with the ability to perform a resolve operation at the end of a
subpass, these implementations are able to perform multisampled rendering on
single-sampled attachments with no extra memory or bandwidth overhead.
This extension exposes this capability by allowing a framebuffer and render
pass to include single-sampled attachments while rendering is done with a
specified number of samples.
New Structures
Extending
VkFormatProperties2
VkSubpassResolvePerformanceQueryEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT
Extending
VkSubpassDescription2
VkRenderingInfo
VkMultisampledRenderToSingleSampledInfoEXT
New Enum Constants
VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME
VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_FEATURES_EXT
VK_STRUCTURE_TYPE_SUBPASS_RESOLVE_PERFORMANCE_QUERY_EXT
Issues
1) Could the multisampled attachment be initialized through some form of
copy?
RESOLVED
: No.
Some implementations do not support copying between attachments in general,
and find expressing this operation through a copy unnatural.
2) Another way to achieve this is by introducing a new
loadOp
to load
the contents of the multisampled image from a single-sampled one.
Why is this extension preferred?
RESOLVED
: Using this extension simplifies the application, as it does not
need to manage a secondary lazily-allocated image.
Additionally, using this extension leaves less room for error; for example a
single mistake in
loadOp
or
storeOp
would result in the
lazily-allocated image to actually take up memory, and remain so until
destruction.
3) There is no guarantee that multisampled data between two subpasses with
the same number of samples will be retained as the implementation may be
forced to split the render pass implicitly for various reasons.
Should this extension require that every subpass that uses
multisampled-render-to-single-sampled end in an implicit render pass split
(which results in a resolve operation)?
RESOLVED
: No.
Not requiring this allows render passes with multiple
multisampled-render-to-single-sampled subpasses to potentially execute more
efficiently (though there is no guarantee).
Version History
Revision 1, 2021-04-12 (Shahbaz Youssefi)
VK_EXT_mutable_descriptor_type
Name String
VK_EXT_mutable_descriptor_type
Extension Type
Device extension
Registered Extension Number
495
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_maintenance3
or
Vulkan Version 1.1
Special Use
D3D support
Contact
Joshua Ashton
Joshua-Ashton
Hans-Kristian Arntzen
HansKristian-Work
Extension Proposal
VK_EXT_mutable_descriptor_type
Other Extension Metadata
Last Modified Date
2022-08-22
IP Status
No known IP claims.
Contributors
Joshua Ashton, Valve
Hans-Kristian Arntzen, Valve
Description
This extension allows applications to reduce descriptor memory footprint by
allowing a descriptor to be able to mutate to a given list of descriptor
types depending on which descriptor types are written into, or copied into a
descriptor set.
The main use case this extension intends to address is descriptor indexing
with
VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT
where the
descriptor types are completely generic, as this means applications can
allocate one large descriptor set, rather than having one large descriptor
set per descriptor type, which significantly bloats descriptor memory usage
and causes performance issues.
This extension also adds a mechanism to declare that a descriptor pool, and
therefore the descriptor sets that are allocated from it, reside only in
host memory; as such these descriptors can only be updated/copied, but not
bound.
These features together allow much more efficient emulation of the raw D3D12
binding model.
This extension is primarily intended to be useful for API layering efforts.
New Structures
VkMutableDescriptorTypeListEXT
Extending
VkDescriptorSetLayoutCreateInfo
VkDescriptorPoolCreateInfo
VkMutableDescriptorTypeCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMutableDescriptorTypeFeaturesEXT
New Enum Constants
VK_EXT_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME
VK_EXT_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION
Extending
VkDescriptorPoolCreateFlagBits
VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_EXT
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_EXT
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_MUTABLE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_EXT
Version History
Revision 1, 2022-08-22 (Jon Leech)
Initial version, promoted from
VK_VALVE_mutable_descriptor_type
VK_EXT_nested_command_buffer
Name String
VK_EXT_nested_command_buffer
Extension Type
Device extension
Registered Extension Number
452
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceNestedCommandBufferFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceNestedCommandBufferPropertiesEXT
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.
Version History
Revision 1, 2023-09-18 (Piers Daniell)
Internal revisions
VK_EXT_non_seamless_cube_map
Name String
VK_EXT_non_seamless_cube_map
Extension Type
Device extension
Registered Extension Number
423
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Uses
D3D support
OpenGL / ES support
Contact
Georg Lehmann
DadSchoorse
Extension Proposal
VK_EXT_non_seamless_cube_map
Other Extension Metadata
Last Modified Date
2021-09-04
IP Status
No known IP claims.
Contributors
Georg Lehmann
Description
This extension provides functionality to disable
cube map edge handling
on a per sampler level which matches the behavior
of other graphics APIs.
This extension may be useful for building translation layers for those APIs
or for porting applications that rely on this cube map behavior.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceNonSeamlessCubeMapFeaturesEXT
New Enum Constants
VK_EXT_NON_SEAMLESS_CUBE_MAP_EXTENSION_NAME
VK_EXT_NON_SEAMLESS_CUBE_MAP_SPEC_VERSION
Extending
VkSamplerCreateFlagBits
VK_SAMPLER_CREATE_NON_SEAMLESS_CUBE_MAP_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NON_SEAMLESS_CUBE_MAP_FEATURES_EXT
Version History
Revision 1, 2021-09-04 (Georg Lehmann)
First Version
VK_EXT_opacity_micromap
Name String
VK_EXT_opacity_micromap
Extension Type
Device extension
Registered Extension Number
397
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
SPIR-V Dependencies
SPV_EXT_opacity_micromap
Contact
Christoph Kubisch
pixeljetstream
Eric Werness
Extension Proposal
VK_EXT_opacity_micromap
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:
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 Object Types
VkMicromapEXT
New Commands
vkBuildMicromapsEXT
vkCmdBuildMicromapsEXT
vkCmdCopyMemoryToMicromapEXT
vkCmdCopyMicromapEXT
vkCmdCopyMicromapToMemoryEXT
vkCmdWriteMicromapsPropertiesEXT
vkCopyMemoryToMicromapEXT
vkCopyMicromapEXT
vkCopyMicromapToMemoryEXT
vkCreateMicromapEXT
vkDestroyMicromapEXT
vkGetDeviceMicromapCompatibilityEXT
vkGetMicromapBuildSizesEXT
vkWriteMicromapsPropertiesEXT
New Structures
VkCopyMemoryToMicromapInfoEXT
VkCopyMicromapInfoEXT
VkCopyMicromapToMemoryInfoEXT
VkMicromapBuildInfoEXT
VkMicromapBuildSizesInfoEXT
VkMicromapCreateInfoEXT
VkMicromapTriangleEXT
VkMicromapUsageEXT
VkMicromapVersionInfoEXT
Extending
VkAccelerationStructureGeometryTrianglesDataKHR
VkAccelerationStructureDenseGeometryFormatTrianglesDataAMDX
VkAccelerationStructureTrianglesOpacityMicromapEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceOpacityMicromapFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceOpacityMicromapPropertiesEXT
New Enums
VkBuildMicromapFlagBitsEXT
VkBuildMicromapModeEXT
VkCopyMicromapModeEXT
VkMicromapCreateFlagBitsEXT
VkMicromapTypeEXT
VkOpacityMicromapFormatEXT
VkOpacityMicromapSpecialIndexEXT
New Bitmasks
VkBuildMicromapFlagsEXT
VkMicromapCreateFlagsEXT
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_BIT_EXT
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISABLE_OPACITY_MICROMAPS_EXT
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_BIT_EXT
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_EXT
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_BIT_EXT
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_EXT
Extending
VkGeometryInstanceFlagBitsKHR
VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_BIT_EXT
VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_EXT
VK_GEOMETRY_INSTANCE_FORCE_OPACITY_MICROMAP_2_STATE_BIT_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;

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.
Version History
Revision 2, 2022-06-22 (Eric Werness)
EXTify and clean up for discussion
Revision 1, 2022-01-01 (Eric Werness)
Initial revision
VK_EXT_pageable_device_local_memory
Name String
VK_EXT_pageable_device_local_memory
Extension Type
Device extension
Registered Extension Number
413
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_memory_priority
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2021-08-24
Contributors
Hans-Kristian Arntzen, Valve
Axel Gneiting, id Software
Billy Khan, id Software
Daniel Koch, NVIDIA
Chris Lentini, NVIDIA
Joshua Schnarr, NVIDIA
Stu Smith, AMD
Description
Vulkan is frequently implemented on multi-user and multi-process operating
systems where the device-local memory can be shared by more than one
process.
On such systems the size of the device-local memory available to the
application may not be the full size of the memory heap at all times.
In order for these operating systems to support multiple applications the
device-local memory is virtualized and paging is used to move memory between
device-local and host-local memory heaps, transparent to the application.
The current Vulkan specification does not expose this behavior well and may
cause applications to make suboptimal memory choices when allocating memory.
For example, in a system with multiple applications running, the application
may think that device-local memory is full and revert to making
performance-sensitive allocations from host-local memory.
In reality the memory heap might not have been full, it just appeared to be
at the time memory consumption was queried, and a device-local allocation
would have succeeded.
A well designed operating system that implements pageable device-local
memory will try to have all memory allocations for the foreground
application paged into device-local memory, and paged out for other
applications as needed when not in use.
When this extension is exposed by the Vulkan implementation it indicates to
the application that the operating system implements pageable device-local
memory and the application should adjust its memory allocation strategy
accordingly.
The extension also exposes a new
vkSetDeviceMemoryPriorityEXT
function
to allow the application to dynamically adjust the priority of existing
memory allocations based on its current needs.
This will help the operating system page out lower priority memory
allocations before higher priority allocations when needed.
It will also help the operating system decide which memory allocations to
page back into device-local memory first.
To take best advantage of pageable device-local memory the application must
create the Vulkan device with the
VkPhysicalDevicePageableDeviceLocalMemoryFeaturesEXT
::
pageableDeviceLocalMemory
feature enabled.
When enabled the Vulkan implementation will allow device-local memory
allocations to be paged in and out by the operating system, and
may
not
return VK_ERROR_OUT_OF_DEVICE_MEMORY even if device-local memory appears to
be full, but will instead page this, or other allocations, out to make room.
The Vulkan implementation will also ensure that host-local memory
allocations will never be promoted to device-local memory by the operating
system, or consume device-local memory.
New Commands
vkSetDeviceMemoryPriorityEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePageableDeviceLocalMemoryFeaturesEXT
New Enum Constants
VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_EXTENSION_NAME
VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PAGEABLE_DEVICE_LOCAL_MEMORY_FEATURES_EXT
Version History
Revision 1, 2021-08-24 (Piers Daniell)
Initial revision
VK_EXT_pci_bus_info
Name String
VK_EXT_pci_bus_info
Extension Type
Device extension
Registered Extension Number
213
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2018-12-10
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Daniel Rakos, AMD
Description
This extension adds a new query to obtain PCI bus information about a
physical device.
Not all physical devices have PCI bus information, either due to the device
not being connected to the system through a PCI interface or due to platform
specific restrictions and policies.
Thus this extension is only expected to be supported by physical devices
which can provide the information.
As a consequence, applications should always check for the presence of the
extension string for each individual physical device for which they intend
to issue the new query for and should not have any assumptions about the
availability of the extension on any given platform.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePCIBusInfoPropertiesEXT
New Enum Constants
VK_EXT_PCI_BUS_INFO_EXTENSION_NAME
VK_EXT_PCI_BUS_INFO_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT
Version History
Revision 2, 2018-12-10 (Daniel Rakos)
Changed all members of the new structure to have the uint32_t type
Revision 1, 2018-10-11 (Daniel Rakos)
Initial revision
VK_EXT_physical_device_drm
Name String
VK_EXT_physical_device_drm
Extension Type
Device extension
Registered Extension Number
354
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Simon Ser
emersion
Other Extension Metadata
Last Modified Date
2021-06-09
IP Status
No known IP claims.
Contributors
Simon Ser
Description
This extension provides new facilities to query DRM properties for physical
devices, enabling users to match Vulkan physical devices with DRM nodes on
Linux.
Its functionality closely overlaps with
EGL_EXT_device_drm
Unlike the EGL extension, this extension does not expose a string containing
the name of the device file and instead exposes device minor numbers.
DRM defines multiple device node types.
Each physical device may have one primary node and one render node
associated.
Physical devices may have no primary node (e.g. if the device does not have
a display subsystem), may have no render node (e.g. if it is a software
rendering engine), or may have neither (e.g. if it is a software rendering
engine without a display subsystem).
To query DRM properties for a physical device, chain
VkPhysicalDeviceDrmPropertiesEXT
to
VkPhysicalDeviceProperties2
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDrmPropertiesEXT
New Enum Constants
VK_EXT_PHYSICAL_DEVICE_DRM_EXTENSION_NAME
VK_EXT_PHYSICAL_DEVICE_DRM_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRM_PROPERTIES_EXT
References
EGL_EXT_device_drm
Version History
Revision 1, 2021-06-09
First stable revision
VK_EXT_pipeline_library_group_handles
Name String
VK_EXT_pipeline_library_group_handles
Extension Type
Device extension
Registered Extension Number
499
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
and
VK_KHR_pipeline_library
Contact
Hans-Kristian Arntzen
HansKristian-Work
Extension Proposal
VK_EXT_pipeline_library_group_handles
Other Extension Metadata
Last Modified Date
2023-01-25
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
Stuart Smith, AMD
Ricardo Garcia, Igalia
Lionel Landwerlin, Intel
Eric Werness, NVIDIA
Daniel Koch, NVIDIA
Description
When using pipeline libraries in ray tracing pipelines, a library might get
linked into different pipelines in an incremental way.
An application can have a strategy where a ray tracing pipeline is comprised
of N pipeline libraries and is later augmented by creating a new pipeline
with N + 1 libraries.
Without this extension, all group handles must be re-queried as the group
handle is tied to the pipeline, not the library.
This is problematic for applications which aim to decouple construction of
record buffers and the linkage of ray tracing pipelines.
To aid in this, this extension enables support for querying group handles
directly from pipeline libraries.
Group handles obtained from a library
must
remain bitwise identical in any
VkPipeline
that links to the library.
With this feature, the extension also improves compatibility with DXR 1.1
AddToStateObject(), which guarantees that group handles returned remain
bitwise identical between parent and child pipelines.
In addition, querying group handles from COLLECTION objects is also
supported with that API.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineLibraryGroupHandlesFeaturesEXT
New Enum Constants
VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_EXTENSION_NAME
VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_LIBRARY_GROUP_HANDLES_FEATURES_EXT
Version History
Revision 1, 2023-01-25 (Hans-Kristian Arntzen)
Initial draft
VK_EXT_pipeline_properties
Name String
VK_EXT_pipeline_properties
Extension Type
Device extension
Registered Extension Number
373
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Mukund Keshava
mkeshavanv
Other Extension Metadata
Last Modified Date
2022-04-19
IP Status
No known IP claims.
Contributors
Mukund Keshava, NVIDIA
Daniel Koch, NVIDIA
Mark Bellamy, Arm
Description
Vulkan SC requires offline compilation of pipelines.
In order to support this, the pipeline state is represented in a
JSON schema
that is read by an offline tool for compilation.
One method of developing a Vulkan SC application is to author a Vulkan
application and use a layer to record and serialize the pipeline state and
shaders for offline compilation.
Each pipeline is represented by a separate JSON file, and can be identified
with a
pipelineIdentifier
Once the pipelines have been compiled by the offline pipeline cache
compiler, the Vulkan SC application can then use this
pipelineIdentifier
for identifying the pipeline via Vulkan SC’s
VkPipelineIdentifierInfo
structure.
This extension allows the Vulkan application to query the
pipelineIdentifier
associated with each pipeline so that the
application can store this with its pipeline metadata and the Vulkan SC
application will then use to map the same state to an entry in the Vulkan SC
pipeline cache.
It is expected that this extension will initially be implemented in the json
generation layer, although we can envision that there might be future uses
for it in native Vulkan drivers as well.
New Commands
vkGetPipelinePropertiesEXT
New Structures
VkPipelineInfoEXT
VkPipelinePropertiesIdentifierEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelinePropertiesFeaturesEXT
New Enum Constants
VK_EXT_PIPELINE_PROPERTIES_EXTENSION_NAME
VK_EXT_PIPELINE_PROPERTIES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROPERTIES_FEATURES_EXT
VK_STRUCTURE_TYPE_PIPELINE_INFO_EXT
VK_STRUCTURE_TYPE_PIPELINE_PROPERTIES_IDENTIFIER_EXT
Issues
(1) This extension does not make sense on a strict Vulkan SC implementation.
It may however be of potential use in a non-strict Vulkan SC implementation.
Should this extension be enabled as part of Vulkan SC as well?
RESOLVED
: No.
This extension will not be enabled for Vulkan SC.
(2) This is intended to be a general pipeline properties query, but is
currently only retrieving the pipeline identifier.
Should the pipeline identifier query be mandatory for this extension and for
all queries using this command?
RESOLVED
: Use
VkBaseOutStructure
for the return parameter.
Currently this is required to actually be a
VkPipelinePropertiesIdentifierEXT
structure, but that could be relaxed
in the future to allow other structure types or to allow other structures to
be chained in along with this one.
(3) Should there be a feature structure? Should it be required?
RESOLVED
: Add a feature structure, and a feature for querying pipeline
identifier, but allow it to be optional so that this extension can be used
as the basis for other pipeline property queries without requiring the
pipeline identifier to be supported.
Version History
Revision 1, 2022-04-19 (Mukund Keshava, Daniel Koch)
Initial draft
VK_EXT_post_depth_coverage
Name String
VK_EXT_post_depth_coverage
Extension Type
Device extension
Registered Extension Number
156
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_post_depth_coverage
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2017-07-17
Interactions and External Dependencies
This extension provides API support for
GL_ARB_post_depth_coverage
and
GL_EXT_post_depth_coverage
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_KHR_post_depth_coverage
which allows the fragment shader to control whether values in the
SampleMask
built-in input variable reflect the coverage after early
depth
and
stencil
tests are applied.
This extension adds a new
PostDepthCoverage
execution mode under the
SampleMaskPostDepthCoverage
capability.
When this mode is specified along with
EarlyFragmentTests
, the value of
an input variable decorated with the
SampleMask
built-in
reflects the coverage after the early fragment tests are applied.
Otherwise, it reflects the coverage before the depth and stencil tests.
When using GLSL source-based shading languages, the
post_depth_coverage
layout qualifier from GL_ARB_post_depth_coverage or
GL_EXT_post_depth_coverage maps to the
PostDepthCoverage
execution
mode.
New Enum Constants
VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME
VK_EXT_POST_DEPTH_COVERAGE_SPEC_VERSION
New SPIR-V Capabilities
SampleMaskPostDepthCoverage
Version History
Revision 1, 2017-07-17 (Daniel Koch)
Internal revisions
VK_EXT_present_timing
Name String
VK_EXT_present_timing
Extension Type
Device extension
Registered Extension Number
209
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_KHR_present_id2
and
VK_KHR_get_surface_capabilities2
and
VK_KHR_calibrated_timestamps
Contact
Lionel Duc
nvlduc
Extension Proposal
VK_EXT_present_timing
Other Extension Metadata
Last Modified Date
2024-10-09
IP Status
No known IP claims.
Contributors
Ian Elliott, Google
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Daniel Rakos, AMD
Daniel Stone, Collabora
Daniel Vetter, Intel
Aric Cyr, AMD
Faith Ekstrand, Intel
Nicolai Hähnle, AMD
Alon Or-Bach, Samsung
Niklas Smedberg, Unity Technologies
Tobias Hector, AMD
Lionel Duc, NVIDIA
Lina Versace, Google
Sebastian Wick, Red Hat
Jakob Bornecrantz, Collabora
David Kvasnica, NVIDIA
Description
This device extension allows an application that uses the
VK_KHR_swapchain
extension to obtain information about the
presentation engine’s display, to obtain timing information about each
present, and to schedule a present to happen no earlier than a desired time.
An application can use this to minimize various visual anomalies (e.g.
stuttering).
Traditional game and real-time animation applications need to correctly
position their geometry for when the presentable image will be presented to
the user.
To accomplish this, applications need various timing information about the
presentation engine’s display.
They need to know when presentable images were actually presented, and when
they could have been presented.
Applications also need to tell the presentation engine to display an image
no sooner than a given time.
This allows the application to avoid stuttering, so the animation looks
smooth to the user.
New Commands
vkGetPastPresentationTimingEXT
vkGetSwapchainTimeDomainPropertiesEXT
vkGetSwapchainTimingPropertiesEXT
vkSetSwapchainPresentTimingQueueSizeEXT
New Structures
VkPastPresentationTimingEXT
VkPastPresentationTimingInfoEXT
VkPastPresentationTimingPropertiesEXT
VkPresentStageTimeEXT
VkPresentTimingInfoEXT
VkSwapchainTimeDomainPropertiesEXT
VkSwapchainTimingPropertiesEXT
Extending
VkCalibratedTimestampInfoKHR
VkSwapchainCalibratedTimestampInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentTimingFeaturesEXT
Extending
VkPresentInfoKHR
VkPresentTimingsInfoEXT
Extending
VkSurfaceCapabilities2KHR
VkPresentTimingSurfaceCapabilitiesEXT
New Enums
VkPastPresentationTimingFlagBitsEXT
VkPresentStageFlagBitsEXT
VkPresentTimingInfoFlagBitsEXT
New Bitmasks
VkPastPresentationTimingFlagsEXT
VkPresentStageFlagsEXT
VkPresentTimingInfoFlagsEXT
New Enum Constants
VK_EXT_PRESENT_TIMING_EXTENSION_NAME
VK_EXT_PRESENT_TIMING_SPEC_VERSION
Extending
VkResult
VK_ERROR_PRESENT_TIMING_QUEUE_FULL_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PAST_PRESENTATION_TIMING_EXT
VK_STRUCTURE_TYPE_PAST_PRESENTATION_TIMING_INFO_EXT
VK_STRUCTURE_TYPE_PAST_PRESENTATION_TIMING_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_TIMING_FEATURES_EXT
VK_STRUCTURE_TYPE_PRESENT_TIMINGS_INFO_EXT
VK_STRUCTURE_TYPE_PRESENT_TIMING_INFO_EXT
VK_STRUCTURE_TYPE_PRESENT_TIMING_SURFACE_CAPABILITIES_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_CALIBRATED_TIMESTAMP_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_TIME_DOMAIN_PROPERTIES_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_TIMING_PROPERTIES_EXT
Extending
VkSwapchainCreateFlagBitsKHR
VK_SWAPCHAIN_CREATE_PRESENT_TIMING_BIT_EXT
Extending
VkTimeDomainKHR
VK_TIME_DOMAIN_PRESENT_STAGE_LOCAL_EXT
VK_TIME_DOMAIN_SWAPCHAIN_LOCAL_EXT
Issues
1) How does the application determine refresh duration, quanta for change,
whether FRR vs. VRR, etc.
The query returns two values: 1) a refresh-cycle duration
refreshDuration
), and 2) an indication whether the timing is
currently fixed (FRR) or variable (VRR).
If
refreshDuration
is zero, the platform cannot supply these values
until after at least one
vkQueuePresentKHR
has been done, from this
time (e.g. if
vkQueuePresentKHR
has been previously called for this
swapchain, at least one additional call must be made).
After calling
vkQueuePresentKHR
, the query can be repeated until
refreshDuration
is non-zero, at which point the FRR vs. VRR indication
will also be valid.
If the presentation engine’s
refreshDuration
is a fixed value, the
application’s image present duration (IPD) should be a multiple of
refreshDuration
That is, the quanta for changing the IPD is
refreshDuration
For example, if
refreshDuration
is 16.67ms, the IPD can be 16.67ms,
33.33ms, 50.0ms, etc.
If the presentation engine’s
refreshDuration
is variable,
refreshDuration
is the minimum value of the application’s IPD, and the
IPD can be larger by any quanta that is meaningful to the application.
For example, if the
refreshDuration
is 10ms (i.e. the maximum refresh
rate is 100Hz), the application can choose an IPD of 11ms, 13.33ms, 13.5ms,
or 66.0ms; any value greater than or equal to 10ms is valid.
There may be negative consequences for choosing an IPD that is too high, as
the presentation engine may actually have a practical maximum
refreshDuration
, where it needs to display the previous image again,
and during this time the presentation engine might delay displaying a
newly-presented image.
FRR displays on at least one platform (Wayland) are not necessarily fixed;
but can change over time.
For example, if a full-screen video player application is visible, the
display may operate at a 24Hz refresh cycle; and then later switch to 60Hz
when multiple windows are visible.
VRR displays on some platforms can also be seen as having different
characteristics over time.
For example, if an application’s window is full-screen-exclusive (i.e. no
other window or window system component is visible), the display can look
like a VRR display (however that is defined).
If the application’s window is not full-screen-exclusive (e.g. a normal
multi-window case), the display can look like an FRR display (i.e. because
the compositor is trying to treat all windows in a consistent manner).
A different issue will deal with how the timing characteristics can change
over time.
2) Do we return min/max values for refresh duration for VRR?
Return only the minimum value of refreshDuration for a VRR.
VRR displays have a minimum and maximum refresh rate, and therefore a
minimum and maximum refreshDuration.
It has been asserted that the display effectively does not have a minimum
refresh rate.
That is because if an application does not present soon enough, the display
hardware will automatically re-display the previous image.
However, when the display does that, an application cannot present a new
image for a certain period of time.
It is unclear about whether that period is large enough to cause visual
artifacts.
3) How to deal with changes in timing properties?
RESOLVED
: The
VkPastPresentationTimingPropertiesEXT
structure that
is returned by
vkGetPastPresentationTimingEXT
contains
timeDomainsCounter
, which is incremented if the time domain enabled
for the swapchain is not currently available.
An example of why display timing properties can change is if a surface
changes from being a window that’s a subset of the display size, to becoming
full-screen-exclusive.
While the surface was a subset of the display, a compositor might enforce
fixed timings on the surface (e.g. FRR of 60Hz), where the presentation
engine might be free to allow VRR behavior of a full-screen-exclusive
surface.
It is possible that a full-screen-exclusive window can become temporarily
obscured (e.g. when a short-term dialog pops up).
In this case, the surface might use FRR timings while the dialog is visible
and VRR otherwise.
4) One Query for all Timing info vs. an initial query to determine FRR vs.
VRR, and then FRR-specific vs VRR-specific queries?
RESOLVED
: Have one query, as described in issue 1, that can be called
whenever the application needs to obtain the timing properties of the
surface.
5) Query to determine time domain?
RESOLVED
: Have a query to determine the time domain.
This extension defines a basic swapchain-local time domain.
Other extensions can add other platform-specific time domains.
6) What time to use for targetPresentTime for early images?
RESOLVED
: Have no query for determining the current time in the PE’s time
domain; and do allow the special value of zero for targetPresentTime,
meaning that there is no target.
On some platforms, there is no way to determine the current time, nor to
determine surface timing properties until after at least one image has been
presented.
In such cases, the special value of zero allows the application to indicate
that timing feedback is desired, but that no targetPresentTime is requested.
Later, once the application has obtained feedback, it can specify
targetPresentTime by using the result’s actualPresentTime.
7) How long before an application’s request for new image duration is
honored?
Apparently, changes to some vendors' display hardware settings do not take
effect immediately.
It is not clear what settings, and therefore, it is not clear how to address
this issue.
8) Do we have a query for the anticipated latency from present to feedback?
RESOLVED
: Do not provide a query for the feedback latency.
There is some amount of latency from when an application calls
vkQueuePresentKHR to when the image is displayed to the user, to when
feedback is available to the application on when the image was actually
displayed to the user.
The first time (from the call till the image is presented) generally doesn’t
matter, because the application will likely be providing a targetPresentTime
(i.e. the application may have some indication for how long this will be).
However, the latency between targetPresentTime until feedback is available
may be much longer.
For example, on Android on the 1st-generation Pixel phone (60Hz FRR
display), the latency was approximately 5 refresh cycles (83.33ms).
For higher-frequency displays, the latency may have a larger number of
refresh cycles.
9) Do we have a query(s) about the number of VkPastPresentationTimingEXT
structs to keep?
RESOLVED
: Do not provide a query for the number of results the swapchain
is allowed to store before querying them with
vkGetPastPresentationTimingEXT.
Let the application specify that value with a dedicated API.
10) How is the SWAPCHAIN_LOCAL and STAGE_LOCAL time domain used with the
calibrated timestamps extension?
RESOLVED
: Define a struct to chain into
VkCalibratedTimestampInfoEXT::pNext that specifies a swapchain and present
stage.
11) Should VK_PRESENT_MODE_FIFO_LATEST_READY_EXT be part of this extension,
or split out into its own extension?
RESOLVED
: It is only tangentially related.
Split it out into its own extension and define the interaction here.
Version History
Revision 1, 2018-05-11 (Ian Elliott)
Internal revisions.
Revision 2, 2022-11-30 (Lionel Duc)
Rebase for public discussions.
Revision 3, 2024-10-09 (Lionel Duc)
Public revisions.
VK_EXT_primitive_restart_index
Name String
VK_EXT_primitive_restart_index
Extension Type
Device extension
Registered Extension Number
679
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_primitive_restart_index
Other Extension Metadata
Last Modified Date
2026-03-10
IP Status
No known IP claims.
Contributors
Mike Blumenkrantz, Valve
Spencer Fricke, LunarG
Ricardo Garcia, Igalia
Piers Daniell, NVIDIA
Description
This extension allows setting a custom primitive restart index.
It is primarily intended to support GL emulation.
New Commands
vkCmdSetPrimitiveRestartIndexEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePrimitiveRestartIndexFeaturesEXT
New Enum Constants
VK_EXT_PRIMITIVE_RESTART_INDEX_EXTENSION_NAME
VK_EXT_PRIMITIVE_RESTART_INDEX_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVE_RESTART_INDEX_FEATURES_EXT
Version History
Revision 1, 2026-03-10 (Mike Blumenkrantz)
Internal revisions
VK_EXT_primitive_topology_list_restart
Name String
VK_EXT_primitive_topology_list_restart
Extension Type
Device extension
Registered Extension Number
357
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
Shahbaz Youssefi
syoussefi
Other Extension Metadata
Last Modified Date
2021-01-11
IP Status
No known IP claims.
Contributors
Courtney Goeltzenleuchter, Google
Shahbaz Youssefi, Google
Description
This extension allows list primitives to use the primitive restart index
value.
This provides a more efficient implementation when layering OpenGL
functionality on Vulkan by avoiding emulation which incurs data copies.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePrimitiveTopologyListRestartFeaturesEXT
New Enum Constants
VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_EXTENSION_NAME
VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVE_TOPOLOGY_LIST_RESTART_FEATURES_EXT
Version History
Revision 0, 2020-09-14 (Courtney Goeltzenleuchter)
Internal revisions
Revision 1, 2021-01-11 (Shahbaz Youssefi)
Add the
primitiveTopologyPatchListRestart
feature
Internal revisions
VK_EXT_primitives_generated_query
Name String
VK_EXT_primitives_generated_query
Extension Type
Device extension
Registered Extension Number
383
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_transform_feedback
Special Use
OpenGL / ES support
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_primitives_generated_query
Other Extension Metadata
Last Modified Date
2022-01-24
Contributors
Shahbaz Youssefi, Google
Piers Daniell, NVIDIA
Faith Ekstrand, Collabora
Jan-Harald Fredriksen, Arm
Description
This extension adds support for a new query type to match OpenGL’s
GL_PRIMITIVES_GENERATED
to support layering.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePrimitivesGeneratedQueryFeaturesEXT
New Enum Constants
VK_EXT_PRIMITIVES_GENERATED_QUERY_EXTENSION_NAME
VK_EXT_PRIMITIVES_GENERATED_QUERY_SPEC_VERSION
Extending
VkQueryType
VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVES_GENERATED_QUERY_FEATURES_EXT
Issues
1) Can the query from
VK_EXT_transform_feedback
be used instead?
RESOLVED
: No.
While the query from VK_EXT_transform_feedback can produce the same results
as in this extension, it is only available while transform feedback is
active.
The OpenGL
GL_PRIMITIVES_GENERATED
query is independent from transform
feedback.
Emulation through artificial transform feedback is unnecessarily
inefficient.
2) Can
VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT
be used
instead?
RESOLVED
: It could, but we prefer the extension for simplicity.
Vulkan requires that only one query be active at a time.
If both the
GL_PRIMITIVES_GENERATED
and the
GL_CLIPPING_INPUT_PRIMITIVES_ARB
queries need to be simultaneously
enabled, emulation of both through
VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT
is inconvenient.
3) On some hardware, this query cannot be implemented if
VkPipelineRasterizationStateCreateInfo
::
rasterizerDiscardEnable
is enabled.
How will this be handled?
RESOLVED
: A feature flag is exposed by this extension for this.
On said hardware, the GL implementation disables rasterizer-discard and
achieves the same effect through other means.
It will not be able to do the same in Vulkan due to lack of state
information.
A feature flag is exposed by this extension so the OpenGL implementation on
top of Vulkan would be able to implement a similar workaround.
4) On some hardware, this query cannot be implemented for non-zero query
indices.
How will this be handled?
RESOLVED
: A feature flag is exposed by this extension for this.
If this feature is not present, the query from
VK_EXT_transform_feedback
can be used to the same effect.
5) How is the interaction of this extension with
transformFeedbackRasterizationStreamSelect
handled?
RESOLVED
: Disallowed for non-zero streams.
In OpenGL, the rasterization stream is always stream zero.
Version History
Revision 1, 2021-06-23 (Shahbaz Youssefi)
Internal revisions
VK_EXT_provoking_vertex
Name String
VK_EXT_provoking_vertex
Extension Type
Device extension
Registered Extension Number
255
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
Jesse Hall
jessehall
Other Extension Metadata
Last Modified Date
2021-02-22
IP Status
No known IP claims.
Contributors
Alexis Hétu, Google
Bill Licea-Kane, Qualcomm
Daniel Koch, Nvidia
Jamie Madill, Google
Jan-Harald Fredriksen, Arm
Faith Ekstrand, Intel
Jeff Bolz, Nvidia
Jeff Leger, Qualcomm
Jesse Hall, Google
Jörg Wagner, Arm
Matthew Netsch, Qualcomm
Mike Blumenkrantz, Valve
Piers Daniell, Nvidia
Tobias Hector, AMD
Description
This extension allows changing the provoking vertex convention between
Vulkan’s default convention (first vertex) and OpenGL’s convention (last
vertex).
This extension is intended for use by API-translation layers that implement
APIs like OpenGL on top of Vulkan, and need to match the source API’s
provoking vertex convention.
Applications using Vulkan directly should use Vulkan’s default convention.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceProvokingVertexFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceProvokingVertexPropertiesEXT
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationProvokingVertexStateCreateInfoEXT
New Enums
VkProvokingVertexModeEXT
New Enum Constants
VK_EXT_PROVOKING_VERTEX_EXTENSION_NAME
VK_EXT_PROVOKING_VERTEX_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_PROVOKING_VERTEX_STATE_CREATE_INFO_EXT
Issues
1) At what granularity should this state be set?
RESOLVED
: At pipeline bind, with an optional per-render pass restriction.
The most natural place to put this state is in the graphics pipeline object.
Some implementations require it to be known when creating the pipeline, and
pipeline state is convenient for implementing OpenGL 3.2’s
glProvokingVertex, which can change the state between draw calls.
However, some implementations can only change it approximately render pass
granularity.
To accommodate both, provoking vertex will be pipeline state, but
implementations can require that only one mode is used within a render pass
instance; the render pass’s mode is chosen implicitly when the first
pipeline is bound.
2) Does the provoking vertex mode affect the order that vertices are written
to transform feedback buffers?
RESOLVED
: Yes, to enable layered implementations of OpenGL and D3D.
All of OpenGL, OpenGL ES, and Direct3D 11 require that vertices are written
to transform feedback buffers such that flat-shaded attributes have the same
value when drawing the contents of the transform feedback buffer as they did
in the original drawing when the transform feedback buffer was written
(assuming the provoking vertex mode has not changed, in APIs that support
more than one mode).
Version History
Revision 1, (1c) 2021-02-22 (Jesse Hall)
Added
VkPhysicalDeviceProvokingVertexPropertiesEXT::transformFeedbackPreservesTriangleFanProvokingVertex
to accommodate implementations that cannot change the transform
feedback vertex order for triangle fans.
Revision 1, (1b) 2020-06-14 (Jesse Hall)
Added
VkPhysicalDeviceProvokingVertexFeaturesEXT::transformFeedbackPreservesProvokingVertex
and required that transform feedback write vertices so as to preserve
the provoking vertex of each primitive.
Revision 1, (1a) 2019-10-23 (Jesse Hall)
Initial draft, based on a proposal by Alexis Hétu
VK_EXT_queue_family_foreign
Name String
VK_EXT_queue_family_foreign
Extension Type
Device extension
Registered Extension Number
127
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
James Jones
cubanismo
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 for
VK_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/from
VK_QUEUE_FAMILY_EXTERNAL_KHR
New Enum Constants
VK_EXT_QUEUE_FAMILY_FOREIGN_EXTENSION_NAME
VK_EXT_QUEUE_FAMILY_FOREIGN_SPEC_VERSION
VK_QUEUE_FAMILY_FOREIGN_EXT
Version History
Revision 1, 2017-11-01 (Lina Versace)
Squashed internal revisions
VK_EXT_rasterization_order_attachment_access
Name String
VK_EXT_rasterization_order_attachment_access
Extension Type
Device extension
Registered Extension Number
464
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_EXT_rasterization_order_attachment_access
Other Extension Metadata
Last Modified Date
2026-01-16
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Jan-Harald Fredriksen, Arm
Description
This extension extends the mechanism of input attachments to allow access to
framebuffer attachments that are used both as input and as color or
depth/stencil attachments from one fragment to the next, in rasterization
order, without explicit synchronization.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRasterizationOrderAttachmentAccessFeaturesEXT
New Enums
VkPipelineColorBlendStateCreateFlagBits
VkPipelineDepthStencilStateCreateFlagBits
New Enum Constants
VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME
VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION
Extending
VkPipelineColorBlendStateCreateFlagBits
VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT
Extending
VkPipelineDepthStencilStateCreateFlagBits
VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT
VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_EXT
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_EXT
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT
Examples
None.
Version History
Revision 1, 2022-07-04 (Jan-Harald Fredriksen)
Initial draft
Updated Issues section 2026-01-16
VK_EXT_ray_tracing_invocation_reorder
Name String
VK_EXT_ray_tracing_invocation_reorder
Extension Type
Device extension
Registered Extension Number
582
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
SPIR-V Dependencies
SPV_EXT_shader_invocation_reorder
Contact
Eric Werness
ewerness-nv
Extension Proposal
VK_EXT_ray_tracing_invocation_reorder
Other Extension Metadata
Last Modified Date
2025-11-12
Interactions and External Dependencies
This extension provides API support for
GL_EXT_shader_invocation_reorder
Contributors
Eric Werness, NVIDIA
Ashwin Lele, NVIDIA
Daniel Koch, NVIDIA
Vikram Kushwaha, NVIDIA
Piers Daniell, NVIDIA
Stu Smith, AMD
Aaron Hagan, AMD
Tyler Nowicki, AMD
Sebastian Neubauer, AMD
Radoslaw Drabinski, Intel
Sven Woop, Intel
Aleksandra Krstic, QUALCOMM
Andrew Garrard, Imagination Technologies
Mathieu Robart, Arm Limited
Tom Olson, Khronos
Ralph Potter, Samsung Electronics
Antonio Caggiano, LunarG
Description
The ray tracing pipeline API provides some ability to reorder for locality,
but it is useful to have more control over how the reordering happens and
what information is included in the reordering.
The shader API provides a hit object to contain result information from the
hit which can be used as part of the explicit sorting plus options that
contain an integer for hint bits to use to add more coherency.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingInvocationReorderFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRayTracingInvocationReorderPropertiesEXT
New Enums
VkRayTracingInvocationReorderModeEXT
New Enum Constants
VK_EXT_RAY_TRACING_INVOCATION_REORDER_EXTENSION_NAME
VK_EXT_RAY_TRACING_INVOCATION_REORDER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_PROPERTIES_EXT
Version History
Revision 1, 2025-11-12 (Eric Werness)
Internal development - forked from NV
VK_EXT_rgba10x6_formats
Name String
VK_EXT_rgba10x6_formats
Extension Type
Device extension
Registered Extension Number
345
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2021-09-29
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm
Graeme Leese, Broadcom
Spencer Fricke, Samsung
Description
This extension enables the
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
format to be used without
sampler Y′C
conversion
enabled.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRGBA10X6FormatsFeaturesEXT
New Enum Constants
VK_EXT_RGBA10X6_FORMATS_EXTENSION_NAME
VK_EXT_RGBA10X6_FORMATS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RGBA10X6_FORMATS_FEATURES_EXT
Issues
1) Should we reuse the existing format enumeration or introduce a new one?
RESOLVED
: We reuse an existing format enumeration,
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
, that was previously
exclusively used for YCbCr and therefore had a set of limitations related to
that usage.
The alternative was to introduce a new format token with exactly the same
bit representation as the existing token, but without the limitations.
2) Should we only introduce
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
or also 1-3 component
variations?
RESOLVED
: Only the 4-component format is introduced because the 1- and 2-
component variations are already not exclusive to YCbCr, and the 3-component
variation is not a good match for hardware capabilities.
Version History
Revision 1, 2021-09-29 (Jan-Harald Fredriksen)
Initial EXT version
VK_EXT_sample_locations
Name String
VK_EXT_sample_locations
Extension Type
Device extension
Registered Extension Number
144
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2017-08-02
Contributors
Mais Alnasser, AMD
Matthaeus G. Chajdas, AMD
Maciej Jesionowski, AMD
Daniel Rakos, AMD
Slawomir Grajewski, Intel
Jeff Bolz, NVIDIA
Bill Licea-Kane, Qualcomm
Description
This extension allows an application to modify the locations of samples
within a pixel used in rasterization.
Additionally, it allows applications to specify different sample locations
for each pixel in a group of adjacent pixels, which
can
increase
antialiasing quality (particularly if a custom resolve shader is used that
takes advantage of these different locations).
It is common for implementations to optimize the storage of depth values by
storing values that
can
be used to reconstruct depth at each sample
location, rather than storing separate depth values for each sample.
For example, the depth values from a single triangle
may
be represented
using plane equations.
When the depth value for a sample is needed, it is automatically evaluated
at the sample location.
Modifying the sample locations causes the reconstruction to no longer
evaluate the same depth values as when the samples were originally
generated, thus the depth aspect of a depth/stencil attachment
must
be
cleared before rendering to it using different sample locations.
Some implementations
may
need to evaluate depth image values while
performing image layout transitions.
To accommodate this, instances of the
VkSampleLocationsInfoEXT
structure
can
be specified for each situation where an explicit or
automatic layout transition has to take place.
VkSampleLocationsInfoEXT
can
be chained from
VkImageMemoryBarrier
structures to provide sample locations for layout
transitions performed by
vkCmdWaitEvents
and
vkCmdPipelineBarrier
calls, and
VkRenderPassSampleLocationsBeginInfoEXT
can
be chained from
VkRenderPassBeginInfo
to provide sample locations for layout
transitions performed implicitly by a render pass instance.
New Commands
vkCmdSetSampleLocationsEXT
vkGetPhysicalDeviceMultisamplePropertiesEXT
New Structures
VkAttachmentSampleLocationsEXT
VkMultisamplePropertiesEXT
VkSampleLocationEXT
VkSubpassSampleLocationsEXT
Extending
VkImageMemoryBarrier
VkImageMemoryBarrier2
VkSampleLocationsInfoEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceSampleLocationsPropertiesEXT
Extending
VkPipelineMultisampleStateCreateInfo
VkPipelineSampleLocationsStateCreateInfoEXT
Extending
VkRenderPassBeginInfo
VkRenderPassSampleLocationsBeginInfoEXT
New Enum Constants
VK_EXT_SAMPLE_LOCATIONS_EXTENSION_NAME
VK_EXT_SAMPLE_LOCATIONS_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_MULTISAMPLE_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT
VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT
Issues
1) When using with Dynamic Rendering, is there a
VkRenderPassSampleLocationsBeginInfoEXT equivalent struct
RESOLVED
: No, there are no subpasses that need to have a sample location
set.
Version History
Revision 1, 2017-08-02 (Daniel Rakos)
Internal revisions
VK_EXT_shader_64bit_indexing
Name String
VK_EXT_shader_64bit_indexing
Extension Type
Device extension
Registered Extension Number
628
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_shader_64bit_indexing
Contact
Jeff Bolz
jeffbolznv
Extension Proposal
VK_EXT_shader_64bit_indexing
Other Extension Metadata
Last Modified Date
2025-05-02
Interactions and External Dependencies
This extension provides API support for
GL_EXT_shader_64bit_indexing
Contributors
Jeff Bolz, NVIDIA
Description
This extension relaxes the maxStorageBufferRange limit, allowing more than
4GB to be accessed through a buffer binding (or through a buffer device
address).
It adds pipeline and shader creation flags that request 64-bit addressing
support, and
defines
which addressing calculations
use 64 bits of range.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShader64BitIndexingFeaturesEXT
New Enum Constants
VK_EXT_SHADER_64BIT_INDEXING_EXTENSION_NAME
VK_EXT_SHADER_64BIT_INDEXING_SPEC_VERSION
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_64_BIT_INDEXING_BIT_EXT
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_64_BIT_INDEXING_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_64_BIT_INDEXING_FEATURES_EXT
Issues
Version History
Revision 1, 2025-05-02 (Jeff Bolz)
Initial revisions
VK_EXT_shader_atomic_float
Name String
VK_EXT_shader_atomic_float
Extension Type
Device extension
Registered Extension Number
261
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::sparseImageFloat32AtomicAdd
Interacts with VkPhysicalDeviceShaderAtomicFloatFeaturesEXT::sparseImageFloat32Atomics
SPIR-V Dependencies
SPV_EXT_shader_atomic_float_add
Contact
Vikram Kushwaha
vkushwaha-nv
Other Extension Metadata
Last Modified Date
2020-07-15
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_EXT_shader_atomic_float
Contributors
Vikram Kushwaha, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension allows a shader to contain floating-point atomic operations
on buffer, workgroup, and image memory.
It also advertises the SPIR-V
AtomicFloat32AddEXT
and
AtomicFloat64AddEXT
capabilities that allows atomic addition on
floating-points numbers.
The supported operations include
OpAtomicFAddEXT
OpAtomicExchange
OpAtomicLoad
and
OpAtomicStore
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderAtomicFloatFeaturesEXT
New Enum Constants
VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME
VK_EXT_SHADER_ATOMIC_FLOAT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_FEATURES_EXT
New SPIR-V Capabilities
AtomicFloat32AddEXT
AtomicFloat64AddEXT
Version History
Revision 1, 2020-07-15 (Vikram Kushwaha)
Internal revisions
VK_EXT_shader_atomic_float2
Name String
VK_EXT_shader_atomic_float2
Extension Type
Device extension
Registered Extension Number
274
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_EXT_shader_atomic_float
API Interactions
Interacts with VkPhysicalDeviceShaderAtomicFloat2FeaturesEXT::sparseImageFloat32AtomicMinMax
SPIR-V Dependencies
SPV_EXT_shader_atomic_float16_add
SPV_EXT_shader_atomic_float_min_max
Contact
Faith Ekstrand
gfxstrand
Other Extension Metadata
Last Modified Date
2020-08-14
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GLSL_EXT_shader_atomic_float2
Contributors
Faith Ekstrand, Intel
Description
This extension allows a shader to perform 16-bit floating-point atomic
operations on buffer and workgroup memory as well as floating-point atomic
minimum and maximum operations on buffer, workgroup, and image memory.
It advertises the SPIR-V
AtomicFloat16AddEXT
capability which allows
atomic add operations on 16-bit floating-point numbers and the SPIR-V
AtomicFloat16MinMaxEXT
AtomicFloat32MinMaxEXT
and
AtomicFloat64MinMaxEXT
capabilities which allow atomic minimum and
maximum operations on floating-point numbers.
The supported operations include
OpAtomicFAddEXT
OpAtomicFMinEXT
and
OpAtomicFMaxEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderAtomicFloat2FeaturesEXT
New Enum Constants
VK_EXT_SHADER_ATOMIC_FLOAT_2_EXTENSION_NAME
VK_EXT_SHADER_ATOMIC_FLOAT_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_2_FEATURES_EXT
Issues
1) Should this extension add support for 16-bit image atomics?
RESOLVED
: No.
While Vulkan supports creating storage images with
VK_FORMAT_R16_SFLOAT
and doing load and store on them, the data in the
shader has a 32-bit representation.
Vulkan currently has no facility for even basic reading or writing such
images using 16-bit float values in the shader.
Adding such functionality would be required before 16-bit image atomics
would make sense and is outside the scope of this extension.
New SPIR-V Capabilities
AtomicFloat32MinMaxEXT
AtomicFloat32MinMaxEXT
AtomicFloat32MinMaxEXT
AtomicFloat64MinMaxEXT
Version History
Revision 1, 2020-08-14 (Faith Ekstrand)
Internal revisions
VK_EXT_shader_float8
Name String
VK_EXT_shader_float8
Extension Type
Device extension
Registered Extension Number
568
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_KHR_cooperative_matrix
SPIR-V Dependencies
SPV_EXT_float8
Contact
Kevin Petit
kpet
Extension Proposal
VK_EXT_shader_float8
Other Extension Metadata
Last Modified Date
2025-04-16
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Stu Smith, AMD
Jeff Bolz, NVIDIA
Craig Graham, Samsung
Description
This extension enables support for 8-bit floating-point data types as
defined in SPV_EXT_float8.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderFloat8FeaturesEXT
New Enum Constants
VK_EXT_SHADER_FLOAT8_EXTENSION_NAME
VK_EXT_SHADER_FLOAT8_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT8_FEATURES_EXT
If
VK_KHR_cooperative_matrix
is supported:
Extending
VkComponentTypeKHR
VK_COMPONENT_TYPE_FLOAT8_E4M3_EXT
VK_COMPONENT_TYPE_FLOAT8_E5M2_EXT
New SPIR-V Capabilities
Float8EXT
Float8CooperativeMatrixEXT
Issues
1) Resolve interactions with the changes VK_KHR_shader_float16 makes to
rules for denorm flushing (always allowed by default for all FP formats).
How to describe the requirement to preserve subnormals?
RESOLVED
: Subnormals are always preserved when converting FP8 values to
IEEE 754 binary 16.
In all other cases, subnormals may be flushed to zero.
Version History
Revision 1, 2025-04-16 (Kévin Petit)
Initial draft
VK_EXT_shader_image_atomic_int64
Name String
VK_EXT_shader_image_atomic_int64
Extension Type
Device extension
Registered Extension Number
235
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_shader_image_int64
Contact
Tobias Hector
tobski
Other Extension Metadata
Last Modified Date
2020-07-14
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GLSL_EXT_shader_image_int64
Contributors
Matthaeus Chajdas, AMD
Graham Wihlidal, Epic Games
Tobias Hector, AMD
Jeff Bolz, Nvidia
Faith Ekstrand, Intel
Description
This extension extends existing 64-bit integer atomic support to enable
these operations on images as well.
When working with large 2- or 3-dimensional data sets (e.g. rasterization or
screen-space effects), image accesses are generally more efficient than
equivalent buffer accesses.
This extension allows applications relying on 64-bit integer atomics in this
manner to quickly improve performance with only relatively minor code
changes.
64-bit integer atomic support is guaranteed for optimally tiled images with
the
VK_FORMAT_R64_UINT
and
VK_FORMAT_R64_SINT
formats.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderImageAtomicInt64FeaturesEXT
New Enum Constants
VK_EXT_SHADER_IMAGE_ATOMIC_INT64_EXTENSION_NAME
VK_EXT_SHADER_IMAGE_ATOMIC_INT64_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_ATOMIC_INT64_FEATURES_EXT
Version History
Revision 1, 2020-07-14 (Tobias Hector)
Initial draft
VK_EXT_shader_long_vector
Name String
VK_EXT_shader_long_vector
Extension Type
Device extension
Registered Extension Number
636
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.2
API Interactions
Interacts with VK_KHR_workgroup_memory_explicit_layout
SPIR-V Dependencies
SPV_EXT_long_vector
Contact
Jeff Bolz
jeffbolznv
Extension Proposal
VK_EXT_shader_long_vector
Other Extension Metadata
Last Modified Date
2025-06-24
Interactions and External Dependencies
This extension requires
SPV_EXT_long_vector
This extension provides API support for
GL_EXT_long_vector
Contributors
Jeff Bolz, NVIDIA
Spencer Fricke, LunarG
Description
This extension adds support for using vector types with more than four
components in SPIR-V.
Long vector types are defined by the
SPV_EXT_long_vector
SPIR-V extension
and can be used with the
GL_EXT_long_vector
GLSL
extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderLongVectorFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderLongVectorPropertiesEXT
New Enum Constants
VK_EXT_SHADER_LONG_VECTOR_EXTENSION_NAME
VK_EXT_SHADER_LONG_VECTOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_LONG_VECTOR_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_LONG_VECTOR_PROPERTIES_EXT
New SPIR-V Capabilities
LongVectorEXT
Issues
Version History
Revision 1, 2025-06-24 (Jeff Bolz)
Initial revisions
VK_EXT_shader_module_identifier
Name String
VK_EXT_shader_module_identifier
Extension Type
Device extension
Registered Extension Number
463
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_pipeline_creation_cache_control
or
Vulkan Version 1.3
Contact
Hans-Kristian Arntzen
HansKristian-Work
Extension Proposal
VK_EXT_shader_module_identifier
Other Extension Metadata
Last Modified Date
2022-05-16
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
Ricardo Garcia, Igalia
Piers Daniell, NVIDIA
Jan-Harald Fredriksen, Arm
Tom Olson, Arm
Faith Ekstrand, Collabora
Description
Some applications generate SPIR-V code at runtime.
When pipeline caches are primed, either explicitly through e.g.
VkPipelineCache
mechanisms, or implicitly through driver managed
caches, having to re-generate SPIR-V modules is redundant.
SPIR-V modules could be cached on disk by an application, but the extra disk
size requirement might be prohibitive in some use cases.
This extension adds the ability for an application to query a small
identifier associated with a
VkShaderModule
On subsequent runs of the application, the same identifier
can
be provided
in lieu of a
VkShaderModule
object.
A pipeline creation call with such a module
may
succeed if a pipeline could
be created without invoking compilation, and information inside the SPIR-V
module is not required by the implementation.
VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT
must
be used
if only the identifier is provided, and this use case is intended to work
like a non-blocking, speculative compile.
Applications
can
fallback as necessary.
The main motivation for identifying the module itself and not the entire
pipeline is that pipeline identifiers change when a driver is updated, but
module identifiers are expected to be stable for any particular driver
implementation.
This approach is helpful for shader pre-compilation systems which can prime
pipeline caches ahead of time.
When on-disk pipeline caches are updated, the same shader identifiers could
lead to a pipeline cache hit.
New Commands
vkGetShaderModuleCreateInfoIdentifierEXT
vkGetShaderModuleIdentifierEXT
New Structures
VkShaderModuleIdentifierEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderModuleIdentifierFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderModuleIdentifierPropertiesEXT
Extending
VkPipelineShaderStageCreateInfo
VkPipelineShaderStageModuleIdentifierCreateInfoEXT
New Enum Constants
VK_EXT_SHADER_MODULE_IDENTIFIER_EXTENSION_NAME
VK_EXT_SHADER_MODULE_IDENTIFIER_SPEC_VERSION
VK_MAX_SHADER_MODULE_IDENTIFIER_SIZE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_MODULE_IDENTIFIER_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_SHADER_MODULE_IDENTIFIER_EXT
Version History
Revision 1, 2022-03-16 (Hans-Kristian Arntzen)
Initial draft
VK_EXT_shader_object
Name String
VK_EXT_shader_object
Extension Type
Device extension
Registered Extension Number
483
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
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_clamp_control
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
VK_EXT_shader_object
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
Caterina Shablia, 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 Object Types
VkShaderEXT
New Commands
vkCmdBindShadersEXT
vkCmdBindVertexBuffers2EXT
vkCmdSetAlphaToCoverageEnableEXT
vkCmdSetAlphaToOneEnableEXT
vkCmdSetColorBlendEnableEXT
vkCmdSetColorBlendEquationEXT
vkCmdSetColorWriteMaskEXT
vkCmdSetCullModeEXT
vkCmdSetDepthBiasEnableEXT
vkCmdSetDepthBoundsTestEnableEXT
vkCmdSetDepthClampEnableEXT
vkCmdSetDepthCompareOpEXT
vkCmdSetDepthTestEnableEXT
vkCmdSetDepthWriteEnableEXT
vkCmdSetFrontFaceEXT
vkCmdSetLogicOpEXT
vkCmdSetLogicOpEnableEXT
vkCmdSetPatchControlPointsEXT
vkCmdSetPolygonModeEXT
vkCmdSetPrimitiveRestartEnableEXT
vkCmdSetPrimitiveTopologyEXT
vkCmdSetRasterizationSamplesEXT
vkCmdSetRasterizerDiscardEnableEXT
vkCmdSetSampleMaskEXT
vkCmdSetScissorWithCountEXT
vkCmdSetStencilOpEXT
vkCmdSetStencilTestEnableEXT
vkCmdSetTessellationDomainOriginEXT
vkCmdSetVertexInputEXT
vkCmdSetViewportWithCountEXT
vkCreateShadersEXT
vkDestroyShaderEXT
vkGetShaderBinaryDataEXT
If
VK_EXT_blend_operation_advanced
is supported:
vkCmdSetColorBlendAdvancedEXT
If
VK_EXT_conservative_rasterization
is supported:
vkCmdSetConservativeRasterizationModeEXT
vkCmdSetExtraPrimitiveOverestimationSizeEXT
If
VK_EXT_depth_clamp_control
is supported:
vkCmdSetDepthClampRangeEXT
If
VK_EXT_depth_clip_control
is supported:
vkCmdSetDepthClipNegativeOneToOneEXT
If
VK_EXT_depth_clip_enable
is supported:
vkCmdSetDepthClipEnableEXT
If
VK_EXT_line_rasterization
is supported:
vkCmdSetLineRasterizationModeEXT
vkCmdSetLineStippleEnableEXT
If
VK_EXT_provoking_vertex
is supported:
vkCmdSetProvokingVertexModeEXT
If
VK_EXT_sample_locations
is supported:
vkCmdSetSampleLocationsEnableEXT
If
VK_EXT_transform_feedback
is supported:
vkCmdSetRasterizationStreamEXT
If
VK_NV_clip_space_w_scaling
is supported:
vkCmdSetViewportWScalingEnableNV
If
VK_NV_coverage_reduction_mode
is supported:
vkCmdSetCoverageReductionModeNV
If
VK_NV_fragment_coverage_to_color
is supported:
vkCmdSetCoverageToColorEnableNV
vkCmdSetCoverageToColorLocationNV
If
VK_NV_framebuffer_mixed_samples
is supported:
vkCmdSetCoverageModulationModeNV
vkCmdSetCoverageModulationTableEnableNV
vkCmdSetCoverageModulationTableNV
If
VK_NV_representative_fragment_test
is supported:
vkCmdSetRepresentativeFragmentTestEnableNV
If
VK_NV_shading_rate_image
is supported:
vkCmdSetShadingRateImageEnableNV
If
VK_NV_viewport_swizzle
is supported:
vkCmdSetViewportSwizzleNV
New Structures
VkColorBlendAdvancedEXT
VkColorBlendEquationEXT
VkShaderCreateInfoEXT
VkVertexInputAttributeDescription2EXT
VkVertexInputBindingDescription2EXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderObjectFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderObjectPropertiesEXT
Extending
VkPipelineShaderStageCreateInfo
VkShaderCreateInfoEXT
VkShaderRequiredSubgroupSizeCreateInfoEXT
New Enums
VkShaderCodeTypeEXT
VkShaderCreateFlagBitsEXT
New Bitmasks
VkShaderCreateFlagsEXT
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_fragment_density_map
is supported:
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT
If
VK_EXT_mesh_shader
or
VK_NV_mesh_shader
is supported:
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_NO_TASK_SHADER_BIT_EXT
If
VK_EXT_subgroup_size_control
or
Vulkan 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
Vulkan 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);
Version History
Revision 1, 2023-03-30 (Daniel Story)
Initial draft
VK_EXT_shader_replicated_composites
Name String
VK_EXT_shader_replicated_composites
Extension Type
Device extension
Registered Extension Number
565
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_replicated_composites
Contact
Kevin Petit
kpet
Extension Proposal
VK_EXT_shader_replicated_composites
Last Modified Date
2024-02-08
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
This extension adds support for creating composites from a single value in
SPIR-V modules, as defined by SPV_EXT_replicated_composites.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderReplicatedCompositesFeaturesEXT
New Enum Constants
VK_EXT_SHADER_REPLICATED_COMPOSITES_EXTENSION_NAME
VK_EXT_SHADER_REPLICATED_COMPOSITES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_REPLICATED_COMPOSITES_FEATURES_EXT
New SPIR-V Capabilities
ReplicatedCompositesEXT
Version History
Revision 1, 2024-02-08 (Kévin Petit)
Initial revision
VK_EXT_shader_stencil_export
Name String
VK_EXT_shader_stencil_export
Extension Type
Device extension
Registered Extension Number
141
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_EXT_shader_stencil_export
Contact
Dominik Witczak
dominikwitczakamd
Other Extension Metadata
Last Modified Date
2017-07-19
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_ARB_shader_stencil_export
Contributors
Dominik Witczak, AMD
Daniel Rakos, AMD
Rex Xu, AMD
Description
This extension adds support for the SPIR-V extension
SPV_EXT_shader_stencil_export
, providing a mechanism whereby a shader may
generate the stencil reference value per invocation.
When stencil testing is enabled, this allows the test to be performed
against the value generated in the shader.
New Enum Constants
VK_EXT_SHADER_STENCIL_EXPORT_EXTENSION_NAME
VK_EXT_SHADER_STENCIL_EXPORT_SPEC_VERSION
Version History
Revision 1, 2017-07-19 (Dominik Witczak)
Initial draft
VK_EXT_shader_subgroup_partitioned
Name String
VK_EXT_shader_subgroup_partitioned
Extension Type
Device extension
Registered Extension Number
663
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_shader_subgroup_partitioned
SPV_NV_shader_subgroup_partitioned
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2025-11-12
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_subgroup_partitioned
Contributors
Jeff Bolz, NVIDIA
Description
This extension enables support for a new class of
group operations
on
subgroups
via the
GL_NV_shader_subgroup_partitioned
GLSL extension and
SPV_EXT_shader_subgroup_partitioned
SPIR-V extension.
Support for these new operations is advertised via the
VK_SUBGROUP_FEATURE_PARTITIONED_BIT_EXT
bit.
Note that there is not a new GLSL extension since
SPV_EXT_shader_subgroup_partitioned
is compatible with
SPV_NV_shader_subgroup_partitioned
, so the
GL_NV_shader_subgroup_partitioned
GLSL extension can still be used.
This extension requires Vulkan 1.1, for general subgroup support.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderSubgroupPartitionedFeaturesEXT
New Enum Constants
VK_EXT_SHADER_SUBGROUP_PARTITIONED_EXTENSION_NAME
VK_EXT_SHADER_SUBGROUP_PARTITIONED_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_PARTITIONED_FEATURES_EXT
Extending
VkSubgroupFeatureFlagBits
VK_SUBGROUP_FEATURE_PARTITIONED_BIT_EXT
Version History
Revision 1, 2025-11-12 (Jeff Bolz)
Promoted from
VK_NV_shader_subgroup_partitioned
VK_EXT_shader_tile_image
Name String
VK_EXT_shader_tile_image
Extension Type
Device extension
Registered Extension Number
396
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.3
SPIR-V Dependencies
SPV_EXT_shader_tile_image
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_EXT_shader_tile_image
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderTileImageFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderTileImagePropertiesEXT
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
Issues
None.
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();

//..
Version History
Revision 1, 2023-03-23 (Sandeep Kakarlapudi)
Initial version
VK_EXT_shader_uniform_buffer_unsized_array
Name String
VK_EXT_shader_uniform_buffer_unsized_array
Extension Type
Device extension
Registered Extension Number
643
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Piers Daniell
pdaniell-nv
Extension Proposal
VK_EXT_shader_uniform_buffer_unsized_array
Other Extension Metadata
Last Modified Date
2025-05-28
Contributors
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Pranjal Dubey, NVIDIA
Description
This extension allows the last member of a uniform buffer block to be
declared as an unsized array.
This capability enables applications to create flexible buffer layouts where
the array size can vary based on runtime requirements.
When the last member of a uniform buffer block is declared as an unsized
array, the effective array size is inferred at runtime from the size of the
buffer object backing the uniform buffer block.
Such unsized arrays can be indexed with general integer expressions, but may
not be passed as arguments to functions or indexed with negative constant
expressions.
This extension leverages existing SPIR-V capabilities, allowing use of
OpTypeRuntimeArray
as the last member of a uniform buffer block structure
while prohibiting
OpArrayLength
Applications needing to know array sizes at runtime should calculate the
length and pass it to shaders via a separate uniform.
This calculation can be performed using the formula: max((buffer_object_size -
offset_of_array) / stride_of_array, 0), where buffer_object_size is the size
of the bound buffer, offset_of_array is the byte offset of the array in the
block, and stride_of_array is the byte stride between consecutive array
elements.
Uniform buffers have traditionally required explicit sizes for all arrays
which limits flexibility.
With this extension, developers can create a single shader that adapts to
different data set sizes at runtime by binding differently sized buffers.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderUniformBufferUnsizedArrayFeaturesEXT
New Enum Constants
VK_EXT_SHADER_UNIFORM_BUFFER_UNSIZED_ARRAY_EXTENSION_NAME
VK_EXT_SHADER_UNIFORM_BUFFER_UNSIZED_ARRAY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_UNIFORM_BUFFER_UNSIZED_ARRAY_FEATURES_EXT
Version History
Revision 1, 2025-05-28 (Pranjal Dubey)
Initial draft
VK_EXT_subpass_merge_feedback
Name String
VK_EXT_subpass_merge_feedback
Extension Type
Device extension
Registered Extension Number
459
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Ting Wei
catweiting
Extension Proposal
VK_EXT_subpass_merge_feedback
Other Extension Metadata
Last Modified Date
2022-05-24
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm
Jorg Wagner, Arm
Ting Wei, Arm
Description
This extension adds a mechanism to provide feedback to an application about
whether the subpasses specified on render pass creation are merged by the
implementation.
Additionally, it provides a control to enable or disable subpass merging in
the render pass.
New Structures
VkRenderPassCreationFeedbackInfoEXT
VkRenderPassSubpassFeedbackInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSubpassMergeFeedbackFeaturesEXT
Extending
VkRenderPassCreateInfo2
VkRenderPassCreationFeedbackCreateInfoEXT
Extending
VkRenderPassCreateInfo2
VkSubpassDescription2
VkRenderPassCreationControlEXT
Extending
VkSubpassDescription2
VkRenderPassSubpassFeedbackCreateInfoEXT
New Enums
VkSubpassMergeStatusEXT
New Enum Constants
VK_EXT_SUBPASS_MERGE_FEEDBACK_EXTENSION_NAME
VK_EXT_SUBPASS_MERGE_FEEDBACK_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_MERGE_FEEDBACK_FEATURES_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_CONTROL_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_FEEDBACK_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_RENDER_PASS_SUBPASS_FEEDBACK_CREATE_INFO_EXT
Version History
Revision 1, 2022-03-10
Initial draft.
Revision 2, 2022-05-24
Fix structextends and constness issues.
VK_EXT_swapchain_colorspace
Name String
VK_EXT_swapchain_colorspace
Extension Type
Instance extension
Registered Extension Number
105
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Courtney Goeltzenleuchter
courtney-g
Other Extension Metadata
Last Modified Date
2019-04-26
IP Status
No known IP claims.
Contributors
Courtney Goeltzenleuchter, Google
Description
This extension expands
VkColorSpaceKHR
to add support for most
standard color spaces beyond
VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
This extension also adds support for
VK_COLOR_SPACE_PASS_THROUGH_EXT
which allows applications to use color spaces not explicitly enumerated in
VkColorSpaceKHR
New Enum Constants
VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME
VK_EXT_SWAPCHAIN_COLOR_SPACE_SPEC_VERSION
Extending
VkColorSpaceKHR
VK_COLOR_SPACE_ADOBERGB_LINEAR_EXT
VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT
VK_COLOR_SPACE_BT2020_LINEAR_EXT
VK_COLOR_SPACE_BT709_LINEAR_EXT
VK_COLOR_SPACE_BT709_NONLINEAR_EXT
VK_COLOR_SPACE_DCI_P3_LINEAR_EXT
VK_COLOR_SPACE_DCI_P3_NONLINEAR_EXT
VK_COLOR_SPACE_DISPLAY_P3_LINEAR_EXT
VK_COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT
VK_COLOR_SPACE_DOLBYVISION_EXT
VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT
VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT
VK_COLOR_SPACE_HDR10_HLG_EXT
VK_COLOR_SPACE_HDR10_ST2084_EXT
VK_COLOR_SPACE_PASS_THROUGH_EXT
Issues
1) Does the spec need to specify which kinds of image formats support the
color spaces?
RESOLVED
: Pixel format is independent of color space (though some color
spaces really want / need floating-point color components to be useful).
Therefore, do not plan on documenting what formats support which color
spaces.
An application
can
call
vkGetPhysicalDeviceSurfaceFormatsKHR
to query
what a particular implementation supports.
2) How does application determine if HW supports appropriate transfer
function for a color space?
RESOLVED
: Extension indicates that implementation
must
not do the OETF
encoding if it is not sRGB.
That responsibility falls to the application shaders.
Any other native OETF / EOTF functions supported by an implementation can be
described by separate extension.
Version History
Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)
Initial version
Revision 2, 2017-01-19 (Courtney Goeltzenleuchter)
Add pass through and multiple options for BT2020.
Clean up some issues with equations not displaying properly.
Revision 3, 2017-06-23 (Courtney Goeltzenleuchter)
Add extended sRGB non-linear enum.
Revision 4, 2019-04-26 (Graeme Leese)
Clarify color space transfer function usage.
Refer to normative definitions in the Data Format Specification.
Clarify DCI-P3 and Display P3 usage.
Revision 5, 2024-03-16 (Zehui Lin)
Fix interchanged concepts of EOTF and OETF.
Clarify that the presentation engine can accept the color spaces.
VK_EXT_texture_compression_astc_3d
Name String
VK_EXT_texture_compression_astc_3d
Extension Type
Device extension
Registered Extension Number
289
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_EXT_texture_compression_astc_3d
Other Extension Metadata
Last Modified Date
2025-06-09
IP Status
No known issues.
Contributors
Jan-Harald Fredriksen, Arm
Description
This extension adds support for 3D textures compressed using the Adaptive
Scalable Texture Compression (ASTC) format.
These formats are compressed in 3D.
As such, each slice will contain data for a Width x Height x Depth block of
the texture.
All transfer operations are done at the granularity of block dimensions.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTextureCompressionASTC3DFeaturesEXT
New Enum Constants
VK_EXT_TEXTURE_COMPRESSION_ASTC_3D_EXTENSION_NAME
VK_EXT_TEXTURE_COMPRESSION_ASTC_3D_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_ASTC_3x3x3_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_3x3x3_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_3x3x3_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_4x3x3_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_4x3x3_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_4x3x3_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_4x4x3_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_4x4x3_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_4x4x3_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_4x4x4_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_4x4x4_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_4x4x4_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_5x4x4_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_5x4x4_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_5x4x4_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_5x5x4_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_5x5x4_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_5x5x4_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_5x5x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_5x5x5_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_5x5x5_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_6x5x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_6x5x5_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_6x5x5_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_6x6x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_6x6x5_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_6x6x5_UNORM_BLOCK_EXT
VK_FORMAT_ASTC_6x6x6_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_6x6x6_SRGB_BLOCK_EXT
VK_FORMAT_ASTC_6x6x6_UNORM_BLOCK_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_3D_FEATURES_EXT
Issues
None.
Version History
Revision 1, 2025-06-09 (Jan-Harald Fredriksen)
Initial version
VK_EXT_transform_feedback
Name String
VK_EXT_transform_feedback
Extension Type
Device extension
Registered Extension Number
29
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Uses
OpenGL / ES support
D3D support
Developer tools
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 Commands
vkCmdBeginQueryIndexedEXT
vkCmdBeginTransformFeedbackEXT
vkCmdBindTransformFeedbackBuffersEXT
vkCmdDrawIndirectByteCountEXT
vkCmdEndQueryIndexedEXT
vkCmdEndTransformFeedbackEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTransformFeedbackFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTransformFeedbackPropertiesEXT
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationStateStreamCreateInfoEXT
New Bitmasks
VkPipelineRasterizationStateStreamCreateFlagsEXT
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.
Version History
Revision 1, 2018-10-09 (Piers Daniell)
Internal revisions
VK_EXT_validation_cache
Name String
VK_EXT_validation_cache
Extension Type
Device extension
Registered Extension Number
161
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Contact
Cort Stratton
cdwfs
Other Extension Metadata
Last Modified Date
2017-08-29
IP Status
No known IP claims.
Contributors
Cort Stratton, Google
Chris Forbes, Google
Description
This extension provides a mechanism for caching the results of potentially
expensive internal validation operations across multiple runs of a Vulkan
application.
At the core is the
VkValidationCacheEXT
object type, which is managed
similarly to the existing
VkPipelineCache
The new structure
VkShaderModuleValidationCacheCreateInfoEXT
can be
included in the
pNext
chain at
vkCreateShaderModule
time.
It contains a
VkValidationCacheEXT
to use when validating the
VkShaderModule
New Object Types
VkValidationCacheEXT
New Commands
vkCreateValidationCacheEXT
vkDestroyValidationCacheEXT
vkGetValidationCacheDataEXT
vkMergeValidationCachesEXT
New Structures
VkValidationCacheCreateInfoEXT
Extending
VkShaderModuleCreateInfo
VkPipelineShaderStageCreateInfo
VkShaderModuleValidationCacheCreateInfoEXT
New Enums
VkValidationCacheHeaderVersionEXT
New Bitmasks
VkValidationCacheCreateFlagsEXT
New Enum Constants
VK_EXT_VALIDATION_CACHE_EXTENSION_NAME
VK_EXT_VALIDATION_CACHE_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_VALIDATION_CACHE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT
Version History
Revision 1, 2017-08-29 (Cort Stratton)
Initial draft
VK_EXT_vertex_input_dynamic_state
Name String
VK_EXT_vertex_input_dynamic_state
Extension Type
Device extension
Registered Extension Number
353
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2020-08-21
IP Status
No known IP claims.
Contributors
Jeff Bolz, NVIDIA
Spencer Fricke, Samsung
Stu Smith, AMD
Description
One of the states that contributes to the combinatorial explosion of
pipeline state objects that need to be created, is the vertex input binding
and attribute descriptions.
By allowing them to be dynamic applications may reduce the number of
pipeline objects they need to create.
This extension adds dynamic state support for what is normally static state
in
VkPipelineVertexInputStateCreateInfo
New Commands
vkCmdSetVertexInputEXT
New Structures
VkVertexInputAttributeDescription2EXT
VkVertexInputBindingDescription2EXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVertexInputDynamicStateFeaturesEXT
New Enum Constants
VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_EXTENSION_NAME
VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_VERTEX_INPUT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_INPUT_DYNAMIC_STATE_FEATURES_EXT
VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT
VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT
Version History
Revision 2, 2020-11-05 (Piers Daniell)
Make
VkVertexInputBindingDescription2EXT
extensible
Add new
VkVertexInputAttributeDescription2EXT
structure for the
pVertexAttributeDescriptions
parameter to
vkCmdSetVertexInputEXT
so it is also extensible
Revision 1, 2020-08-21 (Piers Daniell)
Internal revisions
VK_EXT_ycbcr_image_arrays
Name String
VK_EXT_ycbcr_image_arrays
Extension Type
Device extension
Registered Extension Number
253
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2019-01-15
Contributors
Piers Daniell, NVIDIA
Description
This extension allows images of a format that requires
Y′C
conversion
to be
created with multiple array layers, which is otherwise restricted.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceYcbcrImageArraysFeaturesEXT
New Enum Constants
VK_EXT_YCBCR_IMAGE_ARRAYS_EXTENSION_NAME
VK_EXT_YCBCR_IMAGE_ARRAYS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_IMAGE_ARRAYS_FEATURES_EXT
Version History
Revision 1, 2019-01-15 (Piers Daniell)
Initial revision
VK_EXT_zero_initialize_device_memory
Name String
VK_EXT_zero_initialize_device_memory
Extension Type
Device extension
Registered Extension Number
621
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Mike Blumenkrantz
zmike
Extension Proposal
VK_EXT_zero_initialize_device_memory
Other Extension Metadata
Last Modified Date
2025-04-09
Interactions and External Dependencies
Interacts with Vulkan 1.1.
Interacts with
VK_KHR_get_physical_device_properties2
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, VALVE
Mike Blumenkrantz, VALVE
Tobias Hector, AMD
Faith Ekstrand, Collabora
Ricardo Garcia, Igalia
Jan-Harald Fredriksen, ARM
Spencer Fricke, LunarG
Description
By default, Vulkan provides no guarantees that device memory allocated
through vkAllocateMemory is cleared to zero.
This means that applications wanting resources to be zero-initialized must
execute a command such as vkCmdFillBuffer or vkCmdClearColorImage on the
device to ensure a deterministic result.
This can be wasteful if the underlying platform either:
Already performs that zero clear anyway, due to e.g. security concerns.
Can be performed more efficiently in implementation, by e.g. clearing
pages to zero in the background after device memory is freed.
This extension also has uses in API layering and porting efforts, where zero
memory behavior may be more strict than Vulkan.
Different OS platforms also have wildly different behaviors here, which
leads to implementations needing to apply workarounds to paper over these
issues in the wild.
If an extension exists to make allocation behavior explicit, we hopefully
achieve a more robust ecosystem for Vulkan.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceZeroInitializeDeviceMemoryFeaturesEXT
New Enum Constants
VK_EXT_ZERO_INITIALIZE_DEVICE_MEMORY_EXTENSION_NAME
VK_EXT_ZERO_INITIALIZE_DEVICE_MEMORY_SPEC_VERSION
Extending
VkImageLayout
VK_IMAGE_LAYOUT_ZERO_INITIALIZED_EXT
Extending
VkMemoryAllocateFlagBits
VK_MEMORY_ALLOCATE_ZERO_INITIALIZE_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_DEVICE_MEMORY_FEATURES_EXT
Version History
Revision 1, 2025-03-10 (Mike Blumenkrantz)
Initial version
VK_AMD_anti_lag
Name String
VK_AMD_anti_lag
Extension Type
Device extension
Registered Extension Number
477
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Stu Smith
Extension Proposal
VK_AMD_anti_lag
Other Extension Metadata
Last Modified Date
2024-06-06
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Stuart Smith, AMD
Arkadiusz Sarwa, AMD
Description
This extension automatically paces the CPU to make sure it does not get too
far ahead of the GPU, reducing the latency between inputs received and
updates on the screen.
Additionally, Anti-Lag+ offers applications the ability to inform the driver
when input processing begins, in order to align the timing of display
updates, enabling even lower latency between receiving input and displaying
on the screen.
New Commands
vkAntiLagUpdateAMD
New Structures
VkAntiLagDataAMD
VkAntiLagPresentationInfoAMD
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAntiLagFeaturesAMD
New Enums
VkAntiLagModeAMD
VkAntiLagStageAMD
New Enum Constants
VK_AMD_ANTI_LAG_EXTENSION_NAME
VK_AMD_ANTI_LAG_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_ANTI_LAG_DATA_AMD
VK_STRUCTURE_TYPE_ANTI_LAG_PRESENTATION_INFO_AMD
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ANTI_LAG_FEATURES_AMD
Version History
Revision 1, 2024-06-06 (Arkadiusz Sarw)
Initial version
VK_AMD_buffer_marker
Name String
VK_AMD_buffer_marker
Extension Type
Device extension
Registered Extension Number
180
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_synchronization2
Special Use
Developer tools
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2018-01-26
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Jaakko Konttinen, AMD
Daniel Rakos, AMD
Description
This extension adds a new operation to execute pipelined writes of small
marker values into a
VkBuffer
object.
The primary purpose of these markers is to facilitate the development of
debugging tools for tracking which pipelined command contributed to device
loss.
New Commands
vkCmdWriteBufferMarkerAMD
If
Vulkan Version 1.3
or
VK_KHR_synchronization2
is supported:
vkCmdWriteBufferMarker2AMD
New Enum Constants
VK_AMD_BUFFER_MARKER_EXTENSION_NAME
VK_AMD_BUFFER_MARKER_SPEC_VERSION
Examples
None.
Version History
Revision 1, 2018-01-26 (Jaakko Konttinen)
Initial revision
VK_AMD_device_coherent_memory
Name String
VK_AMD_device_coherent_memory
Extension Type
Device extension
Registered Extension Number
230
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Tobias Hector
tobski
Other Extension Metadata
Last Modified Date
2019-02-04
Contributors
Ping Fu, AMD
Timothy Lottes, AMD
Tobias Hector, AMD
Description
This extension adds the device coherent and device uncached memory types.
Any device accesses to device coherent memory are automatically made visible
to any other device access.
Device uncached memory indicates to applications that caches are disabled
for a particular memory type, which guarantees device coherence.
Device coherent and uncached memory are expected to have lower performance
for general access than non-device coherent memory, but can be useful in
certain scenarios; particularly so for debugging.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCoherentMemoryFeaturesAMD
New Enum Constants
VK_AMD_DEVICE_COHERENT_MEMORY_EXTENSION_NAME
VK_AMD_DEVICE_COHERENT_MEMORY_SPEC_VERSION
Extending
VkMemoryPropertyFlagBits
VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD
VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COHERENT_MEMORY_FEATURES_AMD
Version History
Revision 1, 2019-02-04 (Tobias Hector)
Initial revision
VK_AMD_display_native_hdr
Name String
VK_AMD_display_native_hdr
Extension Type
Device extension
Registered Extension Number
214
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_get_surface_capabilities2
and
VK_KHR_swapchain
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2018-12-18
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Aaron Hagan, AMD
Aric Cyr, AMD
Timothy Lottes, AMD
Derrick Owens, AMD
Daniel Rakos, AMD
Description
This extension introduces the following display native HDR features to
Vulkan:
A new
VkColorSpaceKHR
enum for setting the native display color
space.
For example, this color space would be set by the swapchain to use the
native color space in Freesync2 displays.
Local dimming control
New Commands
vkSetLocalDimmingAMD
New Structures
Extending
VkSurfaceCapabilities2KHR
VkDisplayNativeHdrSurfaceCapabilitiesAMD
Extending
VkSwapchainCreateInfoKHR
VkSwapchainDisplayNativeHdrCreateInfoAMD
New Enum Constants
VK_AMD_DISPLAY_NATIVE_HDR_EXTENSION_NAME
VK_AMD_DISPLAY_NATIVE_HDR_SPEC_VERSION
Extending
VkColorSpaceKHR
VK_COLOR_SPACE_DISPLAY_NATIVE_AMD
Extending
VkStructureType
VK_STRUCTURE_TYPE_DISPLAY_NATIVE_HDR_SURFACE_CAPABILITIES_AMD
VK_STRUCTURE_TYPE_SWAPCHAIN_DISPLAY_NATIVE_HDR_CREATE_INFO_AMD
Issues
None.
Examples
None.
Version History
Revision 1, 2018-12-18 (Daniel Rakos)
Initial revision
VK_AMD_gcn_shader
Name String
VK_AMD_gcn_shader
Extension Type
Device extension
Registered Extension Number
26
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_gcn_shader
Contact
Dominik Witczak
dominikwitczakamd
Other Extension Metadata
Last Modified Date
2016-05-30
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_gcn_shader
Contributors
Dominik Witczak, AMD
Daniel Rakos, AMD
Rex Xu, AMD
Graham Sellers, AMD
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_AMD_gcn_shader
New Enum Constants
VK_AMD_GCN_SHADER_EXTENSION_NAME
VK_AMD_GCN_SHADER_SPEC_VERSION
Version History
Revision 1, 2016-05-30 (Dominik Witczak)
Initial draft
VK_AMD_memory_overallocation_behavior
Name String
VK_AMD_memory_overallocation_behavior
Extension Type
Device extension
Registered Extension Number
190
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Martin Dinkov
mdinkov
Other Extension Metadata
Last Modified Date
2018-09-19
IP Status
No known IP claims.
Contributors
Martin Dinkov, AMD
Matthaeus Chajdas, AMD
Daniel Rakos, AMD
Jon Campbell, AMD
Description
This extension allows controlling whether explicit overallocation beyond the
device memory heap sizes (reported by
VkPhysicalDeviceMemoryProperties
) is allowed or not.
Overallocation may lead to performance loss and is not supported for all
platforms.
New Structures
Extending
VkDeviceCreateInfo
VkDeviceMemoryOverallocationCreateInfoAMD
New Enums
VkMemoryOverallocationBehaviorAMD
New Enum Constants
VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_EXTENSION_NAME
VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_MEMORY_OVERALLOCATION_CREATE_INFO_AMD
Version History
Revision 1, 2018-09-19 (Martin Dinkov)
Initial draft.
VK_AMD_mixed_attachment_samples
Name String
VK_AMD_mixed_attachment_samples
Extension Type
Device extension
Registered Extension Number
137
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2017-07-24
Contributors
Mais Alnasser, AMD
Matthaeus G. Chajdas, AMD
Maciej Jesionowski, AMD
Daniel Rakos, AMD
Description
This extension enables applications to use multisampled rendering with a
depth/stencil sample count that is larger than the color sample count.
Having a depth/stencil sample count larger than the color sample count
allows maintaining geometry and coverage information at a higher sample rate
than color information.
All samples are depth/stencil tested, but only the first color sample count
number of samples get a corresponding color output.
New Structures
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkCommandBufferInheritanceInfo
VkGraphicsPipelineCreateInfo
VkAttachmentSampleCountInfoAMD
New Enum Constants
VK_AMD_MIXED_ATTACHMENT_SAMPLES_EXTENSION_NAME
VK_AMD_MIXED_ATTACHMENT_SAMPLES_SPEC_VERSION
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_AMD
Issues
None.
Version History
Revision 1, 2017-07-24 (Daniel Rakos)
Internal revisions
VK_AMD_pipeline_compiler_control
Name String
VK_AMD_pipeline_compiler_control
Extension Type
Device extension
Registered Extension Number
184
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2019-07-26
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Daniel Rakos, AMD
Maciej Jesionowski, AMD
Tobias Hector, AMD
Description
This extension introduces
VkPipelineCompilerControlCreateInfoAMD
structure that can be chained to a pipeline’s creation information to
specify additional flags that affect pipeline compilation.
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkComputePipelineCreateInfo
VkExecutionGraphPipelineCreateInfoAMDX
VkPipelineCompilerControlCreateInfoAMD
New Enums
VkPipelineCompilerControlFlagBitsAMD
New Bitmasks
VkPipelineCompilerControlFlagsAMD
New Enum Constants
VK_AMD_PIPELINE_COMPILER_CONTROL_EXTENSION_NAME
VK_AMD_PIPELINE_COMPILER_CONTROL_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_COMPILER_CONTROL_CREATE_INFO_AMD
Issues
None.
Examples
None.
Version History
Revision 1, 2019-07-26 (Tobias Hector)
Initial revision.
VK_AMD_rasterization_order
Name String
VK_AMD_rasterization_order
Extension Type
Device extension
Registered Extension Number
19
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2016-04-25
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Jaakko Konttinen, AMD
Daniel Rakos, AMD
Graham Sellers, AMD
Dominik Witczak, AMD
Description
This extension introduces the possibility for the application to control the
order of primitive rasterization.
In unextended Vulkan, the following stages are guaranteed to execute in
API
order
depth bounds test
stencil test, stencil op, and stencil write
depth test and depth write
occlusion queries
blending, logic op, and color write
This extension enables applications to opt into a relaxed, implementation
defined primitive rasterization order that may allow better parallel
processing of primitives and thus enabling higher primitive throughput.
It is applicable in cases where the primitive rasterization order is known
to not affect the output of the rendering or any differences caused by a
different rasterization order are not a concern from the point of view of
the application’s purpose.
A few examples of cases when using the relaxed primitive rasterization order
would not have an effect on the final rendering:
If the primitives rendered are known to not overlap in framebuffer
space.
If depth testing is used with a comparison operator of
VK_COMPARE_OP_LESS
VK_COMPARE_OP_LESS_OR_EQUAL
VK_COMPARE_OP_GREATER
, or
VK_COMPARE_OP_GREATER_OR_EQUAL
and the primitives rendered are known to not overlap in clip space.
If depth testing is not used and blending is enabled for all attachments
with a commutative blend operator.
New Structures
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationStateRasterizationOrderAMD
New Enums
VkRasterizationOrderAMD
New Enum Constants
VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME
VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD
Issues
1) How is this extension useful to application developers?
RESOLVED
: Allows them to increase primitive throughput for cases when
strict API order rasterization is not important due to the nature of the
content, the configuration used, or the requirements towards the output of
the rendering.
2) How does this extension interact with content optimizations aiming to
reduce overdraw by appropriately ordering the input primitives?
RESOLVED
: While the relaxed rasterization order might somewhat limit the
effectiveness of such content optimizations, most of the benefits of it are
expected to be retained even when the relaxed rasterization order is used,
so applications
should
still apply these optimizations even if they intend
to use the extension.
3) Are there any guarantees about the primitive rasterization order when
using the new relaxed mode?
RESOLVED
: No.
In this case the rasterization order is completely implementation-dependent,
but in practice it is expected to partially still follow the order of
incoming primitives.
4) Does the new relaxed rasterization order have any adverse effect on
repeatability and other invariance rules of the API?
RESOLVED
: Yes, in the sense that it extends the list of exceptions when
the repeatability requirement does not apply.
Examples
None
Issues
None
Version History
Revision 1, 2016-04-25 (Daniel Rakos)
Initial draft.
VK_AMD_shader_ballot
Name String
VK_AMD_shader_ballot
Extension Type
Device extension
Registered Extension Number
38
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_shader_ballot
Contact
Dominik Witczak
dominikwitczakamd
Other Extension Metadata
Last Modified Date
2016-09-19
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_shader_ballot
Contributors
Qun Lin, AMD
Graham Sellers, AMD
Daniel Rakos, AMD
Rex Xu, AMD
Dominik Witczak, AMD
Matthäus G. Chajdas, AMD
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_AMD_shader_ballot
New Enum Constants
VK_AMD_SHADER_BALLOT_EXTENSION_NAME
VK_AMD_SHADER_BALLOT_SPEC_VERSION
Version History
Revision 1, 2016-09-19 (Dominik Witczak)
Initial draft
VK_AMD_shader_core_properties
Name String
VK_AMD_shader_core_properties
Extension Type
Device extension
Registered Extension Number
186
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Martin Dinkov
mdinkov
Other Extension Metadata
Last Modified Date
2019-06-25
IP Status
No known IP claims.
Contributors
Martin Dinkov, AMD
Matthaeus G. Chajdas, AMD
Description
This extension exposes shader core properties for a target physical device
through the
VK_KHR_get_physical_device_properties2
extension.
Please refer to the example below for proper usage.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderCorePropertiesAMD
New Enum Constants
VK_AMD_SHADER_CORE_PROPERTIES_EXTENSION_NAME
VK_AMD_SHADER_CORE_PROPERTIES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD
Examples
This example retrieves the shader core properties for a physical device.
extern VkInstance instance;

PFN_vkGetPhysicalDeviceProperties2 pfnVkGetPhysicalDeviceProperties2 =
reinterpret_cast
(vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceProperties2") );

VkPhysicalDeviceProperties2 general_props;
VkPhysicalDeviceShaderCorePropertiesAMD shader_core_properties;

shader_core_properties.pNext = nullptr;
shader_core_properties.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD;

general_props.pNext = &shader_core_properties;
general_props.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2;

// After this call, shader_core_properties has been populated
pfnVkGetPhysicalDeviceProperties2(device, &general_props);

printf("Number of shader engines: %d\n",
m_shader_core_properties.shader_engine_count =
shader_core_properties.shaderEngineCount;
printf("Number of shader arrays: %d\n",
m_shader_core_properties.shader_arrays_per_engine_count =
shader_core_properties.shaderArraysPerEngineCount;
printf("Number of CUs per shader array: %d\n",
m_shader_core_properties.compute_units_per_shader_array =
shader_core_properties.computeUnitsPerShaderArray;
printf("Number of SIMDs per compute unit: %d\n",
m_shader_core_properties.simd_per_compute_unit =
shader_core_properties.simdPerComputeUnit;
printf("Number of wavefront slots in each SIMD: %d\n",
m_shader_core_properties.wavefronts_per_simd =
shader_core_properties.wavefrontsPerSimd;
printf("Number of threads per wavefront: %d\n",
m_shader_core_properties.wavefront_size =
shader_core_properties.wavefrontSize;
printf("Number of physical SGPRs per SIMD: %d\n",
m_shader_core_properties.sgprs_per_simd =
shader_core_properties.sgprsPerSimd;
printf("Minimum number of SGPRs that can be allocated by a wave: %d\n",
m_shader_core_properties.min_sgpr_allocation =
shader_core_properties.minSgprAllocation;
printf("Number of available SGPRs: %d\n",
m_shader_core_properties.max_sgpr_allocation =
shader_core_properties.maxSgprAllocation;
printf("SGPRs are allocated in groups of this size: %d\n",
m_shader_core_properties.sgpr_allocation_granularity =
shader_core_properties.sgprAllocationGranularity;
printf("Number of physical VGPRs per SIMD: %d\n",
m_shader_core_properties.vgprs_per_simd =
shader_core_properties.vgprsPerSimd;
printf("Minimum number of VGPRs that can be allocated by a wave: %d\n",
m_shader_core_properties.min_vgpr_allocation =
shader_core_properties.minVgprAllocation;
printf("Number of available VGPRs: %d\n",
m_shader_core_properties.max_vgpr_allocation =
shader_core_properties.maxVgprAllocation;
printf("VGPRs are allocated in groups of this size: %d\n",
m_shader_core_properties.vgpr_allocation_granularity =
shader_core_properties.vgprAllocationGranularity;
Version History
Revision 2, 2019-06-25 (Matthaeus G. Chajdas)
Clarified the meaning of a few fields.
Revision 1, 2018-02-15 (Martin Dinkov)
Initial draft.
VK_AMD_shader_core_properties2
Name String
VK_AMD_shader_core_properties2
Extension Type
Device extension
Registered Extension Number
228
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_AMD_shader_core_properties
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2019-07-26
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Tobias Hector, AMD
Description
This extension exposes additional shader core properties for a target
physical device through the
VK_KHR_get_physical_device_properties2
extension.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderCoreProperties2AMD
New Enums
VkShaderCorePropertiesFlagBitsAMD
New Bitmasks
VkShaderCorePropertiesFlagsAMD
New Enum Constants
VK_AMD_SHADER_CORE_PROPERTIES_2_EXTENSION_NAME
VK_AMD_SHADER_CORE_PROPERTIES_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_2_AMD
Examples
None.
Version History
Revision 1, 2019-07-26 (Matthaeus G. Chajdas)
Initial draft.
VK_AMD_shader_early_and_late_fragment_tests
Name String
VK_AMD_shader_early_and_late_fragment_tests
Extension Type
Device extension
Registered Extension Number
322
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_AMD_shader_early_and_late_fragment_tests
Contact
Tobias Hector
tobski
Extension Proposal
VK_AMD_shader_early_and_late_fragment_tests
Other Extension Metadata
Last Modified Date
2021-09-14
Interactions and External Dependencies
This extension interacts with
VK_EXT_shader_stencil_export
Contributors
Tobias Hector, AMD
Description
This extension adds support for the
SPV_AMD_shader_early_and_late_fragment_tests
extension, allowing shaders to explicitly opt in to allowing both early
and
late fragment tests with the
EarlyAndLateFragmentTestsAMD
execution mode.
If the
VK_EXT_shader_stencil_export
extension is supported,
additional execution modes allowing early depth tests similar to
DepthUnchanged
DepthLess
, and
DepthGreater
are provided.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderEarlyAndLateFragmentTestsFeaturesAMD
New Enum Constants
VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_EXTENSION_NAME
VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_FEATURES_AMD
Version History
Revision 1, 2021-09-14 (Tobias Hector)
Initial draft
VK_AMD_shader_explicit_vertex_parameter
Name String
VK_AMD_shader_explicit_vertex_parameter
Extension Type
Device extension
Registered Extension Number
22
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_shader_explicit_vertex_parameter
Contact
Qun Lin
linqun
Other Extension Metadata
Last Modified Date
2016-05-10
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_shader_explicit_vertex_parameter
Contributors
Matthaeus G. Chajdas, AMD
Qun Lin, AMD
Daniel Rakos, AMD
Graham Sellers, AMD
Rex Xu, AMD
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_AMD_shader_explicit_vertex_parameter
New Enum Constants
VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_EXTENSION_NAME
VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_SPEC_VERSION
Version History
Revision 1, 2016-05-10 (Daniel Rakos)
Initial draft
VK_AMD_shader_fragment_mask
Name String
VK_AMD_shader_fragment_mask
Extension Type
Device extension
Registered Extension Number
138
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_shader_fragment_mask
Contact
Aaron Hagan
AaronHaganAMD
Other Extension Metadata
Last Modified Date
2017-08-16
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_shader_fragment_mask
Contributors
Aaron Hagan, AMD
Daniel Rakos, AMD
Timothy Lottes, AMD
Description
This extension provides efficient read access to the fragment mask in
compressed multisampled color surfaces.
The fragment mask is a lookup table that associates color samples with color
fragment values.
From a shader, the fragment mask can be fetched with a call to
fragmentMaskFetchAMD
, which returns a single
uint
where each
subsequent four bits specify the color fragment index corresponding to the
color sample, starting from the least significant bit.
For example, when eight color samples are used, the color fragment index for
color sample 0 will be in bits 0-3 of the fragment mask, for color sample 7
the index will be in bits 28-31.
The color fragment for a particular color sample may then be fetched with
the corresponding fragment mask value using the
fragmentFetchAMD
shader
function.
New Enum Constants
VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME
VK_AMD_SHADER_FRAGMENT_MASK_SPEC_VERSION
New SPIR-V Capabilities
FragmentMaskAMD
Examples
This example shows a shader that queries the fragment mask from a
multisampled compressed surface and uses it to query fragment values.
#version 450 core

#extension GL_AMD_shader_fragment_mask: enable

layout(binding = 0) uniform sampler2DMS s2DMS;
layout(binding = 1) uniform isampler2DMSArray is2DMSArray;

layout(binding = 2, input_attachment_index = 0) uniform usubpassInputMS usubpassMS;

layout(location = 0) out vec4 fragColor;

void main()
vec4 fragOne = vec4(0.0);

uint fragMask = fragmentMaskFetchAMD(s2DMS, ivec2(2, 3));
uint fragIndex = (fragMask & 0xF0) >> 4;
fragOne += fragmentFetchAMD(s2DMS, ivec2(2, 3), 1);

fragMask = fragmentMaskFetchAMD(is2DMSArray, ivec3(2, 3, 1));
fragIndex = (fragMask & 0xF0) >> 4;
fragOne += fragmentFetchAMD(is2DMSArray, ivec3(2, 3, 1), fragIndex);

fragMask = fragmentMaskFetchAMD(usubpassMS);
fragIndex = (fragMask & 0xF0) >> 4;
fragOne += fragmentFetchAMD(usubpassMS, fragIndex);

fragColor = fragOne;
Version History
Revision 1, 2017-08-16 (Aaron Hagan)
Initial draft
VK_AMD_shader_image_load_store_lod
Name String
VK_AMD_shader_image_load_store_lod
Extension Type
Device extension
Registered Extension Number
47
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_shader_image_load_store_lod
Contact
Dominik Witczak
dominikwitczakamd
Other Extension Metadata
Last Modified Date
2017-08-21
Interactions and External Dependencies
This extension provides API support for
GL_AMD_shader_image_load_store_lod
IP Status
No known IP claims.
Contributors
Dominik Witczak, AMD
Qun Lin, AMD
Rex Xu, AMD
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_AMD_shader_image_load_store_lod
New Enum Constants
VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_EXTENSION_NAME
VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_SPEC_VERSION
Version History
Revision 1, 2017-08-21 (Dominik Witczak)
Initial draft
VK_AMD_shader_info
Name String
VK_AMD_shader_info
Extension Type
Device extension
Registered Extension Number
43
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Special Use
Developer tools
Contact
Jaakko Konttinen
jaakkoamd
Other Extension Metadata
Last Modified Date
2017-10-09
IP Status
No known IP claims.
Contributors
Jaakko Konttinen, AMD
Description
This extension adds a way to query certain information about a compiled
shader which is part of a pipeline.
This information may include shader disassembly, shader binary and various
statistics about a shader’s resource usage.
While this extension provides a mechanism for extracting this information,
the details regarding the contents or format of this information are not
specified by this extension and may be provided by the vendor externally.
Furthermore, all information types are optionally supported, and users
should not assume every implementation supports querying every type of
information.
New Commands
vkGetShaderInfoAMD
New Structures
VkShaderResourceUsageAMD
VkShaderStatisticsInfoAMD
New Enums
VkShaderInfoTypeAMD
New Enum Constants
VK_AMD_SHADER_INFO_EXTENSION_NAME
VK_AMD_SHADER_INFO_SPEC_VERSION
Examples
This example extracts the register usage of a fragment shader within a
particular graphics pipeline:
extern VkDevice device;
extern VkPipeline gfxPipeline;

PFN_vkGetShaderInfoAMD pfnGetShaderInfoAMD = (PFN_vkGetShaderInfoAMD)vkGetDeviceProcAddr(
device, "vkGetShaderInfoAMD");

VkShaderStatisticsInfoAMD statistics = {};

size_t dataSize = sizeof(statistics);

if (pfnGetShaderInfoAMD(device,
gfxPipeline,
VK_SHADER_STAGE_FRAGMENT_BIT,
VK_SHADER_INFO_TYPE_STATISTICS_AMD,
&dataSize,
&statistics) == VK_SUCCESS)
printf("VGPR usage: %d\n", statistics.resourceUsage.numUsedVgprs);
printf("SGPR usage: %d\n", statistics.resourceUsage.numUsedSgprs);
The following example continues the previous example by subsequently
attempting to query and print shader disassembly about the fragment shader:
// Query disassembly size (if available)
if (pfnGetShaderInfoAMD(device,
gfxPipeline,
VK_SHADER_STAGE_FRAGMENT_BIT,
VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD,
&dataSize,
nullptr) == VK_SUCCESS)
printf("Fragment shader disassembly:\n");

void* disassembly = malloc(dataSize);

// Query disassembly and print
if (pfnGetShaderInfoAMD(device,
gfxPipeline,
VK_SHADER_STAGE_FRAGMENT_BIT,
VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD,
&dataSize,
disassembly) == VK_SUCCESS)
printf((char*)disassembly);

free(disassembly);
Version History
Revision 1, 2017-10-09 (Jaakko Konttinen)
Initial revision
VK_AMD_shader_trinary_minmax
Name String
VK_AMD_shader_trinary_minmax
Extension Type
Device extension
Registered Extension Number
21
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_shader_trinary_minmax
Contact
Qun Lin
linqun
Other Extension Metadata
Last Modified Date
2016-05-10
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_shader_trinary_minmax
Contributors
Matthaeus G. Chajdas, AMD
Qun Lin, AMD
Daniel Rakos, AMD
Graham Sellers, AMD
Rex Xu, AMD
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_AMD_shader_trinary_minmax
New Enum Constants
VK_AMD_SHADER_TRINARY_MINMAX_EXTENSION_NAME
VK_AMD_SHADER_TRINARY_MINMAX_SPEC_VERSION
Version History
Revision 1, 2016-05-10 (Daniel Rakos)
Initial draft
VK_AMD_texture_gather_bias_lod
Name String
VK_AMD_texture_gather_bias_lod
Extension Type
Device extension
Registered Extension Number
42
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_AMD_texture_gather_bias_lod
Contact
Rex Xu
amdrexu
Other Extension Metadata
Last Modified Date
2017-03-21
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_texture_gather_bias_lod
Contributors
Dominik Witczak, AMD
Daniel Rakos, AMD
Graham Sellers, AMD
Matthaeus G. Chajdas, AMD
Qun Lin, AMD
Rex Xu, AMD
Timothy Lottes, AMD
Description
This extension adds two related features.
Firstly, support for the following SPIR-V extension in Vulkan is added:
SPV_AMD_texture_gather_bias_lod
Secondly, the extension allows the application to query which formats can be
used together with the new function prototypes introduced by the SPIR-V
extension.
New Structures
Extending
VkImageFormatProperties2
VkTextureLODGatherFormatPropertiesAMD
New Enum Constants
VK_AMD_TEXTURE_GATHER_BIAS_LOD_EXTENSION_NAME
VK_AMD_TEXTURE_GATHER_BIAS_LOD_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD
New SPIR-V Capabilities
ImageGatherBiasLodAMD
Examples
struct VkTextureLODGatherFormatPropertiesAMD
VkStructureType sType;
const void* pNext;
VkBool32 supportsTextureGatherLODBiasAMD;
};

// ----------------------------------------------------------------------------------------
// How to detect if an image format can be used with the new function prototypes.
VkPhysicalDeviceImageFormatInfo2 formatInfo;
VkImageFormatProperties2 formatProps;
VkTextureLODGatherFormatPropertiesAMD textureLODGatherSupport;

textureLODGatherSupport.sType = VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD;
textureLODGatherSupport.pNext = nullptr;

formatInfo.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2;
formatInfo.pNext = nullptr;
formatInfo.format = ...;
formatInfo.type = ...;
formatInfo.tiling = ...;
formatInfo.usage = ...;
formatInfo.flags = ...;

formatProps.sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2;
formatProps.pNext = &textureLODGatherSupport;

vkGetPhysicalDeviceImageFormatProperties2(physical_device, &formatInfo, &formatProps);

if (textureLODGatherSupport.supportsTextureGatherLODBiasAMD == VK_TRUE)
// physical device supports SPV_AMD_texture_gather_bias_lod for the specified
// format configuration.
else
// physical device does not support SPV_AMD_texture_gather_bias_lod for the
// specified format configuration.
Version History
Revision 1, 2017-03-21 (Dominik Witczak)
Initial draft
VK_ANDROID_external_format_resolve
Name String
VK_ANDROID_external_format_resolve
Extension Type
Device extension
Registered Extension Number
469
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_ANDROID_external_memory_android_hardware_buffer
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Special Use
OpenGL / ES support
Contact
Chris Forbes
chrisforbes
Extension Proposal
VK_ANDROID_external_format_resolve
Other Extension Metadata
Last Modified Date
2023-05-03
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Chris Forbes, Google
Jan-Harald Fredriksen, Arm
Shahbaz Youssefi, Google
Matthew Netsch, Qualcomm
Tony Zlatsinki, Nvidia
Daniel Koch, Nvidia
Jeff Leger, Qualcomm
Alex Walters, Imagination
Andrew Garrard, Imagination
Ralph Potter, Samsung
Ian Elliott, Google
Description
This extension enables rendering to Android Hardware Buffers with external
formats which cannot be directly represented as renderable in Vulkan,
including Y′C
formats.
New Structures
Extending
VkAndroidHardwareBufferPropertiesANDROID
VkAndroidHardwareBufferFormatResolvePropertiesANDROID
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExternalFormatResolveFeaturesANDROID
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceExternalFormatResolvePropertiesANDROID
New Enum Constants
VK_ANDROID_EXTERNAL_FORMAT_RESOLVE_EXTENSION_NAME
VK_ANDROID_EXTERNAL_FORMAT_RESOLVE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_RESOLVE_PROPERTIES_ANDROID
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FORMAT_RESOLVE_FEATURES_ANDROID
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FORMAT_RESOLVE_PROPERTIES_ANDROID
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
is supported:
Extending
VkResolveModeFlagBits
VK_RESOLVE_MODE_EXTERNAL_FORMAT_DOWNSAMPLE_ANDROID
VK_RESOLVE_MODE_EXTERNAL_FORMAT_DOWNSAMPLE_BIT_ANDROID
Version History
Revision 1, 2023-05-34 (Tobias Hector)
Initial version
VK_ANDROID_external_memory_android_hardware_buffer
Name String
VK_ANDROID_external_memory_android_hardware_buffer
Extension Type
Device extension
Registered Extension Number
130
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
and
VK_KHR_external_memory
and
VK_KHR_dedicated_allocation
or
Vulkan Version 1.1
and
VK_EXT_queue_family_foreign
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
Contact
Jesse Hall
critsec
Other Extension Metadata
Last Modified Date
2021-09-30
IP Status
No known IP claims.
Contributors
Ray Smith, ARM
Lina Versace, Google
Jesse Hall, Google
Tobias Hector, Imagination
James Jones, NVIDIA
Tony Zlatinski, NVIDIA
Matthew Netsch, Qualcomm
Andrew Garrard, Samsung
Description
This extension enables an application to import Android
AHardwareBuffer
objects created outside of the Vulkan device into
Vulkan memory objects, where they
can
be bound to images and buffers.
It also allows exporting an
AHardwareBuffer
from a Vulkan memory
object for symmetry with other operating systems.
But since not all
AHardwareBuffer
usages and formats have Vulkan
equivalents, exporting from Vulkan provides strictly less functionality than
creating the
AHardwareBuffer
externally and importing it.
Some
AHardwareBuffer
images have implementation-defined
external
formats
that
may
not correspond to Vulkan formats.
Sampler Y′C
conversion
can
be used to sample from these images and
convert them to a known color space.
New Base Types
AHardwareBuffer
New Commands
vkGetAndroidHardwareBufferPropertiesANDROID
vkGetMemoryAndroidHardwareBufferANDROID
New Structures
VkAndroidHardwareBufferPropertiesANDROID
VkMemoryGetAndroidHardwareBufferInfoANDROID
Extending
VkAndroidHardwareBufferPropertiesANDROID
VkAndroidHardwareBufferFormatPropertiesANDROID
Extending
VkImageCreateInfo
VkSamplerYcbcrConversionCreateInfo
VkAttachmentDescription2
VkGraphicsPipelineCreateInfo
VkCommandBufferInheritanceInfo
VkExternalFormatANDROID
Extending
VkImageFormatProperties2
VkAndroidHardwareBufferUsageANDROID
Extending
VkMemoryAllocateInfo
VkImportAndroidHardwareBufferInfoANDROID
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkAndroidHardwareBufferPropertiesANDROID
VkAndroidHardwareBufferFormatProperties2ANDROID
New Enum Constants
VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME
VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID
Extending
VkStructureType
VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID
VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_PROPERTIES_ANDROID
VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_USAGE_ANDROID
VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID
VK_STRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID
VK_STRUCTURE_TYPE_MEMORY_GET_ANDROID_HARDWARE_BUFFER_INFO_ANDROID
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_2_ANDROID
Issues
1) Other external memory objects are represented as weakly-typed handles
(e.g. Win32
HANDLE
or POSIX file descriptor), and require a handle type
parameter along with handles.
AHardwareBuffer
is strongly typed, so naming the handle type is
redundant.
Does symmetry justify adding handle type parameters/fields anyway?
RESOLVED
: No.
The handle type is already provided in places that treat external memory
objects generically.
In the places we would add it, the application code that would have to
provide the handle type value is already dealing with
AHardwareBuffer
-specific commands/structures; the extra symmetry
would not be enough to make that code generic.
2) The internal layout and therefore size of a
AHardwareBuffer
image may depend on native usage flags that do not have corresponding Vulkan
counterparts.
Do we provide this information to
vkCreateImage
somehow, or allow the
allocation size reported by
vkGetImageMemoryRequirements
to be
approximate?
RESOLVED
: Allow the allocation size to be unspecified when allocating the
memory.
It has to work this way for exported image memory anyway, since
AHardwareBuffer
allocation happens in
vkAllocateMemory
, and
internally is performed by a separate HAL, not the Vulkan implementation
itself.
There is a similar issue with
vkGetImageSubresourceLayout
: the layout
is determined by the allocator HAL, so it is not known until the image is
bound to memory.
3) Should the result of sampling an external-format image with the suggested
Y′C
conversion parameters yield the same results as using a
samplerExternalOES
in OpenGL ES?
RESOLVED
: This would be desirable, so that apps converting from OpenGL ES
to Vulkan could get the same output given the same input.
But since sampling and conversion from Y′C
images is so loosely defined
in OpenGL ES, multiple implementations do it in a way that does not conform
to Vulkan’s requirements.
Modifying the OpenGL ES implementation would be difficult, and would change
the output of existing unmodified applications.
Changing the output only for applications that are being modified gives
developers the chance to notice and mitigate any problems.
Implementations are encouraged to minimize differences as much as possible
without causing compatibility problems for existing OpenGL ES applications
or violating Vulkan requirements.
4) Should an
AHardwareBuffer
with
AHARDWAREBUFFER_USAGE_CPU_*
usage be mappable in Vulkan? Should it be possible to export an
AHardwareBuffers
with such usage?
RESOLVED
: Optional, and mapping in Vulkan is not the same as
AHardwareBuffer_lock
The semantics of these are different: mapping in memory is persistent, just
gives a raw view of the memory contents, and does not involve ownership.
AHardwareBuffer_lock
gives the host exclusive access to the buffer, is
temporary, and allows for reformatting copy-in/copy-out.
Implementations are not required to support host-visible memory types for
imported Android hardware buffers or resources backed by them.
If a host-visible memory type is supported and used, the memory can be
mapped in Vulkan, but doing so follows Vulkan semantics: it is just a raw
view of the data and does not imply ownership (this means implementations
must not internally call
AHardwareBuffer_lock
to implement
vkMapMemory
, or assume the application has done so).
Implementations are not required to support linear-tiled images backed by
Android hardware buffers, even if the
AHardwareBuffer
has CPU
usage.
There is no reliable way to allocate memory in Vulkan that can be exported
to a
AHardwareBuffer
with CPU usage.
5) Android may add new
AHardwareBuffer
formats and usage flags over
time.
Can reference to them be added to this extension, or do they need a new
extension?
RESOLVED
: This extension can document the interaction between the new AHB
formats/usages and existing Vulkan features.
No new Vulkan features or implementation requirements can be added.
The extension version number will be incremented when this additional
documentation is added, but the version number does not indicate that an
implementation supports Vulkan memory or resources that map to the new
AHardwareBuffer
features: support for that must be queried with
vkGetPhysicalDeviceImageFormatProperties2
or is implied by
successfully allocating a
AHardwareBuffer
outside of Vulkan that
uses the new feature and has a GPU usage flag.
In essence, these are new features added to a new Android API level, rather
than new Vulkan features.
The extension will only document how existing Vulkan features map to that
new Android feature.
Version History
Revision 5, 2022-02-04 (Chris Forbes)
Describe mapping of flags for storage image support
Revision 4, 2021-09-30 (Jon Leech)
Add interaction with
VK_KHR_format_feature_flags2
to
vk.xml
Revision 3, 2019-08-27 (Jon Leech)
Update revision history to correspond to XML version number
Revision 2, 2018-04-09 (Petr Kraus)
Markup fixes and remove incorrect Draft status
Revision 1, 2018-03-04 (Jesse Hall)
Initial version
VK_ARM_data_graph
Name String
VK_ARM_data_graph
Extension Type
Device extension
Registered Extension Number
508
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.3
and
VK_KHR_maintenance5
and
VK_KHR_deferred_host_operations
API Interactions
Interacts with VK_ARM_tensors
SPIR-V Dependencies
SPV_ARM_graph
Contact
Kevin Petit
kpet
Other Extension Metadata
Last Modified Date
2025-06-18
Interactions and External Dependencies
This extension requires
SPV_ARM_graph
This extension interacts with
VK_EXT_mutable_descriptor_type
This extension interacts with
VK_EXT_pipeline_protected_access
This extension interacts with
VK_ARM_tensors
This extension interacts with
VK_EXT_descriptor_buffer
This extension interacts with
VK_KHR_maintenance6
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Emma Ben Yossef, Arm Ltd.
Stefano Bucciarelli, Arm Ltd.
Marco Cattani, Arm Ltd.
Aaron DeBattista, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Einar Hov, Arm Ltd.
Robert Hughes, Arm Ltd.
Oualid Khelifi, Arm Ltd.
Derek Lamberti, Arm Ltd.
Chetan Mistry, Arm Ltd.
Georgios Teneketzis, Arm Ltd.
Matthew Netsch, Qualcomm Technologies, Inc
Description
This extension adds support for a new type of pipeline, data graph
pipelines, that provide an encapsulation construct for computational graphs
operating on full resources (e.g. ML/AI graphs, image processing pipelines,
etc).
This extension only supports tensor resources and does not define any
operations that can be used within those graphs.
These operations will be defined by separate extensions.
New Object Types
VkDataGraphPipelineSessionARM
New Commands
vkBindDataGraphPipelineSessionMemoryARM
vkCmdDispatchDataGraphARM
vkCreateDataGraphPipelineSessionARM
vkCreateDataGraphPipelinesARM
vkDestroyDataGraphPipelineSessionARM
vkGetDataGraphPipelineAvailablePropertiesARM
vkGetDataGraphPipelinePropertiesARM
vkGetDataGraphPipelineSessionBindPointRequirementsARM
vkGetDataGraphPipelineSessionMemoryRequirementsARM
vkGetPhysicalDeviceQueueFamilyDataGraphProcessingEnginePropertiesARM
vkGetPhysicalDeviceQueueFamilyDataGraphPropertiesARM
New Structures
VkBindDataGraphPipelineSessionMemoryInfoARM
VkDataGraphPipelineConstantARM
VkDataGraphPipelineCreateInfoARM
VkDataGraphPipelineDispatchInfoARM
VkDataGraphPipelineInfoARM
VkDataGraphPipelinePropertyQueryResultARM
VkDataGraphPipelineResourceInfoARM
VkDataGraphPipelineSessionBindPointRequirementARM
VkDataGraphPipelineSessionBindPointRequirementsInfoARM
VkDataGraphPipelineSessionCreateInfoARM
VkDataGraphPipelineSessionMemoryRequirementsInfoARM
VkPhysicalDeviceDataGraphOperationSupportARM
VkPhysicalDeviceDataGraphProcessingEngineARM
VkPhysicalDeviceQueueFamilyDataGraphProcessingEngineInfoARM
VkQueueFamilyDataGraphProcessingEnginePropertiesARM
VkQueueFamilyDataGraphPropertiesARM
Extending
VkDataGraphPipelineCreateInfoARM
VkDataGraphPipelineCompilerControlCreateInfoARM
VkDataGraphPipelineIdentifierCreateInfoARM
VkDataGraphPipelineShaderModuleCreateInfoARM
Extending
VkDataGraphPipelineCreateInfoARM
VkDescriptorPoolCreateInfo
VkCommandPoolCreateInfo
VkDataGraphProcessingEngineCreateInfoARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDataGraphFeaturesARM
If
VK_ARM_tensors
is supported:
Extending
VkDataGraphPipelineConstantARM
VkDataGraphPipelineConstantTensorSemiStructuredSparsityInfoARM
New Enums
VkDataGraphPipelineDispatchFlagBitsARM
VkDataGraphPipelinePropertyARM
VkDataGraphPipelineSessionBindPointARM
VkDataGraphPipelineSessionBindPointTypeARM
VkDataGraphPipelineSessionCreateFlagBitsARM
VkPhysicalDeviceDataGraphOperationTypeARM
VkPhysicalDeviceDataGraphProcessingEngineTypeARM
New Bitmasks
VkDataGraphPipelineDispatchFlagsARM
VkDataGraphPipelineSessionCreateFlagsARM
New Enum Constants
VK_ARM_DATA_GRAPH_EXTENSION_NAME
VK_ARM_DATA_GRAPH_SPEC_VERSION
VK_MAX_PHYSICAL_DEVICE_DATA_GRAPH_OPERATION_SET_NAME_SIZE_ARM
Extending
VkAccessFlagBits2
VK_ACCESS_2_DATA_GRAPH_READ_BIT_ARM
VK_ACCESS_2_DATA_GRAPH_WRITE_BIT_ARM
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_DATA_GRAPH_FOREIGN_DESCRIPTOR_BIT_ARM
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_TENSOR_DATA_GRAPH_BIT_ARM
Extending
VkObjectType
VK_OBJECT_TYPE_DATA_GRAPH_PIPELINE_SESSION_ARM
Extending
VkPipelineBindPoint
VK_PIPELINE_BIND_POINT_DATA_GRAPH_ARM
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_DATA_GRAPH_BIT_ARM
Extending
VkQueueFlagBits
VK_QUEUE_DATA_GRAPH_BIT_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_DATA_GRAPH_PIPELINE_SESSION_MEMORY_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_COMPILER_CONTROL_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_CONSTANT_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_DISPATCH_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_IDENTIFIER_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_PROPERTY_QUERY_RESULT_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_RESOURCE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SESSION_BIND_POINT_REQUIREMENTS_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SESSION_BIND_POINT_REQUIREMENT_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SESSION_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SESSION_MEMORY_REQUIREMENTS_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SHADER_MODULE_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PROCESSING_ENGINE_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DATA_GRAPH_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_QUEUE_FAMILY_DATA_GRAPH_PROCESSING_ENGINE_INFO_ARM
VK_STRUCTURE_TYPE_QUEUE_FAMILY_DATA_GRAPH_PROCESSING_ENGINE_PROPERTIES_ARM
VK_STRUCTURE_TYPE_QUEUE_FAMILY_DATA_GRAPH_PROPERTIES_ARM
Extending
VkTensorUsageFlagBitsARM
VK_TENSOR_USAGE_DATA_GRAPH_BIT_ARM
If
VK_ARM_tensors
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_CONSTANT_TENSOR_SEMI_STRUCTURED_SPARSITY_INFO_ARM
New SPIR-V Capabilities
GraphARM
Issues
1) Should graph pipeline resource info structures be integrated into
pipeline layouts? Would a new graph pipeline layout be a better fit?
RESOLVED
: Graph pipeline resource info are passed separately at pipeline
creation time.
2) Do we need a new shader stage for graph pipelines for use in creating
descriptor set layouts?
RESOLVED
: Currently using
VK_SHADER_STAGE_ALL
3) Should this extension provide applications with a way of knowing which
combinations of sparsity information implementations can take advantage of
when processing graph constants?
RESOLVED
: No.
Describing the exact combinations is in some cases complex and it is always
valid for implementations to ignore the sparsity information and treat the
data as dense.
Specific implementations can provide guidance to application writers if they
so desire and applications are encouraged to always provide sparsity
information that they have.
Version History
Revision 1, 2025-06-18 (Kévin Petit)
Initial revision
VK_ARM_data_graph_instruction_set_tosa
Name String
VK_ARM_data_graph_instruction_set_tosa
Extension Type
Device extension
Registered Extension Number
509
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_ARM_data_graph
Contact
Kevin Petit
kpet
Other Extension Metadata
Last Modified Date
2026-03-30
Interactions and External Dependencies
This extension requires
the
TOSA SPIR-V 001000.1 extended instruction set
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Description
This extensions adds support for the
TOSA.001000.1
extended instruction
set for use in data graphs as defined by
VK_ARM_data_graph
It also adds detailed queries to report the TOSA profiles, levels, and
extensions that are supported along with the quality of the implementation
(e.g. accelerated, experimental, deprecated, etc).
New Commands
vkGetPhysicalDeviceQueueFamilyDataGraphEngineOperationPropertiesARM
New Structures
VkDataGraphTOSANameQualityARM
VkQueueFamilyDataGraphTOSAPropertiesARM
New Enums
VkDataGraphTOSALevelARM
VkDataGraphTOSAQualityFlagBitsARM
New Bitmasks
VkDataGraphTOSAQualityFlagsARM
New Enum Constants
VK_ARM_DATA_GRAPH_INSTRUCTION_SET_TOSA_EXTENSION_NAME
VK_ARM_DATA_GRAPH_INSTRUCTION_SET_TOSA_SPEC_VERSION
VK_MAX_DATA_GRAPH_TOSA_NAME_SIZE_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_QUEUE_FAMILY_DATA_GRAPH_TOSA_PROPERTIES_ARM
New SPIR-V Capabilities
None.
Issues
None.
Version History
Revision 1, 2026-03-30 (Kévin Petit)
Initial revision
VK_ARM_data_graph_optical_flow
Name String
VK_ARM_data_graph_optical_flow
Extension Type
Device extension
Registered Extension Number
632
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_ARM_data_graph
Contact
Kevin Petit
kpet
Other Extension Metadata
Last Modified Date
2026-04-08
Contributors
Contributors to VK_NV_optical_flow
Kevin Petit, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Steve Suzuki, Arm Ltd.
Liam O’Neil, Arm Ltd.
Description
This extension allows applications to estimate the 2D displacement of pixels
between two images.
New Commands
vkGetPhysicalDeviceQueueFamilyDataGraphEngineOperationPropertiesARM
vkGetPhysicalDeviceQueueFamilyDataGraphOpticalFlowImageFormatsARM
New Structures
VkDataGraphOpticalFlowImageFormatPropertiesARM
VkDataGraphPipelineSingleNodeConnectionARM
VkQueueFamilyDataGraphOpticalFlowPropertiesARM
Extending
VkDataGraphPipelineCreateInfoARM
VkDataGraphPipelineOpticalFlowCreateInfoARM
VkDataGraphPipelineSingleNodeCreateInfoARM
Extending
VkDataGraphPipelineDispatchInfoARM
VkDataGraphPipelineOpticalFlowDispatchInfoARM
Extending
VkDataGraphPipelineResourceInfoARM
VkDataGraphPipelineResourceInfoImageLayoutARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDataGraphOpticalFlowFeaturesARM
Extending
VkPhysicalDeviceImageFormatInfo2
VkImageCreateInfo
VkDataGraphOpticalFlowImageFormatInfoARM
New Enums
VkDataGraphOpticalFlowCreateFlagBitsARM
VkDataGraphOpticalFlowExecuteFlagBitsARM
VkDataGraphOpticalFlowGridSizeFlagBitsARM
VkDataGraphOpticalFlowImageUsageFlagBitsARM
VkDataGraphOpticalFlowPerformanceLevelARM
VkDataGraphPipelineNodeConnectionTypeARM
VkDataGraphPipelineNodeTypeARM
New Bitmasks
VkDataGraphOpticalFlowCreateFlagsARM
VkDataGraphOpticalFlowExecuteFlagsARM
VkDataGraphOpticalFlowGridSizeFlagsARM
VkDataGraphOpticalFlowImageUsageFlagsARM
New Enum Constants
VK_ARM_DATA_GRAPH_OPTICAL_FLOW_EXTENSION_NAME
VK_ARM_DATA_GRAPH_OPTICAL_FLOW_SPEC_VERSION
Extending
VkDataGraphPipelineNodeConnectionTypeARM
VK_DATA_GRAPH_PIPELINE_NODE_CONNECTION_TYPE_OPTICAL_FLOW_COST_ARM
VK_DATA_GRAPH_PIPELINE_NODE_CONNECTION_TYPE_OPTICAL_FLOW_FLOW_VECTOR_ARM
VK_DATA_GRAPH_PIPELINE_NODE_CONNECTION_TYPE_OPTICAL_FLOW_HINT_ARM
VK_DATA_GRAPH_PIPELINE_NODE_CONNECTION_TYPE_OPTICAL_FLOW_INPUT_ARM
VK_DATA_GRAPH_PIPELINE_NODE_CONNECTION_TYPE_OPTICAL_FLOW_REFERENCE_ARM
Extending
VkDataGraphPipelineNodeTypeARM
VK_DATA_GRAPH_PIPELINE_NODE_TYPE_OPTICAL_FLOW_ARM
Extending
VkDataGraphPipelineSessionBindPointARM
VK_DATA_GRAPH_PIPELINE_SESSION_BIND_POINT_OPTICAL_FLOW_CACHE_ARM
Extending
VkDataGraphPipelineSessionCreateFlagBitsARM
VK_DATA_GRAPH_PIPELINE_SESSION_CREATE_OPTICAL_FLOW_CACHE_BIT_ARM
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_DATA_GRAPH_OPTICAL_FLOW_COST_BIT_ARM
VK_FORMAT_FEATURE_2_DATA_GRAPH_OPTICAL_FLOW_IMAGE_BIT_ARM
VK_FORMAT_FEATURE_2_DATA_GRAPH_OPTICAL_FLOW_VECTOR_BIT_ARM
Extending
VkPhysicalDeviceDataGraphOperationTypeARM
VK_PHYSICAL_DEVICE_DATA_GRAPH_OPERATION_TYPE_OPTICAL_FLOW_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_DATA_GRAPH_OPTICAL_FLOW_IMAGE_FORMAT_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_OPTICAL_FLOW_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_OPTICAL_FLOW_DISPATCH_INFO_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_RESOURCE_INFO_IMAGE_LAYOUT_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SINGLE_NODE_CONNECTION_ARM
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_SINGLE_NODE_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DATA_GRAPH_OPTICAL_FLOW_FEATURES_ARM
VK_STRUCTURE_TYPE_QUEUE_FAMILY_DATA_GRAPH_OPTICAL_FLOW_PROPERTIES_ARM
Version History
Revision 1, 2026-04-08 (Kevin Petit)
Internal revisions
VK_ARM_format_pack
Name String
VK_ARM_format_pack
Extension Type
Device extension
Registered Extension Number
610
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2025-03-24
Interactions and External Dependencies
Contributors
Jan-Harald Fredriksen, Arm
Lisa Wu, Arm
Oivind Boge, Arm
Description
This extension adds support for additional 1-, 2- and 4-component formats
with 10, 12, or 14 bits of components in 16-bit containers.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFormatPackFeaturesARM
New Enum Constants
VK_ARM_FORMAT_PACK_EXTENSION_NAME
VK_ARM_FORMAT_PACK_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_G14X2_B14X2R14X2_2PLANE_420_UNORM_3PACK16_ARM
VK_FORMAT_G14X2_B14X2R14X2_2PLANE_422_UNORM_3PACK16_ARM
VK_FORMAT_R10X6G10X6B10X6A10X6_UINT_4PACK16_ARM
VK_FORMAT_R10X6G10X6_UINT_2PACK16_ARM
VK_FORMAT_R10X6_UINT_PACK16_ARM
VK_FORMAT_R12X4G12X4B12X4A12X4_UINT_4PACK16_ARM
VK_FORMAT_R12X4G12X4_UINT_2PACK16_ARM
VK_FORMAT_R12X4_UINT_PACK16_ARM
VK_FORMAT_R14X2G14X2B14X2A14X2_UINT_4PACK16_ARM
VK_FORMAT_R14X2G14X2B14X2A14X2_UNORM_4PACK16_ARM
VK_FORMAT_R14X2G14X2_UINT_2PACK16_ARM
VK_FORMAT_R14X2G14X2_UNORM_2PACK16_ARM
VK_FORMAT_R14X2_UINT_PACK16_ARM
VK_FORMAT_R14X2_UNORM_PACK16_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FORMAT_PACK_FEATURES_ARM
Issues
What do we call this extension?
RESOLVED
Many existing extension have the format in the name, but in this case we
want to expose multiple formats.
We will describe this set of formats as a “pack”.
Compatibility classes
RESOLVED
Should these additional formats be in the same compatibility class as any
other formats? For single-plane formats, we put formats with the same number
of bits (but different types) in the same class.
Each multi-plane or subsampled format gets its own compatibility class.
This is consistent with how existing formats are handled.
Format feature requirements
RESOLVED
The format feature queries could be used to determine what is supported on
any given implementation, but it may be useful to establish a baseline
requirement in the specification.
For that purpose, we require a set of format features - sufficient to enable
texture operations - to be supported for the added unsigned integer
single-plane formats.
Other formats and format features are optional.
Version History
Revision 1, 2025-03-24
Initial revision
VK_ARM_performance_counters_by_region
Name String
VK_ARM_performance_counters_by_region
Extension Type
Device extension
Registered Extension Number
606
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
Developer tools
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_ARM_performance_counters_by_region
Other Extension Metadata
Last Modified Date
2025-09-09
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm Ltd.
Lisa Wu, Arm Ltd.
Ting Wei, Arm Ltd.
Nikunj Patel, Arm Ltd.
Peter Harris, Arm Ltd.
Camden Mannett, Arm Ltd.
Description
This extension provides the ability to capture performance counters per
region ('tile').
It exposes an enumeration of the available counters, and a way to request
counters to be captured per render pass instance.
New Commands
vkEnumeratePhysicalDeviceQueueFamilyPerformanceCountersByRegionARM
New Structures
VkPerformanceCounterARM
VkPerformanceCounterDescriptionARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePerformanceCountersByRegionFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePerformanceCountersByRegionPropertiesARM
Extending
VkRenderPassBeginInfo
VkRenderingInfo
VkRenderPassPerformanceCountersByRegionBeginInfoARM
New Bitmasks
VkPerformanceCounterDescriptionFlagsARM
New Enum Constants
VK_ARM_PERFORMANCE_COUNTERS_BY_REGION_EXTENSION_NAME
VK_ARM_PERFORMANCE_COUNTERS_BY_REGION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_ARM
VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_DESCRIPTION_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_COUNTERS_BY_REGION_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_COUNTERS_BY_REGION_PROPERTIES_ARM
VK_STRUCTURE_TYPE_RENDER_PASS_PERFORMANCE_COUNTERS_BY_REGION_BEGIN_INFO_ARM
Issues
What is the security model of this extension?
RESOLVED
The GPU hardware is able to run workloads from multiple applications
concurrently.
This introduces the possibility of side-channel leaks where one process can
observe the side effects (e.g., memory pressure) of work done in another
process.
To prevent such leaks when using this extension, the following is
guaranteed:
Command buffers that capture performance counters are automatically
executed in an “exclusive mode”, meaning that they do not run
concurrently with workloads from any other process.
The physical device, at the level of hardware and firmware, guarantees
that performance counters are only captured in “exclusive mode”, and
otherwise returns zero for all counters.
Additionally, this performance counter mechanism only exposes shader core
counters.
Counters related to the external memory system or interactions between
external memory and L2 caches are not available.
Version History
Revision 1, 2025-09-09 (Jan-Harald Fredriksen)
Initial draft.
VK_ARM_pipeline_opacity_micromap
Name String
VK_ARM_pipeline_opacity_micromap
Extension Type
Device extension
Registered Extension Number
597
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_opacity_micromap
Contact
Mathieu Robart
mathieurobart-arm
Extension Proposal
VK_ARM_pipeline_opacity_micromap
Other Extension Metadata
Last Modified Date
2025-01-07
IP Status
No known IP claims.
Contributors
Mathieu Robart, Arm
Marius Bjorge, Arm
Yaozhong Zhang, Arm
Jan-Harald Fredriksen, Arm
Description
The Opacity Micromap extension
VK_EXT_opacity_micromap
supports the new
pipeline creation flag
VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT
, indicating that
the ray tracing pipeline may be used with acceleration structures
referencing micromaps.
This allows for possible optimizations, knowing beforehand that opacity
micromaps may be used with the pipeline.
An equivalent flag does not exist for pipelines supporting Ray Query with
opacity micromaps, such as graphics and compute.
Consequently, it is currently not possible to optimize such pipelines for
no-opacity, e.g. when opacity micromaps are supported by an application but
not used by the pipeline.
This may lead to performance degradation.
This extension adds a new flag,
VK_PIPELINE_CREATE_2_DISALLOW_OPACITY_MICROMAP_BIT_ARM
, indicating that a
pipeline will NOT be used with an acceleration structure referencing an
opacity micromap, therefore allowing possible pipeline optimizations.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineOpacityMicromapFeaturesARM
New Enum Constants
VK_ARM_PIPELINE_OPACITY_MICROMAP_EXTENSION_NAME
VK_ARM_PIPELINE_OPACITY_MICROMAP_SPEC_VERSION
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_DISALLOW_OPACITY_MICROMAP_BIT_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_OPACITY_MICROMAP_FEATURES_ARM
Issues
None.
Examples
None.
Version History
Revision 1, 2025-01-07 (Mathieu Robart)
Initial draft
VK_ARM_render_pass_striped
Name String
VK_ARM_render_pass_striped
Extension Type
Device extension
Registered Extension Number
425
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_ARM_render_pass_striped
Other Extension Metadata
Last Modified Date
2023-11-21
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm
Lisa Wu, Arm
Torbjorn Nilsson, Arm
Ying-Chieh Chen, Mediatek
Jim Chiu, Mediatek
Description
This extension adds the ability to split a render pass instance into
stripes, and to get a notification when rendering has completed for each
stripe.
New Structures
VkRenderPassStripeInfoARM
Extending
VkCommandBufferSubmitInfo
VkRenderPassStripeSubmitInfoARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRenderPassStripedFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRenderPassStripedPropertiesARM
Extending
VkRenderingInfo
VkRenderPassBeginInfo
VkRenderPassStripeBeginInfoARM
New Enum Constants
VK_ARM_RENDER_PASS_STRIPED_EXTENSION_NAME
VK_ARM_RENDER_PASS_STRIPED_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RENDER_PASS_STRIPED_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RENDER_PASS_STRIPED_PROPERTIES_ARM
VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_BEGIN_INFO_ARM
VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_INFO_ARM
VK_STRUCTURE_TYPE_RENDER_PASS_STRIPE_SUBMIT_INFO_ARM
Examples
None.
Version History
Revision 1, 2023-11-21
Initial revision
VK_ARM_scheduling_controls
Name String
VK_ARM_scheduling_controls
Extension Type
Device extension
Registered Extension Number
418
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_ARM_shader_core_builtins
Contact
Kevin Petit
kpet
Other Extension Metadata
Last Modified Date
2025-09-05
Interactions and External Dependencies
None
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Mikel Garai, Arm Ltd.
Description
This extension exposes a collection of controls to modify the scheduling
behavior of Arm Mali devices.
New Commands
vkCmdSetDispatchParametersARM
New Structures
VkDispatchParametersARM
Extending
VkDeviceQueueCreateInfo
VkDeviceCreateInfo
VkDeviceQueueShaderCoreControlCreateInfoARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSchedulingControlsFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceSchedulingControlsDispatchParametersPropertiesARM
VkPhysicalDeviceSchedulingControlsPropertiesARM
New Enums
VkPhysicalDeviceSchedulingControlsFlagBitsARM
New Bitmasks
VkPhysicalDeviceSchedulingControlsFlagsARM
New Enum Constants
VK_ARM_SCHEDULING_CONTROLS_EXTENSION_NAME
VK_ARM_SCHEDULING_CONTROLS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_QUEUE_SHADER_CORE_CONTROL_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_DISPATCH_PARAMETERS_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_DISPATCH_PARAMETERS_PROPERTIES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_PROPERTIES_ARM
New SPIR-V Capabilities
None.
Issues
None.
Version History
Revision 2, 2025-09-05 (Kévin Petit)
Add dispatch parameters controls
VK_PHYSICAL_DEVICE_SCHEDULING_CONTROLS_DISPATCH_PARAMETERS_ARM
vkCmdSetDispatchParametersARM
VkDispatchParametersARM
VkPhysicalDeviceSchedulingControlsDispatchParametersPropertiesARM
Revision 1, 2023-08-23 (Kévin Petit)
Initial revision
VK_ARM_shader_core_builtins
Name String
VK_ARM_shader_core_builtins
Extension Type
Device extension
Registered Extension Number
498
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_ARM_core_builtins
Contact
Kevin Petit
kpet
Other Extension Metadata
Last Modified Date
2022-10-05
Interactions and External Dependencies
This extension provides API support for
GL_ARM_shader_core_builtins
Contributors
Kevin Petit, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Description
This extension provides the ability to determine device-specific properties
on Arm GPUs.
It exposes properties for the number of shader cores, the maximum number of
warps that can run on a shader core, and shader builtins to enable
invocations to identify which core and warp a shader invocation is executing
on.
This extension enables support for the SPIR-V
CoreBuiltinsARM
capability.
These properties and built-ins can be used for debugging or performance
optimization purposes.
A typical optimization example would be to use
CoreIDARM
to select a
per-shader-core instance of a data structure in algorithms that use atomics
so as to reduce contention.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderCoreBuiltinsFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderCoreBuiltinsPropertiesARM
New Enum Constants
VK_ARM_SHADER_CORE_BUILTINS_EXTENSION_NAME
VK_ARM_SHADER_CORE_BUILTINS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_PROPERTIES_ARM
New or Modified Built-In Variables
CoreCountARM
CoreMaxIDARM
CoreIDARM
WarpsMaxIDARM
WarpIDARM
New SPIR-V Capabilities
CoreBuiltinsARM
Issues
None.
Version History
Revision 1, 2022-10-05 (Kevin Petit)
Initial revision
Revision 2, 2022-10-26 (Kevin Petit)
Add
shaderCoreMask
property
VK_ARM_shader_core_properties
Name String
VK_ARM_shader_core_properties
Extension Type
Device extension
Registered Extension Number
416
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2023-02-07
IP Status
No known IP claims.
Contributors
Jan-Harald Fredriksen, Arm Ltd.
Description
This extension provides the ability to determine device-specific performance
properties of Arm GPUs.
It exposes properties for the number of texel, pixel, and fused multiply-add
operations per clock per shader core.
This can be used in combination with the
VK_ARM_shader_core_builtins
extension that provides the ability to
query the number of shader cores on the physical device.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderCorePropertiesARM
New Enum Constants
VK_ARM_SHADER_CORE_PROPERTIES_EXTENSION_NAME
VK_ARM_SHADER_CORE_PROPERTIES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_ARM
Version History
Revision 1, 2023-02-07 (Jan-Harald Fredriksen)
Initial draft.
VK_ARM_shader_instrumentation
Name String
VK_ARM_shader_instrumentation
Extension Type
Device extension
Registered Extension Number
608
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_EXT_shader_object
Special Use
Developer tools
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Extension Proposal
VK_ARM_shader_instrumentation
Other Extension Metadata
Last Modified Date
2026-02-26
IP Status
No known IP claims.
Contributors
Embla Flatlandsmo, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Mikel Garai, Arm Ltd.
Peter Harris, Arm Ltd.
Ting Wei, Arm Ltd.
Torbjörn Nilsson, Arm Ltd.
Description
This extension provides the ability to instrument shaders and capture
performance metrics per shader type from commands executed by a queue.
New Object Types
VkShaderInstrumentationARM
New Commands
vkClearShaderInstrumentationMetricsARM
vkCmdBeginShaderInstrumentationARM
vkCmdEndShaderInstrumentationARM
vkCreateShaderInstrumentationARM
vkDestroyShaderInstrumentationARM
vkEnumeratePhysicalDeviceShaderInstrumentationMetricsARM
vkGetShaderInstrumentationValuesARM
New Structures
VkShaderInstrumentationCreateInfoARM
VkShaderInstrumentationMetricDataHeaderARM
VkShaderInstrumentationMetricDescriptionARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderInstrumentationFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderInstrumentationPropertiesARM
New Bitmasks
VkShaderInstrumentationValuesFlagsARM
New Enum Constants
VK_ARM_SHADER_INSTRUMENTATION_EXTENSION_NAME
VK_ARM_SHADER_INSTRUMENTATION_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_SHADER_INSTRUMENTATION_ARM
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_INSTRUMENT_SHADERS_BIT_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INSTRUMENTATION_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INSTRUMENTATION_PROPERTIES_ARM
VK_STRUCTURE_TYPE_SHADER_INSTRUMENTATION_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_SHADER_INSTRUMENTATION_METRIC_DESCRIPTION_ARM
If
VK_EXT_shader_object
is supported:
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_INSTRUMENT_SHADER_BIT_ARM
Version History
Revision 1, 2026-02-26 (Embla Flatlandsmo, Jan-Harald Fredriksen)
Initial draft.
VK_ARM_tensors
Name String
VK_ARM_tensors
Extension Type
Device extension
Registered Extension Number
461
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.3
API Interactions
Interacts with VK_EXT_descriptor_buffer
Interacts with VK_EXT_frame_boundary
Interacts with VK_EXT_shader_float8
Interacts with VK_KHR_shader_bfloat16
SPIR-V Dependencies
SPV_ARM_tensors
Contact
Kevin Petit
kpet
Extension Proposal
VK_ARM_tensors
Other Extension Metadata
Last Modified Date
2026-01-07
Interactions and External Dependencies
This extension requires
SPV_ARM_tensors
This extension provides API support for
GL_ARM_tensors
This extension interacts with
VK_EXT_mutable_descriptor_type
This extension interacts with
VK_EXT_descriptor_buffer
This extension interacts with
VK_EXT_frame_boundary
This extension interacts with
VK_EXT_robustness2
This extension interacts with
VK_KHR_unified_image_layouts
This extension interacts with
VK_KHR_shader_bfloat16
This extension interacts with
VK_EXT_shader_float8
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Einar Hov, Arm Ltd.
Dominic Symes, Arm Ltd.
Jan-Harald Fredriksen, Arm Ltd.
Marco Cattani, Arm Ltd.
Lisa Wu, Arm Ltd.
Robert Hughes, Arm Ltd.
David Garbett, Arm Ltd.
Oualid Khelifi, Arm Ltd.
Description
This extension adds support for tensors.
New Object Types
VkTensorARM
VkTensorViewARM
New Commands
vkBindTensorMemoryARM
vkCmdCopyTensorARM
vkCreateTensorARM
vkCreateTensorViewARM
vkDestroyTensorARM
vkDestroyTensorViewARM
vkGetDeviceTensorMemoryRequirementsARM
vkGetPhysicalDeviceExternalTensorPropertiesARM
vkGetTensorMemoryRequirementsARM
If
VK_EXT_descriptor_buffer
is supported:
vkGetTensorOpaqueCaptureDescriptorDataARM
vkGetTensorViewOpaqueCaptureDescriptorDataARM
New Structures
VkBindTensorMemoryInfoARM
VkCopyTensorInfoARM
VkDeviceTensorMemoryRequirementsARM
VkExternalTensorPropertiesARM
VkPhysicalDeviceExternalTensorInfoARM
VkTensorCopyARM
VkTensorCreateInfoARM
VkTensorMemoryRequirementsInfoARM
VkTensorViewCreateInfoARM
Extending
VkDataGraphPipelineResourceInfoARM
VkDataGraphPipelineConstantARM
VkTensorDescriptionARM
Extending
VkDependencyInfo
VkTensorDependencyInfoARM
VkTensorMemoryBarrierARM
Extending
VkFormatProperties2
VkTensorFormatPropertiesARM
Extending
VkMemoryAllocateInfo
VkMemoryDedicatedAllocateInfoTensorARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTensorFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTensorPropertiesARM
Extending
VkTensorCreateInfoARM
VkExternalMemoryTensorCreateInfoARM
Extending
VkWriteDescriptorSet
VkWriteDescriptorSetTensorARM
If
VK_EXT_descriptor_buffer
is supported:
VkTensorCaptureDescriptorDataInfoARM
VkTensorViewCaptureDescriptorDataInfoARM
Extending
VkDescriptorGetInfoEXT
VkDescriptorGetTensorInfoARM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorBufferTensorFeaturesARM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorBufferTensorPropertiesARM
If
VK_EXT_frame_boundary
is supported:
Extending
VkSubmitInfo
VkSubmitInfo2
VkPresentInfoKHR
VkBindSparseInfo
VkFrameBoundaryTensorsARM
New Enums
VkTensorCreateFlagBitsARM
VkTensorTilingARM
VkTensorUsageFlagBitsARM
VkTensorViewCreateFlagBitsARM
New Bitmasks
VkTensorCreateFlagsARM
VkTensorUsageFlagsARM
VkTensorViewCreateFlagsARM
New Enum Constants
VK_ARM_TENSORS_EXTENSION_NAME
VK_ARM_TENSORS_SPEC_VERSION
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_TENSOR_ARM
Extending
VkFormat
VK_FORMAT_R8_BOOL_ARM
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_TENSOR_IMAGE_ALIASING_BIT_ARM
VK_FORMAT_FEATURE_2_TENSOR_SHADER_BIT_ARM
Extending
VkImageLayout
VK_IMAGE_LAYOUT_TENSOR_ALIASING_ARM
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_TENSOR_ALIASING_BIT_ARM
Extending
VkObjectType
VK_OBJECT_TYPE_TENSOR_ARM
VK_OBJECT_TYPE_TENSOR_VIEW_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_TENSOR_MEMORY_INFO_ARM
VK_STRUCTURE_TYPE_COPY_TENSOR_INFO_ARM
VK_STRUCTURE_TYPE_DEVICE_TENSOR_MEMORY_REQUIREMENTS_ARM
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_TENSOR_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_EXTERNAL_TENSOR_PROPERTIES_ARM
VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_TENSOR_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_TENSOR_INFO_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TENSOR_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TENSOR_PROPERTIES_ARM
VK_STRUCTURE_TYPE_TENSOR_COPY_ARM
VK_STRUCTURE_TYPE_TENSOR_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_TENSOR_DEPENDENCY_INFO_ARM
VK_STRUCTURE_TYPE_TENSOR_DESCRIPTION_ARM
VK_STRUCTURE_TYPE_TENSOR_FORMAT_PROPERTIES_ARM
VK_STRUCTURE_TYPE_TENSOR_MEMORY_BARRIER_ARM
VK_STRUCTURE_TYPE_TENSOR_MEMORY_REQUIREMENTS_INFO_ARM
VK_STRUCTURE_TYPE_TENSOR_VIEW_CREATE_INFO_ARM
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_TENSOR_ARM
If
VK_EXT_descriptor_buffer
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_DESCRIPTOR_GET_TENSOR_INFO_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_TENSOR_FEATURES_ARM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_TENSOR_PROPERTIES_ARM
VK_STRUCTURE_TYPE_TENSOR_CAPTURE_DESCRIPTOR_DATA_INFO_ARM
VK_STRUCTURE_TYPE_TENSOR_VIEW_CAPTURE_DESCRIPTOR_DATA_INFO_ARM
Extending
VkTensorCreateFlagBitsARM
VK_TENSOR_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_ARM
Extending
VkTensorViewCreateFlagBitsARM
VK_TENSOR_VIEW_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_ARM
If
VK_EXT_frame_boundary
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_FRAME_BOUNDARY_TENSORS_ARM
If
VK_EXT_shader_float8
is supported:
Extending
VkFormat
VK_FORMAT_R8_SFLOAT_FPENCODING_FLOAT8E4M3_ARM
VK_FORMAT_R8_SFLOAT_FPENCODING_FLOAT8E5M2_ARM
If
VK_KHR_shader_bfloat16
is supported:
Extending
VkFormat
VK_FORMAT_R16_SFLOAT_FPENCODING_BFLOAT16_ARM
New SPIR-V Capabilities
TensorsARM
StorageTensorArrayDynamicIndexingARM
StorageTensorArrayNonUniformIndexingARM
Issues
1) Should tensor strides be passed in elements or in bytes?
RESOLVED
: Strides are passed in bytes but are required to be a multiple of
the tensor element size.
Passing strides in bytes makes it possible to relax this requirement in the
future without an interface change.
It also makes it easier to describe memory alignment requirements.
2) Should there be commands to copy data between tensors and buffers/images?
RESOLVED
: Adding these commands would result in a rather large API surface
and not insignificant implementation and validation cost.
The same outcome can be achieved with memory aliasing and tensor to tensor
copy operations.
3) Should this extension define transpose and/or other data reorganization
operations?
RESOLVED
: These operations are useful to expose but this extension is only
meant to add base support for tensors.
Additional operations should be layered on top and defined in other
extensions.
4) Why are tensor strides described using signed integers?
RESOLVED
: Negative strides make it possible to describe different linear
data layouts.
While this extension does not allow negative strides, it uses signed
integers for strides to make it possible to relax this limitation in future
extensions.
Version History
Revision 2, 2026-01-07 (Kévin Petit)
Add interactions with VK_KHR_unified_image_layouts,
VK_KHR_shader_bfloat16, and VK_EXT_shader_float8
Revision 1, 2025-06-03 (Kévin Petit)
Initial revision
VK_FUCHSIA_buffer_collection
Name String
VK_FUCHSIA_buffer_collection
Extension Type
Device extension
Registered Extension Number
367
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_FUCHSIA_external_memory
and
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
API Interactions
Interacts with VK_EXT_debug_report
Contact
John Rosasco
rosasco
Other Extension Metadata
Last Modified Date
2021-09-23
IP Status
No known IP claims.
Contributors
Craig Stout, Google
John Bauman, Google
John Rosasco, Google
Description
A buffer collection is a collection of one or more buffers which were
allocated together as a group and which all have the same properties.
These properties describe the buffers' internal representation such as its
dimensions and memory layout.
This ensures that all of the buffers can be used interchangeably by tasks
that require swapping among multiple buffers, such as double-buffered
graphics rendering.
By sharing such a collection of buffers between components, communication
about buffer lifecycle can be made much simpler and more efficient.
For example, when a content producer finishes writing to a buffer, it can
message the consumer of the buffer with the buffer index, rather than
passing a handle to the shared memory.
On Fuchsia, the Sysmem service uses buffer collections as a core construct
in its design.
VK_FUCHSIA_buffer_collection is the Vulkan extension that allows Vulkan
applications to interoperate with the Sysmem service on Fuchsia.
New Object Types
VkBufferCollectionFUCHSIA
New Commands
vkCreateBufferCollectionFUCHSIA
vkDestroyBufferCollectionFUCHSIA
vkGetBufferCollectionPropertiesFUCHSIA
vkSetBufferCollectionBufferConstraintsFUCHSIA
vkSetBufferCollectionImageConstraintsFUCHSIA
New Structures
VkBufferCollectionConstraintsInfoFUCHSIA
VkBufferCollectionCreateInfoFUCHSIA
VkBufferCollectionPropertiesFUCHSIA
VkBufferConstraintsInfoFUCHSIA
VkImageConstraintsInfoFUCHSIA
VkImageFormatConstraintsInfoFUCHSIA
VkSysmemColorSpaceFUCHSIA
Extending
VkBufferCreateInfo
VkBufferCollectionBufferCreateInfoFUCHSIA
Extending
VkImageCreateInfo
VkBufferCollectionImageCreateInfoFUCHSIA
Extending
VkMemoryAllocateInfo
VkImportMemoryBufferCollectionFUCHSIA
New Enums
VkImageConstraintsInfoFlagBitsFUCHSIA
New Bitmasks
VkImageConstraintsInfoFlagsFUCHSIA
VkImageFormatConstraintsFlagsFUCHSIA
New Enum Constants
VK_FUCHSIA_BUFFER_COLLECTION_EXTENSION_NAME
VK_FUCHSIA_BUFFER_COLLECTION_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA
Extending
VkStructureType
VK_STRUCTURE_TYPE_BUFFER_COLLECTION_BUFFER_CREATE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CONSTRAINTS_INFO_FUCHSIA
VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CREATE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_BUFFER_COLLECTION_IMAGE_CREATE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_BUFFER_COLLECTION_PROPERTIES_FUCHSIA
VK_STRUCTURE_TYPE_BUFFER_CONSTRAINTS_INFO_FUCHSIA
VK_STRUCTURE_TYPE_IMAGE_CONSTRAINTS_INFO_FUCHSIA
VK_STRUCTURE_TYPE_IMAGE_FORMAT_CONSTRAINTS_INFO_FUCHSIA
VK_STRUCTURE_TYPE_IMPORT_MEMORY_BUFFER_COLLECTION_FUCHSIA
VK_STRUCTURE_TYPE_SYSMEM_COLOR_SPACE_FUCHSIA
If
VK_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA_EXT
Issues
1) When configuring a
VkImageConstraintsInfoFUCHSIA
structure for
constraint setting, should a NULL
pFormatConstraints
parameter be
allowed ?
RESOLVED
: No.
Specifying a NULL
pFormatConstraints
results in logical complexity of
interpreting the relationship between the
VkImageCreateInfo
::
usage
settings of the elements of the
pImageCreateInfos
array and the implied or desired
VkFormatFeatureFlags
The explicit requirement for
pFormatConstraints
to be non-NULL
simplifies the implied logic of the implementation and expectations for the
Vulkan application.
Version History
Revision 2, 2021-09-23 (John Rosasco)
Review passes
Revision 1, 2021-03-09 (John Rosasco)
Initial revision
VK_FUCHSIA_external_memory
Name String
VK_FUCHSIA_external_memory
Extension Type
Device extension
Registered Extension Number
365
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_external_memory_capabilities
and
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
John Rosasco
rosasco
Other Extension Metadata
Last Modified Date
2021-03-01
IP Status
No known IP claims.
Contributors
Craig Stout, Google
John Bauman, Google
John Rosasco, Google
Description
Vulkan apps may wish to export or import device memory handles to or from
other logical devices, instances, or APIs.
This memory sharing can eliminate copies of memory buffers when different
subsystems need to interoperate on them.
Sharing memory buffers may also facilitate a better distribution of
processing workload for more complex memory manipulation pipelines.
New Commands
vkGetMemoryZirconHandleFUCHSIA
vkGetMemoryZirconHandlePropertiesFUCHSIA
New Structures
VkMemoryGetZirconHandleInfoFUCHSIA
VkMemoryZirconHandlePropertiesFUCHSIA
Extending
VkMemoryAllocateInfo
VkImportMemoryZirconHandleInfoFUCHSIA
New Enum Constants
VK_FUCHSIA_EXTERNAL_MEMORY_EXTENSION_NAME
VK_FUCHSIA_EXTERNAL_MEMORY_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_ZIRCON_VMO_BIT_FUCHSIA
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMPORT_MEMORY_ZIRCON_HANDLE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_MEMORY_GET_ZIRCON_HANDLE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_MEMORY_ZIRCON_HANDLE_PROPERTIES_FUCHSIA
Issues
See
VK_KHR_external_memory
issues list for further information.
Version History
Revision 1, 2021-03-01 (John Rosasco)
Initial draft
VK_FUCHSIA_external_semaphore
Name String
VK_FUCHSIA_external_semaphore
Extension Type
Device extension
Registered Extension Number
366
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_external_semaphore_capabilities
and
VK_KHR_external_semaphore
Contact
John Rosasco
rosasco
Other Extension Metadata
Last Modified Date
2021-03-08
IP Status
No known IP claims.
Contributors
Craig Stout, Google
John Bauman, Google
John Rosasco, Google
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 Zircon event handles.
New Commands
vkGetSemaphoreZirconHandleFUCHSIA
vkImportSemaphoreZirconHandleFUCHSIA
New Structures
VkImportSemaphoreZirconHandleInfoFUCHSIA
VkSemaphoreGetZirconHandleInfoFUCHSIA
New Enum Constants
VK_FUCHSIA_EXTERNAL_SEMAPHORE_EXTENSION_NAME
VK_FUCHSIA_EXTERNAL_SEMAPHORE_SPEC_VERSION
Extending
VkExternalSemaphoreHandleTypeFlagBits
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_ZIRCON_EVENT_BIT_FUCHSIA
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_ZIRCON_HANDLE_INFO_FUCHSIA
VK_STRUCTURE_TYPE_SEMAPHORE_GET_ZIRCON_HANDLE_INFO_FUCHSIA
Issues
1) Does the application need to close the Zircon event handle returned by
vkGetSemaphoreZirconHandleFUCHSIA
RESOLVED
: Yes, unless it is passed back in to a driver instance to import
the semaphore.
A successful get call transfers ownership of the Zircon event handle to the
application, and a successful import transfers it back to the driver.
Destroying the original semaphore object will not close the Zircon event
handle nor remove its reference to the underlying semaphore resource
associated with it.
Version History
Revision 1, 2021-03-08 (John Rosasco)
Initial revision
VK_FUCHSIA_imagepipe_surface
Name String
VK_FUCHSIA_imagepipe_surface
Extension Type
Instance extension
Registered Extension Number
215
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Craig Stout
cdotstout
Other Extension Metadata
Last Modified Date
2018-07-27
IP Status
No known IP claims.
Contributors
Craig Stout, Google
Ian Elliott, Google
Jesse Hall, Google
Description
The
VK_FUCHSIA_imagepipe_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 Fuchsia
imagePipeHandle
New Commands
vkCreateImagePipeSurfaceFUCHSIA
New Structures
VkImagePipeSurfaceCreateInfoFUCHSIA
New Bitmasks
VkImagePipeSurfaceCreateFlagsFUCHSIA
New Enum Constants
VK_FUCHSIA_IMAGEPIPE_SURFACE_EXTENSION_NAME
VK_FUCHSIA_IMAGEPIPE_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA
Version History
Revision 1, 2018-07-27 (Craig Stout)
Initial draft.
VK_GGP_frame_token
Name String
VK_GGP_frame_token
Extension Type
Device extension
Registered Extension Number
192
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_GGP_stream_descriptor_surface
Contact
Jean-Francois Roy
jfroy
Other Extension Metadata
Last Modified Date
2019-01-28
IP Status
No known IP claims.
Contributors
Jean-Francois Roy, Google
Richard O’Grady, Google
Description
This extension allows an application that uses the
VK_KHR_swapchain
extension in combination with a Google Games Platform surface provided by
the
VK_GGP_stream_descriptor_surface
extension to associate a
Google Games Platform frame token with a present operation.
New Structures
Extending
VkPresentInfoKHR
VkPresentFrameTokenGGP
New Enum Constants
VK_GGP_FRAME_TOKEN_EXTENSION_NAME
VK_GGP_FRAME_TOKEN_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PRESENT_FRAME_TOKEN_GGP
Version History
Revision 1, 2018-11-26 (Jean-Francois Roy)
Initial revision.
VK_GGP_stream_descriptor_surface
Name String
VK_GGP_stream_descriptor_surface
Extension Type
Instance extension
Registered Extension Number
50
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Jean-Francois Roy
jfroy
Other Extension Metadata
Last Modified Date
2019-01-28
IP Status
No known IP claims.
Contributors
Jean-Francois Roy, Google
Brad Grantham, Google
Connor Smith, Google
Cort Stratton, Google
Hai Nguyen, Google
Ian Elliott, Google
Jesse Hall, Google
Jim Ray, Google
Katherine Wu, Google
Kaye Mason, Google
Kuangye Guo, Google
Mark Segal, Google
Nicholas Vining, Google
Paul Lalonde, Google
Richard O’Grady, Google
Description
The
VK_GGP_stream_descriptor_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 Google Games
Platform
GgpStreamDescriptor
New Commands
vkCreateStreamDescriptorSurfaceGGP
New Structures
VkStreamDescriptorSurfaceCreateInfoGGP
New Bitmasks
VkStreamDescriptorSurfaceCreateFlagsGGP
New Enum Constants
VK_GGP_STREAM_DESCRIPTOR_SURFACE_EXTENSION_NAME
VK_GGP_STREAM_DESCRIPTOR_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_STREAM_DESCRIPTOR_SURFACE_CREATE_INFO_GGP
Version History
Revision 1, 2018-11-26 (Jean-Francois Roy)
Initial revision.
VK_GOOGLE_decorate_string
Name String
VK_GOOGLE_decorate_string
Extension Type
Device extension
Registered Extension Number
225
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_GOOGLE_decorate_string
Contact
Hai Nguyen
chaoticbob
Other Extension Metadata
Last Modified Date
2018-07-09
IP Status
No known IP claims.
Contributors
Hai Nguyen, Google
Neil Henning, AMD
Description
The
VK_GOOGLE_decorate_string
extension allows use of the
SPV_GOOGLE_decorate_string
extension in SPIR-V shader modules.
New Enum Constants
VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME
VK_GOOGLE_DECORATE_STRING_SPEC_VERSION
Version History
Revision 1, 2018-07-09 (Neil Henning)
Initial draft
VK_GOOGLE_display_timing
Name String
VK_GOOGLE_display_timing
Extension Type
Device extension
Registered Extension Number
93
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_swapchain
Contact
Ian Elliott
ianelliottus
Other Extension Metadata
Last Modified Date
2017-02-14
IP Status
No known IP claims.
Contributors
Ian Elliott, Google
Jesse Hall, Google
Description
This device extension allows an application that uses the
VK_KHR_swapchain
extension to obtain information about the
presentation engine’s display, to obtain timing information about each
present, and to schedule a present to happen no earlier than a desired time.
An application can use this to minimize various visual anomalies (e.g.
stuttering).
Traditional game and real-time animation applications need to correctly
position their geometry for when the presentable image will be presented to
the user.
To accomplish this, applications need various timing information about the
presentation engine’s display.
They need to know when presentable images were actually presented, and when
they could have been presented.
Applications also need to tell the presentation engine to display an image
no sooner than a given time.
This allows the application to avoid stuttering, so the animation looks
smooth to the user.
This extension treats variable-refresh-rate (VRR) displays as if they are
fixed-refresh-rate (FRR) displays.
New Commands
vkGetPastPresentationTimingGOOGLE
vkGetRefreshCycleDurationGOOGLE
New Structures
VkPastPresentationTimingGOOGLE
VkPresentTimeGOOGLE
VkRefreshCycleDurationGOOGLE
Extending
VkPresentInfoKHR
VkPresentTimesInfoGOOGLE
New Enum Constants
VK_GOOGLE_DISPLAY_TIMING_EXTENSION_NAME
VK_GOOGLE_DISPLAY_TIMING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE
Examples
The example code for the this extension (like the
VK_KHR_surface
and
VK_GOOGLE_display_timing
extensions) is contained in the cube demo
that is shipped with the official Khronos SDK, and is being kept up-to-date
in that location (see:
).
Version History
Revision 1, 2017-02-14 (Ian Elliott)
Internal revisions
VK_GOOGLE_hlsl_functionality1
Name String
VK_GOOGLE_hlsl_functionality1
Extension Type
Device extension
Registered Extension Number
224
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_GOOGLE_hlsl_functionality1
Contact
Hai Nguyen
chaoticbob
Other Extension Metadata
Last Modified Date
2018-07-09
IP Status
No known IP claims.
Contributors
Hai Nguyen, Google
Neil Henning, AMD
Description
The
VK_GOOGLE_hlsl_functionality1
extension allows use of the
SPV_GOOGLE_hlsl_functionality1
extension in SPIR-V shader modules.
New Enum Constants
VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME
VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION
VK_GOOGLE_HLSL_FUNCTIONALITY_1_EXTENSION_NAME
VK_GOOGLE_HLSL_FUNCTIONALITY_1_SPEC_VERSION
Version History
Revision 1, 2018-07-09 (Neil Henning)
Initial draft
VK_GOOGLE_surfaceless_query
Name String
VK_GOOGLE_surfaceless_query
Extension Type
Instance extension
Registered Extension Number
434
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Special Use
OpenGL / ES support
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_GOOGLE_surfaceless_query
Other Extension Metadata
Last Modified Date
2022-08-03
IP Status
No known IP claims.
Contributors
Ian Elliott, Google
Shahbaz Youssefi, Google
James Jones, NVIDIA
Description
This extension allows the
vkGetPhysicalDeviceSurfaceFormatsKHR
and
vkGetPhysicalDeviceSurfacePresentModesKHR
functions to accept
VK_NULL_HANDLE
as their
surface
parameter, allowing potential
surface formats, color spaces and present modes to be queried without
providing a surface.
Identically,
vkGetPhysicalDeviceSurfaceFormats2KHR
vkGetPhysicalDeviceSurfacePresentModes2EXT
, and
vkGetPhysicalDeviceSurfaceCapabilities2KHR
would accept
VK_NULL_HANDLE
in
VkPhysicalDeviceSurfaceInfo2KHR
::
surface
This can only be supported on platforms where the results of these queries
are surface-agnostic and a single presentation engine is the implicit target
of all present operations
New Enum Constants
VK_GOOGLE_SURFACELESS_QUERY_EXTENSION_NAME
VK_GOOGLE_SURFACELESS_QUERY_SPEC_VERSION
Version History
Revision 1, 2021-12-14 (Shahbaz Youssefi)
Internal revisions
Revision 2, 2022-08-03 (Shahbaz Youssefi)
Precisions to which parts of the query responses are defined when
surfaceless
VK_GOOGLE_user_type
Name String
VK_GOOGLE_user_type
Extension Type
Device extension
Registered Extension Number
290
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_GOOGLE_user_type
Contact
Kaye Mason
chaleur
Other Extension Metadata
Last Modified Date
2019-07-09
IP Status
No known IP claims.
Contributors
Kaye Mason, Google
Hai Nguyen, Google
Description
The
VK_GOOGLE_user_type
extension allows use of the
SPV_GOOGLE_user_type
extension in SPIR-V shader modules.
New Enum Constants
VK_GOOGLE_USER_TYPE_EXTENSION_NAME
VK_GOOGLE_USER_TYPE_SPEC_VERSION
Version History
Revision 1, 2019-09-07 (Kaye Mason)
Initial draft
VK_HUAWEI_cluster_culling_shader
Name String
VK_HUAWEI_cluster_culling_shader
Extension Type
Device extension
Registered Extension Number
405
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_HUAWEI_cluster_culling_shader
Contact
Yuchang Wang
richard_Wang2
Extension Proposal
VK_HUAWEI_cluster_culling_shader
Other Extension Metadata
Last Modified Date
2023-08-16
Interactions and External Dependencies
This extension provides API support for
GL_HUAWEI_cluster_culling_shader
Contributors
Yuchang Wang, Huawei
Juntao Li, Huawei
Pan Gao, Huawei
Jie Cao, Huawei
Yunjin Zhang, Huawei
Shujie Zhou, Huawei
Chaojun Wang, Huawei
Jiajun Hu, Huawei
Cong Zhang, Huawei
Description
Cluster Culling Shaders (CCS) are similar to the existing compute shaders.
Their main purpose is to provide an execution environment in order to
perform coarse-level geometry culling and LOD selection more efficiently on
the GPU.
The traditional 2-pass GPU culling solution using a compute shader sometimes
needs a pipeline barrier between compute and graphics pipeline to optimize
performance.
An additional compaction process may also be required.
This extension addresses these shortcomings, allowing compute shaders to
directly emit visible clusters to the following graphics pipeline.
A set of new built-in output variables are used to express a visible
cluster, including per-cluster shading rate.
In addition, a new built-in function is used to emit these variables from
CCS to the IA stage.
The IA stage can use these variables to fetch vertices of a visible cluster
and drive vertex shaders to shading these vertices.
Note that CCS do not work with geometry or tessellation shaders, but both IA
and vertex shaders are preserved.
Vertex shaders are still used for vertex position shading, instead of
directly outputting transformed vertices from the compute shader.
This makes CCS more suitable for mobile GPUs.
New Commands
vkCmdDrawClusterHUAWEI
vkCmdDrawClusterIndirectHUAWEI
New Structures
Extending
VkPhysicalDeviceClusterCullingShaderFeaturesHUAWEI
VkPhysicalDeviceClusterCullingShaderVrsFeaturesHUAWEI
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceClusterCullingShaderFeaturesHUAWEI
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceClusterCullingShaderPropertiesHUAWEI
New Enum Constants
VK_HUAWEI_CLUSTER_CULLING_SHADER_EXTENSION_NAME
VK_HUAWEI_CLUSTER_CULLING_SHADER_SPEC_VERSION
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_CLUSTER_CULLING_SHADER_BIT_HUAWEI
Extending
VkQueryPipelineStatisticFlagBits
VK_QUERY_PIPELINE_STATISTIC_CLUSTER_CULLING_SHADER_INVOCATIONS_BIT_HUAWEI
Extending
VkShaderStageFlagBits
VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_FEATURES_HUAWEI
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_PROPERTIES_HUAWEI
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_VRS_FEATURES_HUAWEI
New Built-In Variables
IndexCountHUAWEI
VertexCountHUAWEI
InstanceCountHUAWEI
FirstIndexHUAWEI
FirstVertexHUAWEI
VertexOffsetHUAWEI
FirstInstanceHUAWEI
ClusterIDHUAWEI
ClusterShadingRateHUAWEI
New SPIR-V Capability
ClusterCullingShadingHUAWEI
Sample Code
Example of cluster culling in a GLSL shader
#extension GL_HUAWEI_cluster_culling_shader: enable

#define GPU_WARP_SIZE 32
#define GPU_GROUP_SIZE GPU_WARP_SIZE

#define GPU_CLUSTER_PER_INVOCATION 1
#define GPU_CLUSTER_PER_WORKGROUP (GPU_GROUP_SIZE * GPU_CLUSTER_PER_INVOCATION)

// Number of threads per workgroup
// - 1D only
// - warpsize = 32
layout(local_size_x=GPU_GROUP_SIZE, local_size_y=1, local_size_z=1) in;

#define GPU_DRAW_BUFFER_BINDING 0
#define GPU_INSTANCE_DESCRIPTOR_BINDING 1

struct BoundingSphere
vec3 center;
float radius;
};

struct InstanceData
mat4 mvp_matrix; // mvp matrix.
vec4 frustum_planes[6]; // six frustum planes
mat4 model_matrix_transpose_inverse; // inverse transpose of model matrix.
vec3 view_origin; // view original
};

struct InstanceDescriptor
uint begin;
uint end;
uint cluster_count;
uint debug;
BoundingSphere sphere;
InstanceData instance_data;
};

struct DrawElementsCommand{
uint indexcount;
uint instanceCount;
uint firstIndex;
int vertexoffset;
uint firstInstance;
uint cluster_id;
};

// indexed mode
out gl_PerClusterHUAWEI{
uint gl_IndexCountHUAWEI;
uint gl_InstanceCountHUAWEI;
uint gl_FirstIndexHUAWEI;
int gl_VertexOffsetHUAWEI;
uint gl_FirstInstanceHUAWEI;
uint gl_ClusterIDHUAWEI;
uint gl_ClusterShadingRateHUAWEI;
};

layout(binding = GPU_DRAW_BUFFER_BINDING, std430) buffer draw_indirect_ssbo
DrawElementsCommand draw_commands[];
};

layout(binding = GPU_INSTANCE_DESCRIPTOR_BINDING, std430) buffer instance_descriptor_ssbo
InstanceDescriptor instance_descriptors[];
};

float Distance(uint instance_id)
vec3 v = normalize(instance_descriptor[instance_id].sphere.center -
instance_descriptor[instance_id].instance_data.view_origin);
float dist = sqrt(dot(v,v));

return dist;

bool isSphereOutsideFrustum( vec3 sphere_center, float sphere_radius )
bool isInside = false;

for(int i = 0; i < 6; i++)
isInside = isInside ||
(dot(instance_descriptors[instance_id].instance_data.frustum_planes[i].xyz,
sphere_center) + instance_descriptors[instance_id].instance_data.frustum_planes[i].w <
sphere_radius);
return isInside;

void main()
// get instance description
instance_id = gl_GlobalInvocationID.x;
InstanceDescriptor inst_desc = instance_descriptors[instance_id];

//instance based culling
bool render = !isSphereOutsideFrustum(inst_desc.sphere.center, inst_desc.sphere.radius);

if (render)
// calculate distance
float distance = Distance(instance_id);

// update shading rate built-in variable
if(distance > 0.7)
gl_ClusterShadingRateHUAWEI =
gl_ShadingRateFlag4VerticalPixelsEXT | gl_ShadingRateFlag4HorizontalPixelsEXT;
else if(distance > 0.3)
gl_ClusterShadingRateHUAWEI =
gl_ShadingRateFlag2VerticalPixelsEXT | gl_ShadingRateFlag2HorizontalPixelsEXT;
else
gl_ClusterShadingRateHUAWEI = 0;

// this is a visible cluster, update built-in output variable.
// in case of indexed mode:
gl_IndexCountHUAWEI = draw_commands[cluster_id].indexcount;
gl_InstanceCountHUAWEI = draw_commands[cluster_id].instanceCount;
gl_FirstIndexHUAWEI = draw_commands[cluster_id].firstIndex;
gl_VertexOffsetHUAWEI = draw_commands[cluster_id].vertexoffset;
gl_FirstInstanceHUAWEI = draw_commands[cluster_id].firstInstance;
gl_ClusterIDHUAWEI = draw_commands[cluster_id].cluster_id;

// emit built-in output variables as a drawing command to subsequent
// rendering pipeline.
dispatchClusterHUAWEI();
Example of graphics pipeline creation with cluster culling shader
// create a cluster culling shader stage info structure.
VkPipelineShaderStageCreateInfo ccsStageInfo{};
ccsStageInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO;
ccsStageInfo.stage = VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI;
ccsStageInfo.module = clustercullingshaderModule;
ccsStageInfo.pName = "main";

// pipeline shader stage creation
VkPipelineShaderStageCreateInfo shaderStages[] = { ccsStageInfo, vertexShaderStageInfo, fragmentShaderStageInfo };

// create graphics pipeline
VkGraphicsPipelineCreateInfo pipelineInfo{};
pipelineInfo.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
pipelineInfo.stageCount = 3;
pipelineInfo.pStage = shaderStages;
pipelineInfo.pVertexInputState = &vertexInputInfo;
// ...
VkPipeline graphicsPipeline;
VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineInfo, nullptr, &graphicsPipeline);
Example of launching the execution of cluster culling shader
vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, graphicsPipeline);
vkCmdDrawClusterHUAWEI(commandBuffer, groupCountX, 1, 1);
vkCmdEndRenderPass(commandBuffer);
Version History
Revision 1, 2022-11-18 (YuChang Wang)
Internal revisions
Revision 2, 2023-04-02 (Jon Leech)
Grammar edits.
Revision 3, 2023-08-21 (YuChang Wang)
Add per-cluster shading rate.
VK_HUAWEI_hdr_vivid
Name String
VK_HUAWEI_hdr_vivid
Extension Type
Device extension
Registered Extension Number
591
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_swapchain
and
VK_EXT_hdr_metadata
Contact
Zehui Lin
bactlink
Other Extension Metadata
Last Modified Date
2024-10-08
IP Status
No known IP claims.
Contributors
Juntao Li, Huawei
Pan Gao, Huawei
Xiufeng Zhang, Huawei
Zehui Lin, Huawei
Description
This extension allows applications to assign HDR Vivid (T/UWA 005.1-2022)
metadata to swapchains.
HDR Vivid is an HDR standard released by UWA (UHD World Association).
It defines tone mapping from the metadata to better preserve the creator’s
intentions and achieve better consistency across devices with different
display capabilities.
New Structures
Extending
VkHdrMetadataEXT
VkHdrVividDynamicMetadataHUAWEI
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceHdrVividFeaturesHUAWEI
New Enum Constants
VK_HUAWEI_HDR_VIVID_EXTENSION_NAME
VK_HUAWEI_HDR_VIVID_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_HDR_VIVID_DYNAMIC_METADATA_HUAWEI
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HDR_VIVID_FEATURES_HUAWEI
Version History
Revision 1, 2024-10-08 (Zehui Lin)
Initial version
VK_HUAWEI_invocation_mask
Name String
VK_HUAWEI_invocation_mask
Extension Type
Device extension
Registered Extension Number
371
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
Contact
Pan Gao
PanGao-h
Extension Proposal
VK_HUAWEI_invocation_mask
Other Extension Metadata
Last Modified Date
2021-05-27
Interactions and External Dependencies
This extension requires
VK_KHR_ray_tracing_pipeline
, which
allow to bind an invocation mask image before the ray tracing command
This extension requires
VK_KHR_synchronization2
, which allows
new pipeline stage for the invocation mask image
Contributors
Yunpeng Zhu
Juntao Li, Huawei
Liang Chen, Huawei
Shaozhuang Shi, Huawei
Hailong Chu, Huawei
Description
The rays to trace may be sparse in some use cases.
For example, the scene only have a few regions to reflect.
Providing an invocation mask image to the ray tracing commands could
potentially give the hardware the hint to do certain optimization without
invoking an additional pass to compact the ray buffer.
New Commands
vkCmdBindInvocationMaskHUAWEI
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceInvocationMaskFeaturesHUAWEI
New Enum Constants
VK_HUAWEI_INVOCATION_MASK_EXTENSION_NAME
VK_HUAWEI_INVOCATION_MASK_SPEC_VERSION
Extending
VkAccessFlagBits2
VK_ACCESS_2_INVOCATION_MASK_READ_BIT_HUAWEI
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_INVOCATION_MASK_BIT_HUAWEI
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_INVOCATION_MASK_BIT_HUAWEI
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INVOCATION_MASK_FEATURES_HUAWEI
Examples
RT mask is updated before each traceRay.
Step 1.
Generate InvocationMask.
//the rt mask image bind as color attachment in the fragment shader
Layout(location = 2) out vec4 outRTmask
vec4 mask = vec4(x,x,x,x);
outRTmask = mask;
Step 2.
traceRay with InvocationMask
vkCmdBindPipeline(
commandBuffers[imageIndex],
VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR, m_rtPipeline);
vkCmdBindDescriptorSets(commandBuffers[imageIndex],
VK_PIPELINE_BIND_POINT_RAY_TRACING_NV,
m_rtPipelineLayout, 0, 1, &m_rtDescriptorSet,
0, nullptr);

vkCmdBindInvocationMaskHUAWEI(
commandBuffers[imageIndex],
InvocationMaskimageView,
InvocationMaskimageLayout);
vkCmdTraceRaysKHR(commandBuffers[imageIndex],
pRaygenShaderBindingTable,
pMissShaderBindingTable,
swapChainExtent.width,
swapChainExtent.height, 1);
Version History
Revision 1, 2021-05-27 (Yunpeng Zhu)
Initial draft.
VK_HUAWEI_subpass_shading
Name String
VK_HUAWEI_subpass_shading
Extension Type
Device extension
Registered Extension Number
370
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_create_renderpass2
or
Vulkan Version 1.2
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
SPIR-V Dependencies
SPV_HUAWEI_subpass_shading
Contact
Pan Gao
PanGao-h
Other Extension Metadata
Last Modified Date
2021-06-01
Interactions and External Dependencies
This extension provides API support for
GL_HUAWEI_subpass_shading
Contributors
Hueilong Wang
Juntao Li, Huawei
Renmiao Lu, Huawei
Pan Gao, Huawei
Description
This extension allows applications to execute a subpass shading pipeline in
a subpass of a render pass in order to save memory bandwidth for algorithms
like tile-based deferred rendering and forward plus.
A subpass shading pipeline is a pipeline with the compute pipeline ability,
allowed to read values from input attachments, and only allowed to be
dispatched inside a stand-alone subpass.
Its work dimension is defined by the render pass’s render area size.
Its workgroup size (width, height) shall be a power-of-two number in width
or height, with minimum value from 8, and maximum value shall be decided
from the render pass attachments and sample counts but depends on
implementation.
The
GlobalInvocationId.xy
of a subpass shading pipeline is equal to the
FragCoord.xy
of a graphic pipeline in the same render pass subtracted
the
offset
of the
VkRenderPassBeginInfo
::
renderArea
GlobalInvocationId.z
is mapped to the Layer if
VK_EXT_shader_viewport_index_layer
is supported.
The
GlobalInvocationId.xy
is equal to the index of the local workgroup
multiplied by the size of the local workgroup plus the
LocalInvocationId
and the
offset
of the
VkRenderPassBeginInfo
::
renderArea
This extension allows a subpass’s pipeline bind point to be
VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI
New Commands
vkCmdSubpassShadingHUAWEI
vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI
New Structures
Extending
VkComputePipelineCreateInfo
VkSubpassShadingPipelineCreateInfoHUAWEI
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSubpassShadingFeaturesHUAWEI
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceSubpassShadingPropertiesHUAWEI
New Enum Constants
VK_HUAWEI_SUBPASS_SHADING_EXTENSION_NAME
VK_HUAWEI_SUBPASS_SHADING_SPEC_VERSION
Extending
VkPipelineBindPoint
VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI
VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI
Extending
VkShaderStageFlagBits
VK_SHADER_STAGE_SUBPASS_SHADING_BIT_HUAWEI
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_FEATURES_HUAWEI
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_PROPERTIES_HUAWEI
VK_STRUCTURE_TYPE_SUBPASS_SHADING_PIPELINE_CREATE_INFO_HUAWEI
Sample Code
Example of subpass shading in a GLSL shader
#extension GL_HUAWEI_subpass_shading: enable
#extension GL_KHR_shader_subgroup_arithmetic: enable

layout(constant_id = 0) const uint tileWidth = 8;
layout(constant_id = 1) const uint tileHeight = 8;
layout(local_size_x_id = 0, local_size_y_id = 1, local_size_z = 1) in;
layout(set=0, binding=0, input_attachment_index=0) uniform subpassInput depth;

void main()
float d = subpassLoad(depth).x;
float minD = subgroupMin(d);
float maxD = subgroupMax(d);
Example of subpass shading dispatching in a subpass
vkCmdNextSubpass(commandBuffer, VK_SUBPASS_CONTENTS_INLINE);
vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipeline);
vkCmdBindDescriptorSets(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipelineLayout,
firstSet, descriptorSetCount, pDescriptorSets, dynamicOffsetCount, pDynamicOffsets);
vkCmdSubpassShadingHUAWEI(commandBuffer)
vkCmdEndRenderPass(commandBuffer);
Example of subpass shading render pass creation
VkAttachmentDescription2 attachments[] = {
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
},
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
},
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
},
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
0, VK_FORMAT_D24_UNORM_S8_UINT, VK_SAMPLE_COUNT_1_BIT,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL
},
VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_STORE,
VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
};

VkAttachmentReference2 gBufferAttachmentReferences[] = {
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 0, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 1, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 2, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT }
};
VkAttachmentReference2 gBufferDepthStencilAttachmentReferences =
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT };
VkAttachmentReference2 depthInputAttachmentReferences[] = {
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT };
};
VkAttachmentReference2 preserveAttachmentReferences[] = {
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 0, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 1, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 2, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT },
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 3, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_DEPTH_BIT|VK_IMAGE_ASPECT_STENCIL_BIT }
}; // G buffer including depth/stencil
VkAttachmentReference2 colorAttachmentReferences[] = {
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 4, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT }
};
VkAttachmentReference2 resolveAttachmentReference =
{ VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2, NULL, 4, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_ASPECT_COLOR_BIT };

VkSubpassDescription2 subpasses[] = {
VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_GRAPHICS, 0,
0, NULL, // input
sizeof(gBufferAttachmentReferences)/sizeof(gBufferAttachmentReferences[0]), gBufferAttachmentReferences, // color
NULL, &gBufferDepthStencilAttachmentReferences, // resolve & DS
0, NULL
},
VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI , 0,
sizeof(depthInputAttachmentReferences)/sizeof(depthInputAttachmentReferences[0]), depthInputAttachmentReferences, // input
0, NULL, // color
NULL, NULL, // resolve & DS
sizeof(preserveAttachmentReferences)/sizeof(preserveAttachmentReferences[0]), preserveAttachmentReferences,
},
VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2, NULL, 0, VK_PIPELINE_BIND_POINT_GRAPHICS, 0,
sizeof(gBufferAttachmentReferences)/sizeof(gBufferAttachmentReferences[0]), gBufferAttachmentReferences, // input
sizeof(colorAttachmentReferences)/sizeof(colorAttachmentReferences[0]), colorAttachmentReferences, // color
&resolveAttachmentReference, &gBufferDepthStencilAttachmentReferences, // resolve & DS
0, NULL
},
};

VkMemoryBarrier2KHR fragmentToSubpassShading = {
VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR, NULL,
VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR, VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT|VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT,
VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI, VK_ACCESS_INPUT_ATTACHMENT_READ_BIT
};

VkMemoryBarrier2KHR subpassShadingToFragment = {
VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR, NULL,
VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI, VK_ACCESS_SHADER_WRITE_BIT,
VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR, VK_ACCESS_SHADER_READ_BIT
};

VkSubpassDependency2 dependencies[] = {
VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2, &fragmentToSubpassShading,
0, 1,
0, 0, 0, 0,
0, 0
},
VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2, &subpassShadingToFragment,
1, 2,
0, 0, 0, 0,
0, 0
},
};

VkRenderPassCreateInfo2 renderPassCreateInfo = {
VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2, NULL, 0,
sizeof(attachments)/sizeof(attachments[0]), attachments,
sizeof(subpasses)/sizeof(subpasses[0]), subpasses,
sizeof(dependencies)/sizeof(dependencies[0]), dependencies,
0, NULL
};
VKRenderPass renderPass;
vkCreateRenderPass2(device, &renderPassCreateInfo, NULL, &renderPass);
Example of subpass shading pipeline creation
VkExtent2D maxWorkgroupSize;

VkSpecializationMapEntry subpassShadingConstantMapEntries[] = {
{ 0, 0 * sizeof(uint32_t), sizeof(uint32_t) },
{ 1, 1 * sizeof(uint32_t), sizeof(uint32_t) }
};

VkSpecializationInfo subpassShadingConstants = {
2, subpassShadingConstantMapEntries,
sizeof(VkExtent2D), &maxWorkgroupSize
};

VkSubpassShadingPipelineCreateInfoHUAWEI subpassShadingPipelineCreateInfo {
VK_STRUCTURE_TYPE_SUBPASSS_SHADING_PIPELINE_CREATE_INFO_HUAWEI, NULL,
renderPass, 1
};

VkPipelineShaderStageCreateInfo subpassShadingPipelineStageCreateInfo {
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO, NULL,
0, VK_SHADER_STAGE_SUBPASS_SHADING_BIT_HUAWEI,
shaderModule, "main",
&subpassShadingConstants
};

VkComputePipelineCreateInfo subpassShadingComputePipelineCreateInfo = {
VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO, &subpassShadingPipelineCreateInfo,
0, &subpassShadingPipelineStageCreateInfo,
pipelineLayout, basePipelineHandle, basePipelineIndex
};

VKPipeline pipeline;

vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI(device, renderPass, &maxWorkgroupSize);
vkCreateComputePipelines(device, pipelineCache, 1, &subpassShadingComputePipelineCreateInfo, NULL, &pipeline);
Version History
Revision 3, 2023-06-19 (Pan Gao)
Rename
VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI
to
VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI
to better aligned with
naming of other pipeline stages
Revision 2, 2021-06-28 (Hueilong Wang)
Change vkGetSubpassShadingMaxWorkgroupSizeHUAWEI to
vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI to resolve issue
pub1564
Revision 1, 2020-12-15 (Hueilong Wang)
Initial draft.
VK_IMG_filter_cubic
Name String
VK_IMG_filter_cubic
Extension Type
Device extension
Registered Extension Number
16
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Tobias Hector
tobski
Other Extension Metadata
Last Modified Date
2016-02-23
Contributors
Tobias Hector, Imagination Technologies
Description
VK_IMG_filter_cubic
adds an additional, high quality cubic filtering mode
to Vulkan, using a Catmull-Rom bicubic filter.
Performing this kind of filtering can be done in a shader by using 16
samples and a number of instructions, but this can be inefficient.
The cubic filter mode exposes an optimized high quality texture sampling
using fixed texture sampling functionality.
New Enum Constants
VK_IMG_FILTER_CUBIC_EXTENSION_NAME
VK_IMG_FILTER_CUBIC_SPEC_VERSION
Extending
VkFilter
VK_FILTER_CUBIC_IMG
Extending
VkFormatFeatureFlagBits
VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_IMG
Example
Creating a sampler with the new filter for both magnification and
minification
VkSamplerCreateInfo createInfo =
.sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
// Other members set to application-desired values
};

createInfo.magFilter = VK_FILTER_CUBIC_IMG;
createInfo.minFilter = VK_FILTER_CUBIC_IMG;

VkSampler sampler;
VkResult result = vkCreateSampler(
device,
&createInfo,
&sampler);
Version History
Revision 1, 2016-02-23 (Tobias Hector)
Initial version
VK_IMG_relaxed_line_rasterization
Name String
VK_IMG_relaxed_line_rasterization
Extension Type
Device extension
Registered Extension Number
111
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
OpenGL / ES support
Contact
James Fitzpatrick
jamesfitzpatrick
Other Extension Metadata
Last Modified Date
2023-10-22
IP Status
No known IP claims.
Contributors
James Fitzpatrick, Imagination
Andrew Garrard, Imagination
Alex Walters, Imagination
Description
OpenGL specifies that implementations should rasterize lines using the
diamond exit rule (a slightly modified version of Bresenham’s algorithm).
To implement OpenGL some implementations have a device-level compatibility
mode to rasterize lines according to the OpenGL specification.
This extension allows OpenGL emulation layers to enable the OpenGL
compatible line rasterization mode of such implementations.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRelaxedLineRasterizationFeaturesIMG
New Enum Constants
VK_IMG_RELAXED_LINE_RASTERIZATION_EXTENSION_NAME
VK_IMG_RELAXED_LINE_RASTERIZATION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RELAXED_LINE_RASTERIZATION_FEATURES_IMG
Issues
None.
Version History
Revision 1, 2023-10-22 (James Fitzpatrick)
Initial version
VK_INTEL_performance_query
Name String
VK_INTEL_performance_query
Extension Type
Device extension
Registered Extension Number
211
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Special Use
Developer tools
Contact
Lionel Landwerlin
llandwerlin
Other Extension Metadata
Last Modified Date
2018-05-16
IP Status
No known IP claims.
Contributors
Lionel Landwerlin, Intel
Piotr Maciejewski, Intel
Description
This extension allows an application to capture performance data to be
interpreted by an external application or library.
Such a library is available at :
Performance analysis tools such as
Graphics
Performance Analyzers
make use of this extension and the metrics-discovery
library to present the data in a human readable way.
New Object Types
VkPerformanceConfigurationINTEL
New Commands
vkAcquirePerformanceConfigurationINTEL
vkCmdSetPerformanceMarkerINTEL
vkCmdSetPerformanceOverrideINTEL
vkCmdSetPerformanceStreamMarkerINTEL
vkGetPerformanceParameterINTEL
vkInitializePerformanceApiINTEL
vkQueueSetPerformanceConfigurationINTEL
vkReleasePerformanceConfigurationINTEL
vkUninitializePerformanceApiINTEL
New Structures
VkInitializePerformanceApiInfoINTEL
VkPerformanceConfigurationAcquireInfoINTEL
VkPerformanceMarkerInfoINTEL
VkPerformanceOverrideInfoINTEL
VkPerformanceStreamMarkerInfoINTEL
VkPerformanceValueINTEL
Extending
VkQueryPoolCreateInfo
VkQueryPoolCreateInfoINTEL
VkQueryPoolPerformanceQueryCreateInfoINTEL
New Unions
VkPerformanceValueDataINTEL
New Enums
VkPerformanceConfigurationTypeINTEL
VkPerformanceOverrideTypeINTEL
VkPerformanceParameterTypeINTEL
VkPerformanceValueTypeINTEL
VkQueryPoolSamplingModeINTEL
New Enum Constants
VK_INTEL_PERFORMANCE_QUERY_EXTENSION_NAME
VK_INTEL_PERFORMANCE_QUERY_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_PERFORMANCE_CONFIGURATION_INTEL
Extending
VkQueryType
VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL
Extending
VkStructureType
VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL
VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL
VK_STRUCTURE_TYPE_PERFORMANCE_MARKER_INFO_INTEL
VK_STRUCTURE_TYPE_PERFORMANCE_OVERRIDE_INFO_INTEL
VK_STRUCTURE_TYPE_PERFORMANCE_STREAM_MARKER_INFO_INTEL
VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL
VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_QUERY_CREATE_INFO_INTEL
Example Code
// A previously created device
VkDevice device;

// A queue derived from the device
VkQueue queue;

VkInitializePerformanceApiInfoINTEL performanceApiInfoIntel = {
VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL,
NULL,
NULL
};

vkInitializePerformanceApiINTEL(
device,
&performanceApiInfoIntel);

VkQueryPoolPerformanceQueryCreateInfoINTEL queryPoolIntel = {
VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL,
NULL,
VK_QUERY_POOL_SAMPLING_MODE_MANUAL_INTEL,
};

VkQueryPoolCreateInfo queryPoolCreateInfo = {
VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
&queryPoolIntel,
0,
VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL,
1,
};

VkQueryPool queryPool;

VkResult result = vkCreateQueryPool(
device,
&queryPoolCreateInfo,
NULL,
&queryPool);

assert(VK_SUCCESS == result);

// A command buffer we want to record counters on
VkCommandBuffer commandBuffer;

VkCommandBufferBeginInfo commandBufferBeginInfo = {
VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
NULL,
VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT,
NULL
};

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
// ...

vkCmdEndQuery(
commandBuffer,
queryPool,
0);

result = vkEndCommandBuffer(commandBuffer);

assert(VK_SUCCESS == result);

VkPerformanceConfigurationAcquireInfoINTEL performanceConfigurationAcquireInfo = {
VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL,
NULL,
VK_PERFORMANCE_CONFIGURATION_TYPE_COMMAND_QUEUE_METRICS_DISCOVERY_ACTIVATED_INTEL
};

VkPerformanceConfigurationINTEL performanceConfigurationIntel;

result = vkAcquirePerformanceConfigurationINTEL(
device,
&performanceConfigurationAcquireInfo,
&performanceConfigurationIntel);

vkQueueSetPerformanceConfigurationINTEL(queue, performanceConfigurationIntel);

assert(VK_SUCCESS == result);

// Submit the command buffer and wait for its completion
// ...

result = vkReleasePerformanceConfigurationINTEL(
device,
performanceConfigurationIntel);

assert(VK_SUCCESS == result);

// Get the report size from metrics-discovery's QueryReportSize

result = vkGetQueryPoolResults(
device,
queryPool,
0, 1, QueryReportSize,
data, QueryReportSize, 0);

assert(VK_SUCCESS == result);

// The data can then be passed back to metrics-discovery from which
// human readable values can be queried.
Version History
Revision 2, 2020-03-06 (Lionel Landwerlin)
Rename VkQueryPoolCreateInfoINTEL in
VkQueryPoolPerformanceQueryCreateInfoINTEL
Revision 1, 2018-05-16 (Lionel Landwerlin)
Initial revision
VK_INTEL_shader_integer_functions2
Name String
VK_INTEL_shader_integer_functions2
Extension Type
Device extension
Registered Extension Number
210
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_INTEL_shader_integer_functions2
Contact
Ian Romanick
ianromanick
Other Extension Metadata
Last Modified Date
2019-04-30
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_INTEL_shader_integer_functions2
Contributors
Ian Romanick, Intel
Ben Ashbaugh, Intel
Description
This extension adds support for several new integer instructions in SPIR-V
for use in graphics shaders.
Many of these instructions have pre-existing counterparts in the Kernel
environment.
The added integer functions are defined by the
SPV_INTEL_shader_integer_functions2
SPIR-V extension and can be used with the
GL_INTEL_shader_integer_functions2
GLSL extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderIntegerFunctions2FeaturesINTEL
New Enum Constants
VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_EXTENSION_NAME
VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_FUNCTIONS_2_FEATURES_INTEL
New SPIR-V Capabilities
IntegerFunctions2INTEL
Version History
Revision 1, 2019-04-30 (Ian Romanick)
Initial draft
VK_LUNARG_direct_driver_loading
Name String
VK_LUNARG_direct_driver_loading
Extension Type
Instance extension
Registered Extension Number
460
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Charles Giessen
charles-lunarg
Extension Proposal
VK_LUNARG_direct_driver_loading
Other Extension Metadata
Last Modified Date
2022-11-29
Contributors
Charles Giessen, LunarG
Description
This extension provides a mechanism for applications to add drivers to the
implementation.
This allows drivers to be included with an application without requiring
installation and is capable of being used in any execution environment, such
as a process running with elevated privileges.
New Structures
VkDirectDriverLoadingInfoLUNARG
Extending
VkInstanceCreateInfo
VkDirectDriverLoadingListLUNARG
New Function Pointers
PFN_vkGetInstanceProcAddrLUNARG
New Enums
VkDirectDriverLoadingModeLUNARG
New Bitmasks
VkDirectDriverLoadingFlagsLUNARG
New Enum Constants
VK_LUNARG_DIRECT_DRIVER_LOADING_EXTENSION_NAME
VK_LUNARG_DIRECT_DRIVER_LOADING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_INFO_LUNARG
VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_LIST_LUNARG
Version History
Revision 1, 2022-11-29 (Charles Giessen)
Initial version
VK_MESA_image_alignment_control
Name String
VK_MESA_image_alignment_control
Extension Type
Device extension
Registered Extension Number
576
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
D3D support
Contact
Hans-Kristian Arntzen
HansKristian-Work
Other Extension Metadata
Last Modified Date
2024-05-03
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
Description
This extension allows applications to request a narrower alignment for
images than an implementation would otherwise require.
Some implementations internally support multiple image layouts in
VK_IMAGE_TILING_OPTIMAL
, each with different alignment requirements
and performance trade-offs.
In some API layering use cases such as D3D12, it is beneficial to be able to
control the alignment, since certain alignments for placed resources are
guaranteed to be supported, and emulating that expectation requires
unnecessary padding of allocations.
VkImageAlignmentControlCreateInfoMESA
can
be chained to
VkImageCreateInfo
, requesting that the alignment is no more than the
provided alignment.
If the requested alignment is not supported for a given
VkImageCreateInfo
, a larger alignment
may
be returned.
While something similar could be achieved with
VK_EXT_image_drm_format_modifier
in theory, this is not the
intended way to use that extension.
Format modifiers are generally used for externally shareable images, and
would not be platform portable.
It is also a cumbersome API to use just to lower the alignment.
New Structures
Extending
VkImageCreateInfo
VkImageAlignmentControlCreateInfoMESA
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageAlignmentControlFeaturesMESA
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceImageAlignmentControlPropertiesMESA
New Enum Constants
VK_MESA_IMAGE_ALIGNMENT_CONTROL_EXTENSION_NAME
VK_MESA_IMAGE_ALIGNMENT_CONTROL_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_ALIGNMENT_CONTROL_CREATE_INFO_MESA
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ALIGNMENT_CONTROL_FEATURES_MESA
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ALIGNMENT_CONTROL_PROPERTIES_MESA
Version History
Revision 1, 2024-04-05 (Hans-Kristian Arntzen)
Initial specification
VK_MSFT_layered_driver
Name String
VK_MSFT_layered_driver
Extension Type
Device extension
Registered Extension Number
531
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Jesse Natalie
jenatali
Extension Proposal
VK_MSFT_layered_driver
Other Extension Metadata
Last Modified Date
2023-06-21
IP Status
No known IP claims.
Contributors
Jesse Natalie, Microsoft
Description
This extension adds new physical device properties to allow applications and
the Vulkan ICD loader to understand when a physical device is implemented as
a layered driver on top of another underlying API.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceLayeredDriverPropertiesMSFT
New Enums
VkLayeredDriverUnderlyingApiMSFT
New Enum Constants
VK_MSFT_LAYERED_DRIVER_EXTENSION_NAME
VK_MSFT_LAYERED_DRIVER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LAYERED_DRIVER_PROPERTIES_MSFT
Examples
None.
Version History
Revision 1, 2023-06-21 (Jesse Natalie)
Initial revision
VK_NN_vi_surface
Name String
VK_NN_vi_surface
Extension Type
Instance extension
Registered Extension Number
63
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Mathias Heyer
mheyer
Other Extension Metadata
Last Modified Date
2016-12-02
IP Status
No known IP claims.
Contributors
Mathias Heyer, NVIDIA
Michael Chock, NVIDIA
Yasuhiro Yoshioka, Nintendo
Daniel Koch, NVIDIA
Description
The
VK_NN_vi_surface
extension is an instance extension.
It provides a mechanism to create a
VkSurfaceKHR
object (defined by
the
VK_KHR_surface
extension) associated with an
nn
::
vi
::
Layer
New Commands
vkCreateViSurfaceNN
New Structures
VkViSurfaceCreateInfoNN
New Bitmasks
VkViSurfaceCreateFlagsNN
New Enum Constants
VK_NN_VI_SURFACE_EXTENSION_NAME
VK_NN_VI_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN
Issues
1) Does VI need a way to query for compatibility between a particular
physical device (and queue family?) and a specific VI display?
RESOLVED
: No.
It is currently always assumed that the device and display will always be
compatible.
2)
VkViSurfaceCreateInfoNN
::
window
is intended to store an
nn
::
vi
::
NativeWindowHandle
, but its declared type is a bare
void*
to store the window handle.
Why the discrepancy?
RESOLVED
: It is for C compatibility.
The definition for the VI native window handle type is defined inside the
nn
::
vi
C++ namespace.
This prevents its use in C source files.
nn
::
vi
::
NativeWindowHandle
is always defined to be
void*
, so this extension uses
void*
to match.
Version History
Revision 1, 2016-12-2 (Michael Chock)
Initial draft.
VK_NV_acquire_winrt_display
Name String
VK_NV_acquire_winrt_display
Extension Type
Device extension
Registered Extension Number
346
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_direct_mode_display
Contact
Jeff Juliano
jjuliano
Other Extension Metadata
Last Modified Date
2020-09-29
IP Status
No known IP claims.
Contributors
Jeff Juliano, NVIDIA
Description
This extension allows an application to take exclusive control of a display
on Windows 10 provided that the display is not already controlled by a
compositor.
Examples of compositors include the Windows desktop compositor, other
applications using this Vulkan extension, and applications that
“Acquire”
“DisplayTarget”
using a
“WinRT”
command such as
“winrt::Windows::Devices::Display::Core::DisplayManager.TryAcquireTarget()”
When control is acquired the application has exclusive access to the display
until control is released or the application terminates.
An application’s attempt to acquire is denied if a different application has
already acquired the display.
New Commands
vkAcquireWinrtDisplayNV
vkGetWinrtDisplayNV
New Enum Constants
VK_NV_ACQUIRE_WINRT_DISPLAY_EXTENSION_NAME
VK_NV_ACQUIRE_WINRT_DISPLAY_SPEC_VERSION
Issues
1) What should the platform substring be for this extension:
RESOLVED
: The platform substring is “Winrt”.
The substring “Winrt” matches the fact that the OS API exposing the
acquire and release functionality is called “WinRT”.
The substring “Win32” is wrong because the related “WinRT” API is
explicitly
not
a “Win32” API.
“WinRT” is a competing API family to the “Win32” API family.
The substring “Windows” is suboptimal because there could be more than one
relevant API on the Windows platform.
There is preference to use the more-specific substring “Winrt”.
2) Should
vkAcquireWinrtDisplayNV
take a winRT DisplayTarget, or a
Vulkan display handle as input?
RESOLVED
: A Vulkan display handle.
This matches the design of
vkAcquireXlibDisplayEXT
3) Should the acquire command be platform-independent named
“vkAcquireDisplayNV”, or platform-specific named
“vkAcquireWinrtDisplayNV”?
RESOLVED
: Add a platform-specific command.
The inputs to the Acquire command are all Vulkan types.
None are WinRT types.
This opens the possibility of the winrt extension defining a
platform-independent acquire command.
The X11 acquire command does need to accept a platform-specific parameter.
This could be handled by adding to a platform-independent acquire command a
params structure to which platform-dependent types can be chained by
pNext
pointer.
The prevailing opinion is that it would be odd to create a second
platform-independent function that is used on the Windows 10 platform, but
that is not used for the X11 platform.
Since a Windows 10 platform-specific command is needed anyway for converting
between vkDisplayKHR and platform-native handles, opinion was to create a
platform-specific acquire function.
4) Should the
vkGetWinrtDisplayNV
parameter identifying a display be
named “deviceRelativeId” or “adapterRelativeId”?
RESOLVED
: The WinRT name is “AdapterRelativeId”.
The name “adapter” is the Windows analog to a Vulkan “physical device”.
Vulkan already has precedent to use the name
deviceLUID
for the
concept that Windows APIs call “AdapterLuid”.
Keeping form with this precedent, the name “deviceRelativeId” is chosen.
5) Does
vkAcquireWinrtDisplayNV
cause the Windows desktop compositor
to release a display?
RESOLVED
: No.
vkAcquireWinrtDisplayNV
does not itself cause the Windows desktop
compositor to release a display.
This action must be performed outside of Vulkan.
Beginning with Windows 10 version 2004 it is possible to cause the Windows
desktop compositor to release a display by using the “Advanced display
settings” sub-page of the “Display settings” control panel.
See
6) Where can one find additional information about custom compositors for
Windows 10?
RESOLVED
: Relevant references are as follows.
According to Microsoft’s documentation on
"building
a custom compositor"
, the ability to write a custom compositor is not a
replacement for a fullscreen desktop window.
The feature is for writing compositor apps that drive specialized hardware.
Only certain editions of Windows 10 support custom compositors,
"documented
here"
The product type can be queried from Windows 10.
See
Version History
Revision 1, 2020-09-29 (Jeff Juliano)
Initial draft
VK_NV_clip_space_w_scaling
Name String
VK_NV_clip_space_w_scaling
Extension Type
Device extension
Registered Extension Number
88
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Eric Werness
ewerness-nv
Other Extension Metadata
Last Modified Date
2017-02-15
Contributors
Eric Werness, NVIDIA
Kedarnath Thangudu, NVIDIA
Description
Virtual Reality (VR) applications often involve a post-processing step to
apply a “barrel” distortion to the rendered image to correct the
“pincushion” distortion introduced by the optics in a VR device.
The barrel distorted image has lower resolution along the edges compared to
the center.
Since the original image is rendered at high resolution, which is uniform
across the complete image, a lot of pixels towards the edges do not make it
to the final post-processed image.
This extension provides a mechanism to render VR scenes at a non-uniform
resolution, in particular a resolution that falls linearly from the center
towards the edges.
This is achieved by scaling the
coordinate of the vertices in the
clip space before perspective divide.
The clip space
coordinate of the vertices
can
be offset as of a
function of
and
coordinates as follows:
w' = w + Ax + By
In the intended use case for viewport position scaling, an application
should use a set of four viewports, one for each of the four quadrants of a
Cartesian coordinate system.
Each viewport is set to the dimension of the image, but is scissored to the
quadrant it represents.
The application should specify
and
coefficients of the
-scaling equation above, that have the same value, but different
signs, for each of the viewports.
The signs of
and
should match the signs of
and
for the quadrant that they represent such that the value of
w'
will always be greater than or equal to the original
value for the
entire image.
Since the offset to
, (
Ax + By
), is always positive, and
increases with the absolute values of
and
, the effective
resolution will fall off linearly from the center of the image to its edges.
New Commands
vkCmdSetViewportWScalingNV
New Structures
VkViewportWScalingNV
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportWScalingStateCreateInfoNV
New Enum Constants
VK_NV_CLIP_SPACE_W_SCALING_EXTENSION_NAME
VK_NV_CLIP_SPACE_W_SCALING_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV
Issues
1) Is the pipeline structure name too long?
RESOLVED
: It fits with the naming convention.
2) Separate W scaling section or fold into coordinate transformations?
RESOLVED
: Leaving it as its own section for now.
Examples
VkViewport viewports[4];
VkRect2D scissors[4];
VkViewportWScalingNV scalings[4];

for (int i = 0; i < 4; i++) {
int x = (i & 2) ? 0 : currentWindowWidth / 2;
int y = (i & 1) ? 0 : currentWindowHeight / 2;

viewports[i].x = 0;
viewports[i].y = 0;
viewports[i].width = currentWindowWidth;
viewports[i].height = currentWindowHeight;
viewports[i].minDepth = 0.0f;
viewports[i].maxDepth = 1.0f;

scissors[i].offset.x = x;
scissors[i].offset.y = y;
scissors[i].extent.width = currentWindowWidth/2;
scissors[i].extent.height = currentWindowHeight/2;

const float factor = 0.15;
scalings[i].xcoeff = ((i & 2) ? -1.0 : 1.0) * factor;
scalings[i].ycoeff = ((i & 1) ? -1.0 : 1.0) * factor;

VkPipelineViewportWScalingStateCreateInfoNV vpWScalingStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV };

vpWScalingStateInfo.viewportWScalingEnable = VK_TRUE;
vpWScalingStateInfo.viewportCount = 4;
vpWScalingStateInfo.pViewportWScalings = &scalings[0];

VkPipelineViewportStateCreateInfo vpStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO };
vpStateInfo.viewportCount = 4;
vpStateInfo.pViewports = &viewports[0];
vpStateInfo.scissorCount = 4;
vpStateInfo.pScissors = &scissors[0];
vpStateInfo.pNext = &vpWScalingStateInfo;
Example shader to read from a w-scaled texture:
// Vertex Shader
// Draw a triangle that covers the whole screen
const vec4 positions[3] = vec4[3](vec4(-1, -1, 0, 1),
vec4( 3, -1, 0, 1),
vec4(-1, 3, 0, 1));
out vec2 uv;
void main()
vec4 pos = positions[ gl_VertexID ];
gl_Position = pos;
uv = pos.xy;

// Fragment Shader
uniform sampler2D tex;
uniform float xcoeff;
uniform float ycoeff;
out vec4 Color;
in vec2 uv;

void main()
// Handle uv as if upper right quadrant
vec2 uvabs = abs(uv);

// unscale: transform w-scaled image into an unscaled image
// scale: transform unscaled image int a w-scaled image
float unscale = 1.0 / (1 + xcoeff * uvabs.x + xcoeff * uvabs.y);
//float scale = 1.0 / (1 - xcoeff * uvabs.x - xcoeff * uvabs.y);

vec2 P = vec2(unscale * uvabs.x, unscale * uvabs.y);

// Go back to the right quadrant
P *= sign(uv);

Color = texture(tex, P * 0.5 + 0.5);
Version History
Revision 1, 2017-02-15 (Eric Werness)
Internal revisions
VK_NV_cluster_acceleration_structure
Name String
VK_NV_cluster_acceleration_structure
Extension Type
Device extension
Registered Extension Number
570
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
API Interactions
Interacts with VK_EXT_opacity_micromap
Interacts with VK_KHR_ray_tracing_pipeline
SPIR-V Dependencies
SPV_NV_cluster_acceleration_structure
Contact
Vikram Kushwaha
vkushwaha
Extension Proposal
VK_NV_cluster_acceleration_structure
Other Extension Metadata
Last Modified Date
2024-09-09
Contributors
Vikram Kushwaha, NVIDIA
Eric Werness, NVIDIA
Christoph Kubisch, NVIDIA
Jan Schmid, NVIDIA
Pyarelal Knowles, NVIDIA
Description
Acceleration structure build times can become a bottleneck in ray tracing
applications dealing with extensive dynamic geometry.
This extension addresses the problem by enabling applications to construct
bottom-level acceleration structures (BLAS) from pre-generated acceleration
structures based on clusters of triangles (CLAS), leading to significant
improvements in build times.
It provides a host-side query function to fetch the requirements and a
versatile multi-indirect call for managing cluster geometry.
This call enables applications to generate cluster geometry, construct
Cluster BLAS from CLAS lists, and move or copy CLAS and BLAS.
By sourcing inputs from device memory and processing multiple elements
simultaneously, the call reduces the host-side costs associated with
traditional acceleration structure functions.
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_cluster_acceleration_structure
New Commands
vkCmdBuildClusterAccelerationStructureIndirectNV
vkGetClusterAccelerationStructureBuildSizesNV
New Structures
VkClusterAccelerationStructureBuildClustersBottomLevelInfoNV
VkClusterAccelerationStructureBuildTriangleClusterInfoNV
VkClusterAccelerationStructureBuildTriangleClusterTemplateInfoNV
VkClusterAccelerationStructureClustersBottomLevelInputNV
VkClusterAccelerationStructureCommandsInfoNV
VkClusterAccelerationStructureGeometryIndexAndGeometryFlagsNV
VkClusterAccelerationStructureGetTemplateIndicesInfoNV
VkClusterAccelerationStructureInputInfoNV
VkClusterAccelerationStructureInstantiateClusterInfoNV
VkClusterAccelerationStructureMoveObjectsInfoNV
VkClusterAccelerationStructureMoveObjectsInputNV
VkClusterAccelerationStructureTriangleClusterInputNV
VkStridedDeviceAddressNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceClusterAccelerationStructureFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceClusterAccelerationStructurePropertiesNV
If
VK_KHR_ray_tracing_pipeline
is supported:
Extending
VkRayTracingPipelineCreateInfoKHR
VkRayTracingPipelineClusterAccelerationStructureCreateInfoNV
New Unions
VkClusterAccelerationStructureOpInputNV
New Enums
VkClusterAccelerationStructureAddressResolutionFlagBitsNV
VkClusterAccelerationStructureClusterFlagBitsNV
VkClusterAccelerationStructureGeometryFlagBitsNV
VkClusterAccelerationStructureIndexFormatFlagBitsNV
VkClusterAccelerationStructureOpModeNV
VkClusterAccelerationStructureOpTypeNV
VkClusterAccelerationStructureTypeNV
New Bitmasks
VkClusterAccelerationStructureAddressResolutionFlagsNV
VkClusterAccelerationStructureClusterFlagsNV
VkClusterAccelerationStructureGeometryFlagsNV
VkClusterAccelerationStructureIndexFormatFlagsNV
New Enum Constants
VK_NV_CLUSTER_ACCELERATION_STRUCTURE_EXTENSION_NAME
VK_NV_CLUSTER_ACCELERATION_STRUCTURE_SPEC_VERSION
Extending
VkBuildAccelerationStructureFlagBitsKHR
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_CLUSTER_OPACITY_MICROMAPS_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_CLUSTER_ACCELERATION_STRUCTURE_CLUSTERS_BOTTOM_LEVEL_INPUT_NV
VK_STRUCTURE_TYPE_CLUSTER_ACCELERATION_STRUCTURE_COMMANDS_INFO_NV
VK_STRUCTURE_TYPE_CLUSTER_ACCELERATION_STRUCTURE_INPUT_INFO_NV
VK_STRUCTURE_TYPE_CLUSTER_ACCELERATION_STRUCTURE_MOVE_OBJECTS_INPUT_NV
VK_STRUCTURE_TYPE_CLUSTER_ACCELERATION_STRUCTURE_TRIANGLE_CLUSTER_INPUT_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_ACCELERATION_STRUCTURE_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_ACCELERATION_STRUCTURE_PROPERTIES_NV
VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CLUSTER_ACCELERATION_STRUCTURE_CREATE_INFO_NV
If
VK_EXT_opacity_micromap
is supported:
Extending
VkOpacityMicromapSpecialIndexEXT
VK_OPACITY_MICROMAP_SPECIAL_INDEX_CLUSTER_GEOMETRY_DISABLE_OPACITY_MICROMAP_NV
New or Modified Built-In Variables
ClusterIDNV
New SPIR-V Capability
RayTracingClusterAccelerationStructureNV
Version History
Revision 4, 2025-07-16 (Vikram Kushwaha)
Adding build flag to enable OMM in cluster acceleration structure
Revision 3, 2025-06-18 (Vikram Kushwaha)
Adding a OpType to get template’s index data
Revision 2, 2024-09-09 (Vikram Kushwaha)
Changes to some structures causing incompatibility with Revision 1
Revision 1, 2024-08-29 (Vikram Kushwaha)
Initial draft
VK_NV_command_buffer_inheritance
Name String
VK_NV_command_buffer_inheritance
Extension Type
Device extension
Registered Extension Number
560
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Lujin Wang
lujinwangnv
Other Extension Metadata
Last Modified Date
2024-02-15
IP Status
No known IP claims.
Contributors
Piers Daniell, NVIDIA
Daniel Story, Nintendo
Description
This extension allows applications to take advantage of the graphics and
compute state that remains valid in the queue between executions of
submitted command buffers.
This works across both primary and secondary command buffers.
The state inherited includes the previously bound pipeline state, previously
bound shader objects, previously bound vertex and index buffers, previously
bound descriptor sets and push constants, and all previously set dynamic
state.
This extension relaxes the requirement that all that state needs to be bound
and set after begin command buffer and before the next draw or dispatch.
By not having to set state that has been inherited applications can save
both CPU and GPU cycles by not having to set state redundantly, and also
have improved flexibility when reusing secondary command buffers.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCommandBufferInheritanceFeaturesNV
New Enum Constants
VK_NV_COMMAND_BUFFER_INHERITANCE_EXTENSION_NAME
VK_NV_COMMAND_BUFFER_INHERITANCE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMMAND_BUFFER_INHERITANCE_FEATURES_NV
Issues
1) How can the validation layer know when state is valid at draw or dispatch
time if it is inherited at execution time?
RESOLVED
: Validation of invalid state at draw and dispatch time cannot be
done while recording those commands.
Instead the validation layer will need to keep track of any unset state when
draw and dispatch commands are recorded, but not report an error at that
time.
It should also keep track of what state is valid at the end of each recorded
command buffer.
When secondary command buffer execution is recorded the validation layer can
update its unset state tracking for that command buffer, and also for draw
and dispatch commands recorded after execution of the secondary as they will
inherit state from the executed secondary.
This can be done recursively so every recorded primary command buffer has a
final tally of any unset state used at draw and dispatch time.
Finally when the primary is submitted to the queue the validation layer will
know the previous primaries submitted to the queue and will know if there is
any unset state used and can report the error then.
Version History
Revision 1, 2024-02-15 (Lujin Wang)
Internal revisions
VK_NV_compute_occupancy_priority
Name String
VK_NV_compute_occupancy_priority
Extension Type
Device extension
Registered Extension Number
646
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Chris Lentini
clentini
Extension Proposal
VK_NV_compute_occupancy_priority
Other Extension Metadata
Last Modified Date
2025-12-01
Contributors
Chris Lentini, NVIDIA
Eric Werness, NVIDIA
Lionel Duc, NVIDIA
Peter Deayton, NVIDIA
Description
This extension provides applications with control over how their compute
workloads utilize GPU compute resources, specifically allowing
prioritization relative to other simultaneously executing workloads.
Applications can specify the priority with which compute workloads should
occupy GPU compute resources, allowing for a fine-grained distinction
between workloads that may want to execute at a background priority over a
long period of time versus workloads with harder latency requirements.
The extension introduces a new command
vkCmdSetComputeOccupancyPriorityNV
that allows applications to set the
occupancy priority for subsequent compute dispatches.
The occupancy priority affects how compute workloads utilize GPU compute
resources relative to other simultaneously executing workloads.
The occupancy priority is stateful on a command buffer.
All commands listed in the
Dispatching Commands
chapter issued
subsequent to a
vkCmdSetComputeOccupancyPriorityNV
call will be
executed with the specified priority parameters until another
vkCmdSetComputeOccupancyPriorityNV
call is made.
For convenience, three named occupancy priority values are defined:
VK_COMPUTE_OCCUPANCY_PRIORITY_LOW_NV
- a constant value that can be
used for
VkComputeOccupancyPriorityParametersNV
::
occupancyPriority
to
specify a low priority level.
VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV
- a constant value that can
be used for
VkComputeOccupancyPriorityParametersNV
::
occupancyPriority
to
specify a normal priority level.
This represents the default priority level.
VK_COMPUTE_OCCUPANCY_PRIORITY_HIGH_NV
- a constant value that can be
used for
VkComputeOccupancyPriorityParametersNV
::
occupancyPriority
to
specify a high priority level.
All command buffers (primary and secondary) start with a priority level
equal to the VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV value.
The priority state is not inherited by secondary command buffers - each
command buffer maintains its own independent priority state.
New Commands
vkCmdSetComputeOccupancyPriorityNV
New Structures
VkComputeOccupancyPriorityParametersNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceComputeOccupancyPriorityFeaturesNV
New Enum Constants
VK_COMPUTE_OCCUPANCY_PRIORITY_HIGH_NV
VK_COMPUTE_OCCUPANCY_PRIORITY_LOW_NV
VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV
VK_NV_COMPUTE_OCCUPANCY_PRIORITY_EXTENSION_NAME
VK_NV_COMPUTE_OCCUPANCY_PRIORITY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_COMPUTE_OCCUPANCY_PRIORITY_PARAMETERS_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_OCCUPANCY_PRIORITY_FEATURES_NV
The extension only allows specification of occupancy priority for compute
workloads, however, the priorities will also impact the prioritization of
compute workloads relative to simultaneously executing graphics workloads.
In such a scenario, the graphics workload may be thought of as executing at
VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV priority, and so a simultaneously
executing compute workload with VK_COMPUTE_OCCUPANCY_PRIORITY_HIGH_NV
occupancy priority will preferentially utilize available compute resources.
Workloads specified with a higher priority may begin execution after
workloads specified with a lower priority, at which point they may find GPU
compute resources already occupied.
So, while they will from that point forward preferentially occupy available
compute resources, they may not ramp up to full occupancy until the already
present lower priority work has reached a point where it can relinquish
compute resources.
Issues
None.
Version History
Revision 1, 2025-08-06 (Chris Lentini)
Initial revision
VK_NV_cooperative_matrix
Name String
VK_NV_cooperative_matrix
Extension Type
Device extension
Registered Extension Number
250
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_cooperative_matrix
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2019-02-05
Interactions and External Dependencies
This extension provides API support for
GL_NV_cooperative_matrix
Contributors
Jeff Bolz, NVIDIA
Markus Tavenrath, NVIDIA
Daniel Koch, NVIDIA
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_NV_cooperative_matrix
SPIR-V extension and can be used with the
GL_NV_cooperative_matrix
GLSL extension.
This extension includes support for enumerating the matrix types and
dimensions that are supported by the implementation.
New Commands
vkGetPhysicalDeviceCooperativeMatrixPropertiesNV
New Structures
VkCooperativeMatrixPropertiesNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCooperativeMatrixFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCooperativeMatrixPropertiesNV
New Enums
VkComponentTypeNV
VkScopeNV
New Enum Constants
VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME
VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION
Extending
VkComponentTypeKHR
VK_COMPONENT_TYPE_FLOAT16_NV
VK_COMPONENT_TYPE_FLOAT32_NV
VK_COMPONENT_TYPE_FLOAT64_NV
VK_COMPONENT_TYPE_SINT16_NV
VK_COMPONENT_TYPE_SINT32_NV
VK_COMPONENT_TYPE_SINT64_NV
VK_COMPONENT_TYPE_SINT8_NV
VK_COMPONENT_TYPE_UINT16_NV
VK_COMPONENT_TYPE_UINT32_NV
VK_COMPONENT_TYPE_UINT64_NV
VK_COMPONENT_TYPE_UINT8_NV
Extending
VkScopeKHR
VK_SCOPE_DEVICE_NV
VK_SCOPE_QUEUE_FAMILY_NV
VK_SCOPE_SUBGROUP_NV
VK_SCOPE_WORKGROUP_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV
New SPIR-V Capabilities
CooperativeMatrixNV
Issues
(1) What matrix properties will be supported in practice?
RESOLVED
: In NVIDIA’s initial implementation, we will support:
AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x16 scope =
Subgroup
AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x8 scope =
Subgroup
AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x16 scope =
Subgroup
AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x8 scope =
Subgroup
Version History
Revision 1, 2019-02-05 (Jeff Bolz)
Internal revisions
VK_NV_cooperative_matrix2
Name String
VK_NV_cooperative_matrix2
Extension Type
Device extension
Registered Extension Number
594
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_cooperative_matrix
SPIR-V Dependencies
SPV_NV_cooperative_matrix2
SPV_NV_tensor_addressing
Contact
Jeff Bolz
jeffbolznv
Extension Proposal
VK_NV_cooperative_matrix2
Other Extension Metadata
Last Modified Date
2024-08-01
Interactions and External Dependencies
This extension provides API support for
GLSL_NV_cooperative_matrix2
Contributors
Jeff Bolz, NVIDIA
Karthik Vaidyanathan, NVIDIA
Description
This extension adds several new features building on the cooperative matrix
types added in VK_KHR_cooperative_matrix.
The goal is to add and accelerate features beyond just simple GEMM kernels,
including adding support for type/use conversions, reductions, per-element
operations, and tensor addressing, and also to improve usability and
out-of-the-box performance by adding support for more flexible matrix sizes,
and workgroup scope matrices with compiler-managed staging through shared
memory.
The new functionality is defined by the
SPV_NV_tensor_addressing
and
SPV_NV_cooperative_matrix2
SPIR-V extensions and can be used with the
GLSL_NV_cooperative_matrix2
GLSL extension.
This extension includes support for enumerating the matrix types and
dimensions that are supported by the implementation, and which specific
features are supported.
New Commands
vkGetPhysicalDeviceCooperativeMatrixFlexibleDimensionsPropertiesNV
New Structures
VkCooperativeMatrixFlexibleDimensionsPropertiesNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCooperativeMatrix2FeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCooperativeMatrix2PropertiesNV
New Enum Constants
VK_NV_COOPERATIVE_MATRIX_2_EXTENSION_NAME
VK_NV_COOPERATIVE_MATRIX_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_FLEXIBLE_DIMENSIONS_PROPERTIES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_2_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_2_PROPERTIES_NV
New SPIR-V Capabilities
TensorAddressingNV
CooperativeMatrixReductionsNV
CooperativeMatrixConversionsNV
CooperativeMatrixPerElementOperationsNV
CooperativeMatrixTensorAddressingNV
CooperativeMatrixBlockLoadsNV
Issues
Version History
Revision 1, 2024-08-01 (Jeff Bolz)
Initial revision
VK_NV_cooperative_vector
Name String
VK_NV_cooperative_vector
Extension Type
Device extension
Registered Extension Number
492
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_cooperative_vector
Contact
Jeff Bolz
jeffbolznv
Extension Proposal
VK_NV_cooperative_vector
Other Extension Metadata
Last Modified Date
2024-05-23
Interactions and External Dependencies
This extension requires
SPV_NV_cooperative_vector
This extension provides API support for
GL_NV_cooperative_vector
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds support for using cooperative vector types in SPIR-V.
Unlike cooperative matrix types, a variable with a cooperative vector type
is logically stored in the invocation it belongs to, but they can cooperate
behind the scenes when performing matrix-vector multiplies.
Cooperative vectors do not require a fully occupied subgroup or uniform
control flow like cooperative matrices, although these do increase the
likelihood of being on the fast path.
And unlike normal vector types, they have arbitrary length and support a
relatively limited set of operations.
These types are intended to help accelerate the evaluation of small neural
networks, where each invocation is performing its own independent evaluation
of the network.
Cooperative vector types are defined by the
SPV_NV_cooperative_vector
SPIR-V extension and can be used with the
GL_NV_cooperative_vector
GLSL extension.
This extension includes support for enumerating the combinations of types
that are supported by the implementation, and for converting matrix data to
and from an optimized opaque layout.
New Commands
vkCmdConvertCooperativeVectorMatrixNV
vkConvertCooperativeVectorMatrixNV
vkGetPhysicalDeviceCooperativeVectorPropertiesNV
New Structures
VkConvertCooperativeVectorMatrixInfoNV
VkCooperativeVectorPropertiesNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCooperativeVectorFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCooperativeVectorPropertiesNV
New Unions
VkDeviceOrHostAddressConstKHR
VkDeviceOrHostAddressKHR
New Enums
VkComponentTypeKHR
VkCooperativeVectorMatrixLayoutNV
New Enum Constants
VK_NV_COOPERATIVE_VECTOR_EXTENSION_NAME
VK_NV_COOPERATIVE_VECTOR_SPEC_VERSION
Extending
VkComponentTypeKHR
VK_COMPONENT_TYPE_FLOAT_E4M3_NV
VK_COMPONENT_TYPE_FLOAT_E5M2_NV
VK_COMPONENT_TYPE_SINT8_PACKED_NV
VK_COMPONENT_TYPE_UINT8_PACKED_NV
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_CONVERT_COOPERATIVE_VECTOR_MATRIX_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_CONVERT_COOPERATIVE_VECTOR_MATRIX_INFO_NV
VK_STRUCTURE_TYPE_COOPERATIVE_VECTOR_PROPERTIES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_VECTOR_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_VECTOR_PROPERTIES_NV
New SPIR-V Capabilities
CooperativeVectorNV
Issues
Version History
Revision 4, 2024-05-23 (Jeff Bolz)
Add maxCooperativeVectorComponents
Revision 3, 2024-05-23 (Jeff Bolz)
Add training functions
Revision 2, 2024-02-10 (Jeff Bolz)
Add device-side matrix conversion
Revision 1, 2023-12-13 (Jeff Bolz)
Initial revisions
VK_NV_corner_sampled_image
Name String
VK_NV_corner_sampled_image
Extension Type
Device extension
Registered Extension Number
51
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2018-08-13
Contributors
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
Chris Lentini, NVIDIA
Description
This extension adds support for a new image organization, which this
extension refers to as “corner-sampled” images.
A corner-sampled image differs from a conventional image in the following
ways:
Texels are centered on integer coordinates.
See
Unnormalized Texel Coordinate Operations
Normalized coordinates are scaled using
coord × (dim - 1)
rather than
coord × dim
, where dim is the size of one
dimension of the image.
See
normalized texel coordinate transform
Partial derivatives are scaled using
coord × (dim - 1)
rather than
coord × dim
See
Scale Factor Operation
Calculation of the next higher LOD size goes according to
⌈dim / 2⌉
rather than
⌊dim / 2⌋
See
Image Mip Level Sizing
The minimum level size is 2x2 for 2D images and 2x2x2 for 3D images.
See
Image Mip Level Sizing
This image organization is designed to facilitate a system like Ptex with
separate textures for each face of a subdivision or polygon mesh.
Placing sample locations at pixel corners allows applications to maintain
continuity between adjacent patches by duplicating values along shared
edges.
Additionally, using the modified mipmapping logic along with texture
dimensions of the form
+1
allows continuity across shared edges
even if the adjacent patches use different LOD values.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCornerSampledImageFeaturesNV
New Enum Constants
VK_NV_CORNER_SAMPLED_IMAGE_EXTENSION_NAME
VK_NV_CORNER_SAMPLED_IMAGE_SPEC_VERSION
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CORNER_SAMPLED_IMAGE_FEATURES_NV
Issues
What should this extension be named?
DISCUSSION
: While naming this extension, we chose the most distinctive
aspect of the image organization and referred to such images as
“corner-sampled images”.
As a result, we decided to name the extension NV_corner_sampled_image.
Do we need a format feature flag so formats can advertise if they support corner-sampling?
DISCUSSION
: Currently NVIDIA supports this for all 2D and 3D formats, but
not for cube maps or depth-stencil formats.
A format feature might be useful if other vendors would only support this on
some formats.
Do integer texel coordinates have a different range for corner-sampled images?
RESOLVED
: No, these are unchanged.
Do unnormalized sampler coordinates work with corner-sampled images? Are there any functional differences?
RESOLVED
: Yes.
Unnormalized coordinates are treated as already scaled for corner-sample
usage.
Should we have a diagram in the “Image Operations” chapter demonstrating different texel sampling locations?
RESOLVED
: Maybe later.
Version History
Revision 1, 2018-08-14 (Daniel Koch)
Internal revisions
Revision 2, 2018-08-14 (Daniel Koch)
???
VK_NV_coverage_reduction_mode
Name String
VK_NV_coverage_reduction_mode
Extension Type
Device extension
Registered Extension Number
251
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_NV_framebuffer_mixed_samples
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Kedarnath Thangudu
kthangudu
Other Extension Metadata
Last Modified Date
2019-01-29
Contributors
Kedarnath Thangudu, NVIDIA
Jeff Bolz, NVIDIA
Description
When using a framebuffer with mixed samples, a per-fragment coverage
reduction operation is performed which generates color sample coverage from
the pixel coverage.
This extension defines the following modes to control how this reduction is
performed.
Merge: When there are more samples in the pixel coverage than color
samples, there is an implementation-dependent association of each pixel
coverage sample to a color sample.
In the merge mode, the color sample coverage is computed such that only
if any associated sample in the pixel coverage is covered, the color
sample is covered.
This is the default mode.
Truncate: When there are more raster samples (N) than color samples (M),
there is one to one association of the first M raster samples to the M
color samples; other raster samples are ignored.
When the number of raster samples is equal to the color samples, there is a
one to one mapping between them in either of the above modes.
The new command
vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV
can
be used to query the various raster, color, depth/stencil sample count and
reduction mode combinations that are supported by the implementation.
This extension would allow an implementation to support the behavior of both
VK_NV_framebuffer_mixed_samples
and
VK_AMD_mixed_attachment_samples
extensions simultaneously.
New Commands
vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV
New Structures
VkFramebufferMixedSamplesCombinationNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCoverageReductionModeFeaturesNV
Extending
VkPipelineMultisampleStateCreateInfo
VkPipelineCoverageReductionStateCreateInfoNV
New Enums
VkCoverageReductionModeNV
New Bitmasks
VkPipelineCoverageReductionStateCreateFlagsNV
New Enum Constants
VK_NV_COVERAGE_REDUCTION_MODE_EXTENSION_NAME
VK_NV_COVERAGE_REDUCTION_MODE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_FRAMEBUFFER_MIXED_SAMPLES_COMBINATION_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COVERAGE_REDUCTION_MODE_FEATURES_NV
VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_REDUCTION_STATE_CREATE_INFO_NV
Version History
Revision 1, 2019-01-29 (Kedarnath Thangudu)
Internal revisions
VK_NV_dedicated_allocation_image_aliasing
Name String
VK_NV_dedicated_allocation_image_aliasing
Extension Type
Device extension
Registered Extension Number
241
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_dedicated_allocation
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Nuno Subtil
nsubtil
Other Extension Metadata
Last Modified Date
2019-01-04
Contributors
Nuno Subtil, NVIDIA
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Axel Gneiting, id Software
Description
This extension allows applications to alias images on dedicated allocations,
subject to specific restrictions: the extent and the number of layers in the
image being aliased must be smaller than or equal to those of the original
image for which the allocation was created, and every other image parameter
must match.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDedicatedAllocationImageAliasingFeaturesNV
New Enum Constants
VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_EXTENSION_NAME
VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEDICATED_ALLOCATION_IMAGE_ALIASING_FEATURES_NV
Version History
Revision 1, 2019-01-04 (Nuno Subtil)
Internal revisions
VK_NV_descriptor_pool_overallocation
Name String
VK_NV_descriptor_pool_overallocation
Extension Type
Device extension
Registered Extension Number
547
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2023-08-30
Contributors
Jeff Bolz, NVIDIA
Description
There are scenarios where the application does not know ahead of time how
many descriptor sets it may need to allocate from a descriptor pool, or how
many descriptors of any of the descriptor types it may need to allocate from
the descriptor pool.
This extension gives applications the ability to request the implementation
allow more sets or descriptors to be allocated than initially specified at
descriptor pool creation time, subject to available resources.
The
VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_SETS_BIT_NV
flag
lets the application allocate more than
VkDescriptorPoolCreateInfo
::
maxSets
descriptor sets, and the
VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_POOLS_BIT_NV
lets the
application allocate more descriptors than initially specified by
VkDescriptorPoolSize
::
descriptorCount
for any descriptor types.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorPoolOverallocationFeaturesNV
New Enum Constants
VK_NV_DESCRIPTOR_POOL_OVERALLOCATION_EXTENSION_NAME
VK_NV_DESCRIPTOR_POOL_OVERALLOCATION_SPEC_VERSION
Extending
VkDescriptorPoolCreateFlagBits
VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_POOLS_BIT_NV
VK_DESCRIPTOR_POOL_CREATE_ALLOW_OVERALLOCATION_SETS_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_POOL_OVERALLOCATION_FEATURES_NV
Version History
Revision 1, 2023-08-30 (Piers Daniell)
Internal revisions
VK_NV_device_diagnostic_checkpoints
Name String
VK_NV_device_diagnostic_checkpoints
Extension Type
Device extension
Registered Extension Number
207
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_synchronization2
Contact
Nuno Subtil
nsubtil
Other Extension Metadata
Last Modified Date
2018-07-16
Contributors
Oleg Kuznetsov, NVIDIA
Alex Dunn, NVIDIA
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Daniel Koch, NVIDIA
Description
This extension allows applications to insert markers in the command stream
and associate them with custom data.
If a device lost error occurs, the application
may
then query the
implementation for the last markers to cross specific implementation-defined
pipeline stages, in order to narrow down which commands were executing at
the time and might have caused the failure.
New Commands
vkCmdSetCheckpointNV
vkGetQueueCheckpointDataNV
If
Vulkan Version 1.3
or
VK_KHR_synchronization2
is supported:
vkGetQueueCheckpointData2NV
New Structures
VkCheckpointDataNV
Extending
VkQueueFamilyProperties2
VkQueueFamilyCheckpointPropertiesNV
If
Vulkan Version 1.3
or
VK_KHR_synchronization2
is supported:
VkCheckpointData2NV
Extending
VkQueueFamilyProperties2
VkQueueFamilyCheckpointProperties2NV
New Enum Constants
VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_EXTENSION_NAME
VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV
VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV
If
Vulkan Version 1.3
or
VK_KHR_synchronization2
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_CHECKPOINT_DATA_2_NV
VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_2_NV
Version History
Revision 1, 2018-07-16 (Nuno Subtil)
Internal revisions
Revision 2, 2018-07-16 (Nuno Subtil)
???
VK_NV_device_diagnostics_config
Name String
VK_NV_device_diagnostics_config
Extension Type
Device extension
Registered Extension Number
301
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Kedarnath Thangudu
kthangudu
Other Extension Metadata
Last Modified Date
2022-04-06
Contributors
Kedarnath Thangudu, NVIDIA
Thomas Klein, NVIDIA
Description
Applications using Nvidia Nsight
Aftermath SDK for Vulkan to integrate
device crash dumps into their error reporting mechanisms,
may
use this
extension to configure options related to device crash dump creation.
Version 2 of this extension adds
VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV
which when set enables enhanced reporting of shader execution errors.
New Structures
Extending
VkDeviceCreateInfo
VkDeviceDiagnosticsConfigCreateInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDiagnosticsConfigFeaturesNV
New Enums
VkDeviceDiagnosticsConfigFlagBitsNV
New Bitmasks
VkDeviceDiagnosticsConfigFlagsNV
New Enum Constants
VK_NV_DEVICE_DIAGNOSTICS_CONFIG_EXTENSION_NAME
VK_NV_DEVICE_DIAGNOSTICS_CONFIG_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_DIAGNOSTICS_CONFIG_CREATE_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DIAGNOSTICS_CONFIG_FEATURES_NV
Version History
Revision 1, 2019-11-21 (Kedarnath Thangudu)
Internal revisions
Revision 2, 2022-04-06 (Kedarnath Thangudu)
Added a config bit
VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV
VK_NV_device_generated_commands
Name String
VK_NV_device_generated_commands
Extension Type
Device extension
Registered Extension Number
278
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
Contact
Christoph Kubisch
pixeljetstream
Other Extension Metadata
Last Modified Date
2020-02-20
Interactions and External Dependencies
This extension requires Vulkan 1.1
This extension requires
VK_EXT_buffer_device_address
or
VK_KHR_buffer_device_address
or Vulkan 1.2 for the ability to bind
vertex and index buffers on the device.
This extension interacts with
VK_NV_mesh_shader
If the latter extension is not supported, remove the command token to
initiate mesh tasks drawing in this extension.
Contributors
Christoph Kubisch, NVIDIA
Pierre Boudier, NVIDIA
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Yuriy O’Donnell, Epic Games
Baldur Karlsson, Valve
Mathias Schott, NVIDIA
Tyson Smith, NVIDIA
Ingo Esser, NVIDIA
Description
This extension allows the device to generate a number of critical graphics
commands for command buffers.
When rendering a large number of objects, the device can be leveraged to
implement a number of critical functions, like updating matrices, or
implementing occlusion culling, frustum culling, front to back sorting, etc.
Implementing those on the device does not require any special extension,
since an application is free to define its own data structures, and just
process them using shaders.
However, if the application desires to quickly kick off the rendering of the
final stream of objects, then unextended Vulkan forces the application to
read back the processed stream and issue graphics command from the host.
For very large scenes, the synchronization overhead and cost to generate the
command buffer can become the bottleneck.
This extension allows an application to generate a device side stream of
state changes and commands, and convert it efficiently into a command buffer
without having to read it back to the host.
Furthermore, it allows incremental changes to such command buffers by
manipulating only partial sections of a command stream — for example
pipeline bindings.
Unextended Vulkan requires re-creation of entire command buffers in such a
scenario, or updates synchronized on the host.
The intended usage for this extension is for the application to:
create
VkBuffer
objects and retrieve physical addresses from them
via
vkGetBufferDeviceAddressEXT
create a graphics pipeline using
VkGraphicsPipelineShaderGroupsCreateInfoNV
for the ability to
change shaders on the device.
create a
VkIndirectCommandsLayoutNV
, which lists the
VkIndirectCommandsTokenTypeNV
it wants to dynamically execute as
an atomic command sequence.
This step likely involves some internal device code compilation, since
the intent is for the GPU to generate the command buffer in the
pipeline.
fill the input stream buffers with the data for each of the inputs it
needs.
Each input is an array that will be filled with token-dependent data.
set up a preprocess
VkBuffer
that uses memory according to the
information retrieved via
vkGetGeneratedCommandsMemoryRequirementsNV
optionally preprocess the generated content using
vkCmdPreprocessGeneratedCommandsNV
, for example on an asynchronous
compute queue, or for the purpose of reusing the data in multiple
executions.
call
vkCmdExecuteGeneratedCommandsNV
to create and execute the
actual device commands for all sequences based on the inputs provided.
For each draw in a sequence, the following can be specified:
a different shader group
a number of vertex buffer bindings
a different index buffer, with an optional dynamic offset and index type
a number of different push constants
a flag that encodes the primitive winding
While the GPU can be faster than a CPU to generate the commands, it will not
happen asynchronously to the device, therefore the primary use case is
generating “less” total work (occlusion culling, classification to use
specialized shaders, etc.).
New Object Types
VkIndirectCommandsLayoutNV
New Commands
vkCmdBindPipelineShaderGroupNV
vkCmdExecuteGeneratedCommandsNV
vkCmdPreprocessGeneratedCommandsNV
vkCreateIndirectCommandsLayoutNV
vkDestroyIndirectCommandsLayoutNV
vkGetGeneratedCommandsMemoryRequirementsNV
New Structures
VkBindIndexBufferIndirectCommandNV
VkBindShaderGroupIndirectCommandNV
VkBindVertexBufferIndirectCommandNV
VkGeneratedCommandsInfoNV
VkGeneratedCommandsMemoryRequirementsInfoNV
VkGraphicsShaderGroupCreateInfoNV
VkIndirectCommandsLayoutCreateInfoNV
VkIndirectCommandsLayoutTokenNV
VkIndirectCommandsStreamNV
VkSetStateFlagsIndirectCommandNV
Extending
VkGraphicsPipelineCreateInfo
VkGraphicsPipelineShaderGroupsCreateInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDeviceGeneratedCommandsFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDeviceGeneratedCommandsPropertiesNV
New Enums
VkIndirectCommandsLayoutUsageFlagBitsNV
VkIndirectCommandsTokenTypeNV
VkIndirectStateFlagBitsNV
New Bitmasks
VkIndirectCommandsLayoutUsageFlagsNV
VkIndirectStateFlagsNV
New Enum Constants
VK_NV_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME
VK_NV_DEVICE_GENERATED_COMMANDS_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV
VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV
Extending
VkObjectType
VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NV
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_INDIRECT_BINDABLE_BIT_NV
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_NV
VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_NV
VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_SHADER_GROUPS_CREATE_INFO_NV
VK_STRUCTURE_TYPE_GRAPHICS_SHADER_GROUP_CREATE_INFO_NV
VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NV
VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_NV
Issues
1) How to name this extension ?
VK_NV_device_generated_commands
As usual, one of the hardest issues ;)
Alternatives:
VK_gpu_commands
VK_execute_commands
VK_device_commands
VK_device_execute_commands
VK_device_execute
VK_device_created_commands
VK_device_recorded_commands
VK_device_generated_commands
VK_indirect_generated_commands
2) Should we use a serial stateful token stream or stateless sequence
descriptions?
Similarly to
VkPipeline
, fixed layouts have the most likelihood to be
cross-vendor adoptable.
They also benefit from being processable in parallel.
This is a different design choice compared to the serial command stream
generated through
GL_NV_command_list
3) How to name a sequence description?
VkIndirectCommandsLayout
as in the NVX extension predecessor.
Alternative:
VkGeneratedCommandsLayout
4) Do we want to provide
indirectCommands
inputs with layout or at
indirectCommands
time?
Separate layout from data as Vulkan does.
Provide full flexibility for
indirectCommands
5) Should the input be provided as SoA or AoS?
Both ways are desirable.
AoS can provide portability to other APIs and easier to setup, while SoA
allows to update individual inputs in a cache-efficient manner, when others
remain static.
6) How do we make developers aware of the memory requirements of
implementation-dependent data used for the generated commands?
Make the API explicit and introduce a
preprocess
VkBuffer
Developers have to allocate it using
vkGetGeneratedCommandsMemoryRequirementsNV
In the NVX version the requirements were hidden implicitly as part of the
command buffer reservation process, however as the memory requirements can
be substantial, we want to give developers the ability to budget the memory
themselves.
By lowering the
maxSequencesCount
the memory consumption can be reduced.
Furthermore reuse of the memory is possible, for example for doing explicit
preprocessing and execution in a ping-pong fashion.
The actual buffer size is implementation-dependent and may be zero, i.e. not
always required.
When making use of Graphics Shader Groups, the programs should behave
similarly with regards to vertex inputs, clipping and culling outputs of the
geometry stage, and sample shading behavior in fragment shaders, to reduce
the amount of the worst-case memory approximation.
7) Should we allow additional per-sequence dynamic state changes?
Yes
Introduced a lightweight indirect state flag
VkIndirectStateFlagBitsNV
So far only switching front face winding state is exposed.
Especially in CAD/DCC mirrored transforms that require such changes are
common, and similar flexibility is given in the ray tracing instance
description.
The flag could be extended further, for example to switch between
primitive-lists or -strips, or make other state modifications.
Furthermore, as new tokens can be added easily, future extension could add
the ability to change any
VkDynamicState
8) How do we allow reusing already “generated”
indirectCommands
Expose a
preprocessBuffer
to reuse implementation-dependencyFlags data.
Set
isPreprocessed
to
VK_TRUE
in
vkCmdExecuteGeneratedCommandsNV
9) Under which conditions is
vkCmdExecuteGeneratedCommandsNV
legal?
It behaves like a regular draw call command.
10) Is
vkCmdPreprocessGeneratedCommandsNV
copying the input data or
referencing it?
There are multiple implementations possible:
one could have some emulation code that parses the inputs, and generates
an output command buffer, therefore copying the inputs.
one could just reference the inputs, and have the processing done in
pipe at execution time.
If the data is mandated to be copied, then it puts a penalty on
implementation that could process the inputs directly in pipe.
If the data is “referenced”, then it allows both types of implementation.
The inputs are “referenced”, and
must
not be modified after the call to
vkCmdExecuteGeneratedCommandsNV
has completed.
11) Which buffer usage flags are required for the buffers referenced by
VkGeneratedCommandsInfoNV
Reuse existing
VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT
VkGeneratedCommandsInfoNV
::
preprocessBuffer
VkGeneratedCommandsInfoNV
::
sequencesCountBuffer
VkGeneratedCommandsInfoNV
::
sequencesIndexBuffer
VkIndirectCommandsStreamNV
::
buffer
12) In which pipeline stage does the device generated command expansion
happen?
vkCmdPreprocessGeneratedCommandsNV
is treated as if it occurs in a
separate logical pipeline from either graphics or compute, and that pipeline
only includes
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT
, a new stage
VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV
, and
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
This new stage has two corresponding new access types,
VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV
and
VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV
, used to synchronize reading
the buffer inputs and writing the preprocess memory output.
The generated output written in the preprocess buffer memory by
vkCmdExecuteGeneratedCommandsNV
is considered to be consumed by the
VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT
pipeline stage.
Thus, to synchronize from writing the input buffers to preprocessing via
vkCmdPreprocessGeneratedCommandsNV
, use:
dstStageMask
VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV
dstAccessMask
VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV
To synchronize from
vkCmdPreprocessGeneratedCommandsNV
to executing
the generated commands by
vkCmdExecuteGeneratedCommandsNV
, use:
srcStageMask
VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV
srcAccessMask
VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV
dstStageMask
VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT
dstAccessMask
VK_ACCESS_INDIRECT_COMMAND_READ_BIT
When
vkCmdExecuteGeneratedCommandsNV
is used with a
isPreprocessed
of
VK_FALSE
, the generated commands are implicitly
preprocessed, therefore one only needs to synchronize the inputs via:
dstStageMask
VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT
dstAccessMask
VK_ACCESS_INDIRECT_COMMAND_READ_BIT
13) What if most token data is “static”, but we frequently want to render
a subsection?
Added “sequencesIndexBuffer”.
This allows to easier sort and filter what should actually be executed.
14) What are the changes compared to the previous NVX extension?
Compute dispatch support was removed (was never implemented in drivers).
There are different approaches how dispatching from the device should
work, hence we defer this to a future extension.
The
ObjectTableNVX
was replaced by using physical buffer addresses and
introducing Shader Groups for the graphics pipeline.
Less state changes are possible overall, but the important operations
are still there (reduces complexity of implementation).
The API was redesigned so all inputs must be passed at both
preprocessing and execution time (this was implicit in NVX, now it is
explicit)
The reservation of intermediate command space is now mandatory and
explicit through a preprocess buffer.
The
VkIndirectStateFlagBitsNV
were introduced
15) When porting from other APIs, their indirect buffers may use different
enums, for example for index buffer types.
How to solve this?
Added “pIndexTypeValues” to map custom
uint32_t
values to corresponding
VkIndexType
16) Do we need more shader group state overrides?
The NVX version allowed all PSO states to be different, however as the goal
is not to replace all state setup, but focus on highly-frequent state
changes for drawing lots of objects, we reduced the amount of state
overrides.
Especially VkPipelineLayout as well as VkRenderPass configuration should be
left static, the rest is still open for discussion.
The current focus is just to allow VertexInput changes as well as shaders,
while all shader groups use the same shader stages.
Too much flexibility will increase the test coverage requirement as well.
However, further extensions could allow more dynamic state as well.
17) Do we need more detailed physical device feature queries/enables?
An EXT version would need detailed implementor feedback to come up with a
good set of features.
Please contact us if you are interested, we are happy to make more features
optional, or add further restrictions to reduce the minimum feature set of
an EXT.
18) Is there an interaction with VK_KHR_pipeline_library planned?
Yes, a future version of this extension will detail the interaction, once
VK_KHR_pipeline_library is no longer provisional.
Example Code
Open-Source samples illustrating the usage of the extension can be found at
the following location (may not yet exist at time of writing):
Version History
Revision 1, 2020-02-20 (Christoph Kubisch)
Initial version
Revision 2, 2020-03-09 (Christoph Kubisch)
Remove VK_EXT_debug_report interactions
Revision 3, 2020-03-09 (Christoph Kubisch)
Fix naming VkPhysicalDeviceGenerated to VkPhysicalDeviceDeviceGenerated
VK_NV_device_generated_commands_compute
Name String
VK_NV_device_generated_commands_compute
Extension Type
Device extension
Registered Extension Number
429
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_NV_device_generated_commands
Contact
Vikram Kushwaha
vkushwaha-nv
Other Extension Metadata
Last Modified Date
2023-07-21
Contributors
Vikram Kushwaha, NVIDIA
Jeff Bolz, NVIDIA
Christoph Kubisch, NVIDIA
Piers Daniell, NVIDIA
Daniel Koch, NVIDIA
Hans-Kristian Arntzen, Valve
Mike Blumenkrantz, VALVE
Description
This extension allows the device to generate commands for binding compute
pipelines, setting push constants and launching compute dispatches.
New Commands
vkCmdUpdatePipelineIndirectBufferNV
vkGetPipelineIndirectDeviceAddressNV
vkGetPipelineIndirectMemoryRequirementsNV
New Structures
VkBindPipelineIndirectCommandNV
VkPipelineIndirectDeviceAddressInfoNV
Extending
VkComputePipelineCreateInfo
VkComputePipelineIndirectBufferInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDeviceGeneratedCommandsComputeFeaturesNV
New Enum Constants
VK_NV_DEVICE_GENERATED_COMMANDS_COMPUTE_EXTENSION_NAME
VK_NV_DEVICE_GENERATED_COMMANDS_COMPUTE_SPEC_VERSION
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_INDIRECT_BINDABLE_BIT_NV
Extending
VkIndirectCommandsTokenTypeNV
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DISPATCH_NV
VK_INDIRECT_COMMANDS_TOKEN_TYPE_PIPELINE_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_INDIRECT_BUFFER_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_COMPUTE_FEATURES_NV
VK_STRUCTURE_TYPE_PIPELINE_INDIRECT_DEVICE_ADDRESS_INFO_NV
Version History
Revision 2, 2023-07-21 (Vikram Kushwaha)
Rename vkCmdUpdatePipelineIndirectBuffer to
vkCmdUpdatePipelineIndirectBufferNV
Revision 1, 2023-06-09 (Vikram Kushwaha)
First Revision
VK_NV_display_stereo
Name String
VK_NV_display_stereo
Extension Type
Instance extension
Registered Extension Number
552
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_display
and
VK_KHR_get_display_properties2
Contact
Russell Chou
russellcnv
Extension Proposal
VK_NV_display_stereo
Other Extension Metadata
Last Modified Date
2024-11-20
Contributors
Russell Chou, NVIDIA
Jeff Juliano, NVIDIA
James Jones, NVIDIA
Description
This extension allows the application to choose which type of 3D stereo
hardware it wants to use so the driver can configure it properly.
This configuration is useful for swapchains created from display surfaces
because some environments do not have an intermediate windowing system
available for easy configuration.
This extension will override any stereo type configuration in the windowing
system.
For HDMI 3D, only some display modes support stereo rendering, and a new
structure is needed to expose that information to the application.
New Structures
Extending
VkDisplayModeProperties2KHR
VkDisplayModeStereoPropertiesNV
Extending
VkDisplaySurfaceCreateInfoKHR
VkDisplaySurfaceStereoCreateInfoNV
New Enums
VkDisplaySurfaceStereoTypeNV
New Enum Constants
VK_NV_DISPLAY_STEREO_EXTENSION_NAME
VK_NV_DISPLAY_STEREO_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DISPLAY_MODE_STEREO_PROPERTIES_NV
VK_STRUCTURE_TYPE_DISPLAY_SURFACE_STEREO_CREATE_INFO_NV
Version History
Revision 1, 2024-11-20 (Russell Chou)
Initial release
VK_NV_extended_sparse_address_space
Name String
VK_NV_extended_sparse_address_space
Extension Type
Device extension
Registered Extension Number
493
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Russell Chou
russellcnv
Other Extension Metadata
Last Modified Date
2023-10-03
Contributors
Russell Chou, NVIDIA
Christoph Kubisch, NVIDIA
Eric Werness, NVIDIA
Jeff Bolz, NVIDIA
Description
Implementations may be able to support an extended address space for sparse
memory resources, but only for a certain set of usages.
This extension adds a query for the extended limit, and the supported usages
that are allowed for that limit.
This limit is an increase to
VkPhysicalDeviceLimits
::
sparseAddressSpaceSize
when the
VkImage
or
VkBuffer
uses only usages that are supported.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExtendedSparseAddressSpaceFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceExtendedSparseAddressSpacePropertiesNV
New Enum Constants
VK_NV_EXTENDED_SPARSE_ADDRESS_SPACE_EXTENSION_NAME
VK_NV_EXTENDED_SPARSE_ADDRESS_SPACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_SPARSE_ADDRESS_SPACE_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_SPARSE_ADDRESS_SPACE_PROPERTIES_NV
Version History
Revision 1, 2023-10-03 (Russell Chou)
Initial draft
VK_NV_external_compute_queue
Name String
VK_NV_external_compute_queue
Extension Type
Device extension
Registered Extension Number
557
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Chris Lentini
clentini
Extension Proposal
VK_NV_external_compute_queue
Other Extension Metadata
Last Modified Date
2025-03-24
Contributors
Chris Lentini, NVIDIA
Eric Werness, NVIDIA
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Liam Middlebrook, NVIDIA
Lionel Duc, NVIDIA
Description
This extension gives applications the ability to join compatible external
compute APIs to a
VkDevice
In this way, the extension allows an application to achieve simultaneous
execution between work submitted from these compatible external APIs and
work that has been submitted through the Vulkan API.
At device creation time, an application
must
supply a
VkExternalComputeQueueDeviceCreateInfoNV
This communicates to the implementation the maximum number of external
queues that the application
can
create at once.
This information
may
be used by the implementation to aid in decisions made
during device creation.
After device creation, the function
vkCreateExternalComputeQueueNV
is
used by an application to create a new
VkExternalComputeQueueNV
object.
The
VkExternalComputeQueueNV
object holds information and reserves
resources necessary for a compatible external API to be able to join a
VkDevice
This information can be queried through the
vkGetExternalComputeQueueDataNV
function, returning an opaque blob of
data which can be passed to compatible external APIs.
The application
must
finally call
vkDestroyExternalComputeQueueNV
when it is done in order to release the reserved resources.
This extension introduces a new properties structure,
VkPhysicalDeviceExternalComputeQueuePropertiesNV
, which can be queried
through
vkGetPhysicalDeviceProperties2
The structure provides information on functional limits to the extension as
well as a way of querying the size of the application allocated memory which
must
be passed to the
vkGetExternalComputeQueueDataNV
function.
When creating a
VkExternalComputeQueueNV
through
vkCreateExternalComputeQueueNV
, the
VkExternalComputeQueueCreateInfoNV
structure requires an application
to supply a
VkQueue
to aid in external compute queue creation.
The supplied
VkQueue
is a strong scheduling hint about which queue it
expects to submit graphics workloads to and with which it expects
simultaneous execution of compute workloads submitted through the external
API.
New Object Types
VkExternalComputeQueueNV
New Commands
vkCreateExternalComputeQueueNV
vkDestroyExternalComputeQueueNV
vkGetExternalComputeQueueDataNV
New Structures
VkExternalComputeQueueCreateInfoNV
VkExternalComputeQueueDataParamsNV
Extending
VkDeviceCreateInfo
VkExternalComputeQueueDeviceCreateInfoNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceExternalComputeQueuePropertiesNV
New Enum Constants
VK_NV_EXTERNAL_COMPUTE_QUEUE_EXTENSION_NAME
VK_NV_EXTERNAL_COMPUTE_QUEUE_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_EXTERNAL_COMPUTE_QUEUE_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXTERNAL_COMPUTE_QUEUE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_EXTERNAL_COMPUTE_QUEUE_DATA_PARAMS_NV
VK_STRUCTURE_TYPE_EXTERNAL_COMPUTE_QUEUE_DEVICE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_COMPUTE_QUEUE_PROPERTIES_NV
While the external queue is now a part of a
VkDevice
, idling the
device through
vkDeviceWaitIdle
does not wait for the external queue.
Draining the work on an external queue
must
be done through its own
external API.
External queues
must
be idled before destroying the associated
VkDevice
In general, synchronization and resource sharing between the external API
and Vulkan must still be accomplished via existing cross-API interop
mechanisms.
Issues
Version History
Revision 1, 2024-05-20 (Chris Lentini)
Internal revisions
VK_NV_external_memory_rdma
Name String
VK_NV_external_memory_rdma
Extension Type
Device extension
Registered Extension Number
372
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_external_memory
or
Vulkan Version 1.1
Contact
Carsten Rohde
crohde
Other Extension Metadata
Last Modified Date
2021-04-19
IP Status
No known IP claims.
Contributors
Carsten Rohde, NVIDIA
Description
This extension adds support for allocating memory which can be used for
remote direct memory access (RDMA) from other devices.
New Base Types
VkRemoteAddressNV
New Commands
vkGetMemoryRemoteAddressNV
New Structures
VkMemoryGetRemoteAddressInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExternalMemoryRDMAFeaturesNV
New Enum Constants
VK_NV_EXTERNAL_MEMORY_RDMA_EXTENSION_NAME
VK_NV_EXTERNAL_MEMORY_RDMA_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV
Extending
VkMemoryPropertyFlagBits
VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_RDMA_FEATURES_NV
Issues
Examples
VkPhysicalDeviceMemoryBudgetPropertiesEXT memoryBudgetProperties = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT };
VkPhysicalDeviceMemoryProperties2 memoryProperties2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2, &memoryBudgetProperties };
vkGetPhysicalDeviceMemoryProperties2(physicalDevice, &memoryProperties2);
uint32_t heapIndex = (uint32_t)-1;
for (uint32_t memoryType = 0; memoryType < memoryProperties2.memoryProperties.memoryTypeCount; memoryType++) {
if (memoryProperties2.memoryProperties.memoryTypes[memoryType].propertyFlags & VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV) {
heapIndex = memoryProperties2.memoryProperties.memoryTypes[memoryType].heapIndex;
break;
if ((heapIndex == (uint32_t)-1) ||
(memoryBudgetProperties.heapBudget[heapIndex] < size)) {
return;

VkPhysicalDeviceExternalBufferInfo externalBufferInfo = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO };
externalBufferInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;
externalBufferInfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkExternalBufferProperties externalBufferProperties = { VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES };
vkGetPhysicalDeviceExternalBufferProperties(physicalDevice, &externalBufferInfo, &externalBufferProperties);

if (!(externalBufferProperties.externalMemoryProperties.externalMemoryFeatures & VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT)) {
return;

VkExternalMemoryBufferCreateInfo externalMemoryBufferCreateInfo = { VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO };
externalMemoryBufferCreateInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkBufferCreateInfo bufferCreateInfo = { VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO, &externalMemoryBufferCreateInfo };
bufferCreateInfo.size = size;
bufferCreateInfo.usage = VK_BUFFER_USAGE_TRANSFER_SRC_BIT | VK_BUFFER_USAGE_TRANSFER_DST_BIT;

VkMemoryRequirements mem_reqs;
vkCreateBuffer(device, &bufferCreateInfo, NULL, &buffer);
vkGetBufferMemoryRequirements(device, buffer, &mem_reqs);

VkExportMemoryAllocateInfo exportMemoryAllocateInfo = { VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO };
exportMemoryAllocateInfo.handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

// Find memory type index
uint32_t i = 0;
for (; i < VK_MAX_MEMORY_TYPES; i++) {
if ((mem_reqs.memoryTypeBits & (1 << i)) &&
(memoryProperties.memoryTypes[i].propertyFlags & VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV)) {
break;

VkMemoryAllocateInfo memAllocInfo = { VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO, &exportMemoryAllocateInfo };
memAllocInfo.allocationSize = mem_reqs.size;
memAllocInfo.memoryTypeIndex = i;

vkAllocateMemory(device, &memAllocInfo, NULL, &mem);
vkBindBufferMemory(device, buffer, mem, 0);

VkMemoryGetRemoteAddressInfoNV getMemoryRemoteAddressInfo = { VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV };
getMemoryRemoteAddressInfo.memory = mem;
getMemoryRemoteAddressInfo.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV;

VkRemoteAddressNV rdmaAddress;
vkGetMemoryRemoteAddressNV(device, &getMemoryRemoteAddressInfo, &rdmaAddress);
// address returned in 'rdmaAddress' can be used by external devices to initiate RDMA transfers
Version History
Revision 1, 2020-12-15 (Carsten Rohde)
Internal revisions
VK_NV_fill_rectangle
Name String
VK_NV_fill_rectangle
Extension Type
Device extension
Registered Extension Number
154
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-05-22
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds a new
VkPolygonMode
enum
where a triangle is
rasterized by computing and filling its axis-aligned screen-space bounding
box, disregarding the actual triangle edges.
This can be useful for drawing a rectangle without being split into two
triangles with an internal edge.
It is also useful to minimize the number of primitives that need to be
drawn, particularly for a user interface.
New Enum Constants
VK_NV_FILL_RECTANGLE_EXTENSION_NAME
VK_NV_FILL_RECTANGLE_SPEC_VERSION
Extending
VkPolygonMode
VK_POLYGON_MODE_FILL_RECTANGLE_NV
Version History
Revision 1, 2017-05-22 (Jeff Bolz)
Internal revisions
VK_NV_fragment_coverage_to_color
Name String
VK_NV_fragment_coverage_to_color
Extension Type
Device extension
Registered Extension Number
150
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-05-21
Contributors
Jeff Bolz, NVIDIA
Description
This extension allows the fragment coverage value, represented as an integer
bitmask, to be substituted for a color output being written to a
single-component color attachment with integer components (e.g.
VK_FORMAT_R8_UINT
).
The functionality provided by this extension is different from simply
writing the
SampleMask
fragment shader output, in that the coverage
value written to the framebuffer is taken after stencil test and depth test,
as well as after fragment operations such as alpha-to-coverage.
This functionality may be useful for deferred rendering algorithms, where
the second pass needs to know which samples belong to which original
fragments.
New Structures
Extending
VkPipelineMultisampleStateCreateInfo
VkPipelineCoverageToColorStateCreateInfoNV
New Bitmasks
VkPipelineCoverageToColorStateCreateFlagsNV
New Enum Constants
VK_NV_FRAGMENT_COVERAGE_TO_COLOR_EXTENSION_NAME
VK_NV_FRAGMENT_COVERAGE_TO_COLOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_TO_COLOR_STATE_CREATE_INFO_NV
Version History
Revision 1, 2017-05-21 (Jeff Bolz)
Internal revisions
VK_NV_fragment_shading_rate_enums
Name String
VK_NV_fragment_shading_rate_enums
Extension Type
Device extension
Registered Extension Number
327
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_fragment_shading_rate
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2020-09-02
Contributors
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension builds on the fragment shading rate functionality provided by
the VK_KHR_fragment_shading_rate extension, adding support for
“supersample” fragment shading rates that trigger multiple fragment shader
invocations per pixel as well as a “no invocations” shading rate that
discards any portions of a primitive that would use that shading rate.
New Commands
vkCmdSetFragmentShadingRateEnumNV
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkPipelineFragmentShadingRateEnumStateCreateInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentShadingRateEnumsFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentShadingRateEnumsPropertiesNV
New Enums
VkFragmentShadingRateNV
VkFragmentShadingRateTypeNV
New Enum Constants
VK_NV_FRAGMENT_SHADING_RATE_ENUMS_EXTENSION_NAME
VK_NV_FRAGMENT_SHADING_RATE_ENUMS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_PROPERTIES_NV
VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_ENUM_STATE_CREATE_INFO_NV
Issues
Why was this extension created? How should it be named?
RESOLVED
: The primary goal of this extension was to expose support for
supersample and “no invocations” shading rates, which are supported by the
VK_NV_shading_rate_image extension but not by VK_KHR_fragment_shading_rate.
Because VK_KHR_fragment_shading_rate specifies the primitive shading rate
using a fragment size in pixels, it lacks a good way to specify supersample
rates.
To deal with this, we defined enums covering shading rates supported by the
KHR extension as well as the new shading rates and added structures and APIs
accepting shading rate enums instead of fragment sizes.
Since this extension adds two different types of shading rates, both
expressed using enums, we chose the extension name
VK_NV_fragment_shading_rate_enums.
Is this a standalone extension?
RESOLVED
: No, this extension requires VK_KHR_fragment_shading_rate.
In order to use the features of this extension, applications must enable the
relevant features of KHR extension.
How are the shading rate enums used, and how were the enum values assigned?
RESOLVED
: The shading rates supported by the enums in this extension are
accepted as pipeline, primitive, and attachment shading rates and behave
identically.
For the shading rates also supported by the KHR extension, the values
assigned to the corresponding enums are identical to the values already used
for the primitive and attachment shading rates in the KHR extension.
For those enums, bits 0 and 1 specify the base two logarithm of the fragment
height and bits 2 and 3 specify the base two logarithm of the fragment
width.
For the new shading rates added by this extension, we chose to use 11
through 14 (10 plus the base two logarithm of the invocation count) for the
supersample rates and 15 for the “no invocations” rate.
None of those values are supported as primitive or attachment shading rates
by the KHR extension.
Between this extension, VK_KHR_fragment_shading_rate, and
VK_NV_shading_rate_image, there are three different ways to specify shading
rate state in a pipeline.
How should we handle this?
RESOLVED
: We do not allow the concurrent use of VK_NV_shading_rate_image
and VK_KHR_fragment_shading_rate; it is an error to enable shading rate
features from both extensions.
But we do allow applications to enable this extension together with
VK_KHR_fragment_shading_rate together.
While we expect that applications will never attach pipeline CreateInfo
structures for both this extension and the KHR extension concurrently,
Vulkan does not have any precedent forbidding such behavior and instead
typically treats a pipeline created without an extension-specific CreateInfo
structure as equivalent to one containing default values specified by the
extension.
Rather than adding such a rule considering the presence or absence of our
new CreateInfo structure, we instead included a
shadingRateType
member
to
VkPipelineFragmentShadingRateEnumStateCreateInfoNV
that selects
between using state specified by that structure and state specified by
VkPipelineFragmentShadingRateStateCreateInfoKHR
Version History
Revision 1, 2020-09-02 (pbrown)
Internal revisions
VK_NV_framebuffer_mixed_samples
Name String
VK_NV_framebuffer_mixed_samples
Extension Type
Device extension
Registered Extension Number
153
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-06-04
Contributors
Jeff Bolz, NVIDIA
Description
This extension allows multisample rendering with a raster and depth/stencil
sample count that is larger than the color sample count.
Rasterization and the results of the depth and stencil tests together
determine the portion of a pixel that is “covered”.
It can be useful to evaluate coverage at a higher frequency than color
samples are stored.
This coverage is then “reduced” to a collection of covered color samples,
each having an opacity value corresponding to the fraction of the color
sample covered.
The opacity can optionally be blended into individual color samples.
Rendering with fewer color samples than depth/stencil samples greatly
reduces the amount of memory and bandwidth consumed by the color buffer.
However, converting the coverage values into opacity introduces artifacts
where triangles share edges and
may
not be suitable for normal triangle
mesh rendering.
One expected use case for this functionality is Stencil-then-Cover path
rendering (similar to the OpenGL GL_NV_path_rendering extension).
The stencil step determines the coverage (in the stencil buffer) for an
entire path at the higher sample frequency, and then the cover step draws
the path into the lower frequency color buffer using the coverage
information to antialias path edges.
With this two-step process, internal edges are fully covered when
antialiasing is applied and there is no corruption on these edges.
The key features of this extension are:
It allows render pass and framebuffer objects to be created where the
number of samples in the depth/stencil attachment in a subpass is a
multiple of the number of samples in the color attachments in the
subpass.
A coverage reduction step is added to Fragment Operations which converts
a set of covered raster/depth/stencil samples to a set of color samples
that perform blending and color writes.
The coverage reduction step also includes an optional coverage
modulation step, multiplying color values by a fractional opacity
corresponding to the number of associated raster/depth/stencil samples
covered.
New Structures
Extending
VkPipelineMultisampleStateCreateInfo
VkPipelineCoverageModulationStateCreateInfoNV
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkCommandBufferInheritanceInfo
VkGraphicsPipelineCreateInfo
VkAttachmentSampleCountInfoNV
New Enums
VkCoverageModulationModeNV
New Bitmasks
VkPipelineCoverageModulationStateCreateFlagsNV
New Enum Constants
VK_NV_FRAMEBUFFER_MIXED_SAMPLES_EXTENSION_NAME
VK_NV_FRAMEBUFFER_MIXED_SAMPLES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_NV
Version History
Revision 1, 2017-06-04 (Jeff Bolz)
Internal revisions
VK_NV_geometry_shader_passthrough
Name String
VK_NV_geometry_shader_passthrough
Extension Type
Device extension
Registered Extension Number
96
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_NV_geometry_shader_passthrough
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2017-02-15
Interactions and External Dependencies
This extension provides API support for
GL_NV_geometry_shader_passthrough
This extension requires the
geometryShader
feature.
Contributors
Piers Daniell, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_geometry_shader_passthrough
Geometry shaders provide the ability for applications to process each
primitive sent through the graphics pipeline using a programmable shader.
However, one common use case treats them largely as a “passthrough”.
In this use case, the bulk of the geometry shader code simply copies inputs
from each vertex of the input primitive to corresponding outputs in the
vertices of the output primitive.
Such shaders might also compute values for additional built-in or
user-defined per-primitive attributes (e.g.,
Layer
) to be assigned to
all the vertices of the output primitive.
This extension provides access to the
PassthroughNV
decoration under
the
GeometryShaderPassthroughNV
capability.
Adding this to a geometry shader input variable specifies that the values of
this input are copied to the corresponding vertex of the output primitive.
When using GLSL source-based shading languages, the
passthrough
layout
qualifier from
GL_NV_geometry_shader_passthrough
maps to the
PassthroughNV
decoration.
To use the
passthrough
layout, in GLSL the
GL_NV_geometry_shader_passthrough
extension must be enabled.
Behavior is described in the
GL_NV_geometry_shader_passthrough
extension
specification.
New Enum Constants
VK_NV_GEOMETRY_SHADER_PASSTHROUGH_EXTENSION_NAME
VK_NV_GEOMETRY_SHADER_PASSTHROUGH_SPEC_VERSION
New Variable Decoration
PassthroughNV
in
Geometry Shader Passthrough
New SPIR-V Capabilities
GeometryShaderPassthroughNV
Issues
1) Should we require or allow a passthrough geometry shader to specify the
output layout qualifiers for the output primitive type and maximum vertex
count in the SPIR-V?
RESOLVED
: Yes they should be required in the SPIR-V.
Per GL_NV_geometry_shader_passthrough they are not permitted in the GLSL
source shader, but SPIR-V is lower-level.
It is straightforward for the GLSL compiler to infer them from the input
primitive type and to explicitly emit them in the SPIR-V according to the
following table.
Input Layout
Implied Output Layout
points
layout(points, max_vertices=1)
lines
layout(line_strip, max_vertices=2)
triangles
layout(triangle_strip, max_vertices=3)
2) How does interface matching work with passthrough geometry shaders?
RESOLVED
: This is described in
Passthrough Interface Matching
In GL when using passthrough geometry shaders in separable mode, all inputs
must also be explicitly assigned location layout qualifiers.
In Vulkan all SPIR-V shader inputs (except built-ins) must also have
location decorations specified.
Redeclarations of built-in variables that add the passthrough layout
qualifier are exempted from the rule requiring location assignment because
built-in variables do not have locations and are matched by
BuiltIn
decoration.
Sample Code
Consider the following simple geometry shader in unextended GLSL:
layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices=3) out;

in Inputs {
vec2 texcoord;
vec4 baseColor;
} v_in[];
out Outputs {
vec2 texcoord;
vec4 baseColor;
};

void main()
int layer = compute_layer();
for (int i = 0; i < 3; i++) {
gl_Position = gl_in[i].gl_Position;
texcoord = v_in[i].texcoord;
baseColor = v_in[i].baseColor;
gl_Layer = layer;
EmitVertex();
In this shader, the inputs
gl_Position
Inputs.texcoord
, and
Inputs.baseColor
are simply copied from the input vertex to the
corresponding output vertex.
The only “interesting” work done by the geometry shader is computing and
emitting a
gl_Layer
value for the primitive.
The following geometry shader, using this extension, is equivalent:
#extension GL_NV_geometry_shader_passthrough : require

layout(triangles) in;
// No output primitive layout qualifiers required.

// Redeclare gl_PerVertex to pass through "gl_Position".
layout(passthrough) in gl_PerVertex {
vec4 gl_Position;
} gl_in[];

// Declare "Inputs" with "passthrough" to automatically copy members.
layout(passthrough) in Inputs {
vec2 texcoord;
vec4 baseColor;
} v_in[];

// No output block declaration required.

void main()
// The shader simply computes and writes gl_Layer. We do not
// loop over three vertices or call EmitVertex().
gl_Layer = compute_layer();
Version History
Revision 1, 2017-02-15 (Daniel Koch)
Internal revisions
VK_NV_inherited_viewport_scissor
Name String
VK_NV_inherited_viewport_scissor
Extension Type
Device extension
Registered Extension Number
279
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
David Zhao Akeley
akeley98
Other Extension Metadata
Last Modified Date
2021-02-04
Contributors
David Zhao Akeley, NVIDIA
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Christoph Kubisch, NVIDIA
Description
This extension adds the ability for a secondary command buffer to inherit
the dynamic viewport and scissor state from a primary command buffer, or a
previous secondary command buffer executed within the same
vkCmdExecuteCommands
call.
It addresses a frequent scenario in applications that deal with window
resizing and want to improve utilization of reusable secondary command
buffers.
The functionality is provided through
VkCommandBufferInheritanceViewportScissorInfoNV
Viewport inheritance is effectively limited to the 2D rectangle; secondary
command buffers must re-specify the inherited depth range values.
New Structures
Extending
VkCommandBufferInheritanceInfo
VkCommandBufferInheritanceViewportScissorInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceInheritedViewportScissorFeaturesNV
New Enum Constants
VK_NV_INHERITED_VIEWPORT_SCISSOR_EXTENSION_NAME
VK_NV_INHERITED_VIEWPORT_SCISSOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_VIEWPORT_SCISSOR_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INHERITED_VIEWPORT_SCISSOR_FEATURES_NV
Issues
(1) Why are viewport depth values configured in the
VkCommandBufferInheritanceViewportScissorInfoNV
struct, rather than by
vkCmd…
function?
DISCUSSION
We considered both adding a new
vkCmdSetViewportDepthNV
function, and
modifying
vkCmdSetViewport
to ignore the
width
, and
height
values when called with a secondary command
buffer that activates this extension.
The primary design considerations for this extension are debuggability and
easy integration into existing applications.
The main issue with adding a new
vkCmdSetViewportDepthNV
function is
reducing ease-of-integration.
A new function pointer will have to be loaded, but more importantly, a new
function would require changes to be supported in graphics debuggers; this
would delay widespread adoption of the extension.
The proposal to modify
vkCmdSetViewport
would avoid these issues.
However, we expect that the intent of applications using this extension is
to have the viewport values used for drawing exactly match the inherited
values; thus, it would be better for debuggability if no function for
modifying the viewport depth alone is provided.
By specifying viewport depth values when starting secondary command buffer
recording, and requiring the specified depth values to match the inherited
depth values, we allow for validation layers that flag depth changes as
errors.
This design also better matches the hardware model.
In fact, there is no need to re-execute a depth-setting command.
The graphics device retains the viewport depth state; it is the CPU-side
state of
VkCommandBuffer
that must be re-initialized.
(2) Why are viewport depth values specified as a partial
VkViewport
struct, rather than a leaner depth-only struct?
DISCUSSION
We considered adding a new
VkViewportDepthNV
struct containing only
minDepth
and
maxDepth
However, as application developers would need to maintain both a
VK_NV_inherited_viewport_scissor
code path and a fallback code path (at
least in the short term), we ultimately chose to continue using the existing
VkViewport
structure.
Doing so would allow application developers to reuse the same
VkViewport
array for both code paths, rather than constructing
separate
VkViewportDepthNV
and
VkViewport
arrays for each code
path.
Version History
Revision 1, 2020-02-04 (David Zhao Akeley)
Internal revisions
VK_NV_linear_color_attachment
Name String
VK_NV_linear_color_attachment
Extension Type
Device extension
Registered Extension Number
431
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
Contact
sourav parmar
souravpNV
Other Extension Metadata
Last Modified Date
2021-12-02
Interactions and External Dependencies
This extension requires
VK_KHR_format_feature_flags2
Contributors
Pat Brown, NVIDIA
Piers Daniell, NVIDIA
Sourav Parmar, NVIDIA
Description
This extension expands support for using
VK_IMAGE_TILING_LINEAR
images
as color attachments when all the color attachments in the render pass
instance have
VK_IMAGE_TILING_LINEAR
tiling.
This extension adds a new flag bit
VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV
that extends the
existing
VkFormatFeatureFlagBits2KHR
bits.
This flag
can
be set for renderable color formats in the
VkFormatProperties3KHR
::
linearTilingFeatures
format properties
structure member.
Formats with the
VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV
flag
may
be used as color attachments as long as all the color attachments
in the render pass instance have
VK_IMAGE_TILING_LINEAR
tiling, and
the formats their images views are created with have
VkFormatProperties3KHR
::
linearTilingFeatures
which include
VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV
This extension supports both dynamic rendering and traditional render
passes.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceLinearColorAttachmentFeaturesNV
New Enum Constants
VK_NV_LINEAR_COLOR_ATTACHMENT_EXTENSION_NAME
VK_NV_LINEAR_COLOR_ATTACHMENT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINEAR_COLOR_ATTACHMENT_FEATURES_NV
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV
Version History
Revision 1, 2021-11-29 (sourav parmar)
Initial draft
VK_NV_low_latency
Name String
VK_NV_low_latency
Extension Type
Device extension
Registered Extension Number
311
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Charles Hansen
cshansen
Other Extension Metadata
Last Modified Date
2023-02-10
Contributors
Charles Hansen, NVIDIA
Description
This extension adds the
VkQueryLowLatencySupportNV
structure, a
structure used to query support for NVIDIA Reflex.
New Structures
Extending
VkSemaphoreCreateInfo
VkQueryLowLatencySupportNV
New Enum Constants
VK_NV_LOW_LATENCY_EXTENSION_NAME
VK_NV_LOW_LATENCY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_QUERY_LOW_LATENCY_SUPPORT_NV
Issues
1) Why does
VkQueryLowLatencySupportNV
have output parameters in an
input chain?
RESOLVED
: We are stuck with this for legacy reasons - we are aware this is
bad behavior and this should not be used as a precedent for future
extensions.
Version History
Revision 1, 2023-02-10 (Charles Hansen)
Internal revisions
VK_NV_low_latency2
Name String
VK_NV_low_latency2
Extension Type
Device extension
Registered Extension Number
506
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.2
or
VK_KHR_timeline_semaphore
and
VK_KHR_present_id
or
VK_KHR_present_id2
Contact
Charles Hansen
cshansen
Other Extension Metadata
Last Modified Date
2023-09-25
Contributors
Charles Hansen, NVIDIA
Liam Middlebrook, NVIDIA
Lionel Duc, NVIDIA
James Jones, NVIDIA
Eric Sullivan, NVIDIA
New Commands
vkGetLatencyTimingsNV
vkLatencySleepNV
vkQueueNotifyOutOfBandNV
vkSetLatencyMarkerNV
vkSetLatencySleepModeNV
New Structures
VkGetLatencyMarkerInfoNV
VkLatencySleepInfoNV
VkLatencySleepModeInfoNV
VkLatencyTimingsFrameReportNV
VkOutOfBandQueueTypeInfoNV
VkSetLatencyMarkerInfoNV
Extending
VkSubmitInfo
VkSubmitInfo2
VkLatencySubmissionPresentIdNV
Extending
VkSurfaceCapabilities2KHR
VkLatencySurfaceCapabilitiesNV
Extending
VkSwapchainCreateInfoKHR
VkSwapchainLatencyCreateInfoNV
New Enums
VkLatencyMarkerNV
VkOutOfBandQueueTypeNV
New Enum Constants
VK_NV_LOW_LATENCY_2_EXTENSION_NAME
VK_NV_LOW_LATENCY_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_GET_LATENCY_MARKER_INFO_NV
VK_STRUCTURE_TYPE_LATENCY_SLEEP_INFO_NV
VK_STRUCTURE_TYPE_LATENCY_SLEEP_MODE_INFO_NV
VK_STRUCTURE_TYPE_LATENCY_SUBMISSION_PRESENT_ID_NV
VK_STRUCTURE_TYPE_LATENCY_SURFACE_CAPABILITIES_NV
VK_STRUCTURE_TYPE_LATENCY_TIMINGS_FRAME_REPORT_NV
VK_STRUCTURE_TYPE_OUT_OF_BAND_QUEUE_TYPE_INFO_NV
VK_STRUCTURE_TYPE_SET_LATENCY_MARKER_INFO_NV
VK_STRUCTURE_TYPE_SWAPCHAIN_LATENCY_CREATE_INFO_NV
Description
This extension gives applications timing suggestions on when to start the
recording of new frames to reduce the latency between input sampling and
frame presentation.
Applications can accomplish this through the extension by calling
vkSetLatencySleepModeNV
to allow the driver to pace a given swapchain,
then calling
vkLatencySleepNV
before input sampling to delay the start
of the CPU side work.
Additional methods and structures are provided to give insight into the
latency pipeline of an application through the latency markers.
VK_NV_low_latency
provides legacy support for applications that
make use of the NVIDIA Reflex SDK whereas new implementations should use the
VK_NV_low_latency2
extension.
Issues
1) How does Low Latency 2 work with applications that utilize device groups?
Low Latency 2 does not support device groups.
Version History
Revision 2, 2023-11-15 (Charles Hansen)
Update vkGetLatencyTimingsNV.
This is a breaking API change which brings behavior in line with other
array querying commands.
More background can be found in
Revision 1, 2023-09-25 (Charles Hansen)
Internal revisions
VK_NV_mesh_shader
Name String
VK_NV_mesh_shader
Extension Type
Device extension
Registered Extension Number
203
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_AMD_draw_indirect_count
Interacts with VK_EXT_device_generated_commands
Interacts with VK_KHR_draw_indirect_count
SPIR-V Dependencies
SPV_NV_mesh_shader
Contact
Christoph Kubisch
pixeljetstream
Other Extension Metadata
Last Modified Date
2018-07-19
Interactions and External Dependencies
This extension provides API support for
GLSL_NV_mesh_shader
Contributors
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Piers Daniell, NVIDIA
Pierre Boudier, NVIDIA
Description
This extension provides a new mechanism allowing applications to generate
collections of geometric primitives via programmable mesh shading.
It is an alternative to the existing programmable primitive shading
pipeline, which relied on generating input primitives by a fixed function
assembler as well as fixed function vertex fetch.
There are new programmable shader types — the task and mesh shader — to
generate these collections to be processed by fixed-function primitive
assembly and rasterization logic.
When task and mesh shaders are dispatched, they replace the core
pre-rasterization stages
including vertex array attribute fetching, vertex shader processing,
tessellation, and geometry shader processing.
This extension also adds support for the following SPIR-V extension in
Vulkan:
SPV_NV_mesh_shader
New Commands
vkCmdDrawMeshTasksIndirectNV
vkCmdDrawMeshTasksNV
If
Vulkan Version 1.2
or
VK_KHR_draw_indirect_count
or
VK_AMD_draw_indirect_count
is supported:
vkCmdDrawMeshTasksIndirectCountNV
New Structures
VkDrawMeshTasksIndirectCommandNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMeshShaderFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMeshShaderPropertiesNV
New Enum Constants
VK_NV_MESH_SHADER_EXTENSION_NAME
VK_NV_MESH_SHADER_SPEC_VERSION
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_MESH_SHADER_BIT_NV
VK_PIPELINE_STAGE_TASK_SHADER_BIT_NV
Extending
VkShaderStageFlagBits
VK_SHADER_STAGE_MESH_BIT_NV
VK_SHADER_STAGE_TASK_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV
If
VK_EXT_device_generated_commands
is supported:
Extending
VkIndirectCommandsTokenTypeEXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_COUNT_NV_EXT
VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_NV_EXT
New or Modified Built-In Variables
TaskCountNV
PrimitiveCountNV
PrimitiveIndicesNV
ClipDistancePerViewNV
CullDistancePerViewNV
LayerPerViewNV
MeshViewCountNV
MeshViewIndicesNV
(modified)
Position
(modified)
PointSize
(modified)
ClipDistance
(modified)
CullDistance
(modified)
PrimitiveId
(modified)
Layer
(modified)
ViewportIndex
(modified)
WorkgroupSize
(modified)
WorkgroupId
(modified)
LocalInvocationId
(modified)
GlobalInvocationId
(modified)
LocalInvocationIndex
(modified)
DrawIndex
(modified)
ViewportMaskNV
(modified)
PositionPerViewNV
(modified)
ViewportMaskPerViewNV
New SPIR-V Capability
MeshShadingNV
Issues
How to name this extension?
RESOLVED
: VK_NV_mesh_shader
Other options considered:
VK_NV_mesh_shading
VK_NV_programmable_mesh_shading
VK_NV_primitive_group_shading
VK_NV_grouped_drawing
Do we need a new VkPrimitiveTopology?
RESOLVED
: No.
We skip the InputAssembler stage.
Should we allow Instancing?
RESOLVED
: No.
There is no fixed function input, other than the IDs.
However, allow offsetting with a “first” value.
Should we use existing vkCmdDraw or introduce new functions?
RESOLVED
: Introduce new functions.
New functions make it easier to separate from “programmable primitive
shading” chapter, less “dual use” language about existing functions
having alternative behavior.
The text around the existing “draws” is heavily based around emitting
vertices.
If new functions, how to name?
RESOLVED
: CmdDrawMeshTasks*
Other options considered:
CmdDrawMeshed
CmdDrawTasked
CmdDrawGrouped
Should VK_SHADER_STAGE_ALL_GRAPHICS be updated to include the new stages?
RESOLVED
: No.
If an application were to be recompiled with headers that include additional
shader stage bits in VK_SHADER_STAGE_ALL_GRAPHICS, then the previously valid
application would no longer be valid on implementations that do not support
mesh or task shaders.
This means the change would not be backwards compatible.
It is too bad VkShaderStageFlagBits does not have a dedicated “all
supported graphics stages” bit like VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT,
which would have avoided this problem.
Version History
Revision 1, 2018-07-19 (Christoph Kubisch, Daniel Koch)
Internal revisions
VK_NV_optical_flow
Name String
VK_NV_optical_flow
Extension Type
Device extension
Registered Extension Number
465
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_format_feature_flags2
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
Contact
Carsten Rohde
crohde
Other Extension Metadata
Last Modified Date
2022-09-26
Contributors
Carsten Rohde, NVIDIA
Vipul Parashar, NVIDIA
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Description
Optical flow are fundamental algorithms in computer vision (CV) area.
This extension allows applications to estimate 2D displacement of pixels
between two frames.
This extension is designed to be used with upcoming NVIDIA Optical Flow SDK
Version 5 which will be available on NVIDIA Developer webpage.
New Object Types
VkOpticalFlowSessionNV
New Commands
vkBindOpticalFlowSessionImageNV
vkCmdOpticalFlowExecuteNV
vkCreateOpticalFlowSessionNV
vkDestroyOpticalFlowSessionNV
vkGetPhysicalDeviceOpticalFlowImageFormatsNV
New Structures
VkOpticalFlowExecuteInfoNV
VkOpticalFlowImageFormatPropertiesNV
VkOpticalFlowSessionCreateInfoNV
Extending
VkOpticalFlowSessionCreateInfoNV
VkOpticalFlowSessionCreatePrivateDataInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceOpticalFlowFeaturesNV
Extending
VkPhysicalDeviceImageFormatInfo2
VkImageCreateInfo
VkOpticalFlowImageFormatInfoNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceOpticalFlowPropertiesNV
New Enums
VkOpticalFlowExecuteFlagBitsNV
VkOpticalFlowGridSizeFlagBitsNV
VkOpticalFlowPerformanceLevelNV
VkOpticalFlowSessionBindingPointNV
VkOpticalFlowSessionCreateFlagBitsNV
VkOpticalFlowUsageFlagBitsNV
New Bitmasks
VkOpticalFlowExecuteFlagsNV
VkOpticalFlowGridSizeFlagsNV
VkOpticalFlowSessionCreateFlagsNV
VkOpticalFlowUsageFlagsNV
New Enum Constants
VK_NV_OPTICAL_FLOW_EXTENSION_NAME
VK_NV_OPTICAL_FLOW_SPEC_VERSION
Extending
VkAccessFlagBits2
VK_ACCESS_2_OPTICAL_FLOW_READ_BIT_NV
VK_ACCESS_2_OPTICAL_FLOW_WRITE_BIT_NV
Extending
VkFormat
VK_FORMAT_R16G16_S10_5_NV
VK_FORMAT_R16G16_SFIXED5_NV
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_OPTICAL_FLOW_COST_BIT_NV
VK_FORMAT_FEATURE_2_OPTICAL_FLOW_IMAGE_BIT_NV
VK_FORMAT_FEATURE_2_OPTICAL_FLOW_VECTOR_BIT_NV
Extending
VkObjectType
VK_OBJECT_TYPE_OPTICAL_FLOW_SESSION_NV
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_OPTICAL_FLOW_BIT_NV
Extending
VkQueueFlagBits
VK_QUEUE_OPTICAL_FLOW_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_OPTICAL_FLOW_EXECUTE_INFO_NV
VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV
VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_NV
VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_INFO_NV
VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_PRIVATE_DATA_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_PROPERTIES_NV
Examples
// Example querying available input formats
VkOpticalFlowImageFormatInfoNV ofFormatInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV };
ofFormatInfo.usage = VK_OPTICAL_FLOW_USAGE_INPUT_BIT_NV;

uint32_t count = 0;
vkGetPhysicalDeviceOpticalFlowImageFormatsNV(physicalDevice, &ofFormatInfo, &count, NULL);
VkOpticalFlowImageFormatPropertiesNV* fmt = new VkOpticalFlowImageFormatPropertiesNV[count];
memset(fmt, 0, count * sizeof(VkOpticalFlowImageFormatPropertiesNV));
for (uint32_t i = 0; i < count; i++) {
fmt[i].sType = VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_NV;
vkGetPhysicalDeviceOpticalFlowImageFormatsNV(physicalDevice, &ofFormatInfo, &count, fmt);

// Pick one of the available formats
VkFormat inputFormat = fmt[0].format;

// Check feature support for optimal tiling
VkFormatProperties3 formatProperties3 = { VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3 };
VkFormatProperties2 formatProperties2 = { VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2, &formatProperties3 };
vkGetPhysicalDeviceFormatProperties2(physicalDevice, inputFormat, &formatProperties2);
if (!(formatProperties3.optimalTilingFeatures & VK_FORMAT_FEATURE_2_OPTICAL_FLOW_IMAGE_BIT_NV)) {
return false;

// Check support for image creation parameters
VkPhysicalDeviceImageFormatInfo2 imageFormatInfo2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2, &ofFormatInfo };
imageFormatInfo2.format = inputFormat;
imageFormatInfo2.type = VK_IMAGE_TYPE_2D;
imageFormatInfo2.tiling = VK_IMAGE_TILING_OPTIMAL;
imageFormatInfo2.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT;

VkImageFormatProperties2 imageFormatProperties2 = { VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2 };
if (vkGetPhysicalDeviceImageFormatProperties2(physicalDevice, &imageFormatInfo2, &imageFormatProperties2) != VK_SUCCESS) {
return false;

VkImageCreateInfo imageCreateInfo = { VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO, &ofFormatInfo };
imageCreateInfo.imageType = VK_IMAGE_TYPE_2D;
imageCreateInfo.format = inputFormat;
imageCreateInfo.extent = { width, height, (uint32_t)1};
imageCreateInfo.mipLevels = 1;
imageCreateInfo.arrayLayers = 1;
imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT | VK_IMAGE_USAGE_TRANSFER_DST_BIT;
imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;

vkCreateImage(device, &imageCreateInfo, NULL, &input);
"allocate memory, bind image, create view"

"do the same for reference and output"

// Create optical flow session
VkOpticalFlowSessionCreateInfoNV sessionCreateInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_INFO_NV };
sessionCreateInfo.width = width;
sessionCreateInfo.height = height;
sessionCreateInfo.imageFormat = inputFormat;
sessionCreateInfo.flowVectorFormat = outputFormat;
sessionCreateInfo.outputGridSize = VK_OPTICAL_FLOW_GRID_SIZE_4X4_BIT_NV;
sessionCreateInfo.performanceLevel = VK_OPTICAL_FLOW_PERFORMANCE_LEVEL_SLOW_NV;
VkOpticalFlowSessionNV session;
vkCreateOpticalFlowSessionNV(device, &sessionCreateInfo, NULL, &session);

"allocate command buffer"

"transfer images to VK_PIPELINE_STAGE_2_OPTICAL_FLOW_BIT_NV"
"transfer input images to VK_ACCESS_2_OPTICAL_FLOW_READ_BIT_NV and output image to VK_ACCESS_2_OPTICAL_FLOW_WRITE_BIT_NV"

vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_INPUT_NV, inputView, VK_IMAGE_LAYOUT_GENERAL);
vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_REFERENCE_NV, refView, VK_IMAGE_LAYOUT_GENERAL);
vkBindOpticalFlowSessionImageNV(device, session, VK_OPTICAL_FLOW_SESSION_BINDING_POINT_FLOW_VECTOR_NV, outputView, VK_IMAGE_LAYOUT_GENERAL);

VkOpticalFlowExecuteInfoNV opticalFlowExecuteInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_EXECUTE_INFO_NV };
vkCmdOpticalFlowExecuteNV(cmd, session, &opticalFlowExecuteInfo);

"submit command buffer"
Version History
Revision 1, 2022-09-26 (Carsten Rohde)
Internal revisions
VK_NV_partitioned_acceleration_structure
Name String
VK_NV_partitioned_acceleration_structure
Extension Type
Device extension
Registered Extension Number
571
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
Contact
Vikram Kushwaha
vkushwaha
Extension Proposal
VK_NV_partitioned_acceleration_structure
Other Extension Metadata
Last Modified Date
2025-01-09
Contributors
Vikram Kushwaha, NVIDIA
Eric Werness, NVIDIA
Christoph Kubisch, NVIDIA
Jan Schmid, NVIDIA
Pyarelal Knowles, NVIDIA
Description
With an increase in scene complexity and expansive game worlds, the number
of instances has surged in ray tracing over the last few years.
The current Top Level Acceleration Structure (TLAS) API necessitates a full
rebuild of the entire data structure even when only a few instances are
modified.
This extension introduces Partitioned Top Level Acceleration Structures
(PTLAS) as an alternative to the existing TLAS.
PTLAS enables the efficient reuse of previously constructed parts of the
acceleration structure, resulting in much faster build times and supporting
a higher number of instances.
New Commands
vkCmdBuildPartitionedAccelerationStructuresNV
vkGetPartitionedAccelerationStructuresBuildSizesNV
New Structures
VkBuildPartitionedAccelerationStructureIndirectCommandNV
VkBuildPartitionedAccelerationStructureInfoNV
VkPartitionedAccelerationStructureInstancesInputNV
VkPartitionedAccelerationStructureUpdateInstanceDataNV
VkPartitionedAccelerationStructureWriteInstanceDataNV
VkPartitionedAccelerationStructureWritePartitionTranslationDataNV
Extending
VkPartitionedAccelerationStructureInstancesInputNV
VkPartitionedAccelerationStructureFlagsNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePartitionedAccelerationStructureFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePartitionedAccelerationStructurePropertiesNV
Extending
VkWriteDescriptorSet
VkWriteDescriptorSetPartitionedAccelerationStructureNV
New Enums
VkPartitionedAccelerationStructureInstanceFlagBitsNV
VkPartitionedAccelerationStructureOpTypeNV
New Bitmasks
VkPartitionedAccelerationStructureInstanceFlagsNV
New Enum Constants
VK_NV_PARTITIONED_ACCELERATION_STRUCTURE_EXTENSION_NAME
VK_NV_PARTITIONED_ACCELERATION_STRUCTURE_SPEC_VERSION
VK_PARTITIONED_ACCELERATION_STRUCTURE_PARTITION_INDEX_GLOBAL_NV
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_PARTITIONED_ACCELERATION_STRUCTURE_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_BUILD_PARTITIONED_ACCELERATION_STRUCTURE_INFO_NV
VK_STRUCTURE_TYPE_PARTITIONED_ACCELERATION_STRUCTURE_FLAGS_NV
VK_STRUCTURE_TYPE_PARTITIONED_ACCELERATION_STRUCTURE_INSTANCES_INPUT_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PARTITIONED_ACCELERATION_STRUCTURE_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PARTITIONED_ACCELERATION_STRUCTURE_PROPERTIES_NV
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_PARTITIONED_ACCELERATION_STRUCTURE_NV
Version History
Revision 1, 2025-01-09 (Vikram Kushwaha)
Initial draft
VK_NV_present_barrier
Name String
VK_NV_present_barrier
Extension Type
Device extension
Registered Extension Number
293
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_surface
and
VK_KHR_get_surface_capabilities2
and
VK_KHR_swapchain
Contact
Liya Li
liyli
Other Extension Metadata
Last Modified Date
2022-05-16
Contributors
Liya Li, Nvidia
Martin Schwarzer, Nvidia
Andy Wolf, Nvidia
Ian Williams, Nvidia
Ben Morris, Nvidia
James Jones, Nvidia
Jeff Juliano, Nvidia
Description
This extension adds support for synchronizing corresponding presentation
requests across multiple swapchains using the
present barrier
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentBarrierFeaturesNV
Extending
VkSurfaceCapabilities2KHR
VkSurfaceCapabilitiesPresentBarrierNV
Extending
VkSwapchainCreateInfoKHR
VkSwapchainPresentBarrierCreateInfoNV
New Enum Constants
VK_NV_PRESENT_BARRIER_EXTENSION_NAME
VK_NV_PRESENT_BARRIER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_BARRIER_FEATURES_NV
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_PRESENT_BARRIER_NV
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_BARRIER_CREATE_INFO_NV
Issues
1) Is there a query interface to check if a swapchain is using the present
barrier?
RESOLVED
There is no such query interface.
When creating a swapchain, an application can specify to use the
present
barrier
, and if the swapchain is created successfully, this swapchain will
be using the present barrier.
2) Do we need an extra interface to set up the present barrier across
distributed systems?
RESOLVED
If the required hardware is presented in the system, and all settings for
the physical synchronization with other systems are set up, an
implementation manages the configuration automatically when creating a
swapchain, without any extra calls from the application.
Version History
Revision 1, 2022-07-20
Initial version
VK_NV_present_metering
Name String
VK_NV_present_metering
Extension Type
Device extension
Registered Extension Number
614
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Charles Hansen
chansen
Other Extension Metadata
Last Modified Date
2025-01-08
Provisional
*This extension is
provisional
and
should
not be used in production
applications.
The functionality defined by this extension
may
change in ways that break
backwards compatibility between revisions, and before the final release of
the non-provisional version of this extension.
Contributors
Charles Hansen, NVIDIA
Lionel Duc, NVIDIA
Description
This extension is used to evenly meter presents.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentMeteringFeaturesNV
Extending
VkPresentInfoKHR
VkSetPresentConfigNV
New Enum Constants
VK_NV_PRESENT_METERING_EXTENSION_NAME
VK_NV_PRESENT_METERING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_METERING_FEATURES_NV
VK_STRUCTURE_TYPE_SET_PRESENT_CONFIG_NV
Issues
Version History
Revision 1, 2025-01-08 (Charles Hansen)
Internal revisions
VK_NV_push_constant_bank
Name String
VK_NV_push_constant_bank
Extension Type
Device extension
Registered Extension Number
581
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_NV_push_constant_bank
Contact
Vassili Nikolaev
vasnik1
Extension Proposal
VK_NV_push_constant_bank
Other Extension Metadata
Last Modified Date
2025-09-15
Contributors
Pat Brown, NVIDIA
Piers Daniell, NVIDIA
Rodrigo Locatti, NVIDIA
Daniel Story, Nintendo
Description
The
VK_NV_push_constant_bank
extension allows applications to specify
a bank and offset for push constants, enabling more flexible push constant
management in descriptor heap scenarios where shaders are able to access
different root descriptors.
Traditional push constants are placed in a default location, but this
extension allows applications to specify which hardware constant bank to use
and at what offset within that bank.
This provides greater control over memory layout and enables more efficient
use of hardware resources in advanced descriptor heap configurations.
The extension integrates with
VK_EXT_descriptor_heap
by allowing
VkPushConstantBankInfoNV
structures to be chained to
VkDescriptorSetAndBindingMappingEXT
VkPushDataInfoEXT
VkPushConstantsInfo
, or
VkIndirectCommandsLayoutTokenEXT
structures, specifying the hardware bank where push constants should be
placed as part of the descriptor heap mapping configuration or push data
operations.
Key features include:
Bank and offset specification for push constant placement
Integration with descriptor heap mapping through structure chaining
Support for GLSL shader qualifiers for bank and offset specification in
SPIR-V
Validation of bank bounds and alignment requirements
Compatibility with existing push constant API
The number of available push constant banks is implementation-dependent and
can be queried through separate limits in
VkPhysicalDevicePushConstantBankPropertiesNV
maxGraphicsPushConstantBanks
and
maxComputePushConstantBanks
for
non-descriptor heap usage, and
maxGraphicsPushDataBanks
and
maxComputePushDataBanks
for descriptor heap scenarios.
Applications must ensure bank indices remain within the appropriate
implementation-defined range based on the shader type and usage context.
Shader support for banks and member offsets are defined by the
SPV_NV_push_constant_bank
SPIR-V extension, which can be used with the
GLSL_NV_push_constant_bank
GLSL extension.
New SPIR-V Capabilities
PushConstantBanksNV
New SPIR-V Decorations
BankNV
MemberOffsetNV
New Structures
Extending
VkDescriptorSetAndBindingMappingEXT
VkPushDataInfoEXT
VkPushConstantsInfo
VkIndirectCommandsLayoutTokenEXT
VkPushConstantBankInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePushConstantBankFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePushConstantBankPropertiesNV
New Enum Constants
VK_NV_PUSH_CONSTANT_BANK_EXTENSION_NAME
VK_NV_PUSH_CONSTANT_BANK_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_CONSTANT_BANK_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_CONSTANT_BANK_PROPERTIES_NV
VK_STRUCTURE_TYPE_PUSH_CONSTANT_BANK_INFO_NV
Issues
None.
Version History
Revision 1, 2025-09-15 (NVIDIA Vassili Nikolaev)
Initial draft
VK_NV_raw_access_chains
Name String
VK_NV_raw_access_chains
Extension Type
Device extension
Registered Extension Number
556
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_raw_access_chains
Contact
Rodrigo Locatti
rlocatti
Other Extension Metadata
Last Modified Date
2023-12-04
Interactions and External Dependencies
This extension requires
SPV_NV_raw_access_chains
Contributors
Hans-Kristian Arntzen, Valve
Rodrigo Locatti, NVIDIA
Description
This extension allows the use of the
SPV_NV_raw_access_chains
extension in
SPIR-V shader modules.
This enables SPIR-V producers to efficiently implement interfaces similar to
Direct3D structured buffers and byte address buffers, allowing shaders
compiled from an HLSL source to generate more efficient code.
New SPIR-V Capabilities
RawAccessChainsNV
Version History
Revision 1, 2023-12-04 (Rodrigo Locatti)
Initial revision
VK_NV_ray_tracing_linear_swept_spheres
Name String
VK_NV_ray_tracing_linear_swept_spheres
Extension Type
Device extension
Registered Extension Number
430
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
SPIR-V Dependencies
SPV_NV_linear_swept_spheres
Contact
Vikram Kushwaha
vkushwaha
Extension Proposal
VK_NV_ray_tracing_linear_swept_spheres
Other Extension Metadata
Last Modified Date
2025-01-03
Interactions and External Dependencies
This extension requires
SPV_NV_linear_swept_spheres
This extension provides API support for
GL_NV_linear_swept_spheres
Contributors
Vikram Kushwaha, NVIDIA
Eric Werness, NVIDIA
Daniel Koch, NVIDIA
Ashwin Lele, NVIDIA
Nathan Morrical, NVIDIA
Description
This extension adds two new primitives for ray tracing: a sphere primitive
and a linear swept sphere (LSS) primitive.
The purpose of the LSS primitive is to enable rendering of high quality hair
and fur using a compact primitive representation encoded in the acceleration
structure.
Sphere primitives are defined by a position and a radius and are a subset of
LSS, but are useful in their own right, for example for particle systems.
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_linear_swept_spheres
New Structures
Extending
VkAccelerationStructureGeometryKHR
VkAccelerationStructureGeometryLinearSweptSpheresDataNV
VkAccelerationStructureGeometrySpheresDataNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingLinearSweptSpheresFeaturesNV
New Enums
VkRayTracingLssIndexingModeNV
VkRayTracingLssPrimitiveEndCapsModeNV
New Enum Constants
VK_NV_RAY_TRACING_LINEAR_SWEPT_SPHERES_EXTENSION_NAME
VK_NV_RAY_TRACING_LINEAR_SWEPT_SPHERES_SPEC_VERSION
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_RADIUS_BUFFER_BIT_NV
Extending
VkGeometryTypeKHR
VK_GEOMETRY_TYPE_LINEAR_SWEPT_SPHERES_NV
VK_GEOMETRY_TYPE_SPHERES_NV
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RAY_TRACING_ALLOW_SPHERES_AND_LINEAR_SWEPT_SPHERES_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_LINEAR_SWEPT_SPHERES_DATA_NV
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_SPHERES_DATA_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_LINEAR_SWEPT_SPHERES_FEATURES_NV
New or Modified Built-In Variables
HitIsSphereNV
HitIsLSSNV
HitSpherePositionNV
HitSphereRadiusNV
HitLSSPositionsNV
HitLSSRadiiNV
New SPIR-V Capabilities
RayTracingSpheresGeometryNV
RayTracingLinearSweptSpheresGeometryNV
Version History
Revision 1, 2025-01-03 (Vikram Kushwaha)
Initial draft
VK_NV_ray_tracing_motion_blur
Name String
VK_NV_ray_tracing_motion_blur
Extension Type
Device extension
Registered Extension Number
328
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
SPIR-V Dependencies
SPV_NV_ray_tracing_motion_blur
Contact
Eric Werness
Other Extension Metadata
Last Modified Date
2021-06-16
Interactions and External Dependencies
This extension provides API support for
GL_NV_ray_tracing_motion_blur
Contributors
Eric Werness, NVIDIA
Ashwin Lele, NVIDIA
Description
Ray tracing support in the API provides an efficient mechanism to intersect
rays against static geometry, but rendering algorithms often want to support
motion, which is more efficiently supported with motion-specific algorithms.
This extension adds a set of mechanisms to support fast tracing of moving
geometry:
A ray pipeline trace call which takes a time parameter
Flags to enable motion support in an acceleration structure
Support for time-varying vertex positions in a geometry
Motion instances to move existing instances over time
The motion represented here is parameterized across a normalized timestep
between 0.0 and 1.0.
A motion trace using
OpTraceRayMotionNV
provides a time within that
normalized range to be used when intersecting that ray with geometry.
The geometry can be provided with motion by a combination of adding a second
vertex position for time of 1.0 using
VkAccelerationStructureGeometryMotionTrianglesDataNV
and providing
multiple transforms in the instance using
VkAccelerationStructureMotionInstanceNV
New Structures
VkAccelerationStructureMatrixMotionInstanceNV
VkAccelerationStructureMotionInstanceNV
VkAccelerationStructureSRTMotionInstanceNV
VkSRTDataNV
Extending
VkAccelerationStructureCreateInfoKHR
VkAccelerationStructureMotionInfoNV
Extending
VkAccelerationStructureGeometryTrianglesDataKHR
VkAccelerationStructureGeometryMotionTrianglesDataNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingMotionBlurFeaturesNV
New Unions
VkAccelerationStructureMotionInstanceDataNV
New Enums
VkAccelerationStructureMotionInstanceTypeNV
New Bitmasks
VkAccelerationStructureMotionInfoFlagsNV
VkAccelerationStructureMotionInstanceFlagsNV
New Enum Constants
VK_NV_RAY_TRACING_MOTION_BLUR_EXTENSION_NAME
VK_NV_RAY_TRACING_MOTION_BLUR_SPEC_VERSION
Extending
VkAccelerationStructureCreateFlagBitsKHR
VK_ACCELERATION_STRUCTURE_CREATE_MOTION_BIT_NV
Extending
VkBuildAccelerationStructureFlagBitsKHR
VK_BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_RAY_TRACING_ALLOW_MOTION_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_MOTION_TRIANGLES_DATA_NV
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MOTION_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MOTION_BLUR_FEATURES_NV
Issues
(1) What size is VkAccelerationStructureMotionInstanceNV?
Added a note on the structure size and made the stride explicit in the
language.
(2) Allow arrayOfPointers for motion TLAS?
Yes, with a packed encoding to minimize the amount of data sent for
metadata.
Version History
Revision 1, 2020-06-16 (Eric Werness, Ashwin Lele)
Initial external release
VK_NV_ray_tracing_validation
Name String
VK_NV_ray_tracing_validation
Extension Type
Device extension
Registered Extension Number
569
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Vikram Kushwaha
vkushwaha-nv
Extension Proposal
VK_NV_ray_tracing_validation
Other Extension Metadata
Last Modified Date
2024-03-04
Contributors
Vikram Kushwaha, NVIDIA
Eric Werness, NVIDIA
Piers Daniell, NVIDIA
Description
This extension adds support for performing ray tracing validation at an
implementation level.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingValidationFeaturesNV
New Enum Constants
VK_NV_RAY_TRACING_VALIDATION_EXTENSION_NAME
VK_NV_RAY_TRACING_VALIDATION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_VALIDATION_FEATURES_NV
Version History
Revision 1, 2024-03-04 (Vikram Kushwaha)
Initial draft
VK_NV_representative_fragment_test
Name String
VK_NV_representative_fragment_test
Extension Type
Device extension
Registered Extension Number
167
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Kedarnath Thangudu
kthangudu
Other Extension Metadata
Last Modified Date
2018-09-13
Contributors
Kedarnath Thangudu, NVIDIA
Christoph Kubisch, NVIDIA
Pierre Boudier, NVIDIA
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Description
This extension provides a new representative fragment test that allows
implementations to reduce the amount of rasterization and fragment
processing work performed for each point, line, or triangle primitive.
For any primitive that produces one or more fragments that pass all other
early fragment tests, the implementation is permitted to choose one or more
“representative” fragments for processing and discard all other fragments.
For draw calls rendering multiple points, lines, or triangles arranged in
lists, strips, or fans, the representative fragment test is performed
independently for each of those primitives.
This extension is useful for applications that use an early render pass to
determine the full set of primitives that would be visible in the final
scene.
In this render pass, such applications would set up a fragment shader that
enables early fragment tests and writes to an image or shader storage buffer
to record the ID of the primitive that generated the fragment.
Without this extension, the shader would record the ID separately for each
visible fragment of each primitive.
With this extension, fewer stores will be performed, particularly for large
primitives.
The representative fragment test has no effect if early fragment tests are
not enabled via the fragment shader.
The set of fragments discarded by the representative fragment test is
implementation-dependent and may vary from frame to frame.
In some cases, the representative fragment test may not discard any
fragments for a given primitive.
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkPipelineRepresentativeFragmentTestStateCreateInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRepresentativeFragmentTestFeaturesNV
New Enum Constants
VK_NV_REPRESENTATIVE_FRAGMENT_TEST_EXTENSION_NAME
VK_NV_REPRESENTATIVE_FRAGMENT_TEST_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_REPRESENTATIVE_FRAGMENT_TEST_FEATURES_NV
VK_STRUCTURE_TYPE_PIPELINE_REPRESENTATIVE_FRAGMENT_TEST_STATE_CREATE_INFO_NV
Issues
(1) Is the representative fragment test guaranteed to have any effect?
RESOLVED
: No.
As specified, we only guarantee that each primitive with at least one
fragment that passes prior tests will have one fragment passing the
representative fragment tests.
We do not guarantee that any particular fragment will fail the test.
In the initial implementation of this extension, the representative fragment
test is treated as an optimization that may be completely disabled for some
pipeline states.
This feature was designed for a use case where the fragment shader records
information on individual primitives using shader storage buffers or storage
images, with no writes to color or depth buffers.
(2) Will the set of fragments that pass the representative fragment test be
repeatable if you draw the same scene over and over again?
RESOLVED
: No.
The set of fragments that pass the representative fragment test is
implementation-dependent and may vary due to the timing of operations
performed by the GPU.
(3) What happens if you enable the representative fragment test with writes
to color and/or depth render targets enabled?
RESOLVED
: If writes to the color or depth buffer are enabled, they will be
performed for any fragments that survive the relevant tests.
Any fragments that fail the representative fragment test will not update
color buffers.
For the use cases intended for this feature, we do not expect color or depth
writes to be enabled.
(4) How do derivatives and automatic texture LOD computations work with the
representative fragment test enabled?
RESOLVED
: If a fragment shader uses derivative functions or texture
lookups using automatic LOD computation, derivatives will be computed
identically whether or not the representative fragment test is enabled.
For the use cases intended for this feature, we do not expect the use of
derivatives in the fragment shader.
Version History
Revision 2, 2018-09-13 (pbrown)
Add issues.
Revision 1, 2018-08-22 (Kedarnath Thangudu)
Internal Revisions
VK_NV_sample_mask_override_coverage
Name String
VK_NV_sample_mask_override_coverage
Extension Type
Device extension
Registered Extension Number
95
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_NV_sample_mask_override_coverage
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2016-12-08
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NV_sample_mask_override_coverage
Contributors
Daniel Koch, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_sample_mask_override_coverage
The extension provides access to the
OverrideCoverageNV
decoration
under the
SampleMaskOverrideCoverageNV
capability.
Adding this decoration to a variable with the
SampleMask
builtin
decoration allows the shader to modify the coverage mask and affect which
samples are used to process the fragment.
When using GLSL source-based shader languages, the
override_coverage
layout qualifier from
GL_NV_sample_mask_override_coverage
maps to the
OverrideCoverageNV
decoration.
To use the
override_coverage
layout qualifier in GLSL the
GL_NV_sample_mask_override_coverage
extension must be enabled.
Behavior is described in the
GL_NV_sample_mask_override_coverage
extension
spec.
New Enum Constants
VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_EXTENSION_NAME
VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_SPEC_VERSION
New Variable Decoration
OverrideCoverageNV in SampleMask
New SPIR-V Capabilities
SampleMaskOverrideCoverageNV
Version History
Revision 1, 2016-12-08 (Piers Daniell)
Internal revisions
VK_NV_scissor_exclusive
Name String
VK_NV_scissor_exclusive
Extension Type
Device extension
Registered Extension Number
206
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2023-01-18
IP Status
No known IP claims.
Interactions and External Dependencies
None
Contributors
Pat Brown, NVIDIA
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Daniel Koch, NVIDIA
Description
This extension adds support for an exclusive scissor test to Vulkan.
The exclusive scissor test behaves like the scissor test, except that the
exclusive scissor test fails for pixels inside the corresponding rectangle
and passes for pixels outside the rectangle.
If the same rectangle is used for both the scissor and exclusive scissor
tests, the exclusive scissor test will pass if and only if the scissor test
fails.
Version 2 of this extension introduces
VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV
and
vkCmdSetExclusiveScissorEnableNV
Applications that use this dynamic state must ensure the implementation
advertises at least
specVersion
of this extension.
New Commands
vkCmdSetExclusiveScissorEnableNV
vkCmdSetExclusiveScissorNV
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExclusiveScissorFeaturesNV
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportExclusiveScissorStateCreateInfoNV
New Enum Constants
VK_NV_SCISSOR_EXCLUSIVE_EXTENSION_NAME
VK_NV_SCISSOR_EXCLUSIVE_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV
VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXCLUSIVE_SCISSOR_FEATURES_NV
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_EXCLUSIVE_SCISSOR_STATE_CREATE_INFO_NV
Issues
1) For the scissor test, the viewport state must be created with a matching
number of scissor and viewport rectangles.
Should we have the same requirement for exclusive scissors?
RESOLVED
: For exclusive scissors, we relax this requirement and allow an
exclusive scissor rectangle count that is either zero or equal to the number
of viewport rectangles.
If you pass in an exclusive scissor count of zero, the exclusive scissor
test is treated as disabled.
Version History
Revision 2, 2023-01-18 (Piers Daniell)
Add dynamic state for explicit exclusive scissor enables
Revision 1, 2018-07-31 (Pat Brown)
Internal revisions
VK_NV_shader_atomic_float16_vector
Name String
VK_NV_shader_atomic_float16_vector
Extension Type
Device extension
Registered Extension Number
564
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_shader_atomic_fp16_vector
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2024-02-03
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_atomic_fp16_vector
Contributors
Jeff Bolz, NVIDIA
Description
This extension allows a shader to perform atomic add, min, max, and exchange
operations on 2- and 4-component vectors of float16.
Buffer, workgroup, and image storage classes are all supported.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderAtomicFloat16VectorFeaturesNV
New Enum Constants
VK_NV_SHADER_ATOMIC_FLOAT16_VECTOR_EXTENSION_NAME
VK_NV_SHADER_ATOMIC_FLOAT16_VECTOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT16_VECTOR_FEATURES_NV
Issues
None.
New SPIR-V Capabilities
AtomicFloat16VectorNV
Version History
Revision 1, 2024-02-03 (Jeff Bolz)
Internal revisions
VK_NV_shader_image_footprint
Name String
VK_NV_shader_image_footprint
Extension Type
Device extension
Registered Extension Number
205
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_shader_image_footprint
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2018-09-13
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_texture_footprint
Contributors
Pat Brown, NVIDIA
Chris Lentini, NVIDIA
Daniel Koch, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds Vulkan support for the
SPV_NV_shader_image_footprint
SPIR-V extension.
That SPIR-V extension provides a new instruction
OpImageSampleFootprintNV
allowing shaders to determine the set of
texels that would be accessed by an equivalent filtered texture lookup.
Instead of returning a filtered texture value, the instruction returns a
structure that can be interpreted by shader code to determine the footprint
of a filtered texture lookup.
This structure includes integer values that identify a small neighborhood of
texels in the image being accessed and a bitfield that indicates which
texels in that neighborhood would be used.
The structure also includes a bitfield where each bit identifies whether any
texel in a small aligned block of texels would be fetched by the texture
lookup.
The size of each block is specified by an access
granularity
provided by
the shader.
The minimum granularity supported by this extension is 2x2 (for 2D textures)
and 2x2x2 (for 3D textures); the maximum granularity is 256x256 (for 2D
textures) or 64x32x32 (for 3D textures).
Each footprint query returns the footprint from a single texture level.
When using minification filters that combine accesses from multiple mipmap
levels, shaders must perform separate queries for the two levels accessed
(“fine” and “coarse”).
The footprint query also returns a flag indicating if the texture lookup
would access texels from only one mipmap level or from two neighboring
levels.
This extension should be useful for multi-pass rendering operations that do
an initial expensive rendering pass to produce a first image that is then
used as a texture for a second pass.
If the second pass ends up accessing only portions of the first image (e.g.,
due to visibility), the work spent rendering the non-accessed portion of the
first image was wasted.
With this feature, an application can limit this waste using an initial pass
over the geometry in the second image that performs a footprint query for
each visible pixel to determine the set of pixels that it needs from the
first image.
This pass would accumulate an aggregate footprint of all visible pixels into
a separate “footprint image” using shader atomics.
Then, when rendering the first image, the application can kill all shading
work for pixels not in this aggregate footprint.
This extension has a number of limitations.
The
OpImageSampleFootprintNV
instruction only supports for two- and
three-dimensional textures.
Footprint evaluation only supports the CLAMP_TO_EDGE wrap mode; results are
poison for all other wrap modes.
Only a limited set of granularity values and that set does not support
separate coverage information for each texel in the original image.
When using SPIR-V generated from the OpenGL Shading Language, the new
instruction will be generated from code using the new
textureFootprint*NV
built-in functions from the
GL_NV_shader_texture_footprint
shading language extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderImageFootprintFeaturesNV
New Enum Constants
VK_NV_SHADER_IMAGE_FOOTPRINT_EXTENSION_NAME
VK_NV_SHADER_IMAGE_FOOTPRINT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_FOOTPRINT_FEATURES_NV
New SPIR-V Capability
ImageFootprintNV
Issues
(1) The footprint returned by the SPIR-V instruction is a structure that
includes an anchor, an offset, and a mask that represents a 8x8 or 4x4x4
neighborhood of texel groups.
But the bits of the mask are not stored in simple pitch order.
Why is the footprint built this way?
RESOLVED
: We expect that applications using this feature will want to use
a fixed granularity and accumulate coverage information from the returned
footprints into an aggregate “footprint image” that tracks the portions of
an image that would be needed by regular texture filtering.
If an application is using a two-dimensional image with 4x4 pixel
granularity, we expect that the footprint image will use 64-bit texels where
each bit in an 8x8 array of bits corresponds to coverage for a 4x4 block in
the original image.
Texel (0,0) in the footprint image would correspond to texels (0,0) through
(31,31) in the original image.
In the usual case, the footprint for a single access will fully contained in
a 32x32 aligned region of the original texture, which corresponds to a
single 64-bit texel in the footprint image.
In that case, the implementation will return an anchor coordinate pointing
at the single footprint image texel, an offset vector of (0,0), and a mask
whose bits are aligned with the bits in the footprint texel.
For this case, the shader can simply atomically OR the mask bits into the
contents of the footprint texel to accumulate footprint coverage.
In the worst case, the footprint for a single access spans multiple 32x32
aligned regions and may require updates to four separate footprint image
texels.
In this case, the implementation will return an anchor coordinate pointing
at the lower right footprint image texel and an offset will identify how
many “columns” and “rows” of the returned 8x8 mask correspond to
footprint texels to the left and above the anchor texel.
If the anchor is (2,3), the 64 bits of the returned mask are arranged
spatially as follows, where each 4x4 block is assigned a bit number that
matches its bit number in the footprint image texels:
+-------------------------+-------------------------+
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- 46 47 | 40 41 42 43 44 45 -- -- |
| -- -- -- -- -- -- 54 55 | 48 49 50 51 52 53 -- -- |
| -- -- -- -- -- -- 62 63 | 56 57 58 59 60 61 -- -- |
+-------------------------+-------------------------+
| -- -- -- -- -- -- 06 07 | 00 01 02 03 04 05 -- -- |
| -- -- -- -- -- -- 14 15 | 08 09 10 11 12 13 -- -- |
| -- -- -- -- -- -- 22 23 | 16 17 18 19 20 21 -- -- |
| -- -- -- -- -- -- 30 31 | 24 25 26 27 28 29 -- -- |
| -- -- -- -- -- -- 38 39 | 32 33 34 35 36 37 -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
| -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
+-------------------------+-------------------------+
To accumulate coverage for each of the four footprint image texels, a shader
can AND the returned mask with simple masks derived from the x and y offset
values and then atomically OR the updated mask bits into the contents of the
corresponding footprint texel.
uint64_t returnedMask = (uint64_t(footprint.mask.x) | (uint64_t(footprint.mask.y) << 32));
uint64_t rightMask = ((0xFF >> footprint.offset.x) * 0x0101010101010101UL);
uint64_t bottomMask = 0xFFFFFFFFFFFFFFFFUL >> (8 * footprint.offset.y);
uint64_t bottomRight = returnedMask & bottomMask & rightMask;
uint64_t bottomLeft = returnedMask & bottomMask & (~rightMask);
uint64_t topRight = returnedMask & (~bottomMask) & rightMask;
uint64_t topLeft = returnedMask & (~bottomMask) & (~rightMask);
(2) What should an application do to ensure maximum performance when
accumulating footprints into an aggregate footprint image?
RESOLVED
: We expect that the most common usage of this feature will be to
accumulate aggregate footprint coverage, as described in the previous issue.
Even if you ignore the anisotropic filtering case where the implementation
may return a granularity larger than that requested by the caller, each
shader invocation will need to use atomic functions to update up to four
footprint image texels for each LOD accessed.
Having each active shader invocation perform multiple atomic operations can
be expensive, particularly when neighboring invocations will want to update
the same footprint image texels.
Techniques can be used to reduce the number of atomic operations performed
when accumulating coverage include:
Have logic that detects returned footprints where all components of the
returned offset vector are zero.
In that case, the mask returned by the footprint function is guaranteed
to be aligned with the footprint image texels and affects only a single
footprint image texel.
Have fragment shaders communicate using built-in functions from the
VK_NV_shader_subgroup_partitioned
extension or other shader subgroup
extensions.
If you have multiple invocations in a subgroup that need to update the
same texel (x,y) in the footprint image, compute an aggregate footprint
mask across all invocations in the subgroup updating that texel and have
a single invocation perform an atomic operation using that aggregate
mask.
When the returned footprint spans multiple texels in the footprint
image, each invocation need to perform four atomic operations.
In the previous issue, we had an example that computed separate masks
for “topLeft”, “topRight”, “bottomLeft”, and “bottomRight”.
When the invocations in a subgroup have good locality, it might be the
case the “top left” for some invocations might refer to footprint
image texel (10,10), while neighbors might have their “top left”
texels at (11,10), (10,11), and (11,11).
If you compute separate masks for even/odd x and y values instead of
left/right or top/bottom, the “odd/odd” mask for all invocations in
the subgroup hold coverage for footprint image texel (11,11), which can
be updated by a single atomic operation for the entire subgroup.
Examples
TBD
Version History
Revision 2, 2018-09-13 (Pat Brown)
Add issue (2) with performance tips.
Revision 1, 2018-08-12 (Pat Brown)
Initial draft
VK_NV_shader_sm_builtins
Name String
VK_NV_shader_sm_builtins
Extension Type
Device extension
Registered Extension Number
155
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_shader_sm_builtins
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2019-05-28
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_sm_builtins
Contributors
Jeff Bolz, NVIDIA
Eric Werness, NVIDIA
Description
This extension provides the ability to determine device-specific properties
on NVIDIA GPUs.
It provides the number of streaming multiprocessors (SMs), the maximum
number of warps (subgroups) that can run on an SM, and shader builtins to
enable invocations to identify which SM and warp a shader invocation is
executing on.
This extension enables support for the SPIR-V
ShaderSMBuiltinsNV
capability.
These properties and built-ins
should
typically only be used for debugging
purposes.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderSMBuiltinsFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderSMBuiltinsPropertiesNV
New Enum Constants
VK_NV_SHADER_SM_BUILTINS_EXTENSION_NAME
VK_NV_SHADER_SM_BUILTINS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_PROPERTIES_NV
New or Modified Built-In Variables
WarpsPerSMNV
SMCountNV
WarpIDNV
SMIDNV
New SPIR-V Capabilities
ShaderSMBuiltinsNV
Issues
What should we call this extension?
RESOLVED
NV_shader_sm_builtins
Other options considered included:
NV_shader_smid
- but SMID is really easy to typo/confuse as SIMD.
NV_shader_sm_info
- but
Info
is typically reserved for input
structures
Version History
Revision 1, 2019-05-28 (Daniel Koch)
Internal revisions
VK_NV_shading_rate_image
Name String
VK_NV_shading_rate_image
Extension Type
Device extension
Registered Extension Number
165
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_shading_rate
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2019-07-18
Interactions and External Dependencies
This extension provides API support for
GL_NV_shading_rate_image
Contributors
Pat Brown, NVIDIA
Carsten Rohde, NVIDIA
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Mathias Schott, NVIDIA
Matthew Netsch, Qualcomm Technologies, Inc.
Description
This extension allows applications to use a variable shading rate when
processing fragments of rasterized primitives.
By default, Vulkan will spawn one fragment shader for each pixel covered by
a primitive.
In this extension, applications can bind a
shading rate image
that can be
used to vary the number of fragment shader invocations across the
framebuffer.
Some portions of the screen may be configured to spawn up to 16 fragment
shaders for each pixel, while other portions may use a single fragment
shader invocation for a 4x4 block of pixels.
This can be useful for use cases like eye tracking, where the portion of the
framebuffer that the user is looking at directly can be processed at high
frequency, while distant corners of the image can be processed at lower
frequency.
Each texel in the shading rate image represents a fixed-size rectangle in
the framebuffer, covering 16x16 pixels in the initial implementation of this
extension.
When rasterizing a primitive covering one of these rectangles, the Vulkan
implementation reads a texel in the bound shading rate image and looks up
the fetched value in a palette to determine a base shading rate.
In addition to the API support controlling rasterization, this extension
also adds Vulkan support for the
SPV_NV_shading_rate
extension to
SPIR-V.
That extension provides two fragment shader variable decorations that allow
fragment shaders to determine the shading rate used for processing the
fragment:
FragmentSizeNV
, which indicates the width and height of the set of
pixels processed by the fragment shader.
InvocationsPerPixel
, which indicates the maximum number of fragment
shader invocations that could be spawned for the pixel(s) covered by the
fragment.
When using SPIR-V in conjunction with the OpenGL Shading Language (GLSL),
the fragment shader capabilities are provided by the
GL_NV_shading_rate_image
language extension and correspond to the built-in
variables
gl_FragmentSizeNV
and
gl_InvocationsPerPixelNV
respectively.
New Commands
vkCmdBindShadingRateImageNV
vkCmdSetCoarseSampleOrderNV
vkCmdSetViewportShadingRatePaletteNV
New Structures
VkCoarseSampleLocationNV
VkCoarseSampleOrderCustomNV
VkShadingRatePaletteNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShadingRateImageFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShadingRateImagePropertiesNV
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportCoarseSampleOrderStateCreateInfoNV
VkPipelineViewportShadingRateImageStateCreateInfoNV
New Enums
VkCoarseSampleOrderTypeNV
VkShadingRatePaletteEntryNV
New Enum Constants
VK_NV_SHADING_RATE_IMAGE_EXTENSION_NAME
VK_NV_SHADING_RATE_IMAGE_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV
Extending
VkDynamicState
VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV
VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV
Extending
VkImageLayout
VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_PROPERTIES_NV
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV
Issues
(1) When using shading rates specifying “coarse” fragments covering
multiple pixels, we will generate a combined coverage mask that combines
the coverage masks of all pixels covered by the fragment.
By default, these masks are combined in an implementation-dependent
order.
Should we provide a mechanism allowing applications to query or specify
an exact order?
RESOLVED
: Yes, this feature is useful for cases where most of the fragment
shader can be evaluated once for an entire coarse fragment, but where some
per-pixel computations are also required.
For example, a per-pixel alpha test may want to kill all the samples for
some pixels in a coarse fragment.
This sort of test can be implemented using an output sample mask, but such a
shader would need to know which bit in the mask corresponds to each sample
in the coarse fragment.
We are including a mechanism to allow applications to specify the orders of
coverage samples for each shading rate and sample count, either as static
pipeline state or dynamically via a command buffer.
This portion of the extension has its own feature bit.
We will not be providing a query to determine the implementation-dependent
default ordering.
The thinking here is that if an application cares enough about the coarse
fragment sample ordering to perform such a query, it could instead just set
its own order, also using custom per-pixel sample locations if required.
(2) For the pipeline stage
VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV
, should we specify a
precise location in the pipeline the shading rate image is accessed (after
geometry shading, but before the early fragment tests) or leave it
under-specified in case there are other implementations that access the
image in a different pipeline location?
RESOLVED
We are specifying the pipeline stage to be between the final
pre-rasterization shader stage
VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT
) and before the first
stage used for fragment processing
VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT
), which seems to be the
natural place to access the shading rate image.
(3) How do centroid-sampled variables work with fragments larger than one
pixel?
RESOLVED
For single-pixel fragments, fragment shader inputs decorated with
Centroid
are sampled at an implementation-dependent location in the
intersection of the area of the primitive being rasterized and the area of
the pixel that corresponds to the fragment.
With multi-pixel fragments, we follow a similar pattern, using the
intersection of the primitive and the
set
of pixels corresponding to the
fragment.
One important thing to keep in mind when using such “coarse” shading rates
is that fragment attributes are sampled at the center of the fragment by
default, regardless of the set of pixels/samples covered by the fragment.
For fragments with a size of 4x4 pixels, this center location will be more
than two pixels (1.5 * sqrt(2)) away from the center of the pixels at the
corners of the fragment.
When rendering a primitive that covers only a small part of a coarse
fragment, sampling a color outside the primitive can produce overly bright
or dark color values if the color values have a large gradient.
To deal with this, an application can use centroid sampling on attributes
where “extrapolation” artifacts can lead to overly bright or dark pixels.
Note that this same problem also exists for multisampling with single-pixel
fragments, but is less severe because it only affects certain samples of a
pixel and such bright/dark samples may be averaged with other samples that
do not have a similar problem.
Version History
Revision 3, 2019-07-18 (Mathias Schott)
Fully list extension interfaces in this appendix.
Revision 2, 2018-09-13 (Pat Brown)
Miscellaneous edits preparing the specification for publication.
Revision 1, 2018-08-08 (Pat Brown)
Internal revisions
VK_NV_viewport_array2
Name String
VK_NV_viewport_array2
Extension Type
Device extension
Registered Extension Number
97
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_NV_viewport_array2
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2017-02-15
Interactions and External Dependencies
This extension provides API support for
GL_NV_viewport_array2
This extension requires the
geometryShader
and
multiViewport
features.
This extension interacts with the
tessellationShader
feature.
Contributors
Piers Daniell, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_viewport_array2
which allows a single primitive to be broadcast to multiple viewports and/or
multiple layers.
A new shader built-in output
ViewportMaskNV
is provided, which allows a
single primitive to be output to multiple viewports simultaneously.
Also, a new SPIR-V decoration is added to control whether the effective
viewport index is added into the variable decorated with the
Layer
built-in decoration.
These capabilities allow a single primitive to be output to multiple layers
simultaneously.
This extension allows variables decorated with the
Layer
and
ViewportIndex
built-ins to be exported from vertex or tessellation
shaders, using the
ShaderViewportIndexLayerNV
capability.
This extension adds a new
ViewportMaskNV
built-in decoration that is
available for output variables in vertex, tessellation evaluation, and
geometry shaders, and a new
ViewportRelativeNV
decoration that can be
added on variables decorated with
Layer
when using the
ShaderViewportMaskNV
capability.
When using GLSL source-based shading languages, the
gl_ViewportMask
[]
built-in output variable and
viewport_relative
layout qualifier from
GL_NV_viewport_array2
map to the
ViewportMaskNV
and
ViewportRelativeNV
decorations, respectively.
Behavior is described in the
GL_NV_viewport_array2
extension
specification.
The
ShaderViewportIndexLayerNV
capability is equivalent to the
ShaderViewportIndexLayerEXT
capability added by
VK_EXT_shader_viewport_index_layer
New Enum Constants
VK_NV_VIEWPORT_ARRAY2_EXTENSION_NAME
VK_NV_VIEWPORT_ARRAY2_SPEC_VERSION
VK_NV_VIEWPORT_ARRAY_2_EXTENSION_NAME
VK_NV_VIEWPORT_ARRAY_2_SPEC_VERSION
New or Modified Built-In Variables
(modified)
Layer
(modified)
ViewportIndex
ViewportMaskNV
New Variable Decoration
ViewportRelativeNV
in
Layer
New SPIR-V Capabilities
ShaderViewportIndexLayerNV
ShaderViewportMaskNV
Version History
Revision 1, 2017-02-15 (Daniel Koch)
Internal revisions
VK_NV_viewport_swizzle
Name String
VK_NV_viewport_swizzle
Extension Type
Device extension
Registered Extension Number
99
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2016-12-22
Interactions and External Dependencies
This extension requires
multiViewport
and
geometryShader
features to be useful.
Contributors
Daniel Koch, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension provides a new per-viewport swizzle that can modify the
position of primitives sent to each viewport.
New viewport swizzle state is added for each viewport, and a new position
vector is computed for each vertex by selecting from and optionally negating
any of the four components of the original position vector.
This new viewport swizzle is useful for a number of algorithms, including
single-pass cube map rendering (broadcasting a primitive to multiple faces
and reorienting the vertex position for each face) and voxel rasterization.
The per-viewport component remapping and negation provided by the swizzle
allows application code to re-orient three-dimensional geometry with a view
along any of the
, or
axes.
If a perspective projection and depth buffering is required,
1/W
buffering should be used, as described in the single-pass cube map rendering
example in the “Issues” section below.
New Structures
VkViewportSwizzleNV
Extending
VkPipelineViewportStateCreateInfo
VkPipelineViewportSwizzleStateCreateInfoNV
New Enums
VkViewportCoordinateSwizzleNV
New Bitmasks
VkPipelineViewportSwizzleStateCreateFlagsNV
New Enum Constants
VK_NV_VIEWPORT_SWIZZLE_EXTENSION_NAME
VK_NV_VIEWPORT_SWIZZLE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SWIZZLE_STATE_CREATE_INFO_NV
Issues
1) Where does viewport swizzling occur in the pipeline?
RESOLVED
: Despite being associated with the viewport, viewport swizzling
must happen prior to the viewport transform.
In particular, it needs to be performed before clipping and perspective
division.
The viewport mask expansion (
VK_NV_viewport_array2
) and the
viewport swizzle could potentially be performed before or after transform
feedback, but feeding back several viewports worth of primitives with
different swizzles does not seem particularly useful.
This specification applies the viewport mask and swizzle after transform
feedback, and makes primitive queries only count each primitive once.
2) Any interesting examples of how this extension,
VK_NV_viewport_array2
, and
VK_NV_geometry_shader_passthrough
can be used together in practice?
RESOLVED
: One interesting use case for this extension is for single-pass
rendering to a cube map.
In this example, the application would attach a cube map texture to a
layered FBO where the six cube faces are treated as layers.
Vertices are sent through the vertex shader without applying a projection
matrix, where the
gl_Position
output is
(x,y,z,1)
and the center
of the cube map is at
(0,0,0)
With unextended Vulkan, one could have a conventional instanced geometry
shader that looks something like the following:
layout(invocations = 6) in; // separate invocation per face
layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices = 3) out;

in Inputs {
vec2 texcoord;
vec3 normal;
vec4 baseColor;
} v[];

out Outputs {
vec2 texcoord;
vec3 normal;
vec4 baseColor;
};

void main()
int face = gl_InvocationID; // which face am I?

// Project gl_Position for each vertex onto the cube map face.
vec4 positions[3];
for (int i = 0; i < 3; i++) {
positions[i] = rotate(gl_in[i].gl_Position, face);

// If the primitive does not project onto this face, we are done.
if (shouldCull(positions)) {
return;

// Otherwise, emit a copy of the input primitive to the
// appropriate face (using gl_Layer).
for (int i = 0; i < 3; i++) {
gl_Layer = face;
gl_Position = positions[i];
texcoord = v[i].texcoord;
normal = v[i].normal;
baseColor = v[i].baseColor;
EmitVertex();
With passthrough geometry shaders, this can be done using a much simpler
shader:
layout(triangles) in;
layout(passthrough) in Inputs {
vec2 texcoord;
vec3 normal;
vec4 baseColor;
layout(passthrough) in gl_PerVertex {
vec4 gl_Position;
} gl_in[];
layout(viewport_relative) out int gl_Layer;

void main()
// Figure out which faces the primitive projects onto and
// generate a corresponding viewport mask.
uint mask = 0;
for (int i = 0; i < 6; i++) {
if (!shouldCull(face)) {
mask |= 1U << i;
gl_ViewportMask = mask;
gl_Layer = 0;
The application code is set up so that each of the six cube faces has a
separate viewport (numbered 0 to 5).
Each face also has a separate swizzle, programmed via the
VkPipelineViewportSwizzleStateCreateInfoNV
pipeline state.
The viewport swizzle feature performs the coordinate transformation handled
by the
rotate
() function in the original shader.
The
viewport_relative
layout qualifier says that the viewport number (0
to 5) is added to the base
gl_Layer
value of 0 to determine which layer
(cube face) the primitive should be sent to.
Note that the use of the passed through input
normal
in this example
suggests that the fragment shader in this example would perform an operation
like per-fragment lighting.
The viewport swizzle would transform the position to be face-relative, but
normal
would remain in the original coordinate system.
It seems likely that the fragment shader in either version of the example
would want to perform lighting in the original coordinate system.
It would likely do this by reconstructing the position of the fragment in
the original coordinate system using
gl_FragCoord
, a constant or
uniform holding the size of the cube face, and the input
gl_ViewportIndex
(or
gl_Layer
), which identifies the cube face.
Since the value of
normal
is in the original coordinate system, it
would not need to be modified as part of this coordinate transformation.
Note that while the
rotate
() operation in the regular geometry shader
above could include an arbitrary post-rotation projection matrix, the
viewport swizzle does not support arbitrary math.
To get proper projection,
1/W
buffering should be used.
To do this:
Program the viewport swizzles to move the pre-projection
eye
coordinate (typically 1.0) into the
coordinate of the swizzle
output and the eye coordinate component used for depth into the
coordinate.
For example, the viewport corresponding to the
+Z
face might use a
swizzle of
(+X, -Y, +W, +Z)
The
normalized device coordinate computed after swizzling would
then be
z'/w' = 1/Z
eye
On NVIDIA implementations supporting floating-point depth buffers with
values outside
[0,1]
, prevent unwanted near plane clipping by
enabling
depthClampEnable
Ensure that the depth clamp does not mess up depth testing by
programming the depth range to very large values, such as
minDepthBounds
=-z
maxDepthBounds
=+z
, where
z = 2
127
It should be possible to use IEEE infinity encodings also (
0xFF800000
for
-INF
0x7F800000
for
+INF
).
Even when near/far clipping is disabled, primitives extending behind the
eye will still be clipped because one or more vertices will have a
negative
coordinate and fail
clipping tests.
On other implementations, scale
, and
eye
coordinates so that vertices on the near plane have a post-swizzle
coordinate of 1.0.
For example, if the near plane is at
eye
= 1/256
, scale
, and
by 256.
Adjust depth testing to reflect the fact that
1/W
values are large
near the eye and small away from the eye.
Clear the depth buffer to zero (infinitely far away) and use a depth
test of
VK_COMPARE_OP_GREATER
instead of
VK_COMPARE_OP_LESS
Version History
Revision 1, 2016-12-22 (Piers Daniell)
Internal revisions
VK_NVX_binary_import
Name String
VK_NVX_binary_import
Extension Type
Device extension
Registered Extension Number
30
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_EXT_debug_report
Contact
Eric Werness
ewerness-nv
Liam Middlebrook
liam-middlebrook
Other Extension Metadata
Last Modified Date
2024-11-04
Contributors
Eric Werness, NVIDIA
Liam Middlebrook, NVIDIA
Description
This extension allows applications to import CuBIN binaries and execute
them.
There is currently no specification language written for this extension.
The links to APIs defined by the extension are to stubs that only include
generated content such as API declarations and implicit valid usage
statements.
New Object Types
VkCuFunctionNVX
VkCuModuleNVX
New Commands
vkCmdCuLaunchKernelNVX
vkCreateCuFunctionNVX
vkCreateCuModuleNVX
vkDestroyCuFunctionNVX
vkDestroyCuModuleNVX
New Structures
VkCuFunctionCreateInfoNVX
VkCuLaunchInfoNVX
VkCuModuleCreateInfoNVX
Extending
VkCuModuleCreateInfoNVX
VkCuModuleTexturingModeCreateInfoNVX
New Enum Constants
VK_NVX_BINARY_IMPORT_EXTENSION_NAME
VK_NVX_BINARY_IMPORT_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_CU_FUNCTION_NVX
VK_OBJECT_TYPE_CU_MODULE_NVX
Extending
VkStructureType
VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX
VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX
VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX
VK_STRUCTURE_TYPE_CU_MODULE_TEXTURING_MODE_CREATE_INFO_NVX
If
VK_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_CU_FUNCTION_NVX_EXT
VK_DEBUG_REPORT_OBJECT_TYPE_CU_MODULE_NVX_EXT
Stub API References
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuFunctionNVX)
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuModuleNVX)
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
VkResult vkCreateCuFunctionNVX(
VkDevice device,
const VkCuFunctionCreateInfoNVX* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkCuFunctionNVX* pFunction);
Valid Usage (Implicit)
VUID-vkCreateCuFunctionNVX-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkCreateCuFunctionNVX-pCreateInfo-parameter
pCreateInfo
must
be a valid pointer to a valid
VkCuFunctionCreateInfoNVX
structure
VUID-vkCreateCuFunctionNVX-pAllocator-parameter
If
pAllocator
is not
NULL
pAllocator
must
be a valid pointer to a valid
VkAllocationCallbacks
structure
VUID-vkCreateCuFunctionNVX-pFunction-parameter
pFunction
must
be a valid pointer to a
VkCuFunctionNVX
handle
VUID-vkCreateCuFunctionNVX-device-queuecount
The device
must
have been created with at least
queue
Return Codes
Success
VK_SUCCESS
Failure
VK_ERROR_INITIALIZATION_FAILED
VK_ERROR_OUT_OF_HOST_MEMORY
VK_ERROR_UNKNOWN
VK_ERROR_VALIDATION_FAILED
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
typedef struct VkCuFunctionCreateInfoNVX {
VkStructureType sType;
const void* pNext;
VkCuModuleNVX module;
const char* pName;
} VkCuFunctionCreateInfoNVX;
Valid Usage (Implicit)
VUID-VkCuFunctionCreateInfoNVX-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX
VUID-VkCuFunctionCreateInfoNVX-pNext-pNext
pNext
must
be
NULL
VUID-VkCuFunctionCreateInfoNVX-module-parameter
module
must
be a valid
VkCuModuleNVX
handle
VUID-VkCuFunctionCreateInfoNVX-pName-parameter
pName
must
be a null-terminated UTF-8 string
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
void vkDestroyCuFunctionNVX(
VkDevice device,
VkCuFunctionNVX function,
const VkAllocationCallbacks* pAllocator);
Valid Usage (Implicit)
VUID-vkDestroyCuFunctionNVX-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkDestroyCuFunctionNVX-function-parameter
function
must
be a valid
VkCuFunctionNVX
handle
VUID-vkDestroyCuFunctionNVX-pAllocator-parameter
If
pAllocator
is not
NULL
pAllocator
must
be a valid pointer to a valid
VkAllocationCallbacks
structure
VUID-vkDestroyCuFunctionNVX-function-parent
function
must
have been created, allocated, or retrieved from
device
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
VkResult vkCreateCuModuleNVX(
VkDevice device,
const VkCuModuleCreateInfoNVX* pCreateInfo,
const VkAllocationCallbacks* pAllocator,
VkCuModuleNVX* pModule);
Valid Usage (Implicit)
VUID-vkCreateCuModuleNVX-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkCreateCuModuleNVX-pCreateInfo-parameter
pCreateInfo
must
be a valid pointer to a valid
VkCuModuleCreateInfoNVX
structure
VUID-vkCreateCuModuleNVX-pAllocator-parameter
If
pAllocator
is not
NULL
pAllocator
must
be a valid pointer to a valid
VkAllocationCallbacks
structure
VUID-vkCreateCuModuleNVX-pModule-parameter
pModule
must
be a valid pointer to a
VkCuModuleNVX
handle
VUID-vkCreateCuModuleNVX-device-queuecount
The device
must
have been created with at least
queue
Return Codes
Success
VK_SUCCESS
Failure
VK_ERROR_INITIALIZATION_FAILED
VK_ERROR_OUT_OF_HOST_MEMORY
VK_ERROR_UNKNOWN
VK_ERROR_VALIDATION_FAILED
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
typedef struct VkCuModuleCreateInfoNVX {
VkStructureType sType;
const void* pNext;
size_t dataSize;
const void* pData;
} VkCuModuleCreateInfoNVX;
Valid Usage (Implicit)
VUID-VkCuModuleCreateInfoNVX-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX
VUID-VkCuModuleCreateInfoNVX-pNext-pNext
pNext
must
be
NULL
or a pointer to a valid instance of
VkCuModuleTexturingModeCreateInfoNVX
VUID-VkCuModuleCreateInfoNVX-sType-unique
The
sType
value of each structure in the
pNext
chain
must
be unique
VUID-VkCuModuleCreateInfoNVX-pData-parameter
If
dataSize
is not
pData
must
be a valid pointer to an array of
dataSize
bytes
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
typedef struct VkCuModuleTexturingModeCreateInfoNVX {
VkStructureType sType;
const void* pNext;
VkBool32 use64bitTexturing;
} VkCuModuleTexturingModeCreateInfoNVX;
Valid Usage (Implicit)
VUID-VkCuModuleTexturingModeCreateInfoNVX-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_CU_MODULE_TEXTURING_MODE_CREATE_INFO_NVX
Structure Chaining
Extends the structure
VkCuModuleCreateInfoNVX
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
void vkDestroyCuModuleNVX(
VkDevice device,
VkCuModuleNVX module,
const VkAllocationCallbacks* pAllocator);
Valid Usage (Implicit)
VUID-vkDestroyCuModuleNVX-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkDestroyCuModuleNVX-module-parameter
module
must
be a valid
VkCuModuleNVX
handle
VUID-vkDestroyCuModuleNVX-pAllocator-parameter
If
pAllocator
is not
NULL
pAllocator
must
be a valid pointer to a valid
VkAllocationCallbacks
structure
VUID-vkDestroyCuModuleNVX-module-parent
module
must
have been created, allocated, or retrieved from
device
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
void vkCmdCuLaunchKernelNVX(
VkCommandBuffer commandBuffer,
const VkCuLaunchInfoNVX* pLaunchInfo);
Valid Usage (Implicit)
VUID-vkCmdCuLaunchKernelNVX-commandBuffer-parameter
commandBuffer
must
be a valid
VkCommandBuffer
handle
VUID-vkCmdCuLaunchKernelNVX-pLaunchInfo-parameter
pLaunchInfo
must
be a valid pointer to a valid
VkCuLaunchInfoNVX
structure
VUID-vkCmdCuLaunchKernelNVX-commandBuffer-recording
commandBuffer
must
be in the
recording state
VUID-vkCmdCuLaunchKernelNVX-commandBuffer-cmdpool
The
VkCommandPool
that
commandBuffer
was allocated from
must
support
VK_QUEUE_COMPUTE_BIT
, or
VK_QUEUE_GRAPHICS_BIT
operations
VUID-vkCmdCuLaunchKernelNVX-suspended
This command
must
not be called between suspended render pass instances
VUID-vkCmdCuLaunchKernelNVX-videocoding
This command
must
only be called outside of a video coding scope
Host Synchronization
Host access to the
VkCommandPool
that
commandBuffer
was allocated from
must
be externally synchronized
Command Properties
Command Buffer Levels
Render Pass Scope
Video Coding Scope
Supported Queue Types
Command Type
Primary
Secondary
Both
Outside
VK_QUEUE_COMPUTE_BIT
VK_QUEUE_GRAPHICS_BIT
Action
Conditional Rendering
vkCmdCuLaunchKernelNVX is not affected by
conditional rendering
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_NVX_binary_import
typedef struct VkCuLaunchInfoNVX {
VkStructureType sType;
const void* pNext;
VkCuFunctionNVX function;
uint32_t gridDimX;
uint32_t gridDimY;
uint32_t gridDimZ;
uint32_t blockDimX;
uint32_t blockDimY;
uint32_t blockDimZ;
uint32_t sharedMemBytes;
size_t paramCount;
const void* const * pParams;
size_t extraCount;
const void* const * pExtras;
} VkCuLaunchInfoNVX;
Valid Usage (Implicit)
VUID-VkCuLaunchInfoNVX-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX
VUID-VkCuLaunchInfoNVX-pNext-pNext
pNext
must
be
NULL
VUID-VkCuLaunchInfoNVX-function-parameter
function
must
be a valid
VkCuFunctionNVX
handle
VUID-VkCuLaunchInfoNVX-pParams-parameter
If
paramCount
is not
pParams
must
be a valid pointer to an array of
paramCount
bytes
VUID-VkCuLaunchInfoNVX-pExtras-parameter
If
extraCount
is not
pExtras
must
be a valid pointer to an array of
extraCount
bytes
Version History
Revision 2, 2024-11-04 (Liam Middlebrook)
Add
VkCuModuleTexturingModeCreateInfoNVX
Revision 1, 2021-04-09 (Eric Werness)
Internal revisions
VK_NVX_image_view_handle
Name String
VK_NVX_image_view_handle
Extension Type
Device extension
Registered Extension Number
31
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Eric Werness
ewerness-nv
Other Extension Metadata
Last Modified Date
2025-12-03
Contributors
Eric Werness, NVIDIA
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Liam Middlebrook, NVIDIA
Rodrigo Locatti, NVIDIA
Description
This extension allows applications to query an opaque handle from an image
view for use as a sampled image or storage image.
This provides no direct functionality itself.
New Commands
vkGetDeviceCombinedImageSamplerIndexNVX
vkGetImageViewAddressNVX
vkGetImageViewHandle64NVX
vkGetImageViewHandleNVX
New Structures
VkImageViewAddressPropertiesNVX
VkImageViewHandleInfoNVX
New Enum Constants
VK_NVX_IMAGE_VIEW_HANDLE_EXTENSION_NAME
VK_NVX_IMAGE_VIEW_HANDLE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_VIEW_ADDRESS_PROPERTIES_NVX
VK_STRUCTURE_TYPE_IMAGE_VIEW_HANDLE_INFO_NVX
Version History
Revision 4, 2025-12-03 (Rodrigo Locatti)
Add
vkGetDeviceCombinedImageSamplerIndexNVX
Revision 3, 2024-11-04 (Liam Middlebrook)
Add
vkGetImageViewHandle64NVX
Revision 2, 2020-04-03 (Piers Daniell)
Add
vkGetImageViewAddressNVX
Revision 1, 2018-12-07 (Eric Werness)
Internal revisions
VK_NVX_multiview_per_view_attributes
Name String
VK_NVX_multiview_per_view_attributes
Extension Type
Device extension
Registered Extension Number
98
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_multiview
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
SPIR-V Dependencies
SPV_NVX_multiview_per_view_attributes
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-01-13
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NVX_multiview_per_view_attributes
This extension interacts with
VK_NV_viewport_array2
Contributors
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Description
This extension adds a new way to write shaders to be used with multiview
subpasses, where the attributes for all views are written out by a single
invocation of the
pre-rasterization shader stages
Related SPIR-V and GLSL extensions
SPV_NVX_multiview_per_view_attributes
and
GL_NVX_multiview_per_view_attributes
introduce per-view position and
viewport mask attributes arrays, and this extension defines how those
per-view attribute arrays are interpreted by Vulkan.
Pipelines using per-view attributes
may
only execute the
pre-rasterization shader stages
once for all views rather than once per-view, which reduces
redundant shading work.
A subpass creation flag controls whether the subpass uses this extension.
A subpass
must
either exclusively use this extension or not use it at all.
Some Vulkan implementations only support the position attribute varying
between views in the X component.
A subpass can declare via a second creation flag whether all pipelines
compiled for this subpass will obey this restriction.
Shaders that use the new per-view outputs (e.g.
gl_PositionPerViewNV
must
also write the non-per-view output (
gl_Position
), and the values
written
must
be such that
gl_Position =
gl_PositionPerViewNV[gl_ViewIndex]
for all views in the subpass.
Implementations are free to either use the per-view outputs or the
non-per-view outputs, whichever would be more efficient.
If the
VK_NV_viewport_array2
extension is not also supported and
enabled, the per-view viewport mask
must
not be used.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkCommandBufferInheritanceInfo
VkGraphicsPipelineCreateInfo
VkRenderingInfo
VkMultiviewPerViewAttributesInfoNVX
New Enum Constants
VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_EXTENSION_NAME
VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_ATTRIBUTES_PROPERTIES_NVX
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX
VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX
If
Vulkan Version 1.3
or
VK_KHR_dynamic_rendering
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_ATTRIBUTES_INFO_NVX
New Built-In Variables
PositionPerViewNV
ViewportMaskPerViewNV
New SPIR-V Capabilities
PerViewAttributesNV
Examples
#version 450 core

#extension GL_KHX_multiview : enable
#extension GL_NVX_multiview_per_view_attributes : enable

layout(location = 0) in vec4 position;
layout(set = 0, binding = 0) uniform Block { mat4 mvpPerView[2]; } buf;

void main()
// Output both per-view positions and gl_Position as a function
// of gl_ViewIndex
gl_PositionPerViewNV[0] = buf.mvpPerView[0] * position;
gl_PositionPerViewNV[1] = buf.mvpPerView[1] * position;
gl_Position = buf.mvpPerView[gl_ViewIndex] * position;
Version History
Revision 1, 2017-01-13 (Jeff Bolz)
Internal revisions
VK_OHOS_external_memory
Name String
VK_OHOS_external_memory
Extension Type
Device extension
Registered Extension Number
453
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
and
VK_KHR_external_memory
and
VK_KHR_dedicated_allocation
or
Vulkan Version 1.1
and
VK_EXT_queue_family_foreign
Contact
Weilan Chen
wchen-h
Other Extension Metadata
Last Modified Date
2025-11-4
IP Status
No known IP claims.
Contributors
Weilan Chen, Huawei
Zeihui Lin, Huawei
Bill Hollings, Huawei
Pan Gao, Huawei
Yang Shi, Huawei
Description
This extension enables an application to: import Open Harmony OS
OH_NativeBuffer
objects created outside of Vulkan device into
Vulkan memory objects, where they can be bound to images and buffers.
It also allows an application to obtain the properties of
OH_NativeBuffer
object.
New Base Types
OH_NativeBuffer
New Commands
vkGetMemoryNativeBufferOHOS
vkGetNativeBufferPropertiesOHOS
New Structures
VkMemoryGetNativeBufferInfoOHOS
VkNativeBufferPropertiesOHOS
Extending
VkImageCreateInfo
VkSamplerYcbcrConversionCreateInfo
VkAttachmentDescription2
VkGraphicsPipelineCreateInfo
VkCommandBufferInheritanceInfo
VkExternalFormatOHOS
Extending
VkImageFormatProperties2
VkNativeBufferUsageOHOS
Extending
VkMemoryAllocateInfo
VkImportNativeBufferInfoOHOS
Extending
VkNativeBufferPropertiesOHOS
VkNativeBufferFormatPropertiesOHOS
New Enum Constants
VK_OHOS_EXTERNAL_MEMORY_EXTENSION_NAME
VK_OHOS_EXTERNAL_MEMORY_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OH_NATIVE_BUFFER_BIT_OHOS
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_OHOS
VK_STRUCTURE_TYPE_IMPORT_NATIVE_BUFFER_INFO_OHOS
VK_STRUCTURE_TYPE_MEMORY_GET_NATIVE_BUFFER_INFO_OHOS
VK_STRUCTURE_TYPE_NATIVE_BUFFER_FORMAT_PROPERTIES_OHOS
VK_STRUCTURE_TYPE_NATIVE_BUFFER_PROPERTIES_OHOS
VK_STRUCTURE_TYPE_NATIVE_BUFFER_USAGE_OHOS
Version History
Revision 1, 2025-11-4 (Weilan Chen)
Change Extension number to 453, which is donated by ARM.
VK_OHOS_surface
Name String
VK_OHOS_surface
Extension Type
Instance extension
Registered Extension Number
588
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Weilan Chen
wchen-h
Other Extension Metadata
Last Modified Date
2025-05-16
IP Status
No known IP claims.
Contributors
Weilan Chen, Huawei
Zehui Lin, Huawei
Pan Gao, Huawei
Zhao Zhang, Huawei
Yang Shi, Huawei
Description
The
VK_OHOS_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
OHNativeWindow
, the native surface type of Open Harmony OS.
Common consumer endpoints for
OHNativeWindows
are the system window
compositor, video encoders, and application-specific compositors.
New Base Types
OHNativeWindow
New Commands
vkCreateSurfaceOHOS
New Structures
VkSurfaceCreateInfoOHOS
New Bitmasks
VkSurfaceCreateFlagsOHOS
New Enum Constants
VK_OHOS_SURFACE_EXTENSION_NAME
VK_OHOS_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_CREATE_INFO_OHOS
Version History
Revision 1, 2025-05-19 (Weilan Chen)
Internal revisions
VK_QCOM_cooperative_matrix_conversion
Name String
VK_QCOM_cooperative_matrix_conversion
Extension Type
Device extension
Registered Extension Number
173
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_cooperative_matrix
SPIR-V Dependencies
SPV_QCOM_cooperative_matrix_conversion
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_cooperative_matrix_conversion
Other Extension Metadata
Last Modified Date
2026-01-28
Interactions and External Dependencies
This extension provides API support for
GLSL_QCOM_cooperative_matrix_conversion
Contributors
Matthew Netsch, Qualcomm Technologies, Inc
Elina Kamenetskaya, Qualcomm Technologies, Inc
Alex Bourd, Qualcomm Technologies, Inc
Ruihao Zhang, Qualcomm Technologies, Inc
Wooyoung Kim, Qualcomm Technologies, Inc
Description
This extension adds support for new SPIR-V shader instructions that allow
loading and storing a cooperative matrix without needing to stage through
shared memory and to allow bit casting arrays.
These instructions are defined by the
SPV_QCOM_cooperative_matrix_conversion
SPIR-V extension and can be used with the
GLSL_QCOM_cooperative_matrix_conversion
GLSL extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCooperativeMatrixConversionFeaturesQCOM
New Enum Constants
VK_QCOM_COOPERATIVE_MATRIX_CONVERSION_EXTENSION_NAME
VK_QCOM_COOPERATIVE_MATRIX_CONVERSION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_CONVERSION_FEATURES_QCOM
New SPIR-V Capabilities
CooperativeMatrixConversionQCOM
Version History
Revision 1, 2026-01-28 (Matthew Netsch)
Initial draft
VK_QCOM_data_graph_model
Name String
VK_QCOM_data_graph_model
Extension Type
Device extension
Registered Extension Number
630
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_ARM_data_graph
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_data_graph_model
Other Extension Metadata
Last Modified Date
2025-06-24
Interactions and External Dependencies
This extension interacts with
VK_ARM_tensors
Contributors
Matthew Netsch, Qualcomm Technologies, Inc
Rob VanReenen, Qualcomm Technologies, Inc
Balaji Calidas, Qualcomm Technologies, Inc
Jacob Yenney, Qualcomm Technologies, Inc
Kévin Petit, Arm Ltd.
Description
This extension supports new
VkPhysicalDeviceDataGraphProcessingEngineTypeARM
, and
VkPhysicalDeviceDataGraphOperationTypeARM
types for data graph
pipelines added in
VK_ARM_data_graph
A new pipeline cache type is also added to seamlessly import ML models such
as ONNX through QNN workflow, and run them on the device or an external
compute engine.
New Structures
VkPipelineCacheHeaderVersionDataGraphQCOM
Extending
VkDataGraphPipelineCreateInfoARM
VkDataGraphPipelineBuiltinModelCreateInfoQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDataGraphModelFeaturesQCOM
New Enums
VkDataGraphModelCacheTypeQCOM
New Enum Constants
VK_DATA_GRAPH_MODEL_TOOLCHAIN_VERSION_LENGTH_QCOM
VK_QCOM_DATA_GRAPH_MODEL_EXTENSION_NAME
VK_QCOM_DATA_GRAPH_MODEL_SPEC_VERSION
Extending
VkPhysicalDeviceDataGraphOperationTypeARM
VK_PHYSICAL_DEVICE_DATA_GRAPH_OPERATION_TYPE_BUILTIN_MODEL_QCOM
VK_PHYSICAL_DEVICE_DATA_GRAPH_OPERATION_TYPE_NEURAL_MODEL_QCOM
Extending
VkPhysicalDeviceDataGraphProcessingEngineTypeARM
VK_PHYSICAL_DEVICE_DATA_GRAPH_PROCESSING_ENGINE_TYPE_COMPUTE_QCOM
VK_PHYSICAL_DEVICE_DATA_GRAPH_PROCESSING_ENGINE_TYPE_NEURAL_QCOM
Extending
VkPipelineCacheHeaderVersion
VK_PIPELINE_CACHE_HEADER_VERSION_DATA_GRAPH_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_DATA_GRAPH_PIPELINE_BUILTIN_MODEL_CREATE_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DATA_GRAPH_MODEL_FEATURES_QCOM
Version History
Revision 1, 2025-06-24 (Matthew Netsch)
Initial revision
VK_QCOM_filter_cubic_clamp
Name String
VK_QCOM_filter_cubic_clamp
Extension Type
Device extension
Registered Extension Number
522
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_filter_cubic
and
Vulkan Version 1.2
or
VK_EXT_sampler_filter_minmax
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-08-02
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Description
This extension extends cubic filtering by adding the ability to enable an
anti-ringing clamp.
Cubic filtering samples from a 4x4 region of texels and computes a cubic
weighted average of the region.
In some cases, the resulting value is outside the range of any of the texels
in the 4x4 region.
This is sometimes referred to as “filter overshoot” or “filter ringing”
and can occur when there is a sharp discontinuity in the 4x4 region being
filtered.
For some use cases this “ringing” can produces unacceptable artifacts.
The solution to the ringing problem is to clamp the post-cubic-filtered
value to be within the max and min of texel values in the 4x4 region.
While such “range clamping” can be performed in shader code, the
additional texture fetches and clamping ALU operations can be costly.
Certain Adreno GPUs are able to perform the range clamp in the texture unit
during cubic filtering at significant performance/power savings versus a
shader-based clamping approach.
This extension exposes such hardware functionality.
This extension extends
VkSamplerReductionMode
, adding
VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_RANGECLAMP_QCOM
which
enables the range clamp operation.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCubicClampFeaturesQCOM
New Enum Constants
VK_QCOM_FILTER_CUBIC_CLAMP_EXTENSION_NAME
VK_QCOM_FILTER_CUBIC_CLAMP_SPEC_VERSION
Extending
VkSamplerReductionMode
VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_RANGECLAMP_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUBIC_CLAMP_FEATURES_QCOM
Version History
Revision 1, 2023-08-02 (jleger)
Initial version
VK_QCOM_filter_cubic_weights
Name String
VK_QCOM_filter_cubic_weights
Extension Type
Device extension
Registered Extension Number
520
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_filter_cubic
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-06-23
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Jonathan Wicks, Qualcomm Technologies, Inc.
Description
This extension extends cubic filtering by adding the ability to select a set
of weights.
Without this extension, the weights used in cubic filtering are limited to
those corresponding to a Catmull-Rom spline.
This extension adds support for 3 additional spline weights.
This extension adds a new structure that
can
be added to the
pNext
chain of
VkSamplerCreateInfo
that
can
be used to specify which set of
cubic weights are used in cubic filtering.
A similar structure can be added to the
pNext
chain of
VkBlitImageInfo2
to specify cubic weights used in a blit operation.
With this extension weights corresponding to the following additional
splines can be selected for cubic filtered sampling and blits:
Zero Tangent Cardinal
B-Spline
Mitchell-Netravali
New Structures
Extending
VkBlitImageInfo2
VkBlitImageCubicWeightsInfoQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCubicWeightsFeaturesQCOM
Extending
VkSamplerCreateInfo
VkSamplerCubicWeightsCreateInfoQCOM
New Enums
VkCubicFilterWeightsQCOM
New Enum Constants
VK_QCOM_FILTER_CUBIC_WEIGHTS_EXTENSION_NAME
VK_QCOM_FILTER_CUBIC_WEIGHTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_BLIT_IMAGE_CUBIC_WEIGHTS_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUBIC_WEIGHTS_FEATURES_QCOM
VK_STRUCTURE_TYPE_SAMPLER_CUBIC_WEIGHTS_CREATE_INFO_QCOM
Version History
Revision 1, 2023-06-23 (jleger)
Initial version
VK_QCOM_image_processing
Name String
VK_QCOM_image_processing
Extension Type
Device extension
Registered Extension Number
441
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_format_feature_flags2
SPIR-V Dependencies
SPV_QCOM_image_processing
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_image_processing
Other Extension Metadata
Last Modified Date
2022-07-08
Interactions and External Dependencies
This extension provides API support for
GL_QCOM_image_processing
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Ruihao Zhang, Qualcomm Technologies, Inc.
Description
GPUs are commonly used to process images for various applications from 3D
graphics to UI and from composition to compute applications.
Simple scaling and filtering can be done with bilinear filtering, which
comes for free during texture sampling.
However, as screen sizes get larger and more use cases rely on GPU such as
camera and video post-processing needs, there is increasing demand for GPU
to support higher order filtering and other advanced image processing.
This extension introduces a new set of SPIR-V built-in functions for image
processing.
It exposes the following new imaging operations
The
OpImageSampleWeightedQCOM
instruction takes 3 operands:
sampled
image
weight image
, and texture coordinates.
The instruction computes a weighted average of an MxN region of texels
in the
sampled image
, using a set of MxN weights in the
weight image
The
OpImageBoxFilterQCOM
instruction takes 3 operands:
sampled
image
box size
, and texture coordinates.
Note that
box size
specifies a floating-point width and height in
texels.
The instruction computes a weighted average of all texels in the
sampled image
that are covered (either partially or fully) by a box
with the specified size and centered at the specified texture
coordinates.
The
OpImageBlockMatchSADQCOM
and
OpImageBlockMatchSSDQCOM
instructions each takes 5 operands:
target image
target
coordinates
reference image
reference coordinates
, and
block
size
Each instruction computes an error metric, that describes whether a
block of texels in the
target image
matches a corresponding block of
texels in the
reference image
The error metric is computed per-component.
OpImageBlockMatchSADQCOM
computes “Sum Of Absolute Difference” and
OpImageBlockMatchSSDQCOM
computes “Sum of Squared Difference”.
Each of the image processing instructions operate only on 2D images.
The instructions do not-support sampling of mipmap, multi-plane,
multi-layer, multi-sampled, or depth/stencil images.
The instructions can be used in any shader stage.
Implementations of this extension should support these operations natively
at the HW instruction level, offering potential performance gains as well as
ease of development.
New Structures
Extending
VkImageViewCreateInfo
VkImageViewSampleWeightCreateInfoQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageProcessingFeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceImageProcessingPropertiesQCOM
New Enum Constants
VK_QCOM_IMAGE_PROCESSING_EXTENSION_NAME
VK_QCOM_IMAGE_PROCESSING_SPEC_VERSION
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM
VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM
VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM
Extending
VkSamplerCreateFlagBits
VK_SAMPLER_CREATE_IMAGE_PROCESSING_BIT_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_VIEW_SAMPLE_WEIGHT_CREATE_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_PROPERTIES_QCOM
If
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_BLOCK_MATCHING_BIT_QCOM
VK_FORMAT_FEATURE_2_BOX_FILTER_SAMPLED_BIT_QCOM
VK_FORMAT_FEATURE_2_WEIGHT_IMAGE_BIT_QCOM
VK_FORMAT_FEATURE_2_WEIGHT_SAMPLED_IMAGE_BIT_QCOM
Version History
Revision 1, 2022-07-08 (Jeff Leger)
VK_QCOM_image_processing2
Name String
VK_QCOM_image_processing2
Extension Type
Device extension
Registered Extension Number
519
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_QCOM_image_processing
SPIR-V Dependencies
SPV_QCOM_image_processing2
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-03-10
Interactions and External Dependencies
This extension provides API support for
GL_QCOM_image_processing2
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Description
This extension enables support for the SPIR-V
TextureBlockMatch2QCOM
capability.
It builds on the functionality of QCOM_image_processing with the addition of
4 new image processing operations.
The
opImageBlockMatchWindowSADQCOM
` SPIR-V instruction builds upon
the functionality of
opImageBlockMatchSADQCOM
` by repeatedly
performing block match operations across a 2D window.
The “2D windowExtent” and “compareMode” are specified by
VkSamplerBlockMatchWindowCreateInfoQCOM
in the sampler used to
create the
target image
Like
OpImageBlockMatchSADQCOM
opImageBlockMatchWindowSADQCOM
computes an error metric, that describes whether a block of texels in
the
target image
matches a corresponding block of texels in the
reference image
Unlike
OpImageBlockMatchSADQCOM
, this instruction computes an error
metric at each (X,Y) location within the 2D window and returns either
the minimum or maximum error.
The instruction only supports single-component formats.
Refer to the pseudocode below for details.
The
opImageBlockMatchWindowSSDQCOM
follows the same pattern,
computing the SSD error metric at each location within the 2D window.
The
opImageBlockMatchGatherSADQCOM
builds upon
OpImageBlockMatchSADQCOM
This instruction computes an error metric, that describes whether a
block of texels in the
target image
matches a corresponding block of
texels in the
reference image
The instruction computes the SAD error metric at 4 texel offsets and
returns the error metric for each offset in the X,Y,Z,and W components.
The instruction only supports single-component texture formats.
Refer to the pseudocode below for details.
The
opImageBlockMatchGatherSSDQCOM
follows the same pattern,
computing the SSD error metric for 4 offsets.
Each of the above 4 image processing instructions are limited to
single-component formats.
Below is the pseudocode for GLSL built-in function
textureWindowBlockMatchSADQCOM
The pseudocode for
textureWindowBlockMatchSSD
is identical other than
replacing all instances of
"SAD"
with
"SSD"
vec4 textureBlockMatchWindowSAD( sampler2D target,
uvec2 targetCoord,
sampler2D reference,
uvec2 refCoord,
uvec2 blocksize) {
// compareMode (MIN or MAX) comes from the vkSampler associated with `target`
// uvec2 window comes from the vkSampler associated with `target`
minSAD = INF;
maxSAD = -INF;
uvec2 minCoord;
uvec2 maxCoord;

for (uint x=0, x < window.width; x++) {
for (uint y=0; y < window.height; y++) {
float SAD = textureBlockMatchSAD(target,
targetCoord + uvec2(x, y),
reference,
refCoord,
blocksize).x;
// Note: the below comparison operator will produce undefined results
// if SAD is a denorm value.
if (SAD < minSAD) {
minSAD = SAD;
minCoord = uvec2(x,y);
if (SAD > maxSAD) {
maxSAD = SAD;
maxCoord = uvec2(x,y);
if (compareMode=MIN) {
return vec4(minSAD, minCoord.x, minCoord.y, 0.0);
} else {
return vec4(maxSAD, maxCoord.x, maxCoord.y, 0.0);
Below is the pseudocode for
textureBlockMatchGatherSADQCOM
The pseudocode for
textureBlockMatchGatherSSD
follows an identical
pattern.
vec4 textureBlockMatchGatherSAD( sampler2D target,
uvec2 targetCoord,
sampler2D reference,
uvec2 refCoord,
uvec2 blocksize) {
vec4 out;
for (uint x=0, x<4; x++) {
float SAD = textureBlockMatchSAD(target,
targetCoord + uvec2(x, 0),
reference,
refCoord,
blocksize).x;
out[x] = SAD;
return out;
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageProcessing2FeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceImageProcessing2PropertiesQCOM
Extending
VkSamplerCreateInfo
VkSamplerBlockMatchWindowCreateInfoQCOM
New Enums
VkBlockMatchWindowCompareModeQCOM
New Enum Constants
VK_QCOM_IMAGE_PROCESSING_2_EXTENSION_NAME
VK_QCOM_IMAGE_PROCESSING_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_2_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_2_PROPERTIES_QCOM
VK_STRUCTURE_TYPE_SAMPLER_BLOCK_MATCH_WINDOW_CREATE_INFO_QCOM
Issues
1) What is the precision of the min/max comparison checks?
RESOLVED
: Intermediate computations for the new operations are performed
at 16-bit floating-point precision.
If the value of
"float SAD"
in the above code sample is a 16-bit denorm
value, then behavior of the MIN/MAX comparison is undefined.
Version History
Revision 1, 2023-03-10 (Jeff Leger)
VK_QCOM_multiview_per_view_render_areas
Name String
VK_QCOM_multiview_per_view_render_areas
Extension Type
Device extension
Registered Extension Number
511
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-01-10
IP Status
No known IP claims.
Interactions and External Dependencies
This extension interacts with
VK_KHR_dynamic_rendering
This extension interacts with
VK_QCOM_render_pass_transform
Contributors
Jeff Leger, Qualcomm
Jonathan Tinkham, Qualcomm
Jonathan Wicks, Qualcomm
Description
Certain use cases (e.g., side-by-side VR rendering) use multiview and render
to distinct regions of the framebuffer for each view.
On some implementations, there may be a performance benefit for providing
per-view render areas to the implementation.
Such per-view render areas can be used by the implementation to reduce the
pixels that are affected by attachment load, store, and multisample resolve
operations.
The extension enables a multiview render pass instance to define per-view
render areas.
For each view of a multiview render pass instance, only those pixels in the
per-view render area are affected by load, store, and resolve operations.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMultiviewPerViewRenderAreasFeaturesQCOM
Extending
VkRenderPassBeginInfo
VkRenderingInfo
VkMultiviewPerViewRenderAreasRenderPassBeginInfoQCOM
New Enum Constants
VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_EXTENSION_NAME
VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_RENDER_AREAS_RENDER_PASS_BEGIN_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_RENDER_AREAS_FEATURES_QCOM
Issues
1) Do the per-view
renderAreas
interact with
vkGetRenderAreaGranularity
RESOLVED
: There is no change.
The granularity returned by
vkGetRenderAreaGranularity
also applies to
the per-view
renderAreas
2) How does this extension interact with
VK_QCOM_render_pass_transform
RESOLVED
: When
VK_QCOM_render_pass_transform
is enabled, the
application provides render area in non-rotated coordinates which is rotated
by the implementation to the rotated coordinate system.
When this extension is used in combination with
VK_QCOM_render_pass_transform
, then the
renderArea
provided
in
VkRenderingInfo
::
renderArea
VkRenderPassBeginInfo
::
renderArea
, or
VkCommandBufferInheritanceRenderPassTransformInfoQCOM
::
renderArea
is rotated by the implementation.
The per-view render areas are not rotated.
3) How does this extension interact with
VK_QCOM_multiview_per_view_viewports
RESOLVED
: There is no direct interaction.
The per-view viewports and the per-view renderAreas are orthogonal features.
4) When a per-view
renderArea
is specified, must multiview rendering
for each view of a multiview render pass be contained within the per-view
renderArea
RESOLVED
: Yes, and the
VK_QCOM_multiview_per_view_viewports
may
help here since it provides per-view scissors.
5) When per-view render areas are specified, what purpose if any do
VkRenderPassBeginInfo
::
renderArea
and
VkRenderingInfo
::
renderArea
serve?
RESOLVED
: The per-view
renderArea
effectively overrides the
per-renderpass
renderArea
The per-view
renderArea
defines the regions of the attachments that
are effected by load, store, and multisample resolve operations.
A valid implementation could ignore the per-renderpass
renderArea
However, as an aid to the implementation, the application must set the
per-renderpass
renderArea
to an area that is at least as large as the
union of all the per-view render areas.
Pixels that are within the per-renderpass
renderArea
but not within
any per-view render area must not be affected by load, store, or multisample
resolve operations.
Version History
Revision 1, 2023-01-10 (Jeff Leger)
VK_QCOM_multiview_per_view_viewports
Name String
VK_QCOM_multiview_per_view_viewports
Extension Type
Device extension
Registered Extension Number
489
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2022-11-22
IP Status
No known IP claims.
Interactions and External Dependencies
This extension interacts with
VK_KHR_dynamic_rendering
This extension interacts with
VK_EXT_extended_dynamic_state
Contributors
Jeff Leger, Qualcomm
Jonathan Tinkham, Qualcomm
Jonathan Wicks, Qualcomm
Description
Certain use cases for multiview have a need for specifying a separate
viewport and scissor for each view, without using shader-based viewport
indexing as introduced with
VK_EXT_shader_viewport_index_layer
This extension adds a new way to control ViewportIndex with multiview.
When the
multiviewPerViewViewports
feature is enabled and if the last
pre-rasterization shader entry point’s interface does not use the
ViewportIndex
built-in decoration, then each view of a multiview render
pass instance will use a viewport and scissor index equal to the
ViewIndex
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMultiviewPerViewViewportsFeaturesQCOM
New Enum Constants
VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_EXTENSION_NAME
VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_VIEWPORTS_FEATURES_QCOM
Issues
1) Is it possible to enable/disable the
multiviewPerViewViewports
feature for individual render pass instances?
RESOLVED
: No, when the multiviewPerViewViewports feature is enabled during
vkCreateDevice, then all created render pass instances (including dynamic
render passes from
VK_KHR_dynamic_rendering
) and all created
VkPipelines will have the feature enabled.
This approach was chosen because it simplifies application code and there is
no known use case to enable/disable the feature for individual render passes
or pipelines.
2) When this extension is used, is the value of
ViewportIndex
implicitly written by the last pre-rasterization shader stage and can the
value of
ViewportIndex
be read in the fragment shader?
RESOLVED
: No, use of the extension does not add an implicit write to
ViewportIndex
in any shader stage, and additionally, the value of
ViewportIndex
in the fragment shader is undefined.
Version History
Revision 1, 2022-11-22 (Jeff Leger)
VK_QCOM_queue_perf_hint
Name String
VK_QCOM_queue_perf_hint
Extension Type
Device extension
Registered Extension Number
303
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_queue_perf_hint
Other Extension Metadata
Last Modified Date
2026-02-26
IP Status
No known IP claims.
Interactions and External Dependencies
Interacts with
VK_KHR_internally_synchronized_queues
Contributors
Matthew Netsch, Qualcomm Technologies, Inc
Description
This extension exposes power constraints to the application, allowing it to
provide hints for influencing the device’s clock frequency.
These hints are
VkQueue
state and are persistent across the life of
the queue until the app updates or removes the constraint.
The kernel combines the constraints across the active queues from all
processes to determine the actual clock frequency levels.
New Commands
vkQueueSetPerfHintQCOM
New Structures
VkPerfHintInfoQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceQueuePerfHintFeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceQueuePerfHintPropertiesQCOM
New Enums
VkPerfHintTypeQCOM
New Enum Constants
VK_QCOM_QUEUE_PERF_HINT_EXTENSION_NAME
VK_QCOM_QUEUE_PERF_HINT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PERF_HINT_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_QUEUE_PERF_HINT_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_QUEUE_PERF_HINT_PROPERTIES_QCOM
Issues
None.
Version History
Revision 1, 2026-02-26 (Matthew Netsch)
VK_QCOM_render_pass_store_ops
Name String
VK_QCOM_render_pass_store_ops
Extension Type
Device extension
Registered Extension Number
302
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2020-03-25
Contributors
Bill Licea-Kane, Qualcomm Technologies, Inc.
Description
Render pass attachments
can
be read-only for the duration of a render pass.
Examples include input attachments and depth attachments where depth tests
are enabled but depth writes are not enabled.
In such cases, there
can
be no contents generated for an attachment within
the render area.
This extension adds a new
VkAttachmentStoreOp
VK_ATTACHMENT_STORE_OP_NONE_QCOM
specifying that the contents within
the render area
may
not be written to memory, but that the prior contents
of the attachment in memory are preserved.
However, if any contents were generated within the render area during
rendering, the contents of the attachment will be
undefined
inside the
render area.
The
VkAttachmentStoreOp
VK_ATTACHMENT_STORE_OP_STORE
may
force
an implementation to assume that the attachment was written and force an
implementation to flush data to memory or to a higher level cache.
The
VkAttachmentStoreOp
VK_ATTACHMENT_STORE_OP_NONE_QCOM
may
allow an implementation to assume that the attachment was not written and
allow an implementation to avoid such a flush.
New Enum Constants
VK_QCOM_RENDER_PASS_STORE_OPS_EXTENSION_NAME
VK_QCOM_RENDER_PASS_STORE_OPS_SPEC_VERSION
Extending
VkAttachmentStoreOp
VK_ATTACHMENT_STORE_OP_NONE_QCOM
Version History
Revision 1, 2019-12-20 (wwlk)
Initial version
Revision 2, 2020-03-25 (wwlk)
Minor renaming
VK_QCOM_render_pass_transform
Name String
VK_QCOM_render_pass_transform
Extension Type
Device extension
Registered Extension Number
283
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2025-06-30
Interactions and External Dependencies
This extension interacts with
VK_KHR_swapchain
This extension interacts with
VK_KHR_surface
This extension interacts with
VK_EXT_fragment_density_map
This extension interacts with
VK_KHR_fragment_shading_rate
This extension interacts with
VK_QCOM_tile_properties
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Brandon Light, Qualcomm Technologies, Inc.
Matthew Netsch, Qualcomm Technologies, Inc.
Arpit Agarwal, Qualcomm Technologies, Inc.
Žiga Markuš, LunarG, Inc.
Description
This extension provides a mechanism for applications to enable driver
support for
render pass transform
Mobile devices can be rotated and mobile applications need to render
properly when a device is held in a landscape or portrait orientation.
When the current orientation differs from the device’s native orientation, a
rotation is required so that the “up” direction of the rendered scene
matches the current orientation.
If the Display Processing Unit (DPU) does not natively support rotation, the
Vulkan presentation engine can handle this rotation in a separate
composition pass.
Alternatively, the application can render frames “pre-rotated” to avoid
this extra pass.
The latter is preferred to reduce power consumption and achieve the best
performance because it avoids tasking the GPU with extra work to perform the
copy/rotate operation.
Unlike OpenGL ES, the burden of pre-rotation in Vulkan falls on the
application.
To implement pre-rotation, applications render into swapchain images
matching the device native aspect ratio of the display and “pre-rotate”
the rendering content to match the device’s current orientation.
The burden is more than adjusting the Model View Projection (MVP) matrix in
the vertex shader to account for rotation and aspect ratio.
The coordinate systems of scissors, viewports, derivatives, and several
shader built-ins may need to be adapted to produce the correct result.
It is difficult for some game engines to manage this burden; many chose to
simply accept the performance/power overhead of performing rotation in the
presentation engine.
This extension allows applications to achieve the performance benefits of
pre-rotated rendering by moving much of the above-mentioned burden to the
graphics driver.
The following is unchanged with this extension:
Applications create a swapchain matching the native orientation of the
display.
Applications must also set the
VkSwapchainCreateInfoKHR
::
preTransform
equal to the
currentTransform
as returned by
vkGetPhysicalDeviceSurfaceCapabilitiesKHR
The following is changed with this extension:
At
vkCmdBeginRenderPass
, the application provides extension struct
VkRenderPassTransformBeginInfoQCOM
specifying the render pass
transform parameters.
At
vkBeginCommandBuffer
for secondary command buffers, the
application provides extension struct
VkCommandBufferInheritanceRenderPassTransformInfoQCOM
specifying
the render pass transform parameters.
The
renderArea
, viewports, scissors, and
fragmentSize
are
all provided in the current (non-rotated) coordinate system.
The implementation will transform those into the native (rotated)
coordinate system.
The implementation is responsible for transforming shader built-ins
FragCoord
PointCoord
SamplePosition
PrimitiveShadingRateKHR
, interpolateAt(), dFdx, dFdy, fWidth) into
the rotated coordinate system.
The implementation is responsible for transforming
position
to the
rotated coordinate system.
If this extension is used with
VK_QCOM_tile_properties
, then
vkGetFramebufferTilePropertiesQCOM
and
vkGetDynamicRenderingTilePropertiesQCOM
return tile properties in
the rotated coordinate space.
New Structures
Extending
VkCommandBufferInheritanceInfo
VkCommandBufferInheritanceRenderPassTransformInfoQCOM
Extending
VkRenderPassBeginInfo
VkRenderPassTransformBeginInfoQCOM
New Enum Constants
VK_QCOM_RENDER_PASS_TRANSFORM_EXTENSION_NAME
VK_QCOM_RENDER_PASS_TRANSFORM_SPEC_VERSION
Extending
VkRenderPassCreateFlagBits
VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM
VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM
Issues
1) Some early Adreno drivers (October 2019 through March 2020) advertised
support for this extension but expected VK_STRUCTURE_TYPE values different
from those in the vulkan headers.
To cover all Adreno devices on the market, applications need to detect the
driver version and use the appropriate VK_STRUCTURE_TYPE values from the
table below.
The driver version reported in VkPhysicalDeviceProperties.driverVersion is a
uint32_t
type.
You can decode the
uint32_t
value into a major.minor.patch version as
shown below:
uint32_t major = ((driverVersion) >> 22);
uint32_t minor = ((driverVersion) >> 12) & 0x3ff);
uint32_t patch = ((driverVersion) & 0xfff);
If the Adreno major.minor.patch version is greater than or equal to
512.469.0, then simply use the VK_STRUCTURE_TYPE values as defined in
vulkan_core.h.
If the version is less than or equal to 512.468.0, then use the alternate
values for the two VK_STRUCTURE_TYPEs in the table below.
Table 1.
Adreno
Driver Requirements
Adreno Driver Version
512.468.0 and earlier
512.469.0 and later
VK_STRUCTURE_TYPE_ RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM
1000282000
1000282001
VK_STRUCTURE_TYPE_ COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM
1000282001
1000282000
2) Should the extension support only rotations (e.g. 90, 180, 270-degrees),
or also mirror transforms (e.g. vertical flips)? Mobile use cases only
require rotation.
Other display systems such as projectors might require a flipped transform.
RESOLVED
: In this version of the extension, the functionality is
restricted to 90, 180, and 270-degree rotations to address mobile use cases.
3) How does this extension interact with VK_EXT_fragment_density_map?
RESOLVED
Some implementations may not be able to support a render pass
that enables both render pass transform and fragment density maps.
For simplicity, this extension disallows enabling both features within a
single render pass.
4) What should this extension be named?
We considered names such as “rotated_rendering”, “pre_rotation” and
others.
Since the functionality is limited to a render pass, it seemed the name
should include “render_pass”.
While the current extension is limited to rotations, it could be extended to
other transforms (like mirror) in the future.
RESOLVED
The name “render_pass_transform” seems like the most accurate
description of the introduced functionality.
5) How does this extension interact with VK_KHR_fragment_shading_rate?
RESOLVED
: For the same reasons as issue 3, this extension disallows
enabling both
pFragmentShadingRateAttachment
and render pass transform
within a single render pass.
However, pipeline shading rate and primitive shading rate are supported, and
their respective
fragmentSize
and
PrimitiveShadingRateKHR
are
provided in the current (non-rotated) coordinate system.
The implementation is responsible for transforming them to the rotated
coordinate system.
The
set of supported shading rates
may
be different per transform.
Supported rates queried from
vkGetPhysicalDeviceFragmentShadingRatesKHR
are in the native (rotated)
coordinate system.
This means that the application
must
swap the x/y of the reported rates to
get the set of rates supported for 90 and 270 degree rotation.
Version History
Revision 1, 2020-02-05 (Jeff Leger)
Revision 2, 2021-03-09 (Matthew Netsch)
Adds interactions with VK_KHR_fragment_shading_rate
Revision 3, 2022-07-11 (Arpit Agarwal)
Adds interactions with VK_QCOM_tile_properties
Revision 4, 2023-12-13 (Matthew Netsch)
Relax dependencies on VK_KHR_surface and VK_KHR_swapchain
Revision 5, 2025-06-30 (Matthew Netsch)
Fix pNext const on info structs
VK_QCOM_rotated_copy_commands
Name String
VK_QCOM_rotated_copy_commands
Extension Type
Device extension
Registered Extension Number
334
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_copy_commands2
or
Vulkan Version 1.3
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-12-13
Interactions and External Dependencies
This extension interacts with
VK_KHR_swapchain
This extension interacts with
VK_KHR_surface
Contributors
Jeff Leger, Qualcomm Technologies, Inc.
Matthew Netsch, Qualcomm Technologies, Inc.
Description
This extension extends adds an optional rotation transform to copy commands
vkCmdBlitImage2KHR
vkCmdCopyImageToBuffer2KHR
and
vkCmdCopyBufferToImage2KHR
When copying between two resources, where one resource contains rotated
content and the other does not, a rotated copy may be desired.
This extension may be used in combination with VK_QCOM_render_pass_transform
which adds rotated render passes.
This extension adds an extension structure to the commands
vkCmdBlitImage2KHR
vkCmdCopyImageToBuffer2KHR
, and
vkCmdCopyBufferToImage2KHR
Issues
1) What is an appropriate name for the added extension structure? The style
guide says “Structures which extend other structures through the
pNext
chain should reflect the name of the base structure they
extend.”, but in this case a single extension structure is used to extend
three base structures (vkCmdBlitImage2KHR, vkCmdCopyImageToBuffer2KHR, and
vkCmdCopyBufferToImage2KHR).
Creating three identical structures with unique names seemed undesirable.
RESOLVED
: Deviate from the style guide for extension structure naming.
2) Should this extension add a rotation capability to vkCmdCopyImage2KHR?
RESOLVED
: No.
Use of rotated vkCmdBlitImage2KHR can fully address this use case.
3) Should this extension add a rotation capability to vkCmdResolveImage2KHR?
RESOLVED
No.
Use of vkCmdResolveImage2KHR is very slow and extremely bandwidth intensive
on Qualcomm’s GPU architecture and use of pResolveAttachments in
vkRenderPass is the strongly preferred approach.
Therefore, we choose not to introduce a rotation capability to
vkCmdResolveImage2KHR.
New Structures
Extending
VkBufferImageCopy2
VkImageBlit2
VkDeviceMemoryImageCopyKHR
VkCopyCommandTransformInfoQCOM
New Enum Constants
VK_QCOM_ROTATED_COPY_COMMANDS_EXTENSION_NAME
VK_QCOM_ROTATED_COPY_COMMANDS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_COPY_COMMAND_TRANSFORM_INFO_QCOM
Version History
Revision 1, 2020-09-19 (Jeff Leger)
Revision 2, 2023-12-13 (Matthew Netsch)
Relax dependency on VK_KHR_swapchain
VK_QCOM_tile_memory_heap
Name String
VK_QCOM_tile_memory_heap
Extension Type
Device extension
Registered Extension Number
548
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_memory_requirements2
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_QCOM_tile_properties
Contact
Patrick Boyle
pboyleQCOM
Extension Proposal
VK_QCOM_tile_memory_heap
Other Extension Metadata
Last Modified Date
2025-05-05
Interactions and External Dependencies
Interacts with
VK_QCOM_tile_properties
Interacts with
VK_QCOM_tile_shading
Contributors
Patrick Boyle, Qualcomm Technologies, Inc.
Matthew Netsch, Qualcomm Technologies, Inc.
Srihari Babu Alla, Qualcomm Technologies, Inc.
Kevin Matlage, Qualcomm Technologies, Inc.
Description
This extension adds a new memory heap which allows applications to allocate
and manage tile memory.
A tile memory heap is denoted by the new
VK_MEMORY_HEAP_TILE_MEMORY_BIT_QCOM
property.
Memory contents within this heap behave differently than other heaps and
only persist its memory contents within a command buffer submission batch
boundary.
This boundary may be extended to a queue submit boundary by querying
queueSubmitBoundary
in the new
VkPhysicalDeviceTileMemoryHeapPropertiesQCOM
structure.
Tile memory from this heap can be bound to VkImages or VkBuffers.
The following new usage flags
VK_IMAGE_USAGE_TILE_MEMORY_BIT_QCOM
VK_BUFFER_USAGE_TILE_MEMORY_BIT_QCOM
VK_BUFFER_USAGE_2_TILE_MEMORY_BIT_QCOM
were added for this.
A new extended structure is added to get memory requirements for tile memory
VkTileMemoryRequirementsQCOM
A new command is added to bind tile memory to a command buffer in order to
access and persist tile memory contents while executing commands
vkCmdBindTileMemoryQCOM
This extension can be used in combination with
VK_QCOM_tile_properties
with the new structure
VkTileMemorySizeInfoQCOM
Issues
None.
New Commands
vkCmdBindTileMemoryQCOM
New Structures
Extending
VkCommandBufferInheritanceInfo
VkTileMemoryBindInfoQCOM
Extending
VkMemoryRequirements2
VkTileMemoryRequirementsQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTileMemoryHeapFeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTileMemoryHeapPropertiesQCOM
If
VK_QCOM_tile_properties
is supported:
Extending
VkRenderPassCreateInfo
VkRenderPassCreateInfo2
VkRenderingInfo
VkTileMemorySizeInfoQCOM
New Enum Constants
VK_QCOM_TILE_MEMORY_HEAP_EXTENSION_NAME
VK_QCOM_TILE_MEMORY_HEAP_SPEC_VERSION
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_TILE_MEMORY_BIT_QCOM
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_TILE_MEMORY_BIT_QCOM
Extending
VkImageUsageFlagBits
VK_IMAGE_USAGE_TILE_MEMORY_BIT_QCOM
Extending
VkMemoryHeapFlagBits
VK_MEMORY_HEAP_TILE_MEMORY_BIT_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_MEMORY_HEAP_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_MEMORY_HEAP_PROPERTIES_QCOM
VK_STRUCTURE_TYPE_TILE_MEMORY_BIND_INFO_QCOM
VK_STRUCTURE_TYPE_TILE_MEMORY_REQUIREMENTS_QCOM
If
VK_QCOM_tile_properties
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_TILE_MEMORY_SIZE_INFO_QCOM
Version History
Revision 1, 2025-03-26 (Patrick Boyle)
Initial version
VK_QCOM_tile_properties
Name String
VK_QCOM_tile_properties
Extension Type
Device extension
Registered Extension Number
485
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_3
Interacts with VK_KHR_dynamic_rendering
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_tile_properties
Other Extension Metadata
Last Modified Date
2022-07-11
Interactions and External Dependencies
This extension interacts with
VK_EXT_subpass_merge_feedback
Contributors
Jonathan Wicks, Qualcomm Technologies, Inc.
Jonathan Tinkham, Qualcomm Technologies, Inc.
Arpit Agarwal, Qualcomm Technologies, Inc.
Jeff Leger, Qualcomm Technologies, Inc.
Description
This extension allows an application to query the tile properties.
This extension supports both renderpasses and dynamic rendering.
New Commands
vkGetDynamicRenderingTilePropertiesQCOM
vkGetFramebufferTilePropertiesQCOM
New Structures
VkTilePropertiesQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTilePropertiesFeaturesQCOM
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
is supported:
VkRenderingInfoKHR
New Enum Constants
VK_QCOM_TILE_PROPERTIES_EXTENSION_NAME
VK_QCOM_TILE_PROPERTIES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_PROPERTIES_FEATURES_QCOM
VK_STRUCTURE_TYPE_TILE_PROPERTIES_QCOM
Version History
Revision 1, 2022-07-11 (Arpit Agarwal)
Initial version
VK_QCOM_tile_shading
Name String
VK_QCOM_tile_shading
Extension Type
Device extension
Registered Extension Number
310
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_QCOM_tile_properties
SPIR-V Dependencies
SPV_QCOM_tile_shading
Contact
Matthew Netsch
mnetsch
Extension Proposal
VK_QCOM_tile_shading
Other Extension Metadata
Last Modified Date
2025-8-13
IP Status
No known IP claims.
Interactions and External Dependencies
This extension interacts with
VK_KHR_dynamic_rendering
This extension interacts with
VK_EXT_transform_feedback
This extension interacts with
VK_EXT_debug_marker
This extension interacts with
VK_EXT_attachment_feedback_loop_layout
This extension interacts with
VK_KHR_dynamic_rendering_local_read
This extension interacts with
VK_QCOM_image_processing
Contributors
Jeff Leger, Qualcomm
Matt Netsch, Qualcomm
Srihari Babu Alla, Qualcomm
Matthew Smith, Qualcomm
Kevin Matlage, Qualcomm
Alex Bourd, Qualcomm
Description
This extension exposes tile shading in Vulkan.
Many mobile GPUs utilize Tile-Based Deferred Rendering (TBDR) to optimize
for power and performance.
Conversely, most desktop GPUs use immediate-mode rendering (IM).
Adreno ™ GPUs uniquely have the ability to operate in either mode, and
when this extension is not enabled, the Adreno driver will select the most
optimal mode (TBDR or IM) based on the workload; this feature is called
FlexRender ™.
When this extension is in use, FlexRender is disabled and the GPU operates
exclusively in TBDR wherever possible.
The TBDR mode divides the color and depth/stencil buffer attachments into a
regular grid of smaller regions called “tiles”.
When a render pass instance is submitted for execution on an Adreno GPU, the
rendering is split into two phases: a single “visibility pass” followed by
multiple “rendering passes” where a separate render pass is issued for
each tile in the framebuffer.
The “visibility pass” processes the geometry: identifies which tiles are
covered by each primitive, eliminates occluded primitives and unneeded state
changes, and performs other tile-specific optimizations.
The primitive coverage information collected during the visibility pass is
used in the subsequent “rendering pass” for each tile.
During the rendering pass for each tile, any primitives that were determined
not to cover the current tile are skipped.
This deferred rasterization additionally utilizes a specialized
high-bandwidth on-die memory, “tile memory”.
Tile memory is dramatically more efficient than other device memory.
The tile memory temporarily stores the color and other attachments for each
tile during rasterization.
After each tile is fully rasterized, the resulting tile is typically copied
to device memory backing the attachment as specified by the render pass
STORE_OP.
The per-tile rendering passes occur independently for each tile, with
multiple tiles potentially being processed in parallel.
This extension enables applications to leverage the power and performance of
tile memory in new ways:
Adds a mechanism for recording dispatches or draws that are guaranteed
to be executed per-tile.
Such draws bypass the above-mentioned visibility-based skipping and are
guaranteed to be executed for every tile in the rendering pass.
Shaders can declare “tile attachments” variables, providing shader
access to color, depth/stencil, and input attachment pixels.
Fragment and compute shaders can read these render pass attachments at
any location within the tile.
Compute shaders can also write to color attachments at any location
within the tile.
Shaders can use new built-in variables that provide the location, size,
and apron region of the tile.
A new tile dispatch command automatically scales workgroup sizes and
counts to the tile size, given a desired shading rate.
Framebuffer-local dependencies are expanded to tile-sized regions,
rather than a single pixel or sample.
A tile shading render pass can also enable tiling “aprons”.
This is a specialized rendering mode where the GPU renders overlapping
tiles that enable specific use cases.
New Commands
vkCmdBeginPerTileExecutionQCOM
vkCmdDispatchTileQCOM
vkCmdEndPerTileExecutionQCOM
New Structures
VkDispatchTileInfoQCOM
VkPerTileBeginInfoQCOM
VkPerTileEndInfoQCOM
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTileShadingFeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTileShadingPropertiesQCOM
Extending
VkRenderPassCreateInfo
VkRenderPassCreateInfo2
VkRenderingInfo
VkCommandBufferInheritanceInfo
VkRenderPassTileShadingCreateInfoQCOM
New Enums
VkTileShadingRenderPassFlagBitsQCOM
New Bitmasks
VkTileShadingRenderPassFlagsQCOM
New Enum Constants
VK_QCOM_TILE_SHADING_EXTENSION_NAME
VK_QCOM_TILE_SHADING_SPEC_VERSION
Extending
VkAccessFlagBits2
VK_ACCESS_2_SHADER_TILE_ATTACHMENT_READ_BIT_QCOM
VK_ACCESS_2_SHADER_TILE_ATTACHMENT_WRITE_BIT_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_DISPATCH_TILE_INFO_QCOM
VK_STRUCTURE_TYPE_PER_TILE_BEGIN_INFO_QCOM
VK_STRUCTURE_TYPE_PER_TILE_END_INFO_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_SHADING_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_SHADING_PROPERTIES_QCOM
VK_STRUCTURE_TYPE_RENDER_PASS_TILE_SHADING_CREATE_INFO_QCOM
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_TILE_SHADING_APRON_BIT_QCOM
New or Modified Built-In Variables
TileOffsetQCOM
TileDimensionQCOM
TileApronSizeQCOM
New SPIR-V Capabilities
TileShadingQCOM
Issues
1) Some early Adreno drivers advertised support for version 1 of this
extension without supporting the required
tileShadingApron
feature.
To cover all Adreno devices on the market, applications should not assume
any version of this extension supports the
tileShadingApron
feature
without performing a feature query.
Version History
Revision 2, 2025-08-13 (Matthew Netsch)
Make the
tileShadingApron
feature optional
Revision 1, 2023-10-12 (Jeff Leger)
VK_QCOM_ycbcr_degamma
Name String
VK_QCOM_ycbcr_degamma
Extension Type
Device extension
Registered Extension Number
521
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2023-07-31
IP Status
No known IP claims.
Interactions and External Dependencies
None
Contributors
Jeff Leger, Qualcomm
Jonathan Wicks, Qualcomm
Description
This extension allows implementations to expose support for “sRGB EOTF”
also known as “sRGB degamma”, used in combination with images using 8-bit
Y′C
formats.
In addition, the degamma can be selectively applied to the Y (luma) or CrCb
(chroma).
VK_KHR_sampler_ycbcr_conversion
adds support for Y′C
conversion, but allows texture sampling in a non-linear space which can
cause artifacts.
This extension allows implementations to expose sRGB degamma for Y′C
formats, which is performed during texture filtering, allowing texture
filtering to operate in a linear space.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceYcbcrDegammaFeaturesQCOM
Extending
VkSamplerYcbcrConversionCreateInfo
VkSamplerYcbcrConversionYcbcrDegammaCreateInfoQCOM
New Enum Constants
VK_QCOM_YCBCR_DEGAMMA_EXTENSION_NAME
VK_QCOM_YCBCR_DEGAMMA_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_DEGAMMA_FEATURES_QCOM
VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_YCBCR_DEGAMMA_CREATE_INFO_QCOM
Issues
1) Which Y′C
formats support the degamma feature?
RESOLVED
: For implementations that support the extension, each format that
contains 8-bit R, G, and B components and supports either
VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT
or
VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT
must support degamma.
Since non-compressed Vulkan sRGB formats are already limited to 8-bit
components, and since Adreno supports degamma for all 8bit Y′C
formats,
this extension does not introduce a new VK_FORMAT_FEATURE* bit for the
degamma feature.
2) On which Y′C
components is the degamma applied?
RESOLVED
: While degamma is expected to be applied to only the Y (luma)
component, the extension provides the ability to selectively enable degamma
for both the Y (luma) and/or CbCr (chroma) components.
3) Should degamma be enabled for the sampler object or for the image view
object?
RESOLVED
: Both.
This extension extends
VkSamplerYcbcrConversionCreateInfo
and the
specification already requires that both sampler and view objects must be
created with an
identical
VkSamplerYcbcrConversionCreateInfo
in
their pNext chains.
4) Why apply the “sRGB” transfer function directly to Y′C
data when it
would be more correct to use the “ITU transfer function”, and do so only
after the values have been converted into non-linear R’G’B'?
RESOLVED
: Y′C
is frequently stored according to standards (e.g. BT.601
and BT.709) that specify that the conversion between linear and non-linear
should use the ITU Transfer function.
The ITU transfer function is mathematically different from the sRGB transfer
function and while sRGB and ITU define similar curves, the difference is
significant.
Performing the “sRGB degamma” prior to range expansion can introduce
artifacts if the content uses
VK_SAMPLER_YCBCR_RANGE_ITU_NARROW
encoding.
Nevertheless, using sRGB can make sense for certain use cases where camera
YCbCr images are known to be encoded with sRGB (or a pure gamma 2.2)
transfer function and are known to use full-range encoding.
For those use cases, this extension leverages the GPU ability to enable sRGB
degamma at little cost, and can improve quality because texture filtering is
able to occur in linear space.
Version History
Revision 1, 2023-07-31 (Jeff Leger)
VK_QNX_external_memory_screen_buffer
Name String
VK_QNX_external_memory_screen_buffer
Extension Type
Device extension
Registered Extension Number
530
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
and
VK_KHR_external_memory
and
VK_KHR_dedicated_allocation
or
Vulkan Version 1.1
and
VK_EXT_queue_family_foreign
Contact
Mike Gorchak
mgorchak-blackberry
Aaron Ruby
aruby-blackberry
Other Extension Metadata
Last Modified Date
2023-05-17
IP Status
No known IP claims.
Contributors
Mike Gorchak, QNX / Blackberry Limited
Aaron Ruby, QNX / Blackberry Limited
Description
This extension enables an application to import QNX Screen
_screen_buffer
objects created outside of the Vulkan device into Vulkan
memory objects, where they can be bound to images and buffers.
Some
_screen_buffer
images have implementation-defined
external
formats
that
may
not correspond to Vulkan formats.
Sampler Y′C
conversion
can
be used to sample from these images and
convert them to a known color space.
_screen_buffer
is strongly typed, so naming the handle type is
redundant.
The internal layout and therefore size of a
_screen_buffer
image may
depend on native usage flags that do not have corresponding Vulkan
counterparts.
New Commands
vkGetScreenBufferPropertiesQNX
New Structures
VkScreenBufferPropertiesQNX
Extending
VkImageCreateInfo
VkSamplerYcbcrConversionCreateInfo
VkExternalFormatQNX
Extending
VkMemoryAllocateInfo
VkImportScreenBufferInfoQNX
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExternalMemoryScreenBufferFeaturesQNX
Extending
VkScreenBufferPropertiesQNX
VkScreenBufferFormatPropertiesQNX
New Enum Constants
VK_QNX_EXTERNAL_MEMORY_SCREEN_BUFFER_EXTENSION_NAME
VK_QNX_EXTERNAL_MEMORY_SCREEN_BUFFER_SPEC_VERSION
Extending
VkExternalMemoryHandleTypeFlagBits
VK_EXTERNAL_MEMORY_HANDLE_TYPE_SCREEN_BUFFER_BIT_QNX
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_QNX
VK_STRUCTURE_TYPE_IMPORT_SCREEN_BUFFER_INFO_QNX
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_SCREEN_BUFFER_FEATURES_QNX
VK_STRUCTURE_TYPE_SCREEN_BUFFER_FORMAT_PROPERTIES_QNX
VK_STRUCTURE_TYPE_SCREEN_BUFFER_PROPERTIES_QNX
Issues
Version History
Revision 1, 2023-05-17 (Mike Gorchak)
Initial version
VK_QNX_screen_surface
Name String
VK_QNX_screen_surface
Extension Type
Instance extension
Registered Extension Number
379
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Mike Gorchak
mgorchak-blackberry
Other Extension Metadata
Last Modified Date
2021-01-11
IP Status
No known IP claims.
Contributors
Mike Gorchak, BlackBerry Limited
Description
The
VK_QNX_screen_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 QNX Screen
window
, as well as a query to determine support for rendering to a QNX
Screen compositor.
New Commands
vkCreateScreenSurfaceQNX
vkGetPhysicalDeviceScreenPresentationSupportQNX
New Structures
VkScreenSurfaceCreateInfoQNX
New Bitmasks
VkScreenSurfaceCreateFlagsQNX
New Enum Constants
VK_QNX_SCREEN_SURFACE_EXTENSION_NAME
VK_QNX_SCREEN_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_SCREEN_SURFACE_CREATE_INFO_QNX
Version History
Revision 1, 2021-01-11 (Mike Gorchak)
Initial draft.
VK_SEC_amigo_profiling
Name String
VK_SEC_amigo_profiling
Extension Type
Device extension
Registered Extension Number
486
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Ralph Potter
r_potter
Other Extension Metadata
Last Modified Date
2022-07-29
IP Status
No known IP claims.
Contributors
Ralph Potter, Samsung
Sangrak Oh, Samsung
Jinku Kang, Samsung
Description
This extension is intended to communicate information from layered API
implementations such as ANGLE to internal proprietary system schedulers.
It has no behavioral implications beyond enabling more intelligent behavior
from the system scheduler.
Application developers should avoid using this extension.
It is documented solely for the benefit of tools and layer developers, who
may need to manipulate
pNext
chains that include these structures.
There is currently no specification language written for this extension.
The links to APIs defined by the extension are to stubs that only include
generated content such as API declarations and implicit valid usage
statements.
This extension is only intended for use in specific embedded environments
with known implementation details, and is therefore undocumented.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceAmigoProfilingFeaturesSEC
Extending
VkSubmitInfo
VkAmigoProfilingSubmitInfoSEC
New Enum Constants
VK_SEC_AMIGO_PROFILING_EXTENSION_NAME
VK_SEC_AMIGO_PROFILING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC
Stub API References
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_SEC_amigo_profiling
typedef struct VkPhysicalDeviceAmigoProfilingFeaturesSEC {
VkStructureType sType;
void* pNext;
VkBool32 amigoProfiling;
} VkPhysicalDeviceAmigoProfilingFeaturesSEC;
Valid Usage (Implicit)
VUID-VkPhysicalDeviceAmigoProfilingFeaturesSEC-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC
Structure Chaining
Extends the structures
VkDeviceCreateInfo
VkPhysicalDeviceFeatures2
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_SEC_amigo_profiling
typedef struct VkAmigoProfilingSubmitInfoSEC {
VkStructureType sType;
const void* pNext;
uint64_t firstDrawTimestamp;
uint64_t swapBufferTimestamp;
} VkAmigoProfilingSubmitInfoSEC;
Valid Usage (Implicit)
VUID-VkAmigoProfilingSubmitInfoSEC-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC
Structure Chaining
Extends the structure
VkSubmitInfo
Version History
Revision 1, 2022-07-29 (Ralph Potter)
Initial specification
VK_SEC_pipeline_cache_incremental_mode
Name String
VK_SEC_pipeline_cache_incremental_mode
Extension Type
Device extension
Registered Extension Number
638
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Contact
Chris Hambacher
chambacher
Other Extension Metadata
Last Modified Date
2025-06-24
IP Status
No known IP claims.
Contributors
Chris Hambacher, Samsung
Mohan Maiya, Samsung
Brandon Schade, Samsung
Description
This extension allows layered implementations such as ANGLE to modify the
default behavior of VkPipelineCache to return only the incremental data from
the previous call to vkGetPipelineCacheData.
Application developers should avoid using this extension.
There is currently no specification language written for this extension.
The links to APIs defined by the extension are to stubs that only include
generated content such as API declarations and implicit valid usage
statements.
This extension is only intended for use in specific embedded environments
with known implementation details, and is therefore undocumented.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineCacheIncrementalModeFeaturesSEC
New Enum Constants
VK_SEC_PIPELINE_CACHE_INCREMENTAL_MODE_EXTENSION_NAME
VK_SEC_PIPELINE_CACHE_INCREMENTAL_MODE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CACHE_INCREMENTAL_MODE_FEATURES_SEC
Stub API References
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_SEC_pipeline_cache_incremental_mode
typedef struct VkPhysicalDevicePipelineCacheIncrementalModeFeaturesSEC {
VkStructureType sType;
void* pNext;
VkBool32 pipelineCacheIncrementalMode;
} VkPhysicalDevicePipelineCacheIncrementalModeFeaturesSEC;
Valid Usage (Implicit)
VUID-VkPhysicalDevicePipelineCacheIncrementalModeFeaturesSEC-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CACHE_INCREMENTAL_MODE_FEATURES_SEC
Structure Chaining
Extends the structures
VkDeviceCreateInfo
VkPhysicalDeviceFeatures2
Version History
Revision 1, 2025-06-24 (Chris Hambacher)
Initial specification
VK_SEC_ubm_surface
Name String
VK_SEC_ubm_surface
Extension Type
Instance extension
Registered Extension Number
665
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Contact
Minji Choe
minjichoe
Other Extension Metadata
Last Modified Date
2026-01-26
IP Status
No known IP claims.
Contributors
Ralph Potter, Samsung
Isaac Hong, Samsung
Jaeyoung Park, Samsung
Changhwan Lee, Samsung
Minji Choe, Samsung
Krzysztof Buben, Samsung
Mikolaj Chadzynski, Samsung
Bohdan Soproniuk, Samsung
Description
The
VK_SEC_ubm_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 UBM
ubm_surface
, as well as a query to determine support for rendering to a
UBM compositor.
New Commands
vkCreateUbmSurfaceSEC
vkGetPhysicalDeviceUbmPresentationSupportSEC
New Structures
VkUbmSurfaceCreateInfoSEC
New Bitmasks
VkUbmSurfaceCreateFlagsSEC
New Enum Constants
VK_SEC_UBM_SURFACE_EXTENSION_NAME
VK_SEC_UBM_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_UBM_SURFACE_CREATE_INFO_SEC
Issues
1) Does UBM 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.
vkGetPhysicalDeviceUbmPresentationSupportSEC
was added to address this
issue.
Version History
Revision 1, 2026-01-30 (Krzysztof Buben)
Initial draft, based on the previous contents of VK_EXT_KHR_swapchain
(later renamed VK_EXT_KHR_surface).
VK_VALVE_descriptor_set_host_mapping
Name String
VK_VALVE_descriptor_set_host_mapping
Extension Type
Device extension
Registered Extension Number
421
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Special Use
D3D support
Contact
Hans-Kristian Arntzen
HansKristian-Work
Other Extension Metadata
Last Modified Date
2022-02-22
IP Status
No known IP claims.
Contributors
Hans-Kristian Arntzen, Valve
Description
This extension allows applications to directly query a host pointer for a
VkDescriptorSet
which
can
be used to copy descriptors between
descriptor sets without the use of an API command.
Memory offsets and sizes for descriptors
can
be queried from a
VkDescriptorSetLayout
as well.
There is currently no specification language written for this extension.
The links to APIs defined by the extension are to stubs that only include
generated content such as API declarations and implicit valid usage
statements.
This extension is only intended for use in specific embedded environments
with known implementation details, and is therefore undocumented.
New Commands
vkGetDescriptorSetHostMappingVALVE
vkGetDescriptorSetLayoutHostMappingInfoVALVE
New Structures
VkDescriptorSetBindingReferenceVALVE
VkDescriptorSetLayoutHostMappingInfoVALVE
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE
New Enum Constants
VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_EXTENSION_NAME
VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE
Stub API References
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetLayoutHostMappingInfoVALVE(
VkDevice device,
const VkDescriptorSetBindingReferenceVALVE* pBindingReference,
VkDescriptorSetLayoutHostMappingInfoVALVE* pHostMapping);
Valid Usage (Implicit)
VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pBindingReference-parameter
pBindingReference
must
be a valid pointer to a valid
VkDescriptorSetBindingReferenceVALVE
structure
VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pHostMapping-parameter
pHostMapping
must
be a valid pointer to a
VkDescriptorSetLayoutHostMappingInfoVALVE
structure
There is currently no specification language written for this command.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetHostMappingVALVE(
VkDevice device,
VkDescriptorSet descriptorSet,
void** ppData);
Valid Usage (Implicit)
VUID-vkGetDescriptorSetHostMappingVALVE-device-parameter
device
must
be a valid
VkDevice
handle
VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parameter
descriptorSet
must
be a valid
VkDescriptorSet
handle
VUID-vkGetDescriptorSetHostMappingVALVE-ppData-parameter
ppData
must
be a valid pointer to a pointer value
VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parent
descriptorSet
must
have been created, allocated, or retrieved from
device
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE {
VkStructureType sType;
void* pNext;
VkBool32 descriptorSetHostMapping;
} VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE;
Valid Usage (Implicit)
VUID-VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE
Structure Chaining
Extends the structures
VkDeviceCreateInfo
VkPhysicalDeviceFeatures2
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetBindingReferenceVALVE {
VkStructureType sType;
const void* pNext;
VkDescriptorSetLayout descriptorSetLayout;
uint32_t binding;
} VkDescriptorSetBindingReferenceVALVE;
Valid Usage (Implicit)
VUID-VkDescriptorSetBindingReferenceVALVE-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE
VUID-VkDescriptorSetBindingReferenceVALVE-pNext-pNext
pNext
must
be
NULL
VUID-VkDescriptorSetBindingReferenceVALVE-descriptorSetLayout-parameter
descriptorSetLayout
must
be a valid
VkDescriptorSetLayout
handle
There is currently no specification language written for this type.
This section acts only as placeholder and to avoid dead links in the
specification and reference pages.
// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetLayoutHostMappingInfoVALVE {
VkStructureType sType;
void* pNext;
size_t descriptorOffset;
uint32_t descriptorSize;
} VkDescriptorSetLayoutHostMappingInfoVALVE;
Valid Usage (Implicit)
VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-sType-sType
sType
must
be
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE
VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-pNext-pNext
pNext
must
be
NULL
Version History
Revision 1, 2022-02-22 (Hans-Kristian Arntzen)
Initial specification
VK_VALVE_fragment_density_map_layered
Name String
VK_VALVE_fragment_density_map_layered
Extension Type
Device extension
Registered Extension Number
612
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_maintenance5
or
Vulkan Version 1.4
and
VK_EXT_fragment_density_map
Contact
Connor Abbott
cwabbott0
Other Extension Metadata
Last Modified Date
2025-06-06
Interactions and External Dependencies
Interacts with Vulkan 1.1.
Interacts with Vulkan 1.3.
Interacts with Vulkan 1.4.
Interacts with
VK_EXT_fragment_density_map
IP Status
No known IP claims.
Contributors
Connor Abbott, VALVE
Mike Blumenkrantz, VALVE
Description
This extension enables the use of layered fragment density maps.
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkPipelineFragmentDensityMapLayeredCreateInfoVALVE
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentDensityMapLayeredFeaturesVALVE
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentDensityMapLayeredPropertiesVALVE
New Enum Constants
VK_VALVE_FRAGMENT_DENSITY_MAP_LAYERED_EXTENSION_NAME
VK_VALVE_FRAGMENT_DENSITY_MAP_LAYERED_SPEC_VERSION
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_PER_LAYER_FRAGMENT_DENSITY_BIT_VALVE
Extending
VkRenderingFlagBits
VK_RENDERING_PER_LAYER_FRAGMENT_DENSITY_BIT_VALVE
Extending
VkRenderPassCreateFlagBits
VK_RENDER_PASS_CREATE_PER_LAYER_FRAGMENT_DENSITY_BIT_VALVE
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_LAYERED_FEATURES_VALVE
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_LAYERED_PROPERTIES_VALVE
VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_DENSITY_MAP_LAYERED_CREATE_INFO_VALVE
Version History
Revision 1, 2025-06-06 (Mike Blumenkrantz)
Initial version
VK_VALVE_shader_mixed_float_dot_product
Name String
VK_VALVE_shader_mixed_float_dot_product
Extension Type
Device extension
Registered Extension Number
674
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_shader_float16_int8
or
Vulkan Version 1.2
SPIR-V Dependencies
SPV_VALVE_mixed_float_dot_product
Contact
Georg Lehmann
DadSchoorse
Other Extension Metadata
Last Modified Date
2026-02-04
IP Status
No known IP claims.
Contributors
Georg Lehmann, Valve
Mike Blumenkrantz, Valve
Description
This extension enables support for mixed precision dot product accumulate
operations in shaders as defined in
SPV_VALVE_mixed_float_dot_product
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderMixedFloatDotProductFeaturesVALVE
New Enum Constants
VK_VALVE_SHADER_MIXED_FLOAT_DOT_PRODUCT_EXTENSION_NAME
VK_VALVE_SHADER_MIXED_FLOAT_DOT_PRODUCT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MIXED_FLOAT_DOT_PRODUCT_FEATURES_VALVE
New SPIR-V Capabilities
DotProductFloat16AccFloat32VALVE
DotProductFloat16AccFloat16VALVE
DotProductBFloat16AccVALVE
DotProductFloat8AccFloat32VALVE
Version History
Revision 1, 2026-02-04 (Georg Lehmann)
Initial specification
VK_VALVE_video_encode_rgb_conversion
Name String
VK_VALVE_video_encode_rgb_conversion
Extension Type
Device extension
Registered Extension Number
391
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_video_encode_queue
and
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
Contact
Autumn Ashton
misyltoad
Other Extension Metadata
Last Modified Date
2025-08-22
IP Status
No known IP claims.
Contributors
Autumn Ashton, Valve
Daniel Rakos, RasterGrid
Description
This extension builds upon the
VK_KHR_video_encode_queue
extension
by enabling the application to pass in RGB/RGBA images in video encode
operations.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVideoEncodeRgbConversionFeaturesVALVE
Extending
VkVideoCapabilitiesKHR
VkVideoEncodeRgbConversionCapabilitiesVALVE
Extending
VkVideoProfileInfoKHR
VkVideoEncodeProfileRgbConversionInfoVALVE
Extending
VkVideoSessionCreateInfoKHR
VkVideoEncodeSessionRgbConversionCreateInfoVALVE
New Enums
VkVideoEncodeRgbChromaOffsetFlagBitsVALVE
VkVideoEncodeRgbModelConversionFlagBitsVALVE
VkVideoEncodeRgbRangeCompressionFlagBitsVALVE
New Bitmasks
VkVideoEncodeRgbChromaOffsetFlagsVALVE
VkVideoEncodeRgbModelConversionFlagsVALVE
VkVideoEncodeRgbRangeCompressionFlagsVALVE
New Enum Constants
VK_VALVE_VIDEO_ENCODE_RGB_CONVERSION_EXTENSION_NAME
VK_VALVE_VIDEO_ENCODE_RGB_CONVERSION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_ENCODE_RGB_CONVERSION_FEATURES_VALVE
VK_STRUCTURE_TYPE_VIDEO_ENCODE_PROFILE_RGB_CONVERSION_INFO_VALVE
VK_STRUCTURE_TYPE_VIDEO_ENCODE_RGB_CONVERSION_CAPABILITIES_VALVE
VK_STRUCTURE_TYPE_VIDEO_ENCODE_SESSION_RGB_CONVERSION_CREATE_INFO_VALVE
Version History
Revision 1, 2025-08-22 (Autumn Ashton)
Initial version
List of Provisional Extensions
VK_KHR_portability_subset
Name String
VK_KHR_portability_subset
Extension Type
Device extension
Registered Extension Number
164
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePortabilitySubsetFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePortabilitySubsetPropertiesKHR
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
Issues
None.
Version History
Revision 1, 2020-07-21 (Bill Hollings)
Initial draft.
VK_AMDX_dense_geometry_format
Name String
VK_AMDX_dense_geometry_format
Extension Type
Device extension
Registered Extension Number
479
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_acceleration_structure
and
VK_KHR_maintenance5
or
Vulkan Version 1.4
This is a
provisional
extension and
must
be used with caution.
See the
description
of provisional header files for enablement and stability details.
Contact
Stu Smith
stu-s
Extension Proposal
VK_AMDX_dense_geometry_format
Other Extension Metadata
Last Modified Date
2025-07-10
IP Status
No known IP claims.
Contributors
Stu Smith, AMD
Josh Barczak, AMD
Carsten Benthin, AMD
David McAllister, AMD
Description
This extension adds the ability to build ray tracing acceleration structures
from pre-compressed
Dense Geometry Format
geometry data.
New Structures
Extending
VkAccelerationStructureGeometryKHR
VkAccelerationStructureDenseGeometryFormatTrianglesDataAMDX
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDenseGeometryFormatFeaturesAMDX
New Enums
VkCompressedTriangleFormatAMDX
New Enum Constants
VK_AMDX_DENSE_GEOMETRY_FORMAT_EXTENSION_NAME
VK_AMDX_DENSE_GEOMETRY_FORMAT_SPEC_VERSION
VK_COMPRESSED_TRIANGLE_FORMAT_DGF1_BYTE_ALIGNMENT_AMDX
VK_COMPRESSED_TRIANGLE_FORMAT_DGF1_BYTE_STRIDE_AMDX
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_COMPRESSED_DATA_DGF1_BIT_AMDX
Extending
VkGeometryTypeKHR
VK_GEOMETRY_TYPE_DENSE_GEOMETRY_FORMAT_TRIANGLES_AMDX
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_DENSE_GEOMETRY_FORMAT_TRIANGLES_DATA_AMDX
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DENSE_GEOMETRY_FORMAT_FEATURES_AMDX
Issues
None.
Examples
None.
Version History
Revision 1, 2025-07-10 (Stu Smith)
Initial revision.
VK_AMDX_shader_enqueue
Name String
VK_AMDX_shader_enqueue
Extension Type
Device extension
Registered Extension Number
135
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_synchronization2
and
VK_KHR_spirv_1_4
and
VK_EXT_extended_dynamic_state
or
Vulkan Version 1.3
and
VK_KHR_maintenance5
and
VK_KHR_pipeline_library
This is a
provisional
extension and
must
be used with caution.
See the
description
of provisional header files for enablement and stability details.
API Interactions
Interacts with VK_VERSION_1_4
Interacts with VK_EXT_mesh_shader
Interacts with VK_KHR_maintenance5
Contact
Tobias Hector
tobski
Extension Proposal
VK_AMDX_shader_enqueue
Other Extension Metadata
Last Modified Date
2024-07-17
Provisional
This extension is
provisional
and
should
not be used in production
applications.
The functionality
may
change in ways that break backwards compatibility
between revisions, and before final release.
Contributors
Tobias Hector, AMD
Matthaeus Chajdas, AMD
Maciej Jesionowski, AMD
Robert Martin, AMD
Qun Lin, AMD
Rex Xu, AMD
Dominik Witczak, AMD
Karthik Srinivasan, AMD
Nicolai Haehnle, AMD
Stuart Smith, AMD
Description
This extension adds the ability for developers to enqueue mesh and compute
shader workgroups from other compute shaders.
New Commands
vkCmdDispatchGraphAMDX
vkCmdDispatchGraphIndirectAMDX
vkCmdDispatchGraphIndirectCountAMDX
vkCmdInitializeGraphScratchMemoryAMDX
vkCreateExecutionGraphPipelinesAMDX
vkGetExecutionGraphPipelineNodeIndexAMDX
vkGetExecutionGraphPipelineScratchSizeAMDX
New Structures
VkDispatchGraphCountInfoAMDX
VkDispatchGraphInfoAMDX
VkExecutionGraphPipelineCreateInfoAMDX
VkExecutionGraphPipelineScratchSizeAMDX
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderEnqueueFeaturesAMDX
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderEnqueuePropertiesAMDX
Extending
VkPipelineShaderStageCreateInfo
VkPipelineShaderStageNodeCreateInfoAMDX
New Unions
VkDeviceOrHostAddressConstAMDX
New Enum Constants
VK_AMDX_SHADER_ENQUEUE_EXTENSION_NAME
VK_AMDX_SHADER_ENQUEUE_SPEC_VERSION
VK_SHADER_INDEX_UNUSED_AMDX
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_EXECUTION_GRAPH_SCRATCH_BIT_AMDX
Extending
VkPipelineBindPoint
VK_PIPELINE_BIND_POINT_EXECUTION_GRAPH_AMDX
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXECUTION_GRAPH_PIPELINE_CREATE_INFO_AMDX
VK_STRUCTURE_TYPE_EXECUTION_GRAPH_PIPELINE_SCRATCH_SIZE_AMDX
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ENQUEUE_FEATURES_AMDX
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ENQUEUE_PROPERTIES_AMDX
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_NODE_CREATE_INFO_AMDX
If
VK_KHR_maintenance5
or
Vulkan Version 1.4
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_EXECUTION_GRAPH_SCRATCH_BIT_AMDX
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_EXECUTION_GRAPH_BIT_AMDX
Version History
Revision 2, 2024-07-17 (Tobias Hector)
Add mesh nodes
Revision 1, 2021-07-22 (Tobias Hector)
Initial revision
VK_NV_cuda_kernel_launch
Name String
VK_NV_cuda_kernel_launch
Extension Type
Device extension
Registered Extension Number
308
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
This is a
provisional
extension and
must
be used with caution.
See the
description
of provisional header files for enablement and stability details.
API Interactions
Interacts with VK_EXT_debug_report
Contact
Tristan Lorach
tlorach
Other Extension Metadata
Last Modified Date
2020-09-30
Contributors
Eric Werness, NVIDIA
Description
Interoperability between APIs can sometimes create additional overhead
depending on the platform used.
This extension targets deployment of existing CUDA kernels via Vulkan, with
a way to directly upload PTX kernels and dispatch the kernels from Vulkan’s
command buffer without the need to use interoperability between the Vulkan
and CUDA contexts.
However, we do encourage actual development using the native CUDA runtime
for the purpose of debugging and profiling.
The application will first have to create a CUDA module using
vkCreateCudaModuleNV
then create the CUDA function entry point with
vkCreateCudaFunctionNV
Then in order to dispatch this function, the application will create a
command buffer where it will launch the kernel with
vkCmdCudaLaunchKernelNV
When done, the application will then destroy the function handle, as well as
the CUDA module handle with
vkDestroyCudaFunctionNV
and
vkDestroyCudaModuleNV
To reduce the impact of compilation time, this extension offers the
capability to return a binary cache from the PTX that was provided.
For this, a first query for the required cache size is made with
vkGetCudaModuleCacheNV
with a
NULL
pointer to a buffer and with a
valid pointer receiving the size; then another call of the same function
with a valid pointer to a buffer to retrieve the data.
The resulting cache could then be used later for further runs of this
application by sending this cache instead of the PTX code (using the same
vkCreateCudaModuleNV
), thus significantly speeding up the
initialization of the CUDA module.
As with
VkPipelineCache
, the binary cache depends on the hardware
architecture.
The application must assume the cache might fail, and need to handle falling
back to the original PTX code as necessary.
Most often, the cache will succeed if the same GPU driver and architecture
is used between the cache generation from PTX and the use of this cache.
In the event of a new driver version, or if using a different GPU
architecture, the cache is likely to become invalid.
New Object Types
VkCudaFunctionNV
VkCudaModuleNV
New Commands
vkCmdCudaLaunchKernelNV
vkCreateCudaFunctionNV
vkCreateCudaModuleNV
vkDestroyCudaFunctionNV
vkDestroyCudaModuleNV
vkGetCudaModuleCacheNV
New Structures
VkCudaFunctionCreateInfoNV
VkCudaLaunchInfoNV
VkCudaModuleCreateInfoNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCudaKernelLaunchFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCudaKernelLaunchPropertiesNV
New Enum Constants
VK_NV_CUDA_KERNEL_LAUNCH_EXTENSION_NAME
VK_NV_CUDA_KERNEL_LAUNCH_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_CUDA_FUNCTION_NV
VK_OBJECT_TYPE_CUDA_MODULE_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_CUDA_FUNCTION_CREATE_INFO_NV
VK_STRUCTURE_TYPE_CUDA_LAUNCH_INFO_NV
VK_STRUCTURE_TYPE_CUDA_MODULE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUDA_KERNEL_LAUNCH_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUDA_KERNEL_LAUNCH_PROPERTIES_NV
If
VK_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_FUNCTION_NV_EXT
VK_DEBUG_REPORT_OBJECT_TYPE_CUDA_MODULE_NV_EXT
Issues
None.
Version History
Revision 1, 2020-03-01 (Tristan Lorach)
Revision 2, 2020-09-30 (Tristan Lorach)
List of Deprecated Extensions
VK_KHR_16bit_storage
Name String
VK_KHR_16bit_storage
Extension Type
Device extension
Registered Extension Number
84
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_storage_buffer_storage_class
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_16bit_storage
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.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
storageBuffer16BitAccess
capability is required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevice16BitStorageFeaturesKHR
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
New SPIR-V Capabilities
StorageBuffer16BitAccess
UniformAndStorageBuffer16BitAccess
StoragePushConstant16
StorageInputOutput16
Version History
Revision 1, 2017-03-23 (Alexander Galazin)
Initial draft
VK_KHR_8bit_storage
Name String
VK_KHR_8bit_storage
Extension Type
Device extension
Registered Extension Number
178
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_storage_buffer_storage_class
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_8bit_storage
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
Vulkan APIs in this extension are 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.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
storageBuffer8BitAccess
capability is required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevice8BitStorageFeaturesKHR
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
New SPIR-V Capabilities
StorageBuffer8BitAccess
UniformAndStorageBuffer8BitAccess
StoragePushConstant8
Version History
Revision 1, 2018-02-05 (Alexander Galazin)
Initial draft
VK_KHR_bind_memory2
Name String
VK_KHR_bind_memory2
Extension Type
Device extension
Registered Extension Number
158
Revision
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 Commands
vkBindBufferMemory2KHR
vkBindImageMemory2KHR
New Structures
VkBindBufferMemoryInfoKHR
VkBindImageMemoryInfoKHR
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
Version History
Revision 1, 2017-05-19 (Tobias Hector)
Pulled bind memory functions into their own extension
VK_KHR_buffer_device_address
Name String
VK_KHR_buffer_device_address
Extension Type
Device extension
Registered Extension Number
258
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_device_group
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_physical_storage_buffer
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
and
GL_EXT_buffer_reference2
and
GL_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
If Vulkan 1.3 is supported, support for the
bufferDeviceAddress
capability is required.
New Commands
vkGetBufferDeviceAddressKHR
vkGetBufferOpaqueCaptureAddressKHR
vkGetDeviceMemoryOpaqueCaptureAddressKHR
New Structures
VkBufferDeviceAddressInfoKHR
VkDeviceMemoryOpaqueCaptureAddressInfoKHR
Extending
VkBufferCreateInfo
VkBufferOpaqueCaptureAddressCreateInfoKHR
Extending
VkMemoryAllocateInfo
VkMemoryOpaqueCaptureAddressAllocateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceBufferDeviceAddressFeaturesKHR
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
New SPIR-V Capabilities
PhysicalStorageBufferAddresses
Version History
Revision 1, 2019-06-24 (Jan-Harald Fredriksen)
Internal revisions based on VK_EXT_buffer_device_address
VK_KHR_copy_commands2
Name String
VK_KHR_copy_commands2
Extension Type
Device extension
Registered Extension Number
338
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Matthew Netsch
mnetsch
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 Commands
vkCmdBlitImage2KHR
vkCmdCopyBuffer2KHR
vkCmdCopyBufferToImage2KHR
vkCmdCopyImage2KHR
vkCmdCopyImageToBuffer2KHR
vkCmdResolveImage2KHR
New Structures
VkBlitImageInfo2KHR
VkBufferCopy2KHR
VkBufferImageCopy2KHR
VkCopyBufferInfo2KHR
VkCopyBufferToImageInfo2KHR
VkCopyImageInfo2KHR
VkCopyImageToBufferInfo2KHR
VkImageBlit2KHR
VkImageCopy2KHR
VkImageResolve2KHR
VkResolveImageInfo2KHR
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
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2020-07-06 (Jeff Leger)
Internal revisions
VK_KHR_create_renderpass2
Name String
VK_KHR_create_renderpass2
Extension Type
Device extension
Registered Extension Number
110
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_multiview
and
VK_KHR_maintenance2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Tobias Hector
tobias
Other Extension Metadata
Last Modified Date
2018-02-07
Contributors
Tobias Hector
Jeff Bolz
Description
This extension provides a new command 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 Commands
vkCmdBeginRenderPass2KHR
vkCmdEndRenderPass2KHR
vkCmdNextSubpass2KHR
vkCreateRenderPass2KHR
New Structures
VkAttachmentDescription2KHR
VkAttachmentReference2KHR
VkRenderPassCreateInfo2KHR
VkSubpassBeginInfoKHR
VkSubpassDependency2KHR
VkSubpassDescription2KHR
VkSubpassEndInfoKHR
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
Version History
Revision 1, 2018-02-07 (Tobias Hector)
Internal revisions
VK_KHR_dedicated_allocation
Name String
VK_KHR_dedicated_allocation
Extension Type
Device extension
Registered Extension Number
128
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_memory_requirements2
or
Vulkan Version 1.1
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 Structures
Extending
VkMemoryAllocateInfo
VkMemoryDedicatedAllocateInfoKHR
Extending
VkMemoryRequirements2
VkMemoryDedicatedRequirementsKHR
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_create_renderpass2
or
Vulkan Version 1.2
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 Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDepthStencilResolvePropertiesKHR
Extending
VkSubpassDescription2
VkSubpassDescriptionDepthStencilResolveKHR
New Enums
VkResolveModeFlagBitsKHR
New Bitmasks
VkResolveModeFlagsKHR
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
Version History
Revision 1, 2018-04-09 (Jan-Harald Fredriksen)
Initial revision
VK_KHR_descriptor_update_template
Name String
VK_KHR_descriptor_update_template
Extension Type
Device extension
Registered Extension Number
86
Revision
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 an application-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 Object Types
VkDescriptorUpdateTemplateKHR
New Commands
vkCreateDescriptorUpdateTemplateKHR
vkDestroyDescriptorUpdateTemplateKHR
vkUpdateDescriptorSetWithTemplateKHR
If
VK_KHR_push_descriptor
is supported:
vkCmdPushDescriptorSetWithTemplateKHR
New Structures
VkDescriptorUpdateTemplateCreateInfoKHR
VkDescriptorUpdateTemplateEntryKHR
New Enums
VkDescriptorUpdateTemplateTypeKHR
New Bitmasks
VkDescriptorUpdateTemplateCreateFlagsKHR
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_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT
If
VK_KHR_push_descriptor
is supported:
Extending
VkDescriptorUpdateTemplateType
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
Version History
Revision 1, 2016-01-11 (Markus Tavenrath)
Initial draft
VK_KHR_device_group
Name String
VK_KHR_device_group
Extension Type
Device extension
Registered Extension Number
61
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_device_group_creation
API Interactions
Interacts with VK_KHR_bind_memory2
Interacts with VK_KHR_surface
Interacts with VK_KHR_swapchain
SPIR-V Dependencies
SPV_KHR_device_group
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
VkDeviceGroupPresentModeFlagBitsKHR
VkDeviceGroupPresentCapabilitiesKHR
VkImageSwapchainCreateInfoKHR
VkBindImageMemorySwapchainInfoKHR
VkAcquireNextImageInfoKHR
VkDeviceGroupPresentInfoKHR
VkDeviceGroupSwapchainCreateInfoKHR
vkGetDeviceGroupPresentCapabilitiesKHR
vkGetDeviceGroupSurfacePresentModesKHR
vkGetPhysicalDevicePresentRectanglesKHR
vkAcquireNextImage2KHR
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 Commands
vkCmdDispatchBaseKHR
vkCmdSetDeviceMaskKHR
vkGetDeviceGroupPeerMemoryFeaturesKHR
If
VK_KHR_surface
is supported:
vkGetDeviceGroupPresentCapabilitiesKHR
vkGetDeviceGroupSurfacePresentModesKHR
vkGetPhysicalDevicePresentRectanglesKHR
If
VK_KHR_swapchain
is supported:
vkAcquireNextImage2KHR
New Structures
Extending
VkBindSparseInfo
VkDeviceGroupBindSparseInfoKHR
Extending
VkCommandBufferBeginInfo
VkDeviceGroupCommandBufferBeginInfoKHR
Extending
VkMemoryAllocateInfo
VkMemoryAllocateFlagsInfoKHR
Extending
VkRenderPassBeginInfo
VkRenderingInfo
VkDeviceGroupRenderPassBeginInfoKHR
Extending
VkSubmitInfo
VkDeviceGroupSubmitInfoKHR
If
VK_KHR_bind_memory2
is supported:
Extending
VkBindBufferMemoryInfo
VkBindBufferMemoryDeviceGroupInfoKHR
Extending
VkBindImageMemoryInfo
VkBindImageMemoryDeviceGroupInfoKHR
If
VK_KHR_surface
is supported:
VkDeviceGroupPresentCapabilitiesKHR
If
VK_KHR_swapchain
is supported:
VkAcquireNextImageInfoKHR
Extending
VkBindImageMemoryInfo
VkBindImageMemorySwapchainInfoKHR
Extending
VkImageCreateInfo
VkImageSwapchainCreateInfoKHR
Extending
VkPresentInfoKHR
VkDeviceGroupPresentInfoKHR
Extending
VkSwapchainCreateInfoKHR
VkDeviceGroupSwapchainCreateInfoKHR
New Enums
VkMemoryAllocateFlagBitsKHR
VkPeerMemoryFeatureFlagBitsKHR
If
VK_KHR_surface
is supported:
VkDeviceGroupPresentModeFlagBitsKHR
New Bitmasks
VkMemoryAllocateFlagsKHR
VkPeerMemoryFeatureFlagsKHR
If
VK_KHR_surface
is supported:
VkDeviceGroupPresentModeFlagsKHR
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_BIT_KHR
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
New Built-in Variables
DeviceIndex
New SPIR-V Capabilities
DeviceGroup
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
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 Commands
vkEnumeratePhysicalDeviceGroupsKHR
New Structures
VkPhysicalDeviceGroupPropertiesKHR
Extending
VkDeviceCreateInfo
VkDeviceGroupDeviceCreateInfoKHR
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);
Version History
Revision 1, 2016-10-19 (Jeff Bolz)
Internal revisions
VK_KHR_draw_indirect_count
Name String
VK_KHR_draw_indirect_count
Extension Type
Device extension
Registered Extension Number
170
Revision
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
VK_AMD_draw_indirect_count
extension.
This extension allows an application to source the number of draws for
indirect drawing calls from a buffer.
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 commands
vkCmdDrawIndirectCount
and
vkCmdDrawIndexedIndirectCount
are
optional.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Commands
vkCmdDrawIndexedIndirectCountKHR
vkCmdDrawIndirectCountKHR
New Enum Constants
VK_KHR_DRAW_INDIRECT_COUNT_EXTENSION_NAME
VK_KHR_DRAW_INDIRECT_COUNT_SPEC_VERSION
Version History
Revision 1, 2017-08-25 (Piers Daniell)
Initial draft based on VK_AMD_draw_indirect_count
VK_KHR_driver_properties
Name String
VK_KHR_driver_properties
Extension Type
Device extension
Registered Extension Number
197
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Structures
VkConformanceVersionKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDriverPropertiesKHR
New Enums
VkDriverIdKHR
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
Version History
Revision 1, 2018-04-11 (Daniel Rakos)
Internal revisions
VK_KHR_dynamic_rendering
Name String
VK_KHR_dynamic_rendering
Extension Type
Device extension
Registered Extension Number
45
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_depth_stencil_resolve
or
Vulkan Version 1.2
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_dynamic_rendering
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
VK_QCOM_render_pass_store_ops
, enabling applications to avoid
unnecessary synchronization when an attachment is not written during a
render pass.
New Commands
vkCmdBeginRenderingKHR
vkCmdEndRenderingKHR
New Structures
VkRenderingAttachmentInfoKHR
VkRenderingInfoKHR
Extending
VkCommandBufferInheritanceInfo
VkCommandBufferInheritanceRenderingInfoKHR
Extending
VkGraphicsPipelineCreateInfo
VkPipelineRenderingCreateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDynamicRenderingFeaturesKHR
New Enums
VkRenderingFlagBitsKHR
New Bitmasks
VkRenderingFlagsKHR
New Enum Constants
VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME
VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION
Extending
VkAttachmentStoreOp
VK_ATTACHMENT_STORE_OP_NONE_KHR
Extending
VkRenderingFlagBits
VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT_KHR
VK_RENDERING_RESUMING_BIT_KHR
VK_RENDERING_SUSPENDING_BIT_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
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2021-10-06 (Tobias Hector)
Initial revision
VK_KHR_dynamic_rendering_local_read
Name String
VK_KHR_dynamic_rendering_local_read
Extension Type
Device extension
Registered Extension Number
233
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Tobias Hector
tobski
Extension Proposal
VK_KHR_dynamic_rendering_local_read
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 Commands
vkCmdSetRenderingAttachmentLocationsKHR
vkCmdSetRenderingInputAttachmentIndicesKHR
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkCommandBufferInheritanceInfo
VkRenderingAttachmentLocationInfoKHR
VkRenderingInputAttachmentIndexInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDynamicRenderingLocalReadFeaturesKHR
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4, with the KHR
suffix omitted.
However, Vulkan 1.4 implementations only have to support local read for
storage resources and single sampled color attachments.
Support for reading depth/stencil attachments and multi-sampled attachments
are respectively gated behind the new boolean
dynamicRenderingLocalReadDepthStencilAttachments
and
dynamicRenderingLocalReadMultisampledAttachments
properties, as
described in the
Version 1.4
appendix.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-11-03 (Tobias Hector)
Initial revision
VK_KHR_external_fence
Name String
VK_KHR_external_fence
Extension Type
Device extension
Registered Extension Number
114
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_fence_capabilities
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
VkExportFenceCreateInfoKHR
New Enums
VkFenceImportFlagBitsKHR
New Bitmasks
VkFenceImportFlagsKHR
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.
Version History
Revision 1, 2017-05-08 (Jesse Hall)
Initial revision
VK_KHR_external_fence_capabilities
Name String
VK_KHR_external_fence_capabilities
Extension Type
Instance extension
Registered Extension Number
113
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Commands
vkGetPhysicalDeviceExternalFencePropertiesKHR
New Structures
VkExternalFencePropertiesKHR
VkPhysicalDeviceExternalFenceInfoKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceIDPropertiesKHR
New Enums
VkExternalFenceFeatureFlagBitsKHR
VkExternalFenceHandleTypeFlagBitsKHR
New Bitmasks
VkExternalFenceFeatureFlagsKHR
VkExternalFenceHandleTypeFlagsKHR
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
Version History
Revision 1, 2017-05-08 (Jesse Hall)
Initial version
VK_KHR_external_memory
Name String
VK_KHR_external_memory
Extension Type
Device extension
Registered Extension Number
73
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_memory_capabilities
or
Vulkan Version 1.1
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 Structures
Extending
VkBufferCreateInfo
VkExternalMemoryBufferCreateInfoKHR
Extending
VkImageCreateInfo
VkExternalMemoryImageCreateInfoKHR
Extending
VkMemoryAllocateInfo
VkExportMemoryAllocateInfoKHR
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.
Reusing
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.
Version History
Revision 1, 2016-10-20 (James Jones)
Initial version
VK_KHR_external_memory_capabilities
Name String
VK_KHR_external_memory_capabilities
Extension Type
Instance extension
Registered Extension Number
72
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Commands
vkGetPhysicalDeviceExternalBufferPropertiesKHR
New Structures
VkExternalBufferPropertiesKHR
VkExternalMemoryPropertiesKHR
VkPhysicalDeviceExternalBufferInfoKHR
Extending
VkImageFormatProperties2
VkExternalImageFormatPropertiesKHR
Extending
VkPhysicalDeviceImageFormatInfo2
VkPhysicalDeviceExternalImageFormatInfoKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceIDPropertiesKHR
New Enums
VkExternalMemoryFeatureFlagBitsKHR
VkExternalMemoryHandleTypeFlagBitsKHR
New Bitmasks
VkExternalMemoryFeatureFlagsKHR
VkExternalMemoryHandleTypeFlagsKHR
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?
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?
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?
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?
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?
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?
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.
Version History
Revision 1, 2016-10-17 (James Jones)
Initial version
VK_KHR_external_semaphore
Name String
VK_KHR_external_semaphore
Extension Type
Device extension
Registered Extension Number
78
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_external_semaphore_capabilities
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 Structures
Extending
VkSemaphoreCreateInfo
VkExportSemaphoreCreateInfoKHR
New Enums
VkSemaphoreImportFlagBitsKHR
New Bitmasks
VkSemaphoreImportFlagsKHR
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.
Version History
Revision 1, 2016-10-21 (James Jones)
Initial revision
VK_KHR_external_semaphore_capabilities
Name String
VK_KHR_external_semaphore_capabilities
Extension Type
Instance extension
Registered Extension Number
77
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Commands
vkGetPhysicalDeviceExternalSemaphorePropertiesKHR
New Structures
VkExternalSemaphorePropertiesKHR
VkPhysicalDeviceExternalSemaphoreInfoKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceIDPropertiesKHR
New Enums
VkExternalSemaphoreFeatureFlagBitsKHR
VkExternalSemaphoreHandleTypeFlagBitsKHR
New Bitmasks
VkExternalSemaphoreFeatureFlagsKHR
VkExternalSemaphoreHandleTypeFlagsKHR
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
Version History
Revision 1, 2016-10-20 (James Jones)
Initial revision
VK_KHR_format_feature_flags2
Name String
VK_KHR_format_feature_flags2
Extension Type
Device extension
Registered Extension Number
361
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_EXT_filter_cubic
Interacts with VK_EXT_sampler_filter_minmax
Interacts with VK_IMG_filter_cubic
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
command, 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
and
VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR
specify
that an implementation supports reading and writing, respectively, a
given
VkFormat
through storage operations without specifying the
format in the shader.
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR
specifies that an implementation supports depth comparison performed by
OpImage*Dref*
instructions on a given
VkFormat
Previously the result of executing a
OpImage*Dref*
instruction on
an image view, where the
format
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
VkFormatProperties3KHR
New Enums
VkFormatFeatureFlagBits2KHR
New Bitmasks
VkFormatFeatureFlags2KHR
New Enum Constants
VK_KHR_FORMAT_FEATURE_FLAGS_2_EXTENSION_NAME
VK_KHR_FORMAT_FEATURE_FLAGS_2_SPEC_VERSION
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_BLIT_DST_BIT_KHR
VK_FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR
VK_FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHR
VK_FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHR
VK_FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR
VK_FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHR
VK_FORMAT_FEATURE_2_DISJOINT_BIT_KHR
VK_FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHR
VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR
VK_FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHR
VK_FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHR
VK_FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR
VK_FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHR
Extending
VkStructureType
VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3_KHR
If
VK_EXT_filter_cubic
or
VK_IMG_filter_cubic
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT
If
Vulkan Version 1.2
or
VK_EXT_sampler_filter_minmax
is supported:
Extending
VkFormatFeatureFlagBits2
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_MINMAX_BIT_KHR
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 2, 2022-07-20 (Lionel Landwerlin)
Clarify that
VK_FORMAT_FEATURE_2_STORAGE_(READ|WRITE)_WITHOUT_FORMAT_BIT also apply
to buffer views.
Revision 1, 2020-07-21 (Lionel Landwerlin)
Initial draft
VK_KHR_get_memory_requirements2
Name String
VK_KHR_get_memory_requirements2
Extension Type
Device extension
Registered Extension Number
147
Revision
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 additional commands.
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 Commands
vkGetBufferMemoryRequirements2KHR
vkGetImageMemoryRequirements2KHR
vkGetImageSparseMemoryRequirements2KHR
New Structures
VkBufferMemoryRequirementsInfo2KHR
VkImageMemoryRequirementsInfo2KHR
VkImageSparseMemoryRequirementsInfo2KHR
VkMemoryRequirements2KHR
VkSparseImageMemoryRequirements2KHR
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
Version History
Revision 1, 2017-03-23 (Faith Ekstrand)
Internal revisions
VK_KHR_get_physical_device_properties2
Name String
VK_KHR_get_physical_device_properties2
Extension Type
Instance extension
Registered Extension Number
60
Revision
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 Commands
vkGetPhysicalDeviceFeatures2KHR
vkGetPhysicalDeviceFormatProperties2KHR
vkGetPhysicalDeviceImageFormatProperties2KHR
vkGetPhysicalDeviceMemoryProperties2KHR
vkGetPhysicalDeviceProperties2KHR
vkGetPhysicalDeviceQueueFamilyProperties2KHR
vkGetPhysicalDeviceSparseImageFormatProperties2KHR
New Structures
VkFormatProperties2KHR
VkImageFormatProperties2KHR
VkPhysicalDeviceImageFormatInfo2KHR
VkPhysicalDeviceMemoryProperties2KHR
VkPhysicalDeviceProperties2KHR
VkPhysicalDeviceSparseImageFormatInfo2KHR
VkQueueFamilyProperties2KHR
VkSparseImageFormatProperties2KHR
Extending
VkDeviceCreateInfo
VkPhysicalDeviceFeatures2KHR
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);
Version History
Revision 1, 2016-09-12 (Jeff Bolz)
Internal revisions
Revision 2, 2016-11-02 (Ian Elliott)
Added ability for applications to use the physical-device components of
device extensions before vkCreateDevice is called.
VK_KHR_global_priority
Name String
VK_KHR_global_priority
Extension Type
Device extension
Registered Extension Number
189
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
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 Structures
Extending
VkDeviceQueueCreateInfo
VkDeviceQueueGlobalPriorityCreateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceGlobalPriorityQueryFeaturesKHR
Extending
VkQueueFamilyProperties2
VkQueueFamilyGlobalPriorityPropertiesKHR
New Enums
VkQueueGlobalPriorityKHR
New Enum Constants
VK_KHR_GLOBAL_PRIORITY_EXTENSION_NAME
VK_KHR_GLOBAL_PRIORITY_SPEC_VERSION
VK_MAX_GLOBAL_PRIORITY_SIZE_KHR
Extending
VkQueueGlobalPriority
VK_QUEUE_GLOBAL_PRIORITY_HIGH_KHR
VK_QUEUE_GLOBAL_PRIORITY_LOW_KHR
VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_KHR
VK_QUEUE_GLOBAL_PRIORITY_REALTIME_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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
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.
Version History
Revision 1, 2021-10-22 (Tobias Hector)
Initial draft
VK_KHR_image_format_list
Name String
VK_KHR_image_format_list
Extension Type
Device extension
Registered Extension Number
148
Revision
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 Structures
Extending
VkImageCreateInfo
VkSwapchainCreateInfoKHR
VkPhysicalDeviceImageFormatInfo2
VkImageFormatListCreateInfoKHR
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
Version History
Revision 1, 2017-03-20 (Faith Ekstrand)
Initial revision
VK_KHR_imageless_framebuffer
Name String
VK_KHR_imageless_framebuffer
Extension Type
Device extension
Registered Extension Number
109
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_maintenance2
or
Vulkan Version 1.1
and
VK_KHR_image_format_list
or
Vulkan Version 1.2
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Tobias Hector
tobias
Other Extension Metadata
Last Modified Date
2018-12-14
Contributors
Tobias Hector
Graham Wihlidal
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 Structures
VkFramebufferAttachmentImageInfoKHR
Extending
VkFramebufferCreateInfo
VkFramebufferAttachmentsCreateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImagelessFramebufferFeaturesKHR
Extending
VkRenderPassBeginInfo
VkRenderPassAttachmentBeginInfoKHR
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
Version History
Revision 1, 2018-12-14 (Tobias Hector)
Internal revisions
VK_KHR_index_type_uint8
Name String
VK_KHR_index_type_uint8
Extension Type
Device extension
Registered Extension Number
534
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceIndexTypeUint8FeaturesKHR
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-06-06 (Piers Daniell)
Internal revisions
VK_KHR_line_rasterization
Name String
VK_KHR_line_rasterization
Extension Type
Device extension
Registered Extension Number
535
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
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 Commands
vkCmdSetLineStippleKHR
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceLineRasterizationFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceLineRasterizationPropertiesKHR
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationLineStateCreateInfoKHR
New Enums
VkLineRasterizationModeKHR
New Enum Constants
VK_KHR_LINE_RASTERIZATION_EXTENSION_NAME
VK_KHR_LINE_RASTERIZATION_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_LINE_STIPPLE_KHR
Extending
VkLineRasterizationMode
VK_LINE_RASTERIZATION_MODE_BRESENHAM_KHR
VK_LINE_RASTERIZATION_MODE_DEFAULT_KHR
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_KHR
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
When
Version 1.4
is supported, the
bresenhamLines
feature must be supported.
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.
Version History
Revision 1, 2019-05-09 (Jeff Bolz)
Initial draft
VK_KHR_load_store_op_none
Name String
VK_KHR_load_store_op_none
Extension Type
Device extension
Registered Extension Number
527
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_load_store_op_none
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
While
VK_ATTACHMENT_STORE_OP_NONE
is part of Vulkan 1.3, this
extension was not promoted to core Vulkan 1.3 either in whole or in part.
This functionality was promoted from
VK_KHR_dynamic_rendering
Version History
Revision 1, 2023-05-16 (Shahbaz Youssefi)
Initial revision, based on VK_EXT_load_store_op_none.
VK_KHR_maintenance1
Name String
VK_KHR_maintenance1
Extension Type
Device extension
Registered Extension Number
70
Revision
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 use
gl_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
and
VK_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 Commands
vkTrimCommandPoolKHR
New Bitmasks
VkCommandPoolTrimFlagsKHR
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
Issues
Are viewports with zero height allowed?
RESOLVED
: Yes, although they have low utility.
Version History
Revision 1, 2016-10-26 (Piers Daniell)
Internal revisions
Revision 2, 2018-03-13 (Jon Leech)
Add issue for zero-height viewports
VK_KHR_maintenance2
Name String
VK_KHR_maintenance2
Extension Type
Device extension
Registered Extension Number
118
Revision
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
VkInputAttachmentAspectReferenceKHR
Extending
VkImageViewCreateInfo
VkImageViewUsageCreateInfoKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePointClippingPropertiesKHR
Extending
VkPipelineTessellationStateCreateInfo
VkPipelineTessellationDomainOriginStateCreateInfoKHR
Extending
VkRenderPassCreateInfo
VkRenderPassInputAttachmentAspectCreateInfoKHR
New Enums
VkPointClippingBehaviorKHR
VkTessellationDomainOriginKHR
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.
Version History
Revision 1, 2017-04-28
VK_KHR_maintenance3
Name String
VK_KHR_maintenance3
Extension Type
Device extension
Registered Extension Number
169
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.1
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-09-05
Contributors
Jeff Bolz, NVIDIA
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 Commands
vkGetDescriptorSetLayoutSupportKHR
New Structures
VkDescriptorSetLayoutSupportKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance3PropertiesKHR
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
Version History
Revision 1, 2017-08-22
VK_KHR_maintenance4
Name String
VK_KHR_maintenance4
Extension Type
Device extension
Registered Extension Number
414
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
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 size
VkBuffer
that
can
be created.
Add support for the SPIR-V 1.2
LocalSizeId
execution mode, which
can be used as an alternative to
LocalSize
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 Commands
vkGetDeviceBufferMemoryRequirementsKHR
vkGetDeviceImageMemoryRequirementsKHR
vkGetDeviceImageSparseMemoryRequirementsKHR
New Structures
VkDeviceBufferMemoryRequirementsKHR
VkDeviceImageMemoryRequirementsKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance4FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance4PropertiesKHR
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
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Issues
None.
Version History
Revision 1, 2021-08-18 (Piers Daniell)
Internal revisions
Revision 2, 2021-10-25 (Yiwei Zhang)
More guarantees on buffer memory requirements
VK_KHR_maintenance5
Name String
VK_KHR_maintenance5
Extension Type
Device extension
Registered Extension Number
471
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_VERSION_1_3
Interacts with VK_VERSION_1_4
Interacts with VK_ARM_pipeline_opacity_micromap
Interacts with VK_ARM_shader_instrumentation
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_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
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Stu Smith
stu-s
Extension Proposal
VK_KHR_maintenance5
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 command
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 using
VK_WHOLE_SIZE
in the
pSizes
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 structure 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 the
layerCount
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
is
VK_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 Commands
vkCmdBindIndexBuffer2KHR
vkGetDeviceImageSubresourceLayoutKHR
vkGetImageSubresourceLayout2KHR
vkGetRenderingAreaGranularityKHR
New Structures
VkDeviceImageSubresourceInfoKHR
VkImageSubresource2KHR
VkRenderingAreaInfoKHR
VkSubresourceLayout2KHR
Extending
VkBufferViewCreateInfo
VkBufferCreateInfo
VkPhysicalDeviceExternalBufferInfo
VkDescriptorBufferBindingInfoEXT
VkBufferUsageFlags2CreateInfoKHR
Extending
VkComputePipelineCreateInfo
VkGraphicsPipelineCreateInfo
VkRayTracingPipelineCreateInfoNV
VkRayTracingPipelineCreateInfoKHR
VkPipelineCreateFlags2CreateInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance5FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance5PropertiesKHR
New Enums
VkBufferUsageFlagBits2KHR
VkPipelineCreateFlagBits2KHR
New Bitmasks
VkBufferUsageFlags2KHR
VkPipelineCreateFlags2KHR
New Enum Constants
VK_KHR_MAINTENANCE_5_EXTENSION_NAME
VK_KHR_MAINTENANCE_5_SPEC_VERSION
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_INDIRECT_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_STORAGE_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_STORAGE_TEXEL_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_TRANSFER_DST_BIT_KHR
VK_BUFFER_USAGE_2_TRANSFER_SRC_BIT_KHR
VK_BUFFER_USAGE_2_UNIFORM_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR
VK_BUFFER_USAGE_2_VERTEX_BUFFER_BIT_KHR
Extending
VkFormat
VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
VK_FORMAT_A8_UNORM_KHR
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_ALLOW_DERIVATIVES_BIT_KHR
VK_PIPELINE_CREATE_2_DERIVATIVE_BIT_KHR
VK_PIPELINE_CREATE_2_DISABLE_OPTIMIZATION_BIT_KHR
VK_PIPELINE_CREATE_2_DISPATCH_BASE_BIT_KHR
VK_PIPELINE_CREATE_2_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_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_KHR_dynamic_rendering
or
Vulkan Version 1.3
and
VK_EXT_fragment_density_map
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT
If
VK_KHR_dynamic_rendering
or
Vulkan Version 1.3
and
VK_KHR_fragment_shading_rate
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR
If
VK_ARM_pipeline_opacity_micromap
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_DISALLOW_OPACITY_MICROMAP_BIT_ARM
If
VK_ARM_shader_instrumentation
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_INSTRUMENT_SHADERS_BIT_ARM
Extending
VkShaderCreateFlagBitsEXT
VK_SHADER_CREATE_INSTRUMENT_SHADER_BIT_ARM
If
VK_EXT_attachment_feedback_loop_layout
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
VK_PIPELINE_CREATE_2_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT
If
VK_EXT_conditional_rendering
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_CONDITIONAL_RENDERING_BIT_EXT
If
VK_EXT_descriptor_buffer
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT
VK_BUFFER_USAGE_2_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT
VK_BUFFER_USAGE_2_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_DESCRIPTOR_BUFFER_BIT_EXT
If
VK_EXT_graphics_pipeline_library
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_LINK_TIME_OPTIMIZATION_BIT_EXT
VK_PIPELINE_CREATE_2_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT
If
VK_EXT_opacity_micromap
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT
VK_BUFFER_USAGE_2_MICROMAP_STORAGE_BIT_EXT
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT
If
VK_EXT_transform_feedback
is supported:
Extending
VkBufferUsageFlagBits2
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
VkBufferUsageFlagBits2
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
VkPipelineCreateFlagBits2
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
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_LIBRARY_BIT_KHR
If
VK_KHR_ray_tracing_pipeline
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_SHADER_BINDING_TABLE_BIT_KHR
Extending
VkPipelineCreateFlagBits2
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
VkBufferUsageFlagBits2
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
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_VIDEO_ENCODE_DST_BIT_KHR
VK_BUFFER_USAGE_2_VIDEO_ENCODE_SRC_BIT_KHR
If
VK_NV_device_generated_commands
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_INDIRECT_BINDABLE_BIT_NV
If
VK_NV_displacement_micromap
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RAY_TRACING_DISPLACEMENT_MICROMAP_BIT_NV
If
VK_NV_ray_tracing
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_RAY_TRACING_BIT_NV
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_DEFER_COMPILE_BIT_NV
If
VK_NV_ray_tracing_motion_blur
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_RAY_TRACING_ALLOW_MOTION_BIT_NV
If
Vulkan Version 1.2
or
VK_KHR_buffer_device_address
or
VK_EXT_buffer_device_address
is supported:
Extending
VkBufferUsageFlagBits2
VK_BUFFER_USAGE_2_SHADER_DEVICE_ADDRESS_BIT_KHR
If
Vulkan Version 1.3
or
VK_EXT_pipeline_creation_cache_control
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_EARLY_RETURN_ON_FAILURE_BIT_KHR
VK_PIPELINE_CREATE_2_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_KHR
If
Vulkan Version 1.4
or
VK_EXT_pipeline_protected_access
is supported:
Extending
VkPipelineCreateFlagBits2
VK_PIPELINE_CREATE_2_NO_PROTECTED_ACCESS_BIT_EXT
VK_PIPELINE_CREATE_2_PROTECTED_ACCESS_ONLY_BIT_EXT
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2022-12-12 (Stu Smith)
Initial revision
VK_KHR_maintenance6
Name String
VK_KHR_maintenance6
Extension Type
Device extension
Registered Extension Number
546
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
API Interactions
Interacts with VK_EXT_descriptor_buffer
Interacts with VK_KHR_push_descriptor
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Jon Leech
oddhack
Extension Proposal
VK_KHR_maintenance6
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′C
conversion
supported by the implementation.
A new property
blockTexelViewCompatibleMultipleLayers
indicating
whether
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT
is allowed
to be used with
layerCount
> 1
pNext
extensible *2 versions of all descriptor binding commands.
New Commands
vkCmdBindDescriptorSets2KHR
vkCmdPushConstants2KHR
If
VK_EXT_descriptor_buffer
is supported:
vkCmdBindDescriptorBufferEmbeddedSamplers2EXT
vkCmdSetDescriptorBufferOffsets2EXT
If
VK_KHR_push_descriptor
is supported:
vkCmdPushDescriptorSet2KHR
vkCmdPushDescriptorSetWithTemplate2KHR
New Structures
VkBindDescriptorSetsInfoKHR
VkPushConstantsInfoKHR
Extending
VkBindBufferMemoryInfo
VkBindImageMemoryInfo
VkBindMemoryStatusKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMaintenance6FeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMaintenance6PropertiesKHR
If
VK_EXT_descriptor_buffer
is supported:
VkBindDescriptorBufferEmbeddedSamplersInfoEXT
VkSetDescriptorBufferOffsetsInfoEXT
If
VK_KHR_push_descriptor
is supported:
VkPushDescriptorSetInfoKHR
VkPushDescriptorSetWithTemplateInfoKHR
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_EXT_descriptor_buffer
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_BUFFER_EMBEDDED_SAMPLERS_INFO_EXT
VK_STRUCTURE_TYPE_SET_DESCRIPTOR_BUFFER_OFFSETS_INFO_EXT
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-08-01 (Jon Leech)
Initial revision
VK_KHR_map_memory2
Name String
VK_KHR_map_memory2
Extension Type
Device extension
Registered Extension Number
272
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Faith Ekstrand
gfxstrand
Extension Proposal
VK_KHR_map_memory2
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 commands.
The new commands are functionally identical to the core commands, except
that their parameters are specified using extensible structures that can be
used to pass extension-specific information.
New Commands
vkMapMemory2KHR
vkUnmapMemory2KHR
New Structures
VkMemoryMapInfoKHR
VkMemoryUnmapInfoKHR
New Enums
VkMemoryUnmapFlagBitsKHR
New Bitmasks
VkMemoryUnmapFlagsKHR
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 0, 2022-08-03 (Faith Ekstrand)
Internal revisions
Revision 1, 2023-03-14
Public release
VK_KHR_multiview
Name String
VK_KHR_multiview
Extension Type
Device extension
Registered Extension Number
54
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_multiview
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMultiviewFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMultiviewPropertiesKHR
Extending
VkRenderPassCreateInfo
VkRenderPassMultiviewCreateInfoKHR
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
New Built-In Variables
ViewIndex
New SPIR-V Capabilities
MultiView
Version History
Revision 1, 2016-10-28 (Jeff Bolz)
Internal revisions
VK_KHR_push_descriptor
Name String
VK_KHR_push_descriptor
Extension Type
Device extension
Registered Extension Number
81
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_1
Interacts with VK_KHR_descriptor_update_template
Deprecation State
Promoted
to
Vulkan 1.4
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 Commands
vkCmdPushDescriptorSetKHR
If
Vulkan Version 1.1
or
VK_KHR_descriptor_update_template
is supported:
vkCmdPushDescriptorSetWithTemplateKHR
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePushDescriptorPropertiesKHR
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
Vulkan Version 1.1
or
VK_KHR_descriptor_update_template
is supported:
Extending
VkDescriptorUpdateTemplateType
VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2016-10-15 (Jeff Bolz)
Internal revisions
Revision 2, 2017-09-12 (Tobias Hector)
Added interactions with Vulkan 1.1
VK_KHR_relaxed_block_layout
Name String
VK_KHR_relaxed_block_layout
Extension Type
Device extension
Registered Extension Number
145
Revision
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.
New Enum Constants
VK_KHR_RELAXED_BLOCK_LAYOUT_EXTENSION_NAME
VK_KHR_RELAXED_BLOCK_LAYOUT_SPEC_VERSION
Version History
Revision 1, 2017-03-26 (JohnK)
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
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.
Version History
Revision 1, 2016-02-16 (Tobias Hector)
Initial draft
Revision 2, 2019-08-14 (Jon Leech)
Add KHR-suffixed alias of non-suffixed enum.
Revision 3, 2019-08-17 (Jon Leech)
Add an issue explaining the reason for the extension API not being
suffixed with KHR.
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
VK_KHR_maintenance1
and
VK_KHR_bind_memory2
and
VK_KHR_get_memory_requirements2
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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′C
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′C
concepts.
This extension provides the ability to perform specified color space
conversions during texture sampling operations for the Y′C
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.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
samplerYcbcrConversion
capability is required.
New Object Types
VkSamplerYcbcrConversionKHR
New Commands
vkCreateSamplerYcbcrConversionKHR
vkDestroySamplerYcbcrConversionKHR
New Structures
VkSamplerYcbcrConversionCreateInfoKHR
Extending
VkBindImageMemoryInfo
VkBindImagePlaneMemoryInfoKHR
Extending
VkImageFormatProperties2
VkSamplerYcbcrConversionImageFormatPropertiesKHR
Extending
VkImageMemoryRequirementsInfo2
VkImagePlaneMemoryRequirementsInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR
Extending
VkSamplerCreateInfo
VkImageViewCreateInfo
VkSamplerYcbcrConversionInfoKHR
New Enums
VkChromaLocationKHR
VkSamplerYcbcrModelConversionKHR
VkSamplerYcbcrRangeKHR
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
If
VK_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR_EXT
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_create_renderpass2
or
Vulkan Version 1.2
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 Structures
Extending
VkAttachmentDescription2
VkAttachmentDescriptionStencilLayoutKHR
Extending
VkAttachmentReference2
VkAttachmentReferenceStencilLayoutKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSeparateDepthStencilLayoutsFeaturesKHR
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
Version History
Revision 1, 2019-06-25 (Piers Daniell)
Internal revisions
VK_KHR_shader_atomic_int64
Name String
VK_KHR_shader_atomic_int64
Extension Type
Device extension
Registered Extension Number
181
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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
and
GL_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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderAtomicInt64FeaturesKHR
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
New SPIR-V Capabilities
Int64Atomics
Version History
Revision 1, 2018-07-05 (Aaron Hagan)
Internal revisions
VK_KHR_shader_draw_parameters
Name String
VK_KHR_shader_draw_parameters
Extension Type
Device extension
Registered Extension Number
64
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_shader_draw_parameters
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 the
firstInstance
parameter passed
to drawing commands,
BaseVertex
, containing the
firstVertex
or
vertexOffset
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
New Built-In Variables
BaseInstance
BaseVertex
DrawIndex
New SPIR-V Capabilities
DrawParameters
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.
Version History
Revision 1, 2016-10-05 (Daniel Koch)
Internal revisions
VK_KHR_shader_expect_assume
Name String
VK_KHR_shader_expect_assume
Extension Type
Device extension
Registered Extension Number
545
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_expect_assume
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Kevin Petit
kpet
Extension Proposal
VK_KHR_shader_expect_assume
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderExpectAssumeFeaturesKHR
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
New SPIR-V Capabilities
ExpectAssumeKHR
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-12-06 (Kevin Petit)
Initial revision
VK_KHR_shader_float16_int8
Name String
VK_KHR_shader_float16_int8
Extension Type
Device extension
Registered Extension Number
83
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
shaderInt8
capability is
required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFloat16Int8FeaturesKHR
VkPhysicalDeviceShaderFloat16Int8FeaturesKHR
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
Version History
Revision 1, 2018-03-07 (Alexander Galazin)
Initial draft
VK_KHR_shader_float_controls
Name String
VK_KHR_shader_float_controls
Extension Type
Device extension
Registered Extension Number
198
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_float_controls
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 Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFloatControlsPropertiesKHR
New Enums
VkShaderFloatControlsIndependenceKHR
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
New SPIR-V Capabilities
DenormPreserve
DenormFlushToZero
SignedZeroInfNanPreserve
RoundingModeRTE
RoundingModeRTZ
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_float_controls2
Name String
VK_KHR_shader_float_controls2
Extension Type
Device extension
Registered Extension Number
529
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_shader_float_controls
SPIR-V Dependencies
SPV_KHR_float_controls2
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Graeme Leese
gnl21
Extension Proposal
VK_KHR_shader_float_controls2
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderFloatControls2FeaturesKHR
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
New SPIR-V Capabilities
FloatControls2
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-05-16 (Graeme Leese)
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
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_integer_dot_product
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Kevin Petit
kpet
Extension Proposal
VK_KHR_shader_integer_dot_product
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderIntegerDotProductFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceShaderIntegerDotProductPropertiesKHR
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
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
New SPIR-V Capabilities
DotProductInputAllKHR
DotProductInput4x8BitKHR
DotProductInput4x8BitPackedKHR
DotProductKHR
Version History
Revision 1, 2021-06-16 (Kévin Petit)
Initial revision
VK_KHR_shader_non_semantic_info
Name String
VK_KHR_shader_non_semantic_info
Extension Type
Device extension
Registered Extension Number
294
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_non_semantic_info
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
Version History
Revision 1, 2019-10-16 (Baldur Karlsson)
Initial revision
VK_KHR_shader_subgroup_extended_types
Name String
VK_KHR_shader_subgroup_extended_types
Extension Type
Device extension
Registered Extension Number
176
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderSubgroupExtendedTypesFeaturesKHR
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
Version History
Revision 1, 2019-01-08 (Neil Henning)
Initial draft
VK_KHR_shader_subgroup_rotate
Name String
VK_KHR_shader_subgroup_rotate
Extension Type
Device extension
Registered Extension Number
417
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_subgroup_rotate
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Kevin Petit
kpet
Extension Proposal
VK_KHR_shader_subgroup_rotate
Last Modified Date
2024-01-29
IP Status
No known IP claims.
Contributors
Kévin Petit, Arm Ltd.
Tobias Hector, AMD
Jon 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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderSubgroupRotateFeaturesKHR
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
New SPIR-V Capabilities
GroupNonUniformRotateKHR
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 2, 2024-01-29 (Kévin Petit)
Add
VK_SUBGROUP_FEATURE_ROTATE_BIT_KHR
and
VK_SUBGROUP_FEATURE_ROTATE_CLUSTERED_BIT_KHR
Revision 1, 2023-06-20 (Kévin Petit)
Initial revision
VK_KHR_shader_terminate_invocation
Name String
VK_KHR_shader_terminate_invocation
Extension Type
Device extension
Registered Extension Number
216
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_terminate_invocation
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
; only previously
executed instructions will have observable effects.
The
OpTerminateInvocation
instruction, along with the
OpDemoteToHelperInvocation
instruction from the
VK_EXT_shader_demote_to_helper_invocation
extension, together
replace the
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderTerminateInvocationFeaturesKHR
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
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2020-08-11 (Jesse Hall)
VK_KHR_spirv_1_4
Name String
VK_KHR_spirv_1_4
Extension Type
Device extension
Registered Extension Number
237
Revision
Ratification Status
Ratified
Extension and Version Dependencies
Vulkan Version 1.1
and
VK_KHR_shader_float_controls
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.
New Enum Constants
VK_KHR_SPIRV_1_4_EXTENSION_NAME
VK_KHR_SPIRV_1_4_SPEC_VERSION
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
Version History
Revision 1, 2019-04-01 (Jesse Hall)
Internal draft versions
VK_KHR_storage_buffer_storage_class
Name String
VK_KHR_storage_buffer_storage_class
Extension Type
Device extension
Registered Extension Number
132
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_storage_buffer_storage_class
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.
Block
-decorated object in this class is equivalent to a
BufferBlock
-decorated object in the
Uniform
storage class.
Promotion to Vulkan 1.1
All functionality in this extension is included in core Vulkan 1.1.
New Enum Constants
VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_EXTENSION_NAME
VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_SPEC_VERSION
Version History
Revision 1, 2017-03-23 (Alexander Galazin)
Initial draft
VK_KHR_synchronization2
Name String
VK_KHR_synchronization2
Extension Type
Device extension
Registered Extension Number
315
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_EXT_blend_operation_advanced
Interacts with VK_EXT_conditional_rendering
Interacts with VK_EXT_device_generated_commands
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_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 to
newLayout
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.
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
and
VK_PIPELINE_STAGE_2_NONE_KHR
values.
VkMemoryBarrier2KHR
can be chained to
VkSubpassDependency2
overriding the original 32-bit stage and access masks.
New Base Types
VkFlags64
New Commands
vkCmdPipelineBarrier2KHR
vkCmdResetEvent2KHR
vkCmdSetEvent2KHR
vkCmdWaitEvents2KHR
vkCmdWriteTimestamp2KHR
vkQueueSubmit2KHR
New Structures
VkBufferMemoryBarrier2KHR
VkCommandBufferSubmitInfoKHR
VkDependencyInfoKHR
VkImageMemoryBarrier2KHR
VkSemaphoreSubmitInfoKHR
VkSubmitInfo2KHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSynchronization2FeaturesKHR
Extending
VkSubpassDependency2
VkMemoryBarrier2KHR
New Enums
VkAccessFlagBits2KHR
VkPipelineStageFlagBits2KHR
VkSubmitFlagBitsKHR
New Bitmasks
VkAccessFlags2KHR
VkPipelineStageFlags2KHR
VkSubmitFlagsKHR
New Enum Constants
VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME
VK_KHR_SYNCHRONIZATION_2_SPEC_VERSION
Extending
VkAccessFlagBits
VK_ACCESS_NONE_KHR
Extending
VkAccessFlagBits2
VK_ACCESS_2_COLOR_ATTACHMENT_READ_BIT_KHR
VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT_KHR
VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT_KHR
VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT_KHR
VK_ACCESS_2_HOST_READ_BIT_KHR
VK_ACCESS_2_HOST_WRITE_BIT_KHR
VK_ACCESS_2_INDEX_READ_BIT_KHR
VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT_KHR
VK_ACCESS_2_INPUT_ATTACHMENT_READ_BIT_KHR
VK_ACCESS_2_MEMORY_READ_BIT_KHR
VK_ACCESS_2_MEMORY_WRITE_BIT_KHR
VK_ACCESS_2_NONE_KHR
VK_ACCESS_2_SHADER_READ_BIT_KHR
VK_ACCESS_2_SHADER_SAMPLED_READ_BIT_KHR
VK_ACCESS_2_SHADER_STORAGE_READ_BIT_KHR
VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT_KHR
VK_ACCESS_2_SHADER_WRITE_BIT_KHR
VK_ACCESS_2_TRANSFER_READ_BIT_KHR
VK_ACCESS_2_TRANSFER_WRITE_BIT_KHR
VK_ACCESS_2_UNIFORM_READ_BIT_KHR
VK_ACCESS_2_VERTEX_ATTRIBUTE_READ_BIT_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
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT_KHR
VK_PIPELINE_STAGE_2_ALL_GRAPHICS_BIT_KHR
VK_PIPELINE_STAGE_2_ALL_TRANSFER_BIT_KHR
VK_PIPELINE_STAGE_2_BLIT_BIT_KHR
VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT_KHR
VK_PIPELINE_STAGE_2_CLEAR_BIT_KHR
VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT_KHR
VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT_KHR
VK_PIPELINE_STAGE_2_COPY_BIT_KHR
VK_PIPELINE_STAGE_2_DRAW_INDIRECT_BIT_KHR
VK_PIPELINE_STAGE_2_EARLY_FRAGMENT_TESTS_BIT_KHR
VK_PIPELINE_STAGE_2_FRAGMENT_SHADER_BIT_KHR
VK_PIPELINE_STAGE_2_GEOMETRY_SHADER_BIT_KHR
VK_PIPELINE_STAGE_2_HOST_BIT_KHR
VK_PIPELINE_STAGE_2_INDEX_INPUT_BIT_KHR
VK_PIPELINE_STAGE_2_LATE_FRAGMENT_TESTS_BIT_KHR
VK_PIPELINE_STAGE_2_NONE_KHR
VK_PIPELINE_STAGE_2_PRE_RASTERIZATION_SHADERS_BIT_KHR
VK_PIPELINE_STAGE_2_RESOLVE_BIT_KHR
VK_PIPELINE_STAGE_2_TESSELLATION_CONTROL_SHADER_BIT_KHR
VK_PIPELINE_STAGE_2_TESSELLATION_EVALUATION_SHADER_BIT_KHR
VK_PIPELINE_STAGE_2_TOP_OF_PIPE_BIT_KHR
VK_PIPELINE_STAGE_2_TRANSFER_BIT_KHR
VK_PIPELINE_STAGE_2_VERTEX_ATTRIBUTE_INPUT_BIT_KHR
VK_PIPELINE_STAGE_2_VERTEX_INPUT_BIT_KHR
VK_PIPELINE_STAGE_2_VERTEX_SHADER_BIT_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
Extending
VkSubmitFlagBits
VK_SUBMIT_PROTECTED_BIT_KHR
If
VK_EXT_blend_operation_advanced
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT
If
VK_EXT_conditional_rendering
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_CONDITIONAL_RENDERING_READ_BIT_EXT
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_CONDITIONAL_RENDERING_BIT_EXT
If
VK_EXT_device_generated_commands
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_COMMAND_PREPROCESS_READ_BIT_EXT
VK_ACCESS_2_COMMAND_PREPROCESS_WRITE_BIT_EXT
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_COMMAND_PREPROCESS_BIT_EXT
If
VK_EXT_fragment_density_map
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_FRAGMENT_DENSITY_MAP_READ_BIT_EXT
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_FRAGMENT_DENSITY_PROCESS_BIT_EXT
If
VK_EXT_mesh_shader
is supported:
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_MESH_SHADER_BIT_EXT
VK_PIPELINE_STAGE_2_TASK_SHADER_BIT_EXT
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
If
VK_NV_device_generated_commands
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_COMMAND_PREPROCESS_READ_BIT_NV
VK_ACCESS_2_COMMAND_PREPROCESS_WRITE_BIT_NV
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_COMMAND_PREPROCESS_BIT_NV
If
VK_NV_mesh_shader
is supported:
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_MESH_SHADER_BIT_NV
VK_PIPELINE_STAGE_2_TASK_SHADER_BIT_NV
If
VK_NV_ray_tracing
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_NV
VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_NV
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_NV
VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_NV
If
VK_NV_shading_rate_image
is supported:
Extending
VkAccessFlagBits2
VK_ACCESS_2_SHADING_RATE_IMAGE_READ_BIT_NV
Extending
VkPipelineStageFlagBits2
VK_PIPELINE_STAGE_2_SHADING_RATE_IMAGE_BIT_NV
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Examples
See
Version History
Revision 1, 2020-12-03 (Tobias Hector)
Internal revisions
VK_KHR_timeline_semaphore
Name String
VK_KHR_timeline_semaphore
Extension Type
Device extension
Registered Extension Number
208
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Commands
vkGetSemaphoreCounterValueKHR
vkSignalSemaphoreKHR
vkWaitSemaphoresKHR
New Structures
VkSemaphoreSignalInfoKHR
VkSemaphoreWaitInfoKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTimelineSemaphoreFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTimelineSemaphorePropertiesKHR
Extending
VkSemaphoreCreateInfo
VkPhysicalDeviceExternalSemaphoreInfo
VkSemaphoreTypeCreateInfoKHR
Extending
VkSubmitInfo
VkBindSparseInfo
VkTimelineSemaphoreSubmitInfoKHR
New Enums
VkSemaphoreTypeKHR
VkSemaphoreWaitFlagBitsKHR
New Bitmasks
VkSemaphoreWaitFlagsKHR
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 application 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 application
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 application 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.
Version History
Revision 1, 2018-05-10 (Faith Ekstrand)
Initial version
Revision 2, 2019-06-12 (Faith Ekstrand)
Added an initialValue parameter to timeline semaphore creation
VK_KHR_uniform_buffer_standard_layout
Name String
VK_KHR_uniform_buffer_standard_layout
Extension Type
Device extension
Registered Extension Number
254
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 structure 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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceUniformBufferStandardLayoutFeaturesKHR
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
Version History
Revision 1, 2019-01-25 (Graeme Leese)
Initial draft
VK_KHR_variable_pointers
Name String
VK_KHR_variable_pointers
Extension Type
Device extension
Registered Extension Number
121
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_storage_buffer_storage_class
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_variable_pointers
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.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
variablePointers
and
variablePointersStorageBuffer
features is required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVariablePointerFeaturesKHR
VkPhysicalDeviceVariablePointersFeaturesKHR
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
New SPIR-V Capabilities
VariablePointers
VariablePointersStorageBuffer
Issues
1) Do we need an optional property for the SPIR-V
VariablePointersStorageBuffer
capability or should it be mandatory when
this extension is advertised?
RESOLVED
: Add it as a distinct feature, but make support mandatory.
Adding it as a feature makes the extension easier to include in a future
core API version.
In the extension, the feature is mandatory, so that presence of the
extension guarantees some functionality.
When included in a core API version, the feature would be optional.
2) Can support for these capabilities vary between shader stages?
RESOLVED
: No, if the capability is supported in any stage it must be
supported in all stages.
3) Should the capabilities be features or limits?
RESOLVED
: Features, primarily for consistency with other similar
extensions.
Version History
Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)
Internal revisions
VK_KHR_vertex_attribute_divisor
Name String
VK_KHR_vertex_attribute_divisor
Extension Type
Device extension
Registered Extension Number
526
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_KHR_vertex_attribute_divisor
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
VK_EXT_vertex_attribute_divisor
extension.
The only difference is the new property
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
VkVertexInputBindingDivisorDescriptionKHR
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVertexAttributeDivisorFeaturesKHR
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceVertexAttributeDivisorPropertiesKHR
Extending
VkPipelineVertexInputStateCreateInfo
VkPipelineVertexInputDivisorStateCreateInfoKHR
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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the KHR
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2023-09-20 (Shahbaz Youssefi)
First Version, based on
VK_EXT_vertex_attribute_divisor
VK_KHR_vulkan_memory_model
Name String
VK_KHR_vulkan_memory_model
Extension Type
Device extension
Registered Extension Number
212
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_KHR_vulkan_memory_model
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.
Version 3 of the spec added a member
vulkanMemoryModelAvailabilityVisibilityChains
) to
VkPhysicalDeviceVulkanMemoryModelFeaturesKHR
, which is an incompatible
change from version 2.
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.
Promotion to Vulkan 1.3
If Vulkan 1.3 is supported, support for the
vulkanMemoryModel
and
vulkanMemoryModelDeviceScope
capabilities is required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVulkanMemoryModelFeaturesKHR
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
New SPIR-V Capabilities
VulkanMemoryModelKHR
Version History
Revision 1, 2018-06-24 (Jeff Bolz)
Initial draft
Revision 3, 2018-12-10 (Jeff Bolz)
Add vulkanMemoryModelAvailabilityVisibilityChains member to the
VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure.
VK_KHR_zero_initialize_workgroup_memory
Name String
VK_KHR_zero_initialize_workgroup_memory
Extension Type
Device extension
Registered Extension Number
326
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
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 Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceZeroInitializeWorkgroupMemoryFeaturesKHR
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
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the KHR
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2020-11-18 (Alan Baker)
Internal draft version
VK_EXT_4444_formats
Name String
VK_EXT_4444_formats
Extension Type
Device extension
Registered Extension Number
341
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Joshua Ashton
Joshua-Ashton
Other Extension Metadata
Last Modified Date
2020-07-28
IP Status
No known IP claims.
Contributors
Joshua Ashton, Valve
Faith Ekstrand, Intel
Description
This extension defines the
VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT
and
VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT
formats which are defined in other
current graphics APIs.
This extension may be useful for building translation layers for those APIs
or for porting applications that use these formats without having to resort
to swizzles.
When VK_EXT_custom_border_color is used, these formats are not subject to
the same restrictions for border color without format as with
VK_FORMAT_B4G4R4A4_UNORM_PACK16.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevice4444FormatsFeaturesEXT
New Enum Constants
VK_EXT_4444_FORMATS_EXTENSION_NAME
VK_EXT_4444_FORMATS_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT
VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_4444_FORMATS_FEATURES_EXT
Promotion to Vulkan 1.3
The format enumerants introduced by the extension are included in core
Vulkan 1.3, with the EXT suffix omitted.
However, runtime support for these formats is optional in core Vulkan 1.3,
while if this extension is supported, runtime support is mandatory.
The feature structure is not promoted.
The original enum names are still available as aliases of the core
functionality.
Version History
Revision 1, 2020-07-04 (Joshua Ashton)
Initial draft
VK_EXT_buffer_device_address
Name String
VK_EXT_buffer_device_address
Extension Type
Device extension
Registered Extension Number
245
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_physical_storage_buffer
Deprecation State
Deprecated
by
VK_KHR_buffer_device_address
extension
Which in turn was
promoted
to
Vulkan 1.2
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2019-01-06
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GLSL_EXT_buffer_reference
and
GLSL_EXT_buffer_reference_uvec2
Contributors
Jeff Bolz, NVIDIA
Neil Henning, AMD
Tobias Hector, AMD
Faith Ekstrand, Intel
Baldur Karlsson, Valve
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
PhysicalStorageBufferEXT
storage class in the
GL_EXT_buffer_reference
GLSL extension and
SPV_EXT_physical_storage_buffer
SPIR-V extension.
It also allows buffer device addresses to be provided by a trace replay
tool, so that it matches the address used when the trace was captured.
New Commands
vkGetBufferDeviceAddressEXT
New Structures
VkBufferDeviceAddressInfoEXT
Extending
VkBufferCreateInfo
VkBufferDeviceAddressCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceBufferAddressFeaturesEXT
VkPhysicalDeviceBufferDeviceAddressFeaturesEXT
New Enum Constants
VK_EXT_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME
VK_EXT_BUFFER_DEVICE_ADDRESS_SPEC_VERSION
Extending
VkBufferCreateFlagBits
VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT
Extending
VkResult
VK_ERROR_INVALID_DEVICE_ADDRESS_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT
New SPIR-V Capabilities
PhysicalStorageBufferAddressesEXT
Issues
1) Where is VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT
and VkPhysicalDeviceBufferAddressFeaturesEXT?
RESOLVED
: They were renamed as
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT
and
VkPhysicalDeviceBufferDeviceAddressFeaturesEXT
accordingly for
consistency.
Even though, the old names can still be found in the generated header files
for compatibility.
Version History
Revision 1, 2018-11-01 (Jeff Bolz)
Internal revisions
Revision 2, 2019-01-06 (Jon Leech)
Minor updates to appendix for publication
VK_EXT_calibrated_timestamps
Name String
VK_EXT_calibrated_timestamps
Extension Type
Device extension
Registered Extension Number
185
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_calibrated_timestamps
extension
Contact
Daniel Rakos
drakos-amd
Extension Proposal
VK_EXT_calibrated_timestamps
Other Extension Metadata
Last Modified Date
2018-10-04
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Alan Harrison, AMD
Derrick Owens, AMD
Daniel Rakos, AMD
Faith Ekstrand, Intel
Keith Packard, Valve
Description
This extension provides an interface to query calibrated timestamps obtained
quasi simultaneously from two time domains.
Promotion to
VK_KHR_calibrated_timestamps
All functionality in this extension is included in
VK_KHR_calibrated_timestamps
, with the suffix changed to KHR.
The original enum names are still available as aliases of the KHR
functionality.
New Commands
vkGetCalibratedTimestampsEXT
vkGetPhysicalDeviceCalibrateableTimeDomainsEXT
New Structures
VkCalibratedTimestampInfoEXT
New Enums
VkTimeDomainEXT
New Enum Constants
VK_EXT_CALIBRATED_TIMESTAMPS_EXTENSION_NAME
VK_EXT_CALIBRATED_TIMESTAMPS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT
Extending
VkTimeDomainKHR
VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT
VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT
VK_TIME_DOMAIN_DEVICE_EXT
VK_TIME_DOMAIN_QUERY_PERFORMANCE_COUNTER_EXT
Version History
Revision 2, 2021-03-16 (Lionel Landwerlin)
Specify requirement on device timestamps
Revision 1, 2018-10-04 (Daniel Rakos)
Internal revisions.
VK_EXT_debug_marker
Name String
VK_EXT_debug_marker
Extension Type
Device extension
Registered Extension Number
23
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_debug_report
Deprecation State
Promoted
to
VK_EXT_debug_utils
extension
Special Use
Debugging tools
Contact
Baldur Karlsson
baldurk
Other Extension Metadata
Last Modified Date
2017-01-31
IP Status
No known IP claims.
Contributors
Baldur Karlsson
Dan Ginsburg, Valve
Jon Ashburn, LunarG
Kyle Spagnoli, NVIDIA
Description
The
VK_EXT_debug_marker
extension is a device extension.
It introduces concepts of object naming and tagging, for better tracking of
Vulkan objects, as well as additional commands for recording annotations of
named sections of a workload to aid organization and offline analysis in
external tools.
New Commands
vkCmdDebugMarkerBeginEXT
vkCmdDebugMarkerEndEXT
vkCmdDebugMarkerInsertEXT
vkDebugMarkerSetObjectNameEXT
vkDebugMarkerSetObjectTagEXT
New Structures
VkDebugMarkerMarkerInfoEXT
VkDebugMarkerObjectNameInfoEXT
VkDebugMarkerObjectTagInfoEXT
New Enums
VkDebugReportObjectTypeEXT
New Enum Constants
VK_EXT_DEBUG_MARKER_EXTENSION_NAME
VK_EXT_DEBUG_MARKER_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT
VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT
VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_TAG_INFO_EXT
Examples
Example 1
Associate a name with an image, for easier debugging in external tools or
with validation layers that can print a friendly name when referring to
objects in error messages.
extern VkDevice device;
extern VkImage image;

// Must call extension functions through a function pointer:
PFN_vkDebugMarkerSetObjectNameEXT pfnDebugMarkerSetObjectNameEXT = (PFN_vkDebugMarkerSetObjectNameEXT)vkGetDeviceProcAddr(device, "vkDebugMarkerSetObjectNameEXT");

// Set a name on the image
const VkDebugMarkerObjectNameInfoEXT imageNameInfo =
.sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT,
.pNext = NULL,
.objectType = VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT,
.object = (uint64_t)image,
.pObjectName = "Brick Diffuse Texture",
};

pfnDebugMarkerSetObjectNameEXT(device, &imageNameInfo);

// A subsequent error might print:
// Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
// command buffer with no memory bound to it.
Example 2
Annotating regions of a workload with naming information so that offline
analysis tools can display a more usable visualization of the commands
submitted.
extern VkDevice device;
extern VkCommandBuffer commandBuffer;

// Must call extension functions through a function pointer:
PFN_vkCmdDebugMarkerBeginEXT pfnCmdDebugMarkerBeginEXT = (PFN_vkCmdDebugMarkerBeginEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerBeginEXT");
PFN_vkCmdDebugMarkerEndEXT pfnCmdDebugMarkerEndEXT = (PFN_vkCmdDebugMarkerEndEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerEndEXT");
PFN_vkCmdDebugMarkerInsertEXT pfnCmdDebugMarkerInsertEXT = (PFN_vkCmdDebugMarkerInsertEXT)vkGetDeviceProcAddr(device, "vkCmdDebugMarkerInsertEXT");

// Describe the area being rendered
const VkDebugMarkerMarkerInfoEXT houseMarker =
.sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT,
.pNext = NULL,
.pMarkerName = "Brick House",
.color = { 1.0f, 0.0f, 0.0f, 1.0f },
};

// Start an annotated group of calls under the 'Brick House' name
pfnCmdDebugMarkerBeginEXT(commandBuffer, &houseMarker);
// A mutable structure for each part being rendered
VkDebugMarkerMarkerInfoEXT housePartMarker =
.sType = VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT,
.pNext = NULL,
.pMarkerName = NULL,
.color = { 0.0f, 0.0f, 0.0f, 0.0f },
};

// Set the name and insert the marker
housePartMarker.pMarkerName = "Walls";
pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

// Insert the drawcall for the walls
vkCmdDrawIndexed(commandBuffer, 1000, 1, 0, 0, 0);

// Insert a recursive region for two sets of windows
housePartMarker.pMarkerName = "Windows";
pfnCmdDebugMarkerBeginEXT(commandBuffer, &housePartMarker);
vkCmdDrawIndexed(commandBuffer, 75, 6, 1000, 0, 0);
vkCmdDrawIndexed(commandBuffer, 100, 2, 1450, 0, 0);
pfnCmdDebugMarkerEndEXT(commandBuffer);

housePartMarker.pMarkerName = "Front Door";
pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

vkCmdDrawIndexed(commandBuffer, 350, 1, 1650, 0, 0);

housePartMarker.pMarkerName = "Roof";
pfnCmdDebugMarkerInsertEXT(commandBuffer, &housePartMarker);

vkCmdDrawIndexed(commandBuffer, 500, 1, 2000, 0, 0);
// End the house annotation started above
pfnCmdDebugMarkerEndEXT(commandBuffer);
Issues
1) Should the tag or name for an object be specified using the
pNext
parameter in the object’s
Vk*CreateInfo
structure?
RESOLVED
: No.
While this fits with other Vulkan patterns and would allow more type safety
and future proofing against future objects, it has notable downsides.
In particular passing the name at
Vk*CreateInfo
time does not allow
renaming, prevents late binding of naming information, and does not allow
naming of implicitly created objects such as queues and swapchain images.
2) Should the command annotation functions
vkCmdDebugMarkerBeginEXT
and
vkCmdDebugMarkerEndEXT
support the ability to specify a color?
RESOLVED
: Yes.
The functions have been expanded to take an optional color which can be used
at will by implementations consuming the command buffer annotations in their
visualization.
3) Should the functions added in this extension accept an extensible
structure as their parameter for a more flexible API, as opposed to direct
function parameters? If so, which functions?
RESOLVED
: Yes.
All functions have been modified to take a structure type with extensible
pNext
pointer, to allow future extensions to add additional annotation
information in the same commands.
Version History
Revision 1, 2016-02-24 (Baldur Karlsson)
Initial draft, based on LunarG marker spec
Revision 2, 2016-02-26 (Baldur Karlsson)
Renamed Dbg to DebugMarker in function names
Allow markers in secondary command buffers under certain circumstances
Minor language tweaks and edits
Revision 3, 2016-04-23 (Baldur Karlsson)
Reorganize spec layout to closer match desired organization
Added optional color to markers (both regions and inserted labels)
Changed functions to take extensible structs instead of direct function
parameters
Revision 4, 2017-01-31 (Baldur Karlsson)
Added explicit dependency on VK_EXT_debug_report
Moved definition of
VkDebugReportObjectTypeEXT
to debug report
chapter.
Fixed typo in dates in revision history
VK_EXT_debug_report
Name String
VK_EXT_debug_report
Extension Type
Instance extension
Registered Extension Number
12
Revision
10
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_VERSION_1_1
Deprecation State
Deprecated
by
VK_EXT_debug_utils
extension
Special Use
Debugging tools
Contact
Courtney Goeltzenleuchter
courtney-g
Other Extension Metadata
Last Modified Date
2020-12-14
IP Status
No known IP claims.
Contributors
Courtney Goeltzenleuchter, LunarG
Dan Ginsburg, Valve
Jon Ashburn, LunarG
Mark Lobodzinski, LunarG
Description
Due to the nature of the Vulkan interface, there is very little error
information available to the developer and application.
By enabling optional validation layers and using the
VK_EXT_debug_report
extension, developers
can
obtain much more detailed feedback on the
application’s use of Vulkan.
This extension defines a way for layers and the implementation to call back
to the application for events of interest to the application.
New Object Types
VkDebugReportCallbackEXT
New Commands
vkCreateDebugReportCallbackEXT
vkDebugReportMessageEXT
vkDestroyDebugReportCallbackEXT
New Structures
Extending
VkInstanceCreateInfo
VkDebugReportCallbackCreateInfoEXT
New Function Pointers
PFN_vkDebugReportCallbackEXT
New Enums
VkDebugReportFlagBitsEXT
VkDebugReportObjectTypeEXT
New Bitmasks
VkDebugReportFlagsEXT
New Enum Constants
VK_EXT_DEBUG_REPORT_EXTENSION_NAME
VK_EXT_DEBUG_REPORT_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT
Extending
VkResult
VK_ERROR_VALIDATION_FAILED_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT
If
Vulkan Version 1.1
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT
VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT
Examples
VK_EXT_debug_report
allows an application to register multiple callbacks
with the validation layers.
Some callbacks may log the information to a file, others may cause a debug
break point or other application-defined behavior.
An application
can
register callbacks even when no validation layers are
enabled, but they will only be called for loader and, if implemented, driver
events.
To capture events that occur while creating or destroying an instance an
application
can
link a
VkDebugReportCallbackCreateInfoEXT
structure
to the
pNext
chain of the
VkInstanceCreateInfo
structure passed
to
vkCreateInstance
Example uses: Create three callback objects.
One will log errors and warnings to the debug console using Windows
OutputDebugString
The second will cause the debugger to break at that callback when an error
happens and the third will log warnings to stdout.
VkResult res;
VkDebugReportCallbackEXT cb1, cb2, cb3;

VkDebugReportCallbackCreateInfoEXT callback1 = {
.sType = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
.pNext = NULL,
.flags = VK_DEBUG_REPORT_ERROR_BIT_EXT |
VK_DEBUG_REPORT_WARNING_BIT_EXT,
.pfnCallback = myOutputDebugString,
.pUserData = NULL
};
res = vkCreateDebugReportCallbackEXT(instance, &callback1, &cb1);
if (res != VK_SUCCESS)
/* Do error handling for VK_ERROR_OUT_OF_MEMORY */

callback.flags = VK_DEBUG_REPORT_ERROR_BIT_EXT;
callback.pfnCallback = myDebugBreak;
callback.pUserData = NULL;
res = vkCreateDebugReportCallbackEXT(instance, &callback, &cb2);
if (res != VK_SUCCESS)
/* Do error handling for VK_ERROR_OUT_OF_MEMORY */

VkDebugReportCallbackCreateInfoEXT callback3 = {
.sType = VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
.pNext = NULL,
.flags = VK_DEBUG_REPORT_WARNING_BIT_EXT,
.pfnCallback = mystdOutLogger,
.pUserData = NULL
};
res = vkCreateDebugReportCallbackEXT(instance, &callback3, &cb3);
if (res != VK_SUCCESS)
/* Do error handling for VK_ERROR_OUT_OF_MEMORY */

...

/* remove callbacks when cleaning up */
vkDestroyDebugReportCallbackEXT(instance, cb1);
vkDestroyDebugReportCallbackEXT(instance, cb2);
vkDestroyDebugReportCallbackEXT(instance, cb3);
In the initial release of the
VK_EXT_debug_report
extension, the token
VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT
was used.
Starting in version 2 of the extension branch,
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT
is used
instead for consistency with Vulkan naming rules.
The older enum is still available for backwards compatibility.
In the initial release of the
VK_EXT_debug_report
extension, the token
VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT
was used.
Starting in version 8 of the extension branch,
VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT
is used
instead for consistency with Vulkan naming rules.
The older enum is still available for backwards compatibility.
Issues
1) What is the hierarchy / seriousness of the message flags? E.g.
ERROR
WARN
PERF_WARN
…
RESOLVED
: There is no specific hierarchy.
Each bit is independent and should be checked via bitwise AND.
For example:
if (localFlags & VK_DEBUG_REPORT_ERROR_BIT_EXT) {
process error message
if (localFlags & VK_DEBUG_REPORT_DEBUG_BIT_EXT) {
process debug message
The validation layers do use them in a hierarchical way (
ERROR
WARN
PERF
WARN
DEBUG
INFO
) and they (at
least at the time of this writing) only set one bit at a time.
But it is not a requirement of this extension.
It is possible that a layer may intercept and change, or augment the flags
with extension values the application’s debug report handler may not be
familiar with, so it is important to treat each flag independently.
2) Should there be a VU requiring
VkDebugReportCallbackCreateInfoEXT
::
flags
to be non-zero?
RESOLVED
: It may not be very useful, but we do not need VU statement
requiring the
VkDebugReportCallbackCreateInfoEXT
::
msgFlags
at
create-time to be non-zero.
One can imagine that apps may prefer it as it allows them to set the mask as
desired - including nothing - at runtime without having to check.
3) What is the difference between
VK_DEBUG_REPORT_DEBUG_BIT_EXT
and
VK_DEBUG_REPORT_INFORMATION_BIT_EXT
RESOLVED
VK_DEBUG_REPORT_DEBUG_BIT_EXT
specifies information that
could be useful debugging the Vulkan implementation itself.
4) How do you compare handles returned by the debug_report callback to the
application’s handles?
RESOLVED
: Due to the different nature of dispatchable and nondispatchable
handles there is no generic way (that we know of) that works for common C
and C++ compilers in both 32-bit and 64-bit ABIs.
We recommend applications use the same cast that the validation layers use:
reinterpret_cast(dispatchableHandle)
(uint64_t)(nondispatchableHandle)
This does require that the application treat dispatchable and
nondispatchable handles differently.
Version History
Revision 1, 2015-05-20 (Courtney Goetzenleuchter)
Initial draft, based on LunarG KHR spec, other KHR specs
Revision 2, 2016-02-16 (Courtney Goetzenleuchter)
Update usage, documentation
Revision 3, 2016-06-14 (Courtney Goetzenleuchter)
Update VK_EXT_DEBUG_REPORT_SPEC_VERSION to indicate added support for
vkCreateInstance and vkDestroyInstance
Revision 4, 2016-12-08 (Mark Lobodzinski)
Added Display_KHR, DisplayModeKHR extension objects
Added ObjectTable_NVX, IndirectCommandsLayout_NVX extension objects
Bumped spec revision
Retroactively added version history
Revision 5, 2017-01-31 (Baldur Karlsson)
Moved definition of
VkDebugReportObjectTypeEXT
from debug marker
chapter
Revision 6, 2017-01-31 (Baldur Karlsson)
Added VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT
Revision 7, 2017-04-20 (Courtney Goeltzenleuchter)
Clarify wording and address questions from developers.
Revision 8, 2017-04-21 (Courtney Goeltzenleuchter)
Remove unused enum VkDebugReportErrorEXT
Revision 9, 2017-09-12 (Tobias Hector)
Added interactions with Vulkan 1.1
Revision 10, 2020-12-14 (Courtney Goetzenleuchter)
Add issue 4 discussing matching handles returned by the extension,
based on suggestion in public issue 368.
VK_EXT_depth_clamp_zero_one
Name String
VK_EXT_depth_clamp_zero_one
Extension Type
Device extension
Registered Extension Number
422
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_depth_clamp_zero_one
extension
Contact
Graeme Leese
gnl21
Other Extension Metadata
Last Modified Date
2021-07-29
Contributors
Graeme Leese, Broadcom
Description
This extension gives defined behavior to fragment depth values which end up
outside the conventional [0, 1] range.
It can be used to ensure portability in edge cases of features like
depthBias.
The particular behavior is chosen to match OpenGL to aid porting or
emulation.
Promotion to
VK_KHR_depth_clamp_zero_one
All functionality in this extension is included in
VK_KHR_depth_clamp_zero_one
, with the suffix change to KHR.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDepthClampZeroOneFeaturesEXT
New Enum Constants
VK_EXT_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME
VK_EXT_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_EXT
Version History
Revision 1, 2021-07-29 (Graeme Leese)
Internal revisions
VK_EXT_descriptor_buffer
Name String
VK_EXT_descriptor_buffer
Extension Type
Device extension
Registered Extension Number
317
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_buffer_device_address
and
VK_EXT_descriptor_indexing
or
Vulkan Version 1.2
and
VK_KHR_synchronization2
or
Vulkan Version 1.3
API Interactions
Interacts with VK_EXT_fragment_density_map
Interacts with VK_KHR_acceleration_structure
Interacts with VK_NV_ray_tracing
Deprecation State
Deprecated
by
VK_EXT_descriptor_heap
extension
Contact
Tobias Hector
tobski
Extension Proposal
VK_EXT_descriptor_buffer
Other Extension Metadata
Last Modified Date
2021-06-07
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Stu Smith, AMD
Maciej Jesionowski, AMD
Boris Zanin, AMD
Hans-Kristian Arntzen, Valve
Connor Abbott, Valve
Baldur Karlsson, Valve
Mike Blumenkrantz, Valve
Graeme Leese, Broadcom
Jan-Harald Fredriksen, Arm
Rodrigo Locatti, NVIDIA
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Jeff Leger, QUALCOMM
Lionel Landwerlin, Intel
Slawomir Grajewski, Intel
Description
This extension introduces new commands to put shader-accessible descriptors
directly in memory, making the management of descriptor data more explicit.
Deprecation by
VK_EXT_descriptor_heap
Functionality in this extension is deprecated by the
VK_EXT_descriptor_heap
extension.
See
Descriptor Management: Replaced by Descriptor Heaps
New Commands
vkCmdBindDescriptorBufferEmbeddedSamplersEXT
vkCmdBindDescriptorBuffersEXT
vkCmdSetDescriptorBufferOffsetsEXT
vkGetBufferOpaqueCaptureDescriptorDataEXT
vkGetDescriptorEXT
vkGetDescriptorSetLayoutBindingOffsetEXT
vkGetDescriptorSetLayoutSizeEXT
vkGetImageOpaqueCaptureDescriptorDataEXT
vkGetImageViewOpaqueCaptureDescriptorDataEXT
vkGetSamplerOpaqueCaptureDescriptorDataEXT
If
VK_KHR_acceleration_structure
or
VK_NV_ray_tracing
is supported:
vkGetAccelerationStructureOpaqueCaptureDescriptorDataEXT
New Structures
VkBufferCaptureDescriptorDataInfoEXT
VkDescriptorAddressInfoEXT
VkDescriptorBufferBindingInfoEXT
VkDescriptorGetInfoEXT
VkImageCaptureDescriptorDataInfoEXT
VkImageViewCaptureDescriptorDataInfoEXT
VkSamplerCaptureDescriptorDataInfoEXT
Extending
VkBufferCreateInfo
VkImageCreateInfo
VkImageViewCreateInfo
VkSamplerCreateInfo
VkAccelerationStructureCreateInfoKHR
VkAccelerationStructureCreateInfoNV
VkTensorCreateInfoARM
VkTensorViewCreateInfoARM
VkAccelerationStructureCreateInfo2KHR
VkOpaqueCaptureDescriptorDataCreateInfoEXT
Extending
VkDescriptorBufferBindingInfoEXT
VkDescriptorBufferBindingPushDescriptorBufferHandleEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorBufferFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorBufferPropertiesEXT
If
VK_EXT_fragment_density_map
is supported:
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorBufferDensityMapPropertiesEXT
If
VK_KHR_acceleration_structure
or
VK_NV_ray_tracing
is supported:
VkAccelerationStructureCaptureDescriptorDataInfoEXT
New Unions
VkDescriptorDataEXT
New Enum Constants
VK_EXT_DESCRIPTOR_BUFFER_EXTENSION_NAME
VK_EXT_DESCRIPTOR_BUFFER_SPEC_VERSION
Extending
VkAccelerationStructureCreateFlagBitsKHR
VK_ACCELERATION_STRUCTURE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT
Extending
VkAccessFlagBits2
VK_ACCESS_2_DESCRIPTOR_BUFFER_READ_BIT_EXT
Extending
VkBufferCreateFlagBits
VK_BUFFER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT
VK_BUFFER_USAGE_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT
VK_BUFFER_USAGE_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_DESCRIPTOR_BUFFER_BIT_EXT
VK_DESCRIPTOR_SET_LAYOUT_CREATE_EMBEDDED_IMMUTABLE_SAMPLERS_BIT_EXT
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT
Extending
VkImageViewCreateFlagBits
VK_IMAGE_VIEW_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_DESCRIPTOR_BUFFER_BIT_EXT
Extending
VkSamplerCreateFlagBits
VK_SAMPLER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_BUFFER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_ADDRESS_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_PUSH_DESCRIPTOR_BUFFER_HANDLE_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_GET_INFO_EXT
VK_STRUCTURE_TYPE_IMAGE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT
VK_STRUCTURE_TYPE_IMAGE_VIEW_CAPTURE_DESCRIPTOR_DATA_INFO_EXT
VK_STRUCTURE_TYPE_OPAQUE_CAPTURE_DESCRIPTOR_DATA_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_DENSITY_MAP_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_PROPERTIES_EXT
VK_STRUCTURE_TYPE_SAMPLER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT
If
VK_KHR_acceleration_structure
or
VK_NV_ray_tracing
is supported:
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT
Version History
Revision 1, 2021-06-07 (Stu Smith)
Initial revision
VK_EXT_descriptor_indexing
Name String
VK_EXT_descriptor_indexing
Extension Type
Device extension
Registered Extension Number
162
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_maintenance3
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_descriptor_indexing
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-10-02
Interactions and External Dependencies
This extension provides API support for
GL_EXT_nonuniform_qualifier
Contributors
Jeff Bolz, NVIDIA
Daniel Rakos, AMD
Slawomir Grajewski, Intel
Tobias Hector, Imagination Technologies
Description
This extension adds several small features which together enable
applications to create large descriptor sets containing substantially all of
their resources, and selecting amongst those resources with dynamic
(non-uniform) indexes in the shader.
There are feature enables and SPIR-V capabilities for non-uniform descriptor
indexing in the shader, and non-uniform indexing in the shader requires use
of a new
NonUniformEXT
decoration defined in the
SPV_EXT_descriptor_indexing
SPIR-V extension.
There are descriptor set layout binding creation flags enabling several
features:
Descriptors can be updated after they are bound to a command buffer,
such that the execution of the command buffer reflects the most recent
update to the descriptors.
Descriptors that are not used by any pending command buffers can be
updated, which enables writing new descriptors for frame N+1 while frame
N is executing.
Relax the requirement that all descriptors in a binding that is
“statically used” must be valid, such that descriptors that are not
accessed by a submission need not be valid and can be updated while that
submission is executing.
The final binding in a descriptor set layout can have a variable size
(and unsized arrays of resources are allowed in the
GL_EXT_nonuniform_qualifier
and
SPV_EXT_descriptor_indexing
extensions).
Note that it is valid for multiple descriptor arrays in a shader to use the
same set and binding number, as long as they are all compatible with the
descriptor type in the pipeline layout.
This means a single array binding in the descriptor set can serve multiple
texture dimensionalities, or an array of buffer descriptors can be used with
multiple different block layouts.
There are new descriptor set layout and descriptor pool creation flags that
are required to opt in to the update-after-bind functionality, and there are
separate
maxPerStage
* and
maxDescriptorSet
* limits that apply to
these descriptor set layouts which
may
be much higher than the pre-existing
limits.
The old limits only count descriptors in non-updateAfterBind descriptor set
layouts, and the new limits count descriptors in all descriptor set layouts
in the pipeline layout.
Promotion to Vulkan 1.2
Vulkan APIs in this extension are included in core Vulkan 1.2, with the EXT
suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
descriptorIndexing
capability is optional.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
shaderUniformTexelBufferArrayDynamicIndexing
and
shaderStorageTexelBufferArrayDynamicIndexing
capabilities is required.
New Structures
Extending
VkDescriptorSetAllocateInfo
VkDescriptorSetVariableDescriptorCountAllocateInfoEXT
Extending
VkDescriptorSetLayoutCreateInfo
VkDescriptorSetLayoutBindingFlagsCreateInfoEXT
Extending
VkDescriptorSetLayoutSupport
VkDescriptorSetVariableDescriptorCountLayoutSupportEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDescriptorIndexingFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDescriptorIndexingPropertiesEXT
New Enums
VkDescriptorBindingFlagBitsEXT
New Bitmasks
VkDescriptorBindingFlagsEXT
New Enum Constants
VK_EXT_DESCRIPTOR_INDEXING_EXTENSION_NAME
VK_EXT_DESCRIPTOR_INDEXING_SPEC_VERSION
Extending
VkDescriptorBindingFlagBits
VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT_EXT
VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT
VK_DESCRIPTOR_BINDING_UPDATE_UNUSED_WHILE_PENDING_BIT_EXT
VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT
Extending
VkDescriptorPoolCreateFlagBits
VK_DESCRIPTOR_POOL_CREATE_UPDATE_AFTER_BIND_BIT_EXT
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT
Extending
VkResult
VK_ERROR_FRAGMENTATION_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_ALLOCATE_INFO_EXT
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_LAYOUT_SUPPORT_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_PROPERTIES_EXT
Version History
Revision 1, 2017-07-26 (Jeff Bolz)
Internal revisions
Revision 2, 2017-10-02 (Jeff Bolz)
???
VK_EXT_device_fault
Name String
VK_EXT_device_fault
Extension Type
Device extension
Registered Extension Number
342
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_device_fault
extension
Contact
Ralph Potter
r_potter
Extension Proposal
VK_EXT_device_fault
Other Extension Metadata
Last Modified Date
2021-03-10
IP Status
No known IP claims.
Contributors
Ralph Potter, Samsung
Stuart Smith, AMD
Jan-Harald Fredriksen, ARM
Mark Bellamy, ARM
Andrew Ellem, Google
Alex Walters, IMG
Jeff Bolz, NVIDIA
Baldur Karlsson, Valve
Description
Device loss can be triggered by a variety of issues, including invalid API
usage, implementation errors, or hardware failures.
This extension introduces a new command:
vkGetDeviceFaultInfoEXT
which may be called subsequent to a
VK_ERROR_DEVICE_LOST
error code
having been returned by the implementation.
This command allows developers to query for additional information on GPU
faults which may have caused device loss, and to generate binary crash
dumps, which may be loaded into external tools for further diagnosis.
New Commands
vkGetDeviceFaultInfoEXT
New Structures
VkDeviceFaultAddressInfoEXT
VkDeviceFaultCountsEXT
VkDeviceFaultInfoEXT
VkDeviceFaultVendorBinaryHeaderVersionOneEXT
VkDeviceFaultVendorInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFaultFeaturesEXT
New Enums
VkDeviceFaultAddressTypeEXT
VkDeviceFaultVendorBinaryHeaderVersionEXT
New Enum Constants
VK_EXT_DEVICE_FAULT_EXTENSION_NAME
VK_EXT_DEVICE_FAULT_SPEC_VERSION
Extending
VkDeviceFaultAddressTypeKHR
VK_DEVICE_FAULT_ADDRESS_TYPE_EXECUTE_INVALID_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_FAULT_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_INVALID_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_INSTRUCTION_POINTER_UNKNOWN_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT
VK_DEVICE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_FAULT_COUNTS_EXT
VK_STRUCTURE_TYPE_DEVICE_FAULT_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FAULT_FEATURES_EXT
Version History
Revision 2, 2023-04-05 (Ralph Potter)
Restored two missing members to the XML definition of
VkDeviceFaultVendorBinaryHeaderVersionOneEXT.
No functional change to the specification.
Revision 1, 2020-10-19 (Ralph Potter)
Initial revision
VK_EXT_extended_dynamic_state
Name String
VK_EXT_extended_dynamic_state
Extension Type
Device extension
Registered Extension Number
268
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2019-12-09
IP Status
No known IP claims.
Contributors
Dan Ginsburg, Valve Corporation
Graeme Leese, Broadcom
Hans-Kristian Arntzen, Valve Corporation
Jan-Harald Fredriksen, Arm Limited
Faith Ekstrand, Intel
Jeff Bolz, NVIDIA
Jesse Hall, Google
Philip Rebohle, Valve Corporation
Stuart Smith, Imagination Technologies
Tobias Hector, AMD
Description
This extension adds some more dynamic state to support applications that
need to reduce the number of pipeline state objects they compile and bind.
New Commands
vkCmdBindVertexBuffers2EXT
vkCmdSetCullModeEXT
vkCmdSetDepthBoundsTestEnableEXT
vkCmdSetDepthCompareOpEXT
vkCmdSetDepthTestEnableEXT
vkCmdSetDepthWriteEnableEXT
vkCmdSetFrontFaceEXT
vkCmdSetPrimitiveTopologyEXT
vkCmdSetScissorWithCountEXT
vkCmdSetStencilOpEXT
vkCmdSetStencilTestEnableEXT
vkCmdSetViewportWithCountEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExtendedDynamicStateFeaturesEXT
New Enum Constants
VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME
VK_EXT_EXTENDED_DYNAMIC_STATE_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_CULL_MODE_EXT
VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE_EXT
VK_DYNAMIC_STATE_DEPTH_COMPARE_OP_EXT
VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE_EXT
VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE_EXT
VK_DYNAMIC_STATE_FRONT_FACE_EXT
VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY_EXT
VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT_EXT
VK_DYNAMIC_STATE_STENCIL_OP_EXT
VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE_EXT
VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE_EXT
VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_FEATURES_EXT
Promotion to Vulkan 1.3
All dynamic state enumerants and commands in this extension are included in
core Vulkan 1.3, with the EXT suffix omitted.
The feature structure is not promoted.
Extension interfaces that were promoted remain available as aliases of the
core functionality.
Issues
1) Why are the values of
pStrides
in
vkCmdBindVertexBuffers2
limited to be between 0 and the maximum extent of the binding, when this
restriction is not present for the same static state?
Implementing these edge cases adds overhead to some implementations that
would require significant cost when calling this function, and the intention
is that this state should be more or less free to change.
VK_EXT_vertex_input_dynamic_state
allows the stride to be changed
freely when supported via
vkCmdSetVertexInputEXT
Version History
Revision 1, 2019-12-09 (Piers Daniell)
Internal revisions
VK_EXT_extended_dynamic_state2
Name String
VK_EXT_extended_dynamic_state2
Extension Type
Device extension
Registered Extension Number
378
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Vikram Kushwaha
vkushwaha-nv
Other Extension Metadata
Last Modified Date
2021-04-12
IP Status
No known IP claims.
Contributors
Vikram Kushwaha, NVIDIA
Piers Daniell, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds some more dynamic state to support applications that
need to reduce the number of pipeline state objects they compile and bind.
New Commands
vkCmdSetDepthBiasEnableEXT
vkCmdSetLogicOpEXT
vkCmdSetPatchControlPointsEXT
vkCmdSetPrimitiveRestartEnableEXT
vkCmdSetRasterizerDiscardEnableEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceExtendedDynamicState2FeaturesEXT
New Enum Constants
VK_EXT_EXTENDED_DYNAMIC_STATE_2_EXTENSION_NAME
VK_EXT_EXTENDED_DYNAMIC_STATE_2_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT
VK_DYNAMIC_STATE_LOGIC_OP_EXT
VK_DYNAMIC_STATE_PATCH_CONTROL_POINTS_EXT
VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_2_FEATURES_EXT
Promotion to Vulkan 1.3
The dynamic state enumerants
VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT
VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT
, and
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT
; and the corresponding
commands in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
The enumerants and commands for dynamic logic operation and patch control
points are not promoted, nor is the feature structure.
Extension interfaces that were promoted remain available as aliases of the
core functionality.
Version History
Revision 1, 2021-04-12 (Vikram Kushwaha)
Internal revisions
VK_EXT_global_priority
Name String
VK_EXT_global_priority
Extension Type
Device extension
Registered Extension Number
175
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
VK_KHR_global_priority
extension
Which in turn was
promoted
to
Vulkan 1.4
Contact
Andres Rodriguez
lostgoat
Other Extension Metadata
Last Modified Date
2017-10-06
IP Status
No known IP claims.
Contributors
Andres Rodriguez, Valve
Pierre-Loup Griffais, Valve
Dan Ginsburg, Valve
Mitch Singer, AMD
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 extension provides a mechanism for callers to set their system-wide
priority.
The default queue priority is
VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT
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 Structures
Extending
VkDeviceQueueCreateInfo
VkDeviceQueueGlobalPriorityCreateInfoEXT
New Enums
VkQueueGlobalPriorityEXT
New Enum Constants
VK_EXT_GLOBAL_PRIORITY_EXTENSION_NAME
VK_EXT_GLOBAL_PRIORITY_SPEC_VERSION
Extending
VkQueueGlobalPriority
VK_QUEUE_GLOBAL_PRIORITY_HIGH_EXT
VK_QUEUE_GLOBAL_PRIORITY_LOW_EXT
VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT
VK_QUEUE_GLOBAL_PRIORITY_REALTIME_EXT
Extending
VkResult
VK_ERROR_NOT_PERMITTED_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT
Version History
Revision 2, 2017-11-03 (Andres Rodriguez)
Fixed VkQueueGlobalPriorityEXT missing _EXT suffix
Revision 1, 2017-10-06 (Andres Rodriguez)
First version.
VK_EXT_global_priority_query
Name String
VK_EXT_global_priority_query
Extension Type
Device extension
Registered Extension Number
389
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_global_priority
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_global_priority
extension
Which in turn was
promoted
to
Vulkan 1.4
Contact
Yiwei Zhang
zzyiwei
Other Extension Metadata
Last Modified Date
2021-03-29
IP Status
No known IP claims.
Contributors
Yiwei Zhang, Google
Description
This device extension allows applications to query the global queue
priorities supported by a queue family.
It allows implementations to report which global priority levels are treated
differently by the implementation, instead of silently mapping multiple
requested global priority levels to the same internal priority, or using
device creation failure to signal that a requested priority is not
supported.
It is intended primarily for use by system integration along with certain
platform-specific priority enforcement rules.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceGlobalPriorityQueryFeaturesEXT
Extending
VkQueueFamilyProperties2
VkQueueFamilyGlobalPriorityPropertiesEXT
New Enum Constants
VK_EXT_GLOBAL_PRIORITY_QUERY_EXTENSION_NAME
VK_EXT_GLOBAL_PRIORITY_QUERY_SPEC_VERSION
VK_MAX_GLOBAL_PRIORITY_SIZE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_EXT
VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_EXT
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.
Version History
Revision 1, 2021-03-29 (Yiwei Zhang)
VK_EXT_host_image_copy
Name String
VK_EXT_host_image_copy
Extension Type
Device extension
Registered Extension Number
271
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_copy_commands2
and
VK_KHR_format_feature_flags2
or
Vulkan Version 1.3
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_host_image_copy
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_BIT_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 Commands
vkCopyImageToImageEXT
vkCopyImageToMemoryEXT
vkCopyMemoryToImageEXT
vkGetImageSubresourceLayout2EXT
vkTransitionImageLayoutEXT
New Structures
VkCopyImageToImageInfoEXT
VkCopyImageToMemoryInfoEXT
VkCopyMemoryToImageInfoEXT
VkHostImageLayoutTransitionInfoEXT
VkImageSubresource2EXT
VkImageToMemoryCopyEXT
VkMemoryToImageCopyEXT
VkSubresourceLayout2EXT
Extending
VkImageFormatProperties2
VkHostImageCopyDevicePerformanceQueryEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceHostImageCopyFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceHostImageCopyPropertiesEXT
Extending
VkSubresourceLayout2
VkSubresourceHostMemcpySizeEXT
New Enums
VkHostImageCopyFlagBitsEXT
New Bitmasks
VkHostImageCopyFlagsEXT
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
VkHostImageCopyFlagBits
VK_HOST_IMAGE_COPY_MEMCPY_BIT_EXT
VK_HOST_IMAGE_COPY_MEMCPY_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
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4, with the EXT
suffix omitted.
However, the feature is made optional in Vulkan 1.4.
The original type, enum, and command names are still available as aliases of
the core functionality.
A Vulkan 1.4 implementation that has a
VK_QUEUE_GRAPHICS_BIT
queue
must support either:
the
hostImageCopy
feature; or
an additional queue that supports
VK_QUEUE_TRANSFER_BIT
Additionally, all queues supporting
VK_QUEUE_GRAPHICS_BIT
or
VK_QUEUE_COMPUTE_BIT
must also advertise
VK_QUEUE_TRANSFER_BIT
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.
Version History
Revision 0, 2021-01-20 (Faith Ekstrand)
Initial idea and xml
Revision 1, 2023-04-26 (Shahbaz Youssefi)
Initial revision
VK_EXT_host_query_reset
Name String
VK_EXT_host_query_reset
Extension Type
Device extension
Registered Extension Number
262
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Bas Nieuwenhuizen
BNieuwenhuizen
Other Extension Metadata
Last Modified Date
2019-03-06
IP Status
No known IP claims.
Contributors
Bas Nieuwenhuizen, Google
Faith Ekstrand, Intel
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Description
This extension adds a new function to reset queries from the host.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
EXT suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Commands
vkResetQueryPoolEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceHostQueryResetFeaturesEXT
New Enum Constants
VK_EXT_HOST_QUERY_RESET_EXTENSION_NAME
VK_EXT_HOST_QUERY_RESET_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_QUERY_RESET_FEATURES_EXT
Version History
Revision 1, 2019-03-12 (Bas Nieuwenhuizen)
Initial draft
VK_EXT_image_robustness
Name String
VK_EXT_image_robustness
Extension Type
Device extension
Registered Extension Number
336
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Graeme Leese
gnl21
Other Extension Metadata
Last Modified Date
2020-04-27
IP Status
No known IP claims.
Contributors
Graeme Leese, Broadcom
Jan-Harald Fredriksen, ARM
Jeff Bolz, NVIDIA
Spencer Fricke, Samsung
Courtney Goeltzenleuchter, Google
Slawomir Cygan, Intel
Description
This extension adds stricter requirements for how out of bounds reads from
images are handled.
Rather than returning undefined values, most out of bounds reads return R,
G, and B values of zero and alpha values of either zero or one.
Components not present in the image format may be set to zero or to values
based on the format as described in
Component Substitution
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceImageRobustnessFeaturesEXT
New Enum Constants
VK_EXT_IMAGE_ROBUSTNESS_EXTENSION_NAME
VK_EXT_IMAGE_ROBUSTNESS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ROBUSTNESS_FEATURES_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Issues
How does this extension differ from VK_EXT_robustness2?
The guarantees provided by this extension are a subset of those provided by
the robustImageAccess2 feature of VK_EXT_robustness2.
Where this extension allows return values of (0, 0, 0, 0) or (0, 0, 0, 1),
robustImageAccess2 requires that a particular value dependent on the image
format be returned.
This extension provides no guarantees about the values returned for an
access to an invalid Lod.
Examples
None.
Version History
Revision 1, 2020-04-27 (Graeme Leese)
Initial draft
VK_EXT_index_type_uint8
Name String
VK_EXT_index_type_uint8
Extension Type
Device extension
Registered Extension Number
266
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_index_type_uint8
extension
Which in turn was
promoted
to
Vulkan 1.4
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2019-05-02
IP Status
No known IP claims.
Contributors
Jeff Bolz, NVIDIA
Description
This extension allows
uint8_t
indices to be used with
vkCmdBindIndexBuffer
Promotion to
VK_KHR_index_type_uint8
All functionality in this extension is included in
VK_KHR_index_type_uint8
, with the suffix changed to KHR.
The original enum names are still available as aliases of the KHR
functionality.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceIndexTypeUint8FeaturesEXT
New Enum Constants
VK_EXT_INDEX_TYPE_UINT8_EXTENSION_NAME
VK_EXT_INDEX_TYPE_UINT8_SPEC_VERSION
Extending
VkIndexType
VK_INDEX_TYPE_UINT8_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_EXT
Version History
Revision 1, 2019-05-02 (Piers Daniell)
Internal revisions
VK_EXT_inline_uniform_block
Name String
VK_EXT_inline_uniform_block
Extension Type
Device extension
Registered Extension Number
139
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_maintenance1
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_2
Interacts with VK_EXT_descriptor_indexing
Interacts with VkPhysicalDeviceVulkan12Features::descriptorIndexing
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Daniel Rakos
aqnuep
Other Extension Metadata
Last Modified Date
2018-08-01
IP Status
No known IP claims.
Contributors
Daniel Rakos, AMD
Jeff Bolz, NVIDIA
Slawomir Grajewski, Intel
Neil Henning, Codeplay
Description
This extension introduces the ability to back uniform blocks directly with
descriptor sets by storing inline uniform data within descriptor pool
storage.
Compared to push constants this new construct allows uniform data to be
reused across multiple disjoint sets of drawing or dispatching commands and
may
enable uniform data to be accessed with fewer indirections compared to
uniforms backed by buffer memory.
New Structures
Extending
VkDescriptorPoolCreateInfo
VkDescriptorPoolInlineUniformBlockCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceInlineUniformBlockFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceInlineUniformBlockPropertiesEXT
Extending
VkWriteDescriptorSet
VkWriteDescriptorSetInlineUniformBlockEXT
New Enum Constants
VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME
VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Vulkan 1.3 adds
additional functionality related to this extension
in the form of the
maxInlineUniformTotalSize
limit.
Issues
1) Do we need a new storage class for inline uniform blocks vs. uniform
blocks?
RESOLVED
: No.
The
Uniform
storage class is used to allow the same syntax used for
both uniform buffers and inline uniform blocks.
2) Is the descriptor array index and array size expressed in terms of bytes
or dwords for inline uniform block descriptors?
RESOLVED
: In bytes, but both
must
be a multiple of 4, similar to how push
constant ranges are specified.
The
descriptorCount
of
VkDescriptorSetLayoutBinding
thus
provides the total number of bytes a particular binding with an inline
uniform block descriptor type can hold, while the
srcArrayElement
dstArrayElement
, and
descriptorCount
members of
VkWriteDescriptorSet
VkCopyDescriptorSet
, and
VkDescriptorUpdateTemplateEntry
(where applicable) specify the byte
offset and number of bytes to write/copy to the binding’s backing store.
Additionally, the
stride
member of
VkDescriptorUpdateTemplateEntry
is ignored for inline uniform blocks
and a default value of one is used, meaning that the data to update inline
uniform block bindings with must be contiguous in memory.
3) What layout rules apply for uniform blocks corresponding to inline
constants?
RESOLVED
: They use the same layout rules as uniform buffers.
4) Do we need to add non-uniform indexing features/properties as introduced
by
VK_EXT_descriptor_indexing
for inline uniform blocks?
RESOLVED
: No, because inline uniform blocks are not allowed to be
“arrayed”.
A single binding with an inline uniform block descriptor type corresponds to
a single uniform block instance and the array indices inside that binding
refer to individual offsets within the uniform block (see issue #2).
However, this extension does introduce new features/properties about the
level of support for update-after-bind inline uniform blocks.
5) Is the
descriptorBindingVariableDescriptorCount
feature introduced by
VK_EXT_descriptor_indexing
supported for inline uniform blocks?
RESOLVED
: Yes, as long as other inline uniform block specific limits are
respected.
6) Do the robustness guarantees of
robustBufferAccess
apply to inline
uniform block accesses?
RESOLVED
: No, similarly to push constants, as they are not backed by
buffer memory like uniform buffers.
Version History
Revision 1, 2018-08-01 (Daniel Rakos)
Internal revisions
VK_EXT_line_rasterization
Name String
VK_EXT_line_rasterization
Extension Type
Device extension
Registered Extension Number
260
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_line_rasterization
extension
Which in turn was
promoted
to
Vulkan 1.4
Special Use
CAD support
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2019-05-09
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.
Promotion to
VK_KHR_line_rasterization
All functionality in this extension is included in
VK_KHR_line_rasterization
, with the suffix changed to KHR.
The original enum names are still available as aliases of the KHR
functionality.
New Commands
vkCmdSetLineStippleEXT
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceLineRasterizationFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceLineRasterizationPropertiesEXT
Extending
VkPipelineRasterizationStateCreateInfo
VkPipelineRasterizationLineStateCreateInfoEXT
New Enums
VkLineRasterizationModeEXT
New Enum Constants
VK_EXT_LINE_RASTERIZATION_EXTENSION_NAME
VK_EXT_LINE_RASTERIZATION_SPEC_VERSION
Extending
VkDynamicState
VK_DYNAMIC_STATE_LINE_STIPPLE_EXT
Extending
VkLineRasterizationMode
VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT
VK_LINE_RASTERIZATION_MODE_DEFAULT_EXT
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_EXT
VK_LINE_RASTERIZATION_MODE_RECTANGULAR_SMOOTH_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_EXT
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.
Version History
Revision 1, 2019-05-09 (Jeff Bolz)
Initial draft
VK_EXT_load_store_op_none
Name String
VK_EXT_load_store_op_none
Extension Type
Device extension
Registered Extension Number
401
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
VK_KHR_load_store_op_none
extension
Which in turn was
promoted
to
Vulkan 1.4
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
VK_QCOM_render_pass_store_ops
, enabling applications to avoid
unnecessary synchronization when an attachment is not written during a
render pass.
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
While
VK_ATTACHMENT_STORE_OP_NONE
is part of Vulkan 1.3, this
extension was not promoted to core either in whole or in part.
This functionality was promoted from
VK_KHR_dynamic_rendering
Version History
Revision 1, 2021-06-06 (Shahbaz Youssefi)
Initial revision, based on VK_QCOM_render_pass_store_ops.
Added VK_ATTACHMENT_LOAD_OP_NONE_EXT.
VK_EXT_pipeline_creation_cache_control
Name String
VK_EXT_pipeline_creation_cache_control
Extension Type
Device extension
Registered Extension Number
298
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Gregory Grebe
grgrebe_amd
Other Extension Metadata
Last Modified Date
2020-03-23
IP Status
No known IP claims.
Contributors
Gregory Grebe, AMD
Tobias Hector, AMD
Matthaeus Chajdas, AMD
Mitch Singer, AMD
Spencer Fricke, Samsung Electronics
Stuart Smith, Imagination Technologies
Jeff Bolz, NVIDIA Corporation
Daniel Koch, NVIDIA Corporation
Dan Ginsburg, Valve Corporation
Jeff Leger, QUALCOMM
Michal Pietrasiuk, Intel
Jan-Harald Fredriksen, Arm Limited
Description
This extension adds flags to
Vk*PipelineCreateInfo
and
VkPipelineCacheCreateInfo
structures with the aim of improving the
predictability of pipeline creation cost.
The goal is to provide information about potentially expensive hazards
within the client driver during pipeline creation to the application before
carrying them out rather than after.
Background
Pipeline creation is a costly operation, and the explicit nature of the
Vulkan design means that cost is not hidden from the developer.
Applications are also expected to schedule, prioritize, and load balance all
calls for pipeline creation.
It is strongly advised that applications create pipelines sufficiently ahead
of their usage.
Failure to do so will result in an unresponsive application, intermittent
stuttering, or other poor user experiences.
Proper usage of pipeline caches and/or derivative pipelines help mitigate
this but is not assured to eliminate disruption in all cases.
In the event that an ahead-of-time creation is not possible, considerations
should be taken to ensure that the current execution context is suitable for
the workload of pipeline creation including possible shader compilation.
Applications making API calls to create a pipeline must be prepared for any
of the following to occur:
OS/kernel calls to be made by the ICD
Internal memory allocation not tracked by the
pAllocator
passed to
vkCreate*Pipelines
Internal thread synchronization or yielding of the current thread’s core
Extremely long (multi-millisecond+), blocking, compilation times
Arbitrary call stacks depths and stack memory usage
The job or task based game engines that are being developed to take
advantage of explicit graphics APIs like Vulkan may behave exceptionally
poorly if any of the above scenarios occur.
However, most game engines are already built to “stream” in assets
dynamically as the user plays the game.
By adding control by way of
VkPipelineCreateFlags
, we can require an
ICD to report back a failure in critical execution paths rather than forcing
an unexpected wait.
Applications can prevent unexpected compilation by setting
VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT
on
Vk*PipelineCreateInfo
::
flags
When set, an ICD must not attempt pipeline or shader compilation to create
the pipeline object.
In such a case, if the implementation fails to create a pipeline without
compilation, the implementation
must
return the result
VK_PIPELINE_COMPILE_REQUIRED_EXT
and return
VK_NULL_HANDLE
for
the pipeline.
By default
vkCreate*Pipelines
calls must attempt to create all
pipelines before returning.
Setting
VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT
on
Vk*PipelineCreateInfo
::
flags
can be used as an escape hatch for
batched pipeline creates.
Hidden locks also add to the unpredictability of the cost of pipeline
creation.
The most common case of locks inside the
vkCreate*Pipelines
is
internal synchronization of the
VkPipelineCache
object.
VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT
can be set
when calling
vkCreatePipelineCache
to state the cache is
externally synchronized
The hope is that armed with this information application and engine
developers can leverage existing asset streaming systems to recover from
"just-in-time" pipeline creation stalls.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineCreationCacheControlFeaturesEXT
New Enums
VkPipelineCacheCreateFlagBits
New Enum Constants
VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_EXTENSION_NAME
VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_SPEC_VERSION
Extending
VkPipelineCacheCreateFlagBits
VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT
VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT
Extending
VkResult
VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT
VK_PIPELINE_COMPILE_REQUIRED_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CREATION_CACHE_CONTROL_FEATURES_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2019-11-01 (Gregory Grebe)
Initial revision
Revision 2, 2020-02-24 (Gregory Grebe)
Initial public revision
Revision 3, 2020-03-23 (Tobias Hector)
Changed
VK_PIPELINE_COMPILE_REQUIRED_EXT
to a success code,
adding an alias for the original
VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT
Also updated the xml to include these codes as return values.
VK_EXT_pipeline_creation_feedback
Name String
VK_EXT_pipeline_creation_feedback
Extension Type
Device extension
Registered Extension Number
193
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
Vulkan 1.3
Special Use
Developer tools
Contact
Jean-Francois Roy
jfroy
Other Extension Metadata
Last Modified Date
2019-03-12
IP Status
No known IP claims.
Contributors
Jean-Francois Roy, Google
Hai Nguyen, Google
Andrew Ellem, Google
Bob Fraser, Google
Sujeevan Rajayogam, Google
Jan-Harald Fredriksen, ARM
Jeff Leger, Qualcomm Technologies, Inc.
Jeff Bolz, NVIDIA
Daniel Koch, NVIDIA
Neil Henning, AMD
Description
This extension adds a mechanism to provide feedback to an application about
pipeline creation, with the specific goal of allowing a feedback loop
between build systems and in-the-field application executions to ensure
effective pipeline caches are shipped to customers.
New Structures
VkPipelineCreationFeedbackEXT
Extending
VkGraphicsPipelineCreateInfo
VkComputePipelineCreateInfo
VkRayTracingPipelineCreateInfoNV
VkRayTracingPipelineCreateInfoKHR
VkExecutionGraphPipelineCreateInfoAMDX
VkDataGraphPipelineCreateInfoARM
VkPipelineCreationFeedbackCreateInfoEXT
New Enums
VkPipelineCreationFeedbackFlagBitsEXT
New Bitmasks
VkPipelineCreationFeedbackFlagsEXT
New Enum Constants
VK_EXT_PIPELINE_CREATION_FEEDBACK_EXTENSION_NAME
VK_EXT_PIPELINE_CREATION_FEEDBACK_SPEC_VERSION
Extending
VkPipelineCreationFeedbackFlagBits
VK_PIPELINE_CREATION_FEEDBACK_APPLICATION_PIPELINE_CACHE_HIT_BIT_EXT
VK_PIPELINE_CREATION_FEEDBACK_BASE_PIPELINE_ACCELERATION_BIT_EXT
VK_PIPELINE_CREATION_FEEDBACK_VALID_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PIPELINE_CREATION_FEEDBACK_CREATE_INFO_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2019-03-12 (Jean-Francois Roy)
Initial revision
VK_EXT_pipeline_protected_access
Name String
VK_EXT_pipeline_protected_access
Extension Type
Device extension
Registered Extension Number
467
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_pipeline_protected_access
Other Extension Metadata
Last Modified Date
2022-07-28
Contributors
Shahbaz Youssefi, Google
Jörg Wagner, Arm
Ralph Potter, Samsung
Daniel Koch, NVIDIA
Description
This extension allows protected memory access to be specified per pipeline
as opposed to per device.
Through the usage of this extension, any performance penalty paid due to
access to protected memory will be limited to the specific pipelines that
make such accesses.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineProtectedAccessFeaturesEXT
New Enum Constants
VK_EXT_PIPELINE_PROTECTED_ACCESS_EXTENSION_NAME
VK_EXT_PIPELINE_PROTECTED_ACCESS_SPEC_VERSION
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_NO_PROTECTED_ACCESS_BIT_EXT
VK_PIPELINE_CREATE_PROTECTED_ACCESS_ONLY_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROTECTED_ACCESS_FEATURES_EXT
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the EXT
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2022-07-28 (Shahbaz Youssefi)
Internal revisions
VK_EXT_pipeline_robustness
Name String
VK_EXT_pipeline_robustness
Extension Type
Device extension
Registered Extension Number
69
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.4
Contact
Jarred Davies
Other Extension Metadata
Last Modified Date
2022-07-12
Interactions and External Dependencies
Interacts with
VK_EXT_robustness2
Interacts with
VK_EXT_image_robustness
Interacts with
VK_KHR_ray_tracing_pipeline
Contributors
Jarred Davies, Imagination Technologies
Alex Walters, Imagination Technologies
Piers Daniell, NVIDIA
Graeme Leese, Broadcom Corporation
Jeff Leger, Qualcomm Technologies, Inc.
Faith Ekstrand, Intel
Lionel Landwerlin, Intel
Shahbaz Youssefi, Google, Inc.
Description
This extension allows users to request robustness on a per-pipeline stage
basis.
As
robustBufferAccess
and other
robustness features may have an adverse effect on performance, this
extension is designed to allow users to request robust behavior only where
it may be needed.
New Structures
Extending
VkGraphicsPipelineCreateInfo
VkComputePipelineCreateInfo
VkPipelineShaderStageCreateInfo
VkRayTracingPipelineCreateInfoKHR
VkPipelineRobustnessCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePipelineRobustnessFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDevicePipelineRobustnessPropertiesEXT
New Enums
VkPipelineRobustnessBufferBehaviorEXT
VkPipelineRobustnessImageBehaviorEXT
New Enum Constants
VK_EXT_PIPELINE_ROBUSTNESS_EXTENSION_NAME
VK_EXT_PIPELINE_ROBUSTNESS_SPEC_VERSION
Extending
VkPipelineRobustnessBufferBehavior
VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_DEVICE_DEFAULT_EXT
VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_DISABLED_EXT
VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_ROBUST_BUFFER_ACCESS_2_EXT
VK_PIPELINE_ROBUSTNESS_BUFFER_BEHAVIOR_ROBUST_BUFFER_ACCESS_EXT
Extending
VkPipelineRobustnessImageBehavior
VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DEVICE_DEFAULT_EXT
VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_DISABLED_EXT
VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_ROBUST_IMAGE_ACCESS_2_EXT
VK_PIPELINE_ROBUSTNESS_IMAGE_BEHAVIOR_ROBUST_IMAGE_ACCESS_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_ROBUSTNESS_CREATE_INFO_EXT
Promotion to Vulkan 1.4
Functionality in this extension is included in core Vulkan 1.4 with the EXT
suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
Version History
Revision 1, 2022-07-12 (Jarred Davies)
Initial version
VK_EXT_present_mode_fifo_latest_ready
Name String
VK_EXT_present_mode_fifo_latest_ready
Extension Type
Device extension
Registered Extension Number
362
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
Deprecation State
Promoted
to
VK_KHR_present_mode_fifo_latest_ready
extension
Contact
Lionel Duc
nvlduc
Extension Proposal
VK_EXT_present_mode_fifo_latest_ready
Other Extension Metadata
Last Modified Date
2024-05-28
IP Status
No known IP claims.
Contributors
James Jones, NVIDIA
Lionel Duc, NVIDIA
Description
This device extension adds a new present mode,
VK_PRESENT_MODE_FIFO_LATEST_READY_EXT
This tear-free present mode behaves much like
VK_PRESENT_MODE_FIFO_KHR
, except that each vertical blanking period
dequeues consecutive present requests until the latest ready is found to
update the current image.
While this seems similar in concept to
VK_PRESENT_MODE_MAILBOX_KHR
the fundamental difference is that the processing of the present requests is
done during vblank.
From the application perspective, this means for example, that in a
flip-based model, a single vblank
may
cause multiple swapchain images to be
released at once, while
VK_PRESENT_MODE_MAILBOX_KHR
may
continuously
be releasing images as new requests become ready.
This additional present mode is useful when using a time-based present API.
Promotion to
VK_KHR_present_mode_fifo_latest_ready
All functionality in this extension is included in
VK_KHR_present_mode_fifo_latest_ready
, with the suffix changed to
KHR.
The original type and enum names are still available as aliases of the KHR
names.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePresentModeFifoLatestReadyFeaturesEXT
New Enum Constants
VK_EXT_PRESENT_MODE_FIFO_LATEST_READY_EXTENSION_NAME
VK_EXT_PRESENT_MODE_FIFO_LATEST_READY_SPEC_VERSION
Extending
VkPresentModeKHR
VK_PRESENT_MODE_FIFO_LATEST_READY_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_MODE_FIFO_LATEST_READY_FEATURES_EXT
Version History
Revision 1, 2024-05-28 (Lionel Duc)
Internal revisions
VK_EXT_private_data
Name String
VK_EXT_private_data
Extension Type
Device extension
Registered Extension Number
296
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Matthew Rusch
mattruschnv
Other Extension Metadata
Last Modified Date
2020-03-25
IP Status
No known IP claims.
Contributors
Matthew Rusch, NVIDIA
Nuno Subtil, NVIDIA
Piers Daniell, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension is a device extension which enables attaching arbitrary
payloads to Vulkan objects.
It introduces the idea of private data slots as a means of storing a 64-bit
unsigned integer of application-defined data.
Private data slots can be created or destroyed any time an associated device
is available.
Private data slots can be reserved at device creation time, and limiting use
to the amount reserved will allow the extension to exhibit better
performance characteristics.
New Object Types
VkPrivateDataSlotEXT
New Commands
vkCreatePrivateDataSlotEXT
vkDestroyPrivateDataSlotEXT
vkGetPrivateDataEXT
vkSetPrivateDataEXT
New Structures
VkPrivateDataSlotCreateInfoEXT
Extending
VkDeviceCreateInfo
VkDevicePrivateDataCreateInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePrivateDataFeaturesEXT
New Bitmasks
VkPrivateDataSlotCreateFlagsEXT
New Enum Constants
VK_EXT_PRIVATE_DATA_EXTENSION_NAME
VK_EXT_PRIVATE_DATA_SPEC_VERSION
Extending
VkObjectType
VK_OBJECT_TYPE_PRIVATE_DATA_SLOT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEVICE_PRIVATE_DATA_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIVATE_DATA_FEATURES_EXT
VK_STRUCTURE_TYPE_PRIVATE_DATA_SLOT_CREATE_INFO_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Examples
In progress
Issues
(1) If I have to create a
VkPrivateDataSlot
to store and retrieve data
on an object, how does this extension help me? Will I not need to store the
VkPrivateDataSlot
mapping with each object, and if I am doing that, I
might as well just store the original data!
The
VkPrivateDataSlot
can be thought of as an opaque index into
storage that is reserved in each object.
That is, you can use the same
VkPrivateDataSlot
with each object for a
specific piece of information.
For example, if a layer wishes to track per-object information, the layer
only needs to allocate one
VkPrivateDataSlot
per device and it can use
that private data slot for all of the device’s child objects.
This allows multiple layers to store private data without conflicting with
each other’s and/or the application’s private data.
2) What if I need to store more than 64-bits of information per object?
The data that you store per object could be a pointer to another object or
structure of your own allocation.
Version History
Revision 1, 2020-01-15 (Matthew Rusch)
Initial draft
VK_EXT_robustness2
Name String
VK_EXT_robustness2
Extension Type
Device extension
Registered Extension Number
287
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_robustness2
extension
Contact
Liam Middlebrook
liam-middlebrook
Other Extension Metadata
Last Modified Date
2020-01-29
IP Status
No known IP claims.
Contributors
Liam Middlebrook, NVIDIA
Jeff Bolz, NVIDIA
Description
This extension adds stricter requirements for how out of bounds reads and
writes are handled.
Most accesses
must
be tightly bounds-checked, out of bounds writes
must
be
discarded, out of bound reads
must
return zero.
Rather than allowing multiple possible
(0,0,0,x)
vectors, the out of
bounds values are treated as zero, and then missing components are inserted
based on the format as described in
Component Substitution
and
vertex input attribute extraction
These additional requirements
may
be expensive on some implementations, and
should only be enabled when truly necessary.
This extension also adds support for “null descriptors”, where
VK_NULL_HANDLE
can
be used instead of a valid handle.
Accesses to null descriptors have well-defined behavior, and do not rely on
robustness.
Promotion to
VK_KHR_robustness2
All functionality in this extension is included in
VK_KHR_robustness2
, with the suffix changed to KHR.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRobustness2FeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRobustness2PropertiesEXT
New Enum Constants
VK_EXT_ROBUSTNESS_2_EXTENSION_NAME
VK_EXT_ROBUSTNESS_2_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_EXT
Issues
Why do
VkPhysicalDeviceRobustness2PropertiesEXT
::
robustUniformBufferAccessSizeAlignment
and
VkPhysicalDeviceRobustness2PropertiesEXT
::
robustStorageBufferAccessSizeAlignment
exist?
RESOLVED
: Some implementations cannot efficiently tightly bounds-check all
buffer accesses.
Rather, the size of the bound range is padded to some power of two multiple,
up to 256 bytes for uniform buffers and up to 4 bytes for storage buffers,
and that padded size is bounds-checked.
This is sufficient to implement D3D-like behavior, because D3D only allows
binding whole uniform buffers or ranges that are a multiple of 256 bytes,
and D3D raw and structured buffers only support 32-bit accesses.
Examples
None.
Version History
Revision 1, 2019-11-01 (Jeff Bolz, Liam Middlebrook)
Initial draft
VK_EXT_sampler_filter_minmax
Name String
VK_EXT_sampler_filter_minmax
Extension Type
Device extension
Registered Extension Number
131
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2017-05-19
IP Status
No known IP claims.
Contributors
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Description
In unextended Vulkan, minification and magnification filters such as LINEAR
allow sampled image lookups to return a filtered texel value produced by
computing a weighted average of a collection of texels in the neighborhood
of the texture coordinate provided.
This extension provides a new sampler parameter which allows applications to
produce a filtered texel value by computing a component-wise minimum (MIN)
or maximum (MAX) of the texels that would normally be averaged.
The reduction mode is orthogonal to the minification and magnification
filter parameters.
The filter parameters are used to identify the set of texels used to produce
a final filtered value; the reduction mode identifies how these texels are
combined.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
EXT suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Structures
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT
Extending
VkSamplerCreateInfo
VkSamplerReductionModeCreateInfoEXT
New Enums
VkSamplerReductionModeEXT
New Enum Constants
VK_EXT_SAMPLER_FILTER_MINMAX_EXTENSION_NAME
VK_EXT_SAMPLER_FILTER_MINMAX_SPEC_VERSION
Extending
VkFormatFeatureFlagBits
VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT
Extending
VkSamplerReductionMode
VK_SAMPLER_REDUCTION_MODE_MAX_EXT
VK_SAMPLER_REDUCTION_MODE_MIN_EXT
VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT
VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT
Version History
Revision 2, 2017-05-19 (Piers Daniell)
Renamed to EXT
Revision 1, 2017-03-25 (Jeff Bolz)
Internal revisions
VK_EXT_scalar_block_layout
Name String
VK_EXT_scalar_block_layout
Extension Type
Device extension
Registered Extension Number
222
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Tobias Hector
tobski
Other Extension Metadata
Last Modified Date
2018-11-14
Contributors
Jeff Bolz
Jan-Harald Fredriksen
Graeme Leese
Faith Ekstrand
John Kessenich
Description
This extension enables C-like structure layout for SPIR-V blocks.
It modifies the alignment rules for uniform buffers, storage buffers and
push constants, allowing non-scalar types to be aligned solely based on the
size of their components, without additional requirements.
Promotion to Vulkan 1.2
Vulkan APIs in this extension are included in core Vulkan 1.2, with the EXT
suffix omitted.
However, if Vulkan 1.2 is supported and this extension is not, the
scalarBlockLayout
capability is optional.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Promotion to Vulkan 1.4
If Vulkan 1.4 is supported, support for the
scalarBlockLayout
capability is required.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceScalarBlockLayoutFeaturesEXT
New Enum Constants
VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME
VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT
Version History
Revision 1, 2018-11-14 (Tobias Hector)
Initial draft
VK_EXT_separate_stencil_usage
Name String
VK_EXT_separate_stencil_usage
Extension Type
Device extension
Registered Extension Number
247
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2018-11-08
IP Status
No known IP claims.
Contributors
Daniel Rakos, AMD
Jordan Logan, AMD
Description
This extension allows specifying separate usage flags for the stencil aspect
of images with a depth-stencil format at image creation time.
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2, with the
EXT suffix omitted.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Structures
Extending
VkImageCreateInfo
VkPhysicalDeviceImageFormatInfo2
VkImageStencilUsageCreateInfoEXT
New Enum Constants
VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME
VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT
Version History
Revision 1, 2018-11-08 (Daniel Rakos)
Internal revisions.
VK_EXT_shader_demote_to_helper_invocation
Name String
VK_EXT_shader_demote_to_helper_invocation
Extension Type
Device extension
Registered Extension Number
277
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_EXT_demote_to_helper_invocation
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2019-06-01
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_EXT_demote_to_helper_invocation
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds Vulkan support for the
SPV_EXT_demote_to_helper_invocation
SPIR-V extension.
That SPIR-V extension provides a new instruction
OpDemoteToHelperInvocationEXT
allowing shaders to “demote” a fragment
shader invocation to behave like a helper invocation for its duration.
The demoted invocation will have no further side effects and will not output
to the framebuffer, but remains active and can participate in computing
derivatives and in
group operations
This is a better match for the “discard” instruction in HLSL.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceShaderDemoteToHelperInvocationFeaturesEXT
New Enum Constants
VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_EXTENSION_NAME
VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DEMOTE_TO_HELPER_INVOCATION_FEATURES_EXT
New SPIR-V Capability
DemoteToHelperInvocationEXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2019-06-01 (Jeff Bolz)
Initial draft
VK_EXT_shader_subgroup_ballot
Name String
VK_EXT_shader_subgroup_ballot
Extension Type
Device extension
Registered Extension Number
65
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_shader_ballot
Deprecation State
Deprecated
by
Vulkan 1.2
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2016-11-28
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_ARB_shader_ballot
Contributors
Jeff Bolz, NVIDIA
Neil Henning, Codeplay
Daniel Koch, NVIDIA Corporation
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_KHR_shader_ballot
This extension provides the ability for a group of invocations, which
execute in parallel, to do limited forms of cross-invocation communication
via a group broadcast of an invocation value, or broadcast of a bit array
representing a predicate value from each invocation in the group.
This extension provides access to a number of additional built-in shader
variables in Vulkan:
SubgroupEqMaskKHR
, containing the subgroup mask of the current
subgroup invocation,
SubgroupGeMaskKHR
, containing the subgroup mask of the invocations
greater than or equal to the current invocation,
SubgroupGtMaskKHR
, containing the subgroup mask of the invocations
greater than the current invocation,
SubgroupLeMaskKHR
, containing the subgroup mask of the invocations
less than or equal to the current invocation,
SubgroupLtMaskKHR
, containing the subgroup mask of the invocations
less than the current invocation,
SubgroupLocalInvocationId
, containing the index of an invocation
within a subgroup, and
SubgroupSize
, containing the maximum number of invocations in a
subgroup.
Additionally, this extension provides access to the new SPIR-V instructions:
OpSubgroupBallotKHR
OpSubgroupFirstInvocationKHR
, and
OpSubgroupReadInvocationKHR
When using GLSL source-based shader languages, the following variables and
shader functions from GL_ARB_shader_ballot can map to these SPIR-V built-in
decorations and instructions:
in uint64_t gl_SubGroupEqMaskARB;
SubgroupEqMaskKHR
in uint64_t gl_SubGroupGeMaskARB;
SubgroupGeMaskKHR
in uint64_t gl_SubGroupGtMaskARB;
SubgroupGtMaskKHR
in uint64_t gl_SubGroupLeMaskARB;
SubgroupLeMaskKHR
in uint64_t gl_SubGroupLtMaskARB;
SubgroupLtMaskKHR
in uint gl_SubGroupInvocationARB;
SubgroupLocalInvocationId
uniform uint gl_SubGroupSizeARB;
SubgroupSize
ballotARB
() →
OpSubgroupBallotKHR
readFirstInvocationARB
() →
OpSubgroupFirstInvocationKHR
, and
readInvocationARB
() →
OpSubgroupReadInvocationKHR
Deprecated by Vulkan 1.2
Most of the functionality in this extension is superseded by the core Vulkan
1.1
subgroup operations
However, Vulkan 1.1 required the
OpGroupNonUniformBroadcast
“Id” to
be constant.
This restriction was removed in Vulkan 1.2 with the addition of the
subgroupBroadcastDynamicId
feature.
New Enum Constants
VK_EXT_SHADER_SUBGROUP_BALLOT_EXTENSION_NAME
VK_EXT_SHADER_SUBGROUP_BALLOT_SPEC_VERSION
New Built-In Variables
SubgroupEqMaskKHR
SubgroupGeMaskKHR
SubgroupGtMaskKHR
SubgroupLeMaskKHR
SubgroupLtMaskKHR
SubgroupLocalInvocationId
SubgroupSize
New SPIR-V Capabilities
SubgroupBallotKHR
Version History
Revision 1, 2016-11-28 (Daniel Koch)
Initial draft
VK_EXT_shader_subgroup_vote
Name String
VK_EXT_shader_subgroup_vote
Extension Type
Device extension
Registered Extension Number
66
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_KHR_subgroup_vote
Deprecation State
Deprecated
by
Vulkan 1.1
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2016-11-28
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_ARB_shader_group_vote
Contributors
Neil Henning, Codeplay
Daniel Koch, NVIDIA Corporation
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_KHR_subgroup_vote
This extension provides new SPIR-V instructions:
OpSubgroupAllKHR
OpSubgroupAnyKHR
, and
OpSubgroupAllEqualKHR
to compute the composite of a set of boolean conditions across a group of
shader invocations that are running concurrently (a
subgroup
).
These composite results may be used to execute shaders more efficiently on a
VkPhysicalDevice
When using GLSL source-based shader languages, the following shader
functions from GL_ARB_shader_group_vote can map to these SPIR-V
instructions:
anyInvocationARB
() →
OpSubgroupAnyKHR
allInvocationsARB
() →
OpSubgroupAllKHR
, and
allInvocationsEqualARB
() →
OpSubgroupAllEqualKHR
The subgroup across which the boolean conditions are evaluated is
implementation-dependent, and this extension provides no guarantee over how
individual shader invocations are assigned to subgroups.
In particular, a subgroup has no necessary relationship with the compute
shader
local workgroup
— any pair of shader invocations in a compute
local workgroup may execute in different subgroups as used by these
instructions.
Compute shaders operate on an explicitly specified group of threads (a local
workgroup), but many implementations will also group non-compute shader
invocations and execute them concurrently.
When executing code like
if (condition) {
result = do_fast_path();
} else {
result = do_general_path();
where
condition
diverges between invocations, an implementation might
first execute
do_fast_path
() for the invocations where
condition
is true and leave the other invocations dormant.
Once
do_fast_path
() returns, it might call
do_general_path
() for
invocations where
condition
is
false
and leave the other
invocations dormant.
In this case, the shader executes
both
the fast and the general path and
might be better off just using the general path for all invocations.
This extension provides the ability to avoid divergent execution by
evaluating a condition across an entire subgroup using code like:
if (allInvocationsARB(condition)) {
result = do_fast_path();
} else {
result = do_general_path();
The built-in function
allInvocationsARB
() will return the same value
for all invocations in the group, so the group will either execute
do_fast_path
() or
do_general_path
(), but never both.
For example, shader code might want to evaluate a complex function
iteratively by starting with an approximation of the result and then
refining the approximation.
Some input values may require a small number of iterations to generate an
accurate result (
do_fast_path
) while others require a larger number
do_general_path
).
In another example, shader code might want to evaluate a complex function
do_general_path
) that can be greatly simplified when assuming a
specific value for one of its inputs (
do_fast_path
).
Deprecated by Vulkan 1.1
All functionality in this extension is superseded by the core Vulkan 1.1
subgroup operations
New Enum Constants
VK_EXT_SHADER_SUBGROUP_VOTE_EXTENSION_NAME
VK_EXT_SHADER_SUBGROUP_VOTE_SPEC_VERSION
New SPIR-V Capabilities
SubgroupVoteKHR
Version History
Revision 1, 2016-11-28 (Daniel Koch)
Initial draft
VK_EXT_shader_viewport_index_layer
Name String
VK_EXT_shader_viewport_index_layer
Extension Type
Device extension
Registered Extension Number
163
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_EXT_shader_viewport_index_layer
Deprecation State
Promoted
to
Vulkan 1.2
Contact
Daniel Koch
dgkoch
Other Extension Metadata
Last Modified Date
2017-08-08
Interactions and External Dependencies
This extension provides API support for
GL_ARB_shader_viewport_layer_array
GL_AMD_vertex_shader_layer
GL_AMD_vertex_shader_viewport_index
and
GL_NV_viewport_array2
This extension requires the
multiViewport
feature.
This extension interacts with the
tessellationShader
feature.
Contributors
Piers Daniell, NVIDIA
Jeff Bolz, NVIDIA
Jan-Harald Fredriksen, ARM
Daniel Rakos, AMD
Slawomir Grajeswki, Intel
Description
This extension adds support for the
ShaderViewportIndexLayerEXT
capability from the
SPV_EXT_shader_viewport_index_layer
extension in
Vulkan.
This extension allows variables decorated with the
Layer
and
ViewportIndex
built-ins to be exported from vertex or tessellation
shaders, using the
ShaderViewportIndexLayerEXT
capability.
When using GLSL source-based shading languages, the
gl_ViewportIndex
and
gl_Layer
built-in variables map to the SPIR-V
ViewportIndex
and
Layer
built-in decorations, respectively.
Behavior of these variables is extended as described in the
GL_ARB_shader_viewport_layer_array
(or the precursor
GL_AMD_vertex_shader_layer
GL_AMD_vertex_shader_viewport_index
, and
GL_NV_viewport_array2
extensions).
The
ShaderViewportIndexLayerEXT
capability is equivalent to the
ShaderViewportIndexLayerNV
capability added by
VK_NV_viewport_array2
Promotion to Vulkan 1.2
All functionality in this extension is included in core Vulkan 1.2.
The single
ShaderViewportIndexLayerEXT
capability from the
SPV_EXT_shader_viewport_index_layer
extension is replaced by the
ShaderViewportIndex
and
ShaderLayer
capabilities from SPIR-V 1.5 which are enabled by the
shaderOutputViewportIndex
and
shaderOutputLayer
features,
respectively.
Additionally, if Vulkan 1.2 is supported but this extension is not, these
capabilities are optional.
Enabling both features is equivalent to enabling the
VK_EXT_shader_viewport_index_layer
extension.
New Enum Constants
VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME
VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_SPEC_VERSION
New or Modified Built-In Variables
(modified)
Layer
(modified)
ViewportIndex
New SPIR-V Capabilities
ShaderViewportIndexLayerEXT
Version History
Revision 1, 2017-08-08 (Daniel Koch)
Internal drafts
VK_EXT_subgroup_size_control
Name String
VK_EXT_subgroup_size_control
Extension Type
Device extension
Registered Extension Number
226
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Neil Henning
sheredom
Other Extension Metadata
Last Modified Date
2019-03-05
Contributors
Jeff Bolz, NVIDIA
Faith Ekstrand, Intel
Sławek Grajewski, Intel
Jesse Hall, Google
Neil Henning, AMD
Daniel Koch, NVIDIA
Jeff Leger, Qualcomm
Graeme Leese, Broadcom
Allan MacKinnon, Google
Mariusz Merecki, Intel
Graham Wihlidal, Electronic Arts
Description
This extension enables an implementation to control the subgroup size by
allowing a varying subgroup size and also specifying a required subgroup
size.
It extends the subgroup support in Vulkan 1.1 to allow an implementation to
expose a varying subgroup size.
Previously Vulkan exposed a single subgroup size per physical device, with
the expectation that implementations will behave as if all subgroups have
the same size.
Some implementations
may
dispatch shaders with a varying subgroup size for
different subgroups.
As a result they could implicitly split a large subgroup into smaller
subgroups or represent a small subgroup as a larger subgroup, some of whose
invocations were inactive on launch.
To aid developers in understanding the performance characteristics of their
programs, this extension exposes a minimum and maximum subgroup size that a
physical device supports and a pipeline create flag to enable that pipeline
to vary its subgroup size.
If enabled, any
SubgroupSize
decorated variables in the SPIR-V shader
modules provided to pipeline creation
may
vary between the
minimum
and
maximum
subgroup sizes.
An implementation is also optionally allowed to support specifying a
required subgroup size for a given pipeline stage.
Implementations advertise which
stages support a required subgroup size
, and any pipeline of a supported stage
can be passed a
VkPipelineShaderStageRequiredSubgroupSizeCreateInfoEXT
structure to set the subgroup size for that shader stage of the pipeline.
For compute shaders, this requires the developer to query the
maxComputeWorkgroupSubgroups
and ensure that:
Developers can also specify a new pipeline shader stage create flag that
requires the implementation to have fully populated subgroups within local
workgroups.
This requires the workgroup size in the X dimension to be a multiple of the
subgroup size.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSubgroupSizeControlFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceSubgroupSizeControlPropertiesEXT
Extending
VkPipelineShaderStageCreateInfo
VkShaderCreateInfoEXT
VkPipelineShaderStageRequiredSubgroupSizeCreateInfoEXT
New Enum Constants
VK_EXT_SUBGROUP_SIZE_CONTROL_EXTENSION_NAME
VK_EXT_SUBGROUP_SIZE_CONTROL_SPEC_VERSION
Extending
VkPipelineShaderStageCreateFlagBits
VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT
VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Version History
Revision 1, 2019-03-05 (Neil Henning)
Initial draft
Revision 2, 2019-07-26 (Faith Ekstrand)
Add the missing
VkPhysicalDeviceSubgroupSizeControlFeaturesEXT
for querying subgroup size control features.
VK_EXT_surface_maintenance1
Name String
VK_EXT_surface_maintenance1
Extension Type
Instance extension
Registered Extension Number
275
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_surface
and
VK_KHR_get_surface_capabilities2
Deprecation State
Promoted
to
VK_KHR_surface_maintenance1
extension
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_surface_maintenance1
Other Extension Metadata
Last Modified Date
2022-12-16
Interactions and External Dependencies
Promoted to
VK_KHR_surface_maintenance1
Contributors
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Lionel Landwerlin, Intel
Shahbaz Youssefi, Google
Chris Forbes, Google
Ian Elliott, Google
Hans-Kristian Arntzen, Valve
Daniel Stone, Collabora
Description
VK_EXT_surface_maintenance1
adds a collection of window system
integration features that were intentionally left out or overlooked in the
original
VK_KHR_surface
extension.
The new features are as follows:
Allow querying number of min/max images from a surface for a particular
presentation mode.
Allow querying a surface’s scaled presentation capabilities.
Allow querying a surface for the set of presentation modes which can be
easily switched between without requiring swapchain recreation.
Promotion to
VK_KHR_surface_maintenance1
All functionality in this extension is included in
VK_KHR_surface_maintenance1
, with the suffix changed to KHR.
The original type, enum, and command names are still available as aliases of
the KHR functionality.
New Structures
Extending
VkPhysicalDeviceSurfaceInfo2KHR
VkSurfacePresentModeEXT
Extending
VkSurfaceCapabilities2KHR
VkSurfacePresentModeCompatibilityEXT
VkSurfacePresentScalingCapabilitiesEXT
New Enums
VkPresentGravityFlagBitsEXT
VkPresentScalingFlagBitsEXT
New Bitmasks
VkPresentGravityFlagsEXT
VkPresentScalingFlagsEXT
New Enum Constants
VK_EXT_SURFACE_MAINTENANCE_1_EXTENSION_NAME
VK_EXT_SURFACE_MAINTENANCE_1_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_COMPATIBILITY_EXT
VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_EXT
VK_STRUCTURE_TYPE_SURFACE_PRESENT_SCALING_CAPABILITIES_EXT
Version History
Revision 0, 2019-02-27 (Lionel Landwerlin)
Internal revisions
Revision 0, 2020-06-15 (James Jones)
Internal revisions
Revision 1, 2022-11-09 (Shahbaz Youssefi)
Add functionality and complete spec
VK_EXT_swapchain_maintenance1
Name String
VK_EXT_swapchain_maintenance1
Extension Type
Device extension
Registered Extension Number
276
Revision
Ratification Status
Ratified
Extension and Version Dependencies
VK_KHR_swapchain
and
VK_EXT_surface_maintenance1
and
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_swapchain_maintenance1
extension
Contact
Shahbaz Youssefi
syoussefi
Extension Proposal
VK_EXT_swapchain_maintenance1
Other Extension Metadata
Last Modified Date
2022-12-16
Interactions and External Dependencies
Promoted to
VK_KHR_swapchain_maintenance1
Contributors
James Jones, NVIDIA
Jeff Juliano, NVIDIA
Shahbaz Youssefi, Google
Chris Forbes, Google
Ian Elliott, Google
Yiwei Zhang, Google
Charlie Lao, Google
Lina Versace, Google
Ralph Potter, Samsung
Igor Nazarov, Samsung
Hyunchang Kim, Samsung
Suenghwan Lee, Samsung
Munseong Kang, Samsung
Joonyong Park, Samsung
Hans-Kristian Arntzen, Valve
Lisa Wu, Arm
Daniel Stone, Collabora
Pan Gao, Huawei
Description
VK_EXT_swapchain_maintenance1
adds a collection of window system
integration features that were intentionally left out or overlooked in the
original
VK_KHR_swapchain
extension.
The new features are as follows:
Specify a fence that will be signaled when the resources associated with
a present operation
can
be safely destroyed.
Allow changing the present mode a swapchain is using at per-present
granularity.
Allow applications to define the behavior when presenting a swapchain
image to a surface with different dimensions than the image.
Using this feature
may
allow implementations to avoid returning
VK_ERROR_OUT_OF_DATE_KHR
in this situation.
Allow applications to defer swapchain memory allocation for improved
startup time and memory footprint.
Allow applications to release previously acquired images without
presenting them.
Promotion to
VK_KHR_swapchain_maintenance1
All functionality in this extension is included in
VK_KHR_swapchain_maintenance1
, with the suffix changed to KHR.
The original type, enum, and command names are still available as aliases of
the KHR functionality.
New Commands
vkReleaseSwapchainImagesEXT
New Structures
VkReleaseSwapchainImagesInfoEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceSwapchainMaintenance1FeaturesEXT
Extending
VkPresentInfoKHR
VkSwapchainPresentFenceInfoEXT
VkSwapchainPresentModeInfoEXT
Extending
VkSwapchainCreateInfoKHR
VkSwapchainPresentModesCreateInfoEXT
VkSwapchainPresentScalingCreateInfoEXT
New Enum Constants
VK_EXT_SWAPCHAIN_MAINTENANCE_1_EXTENSION_NAME
VK_EXT_SWAPCHAIN_MAINTENANCE_1_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SWAPCHAIN_MAINTENANCE_1_FEATURES_EXT
VK_STRUCTURE_TYPE_RELEASE_SWAPCHAIN_IMAGES_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODES_CREATE_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODE_INFO_EXT
VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_SCALING_CREATE_INFO_EXT
Extending
VkSwapchainCreateFlagBitsKHR
VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_EXT
Version History
Revision 0, 2019-05-28 (James Jones)
Initial revisions
Revision 1, 2022-08-21 (Shahbaz Youssefi)
Add functionality and complete spec
VK_EXT_texel_buffer_alignment
Name String
VK_EXT_texel_buffer_alignment
Extension Type
Device extension
Registered Extension Number
282
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2019-06-06
IP Status
No known IP claims.
Contributors
Jeff Bolz, NVIDIA
Description
This extension adds more expressive alignment requirements for uniform and
storage texel buffers.
Some implementations have single texel alignment requirements that cannot be
expressed via
VkPhysicalDeviceLimits
::
minTexelBufferOffsetAlignment
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTexelBufferAlignmentFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceTexelBufferAlignmentPropertiesEXT
New Enum Constants
VK_EXT_TEXEL_BUFFER_ALIGNMENT_EXTENSION_NAME
VK_EXT_TEXEL_BUFFER_ALIGNMENT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_PROPERTIES_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
However, only the properties structure is promoted.
The feature structure is not promoted and
texelBufferAlignment
is
enabled if using a Vulkan 1.3 instance.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API name is still available as an alias of the core
functionality.
Version History
Revision 1, 2019-06-06 (Jeff Bolz)
Initial draft
VK_EXT_texture_compression_astc_hdr
Name String
VK_EXT_texture_compression_astc_hdr
Extension Type
Device extension
Registered Extension Number
67
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2019-05-28
IP Status
No known issues.
Contributors
Jan-Harald Fredriksen, Arm
Description
This extension adds support for textures compressed using the Adaptive
Scalable Texture Compression (ASTC) High Dynamic Range (HDR) profile.
When this extension is enabled, the HDR profile is supported for all ASTC
formats listed in
ASTC Compressed Image Formats
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceTextureCompressionASTCHDRFeaturesEXT
New Enum Constants
VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_EXTENSION_NAME
VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_ASTC_10x10_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_10x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_10x6_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_10x8_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_12x10_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_12x12_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_4x4_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_5x4_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_5x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_6x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_6x6_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_8x5_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_8x6_SFLOAT_BLOCK_EXT
VK_FORMAT_ASTC_8x8_SFLOAT_BLOCK_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_HDR_FEATURES_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
However, the feature is made optional in Vulkan 1.3.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Issues
1) Should we add a feature or limit for this functionality?
Yes.
It is consistent with the ASTC LDR support to add a feature like
textureCompressionASTC_HDR.
The feature is strictly speaking redundant as long as this is just an
extension; it would be sufficient to just enable the extension.
But adding the feature is more forward-looking if wanted to make this an
optional core feature in the future.
2) Should we introduce new format enums for HDR?
Yes.
Vulkan 1.0 describes the ASTC format enums as UNORM, e.g.
VK_FORMAT_ASTC_4x4_UNORM_BLOCK
, so it is confusing to make these
contain HDR data.
Note that the OpenGL (ES) extensions did not make this distinction because a
single ASTC HDR texture may contain both unorm and float blocks.
Implementations
may
not be able to distinguish between LDR and HDR ASTC
textures internally and just treat them as the same format, i.e. if this
extension is supported then sampling from a
VK_FORMAT_ASTC_4x4_UNORM_BLOCK
image format
may
return HDR results.
Applications
can
get predictable results by using the appropriate image
format.
Version History
Revision 1, 2019-05-28 (Jan-Harald Fredriksen)
Initial version
VK_EXT_tooling_info
Name String
VK_EXT_tooling_info
Extension Type
Device extension
Registered Extension Number
246
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
API Interactions
Interacts with VK_EXT_debug_marker
Interacts with VK_EXT_debug_report
Interacts with VK_EXT_debug_utils
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Tobias Hector
tobski
Other Extension Metadata
Last Modified Date
2018-11-05
Contributors
Rolando Caloca
Matthaeus Chajdas
Baldur Karlsson
Daniel Rakos
Description
When an error occurs during application development, a common question is
"What tools are actually running right now?" This extension adds the ability
to query that information directly from the Vulkan implementation.
Outdated versions of one tool might not play nicely with another, or perhaps
a tool is not actually running when it should have been.
Trying to figure that out can cause headaches as it is necessary to consult
each known tool to figure out what is going on — in some cases the tool
might not even be known.
Typically, the expectation is that developers will simply print out this
information for visual inspection when an issue occurs, however a small
amount of semantic information about what the tool is doing is provided to
help identify it programmatically.
For example, if the advertised limits or features of an implementation are
unexpected, is there a tool active which modifies these limits? Or if an
application is providing debug markers, but the implementation is not
actually doing anything with that information, this can quickly point that
out.
New Commands
vkGetPhysicalDeviceToolPropertiesEXT
New Structures
VkPhysicalDeviceToolPropertiesEXT
New Enums
VkToolPurposeFlagBitsEXT
New Bitmasks
VkToolPurposeFlagsEXT
New Enum Constants
VK_EXT_TOOLING_INFO_EXTENSION_NAME
VK_EXT_TOOLING_INFO_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TOOL_PROPERTIES_EXT
Extending
VkToolPurposeFlagBits
VK_TOOL_PURPOSE_ADDITIONAL_FEATURES_BIT_EXT
VK_TOOL_PURPOSE_MODIFYING_FEATURES_BIT_EXT
VK_TOOL_PURPOSE_PROFILING_BIT_EXT
VK_TOOL_PURPOSE_TRACING_BIT_EXT
VK_TOOL_PURPOSE_VALIDATION_BIT_EXT
If
VK_EXT_debug_marker
is supported:
Extending
VkToolPurposeFlagBits
VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT
If
VK_EXT_debug_report
is supported:
Extending
VkToolPurposeFlagBits
VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT
If
VK_EXT_debug_utils
is supported:
Extending
VkToolPurposeFlagBits
VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT
VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT
Promotion to Vulkan 1.3
Vulkan APIs in this extension are included in core Vulkan 1.3, with the EXT
suffix omitted.
External interactions defined by this extension, such as SPIR-V token names,
retain their original names.
The original Vulkan API names are still available as aliases of the core
functionality.
Examples
Printing Tool Information
uint32_t num_tools;
VkPhysicalDeviceToolPropertiesEXT *pToolProperties;
vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, NULL);

pToolProperties = (VkPhysicalDeviceToolPropertiesEXT*)malloc(sizeof(VkPhysicalDeviceToolPropertiesEXT) * num_tools);

vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, pToolProperties);

for (int i = 0; i < num_tools; ++i) {
printf("%s:\n", pToolProperties[i].name);
printf("Version:\n");
printf("%s:\n", pToolProperties[i].version);
printf("Description:\n");
printf("\t%s\n", pToolProperties[i].description);
printf("Purposes:\n");
printf("\t%s\n", VkToolPurposeFlagBitsEXT_to_string(pToolProperties[i].purposes));
if (strnlen_s(pToolProperties[i].layer,VK_MAX_EXTENSION_NAME_SIZE) > 0) {
printf("Corresponding Layer:\n");
printf("\t%s\n", pToolProperties[i].layer);
Issues
1) Why is this information separate from the layer mechanism?
Some tooling may be built into a driver, or be part of the Vulkan loader
etc.
Tying this information directly to layers would have been awkward at best.
Version History
Revision 1, 2018-11-05 (Tobias Hector)
Initial draft
VK_EXT_validation_features
Name String
VK_EXT_validation_features
Extension Type
Instance extension
Registered Extension Number
248
Revision
Ratification Status
Ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
by
VK_EXT_layer_settings
extension
Special Use
Debugging tools
Contact
Karl Schultz
karl-lunarg
Other Extension Metadata
Last Modified Date
2018-11-14
IP Status
No known IP claims.
Contributors
Karl Schultz, LunarG
Dave Houlton, LunarG
Mark Lobodzinski, LunarG
Camden Stocker, LunarG
Tony Barbour, LunarG
John Zulauf, LunarG
Description
This extension provides the
VkValidationFeaturesEXT
structure 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
VkValidationFeatureEnableEXT
enum
values that enable specific validation features that are disabled by
default.
The structure also contains an array of
VkValidationFeatureDisableEXT
enum values that disable specific validation layer features that are enabled
by default.
Deprecation by
VK_EXT_layer_settings
Functionality in this extension is subsumed into the
VK_EXT_layer_settings
extension.
New Structures
Extending
VkInstanceCreateInfo
VkShaderModuleCreateInfo
VkShaderCreateInfoEXT
VkValidationFeaturesEXT
New Enums
VkValidationFeatureDisableEXT
VkValidationFeatureEnableEXT
New Enum Constants
VK_EXT_VALIDATION_FEATURES_EXTENSION_NAME
VK_EXT_VALIDATION_FEATURES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT
Version History
Revision 1, 2018-11-14 (Karl Schultz)
Initial revision
Revision 2, 2019-08-06 (Mark Lobodzinski)
Add Best Practices enable
Revision 3, 2020-03-04 (Tony Barbour)
Add Debug Printf enable
Revision 4, 2020-07-29 (John Zulauf)
Add Synchronization Validation enable
Revision 5, 2021-05-18 (Tony Barbour)
Add Shader Validation Cache disable
Revision 6, 2023-09-25 (Christophe Riccio)
Marked as deprecated by VK_EXT_layer_settings
VK_EXT_validation_flags
Name String
VK_EXT_validation_flags
Extension Type
Instance extension
Registered Extension Number
62
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
by
VK_EXT_layer_settings
extension
Special Use
Debugging tools
Contact
Tobin Ehlis
tobine
Other Extension Metadata
Last Modified Date
2019-08-19
IP Status
No known IP claims.
Contributors
Tobin Ehlis, Google
Courtney Goeltzenleuchter, Google
Description
This extension provides the
VkValidationFlagsEXT
structure 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
VkValidationCheckEXT
values that
will be disabled by the validation layers.
Deprecation by
VK_EXT_layer_settings
Functionality in this extension is subsumed into the
VK_EXT_layer_settings
extension.
New Structures
Extending
VkInstanceCreateInfo
VkValidationFlagsEXT
New Enums
VkValidationCheckEXT
New Enum Constants
VK_EXT_VALIDATION_FLAGS_EXTENSION_NAME
VK_EXT_VALIDATION_FLAGS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT
Version History
Revision 3, 2023-09-25 (Christophe Riccio)
Marked as deprecated by VK_EXT_layer_settings
Revision 2, 2019-08-19 (Mark Lobodzinski)
Marked as deprecated by VK_EXT_validation_features
Revision 1, 2016-08-26 (Courtney Goeltzenleuchter)
Initial draft
VK_EXT_vertex_attribute_divisor
Name String
VK_EXT_vertex_attribute_divisor
Extension Type
Device extension
Registered Extension Number
191
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_vertex_attribute_divisor
extension
Which in turn was
promoted
to
Vulkan 1.4
Contact
Vikram Kushwaha
vkushwaha
Other Extension Metadata
Last Modified Date
2018-08-03
IP Status
No known IP claims.
Contributors
Vikram Kushwaha, NVIDIA
Faith Ekstrand, Intel
Description
This extension allows instance-rate vertex attributes to be repeated for
certain number of instances instead of advancing for every instance when
instanced rendering is enabled.
New Structures
VkVertexInputBindingDivisorDescriptionEXT
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT
Extending
VkPipelineVertexInputStateCreateInfo
VkPipelineVertexInputDivisorStateCreateInfoEXT
New Enum Constants
VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME
VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT
Issues
1) What is the effect of a non-zero value for
firstInstance
RESOLVED
: The Vulkan API should follow the OpenGL convention and offset
attribute fetching by
firstInstance
while computing vertex attribute
offsets.
2) Should zero be an allowed divisor?
RESOLVED
: Yes.
A zero divisor means the vertex attribute is repeated for all instances.
Examples
To create a vertex binding such that the first binding uses instanced
rendering and the same attribute is used for every 4 draw instances, an
application could use the following set of structures:
const VkVertexInputBindingDivisorDescriptionEXT divisorDesc =
.binding = 0,
.divisor = 4
};

const VkPipelineVertexInputDivisorStateCreateInfoEXT divisorInfo =
.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT,
.pNext = NULL,
.vertexBindingDivisorCount = 1,
.pVertexBindingDivisors = &divisorDesc

const VkVertexInputBindingDescription binding =
.binding = 0,
.stride = sizeof(Vertex),
.inputRate = VK_VERTEX_INPUT_RATE_INSTANCE
};

const VkPipelineVertexInputStateCreateInfo viInfo =
.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_CREATE_INFO,
.pNext = &divisorInfo,
...
};
//...
Version History
Revision 1, 2017-12-04 (Vikram Kushwaha)
First Version
Revision 2, 2018-07-16 (Faith Ekstrand)
Adjust the interaction between
divisor
and
firstInstance
to
match the OpenGL convention.
Disallow divisors of zero.
Revision 3, 2018-08-03 (Vikram Kushwaha)
Allow a zero divisor.
Add a physical device features structure to query/enable this feature.
VK_EXT_vertex_attribute_robustness
Name String
VK_EXT_vertex_attribute_robustness
Extension Type
Device extension
Registered Extension Number
609
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_KHR_maintenance9
extension
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2024-11-01
IP Status
No known IP claims.
Contributors
Daniel Story, Nintendo
Description
It can be detrimental to performance for applications to have to define fake
vertex attribute locations and buffer bindings for vertex shaders that may
reference attribute locations for which there is no vertex data.
This extension allows applications to not have to specify fake vertex
attribute locations, and if the vertex shader reads those attributes it will
read (0,0,0,0) or (0,0,0,1).
Promotion to
VK_KHR_maintenance9
The same functionality is provided by
VK_KHR_maintenance9
, but
enabled by the
maintenance9
feature instead.
The
VkPhysicalDeviceVertexAttributeRobustnessFeaturesEXT
structure was
not included in the maintenance extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceVertexAttributeRobustnessFeaturesEXT
New Enum Constants
VK_EXT_VERTEX_ATTRIBUTE_ROBUSTNESS_EXTENSION_NAME
VK_EXT_VERTEX_ATTRIBUTE_ROBUSTNESS_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_ROBUSTNESS_FEATURES_EXT
Issues
None
Version History
Revision 1, 2024-11-01 (Piers Daniell)
Internal revisions
VK_EXT_ycbcr_2plane_444_formats
Name String
VK_EXT_ycbcr_2plane_444_formats
Extension Type
Device extension
Registered Extension Number
331
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_sampler_ycbcr_conversion
or
Vulkan Version 1.1
Deprecation State
Promoted
to
Vulkan 1.3
Contact
Tony Zlatinski
tzlatinski
Other Extension Metadata
Last Modified Date
2020-07-28
IP Status
No known IP claims.
Contributors
Piers Daniell, NVIDIA
Ping Liu, Intel
Description
This extension adds some Y′C
formats that are in common use for video
encode and decode, but were not part of the
VK_KHR_sampler_ycbcr_conversion
extension.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceYcbcr2Plane444FormatsFeaturesEXT
New Enum Constants
VK_EXT_YCBCR_2PLANE_444_FORMATS_EXTENSION_NAME
VK_EXT_YCBCR_2PLANE_444_FORMATS_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16_EXT
VK_FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16_EXT
VK_FORMAT_G16_B16R16_2PLANE_444_UNORM_EXT
VK_FORMAT_G8_B8R8_2PLANE_444_UNORM_EXT
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_2_PLANE_444_FORMATS_FEATURES_EXT
Promotion to Vulkan 1.3
The format enumerants introduced by the extension are included in core
Vulkan 1.3, with the EXT suffix omitted.
However, runtime support for these formats is optional in core Vulkan 1.3,
while if this extension is supported, runtime support is mandatory.
The feature structure is not promoted.
The original enum names are still available as aliases of the core
functionality.
Version History
Revision 1, 2020-03-08 (Piers Daniell)
Initial draft
VK_AMD_draw_indirect_count
Name String
VK_AMD_draw_indirect_count
Extension Type
Device extension
Registered Extension Number
34
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
VK_KHR_draw_indirect_count
extension
Which in turn was
promoted
to
Vulkan 1.2
Contact
Daniel Rakos
drakos-amd
Other Extension Metadata
Last Modified Date
2016-08-23
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Derrick Owens, AMD
Graham Sellers, AMD
Daniel Rakos, AMD
Dominik Witczak, AMD
Description
This extension allows an application to source the number of draws for
indirect drawing commands from a buffer.
This enables applications to generate an arbitrary number of drawing
commands and execute them without host intervention.
Promotion to
VK_KHR_draw_indirect_count
All functionality in this extension is included in
VK_KHR_draw_indirect_count
, with the suffix changed to KHR.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Commands
vkCmdDrawIndexedIndirectCountAMD
vkCmdDrawIndirectCountAMD
New Enum Constants
VK_AMD_DRAW_INDIRECT_COUNT_EXTENSION_NAME
VK_AMD_DRAW_INDIRECT_COUNT_SPEC_VERSION
Version History
Revision 2, 2016-08-23 (Dominik Witczak)
Minor fixes
Revision 1, 2016-07-21 (Matthaeus Chajdas)
Initial draft
VK_AMD_gpu_shader_half_float
Name String
VK_AMD_gpu_shader_half_float
Extension Type
Device extension
Registered Extension Number
37
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_gpu_shader_half_float
Deprecation State
Deprecated
by
VK_KHR_shader_float16_int8
extension
Which in turn was
promoted
to
Vulkan 1.2
Contact
Dominik Witczak
dominikwitczakamd
Other Extension Metadata
Last Modified Date
2019-04-11
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_gpu_shader_half_float
Contributors
Daniel Rakos, AMD
Dominik Witczak, AMD
Donglin Wei, AMD
Graham Sellers, AMD
Qun Lin, AMD
Rex Xu, AMD
Description
This extension adds support for using half float variables in shaders.
Deprecation by
VK_KHR_shader_float16_int8
Functionality in this extension is included in the
VK_KHR_shader_float16_int8
extension, when the
shaderFloat16
feature is enabled.
New Enum Constants
VK_AMD_GPU_SHADER_HALF_FLOAT_EXTENSION_NAME
VK_AMD_GPU_SHADER_HALF_FLOAT_SPEC_VERSION
Version History
Revision 2, 2019-04-11 (Tobias Hector)
Marked as deprecated
Revision 1, 2016-09-21 (Dominik Witczak)
Initial draft
VK_AMD_gpu_shader_int16
Name String
VK_AMD_gpu_shader_int16
Extension Type
Device extension
Registered Extension Number
133
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
SPIR-V Dependencies
SPV_AMD_gpu_shader_int16
Deprecation State
Deprecated
by
VK_KHR_shader_float16_int8
extension
Which in turn was
promoted
to
Vulkan 1.2
Contact
Qun Lin
linqun
Other Extension Metadata
Last Modified Date
2019-04-11
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_AMD_gpu_shader_int16
Contributors
Daniel Rakos, AMD
Dominik Witczak, AMD
Matthaeus G. Chajdas, AMD
Rex Xu, AMD
Timothy Lottes, AMD
Zhi Cai, AMD
Description
This extension adds support for using 16-bit integer variables in shaders.
Deprecation by
VK_KHR_shader_float16_int8
Functionality in this extension is included in the
VK_KHR_shader_float16_int8
extension, when the
shaderInt16
and
shaderFloat16
features are enabled.
New Enum Constants
VK_AMD_GPU_SHADER_INT16_EXTENSION_NAME
VK_AMD_GPU_SHADER_INT16_SPEC_VERSION
Version History
Revision 2, 2019-04-11 (Tobias Hector)
Marked as deprecated
Revision 1, 2017-06-18 (Dominik Witczak)
First version
VK_AMD_negative_viewport_height
Name String
VK_AMD_negative_viewport_height
Extension Type
Device extension
Registered Extension Number
36
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Obsoleted
by
VK_KHR_maintenance1
extension
Which in turn was
promoted
to
Vulkan 1.1
Contact
Matthaeus G. Chajdas
anteru
Other Extension Metadata
Last Modified Date
2016-09-02
IP Status
No known IP claims.
Contributors
Matthaeus G. Chajdas, AMD
Graham Sellers, AMD
Baldur Karlsson
Description
This extension allows an application to specify a negative viewport height.
The result is that the viewport transformation will flip along the y-axis.
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 use
gl_Position.y = -gl_Position.y
in shaders also targeting other APIs.
Obsoletion by
VK_KHR_maintenance1
and Vulkan 1.1
Functionality in this extension is included in the
VK_KHR_maintenance1
extension and subsequently Vulkan 1.1.
Due to some slight behavioral differences, this extension
must
not be
enabled alongside
VK_KHR_maintenance1
, or in an instance created with
version 1.1 or later requested in
VkApplicationInfo
::
apiVersion
New Enum Constants
VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_EXTENSION_NAME
VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_SPEC_VERSION
Version History
Revision 1, 2016-09-02 (Matthaeus Chajdas)
Initial draft
VK_ARM_rasterization_order_attachment_access
Name String
VK_ARM_rasterization_order_attachment_access
Extension Type
Device extension
Registered Extension Number
343
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
Deprecation State
Promoted
to
VK_EXT_rasterization_order_attachment_access
extension
Contact
Jan-Harald Fredriksen
janharaldfredriksen-arm
Other Extension Metadata
Last Modified Date
2026-01-16
IP Status
No known IP claims.
Contributors
Tobias Hector, AMD
Jan-Harald Fredriksen, Arm
Description
Render passes, and specifically subpass dependencies, enable much of the
same functionality as the framebuffer fetch and pixel local storage
extensions did for OpenGL ES.
But certain techniques such as programmable blending are awkward or
impractical to implement with these alone, in part because a self-dependency
is required every time a fragment will read a value at a given sample
coordinate.
This extension extends the mechanism of input attachments to allow access to
framebuffer attachments when used as both input and color, or depth/stencil,
attachments from one fragment to the next, in rasterization order, without
explicit synchronization.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRasterizationOrderAttachmentAccessFeaturesARM
New Enum Constants
VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME
VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION
Extending
VkPipelineColorBlendStateCreateFlagBits
VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_ARM
Extending
VkPipelineDepthStencilStateCreateFlagBits
VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM
VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_ARM
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_ARM
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM
VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM
Issues
See the Issues for
VK_EXT_rasterization_order_attachment_access
Examples
None.
Version History
Revision 1, 2021-11-12 (Jan-Harald Fredriksen)
Initial draft
Updated Issues section 2026-01-16
VK_IMG_format_pvrtc
Name String
VK_IMG_format_pvrtc
Extension Type
Device extension
Registered Extension Number
55
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
without replacement
Contact
Stuart Smith
Other Extension Metadata
Last Modified Date
2019-09-02
IP Status
Imagination Technologies Proprietary
Contributors
Stuart Smith, Imagination Technologies
Description
VK_IMG_format_pvrtc
provides additional texture compression functionality
specific to Imagination Technologies PowerVR Texture compression format
(called PVRTC).
As also noted in the
Khronos Data Format Specification
PVRTC1 images must have dimensions that are a power of two.
Deprecation
Both PVRTC1 and PVRTC2 are slower than standard image formats on PowerVR
GPUs, and support will be removed from future hardware.
New Enum Constants
VK_IMG_FORMAT_PVRTC_EXTENSION_NAME
VK_IMG_FORMAT_PVRTC_SPEC_VERSION
Extending
VkFormat
VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG
VK_FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG
VK_FORMAT_PVRTC1_4BPP_SRGB_BLOCK_IMG
VK_FORMAT_PVRTC1_4BPP_UNORM_BLOCK_IMG
VK_FORMAT_PVRTC2_2BPP_SRGB_BLOCK_IMG
VK_FORMAT_PVRTC2_2BPP_UNORM_BLOCK_IMG
VK_FORMAT_PVRTC2_4BPP_SRGB_BLOCK_IMG
VK_FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG
Version History
Revision 1, 2019-09-02 (Stuart Smith)
Initial version
VK_MVK_ios_surface
Name String
VK_MVK_ios_surface
Extension Type
Instance extension
Registered Extension Number
123
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Deprecation State
Deprecated
by
VK_EXT_metal_surface
extension
Contact
Bill Hollings
billhollings
Other Extension Metadata
Last Modified Date
2020-07-31
IP Status
No known IP claims.
Contributors
Bill Hollings, The Brenwill Workshop Ltd.
Description
The
VK_MVK_ios_surface
extension is an instance extension.
It provides a mechanism to create a
VkSurfaceKHR
object (defined by
the
VK_KHR_surface
extension) based on a
UIView
, the native
surface type of iOS, which is underpinned by a
CAMetalLayer
, to
support rendering to the surface using Apple’s Metal framework.
Deprecation by
VK_EXT_metal_surface
The
VK_MVK_ios_surface
extension is considered deprecated and has been
superseded by the
VK_EXT_metal_surface
extension.
New Commands
vkCreateIOSSurfaceMVK
New Structures
VkIOSSurfaceCreateInfoMVK
New Bitmasks
VkIOSSurfaceCreateFlagsMVK
New Enum Constants
VK_MVK_IOS_SURFACE_EXTENSION_NAME
VK_MVK_IOS_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_IOS_SURFACE_CREATE_INFO_MVK
Version History
Revision 1, 2017-02-15 (Bill Hollings)
Initial draft.
Revision 2, 2017-02-24 (Bill Hollings)
Minor syntax fix to emphasize firm requirement for
UIView
to be
backed by a
CAMetalLayer
Revision 3, 2020-07-31 (Bill Hollings)
Update documentation on requirements for
UIView
Mark as deprecated by
VK_EXT_metal_surface
VK_MVK_macos_surface
Name String
VK_MVK_macos_surface
Extension Type
Instance extension
Registered Extension Number
124
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_surface
Deprecation State
Deprecated
by
VK_EXT_metal_surface
extension
Contact
Bill Hollings
billhollings
Other Extension Metadata
Last Modified Date
2020-07-31
IP Status
No known IP claims.
Contributors
Bill Hollings, The Brenwill Workshop Ltd.
Description
The
VK_MVK_macos_surface
extension is an instance extension.
It provides a mechanism to create a
VkSurfaceKHR
object (defined by
the
VK_KHR_surface
extension) based on an
NSView
, the native
surface type of macOS, which is underpinned by a
CAMetalLayer
, to
support rendering to the surface using Apple’s Metal framework.
Deprecation by
VK_EXT_metal_surface
The
VK_MVK_macos_surface
extension is considered deprecated and has been
superseded by the
VK_EXT_metal_surface
extension.
New Commands
vkCreateMacOSSurfaceMVK
New Structures
VkMacOSSurfaceCreateInfoMVK
New Bitmasks
VkMacOSSurfaceCreateFlagsMVK
New Enum Constants
VK_MVK_MACOS_SURFACE_EXTENSION_NAME
VK_MVK_MACOS_SURFACE_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK
Version History
Revision 1, 2017-02-15 (Bill Hollings)
Initial draft.
Revision 2, 2017-02-24 (Bill Hollings)
Minor syntax fix to emphasize firm requirement for
NSView
to be
backed by a
CAMetalLayer
Revision 3, 2020-07-31 (Bill Hollings)
Update documentation on requirements for
NSView
Mark as deprecated by
VK_EXT_metal_surface
VK_NV_compute_shader_derivatives
Name String
VK_NV_compute_shader_derivatives
Extension Type
Device extension
Registered Extension Number
202
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_compute_shader_derivatives
Deprecation State
Promoted
to
VK_KHR_compute_shader_derivatives
extension
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2018-07-19
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NV_compute_shader_derivatives
Contributors
Pat Brown, NVIDIA
Description
This extension adds Vulkan support for the
SPV_NV_compute_shader_derivatives
SPIR-V extension.
The SPIR-V extension provides two new execution modes, both of which allow
compute shaders to use built-ins that evaluate compute derivatives
explicitly or implicitly.
Derivatives will be computed via differencing over a 2x2 group of shader
invocations.
The
DerivativeGroupQuadsNV
execution mode assembles shader invocations
into 2x2 groups, where each group has x and y coordinates of the local
invocation ID of the form (2m+{0,1}, 2n+{0,1}).
The
DerivativeGroupLinearNV
execution mode assembles shader invocations
into 2x2 groups, where each group has local invocation index values of the
form 4m+{0,1,2,3}.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceComputeShaderDerivativesFeaturesNV
New Enum Constants
VK_NV_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME
VK_NV_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV
New SPIR-V Capability
ComputeDerivativeGroupQuadsNV
ComputeDerivativeGroupLinearNV
Issues
(1) Should we specify that the groups of four shader invocations used for
derivatives in a compute shader are the same groups of four invocations that
form a “quad” in shader subgroups?
RESOLVED
: Yes.
Examples
None.
Version History
Revision 1, 2018-07-19 (Pat Brown)
Initial draft
VK_NV_copy_memory_indirect
Name String
VK_NV_copy_memory_indirect
Extension Type
Device extension
Registered Extension Number
427
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
Deprecation State
Promoted
to
VK_KHR_copy_memory_indirect
extension
Contact
Vikram Kushwaha
vkushwaha-nv
Other Extension Metadata
Last Modified Date
2022-10-14
Contributors
Vikram Kushwaha, NVIDIA
Jeff Bolz, NVIDIA
Christoph Kubisch, NVIDIA
Daniel Koch, NVIDIA
Description
This extension adds support for performing copies between memory and image
regions using indirect parameters that are read by the device from a buffer
during execution.
This functionality
may
be useful for performing copies where the copy
parameters are not known during the command buffer creation time.
New Commands
vkCmdCopyMemoryIndirectNV
vkCmdCopyMemoryToImageIndirectNV
New Structures
VkCopyMemoryIndirectCommandNV
VkCopyMemoryToImageIndirectCommandNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceCopyMemoryIndirectFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceCopyMemoryIndirectPropertiesNV
New Enum Constants
VK_NV_COPY_MEMORY_INDIRECT_EXTENSION_NAME
VK_NV_COPY_MEMORY_INDIRECT_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_PROPERTIES_NV
Version History
Revision 1, 2022-10-14 (Vikram Kushwaha)
Initial draft
VK_NV_dedicated_allocation
Name String
VK_NV_dedicated_allocation
Extension Type
Device extension
Registered Extension Number
27
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
by
VK_KHR_dedicated_allocation
extension
Which in turn was
promoted
to
Vulkan 1.1
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2016-05-31
IP Status
No known IP claims.
Contributors
Jeff Bolz, NVIDIA
Description
This extension allows device memory to be allocated for a particular buffer
or image resource, which on some devices can significantly improve the
performance of that resource.
Normal device memory allocations must support memory aliasing and sparse
binding, which could interfere with optimizations like framebuffer
compression or efficient page table usage.
This is important for render targets and very large resources, but need not
(and probably should not) be used for smaller resources that can benefit
from suballocation.
This extension adds a few small structures to resource creation and memory
allocation: a new structure that flags whether am image/buffer will have a
dedicated allocation, and a structure indicating the image or buffer that an
allocation will be bound to.
New Structures
Extending
VkBufferCreateInfo
VkDedicatedAllocationBufferCreateInfoNV
Extending
VkImageCreateInfo
VkDedicatedAllocationImageCreateInfoNV
Extending
VkMemoryAllocateInfo
VkDedicatedAllocationMemoryAllocateInfoNV
New Enum Constants
VK_NV_DEDICATED_ALLOCATION_EXTENSION_NAME
VK_NV_DEDICATED_ALLOCATION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_BUFFER_CREATE_INFO_NV
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV
Examples
// Create an image with
// VkDedicatedAllocationImageCreateInfoNV::dedicatedAllocation
// set to VK_TRUE

VkDedicatedAllocationImageCreateInfoNV dedicatedImageInfo =
.sType = VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV,
.pNext = NULL,
.dedicatedAllocation = VK_TRUE,
};

VkImageCreateInfo imageCreateInfo =
.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,
.pNext = &dedicatedImageInfo
// Other members set as usual
};

VkImage image;
VkResult result = vkCreateImage(
device,
&imageCreateInfo,
NULL, // pAllocator
&image);

VkMemoryRequirements memoryRequirements;
vkGetImageMemoryRequirements(
device,
image,
&memoryRequirements);

// Allocate memory with VkDedicatedAllocationMemoryAllocateInfoNV::image
// pointing to the image we are allocating the memory for

VkDedicatedAllocationMemoryAllocateInfoNV dedicatedInfo =
.sType = VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,
.pNext = NULL,
.image = image,
.buffer = VK_NULL_HANDLE,
};

VkDeviceMemory memory;
vkAllocateMemory(
device,
&memoryAllocateInfo,
NULL, // pAllocator
&memory);

// Bind the image to the memory

vkBindImageMemory(
device,
image,
memory,
0);
Version History
Revision 1, 2016-05-31 (Jeff Bolz)
Internal revisions
VK_NV_displacement_micromap
Name String
VK_NV_displacement_micromap
Extension Type
Device extension
Registered Extension Number
398
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_EXT_opacity_micromap
This is a
provisional
extension and
must
be used with caution.
See the
description
of provisional header files for enablement and stability details.
Deprecation State
Deprecated
by
VK_NV_cluster_acceleration_structure
extension
Contact
Christoph Kubisch
pixeljetstream
Eric Werness
ewerness-nv
Other Extension Metadata
Last Modified Date
2023-03-17
Interactions and External Dependencies
TBD
Contributors
Christoph Kubisch, NVIDIA
Eric Werness, NVIDIA
Description
Ray tracing can very efficiently render from geometry which has very fine
detail, but when using only a basic triangle representation, memory
consumption can be an issue.
This extension adds the ability to add a
displacement map
to add more
detail to triangles in an acceleration structure with an efficient in-memory
format.
The format is externally visible to allow the application to compress its
internal geometry representations into the compressed format ahead of time.
This format adds displacements along a defined vector to subtriangle
vertices which are subdivided from the main triangles.
This extension provides:
a new
VkMicromapTypeEXT
format for the displacement micromap,
a structure to extend
VkAccelerationStructureGeometryTrianglesDataKHR
to attach a
displacement micromap to the geometry of the acceleration structure,
enums extending
VkBuildAccelerationStructureFlagBitsKHR
to allow
for updates.
New Structures
Extending
VkAccelerationStructureGeometryTrianglesDataKHR
VkAccelerationStructureTrianglesDisplacementMicromapNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceDisplacementMicromapFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceDisplacementMicromapPropertiesNV
New Enums
VkDisplacementMicromapFormatNV
New Enum Constants
VK_NV_DISPLACEMENT_MICROMAP_EXTENSION_NAME
VK_NV_DISPLACEMENT_MICROMAP_SPEC_VERSION
Extending
VkBuildAccelerationStructureFlagBitsKHR
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISPLACEMENT_MICROMAP_UPDATE_BIT_NV
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISPLACEMENT_MICROMAP_UPDATE_NV
Extending
VkMicromapTypeEXT
VK_MICROMAP_TYPE_DISPLACEMENT_MICROMAP_NV
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_RAY_TRACING_DISPLACEMENT_MICROMAP_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_DISPLACEMENT_MICROMAP_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISPLACEMENT_MICROMAP_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISPLACEMENT_MICROMAP_PROPERTIES_NV
Issues
(1) What is the status of this extension?
Deprecated.
The VK_NV_cluster_acceleration_structure extension is not a one-to-one
replacement for this extension but enables similar performance
improvements for high-tessellation geometry and is considered the
preferred direction to improve high-tessellation geometry performance.
Version History
Revision 1, 2023-03-17 (Eric Werness)
Initial public revision
Revision 2, 2023-07-07 (Eric Werness)
Add shader support for decode intrinsics
VK_NV_external_memory
Name String
VK_NV_external_memory
Extension Type
Device extension
Registered Extension Number
57
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_NV_external_memory_capabilities
Deprecation State
Deprecated
by
VK_KHR_external_memory
extension
Which in turn was
promoted
to
Vulkan 1.1
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-08-19
IP Status
No known IP claims.
Contributors
James Jones, NVIDIA
Carsten Rohde, NVIDIA
Description
Applications may wish to export memory to other Vulkan instances or other
APIs, or import memory from other Vulkan instances or other APIs to enable
Vulkan workloads to be split up across application module, process, or API
boundaries.
This extension enables applications to create exportable Vulkan memory
objects such that the underlying resources can be referenced outside the
Vulkan instance that created them.
New Structures
Extending
VkImageCreateInfo
VkExternalMemoryImageCreateInfoNV
Extending
VkMemoryAllocateInfo
VkExportMemoryAllocateInfoNV
New Enum Constants
VK_NV_EXTERNAL_MEMORY_EXTENSION_NAME
VK_NV_EXTERNAL_MEMORY_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV
Issues
1) 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, but strict exceptions to the rules are added to allow some
forms of aliasing in these cases.
Further, other extensions may build upon these new aliasing rules to define
specific support usage within Vulkan for imported native memory objects, or
memory objects from other APIs.
2) 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
: No.
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
(a term to be defined by subsequent interopability extensions), or Vulkan
incompatible.
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
transitioned to the
VK_IMAGE_LAYOUT_GENERAL
layout before handing it
off to the external API.
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.
Examples
// TODO: Write some sample code here.
Version History
Revision 1, 2016-08-19 (James Jones)
Initial draft
VK_NV_external_memory_capabilities
Name String
VK_NV_external_memory_capabilities
Extension Type
Instance extension
Registered Extension Number
56
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
by
VK_KHR_external_memory_capabilities
extension
Which in turn was
promoted
to
Vulkan 1.1
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-08-19
IP Status
No known IP claims.
Interactions and External Dependencies
Interacts with Vulkan 1.1.
Interacts with
VK_KHR_dedicated_allocation
Interacts with
VK_NV_dedicated_allocation
Contributors
James Jones, NVIDIA
Description
Applications may wish to import memory from the Direct 3D API, or export
memory to other Vulkan instances.
This extension provides a set of capability queries that allow applications
determine what types of win32 memory handles an implementation supports for
a given set of use cases.
New Commands
vkGetPhysicalDeviceExternalImageFormatPropertiesNV
New Structures
VkExternalImageFormatPropertiesNV
New Enums
VkExternalMemoryFeatureFlagBitsNV
VkExternalMemoryHandleTypeFlagBitsNV
New Bitmasks
VkExternalMemoryFeatureFlagsNV
VkExternalMemoryHandleTypeFlagsNV
New Enum Constants
VK_NV_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME
VK_NV_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION
Issues
1) Why do so many external memory capabilities need to be queried on a
per-memory-handle-type basis?
RESOLVED
: 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) Does the
VkExternalImageFormatPropertiesNV
structure need to
include a list of memory type bits that support the given handle type?
RESOLVED
: No.
The memory types that do not support the handle types will simply be
filtered out of the results returned by
vkGetImageMemoryRequirements
when a set of handle types was specified at image creation time.
3) Should the non-opaque handle types be moved to their own extension?
RESOLVED
: 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
bitmask 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
Version History
Revision 1, 2016-08-19 (James Jones)
Initial version
VK_NV_external_memory_win32
Name String
VK_NV_external_memory_win32
Extension Type
Device extension
Registered Extension Number
58
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_NV_external_memory
Deprecation State
Deprecated
by
VK_KHR_external_memory_win32
extension
Contact
James Jones
cubanismo
Other Extension Metadata
Last Modified Date
2016-08-19
IP Status
No known IP claims.
Contributors
James Jones, NVIDIA
Carsten Rohde, NVIDIA
Description
Applications may wish to export memory to other Vulkan instances or other
APIs, or import memory from other Vulkan instances or other APIs to enable
Vulkan workloads to be split up across application module, process, or API
boundaries.
This extension enables win32 applications to export win32 handles from
Vulkan memory objects such that the underlying resources can be referenced
outside the Vulkan instance that created them, and import win32 handles
created in the Direct3D API to Vulkan memory objects.
New Commands
vkGetMemoryWin32HandleNV
New Structures
Extending
VkMemoryAllocateInfo
VkExportMemoryWin32HandleInfoNV
VkImportMemoryWin32HandleInfoNV
New Enum Constants
VK_NV_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME
VK_NV_EXTERNAL_MEMORY_WIN32_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV
VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_NV
Issues
1) 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, but strict exceptions to the rules are added to allow some
forms of aliasing in these cases.
Further, other extensions may build upon these new aliasing rules to define
specific support usage within Vulkan for imported native memory objects, or
memory objects from other APIs.
2) 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
: No.
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
(a term to be defined by subsequent interopability extensions), or Vulkan
incompatible.
When sharing images with Vulkan incompatible APIs, the Vulkan image must be
transitioned to the
VK_IMAGE_LAYOUT_GENERAL
layout before handing it
off to the external API.
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.
3) Do applications need to call
CloseHandle
() on the values returned
from
vkGetMemoryWin32HandleNV
when
handleType
is
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV
RESOLVED
: Yes, unless it is passed back in to another driver instance to
import the object.
A successful get call transfers ownership of the handle to the application,
while an import transfers ownership to the associated driver.
Destroying the memory object will not destroy the handle or the handle’s
reference to the underlying memory resource.
Examples
//
// Create an exportable memory object and export an external
// handle from it.
//

// Pick an external format and handle type.
static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
static const VkExternalMemoryHandleTypeFlagsNV handleType =
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV;

extern VkPhysicalDevice physicalDevice;
extern VkDevice device;

VkPhysicalDeviceMemoryProperties memoryProperties;
VkExternalImageFormatPropertiesNV properties;
VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
VkDedicatedAllocationImageCreateInfoNV dedicatedImageCreateInfo;
VkImageCreateInfo imageCreateInfo;
VkImage image;
VkMemoryRequirements imageMemoryRequirements;
uint32_t numMemoryTypes;
uint32_t memoryType;
VkExportMemoryAllocateInfoNV exportMemoryAllocateInfo;
VkDedicatedAllocationMemoryAllocateInfoNV dedicatedAllocationInfo;
VkMemoryAllocateInfo memoryAllocateInfo;
VkDeviceMemory memory;
VkResult result;
HANDLE memoryHnd;

// Figure out how many memory types the device supports
vkGetPhysicalDeviceMemoryProperties(physicalDevice,
&memoryProperties);
numMemoryTypes = memoryProperties.memoryTypeCount;

// Check the external handle type capabilities for the chosen format
// Exportable 2D image support with at least 1 mip level, 1 array
// layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
// texturing and color rendering is required.
result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
physicalDevice,
format,
VK_IMAGE_TYPE_2D,
VK_IMAGE_TILING_OPTIMAL,
VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
0,
handleType,
&properties);

if ((result != VK_SUCCESS) ||
!(properties.externalMemoryFeatures &
VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_NV)) {
abort();

// Set up the external memory image creation info
memset(&externalMemoryImageCreateInfo,
0, sizeof(externalMemoryImageCreateInfo));
externalMemoryImageCreateInfo.sType =
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
externalMemoryImageCreateInfo.handleTypes = handleType;
if (properties.externalMemoryFeatures &
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
memset(&dedicatedImageCreateInfo, 0, sizeof(dedicatedImageCreateInfo));
dedicatedImageCreateInfo.sType =
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV;
dedicatedImageCreateInfo.dedicatedAllocation = VK_TRUE;
externalMemoryImageCreateInfo.pNext = &dedicatedImageCreateInfo;
// Set up the core image creation info
memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
imageCreateInfo.format = format;
imageCreateInfo.extent.width = 64;
imageCreateInfo.extent.height = 64;
imageCreateInfo.extent.depth = 1;
imageCreateInfo.mipLevels = 1;
imageCreateInfo.arrayLayers = 1;
imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

vkCreateImage(device, &imageCreateInfo, NULL, &image);

vkGetImageMemoryRequirements(device,
image,
&imageMemoryRequirements);

// For simplicity, just pick the first compatible memory type.
for (memoryType = 0; memoryType < numMemoryTypes; memoryType++) {
if ((1 << memoryType) & imageMemoryRequirements.memoryTypeBits) {
break;

// At least one memory type must be supported given the prior external
// handle capability check.
assert(memoryType < numMemoryTypes);

// Allocate the external memory object.
memset(&exportMemoryAllocateInfo, 0, sizeof(exportMemoryAllocateInfo));
exportMemoryAllocateInfo.sType =
VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV;
exportMemoryAllocateInfo.handleTypes = handleType;
if (properties.externalMemoryFeatures &
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
memset(&dedicatedAllocationInfo, 0, sizeof(dedicatedAllocationInfo));
dedicatedAllocationInfo.sType =
VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV;
dedicatedAllocationInfo.image = image;
exportMemoryAllocateInfo.pNext = &dedicatedAllocationInfo;
memset(&memoryAllocateInfo, 0, sizeof(memoryAllocateInfo));
memoryAllocateInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
memoryAllocateInfo.pNext = &exportMemoryAllocateInfo;
memoryAllocateInfo.allocationSize = imageMemoryRequirements.size;
memoryAllocateInfo.memoryTypeIndex = memoryType;

vkAllocateMemory(device, &memoryAllocateInfo, NULL, &memory);

if (!(properties.externalMemoryFeatures &
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV)) {
vkBindImageMemory(device, image, memory, 0);

// Get the external memory opaque FD handle
vkGetMemoryWin32HandleNV(device, memory, &memoryHnd);
Version History
Revision 1, 2016-08-11 (James Jones)
Initial draft
VK_NV_fragment_shader_barycentric
Name String
VK_NV_fragment_shader_barycentric
Extension Type
Device extension
Registered Extension Number
204
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_fragment_shader_barycentric
Deprecation State
Promoted
to
VK_KHR_fragment_shader_barycentric
extension
Contact
Pat Brown
nvpbrown
Other Extension Metadata
Last Modified Date
2018-08-03
IP Status
No known IP claims.
Interactions and External Dependencies
This extension provides API support for
GL_NV_fragment_shader_barycentric
Contributors
Pat Brown, NVIDIA
Daniel Koch, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_fragment_shader_barycentric
The extension provides access to three additional fragment shader variable
decorations in SPIR-V:
PerVertexNV
, 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
BaryCoordNV
, which indicates that the variable is a three-component
floating-point vector holding barycentric weights for the fragment
produced using perspective interpolation
BaryCoordNoPerspNV
, 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_NV_fragment_shader_barycentric
maps to these SPIR-V built-in
decorations:
in vec3 gl_BaryCoordNV;
BaryCoordNV
in vec3 gl_BaryCoordNoPerspNV;
BaryCoordNoPerspNV
GLSL variables declared using the
__pervertexNV
GLSL qualifier are
expected to be decorated with
PerVertexNV
in SPIR-V.
Promotion to
VK_KHR_fragment_shader_barycentric
All functionality in this extension is included in
VK_KHR_fragment_shader_barycentric
, with the suffix changed to KHR.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentShaderBarycentricFeaturesNV
New Enum Constants
VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME
VK_NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV
New Built-In Variables
BaryCoordNV
BaryCoordNoPerspNV
New SPIR-V Decorations
PerVertexNV
New SPIR-V Capabilities
FragmentBarycentricNV
Issues
(1) The AMD_shader_explicit_vertex_parameter extension provides similar
functionality.
Why write a new extension, and how is this extension different?
RESOLVED
: For the purposes of Vulkan/SPIR-V, we chose to implement a
separate extension due to several functional differences.
First, the hardware supporting this extension can provide a three-component
barycentric weight vector for variables decorated with
BaryCoordNV
while variables decorated with
BaryCoordSmoothAMD
provide only two
components.
In some cases, it may be more efficient to explicitly interpolate an
attribute via:
float value = (baryCoordNV.x * v[0].attrib +
baryCoordNV.y * v[1].attrib +
baryCoordNV.z * v[2].attrib);
instead of
float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
v[2].attrib);
Additionally, the semantics of the decoration
BaryCoordPullModelAMD
do
not appear to map to anything supported by the initial hardware
implementation of this extension.
This extension provides a smaller number of decorations than the AMD
extension, as we expect that shaders could derive variables decorated with
things like
BaryCoordNoPerspCentroidAMD
with explicit attribute
interpolation instructions.
One other relevant difference is that explicit per-vertex attribute access
using this extension does not require a constant vertex number.
(2) Why do the built-in SPIR-V decorations for this extension include two
separate built-ins
BaryCoordNV
and
BaryCoordNoPerspNV
when a “no
perspective” variable could be decorated with
BaryCoordNV
and
NoPerspective
RESOLVED
: The SPIR-V extension for this feature chose to mirror the
behavior of the GLSL extension, which provides two built-in variables.
Additionally, it is not clear that its a good idea (or even legal) to have
two variables using the “same attribute”, but with different interpolation
modifiers.
Version History
Revision 1, 2018-08-03 (Pat Brown)
Internal revisions
VK_NV_glsl_shader
Name String
VK_NV_glsl_shader
Extension Type
Device extension
Registered Extension Number
13
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Deprecated
without replacement
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2016-02-14
IP Status
No known IP claims.
Contributors
Piers Daniell, NVIDIA
Description
This extension allows GLSL shaders written to the
GL_KHR_vulkan_glsl
extension specification to be used instead of SPIR-V.
The implementation will automatically detect whether the shader is SPIR-V or
GLSL, and compile it appropriately.
Deprecation
Functionality in this extension is outside of the scope of Vulkan and is
better served by a compiler library such as
glslang
No new implementations will support this extension, so applications
should
not use it.
New Enum Constants
VK_NV_GLSL_SHADER_EXTENSION_NAME
VK_NV_GLSL_SHADER_SPEC_VERSION
Extending
VkResult
VK_ERROR_INVALID_SHADER_NV
Examples
Example 1
Passing in GLSL code
char const vss[] =
"#version 450 core\n"
"layout(location = 0) in vec2 aVertex;\n"
"layout(location = 1) in vec4 aColor;\n"
"out vec4 vColor;\n"
"void main()\n"
"{\n"
" vColor = aColor;\n"
" gl_Position = vec4(aVertex, 0, 1);\n"
"}\n"
VkShaderModuleCreateInfo vertexShaderInfo = { VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO };
vertexShaderInfo.codeSize = sizeof vss;
vertexShaderInfo.pCode = vss;
VkShaderModule vertexShader;
vkCreateShaderModule(device, &vertexShaderInfo, 0, &vertexShader);
Version History
Revision 1, 2016-02-14 (Piers Daniell)
Initial draft
VK_NV_memory_decompression
Name String
VK_NV_memory_decompression
Extension Type
Device extension
Registered Extension Number
428
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_KHR_buffer_device_address
or
Vulkan Version 1.2
Deprecation State
Promoted
to
VK_EXT_memory_decompression
extension
Contact
Vikram Kushwaha
vkushwaha-nv
Other Extension Metadata
Last Modified Date
2022-01-31
Contributors
Vikram Kushwaha, NVIDIA
Jeff Bolz, NVIDIA
Christoph Kubisch, NVIDIA
Piers Daniell, NVIDIA
Description
This extension adds support for performing memory to memory decompression.
New Commands
vkCmdDecompressMemoryIndirectCountNV
vkCmdDecompressMemoryNV
New Structures
VkDecompressMemoryRegionNV
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMemoryDecompressionFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceMemoryDecompressionPropertiesNV
New Enums
VkMemoryDecompressionMethodFlagBitsNV
New Bitmasks
VkMemoryDecompressionMethodFlagsNV
New Enum Constants
VK_NV_MEMORY_DECOMPRESSION_EXTENSION_NAME
VK_NV_MEMORY_DECOMPRESSION_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_PROPERTIES_NV
Version History
Revision 1, 2022-01-31 (Vikram Kushwaha)
Initial draft
VK_NV_per_stage_descriptor_set
Name String
VK_NV_per_stage_descriptor_set
Extension Type
Device extension
Registered Extension Number
517
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_maintenance6
or
Vulkan Version 1.4
Deprecation State
Deprecated
by
VK_EXT_descriptor_heap
extension
Contact
Piers Daniell
pdaniell-nv
Other Extension Metadata
Last Modified Date
2023-10-16
IP Status
No known IP claims.
Contributors
Daniel Story, Nintendo
Description
This extension introduces a new descriptor set layout creation flag that
allows bindings in a descriptor set to be scoped to each shader stage.
This means that shaders bound at the same time
may
use completely different
descriptor set layouts without any restrictions on compatibility, and that
the descriptor limits that would otherwise apply to the union of all stages
together instead apply to each stage individually.
It also means that descriptors shared by multiple stages
must
be bound to
each stage or set of stages that use a unique descriptor set layout using
their specific per stage descriptor set layout(s).
This extension also allows each of the new descriptor binding functions from
VK_KHR_maintenance6 to have their
VkPipelineLayout
member be
optionally set to
VK_NULL_HANDLE
, in which case the pipeline layout
information is taken from a
VkPipelineLayoutCreateInfo
structure in
the
pNext
chain.
This enables descriptors to be directly bound using descriptor set layouts
without applications needing to create and manage
VkPipelineLayout
objects at command recording time.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDevicePerStageDescriptorSetFeaturesNV
New Enum Constants
VK_NV_PER_STAGE_DESCRIPTOR_SET_EXTENSION_NAME
VK_NV_PER_STAGE_DESCRIPTOR_SET_SPEC_VERSION
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PER_STAGE_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PER_STAGE_DESCRIPTOR_SET_FEATURES_NV
Issues
None
Version History
Revision 1, 2023-10-16 (Piers Daniell)
Initial draft
VK_NV_ray_tracing
Name String
VK_NV_ray_tracing
Extension Type
Device extension
Registered Extension Number
166
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
and
VK_KHR_get_memory_requirements2
or
Vulkan Version 1.1
API Interactions
Interacts with VK_VERSION_1_1
Interacts with VK_EXT_debug_report
Interacts with VK_KHR_get_memory_requirements2
SPIR-V Dependencies
SPV_NV_ray_tracing
Deprecation State
Deprecated
by
VK_KHR_ray_tracing_pipeline
extension
Contact
Eric Werness
ewerness-nv
Other Extension Metadata
Last Modified Date
2018-11-20
Interactions and External Dependencies
This extension provides API support for
GL_NV_ray_tracing
Contributors
Eric Werness, NVIDIA
Ashwin Lele, NVIDIA
Robert Stepinski, NVIDIA
Nuno Subtil, NVIDIA
Christoph Kubisch, NVIDIA
Martin Stich, NVIDIA
Daniel Koch, NVIDIA
Jeff Bolz, NVIDIA
Joshua Barczak, Intel
Tobias Hector, AMD
Henrik Rydgard, NVIDIA
Pascal Gautron, NVIDIA
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:
Acceleration structure objects and build commands
A new pipeline type with new shader domains
An indirection table to link shader groups with acceleration structure
items
This extension adds support for the following SPIR-V extension in Vulkan:
SPV_NV_ray_tracing
New Object Types
VkAccelerationStructureNV
New Commands
vkBindAccelerationStructureMemoryNV
vkCmdBuildAccelerationStructureNV
vkCmdCopyAccelerationStructureNV
vkCmdTraceRaysNV
vkCmdWriteAccelerationStructuresPropertiesNV
vkCompileDeferredNV
vkCreateAccelerationStructureNV
vkCreateRayTracingPipelinesNV
vkDestroyAccelerationStructureNV
vkGetAccelerationStructureHandleNV
vkGetAccelerationStructureMemoryRequirementsNV
vkGetRayTracingShaderGroupHandlesNV
New Structures
VkAabbPositionsNV
VkAccelerationStructureCreateInfoNV
VkAccelerationStructureInfoNV
VkAccelerationStructureInstanceNV
VkAccelerationStructureMemoryRequirementsInfoNV
VkBindAccelerationStructureMemoryInfoNV
VkGeometryAABBNV
VkGeometryDataNV
VkGeometryNV
VkGeometryTrianglesNV
VkRayTracingPipelineCreateInfoNV
VkRayTracingShaderGroupCreateInfoNV
VkTransformMatrixNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRayTracingPropertiesNV
Extending
VkWriteDescriptorSet
VkWriteDescriptorSetAccelerationStructureNV
If
VK_KHR_get_memory_requirements2
or
Vulkan Version 1.1
is supported:
VkMemoryRequirements2KHR
New Enums
VkAccelerationStructureMemoryRequirementsTypeNV
VkAccelerationStructureTypeNV
VkBuildAccelerationStructureFlagBitsNV
VkCopyAccelerationStructureModeNV
VkGeometryFlagBitsNV
VkGeometryInstanceFlagBitsNV
VkGeometryTypeNV
VkRayTracingShaderGroupTypeNV
New Bitmasks
VkBuildAccelerationStructureFlagsNV
VkGeometryFlagsNV
VkGeometryInstanceFlagsNV
New Enum Constants
VK_NV_RAY_TRACING_EXTENSION_NAME
VK_NV_RAY_TRACING_SPEC_VERSION
VK_SHADER_UNUSED_NV
Extending
VkAccelerationStructureTypeKHR
VK_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_NV
VK_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_NV
Extending
VkAccessFlagBits
VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_NV
VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_NV
Extending
VkBufferUsageFlagBits
VK_BUFFER_USAGE_RAY_TRACING_BIT_NV
Extending
VkBuildAccelerationStructureFlagBitsKHR
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_NV
VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_NV
VK_BUILD_ACCELERATION_STRUCTURE_LOW_MEMORY_BIT_NV
VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_BUILD_BIT_NV
VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_TRACE_BIT_NV
Extending
VkCopyAccelerationStructureModeKHR
VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NV
VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NV
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_NV
Extending
VkGeometryFlagBitsKHR
VK_GEOMETRY_NO_DUPLICATE_ANY_HIT_INVOCATION_BIT_NV
VK_GEOMETRY_OPAQUE_BIT_NV
Extending
VkGeometryInstanceFlagBitsKHR
VK_GEOMETRY_INSTANCE_FORCE_NO_OPAQUE_BIT_NV
VK_GEOMETRY_INSTANCE_FORCE_OPAQUE_BIT_NV
VK_GEOMETRY_INSTANCE_TRIANGLE_CULL_DISABLE_BIT_NV
VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_NV
Extending
VkGeometryTypeKHR
VK_GEOMETRY_TYPE_AABBS_NV
VK_GEOMETRY_TYPE_TRIANGLES_NV
Extending
VkIndexType
VK_INDEX_TYPE_NONE_NV
Extending
VkObjectType
VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV
Extending
VkPipelineBindPoint
VK_PIPELINE_BIND_POINT_RAY_TRACING_NV
Extending
VkPipelineCreateFlagBits
VK_PIPELINE_CREATE_DEFER_COMPILE_BIT_NV
Extending
VkPipelineStageFlagBits
VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_NV
VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV
Extending
VkQueryType
VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_NV
Extending
VkRayTracingShaderGroupTypeKHR
VK_RAY_TRACING_SHADER_GROUP_TYPE_GENERAL_NV
VK_RAY_TRACING_SHADER_GROUP_TYPE_PROCEDURAL_HIT_GROUP_NV
VK_RAY_TRACING_SHADER_GROUP_TYPE_TRIANGLES_HIT_GROUP_NV
Extending
VkShaderStageFlagBits
VK_SHADER_STAGE_ANY_HIT_BIT_NV
VK_SHADER_STAGE_CALLABLE_BIT_NV
VK_SHADER_STAGE_CLOSEST_HIT_BIT_NV
VK_SHADER_STAGE_INTERSECTION_BIT_NV
VK_SHADER_STAGE_MISS_BIT_NV
VK_SHADER_STAGE_RAYGEN_BIT_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_INFO_NV
VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MEMORY_REQUIREMENTS_INFO_NV
VK_STRUCTURE_TYPE_BIND_ACCELERATION_STRUCTURE_MEMORY_INFO_NV
VK_STRUCTURE_TYPE_GEOMETRY_AABB_NV
VK_STRUCTURE_TYPE_GEOMETRY_NV
VK_STRUCTURE_TYPE_GEOMETRY_TRIANGLES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PROPERTIES_NV
VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_NV
VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_NV
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_NV
If
VK_EXT_debug_report
is supported:
Extending
VkDebugReportObjectTypeEXT
VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV_EXT
New or Modified Built-In Variables
LaunchIdNV
LaunchSizeNV
WorldRayOriginNV
WorldRayDirectionNV
ObjectRayOriginNV
ObjectRayDirectionNV
RayTminNV
RayTmaxNV
InstanceCustomIndexNV
InstanceId
ObjectToWorldNV
WorldToObjectNV
HitTNV
HitKindNV
IncomingRayFlagsNV
(modified)
PrimitiveId
New SPIR-V Capabilities
RayTracingNV
Issues
1) Are there issues?
RESOLVED
: Yes.
Sample Code
Example ray generation GLSL shader
#version 450 core
#extension GL_NV_ray_tracing : require
layout(set = 0, binding = 0, rgba8) uniform image2D image;
layout(set = 0, binding = 1) uniform accelerationStructureNV as;
layout(location = 0) rayPayloadNV float payload;

void main()
vec4 col = vec4(0, 0, 0, 1);

vec3 origin = vec3(float(gl_LaunchIDNV.x)/float(gl_LaunchSizeNV.x), float(gl_LaunchIDNV.y)/float(gl_LaunchSizeNV.y), 1.0);
vec3 dir = vec3(0.0, 0.0, -1.0);

traceNV(as, 0, 0xff, 0, 1, 0, origin, 0.0, dir, 1000.0, 0);

col.y = payload;

imageStore(image, ivec2(gl_LaunchIDNV.xy), col);
Version History
Revision 1, 2018-09-11 (Robert Stepinski, Nuno Subtil, Eric Werness)
Internal revisions
Revision 2, 2018-10-19 (Eric Werness)
rename to VK_NV_ray_tracing, add support for callables.
too many updates to list
Revision 3, 2018-11-20 (Daniel Koch)
update to use InstanceId instead of InstanceIndex as implemented.
VK_NV_ray_tracing_invocation_reorder
Name String
VK_NV_ray_tracing_invocation_reorder
Extension Type
Device extension
Registered Extension Number
491
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_ray_tracing_pipeline
SPIR-V Dependencies
SPV_NV_shader_invocation_reorder
Deprecation State
Promoted
to
VK_EXT_ray_tracing_invocation_reorder
extension
Contact
Eric Werness
ewerness-nv
Other Extension Metadata
Last Modified Date
2022-11-02
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_invocation_reorder
Contributors
Eric Werness, NVIDIA
Ashwin Lele, NVIDIA
Description
The ray tracing pipeline API provides some ability to reorder for locality,
but it is useful to have more control over how the reordering happens and
what information is included in the reordering.
The shader API provides a hit object to contain result information from the
hit which can be used as part of the explicit sorting plus options that
contain an integer for hint bits to use to add more locality.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceRayTracingInvocationReorderFeaturesNV
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceRayTracingInvocationReorderPropertiesNV
New Enums
VkRayTracingInvocationReorderModeNV
New Enum Constants
VK_NV_RAY_TRACING_INVOCATION_REORDER_EXTENSION_NAME
VK_NV_RAY_TRACING_INVOCATION_REORDER_SPEC_VERSION
Extending
VkRayTracingInvocationReorderModeEXT
VK_RAY_TRACING_INVOCATION_REORDER_MODE_NONE_NV
VK_RAY_TRACING_INVOCATION_REORDER_MODE_REORDER_NV
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_FEATURES_NV
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_PROPERTIES_NV
HLSL Mapping
HLSL does not provide this functionality natively yet.
However, it is possible to use this functionality via
SPIR-V
Intrinsics
The codes for shader invocation reorder are obtained from
this
page
#define ShaderInvocationReorderNV 5383
#define HitObjectAttributeNV 5385

#define OpHitObjectRecordHitMotionNV 5249
#define OpHitObjectRecordHitWithIndexMotionNV 5250
#define OpHitObjectRecordMissMotionNV 5251
#define OpHitObjectGetWorldToObjectNV 5252
#define OpHitObjectGetObjectToWorldNV 5253
#define OpHitObjectGetObjectRayDirectionNV 5254
#define OpHitObjectGetObjectRayOriginNV 5255
#define OpHitObjectTraceRayMotionNV 5256
#define OpHitObjectGetShaderRecordBufferHandleNV 5257
#define OpHitObjectGetShaderBindingTableRecordIndexNV 5258
#define OpHitObjectRecordEmptyNV 5259
#define OpHitObjectTraceRayNV 5260
#define OpHitObjectRecordHitNV 5261
#define OpHitObjectRecordHitWithIndexNV 5262
#define OpHitObjectRecordMissNV 5263
#define OpHitObjectExecuteShaderNV 5264
#define OpHitObjectGetCurrentTimeNV 5265
#define OpHitObjectGetAttributesNV 5266
#define OpHitObjectGetHitKindNV 5267
#define OpHitObjectGetPrimitiveIndexNV 5268
#define OpHitObjectGetGeometryIndexNV 5269
#define OpHitObjectGetInstanceIdNV 5270
#define OpHitObjectGetInstanceCustomIndexNV 5271
#define OpHitObjectGetWorldRayDirectionNV 5272
#define OpHitObjectGetWorldRayOriginNV 5273
#define OpHitObjectGetRayTMaxNV 5274
#define OpHitObjectGetRayTMinNV 5275
#define OpHitObjectIsEmptyNV 5276
#define OpHitObjectIsHitNV 5277
#define OpHitObjectIsMissNV 5278
#define OpReorderThreadWithHitObjectNV 5279
#define OpReorderThreadWithHintNV 5280
#define OpTypeHitObjectNV 5281
The capability and extension need to be added:
[[vk::ext_capability(ShaderInvocationReorderNV)]]
[[vk::ext_extension("SPV_NV_shader_invocation_reorder")]]
The creation of the
HitObject
type can be done like this:
[[vk::ext_type_def(HitObjectAttributeNV, OpTypeHitObjectNV)]]
void createHitObjectNV();
#define HitObjectNV vk::ext_type
The payload:
must be global
needs the
RayPayloadKHR
attribute as an extra storage class
struct [raypayload] HitPayload
float hitT : write(closesthit, miss) : read(caller);
int instanceIndex : write(closesthit) : read(caller);
float3 pos : write(closesthit) : read(caller);
float3 nrm : write(closesthit) : read(caller);
};

#define RayPayloadKHR 5338
[[vk::ext_storage_class(RayPayloadKHR)]] static HitPayload payload;
Here is the declaration of a few invocation reordering functions:
[[vk::ext_instruction(OpHitObjectRecordEmptyNV)]]
void hitObjectRecordEmptyNV([[vk::ext_reference]] HitObjectNV hitObject);

[[vk::ext_instruction(OpHitObjectTraceRayNV)]]
void hitObjectTraceRayNV(
[[vk::ext_reference]] HitObjectNV hitObject,
RaytracingAccelerationStructure as,
uint RayFlags,
uint CullMask,
uint SBTOffset,
uint SBTStride,
uint MissIndex,
float3 RayOrigin,
float RayTmin,
float3 RayDirection,
float RayTMax,
[[vk::ext_reference]] [[vk::ext_storage_class(RayPayloadKHR)]] HitPayload payload
);

[[vk::ext_instruction(OpReorderThreadWithHintNV)]]
void reorderThreadWithHintNV(int Hint, int Bits);

[[vk::ext_instruction(OpReorderThreadWithHitObjectNV)]]
void reorderThreadWithHitObjectNV([[vk::ext_reference]] HitObjectNV hitObject);

[[vk::ext_instruction(OpHitObjectExecuteShaderNV)]]
void hitObjectExecuteShaderNV([[vk::ext_reference]] HitObjectNV hitObject, [[vk::ext_reference]] [[vk::ext_storage_class(RayPayloadKHR)]] HitPayload payload);

[[vk::ext_instruction(OpHitObjectIsHitNV)]]
bool hitObjectIsHitNV([[vk::ext_reference]] HitObjectNV hitObject);
Using the function in the code, can be done like this
if (USE_SER == 1)
createHitObjectNV();
HitObjectNV hObj; // hitObjectNV hObj;
hitObjectRecordEmptyNV(hObj); //Initialize to an empty hit object
hitObjectTraceRayNV(hObj, topLevelAS, rayFlags, 0xFF, 0, 0, 0, r.Origin, 0.0, r.Direction, INFINITE, payload);
reorderThreadWithHitObjectNV(hObj);
hitObjectExecuteShaderNV(hObj, payload);
Note:
createHitObjectNV() needs to be call at least once.
This can be also done in the main entry of the shader.
Function with a payload parameter, needs to have the payload struct
defined before.
There are no templated declaration of the function.
Version History
Revision 1, 2020-09-12 (Eric Werness, Ashwin Lele)
Initial external release
VK_NV_shader_subgroup_partitioned
Name String
VK_NV_shader_subgroup_partitioned
Extension Type
Device extension
Registered Extension Number
199
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
Vulkan Version 1.1
SPIR-V Dependencies
SPV_NV_shader_subgroup_partitioned
Deprecation State
Promoted
to
VK_EXT_shader_subgroup_partitioned
extension
Contact
Jeff Bolz
jeffbolznv
Other Extension Metadata
Last Modified Date
2025-11-12
Interactions and External Dependencies
This extension provides API support for
GL_NV_shader_subgroup_partitioned
Contributors
Jeff Bolz, NVIDIA
Description
This extension enables support for a new class of
group operations
on
subgroups
via the
GL_NV_shader_subgroup_partitioned
GLSL extension and
SPV_NV_shader_subgroup_partitioned
SPIR-V extension.
Support for these new operations is advertised via the
VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV
bit.
This extension requires Vulkan 1.1, for general subgroup support.
Promotion to
VK_EXT_shader_subgroup_partitioned
All functionality in this extension is included in
VK_EXT_shader_subgroup_partitioned
, with the suffix changed to EXT.
The original type, enum, and command names are still available as aliases of
the core functionality.
New Enum Constants
VK_NV_SHADER_SUBGROUP_PARTITIONED_EXTENSION_NAME
VK_NV_SHADER_SUBGROUP_PARTITIONED_SPEC_VERSION
Extending
VkSubgroupFeatureFlagBits
VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV
Version History
Revision 1, 2018-03-17 (Jeff Bolz)
Internal revisions
VK_NV_win32_keyed_mutex
Name String
VK_NV_win32_keyed_mutex
Extension Type
Device extension
Registered Extension Number
59
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_NV_external_memory_win32
Deprecation State
Promoted
to
VK_KHR_win32_keyed_mutex
extension
Contact
Carsten Rohde
crohde
Other Extension Metadata
Last Modified Date
2016-08-19
IP Status
No known IP claims.
Contributors
James Jones, 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 Structures
Extending
VkSubmitInfo
VkSubmitInfo2
VkWin32KeyedMutexAcquireReleaseInfoNV
New Enum Constants
VK_NV_WIN32_KEYED_MUTEX_EXTENSION_NAME
VK_NV_WIN32_KEYED_MUTEX_SPEC_VERSION
Extending
VkStructureType
VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV
Examples
//
// Import a memory object from Direct3D 11, and synchronize
// access to it in Vulkan using keyed mutex objects.
//

extern VkPhysicalDevice physicalDevice;
extern VkDevice device;
extern HANDLE sharedNtHandle;

static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
static const VkExternalMemoryHandleTypeFlagsNV handleType =
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_IMAGE_BIT_NV;

VkPhysicalDeviceMemoryProperties memoryProperties;
VkExternalImageFormatPropertiesNV properties;
VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
VkImageCreateInfo imageCreateInfo;
VkImage image;
VkMemoryRequirements imageMemoryRequirements;
uint32_t numMemoryTypes;
uint32_t memoryType;
VkImportMemoryWin32HandleInfoNV importMemoryInfo;
VkMemoryAllocateInfo memoryAllocateInfo;
VkDeviceMemory mem;
VkResult result;

// Figure out how many memory types the device supports
vkGetPhysicalDeviceMemoryProperties(physicalDevice,
&memoryProperties);
numMemoryTypes = memoryProperties.memoryTypeCount;

// Check the external handle type capabilities for the chosen format
// Importable 2D image support with at least 1 mip level, 1 array
// layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
// texturing and color rendering is required.
result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
physicalDevice,
format,
VK_IMAGE_TYPE_2D,
VK_IMAGE_TILING_OPTIMAL,
VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
0,
handleType,
&properties);

if ((result != VK_SUCCESS) ||
!(properties.externalMemoryFeatures &
VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_NV)) {
abort();

// Set up the external memory image creation info
memset(&externalMemoryImageCreateInfo,
0, sizeof(externalMemoryImageCreateInfo));
externalMemoryImageCreateInfo.sType =
VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
externalMemoryImageCreateInfo.handleTypes = handleType;
// Set up the core image creation info
memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
imageCreateInfo.format = format;
imageCreateInfo.extent.width = 64;
imageCreateInfo.extent.height = 64;
imageCreateInfo.extent.depth = 1;
imageCreateInfo.mipLevels = 1;
imageCreateInfo.arrayLayers = 1;
imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

vkCreateImage(device, &imageCreateInfo, NULL, &image);
vkGetImageMemoryRequirements(device,
image,
&imageMemoryRequirements);

// At least one memory type must be supported given the prior external
// handle capability check.
assert(memoryType < numMemoryTypes);

memset(&memoryAllocateInfo, 0, sizeof(memoryAllocateInfo));
memoryAllocateInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
memoryAllocateInfo.pNext = &exportMemoryAllocateInfo;
memoryAllocateInfo.allocationSize = imageMemoryRequirements.size;
memoryAllocateInfo.memoryTypeIndex = memoryType;

vkAllocateMemory(device, &memoryAllocateInfo, NULL, &mem);

vkBindImageMemory(device, image, mem, 0);

...

const uint64_t acquireKey = 1;
const uint32_t timeout = INFINITE;
const uint64_t releaseKey = 2;

VkWin32KeyedMutexAcquireReleaseInfoNV keyedMutex =
{ VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV };
keyedMutex.acquireCount = 1;
keyedMutex.pAcquireSyncs = &mem;
keyedMutex.pAcquireKeys = &acquireKey;
keyedMutex.pAcquireTimeoutMilliseconds = &timeout;
keyedMutex.releaseCount = 1;
keyedMutex.pReleaseSyncs = &mem;
keyedMutex.pReleaseKeys = &releaseKey;

VkSubmitInfo submit_info = { VK_STRUCTURE_TYPE_SUBMIT_INFO, &keyedMutex };
submit_info.commandBufferCount = 1;
submit_info.pCommandBuffers = &cmd_buf;
vkQueueSubmit(queue, 1, &submit_info, VK_NULL_HANDLE);
Version History
Revision 2, 2016-08-11 (James Jones)
Updated sample code based on the NV external memory extensions.
Renamed from NVX to NV extension.
Added Overview and Description sections.
Updated sample code to use the NV external memory extensions.
Revision 1, 2016-06-14 (Carsten Rohde)
Initial draft.
VK_QCOM_fragment_density_map_offset
Name String
VK_QCOM_fragment_density_map_offset
Extension Type
Device extension
Registered Extension Number
426
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1
and
VK_EXT_fragment_density_map
Deprecation State
Promoted
to
VK_EXT_fragment_density_map_offset
extension
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2024-06-17
Contributors
Matthew Netsch, Qualcomm Technologies, Inc.
Jonathan Wicks, Qualcomm Technologies, Inc.
Jonathan Tinkham, Qualcomm Technologies, Inc.
Jeff Leger, Qualcomm Technologies, Inc.
Manan Katwala, Qualcomm Technologies, Inc.
Connor Abbott, Valve Corporation
Description
This extension allows an application to specify offsets to a fragment
density map attachment, changing the location where the fragment density map
is applied to the framebuffer.
This is helpful for eye-tracking use cases where the fovea needs to be moved
around the framebuffer to match the eye pose.
New Structures
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceFragmentDensityMapOffsetFeaturesQCOM
Extending
VkPhysicalDeviceProperties2
VkPhysicalDeviceFragmentDensityMapOffsetPropertiesQCOM
Extending
VkSubpassEndInfo
VkRenderingEndInfoKHR
VkSubpassFragmentDensityMapOffsetEndInfoQCOM
New Enum Constants
VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_EXTENSION_NAME
VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_SPEC_VERSION
Extending
VkImageCreateFlagBits
VK_IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_QCOM
Extending
VkStructureType
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_FEATURES_QCOM
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_PROPERTIES_QCOM
VK_STRUCTURE_TYPE_SUBPASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_QCOM
Version History
Revision 3, 2025-03-20 (Connor Abbott/Matthew Netsch)
Fix clamp equation and clarify the offsets are FDM relative (editorial
only)
Revision 2, 2024-06-17 (Matthew Netsch)
Fix typo in spec regarding fragmentDensityMapOffset feature
Revision 1, 2021-09-03 (Matthew Netsch)
Initial version
VK_QCOM_render_pass_shader_resolve
Name String
VK_QCOM_render_pass_shader_resolve
Extension Type
Device extension
Registered Extension Number
172
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
None
Deprecation State
Promoted
to
VK_EXT_custom_resolve
extension
Contact
Matthew Netsch
mnetsch
Other Extension Metadata
Last Modified Date
2019-11-07
IP Status
No known IP claims.
Interactions and External Dependencies
None.
Contributors
Srihari Babu Alla, Qualcomm
Bill Licea-Kane, Qualcomm
Jeff Leger, Qualcomm
Description
This extension allows a shader resolve to replace fixed-function resolve.
Fixed-function resolve is limited in function to simple filters of
multisample buffers to a single sample buffer.
Fixed-function resolve is more performance efficient and/or power efficient
than shader resolve for such simple filters.
Shader resolve allows a shader writer to create complex, non-linear
filtering of a multisample buffer in the last subpass of a subpass
dependency chain.
This extension also provides a bit which
can
be used to enlarge a sample
region dependency to a fragment region dependency, so that a
framebuffer-region dependency
can
replace a framebuffer-global dependency
in some cases.
New Enum Constants
VK_QCOM_RENDER_PASS_SHADER_RESOLVE_EXTENSION_NAME
VK_QCOM_RENDER_PASS_SHADER_RESOLVE_SPEC_VERSION
Extending
VkSubpassDescriptionFlagBits
VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM
VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM
Issues
1) Should this extension be named render_pass_shader_resolve?
RESOLVED
Yes.
This is part of suite of small extensions to render pass.
Following the style guide, instead of following VK_KHR_create_renderpass2.
2) Should the VK_SAMPLE_COUNT_1_BIT be required for each pColorAttachment
and the DepthStencilAttachment?
RESOLVED
No.
While this may not be a common use case, and while most fixed-function
resolve hardware has this limitation, there is little reason to require a
shader resolve to resolve to a single sample buffer.
3) Should a shader resolve subpass be the last subpass in a render pass?
RESOLVED
Yes.
To be more specific, it should be the last subpass in a subpass dependency
chain.
4) Do we need the
VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM
bit?
RESOLVED
Yes.
This applies when an input attachment’s sample count is equal to
rasterizationSamples
Further, if
sampleShading
is enabled (explicitly or implicitly) then
minSampleShading
must
equal 0.0.
However, this bit may be set on any subpass, it is not restricted to a
shader resolve subpass.
Version History
Revision 1, 2019-06-28 (wwlk)
Initial draft
Revision 2, 2019-11-06 (wwlk)
General clean-up/spec updates
Added issues
Revision 3, 2019-11-07 (wwlk)
Typos
Additional issues
Clarified that a shader resolve subpass is the last subpass in a
subpass dependency chain
Revision 4, 2020-01-06 (wwlk)
Change resolution of Issue 1 (
render_pass
, not
renderpass
VK_VALVE_mutable_descriptor_type
Name String
VK_VALVE_mutable_descriptor_type
Extension Type
Device extension
Registered Extension Number
352
Revision
Ratification Status
Not ratified
Extension and Version Dependencies
VK_KHR_maintenance3
Deprecation State
Promoted
to
VK_EXT_mutable_descriptor_type
extension
Special Use
D3D support
Contact
Joshua Ashton
Joshua-Ashton
Hans-Kristian Arntzen
HansKristian-Work
Other Extension Metadata
Last Modified Date
2020-12-02
IP Status
No known IP claims.
Contributors
Joshua Ashton, Valve
Hans-Kristian Arntzen, Valve
Description
This extension allows applications to reduce descriptor memory footprint by
allowing a descriptor to be able to mutate to a given list of descriptor
types depending on which descriptor types are written into, or copied into a
descriptor set.
The main use case this extension intends to address is descriptor indexing
with
VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT
where the
descriptor types are completely generic, as this means applications can
allocate one large descriptor set, rather than having one large descriptor
set per descriptor type, which significantly bloats descriptor memory usage
and causes performance issues.
This extension also adds a mechanism to declare that a descriptor pool, and
therefore the descriptor sets that are allocated from it, reside only in
host memory; as such these descriptors can only be updated/copied, but not
bound.
These features together allow much more efficient emulation of the raw D3D12
binding model.
This extension is primarily intended to be useful for API layering efforts.
New Structures
VkMutableDescriptorTypeListVALVE
Extending
VkDescriptorSetLayoutCreateInfo
VkDescriptorPoolCreateInfo
VkMutableDescriptorTypeCreateInfoVALVE
Extending
VkPhysicalDeviceFeatures2
VkDeviceCreateInfo
VkPhysicalDeviceMutableDescriptorTypeFeaturesVALVE
New Enum Constants
VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME
VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION
Extending
VkDescriptorPoolCreateFlagBits
VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_VALVE
Extending
VkDescriptorSetLayoutCreateFlagBits
VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_VALVE
Extending
VkDescriptorType
VK_DESCRIPTOR_TYPE_MUTABLE_VALVE
Extending
VkStructureType
VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_VALVE
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_VALVE
Version History
Revision 1, 2020-12-01 (Joshua Ashton, Hans-Kristian Arntzen)
Initial specification, squashed from public draft.