Vulkan Logo

Appendix E: Layers & Extensions (Informative)

Extensions to the Vulkan API can be defined by authors, groups of authors, and the Khronos Vulkan Working Group. In order not to compromise the readability of the Vulkan Specification, the core Specification does not incorporate most extensions. The online Registry of extensions is available at URL

and allows generating versions of the Specification incorporating different extensions.

Authors creating extensions and layers must follow the mandatory procedures described in the Vulkan Documentation and Extensions document when creating extensions and layers.

The remainder of this appendix documents a set of extensions chosen when this document was built. Versions of the Specification published in the Registry include:

  • Core API + mandatory extensions required of all Vulkan implementations.

  • Core API + all registered and published Khronos (KHR) extensions.

  • Core API + all registered and published extensions.

Extensions are grouped as Khronos KHR, multivendor EXT, and then alphabetically by author ID. Within each group, extensions are listed in alphabetical order by their name.

Extension Dependencies

Extensions which have dependencies on specific core versions or on other extensions will list such dependencies.

For core versions, the specified version must be supported at runtime. All extensions implicitly require support for Vulkan 1.0.

For a device extension, use of any device-level functionality defined by that extension requires that any extensions that extension depends on be enabled.

For any extension, use of any instance-level functionality defined by that extension requires only that any extensions that extension depends on be supported at runtime.

Extension Interactions

Some extensions define APIs which are only supported when other extensions or core versions are supported at runtime. Such interactions are noted as “API Interactions”.

List of Current Extensions

VK_KHR_acceleration_structure

Name String

VK_KHR_acceleration_structure

Extension Type

Device extension

Registered Extension Number

151

Revision

13

Ratification Status

Ratified

Extension and Version Dependencies

         Version 1.1
         and
         VK_EXT_descriptor_indexing
         and
         VK_KHR_buffer_device_address
     or
     Version 1.2
and
VK_KHR_deferred_host_operations

API Interactions
  • Interacts with VK_VERSION_1_3

  • Interacts with VK_EXT_debug_report

  • Interacts with VK_KHR_format_feature_flags2

Contact
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
New Enum Constants
  • VK_KHR_ACCELERATION_STRUCTURE_EXTENSION_NAME

  • VK_KHR_ACCELERATION_STRUCTURE_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR

    • VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR

    • VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR

  • Extending VkIndexType:

    • VK_INDEX_TYPE_NONE_KHR

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR

  • Extending VkQueryType:

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_KHR

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_SIZE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_GEOMETRY_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_DEVICE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_AABBS_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_INSTANCES_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_TRIANGLES_DATA_KHR

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_TO_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_ACCELERATION_STRUCTURE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_KHR

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:

(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?

(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:

  • 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)

VK_KHR_android_surface

Name String

VK_KHR_android_surface

Extension Type

Instance extension

Registered Extension Number

9

Revision

6

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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
New Enum Constants
  • VK_KHR_ANDROID_SURFACE_EXTENSION_NAME

  • VK_KHR_ANDROID_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR

Issues

1) Does Android need a way to query for compatibility between a particular physical device (and queue family?) and a specific Android display?

RESOLVED: No. Currently on Android, any physical device is expected to be able to present to the system compositor, and all queue families must support the necessary image layout transitions and synchronization operations.

Version History
  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft.

  • Revision 2, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_android_surface to VK_KHR_android_surface.

  • Revision 3, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to surface creation function.

  • Revision 4, 2015-11-10 (Jesse Hall)

    • Removed VK_ERROR_INVALID_ANDROID_WINDOW_KHR.

  • Revision 5, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

  • Revision 6, 2016-01-14 (James Jones)

    • Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

VK_KHR_calibrated_timestamps

Name String

VK_KHR_calibrated_timestamps

Extension Type

Device extension

Registered Extension Number

544

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 Enums
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_cooperative_matrix

Name String

VK_KHR_cooperative_matrix

Extension Type

Device extension

Registered Extension Number

507

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Extension Proposal

VK_KHR_cooperative_matrix

Other Extension Metadata
Last Modified Date

2023-05-03

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Markus Tavenrath, NVIDIA

  • Daniel Koch, NVIDIA

  • Kevin Petit, Arm Ltd.

  • Boris Zanin, AMD

Description

This extension adds support for using cooperative matrix types in SPIR-V. Cooperative matrix types are medium-sized matrices that are primarily supported in compute shaders, where the storage for the matrix is spread across all invocations in some scope (usually a subgroup) and those invocations cooperate to efficiently perform matrix multiplies.

Cooperative matrix types are defined by the SPV_KHR_cooperative_matrix SPIR-V extension and can be used with the GLSL_KHR_cooperative_matrix GLSL extension.

This extension includes support for enumerating the matrix types and dimensions that are supported by the implementation.

New Enum Constants
  • VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME

  • VK_KHR_COOPERATIVE_MATRIX_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_KHR

New SPIR-V Capabilities
Issues
Version History
  • Revision 2, 2023-05-03 (Kevin Petit)

    • First KHR revision

  • Revision 1, 2019-02-05 (Jeff Bolz)

    • NVIDIA vendor extension

VK_KHR_deferred_host_operations

Name String

VK_KHR_deferred_host_operations

Extension Type

Device extension

Registered Extension Number

269

Revision

4

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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
New Enum Constants
  • VK_KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME

  • VK_KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR

  • Extending VkResult:

    • VK_OPERATION_DEFERRED_KHR

    • VK_OPERATION_NOT_DEFERRED_KHR

    • VK_THREAD_DONE_KHR

    • VK_THREAD_IDLE_KHR

Code Examples

The following examples will illustrate the concept of deferrable operations using a hypothetical example. The command vkDoSomethingExpensive denotes a deferrable command.

The following example illustrates how a vulkan application might request deferral of an expensive operation:

// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);

result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );

// operation was deferred.  Execute it asynchronously
std::async::launch(
    [ hOp ] ( )
    {
        vkDeferredOperationJoinKHR(device, hOp);

        result = vkGetDeferredOperationResultKHR(device, hOp);

        // deferred operation is now complete.  'result' indicates success or failure

        vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);
    }
);

The following example illustrates extracting concurrency from a single deferred operation:

// create a deferred operation
VkDeferredOperationKHR hOp;
VkResult result = vkCreateDeferredOperationKHR(device, pCallbacks, &hOp);
assert(result == VK_SUCCESS);

result = vkDoSomethingExpensive(device, hOp, ...);
assert( result == VK_OPERATION_DEFERRED_KHR );

// Query the maximum amount of concurrency and clamp to the desired maximum
uint32_t numLaunches = std::min(vkGetDeferredOperationMaxConcurrencyKHR(device, hOp), maxThreads);

std::vector<std::future<void> > joins;

for (uint32_t i = 0; i < numLaunches; i++) {
  joins.emplace_back(std::async::launch(
    [ hOp ] ( )
    {
        vkDeferredOperationJoinKHR(device, hOp);
                // in a job system, a return of VK_THREAD_IDLE_KHR should queue another
                // job, but it is not functionally required
    }
  ));
}

for (auto &f : joins) {
  f.get();
}

result = vkGetDeferredOperationResultKHR(device, hOp);

// deferred operation is now complete.  'result' indicates success or failure

vkDestroyDeferredOperationKHR(device, hOp, pCallbacks);

The following example shows a subroutine which guarantees completion of a deferred operation, in the presence of multiple worker threads, and returns the result of the operation.

VkResult FinishDeferredOperation(VkDeferredOperationKHR hOp)
{
    // Attempt to join the operation until the implementation indicates that we should stop

    VkResult result = vkDeferredOperationJoinKHR(device, hOp);
    while( result == VK_THREAD_IDLE_KHR )
    {
        std::this_thread::yield();
        result = vkDeferredOperationJoinKHR(device, hOp);
    }

    switch( result )
    {
    case VK_SUCCESS:
        {
            // deferred operation has finished.  Query its result.
            result = vkGetDeferredOperationResultKHR(device, hOp);
        }
        break;

    case VK_THREAD_DONE_KHR:
        {
            // deferred operation is being wrapped up by another thread
            //  wait for that thread to finish
            do
            {
                std::this_thread::yield();
                result = vkGetDeferredOperationResultKHR(device, hOp);
            } while( result == VK_NOT_READY );
        }
        break;

    default:
        assert(false); // other conditions are illegal.
        break;
    }

    return result;
}
Issues
  1. Should this extension have a VkPhysicalDevice*FeaturesKHR structure?

RESOLVED: No. This extension does not add any functionality on its own and requires a dependent extension to actually enable functionality and thus there is no value in adding a feature structure. If necessary, any dependent extension could add a feature boolean if it wanted to indicate that it is adding optional deferral support.

Version History
  • Revision 1, 2019-12-05 (Josh Barczak, Daniel Koch)

    • Initial draft.

  • Revision 2, 2020-03-06 (Daniel Koch, Tobias Hector)

    • Add missing VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR enum

    • fix sample code

    • Clarified deferred operation parameter lifetimes (#2018,!3647)

  • Revision 3, 2020-05-15 (Josh Barczak)

    • Clarify behavior of vkGetDeferredOperationMaxConcurrencyKHR, allowing it to return 0 if the operation is complete (#2036,!3850)

  • Revision 4, 2020-11-12 (Tobias Hector, Daniel Koch)

    • Remove VkDeferredOperationInfoKHR and change return value semantics when deferred host operations are in use (#2067,3813)

    • clarify return value of vkGetDeferredOperationResultKHR (#2339,!4110)

VK_KHR_display

Name String

VK_KHR_display

Extension Type

Instance extension

Registered Extension Number

3

Revision

23

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-03-13

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Norbert Nopper, Freescale

  • Jeff Vigil, Qualcomm

  • Daniel Rakos, AMD

Description

This extension provides the API to enumerate displays and available modes on a given device.

New Object Types
New Enum Constants
  • VK_KHR_DISPLAY_EXTENSION_NAME

  • VK_KHR_DISPLAY_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DISPLAY_KHR

    • VK_OBJECT_TYPE_DISPLAY_MODE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR

Issues

1) Which properties of a mode should be fixed in the mode information vs. settable in some other function when setting the mode? E.g., do we need to double the size of the mode pool to include both stereo and non-stereo modes? YUV and RGB scanout even if they both take RGB input images? BGR vs. RGB input? etc.

RESOLVED: Many modern displays support at most a handful of resolutions and timings natively. Other “modes” are expected to be supported using scaling hardware on the display engine or GPU. Other properties, such as rotation and mirroring should not require duplicating hardware modes just to express all combinations. Further, these properties may be implemented on a per-display or per-overlay granularity.

To avoid the exponential growth of modes as mutable properties are added, as was the case with EGLConfig/WGL pixel formats/GLXFBConfig, this specification should separate out hardware properties and configurable state into separate objects. Modes and overlay planes will express capabilities of the hardware, while a separate structure will allow applications to configure scaling, rotation, mirroring, color keys, LUT values, alpha masks, etc. for a given swapchain independent of the mode in use. Constraints on these settings will be established by properties of the immutable objects.

Note the resolution of this issue may affect issue 5 as well.

2) What properties of a display itself are useful?

RESOLVED: This issue is too broad. It was meant to prompt general discussion, but resolving this issue amounts to completing this specification. All interesting properties should be included. The issue will remain as a placeholder since removing it would make it hard to parse existing discussion notes that refer to issues by number.

3) How are multiple overlay planes within a display or mode enumerated?

RESOLVED: They are referred to by an index. Each display will report the number of overlay planes it contains.

4) Should swapchains be created relative to a mode or a display?

RESOLVED: When using this extension, swapchains are created relative to a mode and a plane. The mode implies the display object the swapchain will present to. If the specified mode is not the display’s current mode, the new mode will be applied when the first image is presented to the swapchain, and the default operating system mode, if any, will be restored when the swapchain is destroyed.

5) Should users query generic ranges from displays and construct their own modes explicitly using those constraints rather than querying a fixed set of modes (Most monitors only have one real “mode” these days, even though many support relatively arbitrary scaling, either on the monitor side or in the GPU display engine, making “modes” something of a relic/compatibility construct).

RESOLVED: Expose both. Display information structures will expose a set of predefined modes, as well as any attributes necessary to construct a customized mode.

6) Is it fine if we return the display and display mode handles in the structure used to query their properties?

RESOLVED: Yes.

7) Is there a possibility that not all displays of a device work with all of the present queues of a device? If yes, how do we determine which displays work with which present queues?

RESOLVED: No known hardware has such limitations, but determining such limitations is supported automatically using the existing VK_KHR_surface and VK_KHR_swapchain query mechanisms.

8) Should all presentation need to be done relative to an overlay plane, or can a display mode + display be used alone to target an output?

RESOLVED: Require specifying a plane explicitly.

9) Should displays have an associated window system display, such as an HDC or Display*?

RESOLVED: No. Displays are independent of any windowing system in use on the system. Further, neither HDC nor Display* refer to a physical display object.

10) Are displays queried from a physical GPU or from a device instance?

RESOLVED: Developers prefer to query modes directly from the physical GPU so they can use display information as an input to their device selection algorithms prior to device creation. This avoids the need to create placeholder device instances to enumerate displays.

This preference must be weighed against the extra initialization that must be done by driver vendors prior to device instance creation to support this usage.

11) Should displays and/or modes be dispatchable objects? If functions are to take displays, overlays, or modes as their first parameter, they must be dispatchable objects as defined in Khronos bug 13529. If they are not added to the list of dispatchable objects, functions operating on them must take some higher-level object as their first parameter. There is no performance case against making them dispatchable objects, but they would be the first extension objects to be dispatchable.

RESOLVED: Do not make displays or modes dispatchable. They will dispatch based on their associated physical device.

12) Should hardware cursor capabilities be exposed?

RESOLVED: Defer. This could be a separate extension on top of the base WSI specs.

13) How many display objects should be enumerated for "tiled" display devices? There are ongoing design discussions among lower-level display API authors regarding how to expose displays if they are one physical display device to an end user, but may internally be implemented as two side-by-side displays using the same display engine (and sometimes cabling) resources as two physically separate display devices.

RESOLVED: Tiled displays will appear as a single display object in this API.

14) Should the raw EDID data be included in the display information?

RESOLVED: No. A future extension could be added which reports the EDID if necessary. This may be complicated by the outcome of issue 13.

15) Should min and max scaling factor capabilities of overlays be exposed?

RESOLVED: Yes. This is exposed indirectly by allowing applications to query the min/max position and extent of the source and destination regions from which image contents are fetched by the display engine when using a particular mode and overlay pair.

16) Should devices be able to expose planes that can be moved between displays? If so, how?

RESOLVED: Yes. Applications can determine which displays a given plane supports using vkGetDisplayPlaneSupportedDisplaysKHR.

17) Should there be a way to destroy display modes? If so, does it support destroying “built in” modes?

RESOLVED: Not in this extension. A future extension could add this functionality.

18) What should the lifetime of display and built-in display mode objects be?

RESOLVED: The lifetime of the instance. These objects cannot be destroyed. A future extension may be added to expose a way to destroy these objects and/or support display hotplug.

19) Should persistent mode for smart panels be enabled/disabled at swapchain creation time, or on a per-present basis.

RESOLVED: On a per-present basis.

Examples
Note

The example code for the 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: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c).

Version History
  • Revision 1, 2015-02-24 (James Jones)

    • Initial draft

  • Revision 2, 2015-03-12 (Norbert Nopper)

    • Added overlay enumeration for a display.

  • Revision 3, 2015-03-17 (Norbert Nopper)

    • Fixed typos and namings as discussed in Bugzilla.

    • Reordered and grouped functions.

    • Added functions to query count of display, mode and overlay.

    • Added native display handle, which may be needed on some platforms to create a native Window.

  • Revision 4, 2015-03-18 (Norbert Nopper)

    • Removed primary and virtualPostion members (see comment of James Jones in Bugzilla).

    • Added native overlay handle to information structure.

    • Replaced , with ; in struct.

  • Revision 6, 2015-03-18 (Daniel Rakos)

    • Added WSI extension suffix to all items.

    • Made the whole API more “Vulkanish”.

    • Replaced all functions with a single vkGetDisplayInfoKHR function to better match the rest of the API.

    • Made the display, display mode, and overlay objects be first class objects, not subclasses of VkBaseObject as they do not support the common functions anyways.

    • Renamed *Info structures to *Properties.

    • Removed overlayIndex field from VkOverlayProperties as there is an implicit index already as a result of moving to a “Vulkanish” API.

    • Displays are not get through device, but through physical GPU to match the rest of the Vulkan API. Also this is something ISVs explicitly requested.

    • Added issue (6) and (7).

  • Revision 7, 2015-03-25 (James Jones)

    • Added an issues section

    • Added rotation and mirroring flags

  • Revision 8, 2015-03-25 (James Jones)

    • Combined the duplicate issues sections introduced in last change.

    • Added proposed resolutions to several issues.

  • Revision 9, 2015-04-01 (Daniel Rakos)

    • Rebased extension against Vulkan 0.82.0

  • Revision 10, 2015-04-01 (James Jones)

    • Added issues (10) and (11).

    • Added more straw-man issue resolutions, and cleaned up the proposed resolution for issue (4).

    • Updated the rotation and mirroring enums to have proper bitmask semantics.

  • Revision 11, 2015-04-15 (James Jones)

    • Added proposed resolution for issues (1) and (2).

    • Added issues (12), (13), (14), and (15)

    • Removed pNativeHandle field from overlay structure.

    • Fixed small compilation errors in example code.

  • Revision 12, 2015-07-29 (James Jones)

    • Rewrote the guts of the extension against the latest WSI swapchain specifications and the latest Vulkan API.

    • Address overlay planes by their index rather than an object handle and refer to them as “planes” rather than “overlays” to make it slightly clearer that even a display with no “overlays” still has at least one base “plane” that images can be displayed on.

    • Updated most of the issues.

    • Added an “extension type” section to the specification header.

    • Reused the VK_EXT_KHR_surface surface transform enumerations rather than redefining them here.

    • Updated the example code to use the new semantics.

  • Revision 13, 2015-08-21 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.

  • Revision 14, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 15, 2015-09-08 (James Jones)

    • Added alpha flags enum.

    • Added premultiplied alpha support.

  • Revision 16, 2015-09-08 (James Jones)

    • Added description section to the spec.

    • Added issues 16 - 18.

  • Revision 17, 2015-10-02 (James Jones)

    • Planes are now a property of the entire device rather than individual displays. This allows planes to be moved between multiple displays on devices that support it.

    • Added a function to create a VkSurfaceKHR object describing a display plane and mode to align with the new per-platform surface creation conventions.

    • Removed detailed mode timing data. It was agreed that the mode extents and refresh rate are sufficient for current use cases. Other information could be added back in as an extension if it is needed in the future.

    • Added support for smart/persistent/buffered display devices.

  • Revision 18, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_display to VK_KHR_display.

  • Revision 19, 2015-11-02 (James Jones)

    • Updated example code to match revision 17 changes.

  • Revision 20, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to creation functions.

  • Revision 21, 2015-11-10 (Jesse Hall)

    • Added VK_DISPLAY_PLANE_ALPHA_OPAQUE_BIT_KHR, and use VkDisplayPlaneAlphaFlagBitsKHR for VkDisplayPlanePropertiesKHR::alphaMode instead of VkDisplayPlaneAlphaFlagsKHR, since it only represents one mode.

    • Added reserved flags bitmask to VkDisplayPlanePropertiesKHR.

    • Use VkSurfaceTransformFlagBitsKHR instead of obsolete VkSurfaceTransformKHR.

    • Renamed vkGetDisplayPlaneSupportedDisplaysKHR parameters for clarity.

  • Revision 22, 2015-12-18 (James Jones)

    • Added missing “planeIndex” parameter to vkGetDisplayPlaneSupportedDisplaysKHR()

  • Revision 23, 2017-03-13 (James Jones)

    • Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.

    • Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.

VK_KHR_display_swapchain

Name String

VK_KHR_display_swapchain

Extension Type

Device extension

Registered Extension Number

4

Revision

10

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-03-13

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Vigil, Qualcomm

  • Jesse Hall, Google

Description

This extension provides an API to create a swapchain directly on a device’s display without any underlying window system.

New Structures
New Enum Constants
  • VK_KHR_DISPLAY_SWAPCHAIN_EXTENSION_NAME

  • VK_KHR_DISPLAY_SWAPCHAIN_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_INCOMPATIBLE_DISPLAY_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR

Issues

1) Should swapchains sharing images each hold a reference to the images, or should it be up to the application to destroy the swapchains and images in an order that avoids the need for reference counting?

RESOLVED: Take a reference. The lifetime of presentable images is already complex enough.

2) Should the srcRect and dstRect parameters be specified as part of the presentation command, or at swapchain creation time?

RESOLVED: As part of the presentation command. This allows moving and scaling the image on the screen without the need to respecify the mode or create a new swapchain and presentable images.

3) Should srcRect and dstRect be specified as rects, or separate offset/extent values?

RESOLVED: As rects. Specifying them separately might make it easier for hardware to expose support for one but not the other, but in such cases applications must just take care to obey the reported capabilities and not use non-zero offsets or extents that require scaling, as appropriate.

4) How can applications create multiple swapchains that use the same images?

RESOLVED: By calling vkCreateSharedSwapchainsKHR.

An earlier resolution used vkCreateSwapchainKHR, chaining multiple VkSwapchainCreateInfoKHR structures through pNext. In order to allow each swapchain to also allow other extension structs, a level of indirection was used: VkSwapchainCreateInfoKHR::pNext pointed to a different structure, which had both sType and pNext members for additional extensions, and also had a pointer to the next VkSwapchainCreateInfoKHR structure. The number of swapchains to be created could only be found by walking this linked list of alternating structures, and the pSwapchains out parameter was reinterpreted to be an array of VkSwapchainKHR handles.

Another option considered was a method to specify a “shared” swapchain when creating a new swapchain, such that groups of swapchains using the same images could be built up one at a time. This was deemed unusable because drivers need to know all of the displays an image will be used on when determining which internal formats and layouts to use for that image.

Examples
Note

The example code for the 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: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c).

Version History
  • Revision 1, 2015-07-29 (James Jones)

    • Initial draft

  • Revision 2, 2015-08-21 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.

  • Revision 3, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 4, 2015-09-08 (James Jones)

    • Allow creating multiple swapchains that share the same images using a single call to vkCreateSwapchainKHR().

  • Revision 5, 2015-09-10 (Alon Or-bach)

    • Removed underscores from SWAP_CHAIN in two enums.

  • Revision 6, 2015-10-02 (James Jones)

    • Added support for smart panels/buffered displays.

  • Revision 7, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_display_swapchain to VK_KHR_display_swapchain.

  • Revision 8, 2015-11-03 (Daniel Rakos)

    • Updated sample code based on the changes to VK_KHR_swapchain.

  • Revision 9, 2015-11-10 (Jesse Hall)

    • Replaced VkDisplaySwapchainCreateInfoKHR with vkCreateSharedSwapchainsKHR, changing resolution of issue #4.

  • Revision 10, 2017-03-13 (James Jones)

    • Closed all remaining issues. The specification and implementations have been shipping with the proposed resolutions for some time now.

    • Removed the sample code and noted it has been integrated into the official Vulkan SDK cube demo.

VK_KHR_dynamic_rendering_local_read

Name String

VK_KHR_dynamic_rendering_local_read

Extension Type

Device extension

Registered Extension Number

233

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 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

Version History
  • Revision 1, 2023-11-03 (Tobias Hector)

    • Initial revision

VK_KHR_external_fence_fd

Name String

VK_KHR_external_fence_fd

Extension Type

Device extension

Registered Extension Number

116

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Contributors
Description

An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from POSIX file descriptors.

New Enum Constants
  • VK_KHR_EXTERNAL_FENCE_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_FD_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FENCE_GET_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR

Issues

This extension borrows concepts, semantics, and language from VK_KHR_external_semaphore_fd. That extension’s issues apply equally to this extension.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Contributors
Description

An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to export fence payload to and import fence payload from Windows handles.

New Enum Constants
  • VK_KHR_EXTERNAL_FENCE_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_WIN32_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR

Issues

This extension borrows concepts, semantics, and language from VK_KHR_external_semaphore_win32. That extension’s issues apply equally to this extension.

1) Should D3D12 fence handle types be supported, like they are for semaphores?

RESOLVED: No. Doing so would require extending the fence signal and wait operations to provide values to signal / wait for, like VkD3D12FenceSubmitInfoKHR does. A D3D12 fence can be signaled by importing it into a VkSemaphore instead of a VkFence, and applications can check status or wait on the D3D12 fence using non-Vulkan APIs. The convenience of being able to do these operations on VkFence objects does not justify the extra API complexity.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export POSIX file descriptor handles from Vulkan memory objects and to import Vulkan memory objects from POSIX file descriptor handles exported from other Vulkan memory objects or from similar resources in other APIs.

New Enum Constants
  • VK_KHR_EXTERNAL_MEMORY_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_FD_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR

Issues

1) Does the application need to close the file descriptor returned by vkGetMemoryFdKHR?

RESOLVED: Yes, unless it is passed back in to a driver instance to import the memory. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original memory object will not close the file descriptor or remove its reference to the underlying memory resource associated with it.

2) Do drivers ever need to expose multiple file descriptors per memory object?

RESOLVED: No. This would indicate there are actually multiple memory objects, rather than a single memory object.

3) How should the valid size and memory type for POSIX file descriptor memory handles created outside of Vulkan be specified?

RESOLVED: The valid memory types are queried directly from the external handle. The size will be specified by future extensions that introduce such external memory handle types.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export Windows handles from Vulkan memory objects and to import Vulkan memory objects from Windows handles exported from other Vulkan memory objects or from similar resources in other APIs.

New Enum Constants
  • VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_WIN32_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR

Issues

1) Do applications need to call CloseHandle() on the values returned from vkGetMemoryWin32HandleKHR when handleType is VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?

RESOLVED: Yes. A successful get call transfers ownership of the handle to the application. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource. Unlike file descriptor opaque handles, win32 opaque handle ownership can not be transferred back to a driver by an import operation.

2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?

RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.

3) How should the valid size and memory type for windows memory handles created outside of Vulkan be specified?

RESOLVED: The valid memory types are queried directly from the external handle. The size is determined by the associated image or buffer memory requirements for external handle types that require dedicated allocations, and by the size specified when creating the object from which the handle was exported for other external handle types.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

Description

An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to export semaphore payload to and import semaphore payload from POSIX file descriptors.

New Enum Constants
  • VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_FD_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR

Issues

1) Does the application need to close the file descriptor returned by vkGetSemaphoreFdKHR?

RESOLVED: Yes, unless it is passed back in to a driver instance to import the semaphore. A successful get call transfers ownership of the file descriptor to the application, and a successful import transfers it back to the driver. Destroying the original semaphore object will not close the file descriptor or remove its reference to the underlying semaphore resource associated with it.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

Description

An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to export semaphore payload to and import semaphore payload from Windows handles.

New Enum Constants
  • VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_WIN32_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR

Issues

1) Do applications need to call CloseHandle() on the values returned from vkGetSemaphoreWin32HandleKHR when handleType is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR?

RESOLVED: Yes. A successful get call transfers ownership of the handle to the application. Destroying the semaphore object will not destroy the handle or the handle’s reference to the underlying semaphore resource. Unlike file descriptor opaque handles, win32 opaque handle ownership can not be transferred back to a driver by an import operation.

2) Should the language regarding KMT/Windows 7 handles be moved to a separate extension so that it can be deprecated over time?

RESOLVED: No. Support for them can be deprecated by drivers if they choose, by no longer returning them in the supported handle types of the instance level queries.

3) Should applications be allowed to specify additional object attributes for shared handles?

RESOLVED: Yes. Applications will be allowed to provide similar attributes to those they would to any other handle creation API.

4) How do applications communicate the desired fence values to use with D3D12_FENCE-based Vulkan semaphores?

RESOLVED: There are a couple of options. The values for the signaled and reset states could be communicated up front when creating the object and remain static for the life of the Vulkan semaphore, or they could be specified using auxiliary structures when submitting semaphore signal and wait operations, similar to what is done with the keyed mutex extensions. The latter is more flexible and consistent with the keyed mutex usage, but the former is a much simpler API.

Since Vulkan tends to favor flexibility and consistency over simplicity, a new structure specifying D3D12 fence acquire and release values is added to the vkQueueSubmit function.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
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
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:

The extension provides access to three additional fragment shader variable decorations in SPIR-V:

  • PerVertexKHR, which indicates that a fragment shader input will not have interpolated values, but instead must be accessed with an extra array index that identifies one of the vertices of the primitive producing the fragment

  • BaryCoordKHR, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using perspective interpolation

  • BaryCoordNoPerspKHR, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using linear interpolation

When using GLSL source-based shader languages, the following variables from GL_EXT_fragment_shader_barycentric map to these SPIR-V built-in decorations:

  • in vec3 gl_BaryCoordEXT;BaryCoordKHR

  • in vec3 gl_BaryCoordNoPerspEXT;BaryCoordNoPerspKHR

GLSL variables declared using the pervertexEXT GLSL qualifier are expected to be decorated with PerVertexKHR in SPIR-V.

New Enum Constants
  • VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME

  • VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_PROPERTIES_KHR

New Built-In Variables
New SPIR-V Decorations
New SPIR-V Capabilities
Issues

1) What are the interactions with MSAA and how are BaryCoordKHR and BaryCoordNoPerspKHR interpolated?

RESOLVED: The inputs decorated with BaryCoordKHR or BaryCoordNoPerspKHR may also be decorated with the Centroid or Sample qualifiers to specify interpolation, like any other fragment shader input. If shaderSampleRateInterpolationFunctions is enabled, the extended instructions InterpolateAtCentroid, InterpolateAtOffset, and InterpolateAtSample from the GLSL.std.450 may also be used with inputs decorated with BaryCoordKHR or BaryCoordNoPerspKHR.

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

2

Ratification Status

Ratified

Extension and Version Dependencies

         VK_KHR_get_physical_device_properties2
         or
         Version 1.1
     and
     VK_KHR_create_renderpass2
or
Version 1.2

API Interactions
  • Interacts with VK_VERSION_1_3

  • Interacts with VK_KHR_format_feature_flags2

SPIR-V Dependencies
Contact
Extension Proposal

VK_KHR_fragment_shading_rate

Other Extension Metadata
Last Modified Date

2021-09-30

Interactions and External Dependencies
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:

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

Version History
  • Revision 1, 2020-05-06 (Tobias Hector)

    • Initial revision

  • Revision 2, 2021-09-30 (Jon Leech)

VK_KHR_get_display_properties2

Name String

VK_KHR_get_display_properties2

Extension Type

Instance extension

Registered Extension Number

122

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-02-21

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • James Jones, NVIDIA

Description

This extension provides new queries for device display properties and capabilities that can be easily extended by other extensions, without introducing any further queries. This extension can be considered the VK_KHR_display equivalent of the VK_KHR_get_physical_device_properties2 extension.

New Enum Constants
  • VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME

  • VK_KHR_GET_DISPLAY_PROPERTIES_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_MODE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_CAPABILITIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PLANE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_DISPLAY_PROPERTIES_2_KHR

Issues

1) What should this extension be named?

RESOLVED: VK_KHR_get_display_properties2. Other alternatives:

  • VK_KHR_display2

  • One extension, combined with VK_KHR_surface_capabilites2.

2) Should extensible input structs be added for these new functions:

RESOLVED:

3) Should additional display query functions be extended?

RESOLVED:

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-02-27

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • James Jones, NVIDIA

  • Alon Or-bach, Samsung

Description

This extension provides new queries for device surface capabilities that can be easily extended by other extensions, without introducing any further queries. This extension can be considered the VK_KHR_surface equivalent of the VK_KHR_get_physical_device_properties2 extension.

New Enum Constants
  • VK_KHR_GET_SURFACE_CAPABILITIES_2_EXTENSION_NAME

  • VK_KHR_GET_SURFACE_CAPABILITIES_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR

    • VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR

Issues

1) What should this extension be named?

RESOLVED: VK_KHR_get_surface_capabilities2. Other alternatives:

  • VK_KHR_surface2

  • One extension, combining a separate display-specific query extension.

2) Should additional WSI query functions be extended?

RESOLVED:

Version History
  • Revision 1, 2017-02-27 (James Jones)

    • Initial draft.

VK_KHR_global_priority

Name String

VK_KHR_global_priority

Extension Type

Device extension

Registered Extension Number

189

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2021-10-22

Contributors
  • Tobias Hector, AMD

  • Contributors to VK_EXT_global_priority

  • Contributors to VK_EXT_global_priority_query

Description

In Vulkan, users can specify device-scope queue priorities. In some cases it may be useful to extend this concept to a system-wide scope. This device extension allows applications to query the global queue priorities supported by a queue family, and then set a priority when creating queues. The default queue priority is VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT.

Implementations can report which global priority levels are treated differently by the implementation. It is intended primarily for use in system integration along with certain platform-specific priority enforcement rules.

The driver implementation will attempt to skew hardware resource allocation in favor of the higher-priority task. Therefore, higher-priority work may retain similar latency and throughput characteristics even if the system is congested with lower priority work.

The global priority level of a queue shall take precedence over the per-process queue priority (VkDeviceQueueCreateInfo::pQueuePriorities).

Abuse of this feature may result in starving the rest of the system from hardware resources. Therefore, the driver implementation may deny requests to acquire a priority above the default priority (VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT) if the caller does not have sufficient privileges. In this scenario VK_ERROR_NOT_PERMITTED_EXT is returned.

The driver implementation may fail the queue allocation request if resources required to complete the operation have been exhausted (either by the same process or a different process). In this scenario VK_ERROR_INITIALIZATION_FAILED is returned.

New Enum Constants
  • VK_KHR_GLOBAL_PRIORITY_EXTENSION_NAME

  • VK_KHR_GLOBAL_PRIORITY_SPEC_VERSION

  • VK_MAX_GLOBAL_PRIORITY_SIZE_KHR

  • Extending VkResult:

    • VK_ERROR_NOT_PERMITTED_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_KHR

Issues

1) Can we additionally query whether a caller is permitted to acquire a specific global queue priority in this extension?

RESOLVED: No. Whether a caller has enough privilege goes with the OS, and the Vulkan driver cannot really guarantee that the privilege will not change in between this query and the actual queue creation call.

2) If more than 1 queue using global priority is requested, is there a good way to know which queue is failing the device creation?

RESOLVED: No. There is not a good way at this moment, and it is also not quite actionable for the applications to know that because the information may not be accurate. Queue creation can fail because of runtime constraints like insufficient privilege or lack of resource, and the failure is not necessarily tied to that particular queue configuration requested.

Version History
  • Revision 1, 2021-10-22 (Tobias Hector)

    • Initial draft

VK_KHR_incremental_present

Name String

VK_KHR_incremental_present

Extension Type

Device extension

Registered Extension Number

85

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-11-02

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • Jesse Hall, Google

  • Alon Or-bach, Samsung

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Ray Smith, ARM

  • Mika Isojarvi, Google

  • Jeff Juliano, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This device extension extends vkQueuePresentKHR, from the VK_KHR_swapchain extension, allowing an application to specify a list of rectangular, modified regions of each image to present. This should be used in situations where an application is only changing a small portion of the presentable images within a swapchain, since it enables the presentation engine to avoid wasting time presenting parts of the surface that have not changed.

This extension is leveraged from the EGL_KHR_swap_buffers_with_damage extension.

New Enum Constants
  • VK_KHR_INCREMENTAL_PRESENT_EXTENSION_NAME

  • VK_KHR_INCREMENTAL_PRESENT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR

Issues

1) How should we handle steroescopic-3D swapchains? We need to add a layer for each rectangle. One approach is to create another struct containing the VkRect2D plus layer, and have VkPresentRegionsKHR point to an array of that struct. Another approach is to have two parallel arrays, pRectangles and pLayers, where pRectangles[i] and pLayers[i] must be used together. Which approach should we use, and if the array of a new structure, what should that be called?

RESOLVED: Create a new structure, which is a VkRect2D plus a layer, and will be called VkRectLayerKHR.

2) Where is the origin of the VkRectLayerKHR?

RESOLVED: The upper left corner of the presentable image(s) of the swapchain, per the definition of framebuffer coordinates.

3) Does the rectangular region, VkRectLayerKHR, specify pixels of the swapchain’s image(s), or of the surface?

RESOLVED: Of the image(s). Some presentation engines may scale the pixels of a swapchain’s image(s) to the size of the surface. The size of the swapchain’s image(s) will be consistent, where the size of the surface may vary over time.

4) What if all of the rectangles for a given swapchain contain a width and/or height of zero?

RESOLVED: The application is indicating that no pixels changed since the last present. The presentation engine may use such a hint and not update any pixels for the swapchain. However, all other semantics of vkQueuePresentKHR must still be honored, including waiting for semaphores to signal.

5) When the swapchain is created with VkSwapchainCreateInfoKHR::preTransform set to a value other than VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR, should the rectangular region, VkRectLayerKHR, be transformed to align with the preTransform?

RESOLVED: No. The rectangular region in VkRectLayerKHR should not be transformed. As such, it may not align with the extents of the swapchain’s image(s). It is the responsibility of the presentation engine to transform the rectangular region. This matches the behavior of the Android presentation engine, which set the precedent.

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_index_type_uint8

Name String

VK_KHR_index_type_uint8

Extension Type

Device extension

Registered Extension Number

534

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2023-06-06

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension allows uint8_t indices to be used with vkCmdBindIndexBuffer.

New Enum Constants
  • VK_KHR_INDEX_TYPE_UINT8_EXTENSION_NAME

  • VK_KHR_INDEX_TYPE_UINT8_SPEC_VERSION

  • Extending VkIndexType:

    • VK_INDEX_TYPE_UINT8_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_KHR

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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
New Enum Constants
  • VK_KHR_LINE_RASTERIZATION_EXTENSION_NAME

  • VK_KHR_LINE_RASTERIZATION_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_LINE_STIPPLE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_KHR

Issues

1) Do we need to support Bresenham-style and smooth lines with more than one rasterization sample? i.e. the equivalent of glDisable(GL_MULTISAMPLE) in OpenGL when the framebuffer has more than one sample?

RESOLVED: Yes. For simplicity, Bresenham line rasterization carries forward a few restrictions from OpenGL, such as not supporting per-sample shading, alpha to coverage, or alpha to one.

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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

Version History
  • Revision 1, 2023-05-16 (Shahbaz Youssefi)

    • Initial revision, based on VK_EXT_load_store_op_none.

VK_KHR_maintenance5

Name String

VK_KHR_maintenance5

Extension Type

Device extension

Registered Extension Number

471

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

     Version 1.1
     and
     VK_KHR_dynamic_rendering
or
Version 1.3

API Interactions
  • Interacts with VK_VERSION_1_1

  • Interacts with VK_VERSION_1_2

  • Interacts with VK_VERSION_1_3

  • Interacts with VK_EXT_attachment_feedback_loop_layout

  • Interacts with VK_EXT_buffer_device_address

  • Interacts with VK_EXT_conditional_rendering

  • Interacts with VK_EXT_descriptor_buffer

  • Interacts with VK_EXT_fragment_density_map

  • Interacts with VK_EXT_graphics_pipeline_library

  • Interacts with VK_EXT_opacity_micromap

  • Interacts with VK_EXT_pipeline_creation_cache_control

  • Interacts with VK_EXT_pipeline_protected_access

  • Interacts with VK_EXT_transform_feedback

  • Interacts with VK_KHR_acceleration_structure

  • Interacts with VK_KHR_buffer_device_address

  • Interacts with VK_KHR_device_group

  • Interacts with VK_KHR_dynamic_rendering

  • Interacts with VK_KHR_fragment_shading_rate

  • Interacts with VK_KHR_pipeline_executable_properties

  • Interacts with VK_KHR_pipeline_library

  • Interacts with VK_KHR_ray_tracing_pipeline

  • Interacts with VK_KHR_video_decode_queue

  • Interacts with VK_KHR_video_encode_queue

  • Interacts with VK_NV_device_generated_commands

  • Interacts with VK_NV_displacement_micromap

  • Interacts with VK_NV_ray_tracing

  • Interacts with VK_NV_ray_tracing_motion_blur

Contact
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 entry point vkCmdBindIndexBuffer2KHR, allowing a range of memory to be bound as an index buffer

  • vkGetDeviceProcAddr must return NULL for supported core functions beyond the version requested by the application.

  • A property to indicate that the sample mask test is performed after sample counting in EarlyFragmentTests mode

  • vkCmdBindVertexBuffers2 now supports 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 struct to pipeline creation via VkPipelineShaderStageCreateInfo

  • A function vkGetRenderingAreaGranularityKHR to query the optimal render area for a dynamic rendering instance.

  • A property to indicate that depth/stencil texturing operations with VK_COMPONENT_SWIZZLE_ONE have defined behavior

  • Add vkGetImageSubresourceLayout2KHR and a new function vkGetDeviceImageSubresourceLayoutKHR to allow the application to query the image memory layout without having to create an image object and query it.

  • Allow VK_REMAINING_ARRAY_LAYERS as 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 Enum Constants
  • VK_KHR_MAINTENANCE_5_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_5_SPEC_VERSION

  • Extending VkFormat:

    • VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR

    • VK_FORMAT_A8_UNORM_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_USAGE_FLAGS_2_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_IMAGE_SUBRESOURCE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_5_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_CREATE_FLAGS_2_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_AREA_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_KHR

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

    • VK_PIPELINE_CREATE_2_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT

If VK_EXT_opacity_micromap is supported:

If VK_EXT_transform_feedback is supported:

  • Extending VkBufferUsageFlagBits2KHR:

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

  • Extending VkBufferUsageFlagBits2KHR:

    • VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR

    • VK_BUFFER_USAGE_2_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR

    • VK_PIPELINE_CREATE_2_CAPTURE_STATISTICS_BIT_KHR

If VK_KHR_pipeline_library is supported:

If VK_KHR_ray_tracing_pipeline is supported:

  • Extending VkBufferUsageFlagBits2KHR:

    • VK_BUFFER_USAGE_2_SHADER_BINDING_TABLE_BIT_KHR

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_AABBS_BIT_KHR

    • VK_PIPELINE_CREATE_2_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR

If VK_KHR_video_decode_queue is supported:

If VK_KHR_video_encode_queue is supported:

If Version 1.1 or VK_KHR_device_group is supported:

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_DISPATCH_BASE_BIT_KHR

    • VK_PIPELINE_CREATE_2_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

If Version 1.2 or VK_KHR_buffer_device_address or VK_EXT_buffer_device_address is supported:

If Version 1.3 or VK_EXT_pipeline_creation_cache_control is supported:

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_EARLY_RETURN_ON_FAILURE_BIT_KHR

    • VK_PIPELINE_CREATE_2_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_KHR

Issues

None.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_EXT_descriptor_buffer

  • Interacts with VK_KHR_push_descriptor

Contact
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′CBCR 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 Enum Constants
  • VK_KHR_MAINTENANCE_6_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_6_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_SETS_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_MEMORY_STATUS_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_6_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PUSH_CONSTANTS_INFO_KHR

If VK_KHR_push_descriptor is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_INFO_KHR

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_WITH_TEMPLATE_INFO_KHR

Issues

None.

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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 entry points. The new entry points are functionally identical to the core entry points, except that their parameters are specified using extensible structures that can be used to pass extension-specific information.

New Bitmasks
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

Version History
  • Revision 0, 2022-08-03 (Faith Ekstrand)

    • Internal revisions

  • Revision 1, 2023-03-14

    • Public release

VK_KHR_performance_query

Name String

VK_KHR_performance_query

Extension Type

Device extension

Registered Extension Number

117

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Special Use
Contact
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 Enum Constants
  • VK_KHR_PERFORMANCE_QUERY_EXTENSION_NAME

  • VK_KHR_PERFORMANCE_QUERY_SPEC_VERSION

  • Extending VkQueryType:

    • VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_DESCRIPTION_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_KHR

    • VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR

Issues

1) Should this extension include a mechanism to begin a query in command buffer A and end the query in command buffer B?

RESOLVED No - queries are tied to command buffer creation and thus have to be encapsulated within a single command buffer.

2) Should this extension include a mechanism to begin and end queries globally on the queue, not using the existing command buffer commands?

RESOLVED No - for the same reasoning as the resolution of 1).

3) Should this extension expose counters that require multiple passes?

RESOLVED Yes - users should re-submit a command buffer with the same commands in it multiple times, specifying the pass to count as the query parameter in VkPerformanceQuerySubmitInfoKHR.

4) How to handle counters across parallel workloads?

RESOLVED In the spirit of Vulkan, a counter description flag VK_PERFORMANCE_COUNTER_DESCRIPTION_CONCURRENTLY_IMPACTED_BIT_KHR denotes that the accuracy of a counter result is affected by parallel workloads.

5) How to handle secondary command buffers?

RESOLVED Secondary command buffers inherit any counter pass index specified in the parent primary command buffer. Note: this is no longer an issue after change from issue 10 resolution

6) What commands does the profiling lock have to be held for?

RESOLVED For any command buffer that is being queried with a performance query pool, the profiling lock must be held while that command buffer is in the recording, executable, or pending state.

7) Should we support vkCmdCopyQueryPoolResults?

RESOLVED Yes.

8) Should we allow performance queries to interact with multiview?

RESOLVED Yes, but the performance queries must be performed once for each pass per view.

9) Should a queryCount > 1 be usable for performance queries?

RESOLVED Yes. Some vendors will have costly performance counter query pool creation, and would rather if a certain set of counters were to be used multiple times that a queryCount > 1 can be used to amortize the instantiation cost.

10) Should we introduce an indirect mechanism to set the counter pass index?

RESOLVED Specify the counter pass index at submit time instead, to avoid requiring re-recording of command buffers when multiple counter passes are needed.

Examples

The following example shows how to find what performance counters a queue family supports, setup a query pool to record these performance counters, how to add the query pool to the command buffer to record information, and how to get the results from the query pool.

// A previously created physical device
VkPhysicalDevice physicalDevice;

// One of the queue families our device supports
uint32_t queueFamilyIndex;

uint32_t counterCount;

// Get the count of counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
  physicalDevice,
  queueFamilyIndex,
  &counterCount,
  NULL,
  NULL);

VkPerformanceCounterKHR* counters =
  malloc(sizeof(VkPerformanceCounterKHR) * counterCount);
VkPerformanceCounterDescriptionKHR* counterDescriptions =
  malloc(sizeof(VkPerformanceCounterDescriptionKHR) * counterCount);

// Get the counters supported
vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR(
  physicalDevice,
  queueFamilyIndex,
  &counterCount,
  counters,
  counterDescriptions);

// Try to enable the first 8 counters
uint32_t enabledCounters[8];

const uint32_t enabledCounterCount = min(counterCount, 8));

for (uint32_t i = 0; i < enabledCounterCount; i++) {
  enabledCounters[i] = i;
}

// A previously created device that had the performanceCounterQueryPools feature
// set to VK_TRUE
VkDevice device;

VkQueryPoolPerformanceCreateInfoKHR performanceQueryCreateInfo = {
  .sType = VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR,
  .pNext = NULL,

  // Specify the queue family that this performance query is performed on
  .queueFamilyIndex = queueFamilyIndex,

  // The number of counters to enable
  .counterIndexCount = enabledCounterCount,

  // The array of indices of counters to enable
  .pCounterIndices = enabledCounters
};


// Get the number of passes our counters will require.
uint32_t numPasses;

vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR(
  physicalDevice,
  &performanceQueryCreateInfo,
  &numPasses);

VkQueryPoolCreateInfo queryPoolCreateInfo = {
  .sType = VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
  .pNext = &performanceQueryCreateInfo,
  .flags = 0,
  // Using our new query type here
  .queryType = VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR,
  .queryCount = 1,
  .pipelineStatistics = 0
};

VkQueryPool queryPool;

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

assert(VK_SUCCESS == result);

// A queue from queueFamilyIndex
VkQueue queue;

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

VkCommandBufferBeginInfo commandBufferBeginInfo = {
  .sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
  .pNext = NULL,
  .flags = 0,
  .pInheritanceInfo = NULL
};

VkAcquireProfilingLockInfoKHR lockInfo = {
  .sType = VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR,
  .pNext = NULL,
  .flags = 0,
  .timeout = UINT64_MAX // Wait forever for the lock
};

// Acquire the profiling lock before we record command buffers
// that will use performance queries

result = vkAcquireProfilingLockKHR(device, &lockInfo);

assert(VK_SUCCESS == result);

result = vkBeginCommandBuffer(commandBuffer, &commandBufferBeginInfo);

assert(VK_SUCCESS == result);

vkCmdResetQueryPool(
  commandBuffer,
  queryPool,
  0,
  1);

vkCmdBeginQuery(
  commandBuffer,
  queryPool,
  0,
  0);

// Perform the commands you want to get performance information on
// ...

// Perform a barrier to ensure all previous commands were complete before
// ending the query
vkCmdPipelineBarrier(commandBuffer,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,
  0,
  0,
  NULL,
  0,
  NULL,
  0,
  NULL);

vkCmdEndQuery(
  commandBuffer,
  queryPool,
  0);

result = vkEndCommandBuffer(commandBuffer);

assert(VK_SUCCESS == result);

for (uint32_t counterPass = 0; counterPass < numPasses; counterPass++) {

  VkPerformanceQuerySubmitInfoKHR performanceQuerySubmitInfo = {
    VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR,
    NULL,
    counterPass
  };


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

// Release the profiling lock after the command buffer is no longer in the
// pending state.
vkReleaseProfilingLockKHR(device);

result = vkResetCommandBuffer(commandBuffer, 0);

assert(VK_SUCCESS == result);

// Create an array to hold the results of all counters
VkPerformanceCounterResultKHR* recordedCounters = malloc(
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount);

result = vkGetQueryPoolResults(
  device,
  queryPool,
  0,
  1,
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
  recordedCounters,
  sizeof(VkPerformanceCounterResultKHR) * enabledCounterCount,
  NULL);

// recordedCounters is filled with our counters, we will look at one for posterity
switch (counters[0].storage) {
  case VK_PERFORMANCE_COUNTER_STORAGE_INT32:
    // use recordCounters[0].int32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_INT64:
    // use recordCounters[0].int64 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_UINT32:
    // use recordCounters[0].uint32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_UINT64:
    // use recordCounters[0].uint64 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT32:
    // use recordCounters[0].float32 to get at the counter result!
    break;
  case VK_PERFORMANCE_COUNTER_STORAGE_FLOAT64:
    // use recordCounters[0].float64 to get at the counter result!
    break;
}
Version History
  • Revision 1, 2019-10-08

VK_KHR_pipeline_executable_properties

Name String

VK_KHR_pipeline_executable_properties

Extension Type

Device extension

Registered Extension Number

270

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Special Use
Contact
Other Extension Metadata
Last Modified Date

2019-05-28

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Faith Ekstrand, Intel

  • Ian Romanick, Intel

  • Kenneth Graunke, Intel

  • Baldur Karlsson, Valve

  • Jesse Hall, Google

  • Jeff Bolz, Nvidia

  • Piers Daniel, Nvidia

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

  • Daniel Koch, Nvidia

  • Spencer Fricke, Samsung

Description

When a pipeline is created, its state and shaders are compiled into zero or more device-specific executables, which are used when executing commands against that pipeline. This extension adds a mechanism to query properties and statistics about the different executables produced by the pipeline compilation process. This is intended to be used by debugging and performance tools to allow them to provide more detailed information to the user. Certain compile time shader statistics provided through this extension may be useful to developers for debugging or performance analysis.

New Enum Constants
  • VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_EXTENSION_NAME

  • VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_SPEC_VERSION

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR

    • VK_PIPELINE_CREATE_CAPTURE_STATISTICS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_EXECUTABLE_PROPERTIES_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INFO_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INTERNAL_REPRESENTATION_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_STATISTIC_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_INFO_KHR

Issues

1) What should we call the pieces of the pipeline which are produced by the compilation process and about which you can query properties and statistics?

RESOLVED: Call them “executables”. The name “binary” was used in early drafts of the extension but it was determined that “pipeline binary” could have a fairly broad meaning (such as a binary serialized form of an entire pipeline) and was too big of a namespace for the very specific needs of this extension.

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
Other Extension Metadata
Last Modified Date

2020-01-08

IP Status

No known IP claims.

Contributors
Description

A pipeline library is a special pipeline that cannot be bound, instead it defines a set of shaders and shader groups which can be linked into other pipelines. This extension defines the infrastructure for pipeline libraries, but does not specify the creation or usage of pipeline libraries. This is left to additional dependent extensions.

New Enum Constants
  • VK_KHR_PIPELINE_LIBRARY_EXTENSION_NAME

  • VK_KHR_PIPELINE_LIBRARY_SPEC_VERSION

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_LIBRARY_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_LIBRARY_CREATE_INFO_KHR

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
Other Extension Metadata
Last Modified Date

2021-06-02

IP Status

No known IP claims.

Interactions and External Dependencies
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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2019-05-15

IP Status

No known IP claims.

Contributors
  • Keith Packard, Valve

  • Ian Elliott, Google

  • Alon Or-bach, Samsung

Description

This device extension allows an application that uses the VK_KHR_swapchain extension to provide an identifier for present operations on a swapchain. An application can use this to reference specific present operations in other extensions.

New Enum Constants
  • VK_KHR_PRESENT_ID_EXTENSION_NAME

  • VK_KHR_PRESENT_ID_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_ID_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PRESENT_ID_KHR

Issues

None.

Examples
Version History
  • Revision 1, 2019-05-15 (Keith Packard)

    • Initial version

VK_KHR_present_wait

Name String

VK_KHR_present_wait

Extension Type

Device extension

Registered Extension Number

249

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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
New Enum Constants
  • VK_KHR_PRESENT_WAIT_EXTENSION_NAME

  • VK_KHR_PRESENT_WAIT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_FEATURES_KHR

Issues

1) When does the wait finish?

RESOLVED. The wait will finish when the present is visible to the user. There is no requirement for any precise timing relationship between the presentation of the image to the user, but implementations should signal the wait as close as possible to the presentation of the first pixel in the new image to the user.

2) Should this use fences or other existing synchronization mechanism.

RESOLVED. Because display and rendering are often implemented in separate drivers, this extension will provide a separate synchronization API.

3) Should this extension share present identification with other extensions?

RESOLVED. Yes. A new extension, VK_KHR_present_id, should be created to provide a shared structure for presentation identifiers.

4) What happens when presentations complete out of order wrt calls to vkQueuePresent? This could happen if the semaphores for the presentations were ready out of order.

OPTION A: Require that when a PresentId is set that the driver ensure that images are always presented in the order of calls to vkQueuePresent.

OPTION B: Finish both waits when the earliest present completes. This will complete the later present wait earlier than the actual presentation. This should be the easiest to implement as the driver need only track the largest present ID completed. This is also the 'natural' consequence of interpreting the existing vkWaitForPresentKHR specificationn.

OPTION C: Finish both waits when both have completed. This will complete the earlier presentation later than the actual presentation time. This is allowed by the current specification as there is no precise timing requirement for when the presentId value is updated. This requires slightly more complexity in the driver as it will need to track all outstanding presentId values.

Examples
Version History
  • Revision 1, 2019-02-19 (Keith Packard)

    • Initial version

VK_KHR_push_descriptor

Name String

VK_KHR_push_descriptor

Extension Type

Device extension

Registered Extension Number

81

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_VERSION_1_1

  • Interacts with VK_KHR_descriptor_update_template

Contact
Other Extension Metadata
Last Modified Date

2017-09-12

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

Description

This extension allows descriptors to be written into the command buffer, while the implementation is responsible for managing their memory. Push descriptors may enable easier porting from older APIs and in some cases can be more efficient than writing descriptors into descriptor sets.

New Enum Constants
  • VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME

  • VK_KHR_PUSH_DESCRIPTOR_SPEC_VERSION

  • Extending VkDescriptorSetLayoutCreateFlagBits:

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES_KHR

If Version 1.1 is supported:

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_ray_query

Name String

VK_KHR_ray_query

Extension Type

Device extension

Registered Extension Number

349

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-11-12

Interactions and External Dependencies
Contributors
  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Spencer Fricke, Samsung

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

Description

Rasterization has been the dominant method to produce interactive graphics, but increasing performance of graphics hardware has made ray tracing a viable option for interactive rendering. Being able to integrate ray tracing with traditional rasterization makes it easier for applications to incrementally add ray traced effects to existing applications or to do hybrid approaches with rasterization for primary visibility and ray tracing for secondary queries.

Ray queries are available to all shader types, including graphics, compute and ray tracing pipelines. Ray queries are not able to launch additional shaders, instead returning traversal results to the calling shader.

This extension adds support for the following SPIR-V extension in Vulkan:

  • SPV_KHR_ray_query

New Enum Constants
  • VK_KHR_RAY_QUERY_EXTENSION_NAME

  • VK_KHR_RAY_QUERY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_QUERY_FEATURES_KHR

Sample Code

Example of ray query in a GLSL shader, illustrating how to use ray queries to determine whether a given position (at ray origin) is in shadow or not, by tracing a ray towards the light, and checking for any intersections with geometry occluding the light.

rayQueryEXT rq;

rayQueryInitializeEXT(rq, accStruct, gl_RayFlagsTerminateOnFirstHitEXT, cullMask, origin, tMin, direction, tMax);

// Traverse the acceleration structure and store information about the first intersection (if any)
rayQueryProceedEXT(rq);

if (rayQueryGetIntersectionTypeEXT(rq, true) == gl_RayQueryCommittedIntersectionNoneEXT) {
    // Not in shadow
}
Issues

(1) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the final (VK_KHR_acceleration_structure v11 / VK_KHR_ray_query v1) release?

  • refactor VK_KHR_ray_tracing into 3 extensions, enabling implementation flexibility and decoupling ray query support from ray pipelines:

  • 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

1

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_VERSION_1_3

  • Interacts with VK_KHR_ray_tracing_pipeline

  • Interacts with VK_KHR_synchronization2

SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2022-02-21

Interactions and External Dependencies
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:

  • 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 Enum Constants
  • VK_KHR_RAY_TRACING_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_MAINTENANCE_1_SPEC_VERSION

  • Extending VkQueryType:

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MAINTENANCE_1_FEATURES_KHR

If VK_KHR_synchronization2 or Version 1.3 is supported:

New Built-In Variables
New SPIR-V Capabilities
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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-11-12

Interactions and External Dependencies
Contributors
  • Matthäus Chajdas, AMD

  • Greg Grebe, AMD

  • Nicolai Hähnle, AMD

  • Tobias Hector, AMD

  • Dave Oldcorn, AMD

  • Skyler Saleh, AMD

  • Mathieu Robart, Arm

  • Marius Bjorge, Arm

  • Tom Olson, Arm

  • Sebastian Tafuri, EA

  • Henrik Rydgard, Embark

  • Juan Cañada, Epic Games

  • Patrick Kelly, Epic Games

  • Yuriy O’Donnell, Epic Games

  • Michael Doggett, Facebook/Oculus

  • Andrew Garrard, Imagination

  • Don Scorgie, Imagination

  • Dae Kim, Imagination

  • Joshua Barczak, Intel

  • Slawek Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Pascal Gautron, NVIDIA

  • Daniel Koch, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Martin Stich, NVIDIA

  • Nuno Subtil, NVIDIA

  • Eric Werness, NVIDIA

  • Jon Leech, Khronos

  • Jeroen van Schijndel, OTOY

  • Juul Joosten, OTOY

  • Alex Bourd, Qualcomm

  • Roman Larionov, Qualcomm

  • David McAllister, Qualcomm

  • Spencer Fricke, Samsung

  • Lewis Gordon, Samsung

  • Ralph Potter, Samsung

  • Jasper Bekkers, Traverse Research

  • Jesse Barker, Unity

  • Baldur Karlsson, Valve

Description

Rasterization has been the dominant method to produce interactive graphics, but increasing performance of graphics hardware has made ray tracing a viable option for interactive rendering. Being able to integrate ray tracing with traditional rasterization makes it easier for applications to incrementally add ray traced effects to existing applications or to do hybrid approaches with rasterization for primary visibility and ray tracing for secondary queries.

To enable ray tracing, this extension adds a few different categories of new functionality:

  • A new ray tracing pipeline type with new shader domains: ray generation, intersection, any-hit, closest hit, miss, and callable

  • A shader binding indirection table to link shader groups with acceleration structure items

  • Ray tracing commands which initiate the ray pipeline traversal and invocation of the various new shader domains depending on which traversal conditions are met

This extension adds support for the following SPIR-V extension in Vulkan:

  • SPV_KHR_ray_tracing

New Enum Constants
  • VK_KHR_RAY_TRACING_PIPELINE_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_PIPELINE_SPEC_VERSION

  • VK_SHADER_UNUSED_KHR

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR

  • Extending VkPipelineBindPoint:

    • VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR

    • VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_ANY_HIT_BIT_KHR

    • VK_SHADER_STAGE_CALLABLE_BIT_KHR

    • VK_SHADER_STAGE_CLOSEST_HIT_BIT_KHR

    • VK_SHADER_STAGE_INTERSECTION_BIT_KHR

    • VK_SHADER_STAGE_MISS_BIT_KHR

    • VK_SHADER_STAGE_RAYGEN_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_INTERFACE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_KHR

Issues

(1) How does this extension differ from VK_NV_ray_tracing?

DISCUSSION:

The following is a summary of the main functional differences between VK_KHR_ray_tracing_pipeline and VK_NV_ray_tracing:

  • added support for indirect ray tracing (vkCmdTraceRaysIndirectKHR)

  • uses SPV_KHR_ray_tracing instead of SPV_NV_ray_tracing

    • refer to KHR SPIR-V enums instead of NV SPIR-V enums (which are functionally equivalent and aliased to the same values).

    • added RayGeometryIndexKHR built-in

  • removed vkCompileDeferredNV compilation functionality and replaced with deferred host operations interactions for ray tracing

  • added VkPhysicalDeviceRayTracingPipelineFeaturesKHR structure

  • extended VkPhysicalDeviceRayTracingPipelinePropertiesKHR structure

    • renamed maxRecursionDepth 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

(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?

(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:

  • 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 “Feature Requirements” section says it is required to be supported anyhow?

RESOLVED: If VK_KHR_pipeline_library were a required extension dependency, then every application would need to enable the extension whether or not they actually want to use the pipeline library functionality. Developers found this to be annoying and unfriendly behavior. We do wish to require all implementations to support it though, and thus it is listed in the feature requirements section.

Sample Code

Example ray generation GLSL shader

#version 450 core
#extension GL_EXT_ray_tracing : require
layout(set = 0, binding = 0, rgba8) uniform image2D image;
layout(set = 0, binding = 1) uniform accelerationStructureEXT as;
layout(location = 0) rayPayloadEXT float payload;

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

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

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

   col.y = payload;

   imageStore(image, ivec2(gl_LaunchIDEXT.xy), col);
}
Version History
  • Revision 1, 2020-11-12 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)

    • Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_ray_tracing_pipeline (#1918,!3912)

    • require certain subgroup and sm_shader_builtin shader builtins to be decorated as volatile in the ray generation, closest hit, miss, intersection, and callable stages (#1924,!3903,!3954)

    • clarify buffer usage flags for ray tracing (#2181,!3939)

    • rename maxRecursionDepth to maxRayPipelineRecursionDepth and maxRayRecursionDepth (#2203,!3937)

    • add queryable maxRayHitAttributeSize and rename members of VkRayTracingPipelineInterfaceCreateInfoKHR (#2102,!3966)

    • update to use RayTracingKHR SPIR-V capability

    • add VUs for matching hit group type against geometry type (#2245,!3994)

    • require RayTMaxKHR be volatile in intersection shaders (#2268,!4030)

    • add numerical limits for ray parameters (#2235,!3960)

    • fix SBT indexing rules for device addresses (#2308,!4079)

    • relax formula for ray intersection candidate determination (#2322,!4080)

    • add more details on ShaderRecordBufferKHR variables (#2230,!4083)

    • clarify valid bits for InstanceCustomIndexKHR (GLSL/GLSL#19,!4128)

    • allow at most one IncomingRayPayloadKHR, IncomingCallableDataKHR, 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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
  • Eric Werness

Extension Proposal

VK_KHR_ray_tracing_position_fetch

Other Extension Metadata
Last Modified Date

2023-02-17

Interactions and External Dependencies
Contributors
  • Eric Werness, NVIDIA

  • Stu Smith, AMD

  • Yuriy O’Donnell, Epic Games

  • Ralph Potter, Samsung

  • Joshua Barczak, Intel

  • Lionel Landwerlin, Intel

  • Andrew Garrard, Imagination Technologies

  • Alex Bourd, Qualcomm

  • Yunpeng Zhu, Huawei Technologies

  • Marius Bjorge, Arm

  • Daniel Koch, NVIDIA

Description

VK_KHR_ray_tracing_position_fetch adds the ability to fetch the vertex positions in the shader from a hit triangle as stored in the acceleration structure.

An application adds VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR to the acceleration structure at build time. Then, if the hit is a triangle geometry, the shader (any-hit or closest hit for ray pipelines or using ray query) can fetch the three, three-component vertex positions in object space, of the triangle which was hit.

New Enum Constants
  • VK_KHR_RAY_TRACING_POSITION_FETCH_EXTENSION_NAME

  • VK_KHR_RAY_TRACING_POSITION_FETCH_SPEC_VERSION

  • Extending VkBuildAccelerationStructureFlagBitsKHR:

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_POSITION_FETCH_FEATURES_KHR

New Built-In Variables
New SPIR-V Capabilities
Issues

None Yet!

Version History
  • Revision 1, 2023-02-17 (Eric Werness)

    • internal revisions

VK_KHR_shader_clock

Name String

VK_KHR_shader_clock

Extension Type

Device extension

Registered Extension Number

182

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2019-4-25

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Aaron Hagan, AMD

  • Daniel Koch, NVIDIA

Description

This extension advertises the SPIR-V ShaderClockKHR capability for Vulkan, which allows a shader to query a real-time or monotonically incrementing counter at the subgroup level or across the device level. The two valid SPIR-V scopes for OpReadClockKHR are Subgroup and Device.

When using GLSL source-based shading languages, the clockRealtime*EXT() timing functions map to the OpReadClockKHR instruction with a scope of Device, and the clock*ARB() timing functions map to the OpReadClockKHR instruction with a scope of Subgroup.

New Enum Constants
  • VK_KHR_SHADER_CLOCK_EXTENSION_NAME

  • VK_KHR_SHADER_CLOCK_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CLOCK_FEATURES_KHR

New SPIR-V Capabilities
Version History
  • Revision 1, 2019-4-25 (Aaron Hagan)

    • Initial revision

VK_KHR_shader_expect_assume

Name String

VK_KHR_shader_expect_assume

Extension Type

Device extension

Registered Extension Number

545

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
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 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
Version History
  • Revision 1, 2023-12-06 (Kevin Petit)

    • Initial revision

VK_KHR_shader_float_controls2

Name String

VK_KHR_shader_float_controls2

Extension Type

Device extension

Registered Extension Number

529

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Extension Proposal

VK_KHR_shader_float_controls2

Other Extension Metadata
Last Modified Date

2023-05-16

Interactions and External Dependencies
Contributors
  • Graeme Leese, Broadcom

Description

This extension enables use of the more expressive fast floating-point math flags in the SPV_KHR_float_controls2 extension. These flags give finer- grained control over which optimizations compilers may apply, potentially speeding up execution while retaining correct results.

The extension also adds control over the fast-math modes to the GLSL extended instruction set, making these operations more consistent with SPIR-V and allowing their use in situations where floating-point conformance is important.

New Enum Constants
  • VK_KHR_SHADER_FLOAT_CONTROLS_2_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT_CONTROLS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT_CONTROLS_2_FEATURES_KHR

New SPIR-V Capabilities
Version History
  • Revision 1, 2023-05-16 (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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
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
Contributors
  • Alan Baker, Google

Description

This extension allows the use of the SPV_KHR_maximal_reconvergence SPIR-V extension in shader modules. SPV_KHR_maximal_reconvergence provides stronger guarantees that diverged subgroups will reconverge. These guarantees should match shader author intuition about divergence and reconvergence of invocations based on the structure of the code in the HLL.

Developers should utilize this extension if they require stronger guarantees about reconvergence than either the core spec or SPV_KHR_subgroup_uniform_control_flow. This extension will define the rules that govern how invocations diverge and reconverge in a way that should match developer intuition. It allows robust programs to be written relying on subgroup operations and other tangled instructions.

New Enum Constants
  • VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_EXTENSION_NAME

  • VK_KHR_SHADER_MAXIMAL_RECONVERGENCE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MAXIMAL_RECONVERGENCE_FEATURES_KHR

New SPIR-V Capabilities
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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
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 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
Version History
  • Revision 1, 2023-11-01 (Tobias Hector)

    • Initial draft

VK_KHR_shader_subgroup_rotate

Name String

VK_KHR_shader_subgroup_rotate

Extension Type

Device extension

Registered Extension Number

417

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies

None

SPIR-V Dependencies
Contact
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

  • John Leech, Khronos

  • Matthew Netsch, Qualcomm

  • Jan-Harald Fredriksen, Arm Ltd.

  • Graeme Leese, Broadcom

  • Tom Olson, Arm Ltd.

  • Spencer Fricke, LunarG Inc.

This extension adds support for the subgroup rotate instruction defined in SPV_KHR_subgroup_rotate.

New Enum Constants
  • VK_KHR_SHADER_SUBGROUP_ROTATE_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_ROTATE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_ROTATE_FEATURES_KHR

  • Extending VkSubgroupFeatureFlagBits:

    • VK_SUBGROUP_FEATURE_ROTATE_BIT_KHR

    • VK_SUBGROUP_FEATURE_ROTATE_CLUSTERED_BIT_KHR

New SPIR-V Capabilities
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_subgroup_uniform_control_flow

Name String

VK_KHR_shader_subgroup_uniform_control_flow

Extension Type

Device extension

Registered Extension Number

324

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-08-27

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alan Baker, Google

  • Jeff Bolz, NVIDIA

Description

This extension allows the use of the SPV_KHR_subgroup_uniform_control_flow SPIR-V extension in shader modules. SPV_KHR_subgroup_uniform_control_flow provides stronger guarantees that diverged subgroups will reconverge.

Developers should utilize this extension if they use subgroup operations to reduce the work performed by a uniform subgroup. This extension will guarantee that uniform subgroup will reconverge in the same manner as invocation groups (see “Uniform Control Flow” in the Khronos SPIR-V Specification).

New Enum Constants
  • VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR

Version History
  • Revision 1, 2020-08-27 (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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-03-20

IP Status

No known IP claims.

Contributors
  • Alon Or-bach, Samsung Electronics

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Pablo Ceballos, Google

  • Chris Forbes, Google

  • Jeff Juliano, NVIDIA

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Tobias Hector, Imagination Technologies

  • Graham Connor, Imagination Technologies

  • Michael Worcester, Imagination Technologies

  • Cass Everitt, Oculus

  • Johannes Van Waveren, Oculus

Description

This extension extends VK_KHR_swapchain to enable creation of a shared presentable image. This allows the application to use the image while the presention engine is accessing it, in order to reduce the latency between rendering and presentation.

New Enum Constants
  • VK_KHR_SHARED_PRESENTABLE_IMAGE_EXTENSION_NAME

  • VK_KHR_SHARED_PRESENTABLE_IMAGE_SPEC_VERSION

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR

  • Extending VkPresentModeKHR:

    • VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR

    • VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR

Issues

1) Should we allow a Vulkan WSI swapchain to toggle between normal usage and shared presentation usage?

RESOLVED: No. WSI swapchains are typically recreated with new properties instead of having their properties changed. This can also save resources, assuming that fewer images are needed for shared presentation, and assuming that most VR applications do not need to switch between normal and shared usage.

2) Should we have a query for determining how the presentation engine refresh is triggered?

RESOLVED: Yes. This is done via which presentation modes a surface supports.

3) Should the object representing a shared presentable image be an extension of a VkSwapchainKHR or a separate object?

RESOLVED: Extension of a swapchain due to overlap in creation properties and to allow common functionality between shared and normal presentable images and swapchains.

4) What should we call the extension and the new structures it creates?

RESOLVED: Shared presentable image / shared present.

5) Should the minImageCount and presentMode values of the VkSwapchainCreateInfoKHR be ignored, or required to be compatible values?

RESOLVED: minImageCount must be set to 1, and presentMode should be set to either VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR or VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR.

6) What should the layout of the shared presentable image be?

RESOLVED: After acquiring the shared presentable image, the application must transition it to the VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout prior to it being used. After this initial transition, any image usage that was requested during swapchain creation can be performed on the image without layout transitions being performed.

7) Do we need a new API for the trigger to refresh new content?

RESOLVED: vkQueuePresentKHR to act as API to trigger a refresh, as will allow combination with other compatible extensions to vkQueuePresentKHR.

8) How should an application detect a VK_ERROR_OUT_OF_DATE_KHR error on a swapchain using the VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR present mode?

RESOLVED: Introduce vkGetSwapchainStatusKHR to allow applications to query the status of a swapchain using a shared presentation mode.

9) What should subsequent calls to vkQueuePresentKHR for VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR swapchains be defined to do?

RESOLVED: State that implementations may use it as a hint for updated content.

10) Can the ownership of a shared presentable image be transferred to a different queue?

RESOLVED: No. It is not possible to transfer ownership of a shared presentable image obtained from a swapchain created using VK_SHARING_MODE_EXCLUSIVE after it has been presented.

11) How should vkQueueSubmit behave if a command buffer uses an image from a VK_ERROR_OUT_OF_DATE_KHR swapchain?

RESOLVED: vkQueueSubmit is expected to return the VK_ERROR_DEVICE_LOST error.

12) Can Vulkan provide any guarantee on the order of rendering, to enable beam chasing?

RESOLVED: This could be achieved via use of render passes to ensure strip rendering.

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

1

Revision

25

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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
New Enum Constants
  • VK_KHR_SURFACE_EXTENSION_NAME

  • VK_KHR_SURFACE_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_SURFACE_KHR

  • Extending VkResult:

    • VK_ERROR_NATIVE_WINDOW_IN_USE_KHR

    • VK_ERROR_SURFACE_LOST_KHR

Examples
Note

The example code for the 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: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c).

Issues

1) Should this extension include a method to query whether a physical device supports presenting to a specific window or native surface on a given platform?

RESOLVED: Yes. Without this, applications would need to create a device instance to determine whether a particular window can be presented to. Knowing that a device supports presentation to a platform in general is not sufficient, as a single machine might support multiple seats, or instances of the platform that each use different underlying physical devices. Additionally, on some platforms, such as the X Window System, different drivers and devices might be used for different windows depending on which section of the desktop they exist on.

2) Should the vkGetPhysicalDeviceSurfaceCapabilitiesKHR, vkGetPhysicalDeviceSurfaceFormatsKHR, and vkGetPhysicalDeviceSurfacePresentModesKHR functions be in this extension and operate on physical devices, rather than being in VK_KHR_swapchain (i.e. device extension) and being dependent on VkDevice?

RESOLVED: Yes. While it might be useful to depend on VkDevice (and therefore on enabled extensions and features) for the queries, Vulkan was released only with the VkPhysicalDevice versions. Many cases can be resolved by a Valid Usage statement, and/or by a separate pNext chain version of the query struct specific to a given extension or parameters, via extensible versions of the queries: vkGetPhysicalDeviceSurfaceCapabilities2KHR, and vkGetPhysicalDeviceSurfaceFormats2KHR.

3) Should Vulkan support Xlib or XCB as the API for accessing the X Window System platform?

RESOLVED: Both. XCB is a more modern and efficient API, but Xlib usage is deeply ingrained in many applications and likely will remain in use for the foreseeable future. Not all drivers necessarily need to support both, but including both as options in the core specification will probably encourage support, which should in turn ease adoption of the Vulkan API in older codebases. Additionally, the performance improvements possible with XCB likely will not have a measurable impact on the performance of Vulkan presentation and other minimal window system interactions defined here.

4) Should the GBM platform be included in the list of platform enums?

RESOLVED: Deferred, and will be addressed with a platform-specific extension to be written in the future.

Version History
  • Revision 1, 2015-05-20 (James Jones)

    • Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.

  • Revision 2, 2015-05-22 (Ian Elliott)

    • Created initial Description section.

    • Removed query for whether a platform requires the use of a queue for presentation, since it was decided that presentation will always be modeled as being part of the queue.

    • Fixed typos and other minor mistakes.

  • Revision 3, 2015-05-26 (Ian Elliott)

    • Improved the Description section.

  • Revision 4, 2015-05-27 (James Jones)

    • Fixed compilation errors in example code.

  • Revision 5, 2015-06-01 (James Jones)

    • Added issues 1 and 2 and made related spec updates.

  • Revision 6, 2015-06-01 (James Jones)

    • Merged the platform type mappings table previously removed from VK_KHR_swapchain with the platform description table in this spec.

    • Added issues 3 and 4 documenting choices made when building the initial list of native platforms supported.

  • Revision 7, 2015-06-11 (Ian Elliott)

    • Updated table 1 per input from the KHR TSG.

    • Updated issue 4 (GBM) per discussion with Daniel Stone. He will create a platform-specific extension sometime in the future.

  • Revision 8, 2015-06-17 (James Jones)

    • Updated enum-extending values using new convention.

    • Fixed the value of VK_SURFACE_PLATFORM_INFO_TYPE_SUPPORTED_KHR.

  • Revision 9, 2015-06-17 (James Jones)

    • Rebased on Vulkan API version 126.

  • Revision 10, 2015-06-18 (James Jones)

    • Marked issues 2 and 3 resolved.

  • Revision 11, 2015-06-23 (Ian Elliott)

    • Examples now show use of function pointers for extension functions.

    • Eliminated extraneous whitespace.

  • Revision 12, 2015-07-07 (Daniel Rakos)

    • Added error section describing when each error is expected to be reported.

    • Replaced the term “queue node index” with “queue family index” in the spec as that is the agreed term to be used in the latest version of the core header and spec.

    • Replaced bool32_t with VkBool32.

  • Revision 13, 2015-08-06 (Daniel Rakos)

    • Updated spec against latest core API header version.

  • Revision 14, 2015-08-20 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.

    • Did miscellaneous cleanup, etc.

  • Revision 15, 2015-08-20 (Ian Elliott—​porting a 2015-07-29 change from James Jones)

    • Moved the surface transform enums here from VK_WSI_swapchain so they could be reused by VK_WSI_display.

  • Revision 16, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 17, 2015-09-01 (James Jones)

    • Fix example code compilation errors.

  • Revision 18, 2015-09-26 (Jesse Hall)

    • Replaced VkSurfaceDescriptionKHR with the VkSurfaceKHR object, which is created via layered extensions. Added VkDestroySurfaceKHR.

  • Revision 19, 2015-09-28 (Jesse Hall)

    • Renamed from VK_EXT_KHR_swapchain to VK_EXT_KHR_surface.

  • Revision 20, 2015-09-30 (Jeff Vigil)

    • Add error result VK_ERROR_SURFACE_LOST_KHR.

  • Revision 21, 2015-10-15 (Daniel Rakos)

    • Updated the resolution of issue #2 and include the surface capability queries in this extension.

    • Renamed SurfaceProperties to SurfaceCapabilities as it better reflects that the values returned are the capabilities of the surface on a particular device.

    • Other minor cleanup and consistency changes.

  • Revision 22, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_surface to VK_KHR_surface.

  • Revision 23, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkDestroySurfaceKHR.

  • Revision 24, 2015-11-10 (Jesse Hall)

    • Removed VkSurfaceTransformKHR. Use VkSurfaceTransformFlagBitsKHR instead.

    • Rename VkSurfaceCapabilitiesKHR member maxImageArraySize to maxImageArrayLayers.

  • Revision 25, 2016-01-14 (James Jones)

    • Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

  • 2016-08-23 (Ian Elliott)

    • Update the example code, to not have so many characters per line, and to split out a new example to show how to obtain function pointers.

  • 2016-08-25 (Ian Elliott)

    • A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.

VK_KHR_surface_protected_capabilities

Name String

VK_KHR_surface_protected_capabilities

Extension Type

Instance extension

Registered Extension Number

240

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2018-12-18

IP Status

No known IP claims.

Contributors
  • Sandeep Shinde, NVIDIA

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension extends VkSurfaceCapabilities2KHR, providing applications a way to query whether swapchains can be created with the VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR flag set.

Vulkan 1.1 added (optional) support for protect memory and protected resources including buffers (VK_BUFFER_CREATE_PROTECTED_BIT), images (VK_IMAGE_CREATE_PROTECTED_BIT), and swapchains (VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR). However, on implementations which support multiple windowing systems, not all window systems may be able to provide a protected display path.

This extension provides a way to query if a protected swapchain created for a surface (and thus a specific windowing system) can be displayed on screen. It extends the existing VkSurfaceCapabilities2KHR structure with a new VkSurfaceProtectedCapabilitiesKHR structure from which the application can obtain information about support for protected swapchain creation through vkGetPhysicalDeviceSurfaceCapabilities2KHR.

New Enum Constants
  • VK_KHR_SURFACE_PROTECTED_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_SURFACE_PROTECTED_CAPABILITIES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_PROTECTED_CAPABILITIES_KHR

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

2

Revision

70

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_VERSION_1_1

Contact
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
New Enum Constants
  • VK_KHR_SWAPCHAIN_EXTENSION_NAME

  • VK_KHR_SWAPCHAIN_SPEC_VERSION

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_PRESENT_SRC_KHR

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_SWAPCHAIN_KHR

  • Extending VkResult:

    • VK_ERROR_OUT_OF_DATE_KHR

    • VK_SUBOPTIMAL_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR

If Version 1.1 is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

  • Extending VkSwapchainCreateFlagBitsKHR:

    • VK_SWAPCHAIN_CREATE_PROTECTED_BIT_KHR

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

Issues

1) Does this extension allow the application to specify the memory backing of the presentable images?

RESOLVED: No. Unlike standard images, the implementation will allocate the memory backing of the presentable image.

2) What operations are allowed on presentable images?

RESOLVED: This is determined by the image usage flags specified when creating the presentable image’s swapchain.

3) Does this extension support MSAA presentable images?

RESOLVED: No. Presentable images are always single-sampled. Multi-sampled rendering must use regular images. To present the rendering results the application must manually resolve the multi- sampled image to a single-sampled presentable image prior to presentation.

4) Does this extension support stereo/multi-view presentable images?

RESOLVED: Yes. The number of views associated with a presentable image is determined by the imageArrayLayers specified when creating a swapchain. All presentable images in a given swapchain use the same array size.

5) Are the layers of stereo presentable images half-sized?

RESOLVED: No. The image extents always match those requested by the application.

6) Do the “present” and “acquire next image” commands operate on a queue? If not, do they need to include explicit semaphore objects to interlock them with queue operations?

RESOLVED: The present command operates on a queue. The image ownership operation it represents happens in order with other operations on the queue, so no explicit semaphore object is required to synchronize its actions.

Applications may want to acquire the next image in separate threads from those in which they manage their queue, or in multiple threads. To make such usage easier, the acquire next image command takes a semaphore to signal as a method of explicit synchronization. The application must later queue a wait for this semaphore before queuing execution of any commands using the image.

7) Does vkAcquireNextImageKHR block if no images are available?

RESOLVED: The command takes a timeout parameter. Special values for the timeout are 0, which makes the call a non-blocking operation, and UINT64_MAX, which blocks indefinitely. Values in between will block for up to the specified time. The call will return when an image becomes available or an error occurs. It may, but is not required to, return before the specified timeout expires if the swapchain becomes out of date.

8) Can multiple presents be queued using one vkQueuePresentKHR call?

RESOLVED: Yes. VkPresentInfoKHR contains a list of swapchains and corresponding image indices that will be presented. When supported, all presentations queued with a single vkQueuePresentKHR call will be applied atomically as one operation. The same swapchain must not appear in the list more than once. Later extensions may provide applications stronger guarantees of atomicity for such present operations, and/or allow them to query whether atomic presentation of a particular group of swapchains is possible.

9) How do the presentation and acquire next image functions notify the application the targeted surface has changed?

RESOLVED: Two new result codes are introduced for this purpose:

  • VK_SUBOPTIMAL_KHR - Presentation will still succeed, subject to the window resize behavior, but the swapchain is no longer configured optimally for the surface it targets. Applications should query updated surface information and recreate their swapchain at the next convenient opportunity.

  • VK_ERROR_OUT_OF_DATE_KHR - Failure. The swapchain is no longer compatible with the surface it targets. The application must query updated surface information and recreate the swapchain before presentation will succeed.

These can be returned by both vkAcquireNextImageKHR and vkQueuePresentKHR.

10) Does the vkAcquireNextImageKHR command return a semaphore to the application via an output parameter, or accept a semaphore to signal from the application as an object handle parameter?

RESOLVED: Accept a semaphore to signal as an object handle. This avoids the need to specify whether the application must destroy the semaphore or whether it is owned by the swapchain, and if the latter, what its lifetime is and whether it can be reused for other operations once it is received from vkAcquireNextImageKHR.

11) What types of swapchain queuing behavior should be exposed? Options include swap interval specification, mailbox/most recent vs. FIFO queue management, targeting specific vertical blank intervals or absolute times for a given present operation, and probably others. For some of these, whether they are specified at swapchain creation time or as per-present parameters needs to be decided as well.

RESOLVED: The base swapchain extension will expose 3 possible behaviors (of which, FIFO will always be supported):

  • Immediate present: Does not wait for vertical blanking period to update the current image, likely resulting in visible tearing. No internal queue is used. Present requests are applied immediately.

  • Mailbox queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal single-entry queue is used to hold pending presentation requests. If the queue is full when a new presentation request is received, the new request replaces the existing entry, and any images associated with the prior entry become available for reuse by the application.

  • FIFO queue: Waits for the next vertical blanking period to update the current image. No tearing should be observed. An internal queue containing numSwapchainImages - 1 entries is used to hold pending presentation requests. New requests are appended to the end of the queue, and one request is removed from the beginning of the queue and processed during each vertical blanking period in which the queue is non-empty

Not all surfaces will support all of these modes, so the modes supported will be returned using a surface information query. All surfaces must support the FIFO queue mode. Applications must choose one of these modes up front when creating a swapchain. Switching modes can be accomplished by recreating the swapchain.

12) Can VK_PRESENT_MODE_MAILBOX_KHR provide non-blocking guarantees for vkAcquireNextImageKHR? If so, what is the proper criteria?

RESOLVED: Yes. The difficulty is not immediately obvious here. Naively, if at least 3 images are requested, mailbox mode should always have an image available for the application if the application does not own any images when the call to vkAcquireNextImageKHR was made. However, some presentation engines may have more than one “current” image, and would still need to block in some cases. The right requirement appears to be that if the application allocates the surface’s minimum number of images + 1 then it is guaranteed non-blocking behavior when it does not currently own any images.

13) Is there a way to create and initialize a new swapchain for a surface that has generated a VK_SUBOPTIMAL_KHR return code while still using the old swapchain?

RESOLVED: Not as part of this specification. This could be useful to allow the application to create an “optimal” replacement swapchain and rebuild all its command buffers using it in a background thread at a low priority while continuing to use the “suboptimal” swapchain in the main thread. It could probably use the same “atomic replace” semantics proposed for recreating direct-to-device swapchains without incurring a mode switch. However, after discussion, it was determined some platforms probably could not support concurrent swapchains for the same surface though, so this will be left out of the base KHR extensions. A future extension could add this for platforms where it is supported.

14) Should there be a special value for VkSurfaceCapabilitiesKHR::maxImageCount to indicate there are no practical limits on the number of images in a swapchain?

RESOLVED: Yes. There will often be cases where there is no practical limit to the number of images in a swapchain other than the amount of available resources (i.e., memory) in the system. Trying to derive a hard limit from things like memory size is prone to failure. It is better in such cases to leave it to applications to figure such soft limits out via trial/failure iterations.

15) Should there be a special value for VkSurfaceCapabilitiesKHR::currentExtent to indicate the size of the platform surface is undefined?

RESOLVED: Yes. On some platforms (Wayland, for example), the surface size is defined by the images presented to it rather than the other way around.

16) Should there be a special value for VkSurfaceCapabilitiesKHR::maxImageExtent to indicate there is no practical limit on the surface size?

RESOLVED: No. It seems unlikely such a system would exist. 0 could be used to indicate the platform places no limits on the extents beyond those imposed by Vulkan for normal images, but this query could just as easily return those same limits, so a special “unlimited” value does not seem useful for this field.

17) How should surface rotation and mirroring be exposed to applications? How do they specify rotation and mirroring transforms applied prior to presentation?

RESOLVED: Applications can query both the supported and current transforms of a surface. Both are specified relative to the device’s “natural” display rotation and direction. The supported transforms indicate which orientations the presentation engine accepts images in. For example, a presentation engine that does not support transforming surfaces as part of presentation, and which is presenting to a surface that is displayed with a 90-degree rotation, would return only one supported transform bit: VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR. Applications must transform their rendering by the transform they specify when creating the swapchain in preTransform field.

18) Can surfaces ever not support VK_MIRROR_NONE? Can they support vertical and horizontal mirroring simultaneously? Relatedly, should VK_MIRROR_NONE[_BIT] be zero, or bit one, and should applications be allowed to specify multiple pre and current mirror transform bits, or exactly one?

RESOLVED: Since some platforms may not support presenting with a transform other than the native window’s current transform, and prerotation/mirroring are specified relative to the device’s natural rotation and direction, rather than relative to the surface’s current rotation and direction, it is necessary to express lack of support for no mirroring. To allow this, the MIRROR_NONE enum must occupy a bit in the flags. Since MIRROR_NONE must be a bit in the bitmask rather than a bitmask with no values set, allowing more than one bit to be set in the bitmask would make it possible to describe undefined transforms such as VK_MIRROR_NONE_BIT | VK_MIRROR_HORIZONTAL_BIT, or a transform that includes both “no mirroring” and “horizontal mirroring” simultaneously. Therefore, it is desirable to allow specifying all supported mirroring transforms using only one bit. The question then becomes, should there be a VK_MIRROR_HORIZONTAL_AND_VERTICAL_BIT to represent a simultaneous horizontal and vertical mirror transform? However, such a transform is equivalent to a 180 degree rotation, so presentation engines and applications that wish to support or use such a transform can express it through rotation instead. Therefore, 3 exclusive bits are sufficient to express all needed mirroring transforms.

19) Should support for sRGB be required?

RESOLVED: In the advent of UHD and HDR display devices, proper color space information is vital to the display pipeline represented by the swapchain. The app can discover the supported format/color-space pairs and select a pair most suited to its rendering needs. Currently only the sRGB color space is supported, future extensions may provide support for more color spaces. See issues 23 and 24.

20) Is there a mechanism to modify or replace an existing swapchain with one targeting the same surface?

RESOLVED: Yes. This is described above in the text.

21) Should there be a way to set prerotation and mirroring using native APIs when presenting using a Vulkan swapchain?

RESOLVED: Yes. The transforms that can be expressed in this extension are a subset of those possible on native platforms. If a platform exposes a method to specify the transform of presented images for a given surface using native methods and exposes more transforms or other properties for surfaces than Vulkan supports, it might be impossible, difficult, or inconvenient to set some of those properties using Vulkan KHR extensions and some using the native interfaces. To avoid overwriting properties set using native commands when presenting using a Vulkan swapchain, the application can set the pretransform to “inherit”, in which case the current native properties will be used, or if none are available, a platform-specific default will be used. Platforms that do not specify a reasonable default or do not provide native mechanisms to specify such transforms should not include the inherit bits in the supportedTransforms bitmask they return in VkSurfaceCapabilitiesKHR.

22) Should the content of presentable images be clipped by objects obscuring their target surface?

RESOLVED: Applications can choose which behavior they prefer. Allowing the content to be clipped could enable more efficient presentation methods on some platforms, but some applications might rely on the content of presentable images to perform techniques such as partial updates or motion blurs.

23) What is the purpose of specifying a VkColorSpaceKHR along with VkFormat when creating a swapchain?

RESOLVED: While Vulkan itself is color space agnostic (e.g. even the meaning of R, G, B and A can be freely defined by the rendering application), the swapchain eventually will have to present the images on a display device with specific color reproduction characteristics. If any color space transformations are necessary before an image can be displayed, the color space of the presented image must be known to the swapchain. A swapchain will only support a restricted set of color format and -space pairs. This set can be discovered via vkGetPhysicalDeviceSurfaceFormatsKHR. As it can be expected that most display devices support the sRGB color space, at least one format/color-space pair has to be exposed, where the color space is VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.

24) How are sRGB formats and the sRGB color space related?

RESOLVED: While Vulkan exposes a number of SRGB texture formats, using such formats does not guarantee working in a specific color space. It merely means that the hardware can directly support applying the non-linear transfer functions defined by the sRGB standard color space when reading from or writing to images of those formats. Still, it is unlikely that a swapchain will expose a *_SRGB format along with any color space other than VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.

On the other hand, non-*_SRGB formats will be very likely exposed in pair with a SRGB color space. This means, the hardware will not apply any transfer function when reading from or writing to such images, yet they will still be presented on a device with sRGB display characteristics. In this case the application is responsible for applying the transfer function, for instance by using shader math.

25) How are the lifetimes of surfaces and swapchains targeting them related?

RESOLVED: A surface must outlive any swapchains targeting it. A VkSurfaceKHR owns the binding of the native window to the Vulkan driver.

26) How can the client control the way the alpha component of swapchain images is treated by the presentation engine during compositing?

RESOLVED: We should add new enum values to allow the client to negotiate with the presentation engine on how to treat image alpha values during the compositing process. Since not all platforms can practically control this through the Vulkan driver, a value of VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR is provided like for surface transforms.

27) Is vkCreateSwapchainKHR the right function to return VK_ERROR_NATIVE_WINDOW_IN_USE_KHR, or should the various platform-specific VkSurfaceKHR factory functions catch this error earlier?

RESOLVED: For most platforms, the VkSurfaceKHR structure is a simple container holding the data that identifies a native window or other object representing a surface on a particular platform. For the surface factory functions to return this error, they would likely need to register a reference on the native objects with the native display server somehow, and ensure no other such references exist. Surfaces were not intended to be that heavyweight.

Swapchains are intended to be the objects that directly manipulate native windows and communicate with the native presentation mechanisms. Swapchains will already need to communicate with the native display server to negotiate allocation and/or presentation of presentable images for a native surface. Therefore, it makes more sense for swapchain creation to be the point at which native object exclusivity is enforced. Platforms may choose to enforce further restrictions on the number of VkSurfaceKHR objects that may be created for the same native window if such a requirement makes sense on a particular platform, but a global requirement is only sensible at the swapchain level.

Examples
Note

The example code for the 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: https://github.com/KhronosGroup/Vulkan-Tools/blob/main/cube/cube.c).

Version History
  • Revision 1, 2015-05-20 (James Jones)

    • Initial draft, based on LunarG KHR spec, other KHR specs, patches attached to bugs.

  • Revision 2, 2015-05-22 (Ian Elliott)

    • Made many agreed-upon changes from 2015-05-21 KHR TSG meeting. This includes using only a queue for presentation, and having an explicit function to acquire the next image.

    • Fixed typos and other minor mistakes.

  • Revision 3, 2015-05-26 (Ian Elliott)

    • Improved the Description section.

    • Added or resolved issues that were found in improving the Description. For example, pSurfaceDescription is used consistently, instead of sometimes using pSurface.

  • Revision 4, 2015-05-27 (James Jones)

    • Fixed some grammatical errors and typos

    • Filled in the description of imageUseFlags when creating a swapchain.

    • Added a description of swapInterval.

    • Replaced the paragraph describing the order of operations on a queue for image ownership and presentation.

  • Revision 5, 2015-05-27 (James Jones)

    • Imported relevant issues from the (abandoned) vk_wsi_persistent_swapchain_images extension.

    • Added issues 6 and 7, regarding behavior of the acquire next image and present commands with respect to queues.

    • Updated spec language and examples to align with proposed resolutions to issues 6 and 7.

  • Revision 6, 2015-05-27 (James Jones)

    • Added issue 8, regarding atomic presentation of multiple swapchains

    • Updated spec language and examples to align with proposed resolution to issue 8.

  • Revision 7, 2015-05-27 (James Jones)

    • Fixed compilation errors in example code, and made related spec fixes.

  • Revision 8, 2015-05-27 (James Jones)

    • Added issue 9, and the related VK_SUBOPTIMAL_KHR result code.

    • Renamed VK_OUT_OF_DATE_KHR to VK_ERROR_OUT_OF_DATE_KHR.

  • Revision 9, 2015-05-27 (James Jones)

    • Added inline proposed resolutions (marked with [JRJ]) to some XXX questions/issues. These should be moved to the issues section in a subsequent update if the proposals are adopted.

  • Revision 10, 2015-05-28 (James Jones)

    • Converted vkAcquireNextImageKHR back to a non-queue operation that uses a VkSemaphore object for explicit synchronization.

    • Added issue 10 to determine whether vkAcquireNextImageKHR generates or returns semaphores, or whether it operates on a semaphore provided by the application.

  • Revision 11, 2015-05-28 (James Jones)

    • Marked issues 6, 7, and 8 resolved.

    • Renamed VkSurfaceCapabilityPropertiesKHR to VkSurfacePropertiesKHR to better convey the mutable nature of the information it contains.

  • Revision 12, 2015-05-28 (James Jones)

    • Added issue 11 with a proposed resolution, and the related issue 12.

    • Updated various sections of the spec to match the proposed resolution to issue 11.

  • Revision 13, 2015-06-01 (James Jones)

    • Moved some structures to VK_EXT_KHR_swap_chain to resolve the specification’s issues 1 and 2.

  • Revision 14, 2015-06-01 (James Jones)

    • Added code for example 4 demonstrating how an application might make use of the two different present and acquire next image KHR result codes.

    • Added issue 13.

  • Revision 15, 2015-06-01 (James Jones)

    • Added issues 14 - 16 and related spec language.

    • Fixed some spelling errors.

    • Added language describing the meaningful return values for vkAcquireNextImageKHR and vkQueuePresentKHR.

  • Revision 16, 2015-06-02 (James Jones)

    • Added issues 17 and 18, as well as related spec language.

    • Removed some erroneous text added by mistake in the last update.

  • Revision 17, 2015-06-15 (Ian Elliott)

    • Changed special value from “-1” to “0” so that the data types can be unsigned.

  • Revision 18, 2015-06-15 (Ian Elliott)

    • Clarified the values of VkSurfacePropertiesKHR::minImageCount and the timeout parameter of the vkAcquireNextImageKHR function.

  • Revision 19, 2015-06-17 (James Jones)

    • Misc. cleanup. Removed resolved inline issues and fixed typos.

    • Fixed clarification of VkSurfacePropertiesKHR::minImageCount made in version 18.

    • Added a brief “Image Ownership” definition to the list of terms used in the spec.

  • Revision 20, 2015-06-17 (James Jones)

    • Updated enum-extending values using new convention.

  • Revision 21, 2015-06-17 (James Jones)

    • Added language describing how to use VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.

    • Cleaned up an XXX comment regarding the description of which queues vkQueuePresentKHR can be used on.

  • Revision 22, 2015-06-17 (James Jones)

    • Rebased on Vulkan API version 126.

  • Revision 23, 2015-06-18 (James Jones)

    • Updated language for issue 12 to read as a proposed resolution.

    • Marked issues 11, 12, 13, 16, and 17 resolved.

    • Temporarily added links to the relevant bugs under the remaining unresolved issues.

    • Added issues 19 and 20 as well as proposed resolutions.

  • Revision 24, 2015-06-19 (Ian Elliott)

    • Changed special value for VkSurfacePropertiesKHR::currentExtent back to “-1” from “0”. This value will never need to be unsigned, and “0” is actually a legal value.

  • Revision 25, 2015-06-23 (Ian Elliott)

    • Examples now show use of function pointers for extension functions.

    • Eliminated extraneous whitespace.

  • Revision 26, 2015-06-25 (Ian Elliott)

    • Resolved Issues 9 & 10 per KHR TSG meeting.

  • Revision 27, 2015-06-25 (James Jones)

    • Added oldSwapchain member to VkSwapchainCreateInfoKHR.

  • Revision 28, 2015-06-25 (James Jones)

    • Added the “inherit” bits to the rotation and mirroring flags and the associated issue 21.

  • Revision 29, 2015-06-25 (James Jones)

    • Added the “clipped” flag to VkSwapchainCreateInfoKHR, and the associated issue 22.

    • Specified that presenting an image does not modify it.

  • Revision 30, 2015-06-25 (James Jones)

    • Added language to the spec that clarifies the behavior of vkCreateSwapchainKHR() when the oldSwapchain field of VkSwapchainCreateInfoKHR is not NULL.

  • Revision 31, 2015-06-26 (Ian Elliott)

    • Example of new VkSwapchainCreateInfoKHR members, “oldSwapchain” and “clipped”.

    • Example of using VkSurfacePropertiesKHR::{min|max}ImageCount to set VkSwapchainCreateInfoKHR::minImageCount.

    • Rename vkGetSurfaceInfoKHR()'s 4th parameter to “pDataSize”, for consistency with other functions.

    • Add macro with C-string name of extension (just to header file).

  • Revision 32, 2015-06-26 (James Jones)

    • Minor adjustments to the language describing the behavior of “oldSwapchain”

    • Fixed the version date on my previous two updates.

  • Revision 33, 2015-06-26 (Jesse Hall)

    • Add usage flags to VkSwapchainCreateInfoKHR

  • Revision 34, 2015-06-26 (Ian Elliott)

    • Rename vkQueuePresentKHR()'s 2nd parameter to “pPresentInfo”, for consistency with other functions.

  • Revision 35, 2015-06-26 (Faith Ekstrand)

    • Merged the VkRotationFlagBitsKHR and VkMirrorFlagBitsKHR enums into a single VkSurfaceTransformFlagBitsKHR enum.

  • Revision 36, 2015-06-26 (Faith Ekstrand)

    • Added a VkSurfaceTransformKHR enum that is not a bitmask. Each value in VkSurfaceTransformKHR corresponds directly to one of the bits in VkSurfaceTransformFlagBitsKHR so transforming from one to the other is easy. Having a separate enum means that currentTransform and preTransform are now unambiguous by definition.

  • Revision 37, 2015-06-29 (Ian Elliott)

    • Corrected one of the signatures of vkAcquireNextImageKHR, which had the last two parameters switched from what it is elsewhere in the specification and header files.

  • Revision 38, 2015-06-30 (Ian Elliott)

    • Corrected a typo in description of the vkGetSwapchainInfoKHR() function.

    • Corrected a typo in header file comment for VkPresentInfoKHR::sType.

  • Revision 39, 2015-07-07 (Daniel Rakos)

    • Added error section describing when each error is expected to be reported.

    • Replaced bool32_t with VkBool32.

  • Revision 40, 2015-07-10 (Ian Elliott)

    • Updated to work with version 138 of the vulkan.h header. This includes declaring the VkSwapchainKHR type using the new VK_DEFINE_NONDISP_HANDLE macro, and no longer extending VkObjectType (which was eliminated).

  • Revision 41 2015-07-09 (Mathias Heyer)

    • Added color space language.

  • Revision 42, 2015-07-10 (Daniel Rakos)

    • Updated query mechanism to reflect the convention changes done in the core spec.

    • Removed “queue” from the name of VK_STRUCTURE_TYPE_QUEUE_PRESENT_INFO_KHR to be consistent with the established naming convention.

    • Removed reference to the no longer existing VkObjectType enum.

  • Revision 43, 2015-07-17 (Daniel Rakos)

    • Added support for concurrent sharing of swapchain images across queue families.

    • Updated sample code based on recent changes

  • Revision 44, 2015-07-27 (Ian Elliott)

    • Noted that support for VK_PRESENT_MODE_FIFO_KHR is required. That is ICDs may optionally support IMMEDIATE and MAILBOX, but must support FIFO.

  • Revision 45, 2015-08-07 (Ian Elliott)

    • Corrected a typo in spec file (type and variable name had wrong case for the imageColorSpace member of the VkSwapchainCreateInfoKHR struct).

    • Corrected a typo in header file (last parameter in PFN_vkGetSurfacePropertiesKHR was missing “KHR” at the end of type: VkSurfacePropertiesKHR).

  • Revision 46, 2015-08-20 (Ian Elliott)

    • Renamed this extension and all of its enumerations, types, functions, etc. This makes it compliant with the proposed standard for Vulkan extensions.

    • Switched from “revision” to “version”, including use of the VK_MAKE_VERSION macro in the header file.

    • Made improvements to several descriptions.

    • Changed the status of several issues from PROPOSED to RESOLVED, leaving no unresolved issues.

    • Resolved several TODOs, did miscellaneous cleanup, etc.

  • Revision 47, 2015-08-20 (Ian Elliott—​porting a 2015-07-29 change from James Jones)

    • Moved the surface transform enums to VK_WSI_swapchain so they could be reused by VK_WSI_display.

  • Revision 48, 2015-09-01 (James Jones)

    • Various minor cleanups.

  • Revision 49, 2015-09-01 (James Jones)

    • Restore single-field revision number.

  • Revision 50, 2015-09-01 (James Jones)

    • Update Example #4 to include code that illustrates how to use the oldSwapchain field.

  • Revision 51, 2015-09-01 (James Jones)

    • Fix example code compilation errors.

  • Revision 52, 2015-09-08 (Matthaeus G. Chajdas)

    • Corrected a typo.

  • Revision 53, 2015-09-10 (Alon Or-bach)

    • Removed underscore from SWAP_CHAIN left in VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR.

  • Revision 54, 2015-09-11 (Jesse Hall)

    • Described the execution and memory coherence requirements for image transitions to and from VK_IMAGE_LAYOUT_PRESENT_SOURCE_KHR.

  • Revision 55, 2015-09-11 (Ray Smith)

    • Added errors for destroying and binding memory to presentable images

  • Revision 56, 2015-09-18 (James Jones)

    • Added fence argument to vkAcquireNextImageKHR

    • Added example of how to meter a host thread based on presentation rate.

  • Revision 57, 2015-09-26 (Jesse Hall)

    • Replace VkSurfaceDescriptionKHR with VkSurfaceKHR.

    • Added issue 25 with agreed resolution.

  • Revision 58, 2015-09-28 (Jesse Hall)

    • Renamed from VK_EXT_KHR_device_swapchain to VK_EXT_KHR_swapchain.

  • Revision 59, 2015-09-29 (Ian Elliott)

    • Changed vkDestroySwapchainKHR() to return void.

  • Revision 60, 2015-10-01 (Jeff Vigil)

    • Added error result VK_ERROR_SURFACE_LOST_KHR.

  • Revision 61, 2015-10-05 (Faith Ekstrand)

    • Added the VkCompositeAlpha enum and corresponding structure fields.

  • Revision 62, 2015-10-12 (Daniel Rakos)

    • Added VK_PRESENT_MODE_FIFO_RELAXED_KHR.

  • Revision 63, 2015-10-15 (Daniel Rakos)

    • Moved surface capability queries to VK_EXT_KHR_surface.

  • Revision 64, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_swapchain to VK_KHR_swapchain.

  • Revision 65, 2015-10-28 (Ian Elliott)

    • Added optional pResult member to VkPresentInfoKHR, so that per-swapchain results can be obtained from vkQueuePresentKHR().

  • Revision 66, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to create and destroy functions.

    • Updated resource transition language.

    • Updated sample code.

  • Revision 67, 2015-11-10 (Jesse Hall)

    • Add reserved flags bitmask to VkSwapchainCreateInfoKHR.

    • Modify naming and member ordering to match API style conventions, and so the VkSwapchainCreateInfoKHR image property members mirror corresponding VkImageCreateInfo members but with an 'image' prefix.

    • Make VkPresentInfoKHR::pResults non-const; it is an output array parameter.

    • Make pPresentInfo parameter to vkQueuePresentKHR const.

  • Revision 68, 2016-04-05 (Ian Elliott)

    • Moved the “validity” include for vkAcquireNextImage to be in its proper place, after the prototype and list of parameters.

    • Clarified language about presentable images, including how they are acquired, when applications can and cannot use them, etc. As part of this, removed language about “ownership” of presentable images, and replaced it with more-consistent language about presentable images being “acquired” by the application.

  • 2016-08-23 (Ian Elliott)

    • Update the example code, to use the final API command names, to not have so many characters per line, and to split out a new example to show how to obtain function pointers. This code is more similar to the LunarG “cube” demo program.

  • 2016-08-25 (Ian Elliott)

    • A note was added at the beginning of the example code, stating that it will be removed from future versions of the appendix.

  • Revision 69, 2017-09-07 (Tobias Hector)

    • Added interactions with Vulkan 1.1

  • Revision 70, 2017-10-06 (Ian Elliott)

    • Corrected interactions with Vulkan 1.1

VK_KHR_swapchain_mutable_format

Name String

VK_KHR_swapchain_mutable_format

Extension Type

Device extension

Registered Extension Number

201

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_swapchain
and
     VK_KHR_maintenance2
     or
     Version 1.1
and
     VK_KHR_image_format_list
     or
     Version 1.2

Contact
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_vertex_attribute_divisor

Name String

VK_KHR_vertex_attribute_divisor

Extension Type

Device extension

Registered Extension Number

526

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 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

Version History
  • Revision 1, 2023-09-20 (Shahbaz Youssefi)

    • First Version, based on VK_EXT_vertex_attribute_divisor

VK_KHR_video_decode_av1

Name String

VK_KHR_video_decode_av1

Extension Type

Device extension

Registered Extension Number

513

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 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

9

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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.

Note

This extension was promoted to KHR from the provisional extension VK_EXT_video_decode_h264.

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

8

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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.

Note

This extension was promoted to KHR from the provisional extension VK_EXT_video_decode_h265.

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

8

Ratification Status

Ratified

Extension and Version Dependencies

VK_KHR_video_queue
and
     VK_KHR_synchronization2
     or
     Version 1.3

API Interactions
  • Interacts with VK_VERSION_1_3

  • Interacts with VK_KHR_format_feature_flags2

Contact
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
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

  • 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)

  • Revision 3, 2022-02-25 (Ahmed Abdelkhalek)

    • Add VkVideoDecodeCapabilitiesKHR with new flags to report support for decode DPB and output coinciding in the same image, or in distinct images.

  • Revision 4, 2022-03-31 (Ahmed Abdelkhalek)

    • Remove redundant VkVideoDecodeInfoKHR.coded{Offset|Extent}

  • Revision 5, 2022-07-18 (Daniel Rakos)

    • Remove VkVideoDecodeFlagBitsKHR as it contains no defined flags for now

  • Revision 6, 2022-08-12 (Daniel Rakos)

    • Add VkVideoDecodeUsageInfoKHR structure and related flags

  • Revision 7, 2022-09-29 (Daniel Rakos)

    • Extension is no longer provisional

  • Revision 8, 2023-12-05 (Daniel Rakos)

    • Require the specification of a reconstructed picture in all cases, except when the video session was created with no DPB slots to match shipping implementations

    • Make DPB slot activation behavior codec-specific to continue allowing application control over reference picture setup now that a reconstructed picture is always mandatory

VK_KHR_video_encode_h264

Name String

VK_KHR_video_encode_h264

Extension Type

Device extension

Registered Extension Number

39

Revision

14

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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, Core Avionics & Industrial Inc.

  • Lynne Iribarren, Independent

Description

This extension builds upon the VK_KHR_video_encode_queue extension by adding support for encoding elementary video stream sequences compliant with the H.264/AVC video compression standard.

Note

This extension was promoted to KHR from the provisional extension VK_EXT_video_encode_h264.

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
Contact
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, Core Avionics & Industrial Inc.

  • Lynne Iribarren, Independent

Description

This extension builds upon the VK_KHR_video_encode_queue extension by adding support for encoding elementary video stream sequences compliant with the H.265/HEVC video compression standard.

Note

This extension was promoted to KHR from the provisional extension VK_EXT_video_encode_h265.

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_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
     Version 1.3

API Interactions
  • Interacts with VK_VERSION_1_3

  • Interacts with VK_KHR_format_feature_flags2

Contact
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, Core Avionics & Industrial Inc.

  • Lynne Iribarren, Independent

Description

This extension builds upon the VK_KHR_video_queue extension by adding common APIs specific to video encoding and thus enabling implementations to expose queue families supporting video encode operations.

More specifically, it adds video encode specific capabilities and a new command buffer command that allows recording video encode operations against a video session.

This extension is to be used in conjunction with other codec specific video encode extensions that enable encoding video sequences of specific video compression standards.

New 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

  • 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)

  • 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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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, Core Avionics & Industrial Inc.

  • Ping Liu, Intel

  • Lynne Iribarren, Independent

  • Srinath Kumarapuram, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Daniel Rakos, RasterGrid

Description

VK_KHR_video_maintenance1 adds a collection of minor video coding features, none of which would warrant an entire extension of their own.

The new features are as follows:

  • Allow creating buffers that can be used in video coding operations, independent of the used video profile, using the new buffer creation flag VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR.

  • Allow creating images that can be used as decode output or encode input pictures, independent of the used video profile, using the new image creation flag VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR.

  • Allow specifying queries used by video coding operations as part of the video coding command parameters, instead of using begin/end query when the video session is created using the new video session creation flag VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR.

New Enum Constants
  • VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_VIDEO_MAINTENANCE_1_SPEC_VERSION

  • Extending VkBufferCreateFlagBits:

    • VK_BUFFER_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR

    • VK_STRUCTURE_TYPE_VIDEO_INLINE_QUERY_INFO_KHR

  • Extending VkVideoSessionCreateFlagBitsKHR:

    • VK_VIDEO_SESSION_CREATE_INLINE_QUERIES_BIT_KHR

Version History
  • Revision 1, 2023-07-27 (Daniel Rakos)

    • internal revisions

VK_KHR_video_queue

Name String

VK_KHR_video_queue

Extension Type

Device extension

Registered Extension Number

24

Revision

8

Ratification Status

Ratified

Extension and Version Dependencies

     Version 1.1
     and
     VK_KHR_synchronization2
or
Version 1.3

Contact
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 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

7

Revision

6

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2015-11-28

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

Description

The VK_KHR_wayland_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Wayland wl_surface, as well as a query to determine support for rendering to a Wayland compositor.

New Enum Constants
  • VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME

  • VK_KHR_WAYLAND_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR

Issues

1) Does Wayland need a way to query for compatibility between a particular physical device and a specific Wayland display? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR: if the Wayland-specific query returned VK_TRUE for a (VkPhysicalDevice, struct wl_display*) pair, then the physical device could be assumed to support presentation to any VkSurfaceKHR for surfaces on the display.

RESOLVED: Yes. vkGetPhysicalDeviceWaylandPresentationSupportKHR was added to address this issue.

2) Should we require surfaces created with vkCreateWaylandSurfaceKHR to support the VK_PRESENT_MODE_MAILBOX_KHR present mode?

RESOLVED: Yes. Wayland is an inherently mailbox window system and mailbox support is required for some Wayland compositor interactions to work as expected. While handling these interactions may be possible with VK_PRESENT_MODE_FIFO_KHR, it is much more difficult to do without deadlock and requiring all Wayland applications to be able to support implementations which only support VK_PRESENT_MODE_FIFO_KHR would be an onerous restriction on application developers.

Version History
  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve issue #1.

    • Adjusted wording of issue #1 to match the agreed-upon solution.

    • Renamed “window” parameters to “surface” to match Wayland conventions.

  • Revision 3, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface.

  • Revision 4, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkCreateWaylandSurfaceKHR.

  • Revision 5, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

  • Revision 6, 2017-02-08 (Faith Ekstrand)

    • Added the requirement that implementations support VK_PRESENT_MODE_MAILBOX_KHR.

    • Added wording about interactions between vkQueuePresentKHR and the Wayland requests sent to the compositor.

VK_KHR_win32_keyed_mutex

Name String

VK_KHR_win32_keyed_mutex

Extension Type

Device extension

Registered Extension Number

76

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-10-21

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Carsten Rohde, NVIDIA

Description

Applications that wish to import Direct3D 11 memory objects into the Vulkan API may wish to use the native keyed mutex mechanism to synchronize access to the memory between Vulkan and Direct3D. This extension provides a way for an application to access the keyed mutex associated with an imported Vulkan memory object when submitting command buffers to a queue.

New Enum Constants
  • VK_KHR_WIN32_KEYED_MUTEX_EXTENSION_NAME

  • VK_KHR_WIN32_KEYED_MUTEX_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_KHR

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

6

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-04-24

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

Description

The VK_KHR_win32_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Win32 HWND, as well as a query to determine support for rendering to the windows desktop.

New Enum Constants
  • VK_KHR_WIN32_SURFACE_EXTENSION_NAME

  • VK_KHR_WIN32_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR

Issues

1) Does Win32 need a way to query for compatibility between a particular physical device and a specific screen? Compatibility between a physical device and a window generally only depends on what screen the window is on. However, there is not an obvious way to identify a screen without already having a window on the screen.

RESOLVED: No. While it may be useful, there is not a clear way to do this on Win32. However, a method was added to query support for presenting to the windows desktop as a whole.

2) If a native window object (HWND) is used by one graphics API, and then is later used by a different graphics API (one of which is Vulkan), can these uses interfere with each other?

RESOLVED: Yes.

Uses of a window object by multiple graphics APIs results in undefined behavior. Such behavior may succeed when using one Vulkan implementation but fail when using a different Vulkan implementation. Potential failures include:

  • Creating then destroying a flip presentation model DXGI swapchain on a window object can prevent vkCreateSwapchainKHR from succeeding on the same window object.

  • Creating then destroying a VkSwapchainKHR on a window object can prevent creation of a bitblt model DXGI swapchain on the same window object.

  • Creating then destroying a VkSwapchainKHR on a window object can effectively SetPixelFormat to a different format than the format chosen by an OpenGL application.

  • Creating then destroying a VkSwapchainKHR on a window object on one VkPhysicalDevice can prevent vkCreateSwapchainKHR from succeeding on the same window object, but on a different VkPhysicalDevice that is associated with a different Vulkan ICD.

In all cases the problem can be worked around by creating a new window object.

Technical details include:

  • Creating a DXGI swapchain over a window object can alter the object for the remainder of its lifetime. The alteration persists even after the DXGI swapchain has been destroyed. This alteration can make it impossible for a conformant Vulkan implementation to create a VkSwapchainKHR over the same window object. Mention of this alteration can be found in the remarks section of the MSDN documentation for DXGI_SWAP_EFFECT.

  • Calling GDI’s SetPixelFormat (needed by OpenGL’s WGL layer) on a window object alters the object for the remainder of its lifetime. The MSDN documentation 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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
  • Caio Marcelo de Oliveira Filho cmarcelo

Other Extension Metadata
Last Modified Date

2020-06-01

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Caio Marcelo de Oliveira Filho, Intel

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Faith Ekstrand, Intel

  • Daniel Koch, NVIDIA

Description

This extension adds Vulkan support for the SPV_KHR_workgroup_memory_explicit_layout SPIR-V extension, which allows shaders to explicitly define the layout of Workgroup storage class memory and create aliases between variables from that storage class in a compute shader.

The aliasing feature allows different “views” on the same data, so the shader can bulk copy data from another storage class using one type (e.g. an array of large vectors), and then use the data with a more specific type. It also enables reducing the amount of workgroup memory consumed by allowing the shader to alias data whose lifetimes do not overlap.

The explicit layout support and some form of aliasing is also required for layering OpenCL on top of Vulkan.

New Enum Constants
  • VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_EXTENSION_NAME

  • VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_FEATURES_KHR

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

6

Revision

6

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 Structures
New Enum Constants
  • VK_KHR_XCB_SURFACE_EXTENSION_NAME

  • VK_KHR_XCB_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR

Issues

1) Does XCB need a way to query for compatibility between a particular physical device and a specific screen? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR: If it returned VK_TRUE, then the physical device could be assumed to support presentation to any window on that screen.

RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.

Version History
  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added presentation support query for an (xcb_connection_t*, xcb_visualid_t) pair.

    • Removed “root” parameter from CreateXcbSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.

    • Adjusted wording of issue #1 and added agreed upon resolution.

  • Revision 3, 2015-10-14 (Ian Elliott)

    • Removed “root” parameter from CreateXcbSurfaceKHR() in one more place.

  • Revision 4, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_xcb_surface to VK_KHR_xcb_surface.

  • Revision 5, 2015-10-23 (Daniel Rakos)

    • Added allocation callbacks to vkCreateXcbSurfaceKHR.

  • Revision 6, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

VK_KHR_xlib_surface

Name String

VK_KHR_xlib_surface

Extension Type

Instance extension

Registered Extension Number

5

Revision

6

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2015-11-28

IP Status

No known IP claims.

Contributors
  • Patrick Doane, Blizzard

  • Faith Ekstrand, Intel

  • Ian Elliott, LunarG

  • Courtney Goeltzenleuchter, LunarG

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Antoine Labour, Google

  • Jon Leech, Khronos

  • David Mao, AMD

  • Norbert Nopper, Freescale

  • Alon Or-bach, Samsung

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Ray Smith, ARM

  • Jeff Vigil, Qualcomm

  • Chia-I Wu, LunarG

Description

The VK_KHR_xlib_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to an X11 Window, using the Xlib client-side library, as well as a query to determine support for rendering via Xlib.

New Enum Constants
  • VK_KHR_XLIB_SURFACE_EXTENSION_NAME

  • VK_KHR_XLIB_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR

Issues

1) Does X11 need a way to query for compatibility between a particular physical device and a specific screen? This would be a more general query than vkGetPhysicalDeviceSurfaceSupportKHR; if it returned VK_TRUE, then the physical device could be assumed to support presentation to any window on that screen.

RESOLVED: Yes, this is needed for toolkits that want to create a VkDevice before creating a window. To ensure the query is reliable, it must be made against a particular X visual rather than the screen in general.

Version History
  • Revision 1, 2015-09-23 (Jesse Hall)

    • Initial draft, based on the previous contents of VK_EXT_KHR_swapchain (later renamed VK_EXT_KHR_surface).

  • Revision 2, 2015-10-02 (James Jones)

    • Added presentation support query for (Display*, VisualID) pair.

    • Removed “root” parameter from CreateXlibSurfaceKHR(), as it is redundant when a window on the same screen is specified as well.

    • Added appropriate X errors.

    • Adjusted wording of issue #1 and added agreed upon resolution.

  • Revision 3, 2015-10-14 (Ian Elliott)

    • Renamed this extension from VK_EXT_KHR_x11_surface to VK_EXT_KHR_xlib_surface.

  • Revision 4, 2015-10-26 (Ian Elliott)

    • Renamed from VK_EXT_KHR_xlib_surface to VK_KHR_xlib_surface.

  • Revision 5, 2015-11-03 (Daniel Rakos)

    • Added allocation callbacks to vkCreateXlibSurfaceKHR.

  • Revision 6, 2015-11-28 (Daniel Rakos)

    • Updated the surface create function to take a pCreateInfo structure.

VK_EXT_attachment_feedback_loop_dynamic_state

Name String

VK_EXT_attachment_feedback_loop_dynamic_state

Extension Type

Device extension

Registered Extension Number

525

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
  • Mike Blumenkrantz zmike

Extension Proposal

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

2

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 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_depth_bias_control

Name String

VK_EXT_depth_bias_control

Extension Type

Device extension

Registered Extension Number

284

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Special Use
Contact
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
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_clip_enable

Name String

VK_EXT_depth_clip_enable

Extension Type

Device extension

Registered Extension Number

103

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Special Use
Contact
Other Extension Metadata
Last Modified Date

2018-12-20

Contributors
  • Daniel Rakos, AMD

  • Henri Verbeet, CodeWeavers

  • Jeff Bolz, NVIDIA

  • Philip Rebohle, DXVK

  • Tobias Hector, AMD

Description

This extension allows the depth clipping operation, that is normally implicitly controlled by VkPipelineRasterizationStateCreateInfo::depthClampEnable, to instead be controlled explicitly by VkPipelineRasterizationDepthClipStateCreateInfoEXT::depthClipEnable.

This is useful for translating DX content which assumes depth clamping is always enabled, but depth clip can be controlled by the DepthClipEnable rasterization state (D3D12_RASTERIZER_DESC).

New Enum Constants
  • VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME

  • VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
Other Extension Metadata
Last Modified Date

2017-06-22

Contributors
  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension removes the VkViewport minDepth and maxDepth restrictions that the values must be between 0.0 and 1.0, inclusive. It also removes the same restriction on VkPipelineDepthStencilStateCreateInfo minDepthBounds and maxDepthBounds. Finally it removes the restriction on the depth value in VkClearDepthStencilValue.

New Enum Constants
  • VK_EXT_DEPTH_RANGE_UNRESTRICTED_EXTENSION_NAME

  • VK_EXT_DEPTH_RANGE_UNRESTRICTED_SPEC_VERSION

Issues

1) How do VkViewport minDepth and maxDepth values outside of the 0.0 to 1.0 range interact with Primitive Clipping?

RESOLVED: The behavior described in Primitive Clipping still applies. If depth clamping is disabled the depth values are still clipped to 0 ≤ zc ≤ wc before the viewport transform. If depth clamping is enabled the above equation is ignored and the depth values are instead clamped to the VkViewport minDepth and maxDepth values, which in the case of this extension can be outside of the 0.0 to 1.0 range.

2) What happens if a resulting depth fragment is outside of the 0.0 to 1.0 range and the depth buffer is fixed-point rather than floating-point?

RESOLVED: This situation can also arise without this extension (when fragment shaders replace depth values, for example), and this extension does not change the behavior, which is defined in the Depth Test section of the Fragment Operations chapter.

Version History
  • Revision 1, 2017-06-22 (Piers Daniell)

    • Internal revisions

VK_EXT_discard_rectangles

Name String

VK_EXT_discard_rectangles

Extension Type

Device extension

Registered Extension Number

100

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2023-01-18

Interactions and External Dependencies
Contributors
  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension provides additional orthogonally aligned “discard rectangles” specified in framebuffer-space coordinates that restrict rasterization of all points, lines and triangles.

From zero to an implementation-dependent limit (specified by maxDiscardRectangles) number of discard rectangles can be operational at once. When one or more discard rectangles are active, rasterized fragments can either survive if the fragment is within any of the operational discard rectangles (VK_DISCARD_RECTANGLE_MODE_INCLUSIVE_EXT mode) or be rejected if the fragment is within any of the operational discard rectangles (VK_DISCARD_RECTANGLE_MODE_EXCLUSIVE_EXT mode).

These discard rectangles operate orthogonally to the existing scissor test functionality. The discard rectangles can be different for each physical device in a device group by specifying the device mask and setting discard rectangle dynamic state.

Version 2 of this extension introduces new dynamic states VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT and VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT, and the corresponding functions vkCmdSetDiscardRectangleEnableEXT and vkCmdSetDiscardRectangleModeEXT. Applications that use these dynamic states must ensure the implementation advertises at least specVersion 2 of this extension.

New Enum Constants
  • VK_EXT_DISCARD_RECTANGLES_EXTENSION_NAME

  • VK_EXT_DISCARD_RECTANGLES_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_ENABLE_EXT

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_EXT

    • VK_DYNAMIC_STATE_DISCARD_RECTANGLE_MODE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISCARD_RECTANGLE_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_DISCARD_RECTANGLE_STATE_CREATE_INFO_EXT

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_dynamic_rendering_unused_attachments

Name String

VK_EXT_dynamic_rendering_unused_attachments

Extension Type

Device extension

Registered Extension Number

500

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

         VK_KHR_get_physical_device_properties2
         or
         Version 1.1
     and
     VK_KHR_dynamic_rendering
or
Version 1.3

Contact
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 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

2

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_VERSION_1_1

  • Interacts with VK_EXT_blend_operation_advanced

  • Interacts with VK_EXT_conservative_rasterization

  • Interacts with VK_EXT_depth_clip_control

  • Interacts with VK_EXT_depth_clip_enable

  • Interacts with VK_EXT_line_rasterization

  • Interacts with VK_EXT_provoking_vertex

  • Interacts with VK_EXT_sample_locations

  • Interacts with VK_EXT_transform_feedback

  • Interacts with VK_KHR_maintenance2

  • Interacts with VK_NV_clip_space_w_scaling

  • Interacts with VK_NV_coverage_reduction_mode

  • Interacts with VK_NV_fragment_coverage_to_color

  • Interacts with VK_NV_framebuffer_mixed_samples

  • Interacts with VK_NV_representative_fragment_test

  • Interacts with VK_NV_shading_rate_image

  • Interacts with VK_NV_viewport_swizzle

Contact
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 Enum Constants
  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_ALPHA_TO_COVERAGE_ENABLE_EXT

    • VK_DYNAMIC_STATE_ALPHA_TO_ONE_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT

    • VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLAMP_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_ENABLE_EXT

    • VK_DYNAMIC_STATE_POLYGON_MODE_EXT

    • VK_DYNAMIC_STATE_RASTERIZATION_SAMPLES_EXT

    • VK_DYNAMIC_STATE_SAMPLE_MASK_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_PROPERTIES_EXT

If VK_EXT_depth_clip_enable is supported:

If VK_EXT_transform_feedback is supported:

If VK_KHR_maintenance2 or Version 1.1 is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT

Issues

1) What about the VkPipelineMultisampleStateCreateInfo state sampleShadingEnable and minSampleShading?

UNRESOLVED
  • sampleShadingEnable 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

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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 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_frame_boundary

Name String

VK_EXT_frame_boundary

Extension Type

Device extension

Registered Extension Number

376

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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 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_hdr_metadata

Name String

VK_EXT_hdr_metadata

Extension Type

Device extension

Registered Extension Number

106

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2018-12-19

IP Status

No known IP claims.

Contributors
  • Courtney Goeltzenleuchter, Google

Description

This extension defines two new structures and a function to assign SMPTE (the Society of Motion Picture and Television Engineers) 2086 metadata and CTA (Consumer Technology Association) 861.3 metadata to a swapchain. The metadata includes the color primaries, white point, and luminance range of the reference monitor, which all together define the color volume containing all the possible colors the reference monitor can produce. The reference monitor is the display where creative work is done and creative intent is established. To preserve such creative intent as much as possible and achieve consistent color reproduction on different viewing displays, it is useful for the display pipeline to know the color volume of the original reference monitor where content was created or tuned. This avoids performing unnecessary mapping of colors that are not displayable on the original reference monitor. The metadata also includes the maxContentLightLevel and maxFrameAverageLightLevel as defined by CTA 861.3.

While the intended purpose of the metadata is to assist in the transformation between different color volumes of different displays and help achieve better color reproduction, it is not in the scope of this extension to define how exactly the metadata should be used in such a process. It is up to the implementation to determine how to make use of the metadata.

New Commands
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?

PROPOSED: No, Vulkan does not provide queries for state that the application can track on its own.

2) Should we specify default if not specified by the application?

PROPOSED: No, that leaves the default up to the display.

Version History
  • Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)

    • Initial version

  • Revision 2, 2018-12-19 (Courtney Goeltzenleuchter)

    • Correct implicit validity for VkHdrMetadataEXT structure

VK_EXT_host_image_copy

Name String

VK_EXT_host_image_copy

Extension Type

Device extension

Registered Extension Number

271

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

         VK_KHR_get_physical_device_properties2
         or
         Version 1.1
     and
     VK_KHR_copy_commands2
     and
     VK_KHR_format_feature_flags2
or
Version 1.3

Contact
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_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 Enum Constants
  • VK_EXT_HOST_IMAGE_COPY_EXTENSION_NAME

  • VK_EXT_HOST_IMAGE_COPY_SPEC_VERSION

  • Extending VkFormatFeatureFlagBits2:

    • VK_FORMAT_FEATURE_2_HOST_IMAGE_TRANSFER_BIT_EXT

  • Extending VkImageUsageFlagBits:

    • VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_IMAGE_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_MEMORY_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_IMAGE_INFO_EXT

    • VK_STRUCTURE_TYPE_HOST_IMAGE_COPY_DEVICE_PERFORMANCE_QUERY_EXT

    • VK_STRUCTURE_TYPE_HOST_IMAGE_LAYOUT_TRANSITION_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_TO_MEMORY_COPY_EXT

    • VK_STRUCTURE_TYPE_MEMORY_TO_IMAGE_COPY_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_IMAGE_COPY_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SUBRESOURCE_HOST_MEMCPY_SIZE_EXT

Issues

1) When uploading data to an image, the data is usually loaded from disk. Why not have the application load the data directly into a VkDeviceMemory bound to a buffer (instead of host memory), and use vkCmdCopyBufferToImage? The same could be done when downloading data from an image.

RESOLVED: This may not always be possible. Complicated Vulkan applications such as game engines often have decoupled subsystems for streaming data and rendering. It may be unreasonable to require the streaming subsystem to coordinate with the rendering subsystem to allocate memory on its behalf, especially as Vulkan may not be the only API supported by the engine. In emulation layers, the image data is necessarily provided by the application in host memory, so an optimization as suggested is not possible. Most importantly, the device memory may not be mappable by an application, but still accessible to the driver.

2) Are optimalBufferCopyOffsetAlignment and optimalBufferCopyRowPitchAlignment applicable to host memory as well with the functions introduced by this extension? Or should there be new limits?

RESOLVED: No alignment requirements for the host memory pointer.

3) Should there be granularity requirements for image offsets and extents?

RESOLVED: No granularity requirements, i.e. a granularity of 1 pixel (for non-compressed formats) and 1 texel block (for compressed formats) is assumed.

4) How should the application deal with layout transitions before or after copying to or from images?

RESOLVED: An existing issue with linear images is that when emulating other APIs, it is impossible to know when to transition them as they are written to by the host and then used bindlessly. The copy operations in this extension are affected by the same limitation. A new command is thus introduced by this extension to address this problem by allowing the host to perform an image layout transition between a handful of layouts.

Version History
  • Revision 0, 2021-01-20 (Faith Ekstrand)

    • Initial idea and xml

  • Revision 1, 2023-04-26 (Shahbaz Youssefi)

    • Initial revision

VK_EXT_layer_settings

Name String

VK_EXT_layer_settings

Extension Type

Instance extension

Registered Extension Number

497

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies

None

Contact
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 struct that can be included in the pNext chain of the VkInstanceCreateInfo structure passed as the pCreateInfo parameter of vkCreateInstance.

The structure contains an array of VkLayerSettingEXT structure values that configure specific features of layers.

Example

VK_EXT_layer_settings is implemented by the Vulkan Profiles layer.

It allows the profiles layer tests used by the profiles layer C.I. to programmatically configure the layer for each test without affecting the C.I. environment, allowing to run multiple tests concurrently.

const char* profile_file_data = JSON_TEST_FILES_PATH "VP_KHR_roadmap_2022.json";
const char* profile_name_data = "VP_KHR_roadmap_2022";
VkBool32 emulate_portability_data = VK_TRUE;
const char* simulate_capabilities[] = {
    "SIMULATE_API_VERSION_BIT",
    "SIMULATE_FEATURES_BIT",
    "SIMULATE_PROPERTIES_BIT",
    "SIMULATE_EXTENSIONS_BIT",
    "SIMULATE_FORMATS_BIT",
    "SIMULATE_QUEUE_FAMILY_PROPERTIES_BIT"
};
const char* debug_reports[] = {
    "DEBUG_REPORT_ERROR_BIT",
    "DEBUG_REPORT_WARNING_BIT",
    "DEBUG_REPORT_NOTIFICATION_BIT",
    "DEBUG_REPORT_DEBUG_BIT"
};

const VkLayerSettingEXT settings[] = {
     {kLayerName, kLayerSettingsProfileFile, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_file_data},
     {kLayerName, kLayerSettingsProfileName, VK_LAYER_SETTING_TYPE_STRING_EXT, 1, &profile_name_data},
     {kLayerName, kLayerSettingsEmulatePortability, VK_LAYER_SETTING_TYPE_BOOL32_EXT, 1, &emulate_portability_data},
     {kLayerName, kLayerSettingsSimulateCapabilities, VK_LAYER_SETTING_TYPE_STRING_EXT,
        static_cast<uint32_t>(std::size(simulate_capabilities)), simulate_capabilities},
     {kLayerName, kLayerSettingsDebugReports, VK_LAYER_SETTING_TYPE_STRING_EXT,
        static_cast<uint32_t>(std::size(debug_reports)), debug_reports}
};

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

VkInstanceCreateInfo inst_create_info = {};
...
inst_create_info.pNext = &layer_settings_create_info;
vkCreateInstance(&inst_create_info, nullptr, &_instances);
Note

The 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 Enum Constants
  • VK_EXT_LAYER_SETTINGS_EXTENSION_NAME

  • VK_EXT_LAYER_SETTINGS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT

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_nested_command_buffer

Name String

VK_EXT_nested_command_buffer

Extension Type

Device extension

Registered Extension Number

452

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2023-09-18

Contributors
  • Daniel Story, Nintendo

  • Peter Kohaut, NVIDIA

  • Shahbaz Youssefi, Google

  • Slawomir Grajewski, Intel

  • Stu Smith, AMD

Description

With core Vulkan it is not legal to call vkCmdExecuteCommands when recording a secondary command buffer. This extension relaxes that restriction, allowing secondary command buffers to execute other secondary command buffers.

New Enum Constants
  • VK_EXT_NESTED_COMMAND_BUFFER_EXTENSION_NAME

  • VK_EXT_NESTED_COMMAND_BUFFER_SPEC_VERSION

  • Extending VkRenderingFlagBits:

    • VK_RENDERING_CONTENTS_INLINE_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NESTED_COMMAND_BUFFER_PROPERTIES_EXT

  • Extending VkSubpassContents:

    • VK_SUBPASS_CONTENTS_INLINE_AND_SECONDARY_COMMAND_BUFFERS_EXT

Issues

1) The Command Buffer Levels property for the Vulkan commands comes from the cmdbufferlevel attribute in vk.xml for the command, and it is currently not possible to modify this attribute based on whether an extension is enabled. For this extension we want the cmdbufferlevel attribute for vkCmdExecuteCommands to be primary,secondary when this extension is enabled and primary otherwise.

RESOLVED: The cmdbufferlevel attribute for vkCmdExecuteCommands has been changed to primary,secondary and a new VUID added to prohibit recording this command in a secondary command buffer unless this extension is enabled.

Version History
  • Revision 1, 2023-09-18 (Piers Daniell)

    • Internal revisions

VK_EXT_opacity_micromap

Name String

VK_EXT_opacity_micromap

Extension Type

Device extension

Registered Extension Number

397

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
Extension Proposal

VK_EXT_opacity_micromap

Other Extension Metadata
Last Modified Date

2022-08-24

Interactions and External Dependencies
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:

New Object Types
New Enum Constants
  • VK_EXT_OPACITY_MICROMAP_EXTENSION_NAME

  • VK_EXT_OPACITY_MICROMAP_SPEC_VERSION

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_MICROMAP_READ_BIT_EXT

    • VK_ACCESS_2_MICROMAP_WRITE_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT

    • VK_BUFFER_USAGE_MICROMAP_STORAGE_BIT_EXT

  • Extending VkBuildAccelerationStructureFlagBitsKHR:

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_EXT

  • Extending VkGeometryInstanceFlagBitsKHR:

    • VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_GEOMETRY_INSTANCE_FORCE_OPACITY_MICROMAP_2_STATE_EXT

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_MICROMAP_EXT

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT

  • Extending VkQueryType:

    • VK_QUERY_TYPE_MICROMAP_COMPACTED_SIZE_EXT

    • VK_QUERY_TYPE_MICROMAP_SERIALIZATION_SIZE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_OPACITY_MICROMAP_EXT

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_TO_MEMORY_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_SIZES_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_VERSION_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_PROPERTIES_EXT

Reference Code
uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level)
{
    u = clamp(u, 0.0f, 1.0f);
    v = clamp(v, 0.0f, 1.0f);

    uint32_t iu, iv, iw;

    // Quantize barycentric coordinates
    float fu = u * (1u << level);
    float fv = v * (1u << level);

    iu = (uint32_t)fu;
    iv = (uint32_t)fv;

    float uf = fu - float(iu);
    float vf = fv - float(iv);

    if (iu >= (1u << level)) iu = (1u << level) - 1u;
    if (iv >= (1u << level)) iv = (1u << level) - 1u;

    uint32_t iuv = iu + iv;

    if (iuv >= (1u << level))
        iu -= iuv - (1u << level) + 1u;

    iw = ~(iu + iv);

    if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw;

    uint32_t b0 = ~(iu ^ iw);
    b0 &= ((1u << level) - 1u);
    uint32_t t = (iu ^ iv) & b0;

    uint32_t f = t;
    f ^= f >> 1u;
    f ^= f >> 2u;
    f ^= f >> 4u;
    f ^= f >> 8u;
    uint32_t b1 = ((f ^ iu) & ~b0) | t;

    // Interleave bits
    b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu;
    b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu;
    b0 = (b0 | (b0 << 2u)) & 0x33333333u;
    b0 = (b0 | (b0 << 1u)) & 0x55555555u;
    b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu;
    b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu;
    b1 = (b1 | (b1 << 2u)) & 0x33333333u;
    b1 = (b1 | (b1 << 1u)) & 0x55555555u;

    return b0 | (b1 << 1u);
}
Issues

(1) Is the build actually similar to an acceleration structure build?

  • Resolved: The build should be much lighter-weight than an acceleration structure build, but the infrastructure is similar enough that it makes sense to keep the concepts compatible.

(2) Why does VkMicromapUsageEXT not have type/pNext?

  • Resolved: There can be a very large number of these structures, so doubling the size of these can be significant memory consumption. Also, an application may be loading these directly from a file which is more compatible with it being a flat structure. The including structures are extensible and are probably a more suitable place to add extensibility.

(3) Why is there a SPIR-V extension?

  • Resolved: There is a ray flag. To be consistent with how the existing ray tracing extensions work that ray flag needs its own extension.

(4) Should there be indirect micromap build?

  • Resolved: Not for now. There is more in-depth usage metadata required and it seems less likely that something like a GPU culling system would need to change the counts for a micromap.

(5) Should micromaps have a micromap device address?

  • Resolved: There is no need right now (can just use the handle) but that is a bit different from acceleration structures, though the two are not completely parallel in their usage.

(6) Why are the alignment requirements defined as a mix of hardcoded values and caps?

  • Resolved: This is most parallel with the definition of VK_KHR_acceleration_structure and maintaining commonality makes it easier for applications to share memory.

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_queue_family_foreign

Name String

VK_EXT_queue_family_foreign

Extension Type

Device extension

Registered Extension Number

127

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Contact
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_shader_object

Name String

VK_EXT_shader_object

Extension Type

Device extension

Registered Extension Number

483

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

         VK_KHR_get_physical_device_properties2
         or
         Version 1.1
     and
     VK_KHR_dynamic_rendering
or
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_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
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

  • Constantine Shablya, Collabora

  • Daniel Koch, NVIDIA

  • Alyssa Rosenzweig, Collabora

  • Mike Blumenkrantz, Valve

  • Samuel Pitoiset, Valve

  • Qun Lin, AMD

  • Spencer Fricke, LunarG

  • Soroush Faghihi Kashani, Imagination

Description

This extension introduces a new VkShaderEXT object type which represents a single compiled shader stage. Shader objects provide a more flexible alternative to VkPipeline objects, which may be helpful in certain use cases.

New Object Types
New Bitmasks
New Enum Constants
  • VK_EXT_SHADER_OBJECT_EXTENSION_NAME

  • VK_EXT_SHADER_OBJECT_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_SHADER_EXT

  • Extending VkResult:

    • VK_ERROR_INCOMPATIBLE_SHADER_BINARY_EXT

    • VK_INCOMPATIBLE_SHADER_BINARY_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_OBJECT_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SHADER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SHADER_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT

If VK_EXT_subgroup_size_control or Version 1.3 is supported:

  • Extending VkShaderCreateFlagBitsEXT:

    • VK_SHADER_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT

    • VK_SHADER_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT

If VK_KHR_device_group or Version 1.1 is supported:

If VK_KHR_fragment_shading_rate is supported:

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_tile_image

Name String

VK_EXT_shader_tile_image

Extension Type

Device extension

Registered Extension Number

396

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Contact
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
Contributors
  • Sandeep Kakarlapudi, Arm

  • Jan-Harald Fredriksen, Arm

  • James Fitzpatrick, Imagination

  • Andrew Garrard, Imagination

  • Jeff Leger, Qualcomm

  • Huilong Wang, Huawei

  • Graeme Leese, Broadcom

  • Hans-Kristian Arntzen, Valve

  • Tobias Hector, AMD

  • Jeff Bolz, NVIDIA

  • Shahbaz Youssefi, Google

Description

This extension allows fragment shader invocations to read color, depth and stencil values at their pixel location in rasterization order. The functionality is only available when using dynamic render passes introduced by VK_KHR_dynamic_rendering. Example use cases are programmable blending and deferred shading.

See fragment shader tile image reads for more information.

New Enum Constants
  • VK_EXT_SHADER_TILE_IMAGE_EXTENSION_NAME

  • VK_EXT_SHADER_TILE_IMAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TILE_IMAGE_PROPERTIES_EXT

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_transform_feedback

Name String

VK_EXT_transform_feedback

Extension Type

Device extension

Registered Extension Number

29

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Special Uses
Contact
Other Extension Metadata
Last Modified Date

2018-10-09

Contributors
  • Baldur Karlsson, Valve

  • Boris Zanin, Mobica

  • Daniel Rakos, AMD

  • Donald Scorgie, Imagination

  • Henri Verbeet, CodeWeavers

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Barker, Unity

  • Jesse Hall, Google

  • Pierre-Loup Griffais, Valve

  • Philip Rebohle, DXVK

  • Ruihao Zhang, Qualcomm

  • Samuel Pitoiset, Valve

  • Slawomir Grajewski, Intel

  • Stu Smith, Imagination Technologies

Description

This extension adds transform feedback to the Vulkan API by exposing the SPIR-V TransformFeedback and GeometryStreams capabilities to capture vertex, tessellation or geometry shader outputs to one or more buffers. It adds API functionality to bind transform feedback buffers to capture the primitives emitted by the graphics pipeline from SPIR-V outputs decorated for transform feedback. The transform feedback capture can be paused and resumed by way of storing and retrieving a byte counter. The captured data can be drawn again where the vertex count is derived from the byte counter without CPU intervention. If the implementation is capable, a vertex stream other than zero can be rasterized.

All these features are designed to match the full capabilities of OpenGL core transform feedback functionality and beyond. Many of the features are optional to allow base OpenGL ES GPUs to also implement this extension.

The primary purpose of the functionality exposed by this extension is to support translation layers from other 3D APIs. This functionality is not considered forward looking, and is not expected to be promoted to a KHR extension or to core Vulkan. Unless this is needed for translation, it is recommended that developers use alternative techniques of using the GPU to process and capture vertex data.

New Enum Constants
  • VK_EXT_TRANSFORM_FEEDBACK_EXTENSION_NAME

  • VK_EXT_TRANSFORM_FEEDBACK_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT

  • Extending VkQueryType:

    • VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT

Issues

1) Should we include pause/resume functionality?

RESOLVED: Yes, this is needed to ease layering other APIs which have this functionality. To pause use vkCmdEndTransformFeedbackEXT and provide valid buffer handles in the pCounterBuffers array and offsets in the pCounterBufferOffsets array for the implementation to save the resume points. Then to resume use vkCmdBeginTransformFeedbackEXT with the previous pCounterBuffers and pCounterBufferOffsets values. Between the pause and resume there needs to be a memory barrier for the counter buffers with a source access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT to a destination access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT.

2) How does this interact with multiview?

RESOLVED: Transform feedback cannot be made active in a render pass with multiview enabled.

3) How should queries be done?

RESOLVED: There is a new query type VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT. A query pool created with this type will capture 2 integers - numPrimitivesWritten and numPrimitivesNeeded - for the specified vertex stream output from the last pre-rasterization shader stage. The vertex stream output queried is zero by default, but can be specified with the new vkCmdBeginQueryIndexedEXT and vkCmdEndQueryIndexedEXT commands.

Version History
  • Revision 1, 2018-10-09 (Piers Daniell)

    • Internal revisions

List of Provisional Extensions

VK_KHR_portability_subset

Name String

VK_KHR_portability_subset

Extension Type

Device extension

Registered Extension Number

164

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
  • This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact
Other Extension Metadata
Last Modified Date

2020-07-21

IP Status

No known IP claims.

Contributors
  • Bill Hollings, The Brenwill Workshop Ltd.

  • Daniel Koch, NVIDIA

  • Dzmitry Malyshau, Mozilla

  • Chip Davis, CodeWeavers

  • Dan Ginsburg, Valve

  • Mike Weiblen, LunarG

  • Neil Trevett, NVIDIA

  • Alexey Knyazev, Independent

Description

The VK_KHR_portability_subset extension allows a non-conformant Vulkan implementation to be built on top of another non-Vulkan graphics API, and identifies differences between that implementation and a fully-conformant native Vulkan implementation.

This extension provides Vulkan implementations with the ability to mark otherwise-required capabilities as unsupported, or to establish additional properties and limits that the application should adhere to in order to guarantee portable behavior and operation across platforms, including platforms where Vulkan is not natively supported.

The goal of this specification is to document, and make queryable, capabilities which are required to be supported by a fully-conformant Vulkan 1.0 implementation, but may be optional for an implementation of the Vulkan 1.0 Portability Subset.

The intent is that this extension will be advertised only on implementations of the Vulkan 1.0 Portability Subset, and not on conformant implementations of Vulkan 1.0. Fully-conformant Vulkan implementations provide all the required capabilities, and so will not provide this extension. Therefore, the existence of this extension can be used to determine that an implementation is likely not fully conformant with the Vulkan spec.

If this extension is supported by the Vulkan implementation, the application must enable this extension.

This extension defines several new structures that can be chained to the existing structures used by certain standard Vulkan calls, in order to query for non-conformant portable behavior.

New Enum Constants
  • VK_KHR_PORTABILITY_SUBSET_EXTENSION_NAME

  • VK_KHR_PORTABILITY_SUBSET_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_PROPERTIES_KHR

Issues

None.

Version History
  • Revision 1, 2020-07-21 (Bill Hollings)

    • Initial draft.

List of Deprecated Extensions

VK_KHR_16bit_storage

Name String

VK_KHR_16bit_storage

Extension Type

Device extension

Registered Extension Number

84

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, ARM

  • Jan-Harald Fredriksen, ARM

  • Joerg Wagner, ARM

  • Neil Henning, Codeplay

  • Jeff Bolz, Nvidia

  • Daniel Koch, Nvidia

  • David Neto, Google

  • John Kessenich, Google

Description

The VK_KHR_16bit_storage extension allows use of 16-bit types in shader input and output interfaces, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 16-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class. This extension allows 16-bit variables to be declared and used as user-defined shader inputs and outputs but does not change location assignment and component assignment rules.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. However, if Vulkan 1.1 is supported and this extension is not, the storageBuffer16BitAccess capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_16BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_16BIT_STORAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR

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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2018-02-05

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Alexander Galazin, Arm

Description

The VK_KHR_8bit_storage extension allows use of 8-bit types in uniform and storage buffers, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 8-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class.

The StorageBuffer8BitAccess capability must be supported by all implementations of this extension. The other capabilities are optional.

Promotion to Vulkan 1.2

Functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the StorageBuffer8BitAccess capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_8BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_8BIT_STORAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR

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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

Description

This extension provides versions of vkBindBufferMemory and vkBindImageMemory that allow multiple bindings to be performed at once, and are extensible.

This extension also introduces VK_IMAGE_CREATE_ALIAS_BIT_KHR, which allows “identical” images that alias the same memory to interpret the contents consistently, even across image layout changes.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_BIND_MEMORY_2_EXTENSION_NAME

  • VK_KHR_BIND_MEMORY_2_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_ALIAS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR

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

1

Ratification Status

Ratified

Extension and Version Dependencies
SPIR-V Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2019-06-24

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Neil Henning, AMD

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Baldur Karlsson, Valve

  • Jan-Harald Fredriksen, Arm

Description

This extension allows the application to query a 64-bit buffer device address value for a buffer, which can be used to access the buffer memory via the PhysicalStorageBuffer storage class in the GL_EXT_buffer_reference GLSL extension and SPV_KHR_physical_storage_buffer SPIR-V extension.

Another way to describe this extension is that it adds “pointers to buffer memory in shaders”. By calling vkGetBufferDeviceAddress with a VkBuffer, it will return a VkDeviceAddress value which represents the address of the start of the buffer.

vkGetBufferOpaqueCaptureAddress and vkGetDeviceMemoryOpaqueCaptureAddress allow opaque addresses for buffers and memory objects to be queried for the current process. A trace capture and replay tool can then supply these addresses to be used at replay time to match the addresses used when the trace was captured. To enable tools to insert these queries, new memory allocation flags must be specified for memory objects that will be bound to buffers accessed via the PhysicalStorageBuffer storage class. Note that this mechanism is intended only to support capture/replay tools, and is not recommended for use in other applications.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the bufferDeviceAddress feature is optional. The original type, enum and command names are still available as aliases of the core functionality.

Promotion to Vulkan 1.3

Support for the bufferDeviceAddress feature is mandatory in Vulkan 1.3, regardless of whether this extension is supported.

New 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
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

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2020-07-06

Contributors
  • Jeff Leger, Qualcomm

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

Description

This extension provides extensible versions of the Vulkan buffer and image copy commands. The new commands are functionally identical to the core commands, except that their copy parameters are specified using extensible structures that can be used to pass extension-specific information.

The following extensible copy commands are introduced with this extension: vkCmdCopyBuffer2KHR, vkCmdCopyImage2KHR, vkCmdCopyBufferToImage2KHR, vkCmdCopyImageToBuffer2KHR, vkCmdBlitImage2KHR, and vkCmdResolveImage2KHR. Each command contains an *Info2KHR structure parameter that includes sType/pNext members. Lower level structures describing each region to be copied are also extended with sType/pNext members.

New Enum Constants
  • VK_KHR_COPY_COMMANDS_2_EXTENSION_NAME

  • VK_KHR_COPY_COMMANDS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BLIT_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_COPY_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_TO_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_BLIT_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR

    • VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

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

1

Ratification Status

Ratified

Extension and Version Dependencies

     VK_KHR_multiview
     and
     VK_KHR_maintenance2
or
Version 1.1

Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2018-02-07

Contributors
  • Tobias Hector

  • Jeff Bolz

Description

This extension provides a new entry point to create render passes in a way that can be easily extended by other extensions through the substructures of render pass creation. The Vulkan 1.0 render pass creation sub-structures do not include sType/pNext members. Additionally, the render pass begin/next/end commands have been augmented with new extensible structures for passing additional subpass information.

The VkRenderPassMultiviewCreateInfo and VkInputAttachmentAspectReference structures that extended the original VkRenderPassCreateInfo are not accepted into the new creation functions, and instead their parameters are folded into this extension as follows:

The details of these mappings are explained fully in the new structures.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME

  • VK_KHR_CREATE_RENDERPASS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR

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

3

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Faith Ekstrand, Intel

Description

This extension enables resources to be bound to a dedicated allocation, rather than suballocated. For any particular resource, applications can query whether a dedicated allocation is recommended, in which case using a dedicated allocation may improve the performance of access to that resource. Normal device memory allocations must support multiple resources per allocation, memory aliasing and sparse binding, which could interfere with some optimizations. Applications should query the implementation for when a dedicated allocation may be beneficial by adding a VkMemoryDedicatedRequirementsKHR structure to the pNext chain of the VkMemoryRequirements2 structure passed as the pMemoryRequirements parameter of a call to vkGetBufferMemoryRequirements2 or vkGetImageMemoryRequirements2. Certain external handle types and external images or buffers may also depend on dedicated allocations on implementations that associate image or buffer metadata with OS-level memory objects.

This extension adds a two small structures to memory requirements querying and memory allocation: a new structure that flags whether an image/buffer should have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME

  • VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR

Examples
    // Create an image with a dedicated allocation based on the
    // implementation's preference

    VkImageCreateInfo imageCreateInfo =
    {
        // Image creation parameters
    };

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

    VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
        .pNext = NULL,
    };

    VkMemoryRequirements2 memoryRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
        .pNext = &dedicatedRequirements,
    };

    const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
        .pNext = NULL,
        .image = image
    };

    vkGetImageMemoryRequirements2(
        device,
        &imageRequirementsInfo,
        &memoryRequirements);

    if (dedicatedRequirements.prefersDedicatedAllocation) {
        // Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
        // pointing to the image we are allocating the memory for

        VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
            .pNext = NULL,
            .image = image,
            .buffer = VK_NULL_HANDLE,
        };

        VkMemoryAllocateInfo memoryAllocateInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
            .pNext = &dedicatedInfo,
            .allocationSize = memoryRequirements.size,
            .memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
        };

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

        // Bind the image to the memory

        vkBindImageMemory(
            device,
            image,
            memory,
            0);
    } else {
        // Take the normal memory sub-allocation path
    }
Version History
  • Revision 1, 2017-02-27 (James Jones)

    • Copy content from VK_NV_dedicated_allocation

    • Add some references to external object interactions to the overview.

  • Revision 2, 2017-03-27 (Faith Ekstrand)

    • Rework the extension to be query-based

  • Revision 3, 2017-07-31 (Faith Ekstrand)

    • Clarify that memory objects allocated with VkMemoryDedicatedAllocateInfoKHR can only have the specified resource bound and no others.

VK_KHR_depth_stencil_resolve

Name String

VK_KHR_depth_stencil_resolve

Extension Type

Device extension

Registered Extension Number

200

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation State
Contact
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 Bitmasks
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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

API Interactions
  • Interacts with VK_EXT_debug_report

  • Interacts with VK_KHR_push_descriptor

Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

Description

Applications may wish to update a fixed set of descriptors in a large number of descriptor sets very frequently, i.e. during initialization phase or if it is required to rebuild descriptor sets for each frame. For those cases it is also not unlikely that all information required to update a single descriptor set is stored in a single struct. This extension provides a way to update a fixed set of descriptors in a single VkDescriptorSet with a pointer to a user defined data structure describing the new descriptors.

Promotion to Vulkan 1.1

vkCmdPushDescriptorSetWithTemplateKHR is included as an interaction with VK_KHR_push_descriptor. If Vulkan 1.1 and VK_KHR_push_descriptor are supported, this is included by VK_KHR_push_descriptor.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME

  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_SPEC_VERSION

  • Extending VkDescriptorUpdateTemplateType:

    • VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET_KHR

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR

If VK_KHR_push_descriptor is supported:

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

4

Ratification Status

Ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_KHR_bind_memory2

  • Interacts with VK_KHR_surface

  • Interacts with VK_KHR_swapchain

SPIR-V Dependencies
Deprecation State
Contact
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:

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 Enum Constants
  • VK_KHR_DEVICE_GROUP_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_SPEC_VERSION

  • Extending VkDependencyFlagBits:

    • VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR

  • Extending VkMemoryAllocateFlagBits:

    • VK_MEMORY_ALLOCATE_DEVICE_MASK_BIT_KHR

  • Extending VkPeerMemoryFeatureFlagBits:

    • VK_PEER_MEMORY_FEATURE_COPY_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_COPY_SRC_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT_KHR

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_DISPATCH_BASE_KHR

    • VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR

If VK_KHR_bind_memory2 is supported:

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR

If VK_KHR_surface is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

If VK_KHR_swapchain is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

  • Extending VkSwapchainCreateFlagBitsKHR:

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

New Built-in Variables
New SPIR-V Capabilities
Version History
  • Revision 1, 2016-10-19 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-05-19 (Tobias Hector)

    • Removed extended memory bind functions to VK_KHR_bind_memory2, added dependency on that extension, and device-group-specific structs for those functions.

  • Revision 3, 2017-10-06 (Ian Elliott)

    • Corrected Vulkan 1.1 interactions with the WSI extensions. All Vulkan 1.1 WSI interactions are with the VK_KHR_swapchain extension.

  • Revision 4, 2017-10-10 (Jeff Bolz)

    • Rename “SFR” bits and structure members to use the phrase “split instance bind regions”.

VK_KHR_device_group_creation

Name String

VK_KHR_device_group_creation

Extension Type

Instance extension

Registered Extension Number

71

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2016-10-19

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension provides instance-level commands to enumerate groups of physical devices, and to create a logical device from a subset of one of those groups. Such a logical device can then be used with new features in the VK_KHR_device_group extension.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants
  • VK_KHR_DEVICE_GROUP_CREATION_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_CREATION_SPEC_VERSION

  • VK_MAX_DEVICE_GROUP_SIZE_KHR

  • Extending VkMemoryHeapFlagBits:

    • VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR

Examples
    VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
    // (not shown) fill out devCreateInfo as usual.
    uint32_t deviceGroupCount = 0;
    VkPhysicalDeviceGroupPropertiesKHR *props = NULL;

    // Query the number of device groups
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);

    // Allocate and initialize structures to query the device groups
    props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
    for (i = 0; i < deviceGroupCount; ++i) {
        props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
        props[i].pNext = NULL;
    }
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);

    // If the first device group has more than one physical device. create
    // a logical device using all of the physical devices.
    VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
    if (props[0].physicalDeviceCount > 1) {
        deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
        deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
        devCreateInfo.pNext = &deviceGroupInfo;
    }

    vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
    free(props);
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

1

Ratification Status

Ratified

Extension and Version Dependencies

None

Deprecation State
Contact
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 entry points vkCmdDrawIndirectCount and vkCmdDrawIndexedIndirectCount are optional. The original type, enum and command names are still available as aliases of the core functionality.

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

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation State
Contact
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 Enums
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

1

Ratification Status

Ratified

Extension and Version Dependencies

         VK_KHR_get_physical_device_properties2
         or
         Version 1.1
     and
     VK_KHR_depth_stencil_resolve
or
Version 1.2

API Interactions
  • Interacts with VK_AMD_mixed_attachment_samples

  • Interacts with VK_EXT_fragment_density_map

  • Interacts with VK_KHR_fragment_shading_rate

  • Interacts with VK_NVX_multiview_per_view_attributes

  • Interacts with VK_NV_framebuffer_mixed_samples

Deprecation State
Contact
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 Bitmasks
New Enum Constants
  • VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME

  • VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION

  • Extending VkAttachmentStoreOp:

    • VK_ATTACHMENT_STORE_OP_NONE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_INFO_KHR

If VK_KHR_fragment_shading_rate is supported:

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

    • VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History
  • Revision 1, 2021-10-06 (Tobias Hector)

    • Initial revision

VK_KHR_external_fence

Name String

VK_KHR_external_fence

Extension Type

Device extension

Registered Extension Number

114

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation State
Contact
Other Extension Metadata
Last Modified Date

2017-05-08

IP Status

No known IP claims.

Contributors
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
New Bitmasks
New Enum Constants