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
API Interactions
  • 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

If VK_EXT_debug_report is supported:

If VK_KHR_format_feature_flags2 is supported:

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:

(2) Can you give a more detailed comparison of differences and similarities between VK_NV_ray_tracing and VK_KHR_acceleration_structure?

DISCUSSION:

The following is a more detailed comparison of which commands, structures, and enums are aliased, changed, or removed.

(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/master/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/master/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, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource.

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, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application. Destroying the semaphore object will not destroy the handle or the handle’s reference to the underlying semaphore resource.

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_create_renderpass2
     or
     Version 1.2
and
     VK_KHR_get_physical_device_properties2
     or
     Version 1.1

API Interactions
  • 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

If VK_KHR_format_feature_flags2 is supported:

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
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 favour 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
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_conditional_rendering is supported:

If VK_EXT_descriptor_buffer is supported:

  • Extending VkBufferUsageFlagBits2KHR:

    • VK_BUFFER_USAGE_2_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_DESCRIPTOR_BUFFER_BIT_EXT

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_LINK_TIME_OPTIMIZATION_BIT_EXT

    • VK_PIPELINE_CREATE_2_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT

If VK_EXT_opacity_micromap is supported:

  • Extending VkPipelineCreateFlagBits2KHR:

    • VK_PIPELINE_CREATE_2_NO_PROTECTED_ACCESS_BIT_EXT

    • VK_PIPELINE_CREATE_2_PROTECTED_ACCESS_ONLY_BIT_EXT

If VK_EXT_transform_feedback is supported:

  • Extending VkBufferUsageFlagBits2KHR:

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_2_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

  • 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 VK_NV_displacement_micromap is supported:

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

  • 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
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_EXT_descriptor_buffer is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_DESCRIPTOR_BUFFER_EMBEDDED_SAMPLERS_INFO_EXT

    • VK_STRUCTURE_TYPE_SET_DESCRIPTOR_BUFFER_OFFSETS_INFO_EXT

If VK_KHR_push_descriptor is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_INFO_KHR

    • VK_STRUCTURE_TYPE_PUSH_DESCRIPTOR_SET_WITH_TEMPLATE_INFO_KHR

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

(2) Can you give a more detailed comparison of differences and similarities between VK_NV_ray_tracing and VK_KHR_ray_tracing_pipeline?

DISCUSSION:

The following is a more detailed comparison of which commands, structures, and enums are aliased, changed, or removed.

(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 optimisations 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/master/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: vkGetPhysicalDeviceSurfacePresentModes2EXT, vkGetPhysicalDeviceSurfaceCapabilities2KHR, and vkGetPhysicalDeviceSurfaceFormats2KHR.

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

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

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

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

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

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

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

    • Created initial Description section.

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

    • Fixed typos and other minor mistakes.

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

    • Improved the Description section.

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

    • Fixed compilation errors in example code.

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

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

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

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

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

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

    • Updated table 1 per input from the KHR TSG.

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

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

    • Updated enum-extending values using new convention.

    • Fixed the value of VK_SURFACE_PLATFORM_INFO_TYPE_SUPPORTED_KHR.

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

    • Rebased on Vulkan API version 126.

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

    • Marked issues 2 and 3 resolved.

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

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

    • Eliminated extraneous whitespace.

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

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

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

    • Replaced bool32_t with VkBool32.

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

    • Updated spec against latest core API header version.

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

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

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

    • Did miscellaneous cleanup, etc.

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

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

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

    • Restore single-field revision number.

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

    • Fix example code compilation errors.

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

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

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

    • Renamed from VK_EXT_KHR_swapchain to VK_EXT_KHR_surface.

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

    • Add error result VK_ERROR_SURFACE_LOST_KHR.

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

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

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

    • Other minor cleanup and consistency changes.

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

    • Renamed from VK_EXT_KHR_surface to VK_KHR_surface.

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

    • Added allocation callbacks to vkDestroySurfaceKHR.

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

    • Removed VkSurfaceTransformKHR. Use VkSurfaceTransformFlagBitsKHR instead.

    • Rename VkSurfaceCapabilitiesKHR member maxImageArraySize to maxImageArrayLayers.

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

    • Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

  • 2016-08-23 (Ian Elliott)

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

  • 2016-08-25 (Ian Elliott)

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

VK_KHR_surface_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/master/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
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

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
API Interactions
  • 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

If VK_KHR_format_feature_flags2 is supported:

  • Extending VkFormatFeatureFlagBits2:

    • VK_FORMAT_FEATURE_2_VIDEO_DECODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_2_VIDEO_DECODE_OUTPUT_BIT_KHR

Version History
  • Revision 1, 2018-6-11 (Peter Fang)

    • Initial draft

  • Revision 1.5, Nov 09 2018 (Tony Zlatinski)

    • API Updates

  • Revision 1.6, Jan 08 2020 (Tony Zlatinski)

    • API unify with the video_encode_queue spec

  • Revision 1.7, March 29 2021 (Tony Zlatinski)

    • Spec and API updates.

  • Revision 2, September 30 2021 (Jon Leech)

  • 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
API Interactions
  • 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

If VK_KHR_format_feature_flags2 is supported:

  • Extending VkFormatFeatureFlagBits2:

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_DPB_BIT_KHR

    • VK_FORMAT_FEATURE_2_VIDEO_ENCODE_INPUT_BIT_KHR

Version History
  • Revision 1, 2018-07-23 (Ahmed Abdelkhalek)

    • Initial draft

  • Revision 1.1, 10/29/2019 (Tony Zlatinski)

    • Updated the reserved spec tokens and renamed VkVideoEncoderKHR to VkVideoSessionKHR

  • Revision 1.6, Jan 08 2020 (Tony Zlatinski)

    • API unify with the video_decode_queue spec

  • Revision 2, March 29 2021 (Tony Zlatinski)

    • Spec and API updates.

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

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

Name String

VK_EXT_acquire_drm_display

Extension Type

Instance extension

Registered Extension Number

286

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2021-06-09

IP Status

No known IP claims.

Contributors
  • Simon Zeni, Status Holdings, Ltd.

Description

This extension allows an application to take exclusive control of a display using the Direct Rendering Manager (DRM) interface. When acquired, the display will be under full control of the application until the display is either released or the connector is unplugged.

New Enum Constants
  • VK_EXT_ACQUIRE_DRM_DISPLAY_EXTENSION_NAME

  • VK_EXT_ACQUIRE_DRM_DISPLAY_SPEC_VERSION

Issues

None.

Version History
  • Revision 1, 2021-05-11 (Simon Zeni)

    • Initial draft

VK_EXT_acquire_xlib_display

Name String

VK_EXT_acquire_xlib_display

Extension Type

Instance extension

Registered Extension Number

90

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-12-13

IP Status

No known IP claims.

Contributors
  • Dave Airlie, Red Hat

  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Liam Middlebrook, NVIDIA

  • Daniel Vetter, Intel

Description

This extension allows an application to take exclusive control on a display currently associated with an X11 screen. When control is acquired, the display will be deassociated from the X11 screen until control is released or the specified display connection is closed. Essentially, the X11 screen will behave as if the monitor has been unplugged until control is released.

New Enum Constants
  • VK_EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME

  • VK_EXT_ACQUIRE_XLIB_DISPLAY_SPEC_VERSION

Issues

1) Should vkAcquireXlibDisplayEXT take an RandR display ID, or a Vulkan display handle as input?

RESOLVED: A Vulkan display handle. Otherwise there would be no way to specify handles to displays that had been prevented from being included in the X11 display list by some native platform or vendor-specific mechanism.

2) How does an application figure out which RandR display corresponds to a Vulkan display?

RESOLVED: A new function, vkGetRandROutputDisplayEXT, is introduced for this purpose.

3) Should vkGetRandROutputDisplayEXT be part of this extension, or a general Vulkan / RandR or Vulkan / Xlib extension?

RESOLVED: To avoid yet another extension, include it in this extension.

Version History
  • Revision 1, 2016-12-13 (James Jones)

    • Initial draft

VK_EXT_astc_decode_mode

Name String

VK_EXT_astc_decode_mode

Extension Type

Device extension

Registered Extension Number

68

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2018-08-07

Contributors
  • Jan-Harald Fredriksen, Arm

Description

The existing specification requires that low dynamic range (LDR) ASTC textures are decompressed to FP16 values per component. In many cases, decompressing LDR textures to a lower precision intermediate result gives acceptable image quality. Source material for LDR textures is typically authored as 8-bit UNORM values, so decoding to FP16 values adds little value. On the other hand, reducing precision of the decoded result reduces the size of the decompressed data, potentially improving texture cache performance and saving power.

The goal of this extension is to enable this efficiency gain on existing ASTC texture data. This is achieved by giving the application the ability to select the intermediate decoding precision.

Three decoding options are provided:

  • Decode to VK_FORMAT_R16G16B16A16_SFLOAT precision: This is the default, and matches the required behavior in the core API.

  • Decode to VK_FORMAT_R8G8B8A8_UNORM precision: This is provided as an option in LDR mode.

  • Decode to VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 precision: This is provided as an option in both LDR and HDR mode. In this mode, negative values cannot be represented and are clamped to zero. The alpha component is ignored, and the results are as if alpha was 1.0. This decode mode is optional and support can be queried via the physical device properties.

New Enum Constants
  • VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME

  • VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT

Issues

1) Are implementations allowed to decode at a higher precision than what is requested?

RESOLUTION: No.
If we allow this, then this extension could be exposed on all
implementations that support ASTC.
But developers would have no way of knowing what precision was actually
used, and thus whether the image quality is sufficient at reduced
precision.

2) Should the decode mode be image view state and/or sampler state?

RESOLUTION: Image view state only.
Some implementations treat the different decode modes as different
texture formats.
Example

Create an image view that decodes to VK_FORMAT_R8G8B8A8_UNORM precision:

    VkImageViewASTCDecodeModeEXT decodeMode =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT,
        .pNext = NULL,
        .decodeMode = VK_FORMAT_R8G8B8A8_UNORM
    };

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

    VkImageView imageView;
    VkResult result = vkCreateImageView(
        device,
        &createInfo,
        NULL,
        &imageView);
Version History
  • Revision 1, 2018-08-07 (Jan-Harald Fredriksen)

    • Initial revision

VK_EXT_attachment_feedback_loop_dynamic_state

Name String

VK_EXT_attachment_feedback_loop_dynamic_state

Extension Type

Device extension

Registered Extension Number

525

Revision

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_blend_operation_advanced

Name String

VK_EXT_blend_operation_advanced

Extension Type

Device extension

Registered Extension Number

149

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-06-12

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension adds a number of “advanced” blending operations that can be used to perform new color blending operations, many of which are more complex than the standard blend modes provided by unextended Vulkan. This extension requires different styles of usage, depending on the level of hardware support and the enabled features:

  • If VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::advancedBlendCoherentOperations is VK_FALSE, the new blending operations are supported, but a memory dependency must separate each advanced blend operation on a given sample. VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT is used to synchronize reads using advanced blend operations.

  • If VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT::advancedBlendCoherentOperations is VK_TRUE, advanced blend operations obey primitive order just like basic blend operations.

In unextended Vulkan, the set of blending operations is limited, and can be expressed very simply. The VK_BLEND_OP_MIN and VK_BLEND_OP_MAX blend operations simply compute component-wise minimums or maximums of source and destination color components. The VK_BLEND_OP_ADD, VK_BLEND_OP_SUBTRACT, and VK_BLEND_OP_REVERSE_SUBTRACT modes multiply the source and destination colors by source and destination factors and either add the two products together or subtract one from the other. This limited set of operations supports many common blending operations but precludes the use of more sophisticated transparency and blending operations commonly available in many dedicated imaging APIs.

This extension provides a number of new “advanced” blending operations. Unlike traditional blending operations using VK_BLEND_OP_ADD, these blending equations do not use source and destination factors specified by VkBlendFactor. Instead, each blend operation specifies a complete equation based on the source and destination colors. These new blend operations are used for both RGB and alpha components; they must not be used to perform separate RGB and alpha blending (via different values of color and alpha VkBlendOp).

These blending operations are performed using premultiplied colors, where RGB colors can be considered premultiplied or non-premultiplied by alpha, according to the srcPremultiplied and dstPremultiplied members of VkPipelineColorBlendAdvancedStateCreateInfoEXT. If a color is considered non-premultiplied, the (R,G,B) color components are multiplied by the alpha component prior to blending. For non-premultiplied color components in the range [0,1], the corresponding premultiplied color component would have values in the range [0 × A, 1 × A].

Many of these advanced blending equations are formulated where the result of blending source and destination colors with partial coverage have three separate contributions: from the portions covered by both the source and the destination, from the portion covered only by the source, and from the portion covered only by the destination. The blend parameter VkPipelineColorBlendAdvancedStateCreateInfoEXT::blendOverlap can be used to specify a correlation between source and destination pixel coverage. If set to VK_BLEND_OVERLAP_CONJOINT_EXT, the source and destination are considered to have maximal overlap, as would be the case if drawing two objects on top of each other. If set to VK_BLEND_OVERLAP_DISJOINT_EXT, the source and destination are considered to have minimal overlap, as would be the case when rendering a complex polygon tessellated into individual non-intersecting triangles. If set to VK_BLEND_OVERLAP_UNCORRELATED_EXT, the source and destination coverage are assumed to have no spatial correlation within the pixel.

In addition to the coherency issues on implementations not supporting advancedBlendCoherentOperations, this extension has several limitations worth noting. First, the new blend operations have a limit on the number of color attachments they can be used with, as indicated by VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT::advancedBlendMaxColorAttachments. Additionally, blending precision may be limited to 16-bit floating-point, which may result in a loss of precision and dynamic range for framebuffer formats with 32-bit floating-point components, and in a loss of precision for formats with 12- and 16-bit signed or unsigned normalized integer components.

New Enums
New Enum Constants
  • VK_EXT_BLEND_OPERATION_ADVANCED_EXTENSION_NAME

  • VK_EXT_BLEND_OPERATION_ADVANCED_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT

  • Extending VkBlendOp:

    • VK_BLEND_OP_BLUE_EXT

    • VK_BLEND_OP_COLORBURN_EXT

    • VK_BLEND_OP_COLORDODGE_EXT

    • VK_BLEND_OP_CONTRAST_EXT

    • VK_BLEND_OP_DARKEN_EXT

    • VK_BLEND_OP_DIFFERENCE_EXT

    • VK_BLEND_OP_DST_ATOP_EXT

    • VK_BLEND_OP_DST_EXT

    • VK_BLEND_OP_DST_IN_EXT

    • VK_BLEND_OP_DST_OUT_EXT

    • VK_BLEND_OP_DST_OVER_EXT

    • VK_BLEND_OP_EXCLUSION_EXT

    • VK_BLEND_OP_GREEN_EXT

    • VK_BLEND_OP_HARDLIGHT_EXT

    • VK_BLEND_OP_HARDMIX_EXT

    • VK_BLEND_OP_HSL_COLOR_EXT

    • VK_BLEND_OP_HSL_HUE_EXT

    • VK_BLEND_OP_HSL_LUMINOSITY_EXT

    • VK_BLEND_OP_HSL_SATURATION_EXT

    • VK_BLEND_OP_INVERT_EXT

    • VK_BLEND_OP_INVERT_OVG_EXT

    • VK_BLEND_OP_INVERT_RGB_EXT

    • VK_BLEND_OP_LIGHTEN_EXT

    • VK_BLEND_OP_LINEARBURN_EXT

    • VK_BLEND_OP_LINEARDODGE_EXT

    • VK_BLEND_OP_LINEARLIGHT_EXT

    • VK_BLEND_OP_MINUS_CLAMPED_EXT

    • VK_BLEND_OP_MINUS_EXT

    • VK_BLEND_OP_MULTIPLY_EXT

    • VK_BLEND_OP_OVERLAY_EXT

    • VK_BLEND_OP_PINLIGHT_EXT

    • VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT

    • VK_BLEND_OP_PLUS_CLAMPED_EXT

    • VK_BLEND_OP_PLUS_DARKER_EXT

    • VK_BLEND_OP_PLUS_EXT

    • VK_BLEND_OP_RED_EXT

    • VK_BLEND_OP_SCREEN_EXT

    • VK_BLEND_OP_SOFTLIGHT_EXT

    • VK_BLEND_OP_SRC_ATOP_EXT

    • VK_BLEND_OP_SRC_EXT

    • VK_BLEND_OP_SRC_IN_EXT

    • VK_BLEND_OP_SRC_OUT_EXT

    • VK_BLEND_OP_SRC_OVER_EXT

    • VK_BLEND_OP_VIVIDLIGHT_EXT

    • VK_BLEND_OP_XOR_EXT

    • VK_BLEND_OP_ZERO_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT

Issues

None.

Version History
  • Revision 1, 2017-06-12 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-06-12 (Jeff Bolz)

    • Internal revisions

VK_EXT_border_color_swizzle

Name String

VK_EXT_border_color_swizzle

Extension Type

Device extension

Registered Extension Number

412

Revision

1

Ratification Status

Not ratified

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

2021-10-12

IP Status

No known IP claims.

Contributors
  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Ricardo Garcia, Igalia

  • Shahbaz Youssefi, Google

  • Stu Smith, AMD

Description

After the publication of VK_EXT_custom_border_color, it was discovered that some implementations had undefined behavior when combining a sampler that uses a custom border color with image views whose component mapping is not the identity mapping.

Since VK_EXT_custom_border_color has already shipped, this new extension VK_EXT_border_color_swizzle was created to define the interaction between custom border colors and non-identity image view swizzles, and provide a work-around for implementations that must pre-swizzle the sampler border color to match the image view component mapping it is combined with.

This extension also defines the behavior between samplers with an opaque black border color and image views with a non-identity component swizzle, which was previously left undefined.

New Enum Constants
  • VK_EXT_BORDER_COLOR_SWIZZLE_EXTENSION_NAME

  • VK_EXT_BORDER_COLOR_SWIZZLE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BORDER_COLOR_SWIZZLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_BORDER_COLOR_COMPONENT_MAPPING_CREATE_INFO_EXT

Issues

None.

Version History
  • Revision 1, 2021-10-12 (Piers Daniell)

    • Internal revisions.

VK_EXT_color_write_enable

Name String

VK_EXT_color_write_enable

Extension Type

Device extension

Registered Extension Number

382

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-02-25

IP Status

No known IP claims.

Contributors
  • Sharif Elcott, Google

  • Tobias Hector, AMD

  • Piers Daniell, NVIDIA

Description

This extension allows for selectively enabling and disabling writes to output color attachments via a pipeline dynamic state.

The intended use cases for this new state are mostly identical to those of colorWriteMask, such as selectively disabling writes to avoid feedback loops between subpasses or bandwidth savings for unused outputs. By making the state dynamic, one additional benefit is the ability to reduce pipeline counts and pipeline switching via shaders that write a superset of the desired data of which subsets are selected dynamically. The reason for a new state, colorWriteEnable, rather than making colorWriteMask dynamic is that, on many implementations, the more flexible per-component semantics of the colorWriteMask state cannot be made dynamic in a performant manner.

New Enum Constants
  • VK_EXT_COLOR_WRITE_ENABLE_EXTENSION_NAME

  • VK_EXT_COLOR_WRITE_ENABLE_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COLOR_WRITE_ENABLE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_COLOR_WRITE_CREATE_INFO_EXT

Version History
  • Revision 1, 2020-01-25 (Sharif Elcott)

    • Internal revisions

VK_EXT_conditional_rendering

Name String

VK_EXT_conditional_rendering

Extension Type

Device extension

Registered Extension Number

82

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2018-05-21

IP Status

No known IP claims.

Contributors
  • Vikram Kushwaha, NVIDIA

  • Daniel Rakos, AMD

  • Jesse Hall, Google

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Stuart Smith, Imagination Technologies

Description

This extension allows the execution of one or more rendering commands to be conditional on a value in buffer memory. This may help an application reduce the latency by conditionally discarding rendering commands without application intervention. The conditional rendering commands are limited to draws, compute dispatches and clearing attachments within a conditional rendering block.

New Enum Constants
  • VK_EXT_CONDITIONAL_RENDERING_EXTENSION_NAME

  • VK_EXT_CONDITIONAL_RENDERING_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_CONDITIONAL_RENDERING_READ_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_CONDITIONAL_RENDERING_BIT_EXT

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_CONDITIONAL_RENDERING_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_CONDITIONAL_RENDERING_INFO_EXT

    • VK_STRUCTURE_TYPE_CONDITIONAL_RENDERING_BEGIN_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONDITIONAL_RENDERING_FEATURES_EXT

Issues

1) Should conditional rendering affect copy and blit commands?

RESOLVED: Conditional rendering should not affect copies and blits.

2) Should secondary command buffers be allowed to execute while conditional rendering is active in the primary command buffer?

RESOLVED: The rendering commands in secondary command buffer will be affected by an active conditional rendering in primary command buffer if the conditionalRenderingEnable is set to VK_TRUE. Conditional rendering must not be active in the primary command buffer if conditionalRenderingEnable is VK_FALSE.

Examples

None.

Version History
  • Revision 1, 2018-04-19 (Vikram Kushwaha)

    • First Version

  • Revision 2, 2018-05-21 (Vikram Kushwaha)

    • Add new pipeline stage, access flags and limit conditional rendering to a subpass or entire render pass.

VK_EXT_conservative_rasterization

Name String

VK_EXT_conservative_rasterization

Extension Type

Device extension

Registered Extension Number

102

Revision

1

Ratification Status

Not ratified

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

2020-06-09

Interactions and External Dependencies
  • This extension requires SPV_EXT_fragment_fully_covered if the VkPhysicalDeviceConservativeRasterizationPropertiesEXT::fullyCoveredFragmentShaderInputVariable feature is used.

  • This extension requires SPV_KHR_post_depth_coverageif the VkPhysicalDeviceConservativeRasterizationPropertiesEXT::conservativeRasterizationPostDepthCoverage feature is used.

  • This extension provides API support for GL_NV_conservative_raster_underestimation if the VkPhysicalDeviceConservativeRasterizationPropertiesEXT::fullyCoveredFragmentShaderInputVariable feature is used.

Contributors
  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Slawomir Grajewski, Intel

  • Stu Smith, Imagination Technologies

Description

This extension adds a new rasterization mode called conservative rasterization. There are two modes of conservative rasterization; overestimation and underestimation.

When overestimation is enabled, if any part of the primitive, including its edges, covers any part of the rectangular pixel area, including its sides, then a fragment is generated with all coverage samples turned on. This extension allows for some variation in implementations by accounting for differences in overestimation, where the generating primitive size is increased at each of its edges by some sub-pixel amount to further increase conservative pixel coverage. Implementations can allow the application to specify an extra overestimation beyond the base overestimation the implementation already does. It also allows implementations to either cull degenerate primitives or rasterize them.

When underestimation is enabled, fragments are only generated if the rectangular pixel area is fully covered by the generating primitive. If supported by the implementation, when a pixel rectangle is fully covered the fragment shader input variable builtin called FullyCoveredEXT is set to true. The shader variable works in either overestimation or underestimation mode.

Implementations can process degenerate triangles and lines by either discarding them or generating conservative fragments for them. Degenerate triangles are those that end up with zero area after the rasterizer quantizes them to the fixed-point pixel grid. Degenerate lines are those with zero length after quantization.

New Enum Constants
  • VK_EXT_CONSERVATIVE_RASTERIZATION_EXTENSION_NAME

  • VK_EXT_CONSERVATIVE_RASTERIZATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONSERVATIVE_RASTERIZATION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT

New Built-In Variables
New SPIR-V Capabilities
Version History
  • Revision 1.1, 2020-09-06 (Piers Daniell)

    • Add missing SPIR-V and GLSL dependencies.

  • Revision 1, 2017-08-28 (Piers Daniell)

    • Internal revisions

VK_EXT_custom_border_color

Name String

VK_EXT_custom_border_color

Extension Type

Device extension

Registered Extension Number

288

Revision

12

Ratification Status

Not ratified

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

2020-04-16

IP Status

No known IP claims.

Contributors
  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

  • Philip Rebohle, Valve

  • Liam Middlebrook, NVIDIA

  • Jeff Bolz, NVIDIA

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Spencer Fricke, Samsung Electronics

  • Graeme Leese, Broadcom

  • Jesse Hall, Google

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

  • Stuart Smith, Imagination Technologies

  • Donald Scorgie, Imagination Technologies

  • Alex Walters, Imagination Technologies

  • Peter Quayle, Imagination Technologies

Description

This extension provides cross-vendor functionality to specify a custom border color for use when the sampler address mode VK_SAMPLER_ADDRESS_MODE_CLAMP_TO_BORDER is used.

To create a sampler which uses a custom border color set VkSamplerCreateInfo::borderColor to one of:

  • VK_BORDER_COLOR_FLOAT_CUSTOM_EXT

  • VK_BORDER_COLOR_INT_CUSTOM_EXT

When VK_BORDER_COLOR_FLOAT_CUSTOM_EXT or VK_BORDER_COLOR_INT_CUSTOM_EXT is used, applications must provide a VkSamplerCustomBorderColorCreateInfoEXT in the pNext chain for VkSamplerCreateInfo.

New Enum Constants
  • VK_EXT_CUSTOM_BORDER_COLOR_EXTENSION_NAME

  • VK_EXT_CUSTOM_BORDER_COLOR_SPEC_VERSION

  • Extending VkBorderColor:

    • VK_BORDER_COLOR_FLOAT_CUSTOM_EXT

    • VK_BORDER_COLOR_INT_CUSTOM_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_CUSTOM_BORDER_COLOR_CREATE_INFO_EXT

Issues

1) Should VkClearColorValue be used for the border color value, or should we have our own struct/union? Do we need to specify the type of the input values for the components? This is more of a concern if VkClearColorValue is used here because it provides a union of float,int,uint types.

RESOLVED: Will reuse existing VkClearColorValue structure in order to easily take advantage of float,int,uint borderColor types.

2) For hardware which supports a limited number of border colors what happens if that number is exceeded? Should this be handled by the driver unbeknownst to the application? In Revision 1 we had solved this issue using a new Object type, however that may have lead to additional system resource consumption which would otherwise not be required.

RESOLVED: Added VkPhysicalDeviceCustomBorderColorPropertiesEXT::maxCustomBorderColorSamplers for tracking implementation-specific limit, and Valid Usage statement handling overflow.

3) Should this be supported for immutable samplers at all, or by a feature bit? Some implementations may not be able to support custom border colors on immutable samplers — is it worthwhile enabling this to work on them for implementations that can support it, or forbidding it entirely.

RESOLVED: Samplers created with a custom border color are forbidden from being immutable. This resolves concerns for implementations where the custom border color is an index to a LUT instead of being directly embedded into sampler state.

4) Should UINT and SINT (unsigned integer and signed integer) border color types be separated or should they be combined into one generic INT (integer) type?

RESOLVED: Separating these does not make much sense as the existing fixed border color types do not have this distinction, and there is no reason in hardware to do so. This separation would also create unnecessary work and considerations for the application.

Version History
  • Revision 1, 2019-10-10 (Joshua Ashton)

    • Internal revisions.

  • Revision 2, 2019-10-11 (Liam Middlebrook)

    • Remove VkCustomBorderColor object and associated functions

    • Add issues concerning HW limitations for custom border color count

  • Revision 3, 2019-10-12 (Joshua Ashton)

    • Re-expose the limits for the maximum number of unique border colors

    • Add extra details about border color tracking

    • Fix typos

  • Revision 4, 2019-10-12 (Joshua Ashton)

    • Changed maxUniqueCustomBorderColors to a uint32_t from a VkDeviceSize

  • Revision 5, 2019-10-14 (Liam Middlebrook)

    • Added features bit

  • Revision 6, 2019-10-15 (Joshua Ashton)

    • Type-ize VK_BORDER_COLOR_CUSTOM

    • Fix const-ness on pNext of VkSamplerCustomBorderColorCreateInfoEXT

  • Revision 7, 2019-11-26 (Liam Middlebrook)

    • Renamed maxUniqueCustomBorderColors to maxCustomBorderColors

  • Revision 8, 2019-11-29 (Joshua Ashton)

    • Renamed borderColor member of VkSamplerCustomBorderColorCreateInfoEXT to customBorderColor

  • Revision 9, 2020-02-19 (Joshua Ashton)

    • Renamed maxCustomBorderColors to maxCustomBorderColorSamplers

  • Revision 10, 2020-02-21 (Joshua Ashton)

    • Added format to VkSamplerCustomBorderColorCreateInfoEXT and feature bit

  • Revision 11, 2020-04-07 (Joshua Ashton)

    • Dropped UINT/SINT border color differences, consolidated types

  • Revision 12, 2020-04-16 (Joshua Ashton)

    • Renamed VK_BORDER_COLOR_CUSTOM_FLOAT_EXT to VK_BORDER_COLOR_FLOAT_CUSTOM_EXT for consistency

VK_EXT_debug_utils

Name String

VK_EXT_debug_utils

Extension Type

Instance extension

Registered Extension Number

129

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies

None

Special Use
Contact
Other Extension Metadata
Last Modified Date

2020-04-03

Revision

2

IP Status

No known IP claims.

Dependencies
  • This extension is written against version 1.0 of the Vulkan API.

  • Requires VkObjectType

Contributors
  • Mark Young, LunarG

  • Baldur Karlsson

  • Ian Elliott, Google

  • Courtney Goeltzenleuchter, Google

  • Karl Schultz, LunarG

  • Mark Lobodzinski, LunarG

  • Mike Schuchardt, LunarG

  • Jaakko Konttinen, AMD

  • Dan Ginsburg, Valve Software

  • Rolando Olivares, Epic Games

  • Dan Baker, Oxide Games

  • Kyle Spagnoli, NVIDIA

  • Jon Ashburn, LunarG

  • Piers Daniell, NVIDIA

Description

Due to the nature of the Vulkan interface, there is very little error information available to the developer and application. By using the VK_EXT_debug_utils extension, developers can obtain more information. When combined with validation layers, even more detailed feedback on the application’s use of Vulkan will be provided.

This extension provides the following capabilities:

  • The ability to create a debug messenger which will pass along debug messages to an application supplied callback.

  • The ability to identify specific Vulkan objects using a name or tag to improve tracking.

  • The ability to identify specific sections within a VkQueue or VkCommandBuffer using labels to aid organization and offline analysis in external tools.

The main difference between this extension and VK_EXT_debug_report and VK_EXT_debug_marker is that those extensions use VkDebugReportObjectTypeEXT to identify objects. This extension uses the core VkObjectType in place of VkDebugReportObjectTypeEXT. The primary reason for this move is that no future object type handle enumeration values will be added to VkDebugReportObjectTypeEXT since the creation of VkObjectType.

In addition, this extension combines the functionality of both VK_EXT_debug_report and VK_EXT_debug_marker by allowing object name and debug markers (now called labels) to be returned to the application’s callback function. This should assist in clarifying the details of a debug message including: what objects are involved and potentially which location within a VkQueue or VkCommandBuffer the message occurred.

New Object Types
New Function Pointers
New Enum Constants
  • VK_EXT_DEBUG_UTILS_EXTENSION_NAME

  • VK_EXT_DEBUG_UTILS_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_TAG_INFO_EXT

Examples

Example 1

VK_EXT_debug_utils allows an application to register multiple callbacks with any Vulkan component wishing to report debug information. Some callbacks may log the information to a file, others may cause a debug break point or other application defined behavior. An application can register callbacks even when no validation layers are enabled, but they will only be called for loader and, if implemented, driver events.

To capture events that occur while creating or destroying an instance an application can link a VkDebugUtilsMessengerCreateInfoEXT structure to the pNext element of the VkInstanceCreateInfo structure given to vkCreateInstance.

Example uses: Create three callback objects. One will log errors and warnings to the debug console using Windows OutputDebugString. The second will cause the debugger to break at that callback when an error happens and the third will log warnings to stdout.

    extern VkInstance instance;
    VkResult res;
    VkDebugUtilsMessengerEXT cb1, cb2, cb3;

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

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

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

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

    ...

    // Remove callbacks when cleaning up
    pfnDestroyDebugUtilsMessengerEXT(instance, cb1, NULL);
    pfnDestroyDebugUtilsMessengerEXT(instance, cb2, NULL);
    pfnDestroyDebugUtilsMessengerEXT(instance, cb3, NULL);

Example 2

Associate a name with an image, for easier debugging in external tools or with validation layers that can print a friendly name when referring to objects in error messages.

    extern VkInstance instance;
    extern VkDevice device;
    extern VkImage image;

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

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

    pfnSetDebugUtilsObjectNameEXT(device, &imageNameInfo);

    // A subsequent error might print:
    //   Image 'Brick Diffuse Texture' (0xc0dec0dedeadbeef) is used in a
    //   command buffer with no memory bound to it.

Example 3

Annotating regions of a workload with naming information so that offline analysis tools can display a more usable visualization of the commands submitted.

    extern VkInstance instance;
    extern VkCommandBuffer commandBuffer;

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

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

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

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

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

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

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

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

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

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

    // Do other work

    vkEndCommandBuffer(commandBuffer);

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

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

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

    // End the queue label region
    pfnQueueEndDebugUtilsLabelEXT(queue);
Issues

1) Should we just name this extension VK_EXT_debug_report2

RESOLVED: No. There is enough additional changes to the structures to break backwards compatibility. So, a new name was decided that would not indicate any interaction with the previous extension.

2) Will validation layers immediately support all the new features.

RESOLVED: Not immediately. As one can imagine, there is a lot of work involved with converting the validation layer logging over to the new functionality. Basic logging, as seen in the origin VK_EXT_debug_report extension will be made available immediately. However, adding the labels and object names will take time. Since the priority for Khronos at this time is to continue focusing on Valid Usage statements, it may take a while before the new functionality is fully exposed.

3) If the validation layers will not expose the new functionality immediately, then what is the point of this extension?

RESOLVED: We needed a replacement for VK_EXT_debug_report because the VkDebugReportObjectTypeEXT enumeration will no longer be updated and any new objects will need to be debugged using the new functionality provided by this extension.

4) Should this extension be split into two separate parts (1 extension that is an instance extension providing the callback functionality, and another device extension providing the general debug marker and annotation functionality)?

RESOLVED: No, the functionality for this extension is too closely related. If we did split up the extension, where would the structures and enums live, and how would you define that the device behavior in the instance extension is really only valid if the device extension is enabled, and the functionality is passed in. It is cleaner to just define this all as an instance extension, plus it allows the application to enable all debug functionality provided with one enable string during vkCreateInstance.

Version History
  • Revision 1, 2017-09-14 (Mark Young and all listed Contributors)

  • Revision 2, 2020-04-03 (Mark Young and Piers Daniell)

    • Updated to allow either NULL or an empty string to be passed in for pObjectName in VkDebugUtilsObjectNameInfoEXT, because the loader and various drivers support NULL already.

VK_EXT_depth_bias_control

Name String

VK_EXT_depth_bias_control

Extension Type

Device extension

Registered Extension Number

284

Revision

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_clamp_zero_one

Name String

VK_EXT_depth_clamp_zero_one

Extension Type

Device extension

Registered Extension Number

422

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2021-07-29

Contributors
  • Graeme Leese, Broadcom

Description

This extension gives defined behavior to fragment depth values which end up outside the conventional [0, 1] range. It can be used to ensure portability in edge cases of features like depthBias. The particular behavior is chosen to match OpenGL to aid porting or emulation.

New Enum Constants
  • VK_EXT_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME

  • VK_EXT_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_EXT

Version History
  • Revision 1, 2021-07-29 (Graeme Leese)

    • Internal revisions

VK_EXT_depth_clip_control

Name String

VK_EXT_depth_clip_control

Extension Type

Device extension

Registered Extension Number

356

Revision

1

Ratification Status

Not ratified

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

2021-11-09

Contributors
  • Spencer Fricke, Samsung Electronics

  • Shahbaz Youssefi, Google

  • Ralph Potter, Samsung Electronics

Description

This extension allows the application to use the OpenGL depth range in NDC, i.e. with depth in range [-1, 1], as opposed to Vulkan’s default of [0, 1]. The purpose of this extension is to allow efficient layering of OpenGL over Vulkan, by avoiding emulation in the pre-rasterization shader stages. This emulation, which effectively duplicates gl_Position but with a different depth value, costs ALU and consumes shader output components that the implementation may not have to spare to meet OpenGL minimum requirements.

New Enum Constants
  • VK_EXT_DEPTH_CLIP_CONTROL_EXTENSION_NAME

  • VK_EXT_DEPTH_CLIP_CONTROL_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLIP_CONTROL_CREATE_INFO_EXT

Issues

1) Should this extension include an origin control option to match GL_LOWER_LEFT found in ARB_clip_control?

RESOLVED: No. The fix for porting over the origin is a simple y-axis flip. The depth clip control is a much harder problem to solve than what this extension is aimed to solve. Adding an equivalent to GL_LOWER_LEFT would require more testing.

2) Should this pipeline state be dynamic?

RESOLVED: Yes. The purpose of this extension is to emulate the OpenGL depth range, which is expected to be globally fixed (in case of OpenGL ES) or very infrequently changed (with glClipControl in OpenGL).

3) Should the control provided in this extension be an enum that could be extended in the future?

RESOLVED: No. It is highly unlikely that the depth range is changed to anything other than [0, 1] in the future. Should that happen a new extension will be required to extend such an enum, and that extension might as well add a new struct to chain to VkPipelineViewportStateCreateInfo::pNext instead.

Version History
  • Revision 0, 2020-10-01 (Spencer Fricke)

    • Internal revisions

  • Revision 1, 2020-11-26 (Shahbaz Youssefi)

    • Language fixes

VK_EXT_depth_clip_enable

Name String

VK_EXT_depth_clip_enable

Extension Type

Device extension

Registered Extension Number

103

Revision

1

Ratification Status

Not 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

Not 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 behaviour, which is defined in the Depth Test section of the Fragment Operations chapter.

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

    • Internal revisions

VK_EXT_descriptor_buffer

Name String

VK_EXT_descriptor_buffer

Extension Type

Device extension

Registered Extension Number

317

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_KHR_acceleration_structure

  • Interacts with VK_NV_ray_tracing

Contact
Extension Proposal

VK_EXT_descriptor_buffer

Other Extension Metadata
Last Modified Date

2021-06-07

IP Status

No known IP claims.

Contributors
  • Tobias Hector, AMD

  • Stu Smith, AMD

  • Maciej Jesionowski, AMD

  • Boris Zanin, AMD

  • Hans-Kristian Arntzen, Valve

  • Connor Abbott, Valve

  • Baldur Karlsson, Valve

  • Mike Blumenkrantz, Valve

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Rodrigo Locatti, NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Leger, QUALCOMM

  • Lionel Landwerlin, Intel

  • Slawomir Grajewski, Intel

Description

This extension introduces new commands to put shader-accessible descriptors directly in memory, making the management of descriptor data more explicit.

New Unions
New Enum Constants
  • VK_EXT_DESCRIPTOR_BUFFER_EXTENSION_NAME

  • VK_EXT_DESCRIPTOR_BUFFER_SPEC_VERSION

  • Extending VkAccelerationStructureCreateFlagBitsKHR:

    • VK_ACCELERATION_STRUCTURE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_DESCRIPTOR_BUFFER_READ_BIT_EXT

  • Extending VkBufferCreateFlagBits:

    • VK_BUFFER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_PUSH_DESCRIPTORS_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_RESOURCE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_SAMPLER_DESCRIPTOR_BUFFER_BIT_EXT

  • Extending VkDescriptorSetLayoutCreateFlagBits:

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_DESCRIPTOR_BUFFER_BIT_EXT

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_EMBEDDED_IMMUTABLE_SAMPLERS_BIT_EXT

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • Extending VkImageViewCreateFlagBits:

    • VK_IMAGE_VIEW_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_DESCRIPTOR_BUFFER_BIT_EXT

  • Extending VkSamplerCreateFlagBits:

    • VK_SAMPLER_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_ADDRESS_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_BUFFER_BINDING_PUSH_DESCRIPTOR_BUFFER_HANDLE_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_GET_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

    • VK_STRUCTURE_TYPE_OPAQUE_CAPTURE_DESCRIPTOR_DATA_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_DENSITY_MAP_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_BUFFER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CAPTURE_DESCRIPTOR_DATA_INFO_EXT

Version History
  • Revision 1, 2021-06-07 (Stu Smith)

    • Initial revision

VK_EXT_device_address_binding_report

Name String

VK_EXT_device_address_binding_report

Extension Type

Device extension

Registered Extension Number

355

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Uses
Contact
  • Ralph Potter r_potter

Other Extension Metadata
Last Modified Date

2020-11-23

Interactions and External Dependencies
  • This extension requires VK_EXT_debug_utils

Contributors
  • Ralph Potter, Samsung

  • Spencer Fricke, Samsung

  • Jan-Harald Fredriksen, ARM

  • Andrew Ellem, Google

  • Alex Walters, IMG

  • Jeff Bolz, NVIDIA

Description

This extension enables applications to track the binding of regions of the GPU virtual address space, and to associate those regions with Vulkan objects. This extension is primarily intended to aid in crash postmortem, where applications may wish to map a faulting GPU address to a Vulkan object.

For example, a page fault triggered by accessing an address located within a region of the GPU virtual address space that was previously reported as bound and then unbound may indicate a use-after-free error. Similarly, faults generated by accessing virtual addresses outside the limits of a bound region of GPU virtual address space may indicate indexing beyond the bounds of a resource.

New Enum Constants
  • VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_EXTENSION_NAME

  • VK_EXT_DEVICE_ADDRESS_BINDING_REPORT_SPEC_VERSION

  • Extending VkDebugUtilsMessageTypeFlagBitsEXT:

    • VK_DEBUG_UTILS_MESSAGE_TYPE_DEVICE_ADDRESS_BINDING_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_ADDRESS_BINDING_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ADDRESS_BINDING_REPORT_FEATURES_EXT

Issues

1.) Should this extend VK_EXT_debug_utils or VK_EXT_device_memory_report?

RESOLVED: Extend VK_EXT_debug_utils. VK_EXT_device_memory_report focuses on memory allocations and would not normally trigger callbacks in all of the situations where VK_EXT_device_address_binding_report is expected to.

2.) Should this extension cover all Vulkan object types, or only resources such as buffers and images?

RESOLVED: The extension covers all Vulkan objects, and is not restricted to objects backed by VkDeviceMemory objects.

3.) Should reallocation be identified explicitly, or as a unbind/bind pair?

RESOLVED: Reallocation should be represented as an unbind/bind pair.

4.) Can multiple Vulkan objects share an overlapping virtual address range?

RESOLVED: Yes. This can be expected to occur due to resources aliasing.

5.) Can a single Vulkan object be associated with multiple virtual address ranges concurrently?

RESOLVED: Yes. These should be reported via multiple calls to the reporting callback.

6.) Should the virtual address ranges associated with internal allocations such as memory pools be reported?

RESOLVED: Virtual address ranges associated with internal allocations should only be reported when they become associated with a specific Vulkan object. In the case of internal pool allocations, a bind event should be reported when resources from the pool are assigned to a Vulkan object, and an unbind event should be reported when those resources are returned to the pool. Implementations should not report the binding or unbinding of virtual address ranges for which there are no related API objects visible to the application developer.

7.) Can an implementation report binding a virtual address range at VkImage or VkImageView creation, rather than in response to vkBindImageMemory?

RESOLVED: Yes. Virtual address range binding should be reported at the appropriate point at which it occurs within the implementation. This extension does not mandate when that should occur, and applications should anticipate receiving callback events at any point after registering callbacks.

8.) Can reporting of binding/unbinding be deferred until a resource is referenced by an executing command buffer?

RESOLVED: Changes to the virtual address ranges associated with a Vulkan object should be reported as close as possible to where they occur within the implementation. If virtual address binding is deferred, then the callback should also be deferred to match.

9.) Do bind/unbind callbacks have to form matched pairs? Can a large region be bound, and then subregions unbound, resulting in fragmentation?

RESOLVED: Splitting of virtual address regions, and unmatched bind/unbind callbacks may occur. Developers should anticipate that sparse memory may exhibit this behaviour.

10.) The specification mandates that a callback must be triggered whenever a GPU virtual address range associated with any Vulkan object is bound or unbound. Do we need queries or properties indicating which Vulkan objects will report binding modifications?

RESOLVED: No. This extension is not intended to mandate how and when implementations bind virtual ranges to objects. Adding queries or properties would constrain implementations, which might otherwise vary how virtual address bindings occur based on usage.

11.) Should vkAllocateMemory and vkFreeMemory trigger reporting callbacks?

RESOLVED: If an implementation binds a GPU virtual address range when vkAllocateMemory is called, then the callbacks must be triggered associating the virtual address range with the VkDeviceMemory object. If the device memory is subsequently bound to a buffer or image via vkBind*Memory, the callbacks should be triggered a second time, reporting the association between virtual address range and the buffer/image.

Version History
  • Revision 1, 2020-09-23 (Ralph Potter)

    • Internal revisions

VK_EXT_device_fault

Name String

VK_EXT_device_fault

Extension Type

Device extension

Registered Extension Number

342

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Ralph Potter r_potter

Extension Proposal

VK_EXT_device_fault

Other Extension Metadata
Last Modified Date

2021-03-10

IP Status

No known IP claims.

Contributors
  • Ralph Potter, Samsung

  • Stuart Smith, AMD

  • Jan-Harald Fredriksen, ARM

  • Mark Bellamy, ARM

  • Andrew Ellem, Google

  • Alex Walters, IMG

  • Jeff Bolz, NVIDIA

  • Baldur Karlsson, Valve

Description

Device loss can be triggered by a variety of issues, including invalid API usage, implementation errors, or hardware failures.

This extension introduces a new command: vkGetDeviceFaultInfoEXT, which may be called subsequent to a VK_ERROR_DEVICE_LOST error code having been returned by the implementation. This command allows developers to query for additional information on GPU faults which may have caused device loss, and to generate binary crash dumps, which may be loaded into external tools for further diagnosis.

New Enum Constants
  • VK_EXT_DEVICE_FAULT_EXTENSION_NAME

  • VK_EXT_DEVICE_FAULT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_FAULT_COUNTS_EXT

    • VK_STRUCTURE_TYPE_DEVICE_FAULT_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FAULT_FEATURES_EXT

Version History
  • Revision 2, 2023-04-05 (Ralph Potter)

    • Restored two missing members to the XML definition of VkDeviceFaultVendorBinaryHeaderVersionOneEXT. No functional change to the specification.

  • Revision 1, 2020-10-19 (Ralph Potter)

    • Initial revision

VK_EXT_device_memory_report

Name String

VK_EXT_device_memory_report

Extension Type

Device extension

Registered Extension Number

285

Revision

2

Ratification Status

Not ratified

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

2021-01-06

IP Status

No known IP claims.

Contributors
  • Yiwei Zhang, Google

  • Jesse Hall, Google

Description

This device extension allows registration of device memory event callbacks upon device creation, so that applications or middleware can obtain detailed information about memory usage and how memory is associated with Vulkan objects. This extension exposes the actual underlying device memory usage, including allocations that are not normally visible to the application, such as memory consumed by vkCreateGraphicsPipelines. It is intended primarily for use by debug tooling rather than for production applications.

New Function Pointers
New Enum Constants
  • VK_EXT_DEVICE_MEMORY_REPORT_EXTENSION_NAME

  • VK_EXT_DEVICE_MEMORY_REPORT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_DEVICE_MEMORY_REPORT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_REPORT_CALLBACK_DATA_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_MEMORY_REPORT_FEATURES_EXT

Issues

1) Should this be better expressed as an extension to VK_EXT_debug_utils and its general-purpose messenger construct?

RESOLVED: No. The intended lifecycle is quite different. We want to make this extension tied to the device’s lifecycle. Each ICD just handles its own implementation of this extension, and this extension will only be directly exposed from the ICD. So we can avoid the extra implementation complexity used to accommodate the flexibility of VK_EXT_debug_utils extension.

2) Can we extend and use the existing internal allocation callbacks instead of adding the new callback structure in this extension?

RESOLVED: No. Our memory reporting layer that combines this information with other memory information it collects directly (e.g. bindings of resources to VkDeviceMemory) would have to intercept all entry points that take a VkAllocationCallbacks parameter and inject its own pfnInternalAllocation and pfnInternalFree. That may be doable for the extensions we know about, but not for ones we do not. The proposal would work fine in the face of most unknown extensions. But even for ones we know about, since apps can provide a different set of callbacks and userdata and those can be retained by the driver and used later (esp. for pool object, but not just those), we would have to dynamically allocate the interception trampoline every time. That is getting to be an unreasonably large amount of complexity and (possibly) overhead.

We are interested in both alloc/free and import/unimport. The latter is fairly important for tracking (and avoiding double-counting) of swapchain images (still true with “native swapchains” based on external memory) and media/camera interop. Though we might be able to handle this with additional VkInternalAllocationType values, for import/export we do want to be able to tie this to the external resource, which is one thing that the memoryObjectId is for.

The internal alloc/free callbacks are not extensible except via new VkInternalAllocationType values. The VkDeviceMemoryReportCallbackDataEXT in this extension is extensible. That was deliberate: there is a real possibility we will want to get extra information in the future. As one example, currently this reports only physical allocations, but we believe there are interesting cases for tracking how populated that VA region is.

The callbacks are clearly specified as only callable within the context of a call from the app into Vulkan. We believe there are some cases where drivers can allocate device memory asynchronously. This was one of the sticky issues that derailed the internal device memory allocation reporting design (which is essentially what this extension is trying to do) leading up to 1.0.

VkAllocationCallbacks is described in a section called “Host memory” and the intro to it is very explicitly about host memory. The other callbacks are all inherently about host memory. But this extension is very focused on device memory.

3) Should the callback be reporting which heap is used?

RESOLVED: Yes. It is important for non-UMA systems to have all the device memory allocations attributed to the corresponding device memory heaps. For internally-allocated device memory, heapIndex will always correspond to an advertised heap, rather than having a magic value indicating a non-advertised heap. Drivers can advertise heaps that do not have any corresponding memory types if they need to.

4) Should we use an array of callback for the layers to intercept instead of chaining multiple of the VkDeviceDeviceMemoryReportCreateInfoEXT structures in the pNext of VkDeviceCreateInfo?

RESOLVED No. The pointer to the VkDeviceDeviceMemoryReportCreateInfoEXT structure itself is const and you cannot just cast it away. Thus we cannot update the callback array inside the structure. In addition, we cannot drop this pNext chain either, so making a copy of this whole structure does not work either.

5) Should we track bulk allocations shared among multiple objects?

RESOLVED No. Take the shader heap as an example. Some implementations will let multiple VkPipeline objects share the same shader heap. We are not asking the implementation to report VK_OBJECT_TYPE_PIPELINE along with a VK_NULL_HANDLE for this bulk allocation. Instead, this bulk allocation is considered as a layer below what this extension is interested in. Later, when the actual VkPipeline objects are created by suballocating from the bulk allocation, we ask the implementation to report the valid handles of the VkPipeline objects along with the actual suballocated sizes and different memoryObjectId.

6) Can we require the callbacks to be always called in the same thread with the Vulkan commands?

RESOLVED No. Some implementations might choose to multiplex work from multiple application threads into a single backend thread and perform JIT allocations as a part of that flow. Since this behavior is theoretically legit, we cannot require the callbacks to be always called in the same thread with the Vulkan commands, and the note is to remind the applications to handle this case properly.

7) Should we add an additional “allocation failed” event type with things like size and heap index reported?

RESOLVED Yes. This fits in well with the callback infrastructure added in this extension, and implementation touches the same code and has the same overheads as the rest of the extension. It could help debugging things like getting an VK_ERROR_OUT_OF_HOST_MEMORY error when ending a command buffer. Right now the allocation failure could have happened anywhere during recording, and a callback would be really useful to understand where and why.

Version History
  • Revision 1, 2020-08-26 (Yiwei Zhang)

    • Initial version

  • Revision 2, 2021-01-06 (Yiwei Zhang)

    • Minor description update

VK_EXT_direct_mode_display

Name String

VK_EXT_direct_mode_display

Extension Type

Instance extension

Registered Extension Number

89

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-12-13

IP Status

No known IP claims.

Contributors
  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Liam Middlebrook, NVIDIA

Description

This is extension, along with related platform extensions, allows applications to take exclusive control of displays associated with a native windowing system. This is especially useful for virtual reality applications that wish to hide HMDs (head mounted displays) from the native platform’s display management system, desktop, and/or other applications.

New Commands
New Enum Constants
  • VK_EXT_DIRECT_MODE_DISPLAY_EXTENSION_NAME

  • VK_EXT_DIRECT_MODE_DISPLAY_SPEC_VERSION

Issues

1) Should this extension and its related platform-specific extensions leverage VK_KHR_display, or provide separate equivalent interfaces.

RESOLVED: Use VK_KHR_display concepts and objects. VK_KHR_display can be used to enumerate all displays on the system, including those attached to/in use by a window system or native platform, but VK_KHR_display_swapchain will fail to create a swapchain on in-use displays. This extension and its platform-specific children will allow applications to grab in-use displays away from window systems and/or native platforms, allowing them to be used with VK_KHR_display_swapchain.

2) Are separate calls needed to acquire displays and enable direct mode?

RESOLVED: No, these operations happen in one combined command. Acquiring a display puts it into direct mode.

Version History
  • Revision 1, 2016-12-13 (James Jones)

    • Initial draft

VK_EXT_directfb_surface

Name String

VK_EXT_directfb_surface

Extension Type

Instance extension

Registered Extension Number

347

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-06-16

IP Status

No known IP claims.

Contributors
  • Nicolas Caramelli

Description

The VK_EXT_directfb_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a DirectFB IDirectFBSurface, as well as a query to determine support for rendering via DirectFB.

New Enum Constants
  • VK_EXT_DIRECTFB_SURFACE_EXTENSION_NAME

  • VK_EXT_DIRECTFB_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DIRECTFB_SURFACE_CREATE_INFO_EXT

Version History
  • Revision 1, 2020-06-16 (Nicolas Caramelli)

    • Initial version

VK_EXT_discard_rectangles

Name String

VK_EXT_discard_rectangles

Extension Type

Device extension

Registered Extension Number

100

Revision

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_display_control

Name String

VK_EXT_display_control

Extension Type

Device extension

Registered Extension Number

92

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-12-13

IP Status

No known IP claims.

Contributors
  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Daniel Vetter, Intel

Description

This extension defines a set of utility functions for use with the VK_KHR_display and VK_KHR_display_swapchain extensions.

New Enum Constants
  • VK_EXT_DISPLAY_CONTROL_EXTENSION_NAME

  • VK_EXT_DISPLAY_CONTROL_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_DISPLAY_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_DISPLAY_POWER_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_COUNTER_CREATE_INFO_EXT

Issues

1) Should this extension add an explicit “WaitForVsync” API or a fence signaled at vsync that the application can wait on?

RESOLVED: A fence. A separate API could later be provided that allows exporting the fence to a native object that could be inserted into standard run loops on POSIX and Windows systems.

2) Should callbacks be added for a vsync event, or in general to monitor events in Vulkan?

RESOLVED: No, fences should be used. Some events are generated by interrupts which are managed in the kernel. In order to use a callback provided by the application, drivers would need to have the userspace driver spawn threads that would wait on the kernel event, and hence the callbacks could be difficult for the application to synchronize with its other work given they would arrive on a foreign thread.

3) Should vblank or scanline events be exposed?

RESOLVED: Vblank events. Scanline events could be added by a separate extension, but the latency of processing an interrupt and waking up a userspace event is high enough that the accuracy of a scanline event would be rather low. Further, per-scanline interrupts are not supported by all hardware.

Version History
  • Revision 1, 2016-12-13 (James Jones)

    • Initial draft

VK_EXT_display_surface_counter

Name String

VK_EXT_display_surface_counter

Extension Type

Instance extension

Registered Extension Number

91

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2016-12-13

IP Status

No known IP claims.

Contributors
  • Pierre Boudier, NVIDIA

  • James Jones, NVIDIA

  • Damien Leone, NVIDIA

  • Pierre-Loup Griffais, Valve

  • Daniel Vetter, Intel

Description

This extension defines a vertical blanking period counter associated with display surfaces. It provides a mechanism to query support for such a counter from a VkSurfaceKHR object.

New Structures
New Enum Constants
  • VK_EXT_DISPLAY_SURFACE_COUNTER_EXTENSION_NAME

  • VK_EXT_DISPLAY_SURFACE_COUNTER_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT

Version History
  • Revision 1, 2016-12-13 (James Jones)

    • Initial draft

VK_EXT_dynamic_rendering_unused_attachments

Name String

VK_EXT_dynamic_rendering_unused_attachments

Extension Type

Device extension

Registered Extension Number

500

Revision

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 Commands

If VK_EXT_depth_clip_control is supported:

If VK_EXT_depth_clip_enable is supported:

If VK_EXT_line_rasterization is supported:

If VK_EXT_provoking_vertex is supported:

If VK_EXT_sample_locations is supported:

If VK_EXT_transform_feedback is supported:

If VK_KHR_maintenance2 or Version 1.1 is supported:

If VK_NV_clip_space_w_scaling is supported:

If VK_NV_shading_rate_image is supported:

If VK_NV_viewport_swizzle is supported:

New Enum Constants
  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_ALPHA_TO_COVERAGE_ENABLE_EXT

    • VK_DYNAMIC_STATE_ALPHA_TO_ONE_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_EQUATION_EXT

    • VK_DYNAMIC_STATE_COLOR_WRITE_MASK_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLAMP_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_ENABLE_EXT

    • VK_DYNAMIC_STATE_POLYGON_MODE_EXT

    • VK_DYNAMIC_STATE_RASTERIZATION_SAMPLES_EXT

    • VK_DYNAMIC_STATE_SAMPLE_MASK_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_PROPERTIES_EXT

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_CONSERVATIVE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_EXTRA_PRIMITIVE_OVERESTIMATION_SIZE_EXT

If VK_EXT_depth_clip_control is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_DEPTH_CLIP_NEGATIVE_ONE_TO_ONE_EXT

If VK_EXT_depth_clip_enable is supported:

If VK_EXT_line_rasterization is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT

If VK_EXT_provoking_vertex is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_PROVOKING_VERTEX_MODE_EXT

If VK_EXT_sample_locations is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_ENABLE_EXT

If VK_EXT_transform_feedback is supported:

If VK_KHR_maintenance2 or Version 1.1 is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT

If VK_NV_clip_space_w_scaling is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_ENABLE_NV

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_COVERAGE_REDUCTION_MODE_NV

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_ENABLE_NV

    • VK_DYNAMIC_STATE_COVERAGE_TO_COLOR_LOCATION_NV

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_MODE_NV

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_ENABLE_NV

    • VK_DYNAMIC_STATE_COVERAGE_MODULATION_TABLE_NV

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_REPRESENTATIVE_FRAGMENT_TEST_ENABLE_NV

If VK_NV_shading_rate_image is supported:

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_SHADING_RATE_IMAGE_ENABLE_NV

If VK_NV_viewport_swizzle is supported:

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_external_memory_dma_buf

Name String

VK_EXT_external_memory_dma_buf

Extension Type

Device extension

Registered Extension Number

126

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-10-10

IP Status

No known IP claims.

Contributors
  • Lina Versace, Google

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

Description

A dma_buf is a type of file descriptor, defined by the Linux kernel, that allows sharing memory across kernel device drivers and across processes. This extension enables applications to import a dma_buf as VkDeviceMemory, to export VkDeviceMemory as a dma_buf, and to create VkBuffer objects that can be bound to that memory.

New Enum Constants
  • VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME

  • VK_EXT_EXTERNAL_MEMORY_DMA_BUF_SPEC_VERSION

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT

Issues

1) How does the application, when creating a VkImage that it intends to bind to dma_buf VkDeviceMemory containing an externally produced image, specify the memory layout (such as row pitch and DRM format modifier) of the VkImage? In other words, how does the application achieve behavior comparable to that provided by EGL_EXT_image_dma_buf_import and EGL_EXT_image_dma_buf_import_modifiers ?

RESOLVED: Features comparable to those in EGL_EXT_image_dma_buf_import and EGL_EXT_image_dma_buf_import_modifiers will be provided by an extension layered atop this one.

2) Without the ability to specify the memory layout of external dma_buf images, how is this extension useful?

RESOLVED: This extension provides exactly one new feature: the ability to import/export between dma_buf and VkDeviceMemory. This feature, together with features provided by VK_KHR_external_memory_fd, is sufficient to bind a VkBuffer to dma_buf.

Version History
  • Revision 1, 2017-10-10 (Lina Versace)

    • Squashed internal revisions

VK_EXT_external_memory_host

Name String

VK_EXT_external_memory_host

Extension Type

Device extension

Registered Extension Number

179

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2017-11-10

IP Status

No known IP claims.

Contributors
  • Jaakko Konttinen, AMD

  • David Mao, AMD

  • Daniel Rakos, AMD

  • Tobias Hector, Imagination Technologies

  • Faith Ekstrand, Intel

  • James Jones, NVIDIA

Description

This extension enables an application to import host allocations and host mapped foreign device memory to Vulkan memory objects.

New Enum Constants
  • VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME

  • VK_EXT_EXTERNAL_MEMORY_HOST_SPEC_VERSION

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT

    • VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT

Issues

1) What memory type has to be used to import host pointers?

RESOLVED: Depends on the implementation. Applications have to use the new vkGetMemoryHostPointerPropertiesEXT command to query the supported memory types for a particular host pointer. The reported memory types may include memory types that come from a memory heap that is otherwise not usable for regular memory object allocation and thus such a heap’s size may be zero.

2) Can the application still access the contents of the host allocation after importing?

RESOLVED: Yes. However, usual synchronization requirements apply.

3) Can the application free the host allocation?

RESOLVED: No, it violates valid usage conditions. Using the memory object imported from a host allocation that is already freed thus results in undefined behavior.

4) Is vkMapMemory expected to return the same host address which was specified when importing it to the memory object?

RESOLVED: No. Implementations are allowed to return the same address but it is not required. Some implementations might return a different virtual mapping of the allocation, although the same physical pages will be used.

5) Is there any limitation on the alignment of the host pointer and/or size?

RESOLVED: Yes. Both the address and the size have to be an integer multiple of minImportedHostPointerAlignment. In addition, some platforms and foreign devices may have additional restrictions.

6) Can the same host allocation be imported multiple times into a given physical device?

RESOLVED: No, at least not guaranteed by this extension. Some platforms do not allow locking the same physical pages for device access multiple times, so attempting to do it may result in undefined behavior.

7) Does this extension support exporting the new handle type?

RESOLVED: No.

8) Should we include the possibility to import host mapped foreign device memory using this API?

RESOLVED: Yes, through a separate handle type. Implementations are still allowed to support only one of the handle types introduced by this extension by not returning import support for a particular handle type as returned in VkExternalMemoryPropertiesKHR.

Version History
  • Revision 1, 2017-11-10 (Daniel Rakos)

    • Internal revisions

VK_EXT_filter_cubic

Name String

VK_EXT_filter_cubic

Extension Type

Device extension

Registered Extension Number

171

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies

None

Contact
Other Extension Metadata
Last Modified Date

2019-12-13

Contributors
  • Bill Licea-Kane, Qualcomm Technologies, Inc.

  • Andrew Garrard, Samsung

  • Daniel Koch, NVIDIA

  • Donald Scorgie, Imagination Technologies

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

  • Jeff Leger, Qualcomm Technologies, Inc.

  • Tobias Hector, AMD

  • Tom Olson, ARM

  • Stuart Smith, Imagination Technologies

Description

VK_EXT_filter_cubic extends VK_IMG_filter_cubic.

It documents cubic filtering of other image view types. It adds new structures that can be added to the pNext chain of VkPhysicalDeviceImageFormatInfo2 and VkImageFormatProperties2 that can be used to determine which image types and which image view types support cubic filtering.

New Enum Constants
  • VK_EXT_FILTER_CUBIC_EXTENSION_NAME

  • VK_EXT_FILTER_CUBIC_SPEC_VERSION

  • Extending VkFilter:

    • VK_FILTER_CUBIC_EXT

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FILTER_CUBIC_IMAGE_VIEW_IMAGE_FORMAT_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_IMAGE_FORMAT_INFO_EXT

Version History
  • Revision 3, 2019-12-13 (wwlk)

    • Delete requirement to cubic filter the formats USCALED_PACKED32, SSCALED_PACKED32, UINT_PACK32, and SINT_PACK32 (cut/paste error)

  • Revision 2, 2019-06-05 (wwlk)

    • Clarify 1D optional

  • Revision 1, 2019-01-24 (wwlk)

    • Initial version

VK_EXT_fragment_density_map

Name String

VK_EXT_fragment_density_map

Extension Type

Device extension

Registered Extension Number

219

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
API Interactions
  • Interacts with VK_KHR_format_feature_flags2

SPIR-V Dependencies
Contact
Other Extension Metadata
Last Modified Date

2021-09-30

Interactions and External Dependencies
Contributors
  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Robert VanReenen, Qualcomm Technologies, Inc.

  • Jonathan Wicks, Qualcomm Technologies, Inc.

  • Tate Hornbeck, Qualcomm Technologies, Inc.

  • Sam Holmes, Qualcomm Technologies, Inc.

  • Jeff Leger, Qualcomm Technologies, Inc.

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Pat Brown, NVIDIA

  • Daniel Rakos, AMD

  • Piers Daniell, NVIDIA

Description

This extension allows an application to specify areas of the render target where the fragment shader may be invoked fewer times. These fragments are broadcasted out to multiple pixels to cover the render target.

The primary use of this extension is to reduce workloads in areas where lower quality may not be perceived such as the distorted edges of a lens or the periphery of a user’s gaze.

New Enum Constants
  • VK_EXT_FRAGMENT_DENSITY_MAP_EXTENSION_NAME

  • VK_EXT_FRAGMENT_DENSITY_MAP_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_FRAGMENT_DENSITY_MAP_READ_BIT_EXT

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_SUBSAMPLED_BIT_EXT

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT

  • Extending VkImageUsageFlagBits:

    • VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT

  • Extending VkImageViewCreateFlagBits:

    • VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DYNAMIC_BIT_EXT

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_FRAGMENT_DENSITY_PROCESS_BIT_EXT

  • Extending VkSamplerCreateFlagBits:

    • VK_SAMPLER_CREATE_SUBSAMPLED_BIT_EXT

    • VK_SAMPLER_CREATE_SUBSAMPLED_COARSE_RECONSTRUCTION_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_FRAGMENT_DENSITY_MAP_CREATE_INFO_EXT

If VK_KHR_format_feature_flags2 is supported:

New or Modified Built-In Variables
New SPIR-V Capabilities
Version History
  • Revision 1, 2018-09-25 (Matthew Netsch)

    • Initial version

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

VK_EXT_fragment_density_map2

Name String

VK_EXT_fragment_density_map2

Extension Type

Device extension

Registered Extension Number

333

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Other Extension Metadata
Last Modified Date

2020-06-16

Interactions and External Dependencies
  • Interacts with Vulkan 1.1

Contributors
  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Jonathan Tinkham, Qualcomm Technologies, Inc.

  • Jonathan Wicks, Qualcomm Technologies, Inc.

  • Jan-Harald Fredriksen, ARM

Description

This extension adds additional features and properties to VK_EXT_fragment_density_map in order to reduce fragment density map host latency as well as improved queries for subsampled sampler implementation-dependent behavior.

New Enum Constants
  • VK_EXT_FRAGMENT_DENSITY_MAP_2_EXTENSION_NAME

  • VK_EXT_FRAGMENT_DENSITY_MAP_2_SPEC_VERSION

  • Extending VkImageViewCreateFlagBits:

    • VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DEFERRED_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_PROPERTIES_EXT

Version History
  • Revision 1, 2020-06-16 (Matthew Netsch)

    • Initial version

VK_EXT_fragment_shader_interlock

Name String

VK_EXT_fragment_shader_interlock

Extension Type

Device extension

Registered Extension Number

252

Revision

1

Ratification Status

Not ratified

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

2019-05-02

Interactions and External Dependencies
Contributors