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.

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

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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).

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: Require specifying a plane explicitly.

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

PROPOSED RESOLUTION: 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?

PROPOSED RESOLUTION: 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.

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

12) Should hardware cursor capabilities be exposed?

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

editing-note

There appears to be a missing sentence for the first part of issue 13 here.

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

editing-note

(Jon) This issue refers to a token from VK_KHR_external_semaphore_win32, but there is no dependency or interaction with that extension defined above.

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

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_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),
  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
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
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
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
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
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
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_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
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_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
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
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
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_video_decode_h264

Name String

VK_KHR_video_decode_h264

Extension Type

Device extension

Registered Extension Number

41

Revision

8

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_KHR_video_decode_h264

Other Extension Metadata

Last Modified Date

2022-09-29

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

VK_KHR_video_decode_h265

Name String

VK_KHR_video_decode_h265

Extension Type

Device extension

Registered Extension Number

188

Revision

7

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_KHR_video_decode_h265

Other Extension Metadata

Last Modified Date

2022-11-14

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

VK_KHR_video_decode_queue

Name String

VK_KHR_video_decode_queue

Extension Type

Device extension

Registered Extension Number

25

Revision

7

Ratification Status

Ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_KHR_video_decode_queue

Other Extension Metadata

Last Modified Date

2022-09-29

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

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

Name String

VK_EXT_attachment_feedback_loop_layout

Extension Type

Device extension

Registered Extension Number

340

Revision

2

Ratification Status

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

Name String

VK_EXT_calibrated_timestamps

Extension Type

Device extension

Registered Extension Number

185

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_calibrated_timestamps

Other Extension Metadata

Last Modified Date

2018-10-04

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Alan Harrison, AMD

  • Derrick Owens, AMD

  • Daniel Rakos, AMD

  • Faith Ekstrand, Intel

  • Keith Packard, Valve

Description

This extension provides an interface to query calibrated timestamps obtained quasi simultaneously from two time domains.

New Enums

New Enum Constants

  • VK_EXT_CALIBRATED_TIMESTAMPS_EXTENSION_NAME

  • VK_EXT_CALIBRATED_TIMESTAMPS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT

Version History

  • Revision 2, 2021-03-16 (Lionel Landwerlin)

    • Specify requirement on device timestamps

  • Revision 1, 2018-10-04 (Daniel Rakos)

    • Internal revisions.

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

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

Name String

VK_EXT_extended_dynamic_state3

Extension Type

Device extension

Registered Extension Number

456

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_extended_dynamic_state3

Other Extension Metadata

Last Modified Date

2022-09-02

IP Status

No known IP claims.

Contributors
  • Daniel Story, Nintendo

  • Jamie Madill, Google

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Collabora

  • Mike Blumenkrantz, Valve

  • Ricardo Garcia, Igalia

  • Samuel Pitoiset, Valve

  • Shahbaz Youssefi, Google

  • Stu Smith, AMD

  • Tapani Pälli, Intel

Description

This extension adds almost all of the remaining pipeline state as dynamic state to help applications further reduce the number of monolithic pipelines they need to create and bind.

New Enum Constants

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_3_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_ALPHA_TO_COVERAGE_ENABLE_EXT

    • VK_DYNAMIC_STATE_ALPHA_TO_ONE_ENABLE_EXT

    • VK_DYNAMIC_STATE_COLOR_BLEND_ADVANCED_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_CONSERVATIVE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLAMP_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLIP_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_CLIP_NEGATIVE_ONE_TO_ONE_EXT

    • VK_DYNAMIC_STATE_EXTRA_PRIMITIVE_OVERESTIMATION_SIZE_EXT

    • VK_DYNAMIC_STATE_LINE_RASTERIZATION_MODE_EXT

    • VK_DYNAMIC_STATE_LINE_STIPPLE_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_ENABLE_EXT

    • VK_DYNAMIC_STATE_POLYGON_MODE_EXT

    • VK_DYNAMIC_STATE_PROVOKING_VERTEX_MODE_EXT

    • VK_DYNAMIC_STATE_RASTERIZATION_SAMPLES_EXT

    • VK_DYNAMIC_STATE_RASTERIZATION_STREAM_EXT

    • VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_ENABLE_EXT

    • VK_DYNAMIC_STATE_SAMPLE_MASK_EXT

    • VK_DYNAMIC_STATE_TESSELLATION_DOMAIN_ORIGIN_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_3_PROPERTIES_EXT

If VK_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_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
Contact
  • Bill Licea-Kane wwlk

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

Other Extension Metadata

Last Modified Date

2019-05-02

Interactions and External Dependencies
Contributors
  • Daniel Koch, NVIDIA

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Ruihao Zhang, Qualcomm

  • Slawomir Grajewski, Intel

  • Spencer Fricke, Samsung

Description

This extension adds support for the FragmentShaderPixelInterlockEXT, FragmentShaderSampleInterlockEXT, and FragmentShaderShadingRateInterlockEXT capabilities from the SPV_EXT_fragment_shader_interlock extension to Vulkan.

Enabling these capabilities provides a critical section for fragment shaders to avoid overlapping pixels being processed at the same time, and certain guarantees about the ordering of fragment shader invocations of fragments of overlapping pixels.

This extension can be useful for algorithms that need to access per-pixel data structures via shader loads and stores. Algorithms using this extension can access per-pixel data structures in critical sections without other invocations accessing the same per-pixel data. Additionally, the ordering guarantees are useful for cases where the API ordering of fragments is meaningful. For example, applications may be able to execute programmable blending operations in the fragment shader, where the destination buffer is read via image loads and the final value is written via image stores.

New Enum Constants

  • VK_EXT_FRAGMENT_SHADER_INTERLOCK_EXTENSION_NAME

  • VK_EXT_FRAGMENT_SHADER_INTERLOCK_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_INTERLOCK_FEATURES_EXT

Version History

  • Revision 1, 2019-05-24 (Piers Daniell)

    • Internal revisions

VK_EXT_full_screen_exclusive

Name String

VK_EXT_full_screen_exclusive

Extension Type

Device extension

Registered Extension Number

256

Revision

4

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-03-12

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Hans-Kristian Arntzen, ARM

  • Slawomir Grajewski, Intel

  • Tobias Hector, AMD

  • James Jones, NVIDIA

  • Daniel Rakos, AMD

  • Jeff Juliano, NVIDIA

  • Joshua Schnarr, NVIDIA

  • Aaron Hagan, AMD

Description

This extension allows applications to set the policy for swapchain creation and presentation mechanisms relating to full-screen access. Implementations may be able to acquire exclusive access to a particular display for an application window that covers the whole screen. This can increase performance on some systems by bypassing composition, however it can also result in disruptive or expensive transitions in the underlying windowing system when a change occurs.

Applications can choose between explicitly disallowing or allowing this behavior, letting the implementation decide, or managing this mode of operation directly using the new vkAcquireFullScreenExclusiveModeEXT and vkReleaseFullScreenExclusiveModeEXT commands.

New Enum Constants

  • VK_EXT_FULL_SCREEN_EXCLUSIVE_EXTENSION_NAME

  • VK_EXT_FULL_SCREEN_EXCLUSIVE_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_FULL_SCREEN_EXCLUSIVE_EXT

    • VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_INFO_EXT

If VK_KHR_win32_surface is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_WIN32_INFO_EXT

Issues

1) What should the extension & flag be called?

RESOLVED: VK_EXT_full_screen_exclusive.

Other options considered (prior to the app-controlled mode) were:

  • VK_EXT_smooth_fullscreen_transition

  • VK_EXT_fullscreen_behavior

  • VK_EXT_fullscreen_preference

  • VK_EXT_fullscreen_hint

  • VK_EXT_fast_fullscreen_transition

  • VK_EXT_avoid_fullscreen_exclusive

2) Do we need more than a boolean toggle?

RESOLVED: Yes.

Using an enum with default/allowed/disallowed/app-controlled enables applications to accept driver default behavior, specifically override it in either direction without implying the driver is ever required to use full-screen exclusive mechanisms, or manage this mode explicitly.

3) Should this be a KHR or EXT extension?

RESOLVED: EXT, in order to allow it to be shipped faster.

4) Can the fullscreen hint affect the surface capabilities, and if so, should the hint also be specified as input when querying the surface capabilities?

RESOLVED: Yes on both accounts.

While the hint does not guarantee a particular fullscreen mode will be used when the swapchain is created, it can sometimes imply particular modes will NOT be used. If the driver determines that it will opt-out of using a particular mode based on the policy, and knows it can only support certain capabilities if that mode is used, it would be confusing at best to the application to report those capabilities in such cases. Not allowing implementations to report this state to applications could result in situations where applications are unable to determine why swapchain creation fails when they specify certain hint values, which could result in never- terminating surface creation loops.

5) Should full-screen be one word or two?

RESOLVED: Two words.

"Fullscreen" is not in my dictionary, and web searches did not turn up definitive proof that it is a colloquially accepted compound word. Documentation for the corresponding Windows API mechanisms dithers. The text consistently uses a hyphen, but none-the-less, there is a SetFullscreenState method in the DXGI swapchain object. Given this inconclusive external guidance, it is best to adhere to the Vulkan style guidelines and avoid inventing new compound words.

Version History

  • Revision 4, 2019-03-12 (Tobias Hector)

    • Added application-controlled mode, and related functions

    • Tidied up appendix

  • Revision 3, 2019-01-03 (James Jones)

    • Renamed to VK_EXT_full_screen_exclusive

    • Made related adjustments to the tri-state enumerant names.

  • Revision 2, 2018-11-27 (James Jones)

    • Renamed to VK_KHR_fullscreen_behavior

    • Switched from boolean flag to tri-state enum

  • Revision 1, 2018-11-06 (James Jones)

    • Internal revision

VK_EXT_graphics_pipeline_library

Name String

VK_EXT_graphics_pipeline_library

Extension Type

Device extension

Registered Extension Number

321

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_graphics_pipeline_library

Other Extension Metadata

Last Modified Date

2021-08-17

Contributors
  • Tobias Hector, AMD

  • Chris Glover, Google

  • Jeff Leger, Qualcomm

  • Jan-Harald Fredriksen, Arm

  • Piers Daniell, NVidia

  • Boris Zanin, Mobica

  • Krzysztof Niski, NVidia

  • Dan Ginsburg, Valve

  • Sebastian Aaltonen, Unity

  • Arseny Kapoulkine, Roblox

  • Calle Lejdfors, Ubisoft

  • Tiago Rodrigues, Ubisoft

  • Francois Duranleau, Gameloft

Description

This extension allows the separate compilation of four distinct parts of graphics pipelines, with the intent of allowing faster pipeline loading for applications reusing the same shaders or state in multiple pipelines. Each part can be independently compiled into a graphics pipeline library, with a final link step required to create an executable pipeline that can be bound to a command buffer.

New Enum Constants

  • VK_EXT_GRAPHICS_PIPELINE_LIBRARY_EXTENSION_NAME

  • VK_EXT_GRAPHICS_PIPELINE_LIBRARY_SPEC_VERSION

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT

    • VK_PIPELINE_CREATE_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT

  • Extending VkPipelineLayoutCreateFlagBits:

    • VK_PIPELINE_LAYOUT_CREATE_INDEPENDENT_SETS_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_LIBRARY_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_PROPERTIES_EXT

Version History

  • Revision 1, 2021-08-17 (Tobias Hector)

    • Initial draft.

VK_EXT_hdr_metadata

Name String

VK_EXT_hdr_metadata

Extension Type

Device extension

Registered Extension Number

106

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-12-19

IP Status

No known IP claims.

Contributors
  • Courtney Goeltzenleuchter, Google

Description

This extension defines two new structures and a function to assign SMPTE (the Society of Motion Picture and Television Engineers) 2086 metadata and CTA (Consumer Technology Association) 861.3 metadata to a swapchain. The metadata includes the color primaries, white point, and luminance range of the reference monitor, which all together define the color volume containing all the possible colors the reference monitor can produce. The reference monitor is the display where creative work is done and creative intent is established. To preserve such creative intent as much as possible and achieve consistent color reproduction on different viewing displays, it is useful for the display pipeline to know the color volume of the original reference monitor where content was created or tuned. This avoids performing unnecessary mapping of colors that are not displayable on the original reference monitor. The metadata also includes the maxContentLightLevel and maxFrameAverageLightLevel as defined by CTA 861.3.

While the intended purpose of the metadata is to assist in the transformation between different color volumes of different displays and help achieve better color reproduction, it is not in the scope of this extension to define how exactly the metadata should be used in such a process. It is up to the implementation to determine how to make use of the metadata.

New Commands

New Enum Constants

  • VK_EXT_HDR_METADATA_EXTENSION_NAME

  • VK_EXT_HDR_METADATA_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_HDR_METADATA_EXT

Issues

1) Do we need a query function?

PROPOSED: No, Vulkan does not provide queries for state that the application can track on its own.

2) Should we specify default if not specified by the application?

PROPOSED: No, that leaves the default up to the display.

Version History

  • Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)

    • Initial version

  • Revision 2, 2018-12-19 (Courtney Goeltzenleuchter)

    • Correct implicit validity for VkHdrMetadataEXT structure

VK_EXT_headless_surface

Name String

VK_EXT_headless_surface

Extension Type

Instance extension

Registered Extension Number

257

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-03-21

IP Status

No known IP claims.

Contributors
  • Ray Smith, Arm

Description

The VK_EXT_headless_surface extension is an instance extension. It provides a mechanism to create VkSurfaceKHR objects independently of any window system or display device. The presentation operation for a swapchain created from a headless surface is by default a no-op, resulting in no externally-visible result.

Because there is no real presentation target, future extensions can layer on top of the headless surface to introduce arbitrary or customisable sets of restrictions or features. These could include features like saving to a file or restrictions to emulate a particular presentation target.

This functionality is expected to be useful for application and driver development because it allows any platform to expose an arbitrary or customisable set of restrictions and features of a presentation engine. This makes it a useful portable test target for applications targeting a wide range of presentation engines where the actual target presentation engines might be scarce, unavailable or otherwise undesirable or inconvenient to use for general Vulkan application development.

New Enum Constants

  • VK_EXT_HEADLESS_SURFACE_EXTENSION_NAME

  • VK_EXT_HEADLESS_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_HEADLESS_SURFACE_CREATE_INFO_EXT

Version History

  • Revision 1, 2019-03-21 (Ray Smith)

    • Initial draft

VK_EXT_image_2d_view_of_3d

Name String

VK_EXT_image_2d_view_of_3d

Extension Type

Device extension

Registered Extension Number

394

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
  • Mike Blumenkrantz zmike

Other Extension Metadata

Last Modified Date

2022-02-22

IP Status

No known IP claims.

Contributors
  • Mike Blumenkrantz, Valve

  • Piers Daniell, NVIDIA

  • Spencer Fricke, Samsung

  • Ricardo Garcia, Igalia

  • Graeme Leese, Broadcom

  • Ralph Potter, Samsung

  • Stu Smith, AMD

  • Shahbaz Youssefi, Google

  • Alex Walters, Imagination

Description

This extension allows a single slice of a 3D image to be used as a 2D view in image descriptors, matching both the functionality of glBindImageTexture in OpenGL with the layer parameter set to true and 2D view binding provided by the extension EGL_KHR_gl_texture_3D_image. It is primarily intended to support GL emulation.

New Enum Constants

  • VK_EXT_IMAGE_2D_VIEW_OF_3D_EXTENSION_NAME

  • VK_EXT_IMAGE_2D_VIEW_OF_3D_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_2D_VIEW_OF_3D_FEATURES_EXT

Version History

  • Revision 1, 2022-03-25 (Mike Blumenkrantz)

    • Internal revisions

VK_EXT_image_compression_control

Name String

VK_EXT_image_compression_control

Extension Type

Device extension

Registered Extension Number

339

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_image_compression_control

Other Extension Metadata

Last Modified Date

2022-05-02

IP Status

No known IP claims.

Contributors
  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Andrew Garrard, Imagination

  • Lisa Wu, Arm

  • Peter Kohaut, Arm

Description

This extension enables fixed-rate image compression and adds the ability to control when this kind of compression can be applied. Many implementations support some form of framebuffer compression. This is typically transparent to applications as lossless compression schemes are used. With fixed-rate compression, the compression is done at a defined bitrate. Such compression algorithms generally produce results that are visually lossless, but the results are typically not bit-exact when compared to a non-compressed result. The implementation may not be able to use the requested compression rate in all cases. This extension adds a query that can be used to determine the compression scheme and rate that was applied to an image.

New Enum Constants

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_EXTENSION_NAME

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_COMPRESSION_EXHAUSTED_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_CONTROL_EXT

    • VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_EXT

Version History

  • Revision 1, 2022-05-02 (Jan-Harald Fredriksen)

    • Initial draft

VK_EXT_image_compression_control_swapchain

Name String

VK_EXT_image_compression_control_swapchain

Extension Type

Device extension

Registered Extension Number

438

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-05-02

IP Status

No known IP claims.

Contributors
  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Andrew Garrard, Imagination

  • Lisa Wu, Arm

  • Peter Kohaut, Arm

  • Ian Elliott, Google

Description

This extension enables fixed-rate image compression and adds the ability to control when this kind of compression can be applied to swapchain images.

New Enum Constants

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_EXTENSION_NAME

  • VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_FEATURES_EXT

Version History

  • Revision 1, 2022-05-02 (Jan-Harald Fredriksen)

    • Initial draft

VK_EXT_image_drm_format_modifier

Name String

VK_EXT_image_drm_format_modifier

Extension Type

Device extension

Registered Extension Number

159

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies

         VK_KHR_bind_memory2
         and
         VK_KHR_get_physical_device_properties2
         and
         VK_KHR_sampler_ycbcr_conversion
     or
     Version 1.1
and
     VK_KHR_image_format_list
     or
     Version 1.2

Contact

Other Extension Metadata

Last Modified Date

2021-09-30

IP Status

No known IP claims.

Contributors
  • Antoine Labour, Google

  • Bas Nieuwenhuizen, Google

  • Lina Versace, Google

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

  • Jőrg Wagner, ARM

  • Kristian Høgsberg Kristensen, Google

  • Ray Smith, ARM

Description

This extension provides the ability to use DRM format modifiers with images, enabling Vulkan to better integrate with the Linux ecosystem of graphics, video, and display APIs.

Its functionality closely overlaps with EGL_EXT_image_dma_buf_import_modifiers2 and EGL_MESA_image_dma_buf_export3. Unlike the EGL extensions, this extension does not require the use of a specific handle type (such as a dma_buf) for external memory and provides more explicit control of image creation.

Introduction to DRM Format Modifiers

A DRM format modifier is a 64-bit, vendor-prefixed, semi-opaque unsigned integer. Most modifiers represent a concrete, vendor-specific tiling format for images. Some exceptions are DRM_FORMAT_MOD_LINEAR (which is not vendor-specific); DRM_FORMAT_MOD_NONE (which is an alias of DRM_FORMAT_MOD_LINEAR due to historical accident); and DRM_FORMAT_MOD_INVALID (which does not represent a tiling format). The modifier’s vendor prefix consists of the 8 most significant bits. The canonical list of modifiers and vendor prefixes is found in drm_fourcc.h in the Linux kernel source. The other dominant source of modifiers are vendor kernel trees.

One goal of modifiers in the Linux ecosystem is to enumerate for each vendor a reasonably sized set of tiling formats that are appropriate for images shared across processes, APIs, and/or devices, where each participating component may possibly be from different vendors. A non-goal is to enumerate all tiling formats supported by all vendors. Some tiling formats used internally by vendors are inappropriate for sharing; no modifiers should be assigned to such tiling formats.

Modifier values typically do not describe memory layouts. More precisely, a modifier's lower 56 bits usually have no structure. Instead, modifiers name memory layouts; they name a small set of vendor-preferred layouts for image sharing. As a consequence, in each vendor namespace the modifier values are often sequentially allocated starting at 1.

Each modifier is usually supported by a single vendor and its name matches the pattern {VENDOR}_FORMAT_MOD_* or DRM_FORMAT_MOD_{VENDOR}_*. Examples are I915_FORMAT_MOD_X_TILED and DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED. An exception is DRM_FORMAT_MOD_LINEAR, which is supported by most vendors.

Many APIs in Linux use modifiers to negotiate and specify the memory layout of shared images. For example, a Wayland compositor and Wayland client may, by relaying modifiers over the Wayland protocol zwp_linux_dmabuf_v1, negotiate a vendor-specific tiling format for a shared wl_buffer. The client may allocate the underlying memory for the wl_buffer with GBM, providing the chosen modifier to gbm_bo_create_with_modifiers. The client may then import the wl_buffer into Vulkan for producing image content, providing the resource’s dma_buf to VkImportMemoryFdInfoKHR and its modifier to VkImageDrmFormatModifierExplicitCreateInfoEXT. The compositor may then import the wl_buffer into OpenGL for sampling, providing the resource’s dma_buf and modifier to eglCreateImage. The compositor may also bypass OpenGL and submit the wl_buffer directly to the kernel’s display API, providing the dma_buf and modifier through drm_mode_fb_cmd2.

Format Translation

Modifier-capable APIs often pair modifiers with DRM formats, which are defined in drm_fourcc.h. However, VK_EXT_image_drm_format_modifier uses VkFormat instead of DRM formats. The application must convert between VkFormat and DRM format when it sends or receives a DRM format to or from an external API.

The mapping from VkFormat to DRM format is lossy. Therefore, when receiving a DRM format from an external API, often the application must use information from the external API to accurately map the DRM format to a VkFormat. For example, DRM formats do not distinguish between RGB and sRGB (as of 2018-03-28); external information is required to identify the image’s color space.

The mapping between VkFormat and DRM format is also incomplete. For some DRM formats there exist no corresponding Vulkan format, and for some Vulkan formats there exist no corresponding DRM format.

Usage Patterns

Three primary usage patterns are intended for this extension:

  • Negotiation. The application negotiates with modifier-aware, external components to determine sets of image creation parameters supported among all components.

    In the Linux ecosystem, the negotiation usually assumes the image is a 2D, single-sampled, non-mipmapped, non-array image; this extension permits that assumption but does not require it. The result of the negotiation usually resembles a set of tuples such as (drmFormat, drmFormatModifier), where each participating component supports all tuples in the set.

    Many details of this negotiation - such as the protocol used during negotiation, the set of image creation parameters expressible in the protocol, and how the protocol chooses which process and which API will create the image - are outside the scope of this specification.

    In this extension, vkGetPhysicalDeviceFormatProperties2 with VkDrmFormatModifierPropertiesListEXT serves a primary role during the negotiation, and vkGetPhysicalDeviceImageFormatProperties2 with VkPhysicalDeviceImageDrmFormatModifierInfoEXT serves a secondary role.

  • Import. The application imports an image with a modifier.

    In this pattern, the application receives from an external source the image’s memory and its creation parameters, which are often the result of the negotiation described above. Some image creation parameters are implicitly defined by the external source; for example, VK_IMAGE_TYPE_2D is often assumed. Some image creation parameters are usually explicit, such as the image’s format, drmFormatModifier, and extent; and each plane’s offset and rowPitch.

    Before creating the image, the application first verifies that the physical device supports the received creation parameters by querying vkGetPhysicalDeviceFormatProperties2 with VkDrmFormatModifierPropertiesListEXT and vkGetPhysicalDeviceImageFormatProperties2 with VkPhysicalDeviceImageDrmFormatModifierInfoEXT. Then the application creates the image by chaining VkImageDrmFormatModifierExplicitCreateInfoEXT and VkExternalMemoryImageCreateInfo onto VkImageCreateInfo.

  • Export. The application creates an image and allocates its memory. Then the application exports to modifier-aware consumers the image’s memory handles; its creation parameters; its modifier; and the offset, size, and rowPitch of each memory plane.

    In this pattern, the Vulkan device is the authority for the image; it is the allocator of the image’s memory and the decider of the image’s creation parameters. When choosing the image’s creation parameters, the application usually chooses a tuple (format, drmFormatModifier) from the result of the negotiation described above. The negotiation’s result often contains multiple tuples that share the same format but differ in their modifier. In this case, the application should defer the choice of the image’s modifier to the Vulkan implementation by providing all such modifiers to VkImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers; and the implementation should choose from pDrmFormatModifiers the optimal modifier in consideration with the other image parameters.

    The application creates the image by chaining VkImageDrmFormatModifierListCreateInfoEXT and VkExternalMemoryImageCreateInfo onto VkImageCreateInfo. The protocol and APIs by which the application will share the image with external consumers will likely determine the value of VkExternalMemoryImageCreateInfo::handleTypes. The implementation chooses for the image an optimal modifier from VkImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers. The application then queries the implementation-chosen modifier with vkGetImageDrmFormatModifierPropertiesEXT, and queries the memory layout of each plane with vkGetImageSubresourceLayout.

    The application then allocates the image’s memory with VkMemoryAllocateInfo, adding chained extending structures for external memory; binds it to the image; and exports the memory, for example, with vkGetMemoryFdKHR.

    Finally, the application sends the image’s creation parameters, its modifier, its per-plane memory layout, and the exported memory handle to the external consumers. The details of how the application transmits this information to external consumers is outside the scope of this specification.

Prior Art

Extension EGL_EXT_image_dma_buf_import1 introduced the ability to create an EGLImage by importing for each plane a dma_buf, offset, and row pitch.

Later, extension EGL_EXT_image_dma_buf_import_modifiers2 introduced the ability to query which combination of formats and modifiers the implementation supports and to specify modifiers during creation of the EGLImage.

Extension EGL_MESA_image_dma_buf_export3 is the inverse of EGL_EXT_image_dma_buf_import_modifiers.

The Linux kernel modesetting API (KMS), when configuring the display’s framebuffer with struct drm_mode_fb_cmd24, allows one to specify the framebuffer’s modifier as well as a per-plane memory handle, offset, and row pitch.

GBM, a graphics buffer manager for Linux, allows creation of a gbm_bo (that is, a graphics buffer object) by importing data similar to that in EGL_EXT_image_dma_buf_import_modifiers1; and symmetrically allows exporting the same data from the gbm_bo. See the references to modifier and plane in gbm.h5.

New Enum Constants

  • VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME

  • VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION

  • Extending VkImageAspectFlagBits:

    • VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT

    • VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT

  • Extending VkImageTiling:

    • VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT

  • Extending VkResult:

    • VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT

If VK_KHR_format_feature_flags2 is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_2_EXT

Issues

1) Should this extension define a single DRM format modifier per VkImage? Or define one per plane?

+

RESOLVED: There exists a single DRM format modifier per VkImage.

DISCUSSION: Prior art, such as EGL_EXT_image_dma_buf_import_modifiers2, struct drm_mode_fb_cmd24, and struct gbm_import_fd_modifier_data5, allows defining one modifier per plane. However, developers of the GBM and kernel APIs concede it was a mistake. Beginning in Linux 4.10, the kernel requires that the application provide the same DRM format modifier for each plane. (See Linux commit bae781b259269590109e8a4a8227331362b88212). And GBM provides an entry point, gbm_bo_get_modifier, for querying the modifier of the image but does not provide one to query the modifier of individual planes.

2) When creating an image with VkImageDrmFormatModifierExplicitCreateInfoEXT, which is typically used when importing an image, should the application explicitly provide the size of each plane?

+

RESOLVED: No. The application must not provide the size. To enforce this, the API requires that VkImageDrmFormatModifierExplicitCreateInfoEXT::pPlaneLayouts->size must be 0.

DISCUSSION: Prior art, such as EGL_EXT_image_dma_buf_import_modifiers2, struct drm_mode_fb_cmd24, and struct gbm_import_fd_modifier_data5, omits from the API the size of each plane. Instead, the APIs infer each plane’s size from the import parameters, which include the image’s pixel format and a dma_buf, offset, and row pitch for each plane.

However, Vulkan differs from EGL and GBM with regards to image creation in the following ways:

Differences in Image Creation
  • Undedicated allocation by default. When importing or exporting a set of dma_bufs as an EGLImage or gbm_bo, common practice mandates that each dma_buf’s memory be dedicated (in the sense of VK_KHR_dedicated_allocation) to the image (though not necessarily dedicated to a single plane). In particular, neither the GBM documentation nor the EGL extension specifications explicitly state this requirement, but in light of common practice this is likely due to under-specification rather than intentional omission. In contrast, VK_EXT_image_drm_format_modifier permits, but does not require, the implementation to require dedicated allocations for images created with VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.

  • Separation of image creation and memory allocation. When importing a set of dma_bufs as an EGLImage or gbm_bo, EGL and GBM create the image resource and bind it to memory (the dma_bufs) simultaneously. This allows EGL and GBM to query each dma_buf’s size during image creation. In Vulkan, image creation and memory allocation are independent unless a dedicated allocation is used (as in VK_KHR_dedicated_allocation). Therefore, without requiring dedicated allocation, Vulkan cannot query the size of each dma_buf (or other external handle) when calculating the image’s memory layout. Even if dedication allocation were required, Vulkan cannot calculate the image’s memory layout until after the image is bound to its dma_ufs.

The above differences complicate the potential inference of plane size in Vulkan. Consider the following problematic cases:

Problematic Plane Size Calculations
  • Padding. Some plane of the image may require implementation-dependent padding.

  • Metadata. For some modifiers, the image may have a metadata plane which requires a non-trivial calculation to determine its size.

  • Mipmapped, array, and 3D images. The implementation may support VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT for images whose mipLevels, arrayLayers, or depth is greater than 1. For such images with certain modifiers, the calculation of each plane’s size may be non-trivial.

However, an application-provided plane size solves none of the above problems.

For simplicity, consider an external image with a single memory plane. The implementation is obviously capable calculating the image’s size when its tiling is VK_IMAGE_TILING_OPTIMAL. Likewise, any reasonable implementation is capable of calculating the image’s size when its tiling uses a supported modifier.

Suppose that the external image’s size is smaller than the implementation-calculated size. If the application provided the external image’s size to vkCreateImage, the implementation would observe the mismatched size and recognize its inability to comprehend the external image’s layout (unless the implementation used the application-provided size to select a refinement of the tiling layout indicated by the modifier, which is strongly discouraged). The implementation would observe the conflict, and reject image creation with VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On the other hand, if the application did not provide the external image’s size to vkCreateImage, then the application would observe after calling vkGetImageMemoryRequirements that the external image’s size is less than the size required by the implementation. The application would observe the conflict and refuse to bind the VkImage to the external memory. In both cases, the result is explicit failure.

Suppose that the external image’s size is larger than the implementation-calculated size. If the application provided the external image’s size to vkCreateImage, for reasons similar to above the implementation would observe the mismatched size and recognize its inability to comprehend the image data residing in the extra size. The implementation, however, must assume that image data resides in the entire size provided by the application. The implementation would observe the conflict and reject image creation with VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On the other hand, if the application did not provide the external image’s size to vkCreateImage, then the application would observe after calling vkGetImageMemoryRequirements that the external image’s size is larger than the implementation-usable size. The application would observe the conflict and refuse to bind the VkImage to the external memory. In both cases, the result is explicit failure.

Therefore, an application-provided size provides no benefit, and this extension should not require it. This decision renders VkSubresourceLayout::size an unused field during image creation, and thus introduces a risk that implementations may require applications to submit sideband creation parameters in the unused field. To prevent implementations from relying on sideband data, this extension requires the application to set size to 0.

Version History
  • Revision 1, 2018-08-29 (Lina Versace)

    • First stable revision

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

VK_EXT_image_sliced_view_of_3d

Name String

VK_EXT_image_sliced_view_of_3d

Extension Type

Device extension

Registered Extension Number

419

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
  • Mike Blumenkrantz zmike

Extension Proposal

VK_EXT_image_sliced_view_of_3d

Other Extension Metadata

Last Modified Date

2023-01-24

IP Status

No known IP claims.

Contributors
  • Mike Blumenkrantz, Valve

  • Hans-Kristian Arntzen, Valve

  • Ricardo Garcia, Igalia

  • Shahbaz Youssefi, Google

  • Piers Daniell, NVIDIA

Description

This extension allows creating 3D views of 3D images such that the views contain a subset of the slices in the image, using a Z offset and range, for the purpose of using the views as storage image descriptors. This matches functionality in D3D12 and is primarily intended to support D3D12 emulation.

New Enum Constants

  • VK_EXT_IMAGE_SLICED_VIEW_OF_3D_EXTENSION_NAME

  • VK_EXT_IMAGE_SLICED_VIEW_OF_3D_SPEC_VERSION

  • VK_REMAINING_3D_SLICES_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_SLICED_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_SLICED_VIEW_OF_3D_FEATURES_EXT

Version History

  • Revision 1, 2022-10-21 (Mike Blumenkrantz)

    • Initial revision

VK_EXT_image_view_min_lod

Name String

VK_EXT_image_view_min_lod

Extension Type

Device extension

Registered Extension Number

392

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-11-09

IP Status

No known IP claims.

Contributors
  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

  • Samuel Iglesias Gonsalvez, Igalia

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Tom Olson, ARM

Description

This extension allows applications to clamp the minimum LOD value during Image Level(s) Selection, Texel Gathering and Integer Texel Coordinate Operations with a given VkImageView by VkImageViewMinLodCreateInfoEXT::minLod.

This extension may be useful to restrict a VkImageView to only mips which have been uploaded, and the use of fractional minLod can be useful for smoothly introducing new mip levels when using linear mipmap filtering.

New Enum Constants

  • VK_EXT_IMAGE_VIEW_MIN_LOD_EXTENSION_NAME

  • VK_EXT_IMAGE_VIEW_MIN_LOD_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_MIN_LOD_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_MIN_LOD_FEATURES_EXT

Version History

  • Revision 1, 2021-07-06 (Joshua Ashton)

    • Initial version

VK_EXT_index_type_uint8

Name String

VK_EXT_index_type_uint8

Extension Type

Device extension

Registered Extension Number

266

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-05-02

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension allows uint8_t indices to be used with vkCmdBindIndexBuffer.

New Enum Constants

  • VK_EXT_INDEX_TYPE_UINT8_EXTENSION_NAME

  • VK_EXT_INDEX_TYPE_UINT8_SPEC_VERSION

  • Extending VkIndexType:

    • VK_INDEX_TYPE_UINT8_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_EXT

Version History

  • Revision 1, 2019-05-02 (Piers Daniell)

    • Internal revisions

VK_EXT_legacy_dithering

Name String

VK_EXT_legacy_dithering

Extension Type

Device extension

Registered Extension Number

466

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
Extension Proposal

VK_EXT_legacy_dithering

Other Extension Metadata

Last Modified Date

2022-03-31

Contributors
  • Shahbaz Youssefi, Google

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, Arm

Description

This extension exposes a hardware feature used by some vendors to implement OpenGL’s dithering. The purpose of this extension is to support layering OpenGL over Vulkan, by allowing the layer to take advantage of the same hardware feature and provide equivalent dithering to OpenGL applications.

New Enum Constants

  • VK_EXT_LEGACY_DITHERING_EXTENSION_NAME

  • VK_EXT_LEGACY_DITHERING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_DITHERING_FEATURES_EXT

  • Extending VkSubpassDescriptionFlagBits:

    • VK_SUBPASS_DESCRIPTION_ENABLE_LEGACY_DITHERING_BIT_EXT

If VK_KHR_dynamic_rendering is supported:

If Version 1.3 is supported:

Version History

  • Revision 1, 2022-03-31 (Shahbaz Youssefi)

    • Internal revisions

Issues

1) In OpenGL, the dither state can change dynamically. Should this extension add a pipeline state for dither?

RESOLVED: No. Changing dither state is rarely, if ever, done during rendering. Every surveyed Android application either entirely disables dither, explicitly enables it, or uses the default state (which is enabled). Additionally, on some hardware dither can only be specified in a render pass granularity, so a change in dither state would necessarily need to cause a render pass break. This extension considers dynamic changes in OpenGL dither state a theoretical situation, and expects the layer to break the render pass in such a situation without any practical downsides.

VK_EXT_line_rasterization

Name String

VK_EXT_line_rasterization

Extension Type

Device extension

Registered Extension Number

260

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2019-05-09

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Allen Jensen, NVIDIA

  • Faith Ekstrand, Intel

Description

This extension adds some line rasterization features that are commonly used in CAD applications and supported in other APIs like OpenGL. Bresenham-style line rasterization is supported, smooth rectangular lines (coverage to alpha) are supported, and stippled lines are supported for all three line rasterization modes.

New Commands

New Enum Constants

  • VK_EXT_LINE_RASTERIZATION_EXTENSION_NAME

  • VK_EXT_LINE_RASTERIZATION_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_LINE_STIPPLE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINE_RASTERIZATION_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_LINE_STATE_CREATE_INFO_EXT

Issues

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

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

Version History

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

    • Initial draft

VK_EXT_load_store_op_none

Name String

VK_EXT_load_store_op_none

Extension Type

Device extension

Registered Extension Number

401

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-06-06

Contributors
  • Shahbaz Youssefi, Google

  • Bill Licea-Kane, Qualcomm Technologies, Inc.

  • Tobias Hector, AMD

Description

This extension incorporates VK_ATTACHMENT_STORE_OP_NONE_EXT from VK_QCOM_render_pass_store_ops, enabling applications to avoid unnecessary synchronization when an attachment is not written during a render pass.

Additionally, VK_ATTACHMENT_LOAD_OP_NONE_EXT is introduced to avoid unnecessary synchronization when an attachment is not used during a render pass at all. In combination with VK_ATTACHMENT_STORE_OP_NONE_EXT, this is useful as an alternative to preserve attachments in applications that cannot decide if an attachment will be used in a render pass until after the necessary pipelines have been created.

New Enum Constants

  • VK_EXT_LOAD_STORE_OP_NONE_EXTENSION_NAME

  • VK_EXT_LOAD_STORE_OP_NONE_SPEC_VERSION

  • Extending VkAttachmentLoadOp:

    • VK_ATTACHMENT_LOAD_OP_NONE_EXT

  • Extending VkAttachmentStoreOp:

    • VK_ATTACHMENT_STORE_OP_NONE_EXT

Version History

  • Revision 1, 2021-06-06 (Shahbaz Youssefi)

    • Initial revision, based on VK_QCOM_render_pass_store_ops.

    • Added VK_ATTACHMENT_LOAD_OP_NONE_EXT.

VK_EXT_memory_budget

Name String

VK_EXT_memory_budget

Extension Type

Device extension

Registered Extension Number

238

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-10-08

Contributors
  • Jeff Bolz, NVIDIA

  • Jeff Juliano, NVIDIA

Description

While running a Vulkan application, other processes on the machine might also be attempting to use the same device memory, which can pose problems. This extension adds support for querying the amount of memory used and the total memory budget for a memory heap. The values returned by this query are implementation-dependent and can depend on a variety of factors including operating system and system load.

The VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapBudget values can be used as a guideline for how much total memory from each heap the current process can use at any given time, before allocations may start failing or causing performance degradation. The values may change based on other activity in the system that is outside the scope and control of the Vulkan implementation.

The VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapUsage will display the current process estimated heap usage.

With this information, the idea is for an application at some interval (once per frame, per few seconds, etc) to query heapBudget and heapUsage. From here the application can notice if it is over budget and decide how it wants to handle the memory situation (free it, move to host memory, changing mipmap levels, etc). This extension is designed to be used in concert with VK_EXT_memory_priority to help with this part of memory management.

New Enum Constants

  • VK_EXT_MEMORY_BUDGET_EXTENSION_NAME

  • VK_EXT_MEMORY_BUDGET_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT

Version History

  • Revision 1, 2018-10-08 (Jeff Bolz)

    • Initial revision

VK_EXT_memory_priority

Name String

VK_EXT_memory_priority

Extension Type

Device extension

Registered Extension Number

239

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-10-08

Contributors
  • Jeff Bolz, NVIDIA

  • Jeff Juliano, NVIDIA

Description

This extension adds a priority value specified at memory allocation time. On some systems with both device-local and non-device-local memory heaps, the implementation may transparently move memory from one heap to another when a heap becomes full (for example, when the total memory used across all processes exceeds the size of the heap). In such a case, this priority value may be used to determine which allocations are more likely to remain in device-local memory.

New Enum Constants

  • VK_EXT_MEMORY_PRIORITY_EXTENSION_NAME

  • VK_EXT_MEMORY_PRIORITY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT

Version History

  • Revision 1, 2018-10-08 (Jeff Bolz)

    • Initial revision

VK_EXT_mesh_shader

Name String

VK_EXT_mesh_shader

Extension Type

Device extension

Registered Extension Number

329

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_mesh_shader

Other Extension Metadata

Last Modified Date

2022-01-20

Interactions and External Dependencies
Contributors
  • Christoph Kubisch, NVIDIA

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Piers Daniell, NVIDIA

  • Pierre Boudier, NVIDIA

  • Patrick Mours, NVIDIA

  • David Zhao Akeley, NVIDIA

  • Kedarnath Thangudu, NVIDIA

  • Timur Kristóf, Valve

  • Hans-Kristian Arntzen, Valve

  • Philip Rebohle, Valve

  • Mike Blumenkrantz, Valve

  • Slawomir Grajewski, Intel

  • Michal Pietrasiuk, Intel

  • Mariusz Merecki, Intel

  • Tom Olson, ARM

  • Jan-Harald Fredriksen, ARM

  • Sandeep Kakarlapudi, ARM

  • Ruihao Zhang, QUALCOMM

  • Ricardo Garcia, Igalia, S.L.

  • Tobias Hector, AMD

  • Stu Smith, AMD

Description

This extension provides a new mechanism allowing applications to generate collections of geometric primitives via programmable mesh shading. It is an alternative to the existing programmable primitive shading pipeline, which relied on generating input primitives by a fixed function assembler as well as fixed function vertex fetch.

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

New Enum Constants

  • VK_EXT_MESH_SHADER_EXTENSION_NAME

  • VK_EXT_MESH_SHADER_SPEC_VERSION

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_MESH_SHADER_BIT_EXT

    • VK_PIPELINE_STAGE_TASK_SHADER_BIT_EXT

  • Extending VkQueryPipelineStatisticFlagBits:

    • VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT

    • VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT

  • Extending VkQueryType:

    • VK_QUERY_TYPE_MESH_PRIMITIVES_GENERATED_EXT

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_MESH_BIT_EXT

    • VK_SHADER_STAGE_TASK_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_EXT

New or Modified Built-In Variables

  • CullPrimitiveEXT

  • PrimitivePointIndicesEXT

  • PrimitiveLineIndicesEXT

  • PrimitiveTriangleIndicesEXT

  • (modified)Position

  • (modified)PointSize

  • (modified)ClipDistance

  • (modified)CullDistance

  • (modified)PrimitiveId

  • (modified)Layer

  • (modified)ViewportIndex

  • (modified)NumWorkgroups

  • (modified)WorkgroupSize

  • (modified)WorkgroupId

  • (modified)LocalInvocationId

  • (modified)GlobalInvocationId

  • (modified)LocalInvocationIndex

  • (modified)NumSubgroups

  • (modified)SubgroupId

  • (modified)DrawIndex

  • (modified)PrimitiveShadingRateKHR

  • (modified)ViewIndex

New SPIR-V Capability

Version History

  • Revision 1, 2022-03-08 (Christoph Kubisch, Daniel Koch, Patrick Mours)

    • Initial revision

VK_EXT_metal_objects

Name String

VK_EXT_metal_objects

Extension Type

Device extension

Registered Extension Number

312

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_metal_objects

Other Extension Metadata

Last Modified Date

2022-05-28

IP Status

No known IP claims.

Contributors
  • Bill Hollings, The Brenwill Workshop Ltd.

  • Dzmitry Malyshau, Mozilla Corp.

Description

In a Vulkan implementation that is layered on top of Metal on Apple device platforms, this extension provides the ability to import and export the underlying Metal objects associated with specific Vulkan objects.

As detailed in the extension proposal document, this extension adds one new Vulkan command, vkExportMetalObjectsEXT, to export underlying Metal objects from Vulkan objects, and supports importing the appropriate existing Metal objects when creating Vulkan objects of types VkDeviceMemory, VkImage, VkSemaphore, and VkEvent,

The intent is that this extension will be advertised and supported only on implementations that are layered on top of Metal on Apple device platforms.

New Enum Constants

  • VK_EXT_METAL_OBJECTS_EXTENSION_NAME

  • VK_EXT_METAL_OBJECTS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_METAL_BUFFER_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_COMMAND_QUEUE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_DEVICE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_IO_SURFACE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECTS_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECT_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_SHARED_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_EXPORT_METAL_TEXTURE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_BUFFER_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_IO_SURFACE_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_SHARED_EVENT_INFO_EXT

    • VK_STRUCTURE_TYPE_IMPORT_METAL_TEXTURE_INFO_EXT

Issues

None.

Version History

  • Revision 1, 2022-05-28 (Bill Hollings)

    • Initial draft.

    • Incorporated feedback from review by the Vulkan Working Group. Renamed many structures, moved import/export of MTLBuffer to VkDeviceMemory, added export of MTLSharedEvent, added import of MTLSharedEvent for VkSemaphore and VkEvent, and changed used bit mask fields to individual bit fields to simplify Valid Usage rules.

VK_EXT_metal_surface

Name String

VK_EXT_metal_surface

Extension Type

Instance extension

Registered Extension Number

218

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-10-01

IP Status

No known IP claims.

Contributors
  • Dzmitry Malyshau, Mozilla Corp.

Description

The VK_EXT_metal_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) from CAMetalLayer, which is the native rendering surface of Apple’s Metal framework.

New Base Types

New Enum Constants

  • VK_EXT_METAL_SURFACE_EXTENSION_NAME

  • VK_EXT_METAL_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_METAL_SURFACE_CREATE_INFO_EXT

Version History

  • Revision 1, 2018-10-01 (Dzmitry Malyshau)

    • Initial version

VK_EXT_multi_draw

Name String

VK_EXT_multi_draw

Extension Type

Device extension

Registered Extension Number

393

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Mike Blumenkrantz zmike

Other Extension Metadata

Last Modified Date

2021-05-19

IP Status

No known IP claims.

Contributors
  • Mike Blumenkrantz, VALVE

  • Piers Daniell, NVIDIA

  • Faith Ekstrand, INTEL

  • Spencer Fricke, SAMSUNG

  • Ricardo Garcia, IGALIA

  • Jon Leech, KHRONOS

  • Stu Smith, AMD

Description

Processing multiple draw commands in sequence incurs measurable overhead within drivers due to repeated state checks and updates during dispatch. This extension enables passing the entire sequence of draws directly to the driver in order to avoid any such overhead, using an array of VkMultiDrawInfoEXT or VkMultiDrawIndexedInfoEXT structs with vkCmdDrawMultiEXT or vkCmdDrawMultiIndexedEXT, respectively. These functions could be used any time multiple draw commands are being recorded without any state changes between them in order to maximize performance.

New Enum Constants

  • VK_EXT_MULTI_DRAW_EXTENSION_NAME

  • VK_EXT_MULTI_DRAW_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_PROPERTIES_EXT

New or Modified Built-In Variables

  • (modified)DrawIndex

Version History

  • Revision 1, 2021-01-20 (Mike Blumenkrantz)

    • Initial version

VK_EXT_multisampled_render_to_single_sampled

Name String

VK_EXT_multisampled_render_to_single_sampled

Extension Type

Device extension

Registered Extension Number

377

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_multisampled_render_to_single_sampled

Other Extension Metadata

Last Modified Date

2021-04-16

IP Status

No known IP claims.

Contributors
  • Shahbaz Youssefi, Google

  • Jan-Harald Fredriksen, Arm

  • Jörg Wagner, Arm

  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Jarred Davies, Imagination Technologies

Description

With careful usage of resolve attachments, multisampled image memory allocated with VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT, loadOp not equal to VK_ATTACHMENT_LOAD_OP_LOAD and storeOp not equal to VK_ATTACHMENT_STORE_OP_STORE, a Vulkan application is able to efficiently perform multisampled rendering without incurring any additional memory penalty on some implementations.

Under certain circumstances however, the application may not be able to complete its multisampled rendering within a single render pass; for example if it does partial rasterization from frame to frame, blending on an image from a previous frame, or in emulation of GL_EXT_multisampled_render_to_texture. In such cases, the application can use an initial subpass to effectively load single-sampled data from the next subpass’s resolve attachment and fill in the multisampled attachment which otherwise uses loadOp equal to VK_ATTACHMENT_LOAD_OP_DONT_CARE. However, this is not always possible (for example for stencil in the absence of VK_EXT_shader_stencil_export) and has multiple drawbacks.

Some implementations are able to perform said operation efficiently in hardware, effectively loading a multisampled attachment from the contents of a single sampled one. Together with the ability to perform a resolve operation at the end of a subpass, these implementations are able to perform multisampled rendering on single-sampled attachments with no extra memory or bandwidth overhead. This extension exposes this capability by allowing a framebuffer and render pass to include single-sampled attachments while rendering is done with a specified number of samples.

New Enum Constants

  • VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME

  • VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_FEATURES_EXT

    • VK_STRUCTURE_TYPE_SUBPASS_RESOLVE_PERFORMANCE_QUERY_EXT

Issues

1) Could the multisampled attachment be initialized through some form of copy?

RESOLVED: No. Some implementations do not support copying between attachments in general, and find expressing this operation through a copy unnatural.

2) Another way to achieve this is by introducing a new loadOp to load the contents of the multisampled image from a single-sampled one. Why is this extension preferred?

RESOLVED: Using this extension simplifies the application, as it does not need to manage a secondary lazily-allocated image. Additionally, using this extension leaves less room for error; for example a single mistake in loadOp or storeOp would result in the lazily-allocated image to actually take up memory, and remain so until destruction.

3) There is no guarantee that multisampled data between two subpasses with the same number of samples will be retained as the implementation may be forced to split the render pass implicitly for various reasons. Should this extension require that every subpass that uses multisampled-render-to-single-sampled end in an implicit render pass split (which results in a resolve operation)?

RESOLVED: No. Not requiring this allows render passes with multiple multisampled-render-to-single-sampled subpasses to potentially execute more efficiently (though there is no guarantee).

Version History

  • Revision 1, 2021-04-12 (Shahbaz Youssefi)

VK_EXT_mutable_descriptor_type

Name String

VK_EXT_mutable_descriptor_type

Extension Type

Device extension

Registered Extension Number

495

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
Extension Proposal

VK_EXT_mutable_descriptor_type

Other Extension Metadata

Last Modified Date

2022-08-22

IP Status

No known IP claims.

Contributors
  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

Description

This extension allows applications to reduce descriptor memory footprint by allowing a descriptor to be able to mutate to a given list of descriptor types depending on which descriptor types are written into, or copied into a descriptor set.

The main use case this extension intends to address is descriptor indexing with VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT where the descriptor types are completely generic, as this means applications can allocate one large descriptor set, rather than having one large descriptor set per descriptor type, which significantly bloats descriptor memory usage and causes performance issues.

This extension also adds a mechanism to declare that a descriptor pool, and therefore the descriptor sets that are allocated from it, reside only in host memory; as such these descriptors can only be updated/copied, but not bound.

These features together allow much more efficient emulation of the raw D3D12 binding model. This extension is primarily intended to be useful for API layering efforts.

New Enum Constants

  • VK_EXT_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME

  • VK_EXT_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION

  • Extending VkDescriptorPoolCreateFlagBits:

    • VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_EXT

  • Extending VkDescriptorSetLayoutCreateFlagBits:

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_EXT

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_MUTABLE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_EXT

Version History

VK_EXT_non_seamless_cube_map

Name String

VK_EXT_non_seamless_cube_map

Extension Type

Device extension

Registered Extension Number

423

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Uses
Contact
Extension Proposal

VK_EXT_non_seamless_cube_map

Other Extension Metadata

Last Modified Date

2021-09-04

IP Status

No known IP claims.

Contributors
  • Georg Lehmann

Description

This extension provides functionality to disable cube map edge handling on a per sampler level which matches the behavior of other graphics APIs.

This extension may be useful for building translation layers for those APIs or for porting applications that rely on this cube map behavior.

New Enum Constants

  • VK_EXT_NON_SEAMLESS_CUBE_MAP_EXTENSION_NAME

  • VK_EXT_NON_SEAMLESS_CUBE_MAP_SPEC_VERSION

  • Extending VkSamplerCreateFlagBits:

    • VK_SAMPLER_CREATE_NON_SEAMLESS_CUBE_MAP_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NON_SEAMLESS_CUBE_MAP_FEATURES_EXT

Version History

  • Revision 1, 2021-09-04 (Georg Lehmann)

    • First Version

VK_EXT_opacity_micromap

Name String

VK_EXT_opacity_micromap

Extension Type

Device extension

Registered Extension Number

397

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_opacity_micromap

Other Extension Metadata

Last Modified Date

2022-08-24

Interactions and External Dependencies
Contributors
  • Christoph Kubisch, NVIDIA

  • Eric Werness, NVIDIA

  • Josh Barczak, Intel

  • Stu Smith, AMD

Description

When adding adding transparency to a ray traced scene, an application can choose between further tessellating the geometry or using an any hit shader to allow the ray through specific parts of the geometry. These options have the downside of either significantly increasing memory consumption or adding runtime overhead to run shader code in the middle of traversal, respectively.

This extension adds the ability to add an opacity micromap to geometry when building an acceleration structure. The opacity micromap compactly encodes opacity information which can be read by the implementation to mark parts of triangles as opaque or transparent. The format is externally visible to allow the application to compress its internal geometry and surface representations into the compressed format ahead of time. The compressed format subdivides each triangle into a set of subtriangles, each of which can be assigned either two or four opacity values. These opacity values can control if a ray hitting that subtriangle is treated as an opaque hit, complete miss, or possible hit, depending on the controls described in Ray Opacity Micromap.

This extension provides:

New Object Types

New Enum Constants

  • VK_EXT_OPACITY_MICROMAP_EXTENSION_NAME

  • VK_EXT_OPACITY_MICROMAP_SPEC_VERSION

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_MICROMAP_READ_BIT_EXT

    • VK_ACCESS_2_MICROMAP_WRITE_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_MICROMAP_BUILD_INPUT_READ_ONLY_BIT_EXT

    • VK_BUFFER_USAGE_MICROMAP_STORAGE_BIT_EXT

  • Extending VkBuildAccelerationStructureFlagBitsKHR:

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_DATA_UPDATE_EXT

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_OPACITY_MICROMAP_UPDATE_EXT

  • Extending VkGeometryInstanceFlagBitsKHR:

    • VK_GEOMETRY_INSTANCE_DISABLE_OPACITY_MICROMAPS_EXT

    • VK_GEOMETRY_INSTANCE_FORCE_OPACITY_MICROMAP_2_STATE_EXT

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_MICROMAP_EXT

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RAY_TRACING_OPACITY_MICROMAP_BIT_EXT

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_MICROMAP_BUILD_BIT_EXT

  • Extending VkQueryType:

    • VK_QUERY_TYPE_MICROMAP_COMPACTED_SIZE_EXT

    • VK_QUERY_TYPE_MICROMAP_SERIALIZATION_SIZE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_TRIANGLES_OPACITY_MICROMAP_EXT

    • VK_STRUCTURE_TYPE_COPY_MEMORY_TO_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_INFO_EXT

    • VK_STRUCTURE_TYPE_COPY_MICROMAP_TO_MEMORY_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_BUILD_SIZES_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_MICROMAP_VERSION_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPACITY_MICROMAP_PROPERTIES_EXT

Reference Code

uint32_t BarycentricsToSpaceFillingCurveIndex(float u, float v, uint32_t level)
{
    u = clamp(u, 0.0f, 1.0f);
    v = clamp(v, 0.0f, 1.0f);

    uint32_t iu, iv, iw;

    // Quantize barycentric coordinates
    float fu = u * (1u << level);
    float fv = v * (1u << level);

    iu = (uint32_t)fu;
    iv = (uint32_t)fv;

    float uf = fu - float(iu);
    float vf = fv - float(iv);

    if (iu >= (1u << level)) iu = (1u << level) - 1u;
    if (iv >= (1u << level)) iv = (1u << level) - 1u;

    uint32_t iuv = iu + iv;

    if (iuv >= (1u << level))
        iu -= iuv - (1u << level) + 1u;

    iw = ~(iu + iv);

    if (uf + vf >= 1.0f && iuv < (1u << level) - 1u) --iw;

    uint32_t b0 = ~(iu ^ iw);
    b0 &= ((1u << level) - 1u);
    uint32_t t = (iu ^ iv) & b0;

    uint32_t f = t;
    f ^= f >> 1u;
    f ^= f >> 2u;
    f ^= f >> 4u;
    f ^= f >> 8u;
    uint32_t b1 = ((f ^ iu) & ~b0) | t;

    // Interleave bits
    b0 = (b0 | (b0 << 8u)) & 0x00ff00ffu;
    b0 = (b0 | (b0 << 4u)) & 0x0f0f0f0fu;
    b0 = (b0 | (b0 << 2u)) & 0x33333333u;
    b0 = (b0 | (b0 << 1u)) & 0x55555555u;
    b1 = (b1 | (b1 << 8u)) & 0x00ff00ffu;
    b1 = (b1 | (b1 << 4u)) & 0x0f0f0f0fu;
    b1 = (b1 | (b1 << 2u)) & 0x33333333u;
    b1 = (b1 | (b1 << 1u)) & 0x55555555u;

    return b0 | (b1 << 1u);
}

Issues

(1) Is the build actually similar to an acceleration structure build?

  • Resolved: The build should be much lighter-weight than an acceleration structure build, but the infrastructure is similar enough that it makes sense to keep the concepts compatible.

(2) Why does VkMicromapUsageEXT not have type/pNext?

  • Resolved: There can be a very large number of these structures, so doubling the size of these can be significant memory consumption. Also, an application may be loading these directly from a file which is more compatible with it being a flat structure. The including structures are extensible and are probably a more suitable place to add extensibility.

(3) Why is there a SPIR-V extension?

  • Resolved: There is a ray flag. To be consistent with how the existing ray tracing extensions work that ray flag needs its own extension.

(4) Should there be indirect micromap build?

  • Resolved: Not for now. There is more in-depth usage metadata required and it seems less likely that something like a GPU culling system would need to change the counts for a micromap.

(5) Should micromaps have a micromap device address?

  • Resolved: There is no need right now (can just use the handle) but that is a bit different from acceleration structures, though the two are not completely parallel in their usage.

(6) Why are the alignment requirements defined as a mix of hardcoded values and caps?

  • Resolved: This is most parallel with the definition of VK_KHR_acceleration_structure and maintaining commonality makes it easier for applications to share memory.

Version History

  • Revision 2, 2022-06-22 (Eric Werness)

    • EXTify and clean up for discussion

  • Revision 1, 2022-01-01 (Eric Werness)

    • Initial revision

VK_EXT_pageable_device_local_memory

Name String

VK_EXT_pageable_device_local_memory

Extension Type

Device extension

Registered Extension Number

413

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-08-24

Contributors
  • Hans-Kristian Arntzen, Valve

  • Axel Gneiting, id Software

  • Billy Khan, id Software

  • Daniel Koch, NVIDIA

  • Chris Lentini, NVIDIA

  • Joshua Schnarr, NVIDIA

  • Stu Smith, AMD

Description

Vulkan is frequently implemented on multi-user and multi-process operating systems where the device-local memory can be shared by more than one process. On such systems the size of the device-local memory available to the application may not be the full size of the memory heap at all times. In order for these operating systems to support multiple applications the device-local memory is virtualized and paging is used to move memory between device-local and host-local memory heaps, transparent to the application.

The current Vulkan specification does not expose this behavior well and may cause applications to make suboptimal memory choices when allocating memory. For example, in a system with multiple applications running, the application may think that device-local memory is full and revert to making performance-sensitive allocations from host-local memory. In reality the memory heap might not have been full, it just appeared to be at the time memory consumption was queried, and a device-local allocation would have succeeded. A well designed operating system that implements pageable device-local memory will try to have all memory allocations for the foreground application paged into device-local memory, and paged out for other applications as needed when not in use.

When this extension is exposed by the Vulkan implementation it indicates to the application that the operating system implements pageable device-local memory and the application should adjust its memory allocation strategy accordingly. The extension also exposes a new vkSetDeviceMemoryPriorityEXT function to allow the application to dynamically adjust the priority of existing memory allocations based on its current needs. This will help the operating system page out lower priority memory allocations before higher priority allocations when needed. It will also help the operating system decide which memory allocations to page back into device-local memory first.

To take best advantage of pageable device-local memory the application must create the Vulkan device with the VkPhysicalDevicePageableDeviceLocalMemoryFeaturesEXT::pageableDeviceLocalMemory feature enabled. When enabled the Vulkan implementation will allow device-local memory allocations to be paged in and out by the operating system, and may not return VK_ERROR_OUT_OF_DEVICE_MEMORY even if device-local memory appears to be full, but will instead page this, or other allocations, out to make room. The Vulkan implementation will also ensure that host-local memory allocations will never be promoted to device-local memory by the operating system, or consume device-local memory.

New Enum Constants

  • VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_EXTENSION_NAME

  • VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PAGEABLE_DEVICE_LOCAL_MEMORY_FEATURES_EXT

Version History

  • Revision 1, 2021-08-24 (Piers Daniell)

    • Initial revision

VK_EXT_pci_bus_info

Name String

VK_EXT_pci_bus_info

Extension Type

Device extension

Registered Extension Number

213

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-12-10

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Daniel Rakos, AMD

Description

This extension adds a new query to obtain PCI bus information about a physical device.

Not all physical devices have PCI bus information, either due to the device not being connected to the system through a PCI interface or due to platform specific restrictions and policies. Thus this extension is only expected to be supported by physical devices which can provide the information.

As a consequence, applications should always check for the presence of the extension string for each individual physical device for which they intend to issue the new query for and should not have any assumptions about the availability of the extension on any given platform.

New Enum Constants

  • VK_EXT_PCI_BUS_INFO_EXTENSION_NAME

  • VK_EXT_PCI_BUS_INFO_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT

Version History

  • Revision 2, 2018-12-10 (Daniel Rakos)

    • Changed all members of the new structure to have the uint32_t type

  • Revision 1, 2018-10-11 (Daniel Rakos)

    • Initial revision

VK_EXT_physical_device_drm

Name String

VK_EXT_physical_device_drm

Extension Type

Device extension

Registered Extension Number

354

Revision

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 Ser

Description

This extension provides new facilities to query DRM properties for physical devices, enabling users to match Vulkan physical devices with DRM nodes on Linux.

Its functionality closely overlaps with EGL_EXT_device_drm1. Unlike the EGL extension, this extension does not expose a string containing the name of the device file and instead exposes device minor numbers.

DRM defines multiple device node types. Each physical device may have one primary node and one render node associated. Physical devices may have no primary node (e.g. if the device does not have a display subsystem), may have no render node (e.g. if it is a software rendering engine), or may have neither (e.g. if it is a software rendering engine without a display subsystem).

To query DRM properties for a physical device, chain VkPhysicalDeviceDrmPropertiesEXT to VkPhysicalDeviceProperties2.

New Enum Constants

  • VK_EXT_PHYSICAL_DEVICE_DRM_EXTENSION_NAME

  • VK_EXT_PHYSICAL_DEVICE_DRM_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRM_PROPERTIES_EXT

References

Version History

  • Revision 1, 2021-06-09

    • First stable revision

VK_EXT_pipeline_library_group_handles

Name String

VK_EXT_pipeline_library_group_handles

Extension Type

Device extension

Registered Extension Number

499

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_pipeline_library_group_handles

Other Extension Metadata

Last Modified Date

2023-01-25

IP Status

No known IP claims.

Contributors
  • Hans-Kristian Arntzen, Valve

  • Stuart Smith, AMD

  • Ricardo Garcia, Igalia

  • Lionel Landwerlin, Intel

  • Eric Werness, NVIDIA

  • Daniel Koch, NVIDIA

Description

When using pipeline libraries in ray tracing pipelines, a library might get linked into different pipelines in an incremental way. An application can have a strategy where a ray tracing pipeline is comprised of N pipeline libraries and is later augumented by creating a new pipeline with N + 1 libraries. Without this extension, all group handles must be re-queried as the group handle is tied to the pipeline, not the library. This is problematic for applications which aim to decouple construction of record buffers and the linkage of ray tracing pipelines.

To aid in this, this extension enables support for querying group handles directly from pipeline libraries. Group handles obtained from a library must remain bitwise identical in any VkPipeline that links to the library.

With this feature, the extension also improves compatibility with DXR 1.1 AddToStateObject(), which guarantees that group handles returned remain bitwise identical between parent and child pipelines. In addition, querying group handles from COLLECTION objects is also supported with that API.

New Enum Constants

  • VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_EXTENSION_NAME

  • VK_EXT_PIPELINE_LIBRARY_GROUP_HANDLES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_LIBRARY_GROUP_HANDLES_FEATURES_EXT

Version History

  • Revision 1, 2023-01-25 (Hans-Kristian Arntzen)

    • Initial draft

VK_EXT_pipeline_properties

Name String

VK_EXT_pipeline_properties

Extension Type

Device extension

Registered Extension Number

373

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-04-19

IP Status

No known IP claims.

Contributors
  • Mukund Keshava, NVIDIA

  • Daniel Koch, NVIDIA

  • Mark Bellamy, Arm

Description

Vulkan SC requires offline compilation of pipelines. In order to support this, the pipeline state is represented in a JSON schema that is read by an offline tool for compilation.

One method of developing a Vulkan SC application is to author a Vulkan application and use a layer to record and serialize the pipeline state and shaders for offline compilation. Each pipeline is represented by a separate JSON file, and can be identified with a pipelineIdentifier.

Once the pipelines have been compiled by the offline pipeline cache compiler, the Vulkan SC application can then use this pipelineIdentifier for identifying the pipeline via Vulkan SC’s VkPipelineIdentifierInfo structure.

This extension allows the Vulkan application to query the pipelineIdentifier associated with each pipeline so that the application can store this with its pipeline metadata and the Vulkan SC application will then use to map the same state to an entry in the Vulkan SC pipeline cache.

It is expected that this extension will initially be implemented in the json generation layer, although we can envision that there might be future uses for it in native Vulkan drivers as well.

New Enum Constants

  • VK_EXT_PIPELINE_PROPERTIES_EXTENSION_NAME

  • VK_EXT_PIPELINE_PROPERTIES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROPERTIES_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_INFO_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_PROPERTIES_IDENTIFIER_EXT

Issues

(1) This extension does not make sense on a strict Vulkan SC implementation. It may however be of potential use in a non-strict Vulkan SC implementation. Should this extension be enabled as part of Vulkan SC as well?

RESOLVED: No. This extension will not be enabled for Vulkan SC.

(2) This is intended to be a general pipeline properties query, but is currently only retrieving the pipeline identifier. Should the pipeline identifier query be mandatory for this extension and for all queries using this entry point?

RESOLVED: Use VkBaseOutStructure for the return parameter. Currently this is required to actually be a VkPipelinePropertiesIdentifierEXT structure, but that could be relaxed in the future to allow other structure types or to allow other structures to be chained in along with this one.

(3) Should there be a feature structure? Should it be required?

RESOLVED: Add a feature structure, and a feature for querying pipeline identifier, but allow it to be optional so that this extension can be used as the basis for other pipeline property queries without requiring the pipeline identifier to be supported.

Version History

  • Revision 1, 2022-04-19 (Mukund Keshava, Daniel Koch)

    • Initial draft

VK_EXT_pipeline_protected_access

Name String

VK_EXT_pipeline_protected_access

Extension Type

Device extension

Registered Extension Number

467

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_pipeline_protected_access

Other Extension Metadata

Last Modified Date

2022-07-28

Contributors
  • Shahbaz Youssefi, Google

  • Jörg Wagner, Arm

  • Ralph Potter, Samsung

  • Daniel Koch, NVIDIA

Description

This extension allows protected memory access to be specified per pipeline as opposed to per device. Through the usage of this extension, any performance penalty paid due to access to protected memory will be limited to the specific pipelines that make such accesses.

New Enum Constants

  • VK_EXT_PIPELINE_PROTECTED_ACCESS_EXTENSION_NAME

  • VK_EXT_PIPELINE_PROTECTED_ACCESS_SPEC_VERSION

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_NO_PROTECTED_ACCESS_BIT_EXT

    • VK_PIPELINE_CREATE_PROTECTED_ACCESS_ONLY_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROTECTED_ACCESS_FEATURES_EXT

Version History

  • Revision 1, 2022-07-28 (Shahbaz Youssefi)

    • Internal revisions

VK_EXT_pipeline_robustness

Name String

VK_EXT_pipeline_robustness

Extension Type

Device extension

Registered Extension Number

69

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Jarred Davies

Other Extension Metadata

Last Modified Date

2022-07-12

Interactions and External Dependencies
Contributors
  • Jarred Davies, Imagination Technologies

  • Alex Walters, Imagination Technologies

  • Piers Daniell, NVIDIA

  • Graeme Leese, Broadcom Corporation

  • Jeff Leger, Qualcomm Technologies, Inc.

  • Faith Ekstrand, Intel

  • Lionel Landwerlin, Intel

  • Shahbaz Youssefi, Google, Inc.

Description

This extension allows users to request robustness on a per-pipeline stage basis.

As robustBufferAccess and other robustness features may have an adverse effect on performance, this extension is designed to allow users to request robust behavior only where it may be needed.

New Enum Constants

  • VK_EXT_PIPELINE_ROBUSTNESS_EXTENSION_NAME

  • VK_EXT_PIPELINE_ROBUSTNESS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_ROBUSTNESS_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_ROBUSTNESS_CREATE_INFO_EXT

Version History

  • Revision 1, 2022-07-12 (Jarred Davies)

    • Initial version

VK_EXT_post_depth_coverage

Name String

VK_EXT_post_depth_coverage

Extension Type

Device extension

Registered Extension Number

156

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-07-17

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

Description

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

  • SPV_KHR_post_depth_coverage

which allows the fragment shader to control whether values in the SampleMask built-in input variable reflect the coverage after early depth and stencil tests are applied.

This extension adds a new PostDepthCoverage execution mode under the SampleMaskPostDepthCoverage capability. When this mode is specified along with EarlyFragmentTests, the value of an input variable decorated with the SampleMask built-in reflects the coverage after the early fragment tests are applied. Otherwise, it reflects the coverage before the depth and stencil tests.

When using GLSL source-based shading languages, the post_depth_coverage layout qualifier from GL_ARB_post_depth_coverage or GL_EXT_post_depth_coverage maps to the PostDepthCoverage execution mode.

New Enum Constants

  • VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME

  • VK_EXT_POST_DEPTH_COVERAGE_SPEC_VERSION

New SPIR-V Capabilities

Version History

  • Revision 1, 2017-07-17 (Daniel Koch)

    • Internal revisions

VK_EXT_present_timing

Name String

VK_EXT_present_timing

Extension Type

Device extension

Registered Extension Number

209

Revision

4

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2023-03-07

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Daniel Rakos, AMD

  • Daniel Stone, Collabora

  • Daniel Vetter, Intel

  • Aric Cyr, AMD

  • Faith Ekstrand, Intel

  • Nicolai Hähnle, AMD

  • Alon Or-Bach, Samsung

  • Niklas Smedberg, Unity Technologies

  • Tobias Hector, AMD

  • Lionel Duc, NVIDIA

  • Lina Versace, Google

  • Sebastian Wick, Red Hat

  • Jakob Bornecrantz, Collabora

Description

This device extension allows an application that uses the VK_KHR_swapchain extension to obtain information about the presentation engine’s display, to obtain timing information about each present, and to schedule a present to happen no earlier than a desired time. An application can use this to minimize various visual anomalies (e.g. stuttering).

Traditional game and real-time animation applications need to correctly position their geometry for when the presentable image will be presented to the user. To accomplish this, applications need various timing information about the presentation engine’s display. They need to know when presentable images were actually presented, and when they could have been presented. Applications also need to tell the presentation engine to display an image no sooner than a given time. This allows the application to avoid stuttering, so the animation looks smooth to the user.

New Unions

New Bitmasks

New Enum Constants

  • VK_EXT_PRESENT_TIMING_EXTENSION_NAME

  • VK_EXT_PRESENT_TIMING_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_PRESENT_TIMING_QUEUE_FULL_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PAST_PRESENTATION_TIMING_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_TIMING_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_EXT

    • VK_STRUCTURE_TYPE_PRESENT_TIMING_SURFACE_CAPABILITIES_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_CALIBRATED_TIMESTAMP_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_TIMING_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_TIME_DOMAIN_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_TIMING_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_TIMING_PROPERTIES_EXT

  • Extending VkTimeDomainEXT:

    • VK_TIME_DOMAIN_SWAPCHAIN_LOCAL_EXT

Issues

1) How does the application determine refresh duration, quanta for change, whether FRR vs. VRR, etc.

PROPOSED: the query returns two values: 1) a refresh-cycle duration (refreshDuration), and 2) an indication whether the timing is currently fixed (FRR) or variable (VRR). If refreshDuration is zero, the platform cannot supply these values until after at least one vkQueuePresentKHR has been done, from this time (e.g. if vkQueuePresentKHR has been previously called for this swapchain, at least one additional call must be made). After calling vkQueuePresentKHR, the query can be repeated until refreshDuration is non-zero, at which point the FRR vs. VRR indication will also be valid.

If the presentation engine’s refreshDuration is a fixed value, the application’s image present duration (IPD) should be a multiple of refreshDuration. That is, the quanta for changing the IPD is refreshDuration. For example, if refreshDuration is 16.67ms, the IPD can be 16.67ms, 33.33ms, 50.0ms, etc.

If the presentation engine’s refreshDuration is variable, refreshDuration is the minimum value of the application’s IPD, and the IPD can be larger by any quanta that is meaningful to the application. For example, if the refreshDuration is 10ms (i.e. the maximum refresh rate is 100Hz), the application can choose an IPD of 11ms, 13.33ms, 13.5ms, or 66.0ms; any value greater than or equal to 10ms is valid. There may be negative consequences for choosing an IPD that is too high, as the presentation engine may actually have a practical maximum refreshDuration, where it needs to display the previous image again, and during this time the presentation engine might delay displaying a newly-presented image.

FRR displays on at least one platform (Wayland) are not necessarily fixed; but can change over time. For example, if a full-screen video player application is visible, the display may operate at a 24Hz refresh cycle; and then later switch to 60Hz when multiple windows are visible.

VRR displays on some platforms can also be seen as having different characteristics over time. For example, if an application’s window is full-screen-exclusive (i.e. no other window or window system component is visible), the display can look like a VRR display (however that is defined). If the application’s window is not full-screen-exclusive (e.g. a normal multi-window case), the display can look like an FRR display (i.e. because the compositor is trying to treat all windows in a consistent manner). A different issue will deal with how the timing characteristics can change over time.

2) Do we return min/max values for refresh duration for VRR?

PROPOSED: return only the minimum value of refreshDuration for a VRR.

VRR displays have a minimum and maximum refresh rate, and therefore a minimum and maximum refreshDuration. It has been asserted that the display effectively does not have a minimum refresh rate. That is because if an application does not present soon enough, the display hardware will automatically re-display the previous image. However, when the display does that, an application cannot present a new image for a certain period of time. It is unclear about whether that period is large enough to cause visual artifacts.

3) How to deal with changes in timing properties?

RESOLVED: The VkPastPresentationTimingEXT structure that is returned by vkGetPastPresentationTimingEXT will contain timeDomainChanged, which will be VK_TRUE if the time domain enabled for the swapchain is not currently available.

An example of why display timing properties can change is if a surface changes from being a window that’s a subset of the display size, to becoming full-screen-exclusive. While the surface was a subset of the display, a compositor might enforce fixed timings on the surface (e.g. FRR of 60Hz), where the presentation engine might be free to allow VRR behavior of a full-screen-exclusive surface.

It is possible that a full-screen-exclusive window can become temporarily obscured (e.g. when a short-term dialog pops up). In this case, the surface might use FRR timings while the dialog is visible and VRR otherwise.

4) One Query for all Timing info vs. an initial query to determine FRR vs. VRR, and then FRR-specific vs VRR-specific queries?

RESOLVED: Have one query, as described in issue 1, that can be called whenever the application needs to obtain the timing properties of the surface.

5) Query to determine time domain?

RESOLVED: Have a query to determine the time domain. This extension defines a basic swapchain-local time domain. Other extensions can add other platform-specific time domains.

6) What time to use for targetPresentTime for early images?

PROPOSED: Have no query for determining the current time in the PE’s time domain; and do allow the special value of zero for targetPresentTime, meaning that there is no target.

On some platforms, there is no way to determine the current time, nor to determine surface timing properties until after at least one image has been presented.

In such cases, the special value of zero allows the application to indicate that timing feedback is desired, but that no targetPresentTime is requested. Later, once the application has obtained feedback, it can specify targetPresentTime by using the results actualPresentTime.

7) How long before an application’s request for new image duration is honored?

UNRESOLVED: Apparently, changes to some vendors' display hardware settings do not take effect immediately. It is not clear what settings, and therefore, it is not clear how to address this issue.

8) Do we have a query for the anticipated latency from present to feedback?

UNRESOLVED: There is some amount of latency from when an application calls vkQueuePresentKHR to when the image is displayed to the user, to when feedback is available to the application on when the image was actually displayed to the user. The first time (from the call till the image is presented) generally doesn’t matter, because the application will likely be providing a targetPresentTime (i.e. the application may have some indication for how long this will be). However, the latency between targetPresentTime until feedback is available may be much longer. For example, on Android on the 1st-generation Pixel phone (60Hz FRR display), the latency was approximately 5 refresh cycles (83.33ms). For higher-frequency displays, the latency may have a larger number of refresh cycles.

Is there value in having a query for the application to know how long it may have to wait for feedback? Can such a query be reasonably answered by the driver? Is there other interesting information in this space that we may wish to capture?

9) Do we have a query(s) about the number of VkPastPresentationTimingEXT structs to keep?

PROPOSED: Let the application specify at swapchain creation how many results the swapchain is allowed to store before querying them with vkGetPastPresentationTimingEXT.

10) How is the SWAPCHAIN_LOCAL time domain used with the calibrated timestamps extension?

PROPOSED: Define a struct to chain into VkCalibratedTimestampInfoEXT::pNext that specifies a swapchain. Is anything additional needed for vkGetPhysicalDeviceCalibrateableTimeDomainsEXT, or are swapchain-local timestamps always calibrateable or always not calibrateable for a given device?

11) Should VK_PRESENT_MODE_FIFO_LATEST_READY_EXT be part of this extension, or split out into its own extension?

RESOLVED: It is only tangentially related. Split it out into its own extension and define the interaction here.

Version History

  • Revision 1, 2018-05-11 (Ian Elliott)

    • Internal revisions.

  • Revision 2, 2022-11-30 (Lionel Duc)

    • Major rebase.

    • Add physical device feature flags.

    • Rely on VK_KHR_present_id for present ids.

    • Resolve issue (11): remove VK_PRESENT_MODE_FIFO_LATEST_READY_EXT.

    • Add per-surface capabilities.

  • Revision 3, 2023-01-31 (Lionel Duc)

    • Propose resolution to issue (9): let the application provide the queue size for the pending results.

  • Revision 4, 2023-05-03 (Lionel Duc)

    • Change target and feedback times to be associated with a well-defined present stage.

VK_EXT_primitive_topology_list_restart

Name String

VK_EXT_primitive_topology_list_restart

Extension Type

Device extension

Registered Extension Number

357

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2021-01-11

IP Status

No known IP claims.

Contributors
  • Courtney Goeltzenleuchter, Google

  • Shahbaz Youssefi, Google

Description

This extension allows list primitives to use the primitive restart index value. This provides a more efficient implementation when layering OpenGL functionality on Vulkan by avoiding emulation which incurs data copies.

New Enum Constants

  • VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_EXTENSION_NAME

  • VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVE_TOPOLOGY_LIST_RESTART_FEATURES_EXT

Version History

  • Revision 0, 2020-09-14 (Courtney Goeltzenleuchter)

    • Internal revisions

  • Revision 1, 2021-01-11 (Shahbaz Youssefi)

    • Add the primitiveTopologyPatchListRestart feature

    • Internal revisions

VK_EXT_primitives_generated_query

Name String

VK_EXT_primitives_generated_query

Extension Type

Device extension

Registered Extension Number

383

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
Extension Proposal

VK_EXT_primitives_generated_query

Other Extension Metadata

Last Modified Date

2022-01-24

Contributors
  • Shahbaz Youssefi, Google

  • Piers Daniell, NVIDIA

  • Faith Ekstrand, Collabora

  • Jan-Harald Fredriksen, Arm

Description

This extension adds support for a new query type to match OpenGL’s GL_PRIMITIVES_GENERATED to support layering.

New Enum Constants

  • VK_EXT_PRIMITIVES_GENERATED_QUERY_EXTENSION_NAME

  • VK_EXT_PRIMITIVES_GENERATED_QUERY_SPEC_VERSION

  • Extending VkQueryType:

    • VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVES_GENERATED_QUERY_FEATURES_EXT

Issues

1) Can the query from VK_EXT_transform_feedback be used instead?

RESOLVED: No. While the query from VK_EXT_transform_feedback can produce the same results as in this extension, it is only available while transform feedback is active. The OpenGL GL_PRIMITIVES_GENERATED query is independent from transform feedback. Emulation through artificial transform feedback is unnecessarily inefficient.

2) Can VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT be used instead?

RESOLVED: It could, but we prefer the extension for simplicity. Vulkan requires that only one query be active at a time. If both the GL_PRIMITIVES_GENERATED and the GL_CLIPPING_INPUT_PRIMITIVES_ARB queries need to be simultaneously enabled, emulation of both through VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT is inconvenient.

3) On some hardware, this query cannot be implemented if VkPipelineRasterizationStateCreateInfo::rasterizerDiscardEnable is enabled. How will this be handled?

RESOLVED: A feature flag is exposed by this extension for this. On said hardware, the GL implementation disables rasterizer-discard and achieves the same effect through other means. It will not be able to do the same in Vulkan due to lack of state information. A feature flag is exposed by this extension so the OpenGL implementation on top of Vulkan would be able to implement a similar workaround.

4) On some hardware, this query cannot be implemented for non-zero query indices. How will this be handled?

RESOLVED: A feature flag is exposed by this extension for this. If this feature is not present, the query from VK_EXT_transform_feedback can be used to the same effect.

5) How is the interaction of this extension with transformFeedbackRasterizationStreamSelect handled?

RESOLVED: Disallowed for non-zero streams. In OpenGL, the rasterization stream is always stream zero.

Version History

  • Revision 1, 2021-06-23 (Shahbaz Youssefi)

    • Internal revisions

VK_EXT_provoking_vertex

Name String

VK_EXT_provoking_vertex

Extension Type

Device extension

Registered Extension Number

255

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2021-02-22

IP Status

No known IP claims.

Contributors
  • Alexis Hétu, Google

  • Bill Licea-Kane, Qualcomm

  • Daniel Koch, Nvidia

  • Jamie Madill, Google

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, Nvidia

  • Jeff Leger, Qualcomm

  • Jesse Hall, Google

  • Jörg Wagner, Arm

  • Matthew Netsch, Qualcomm

  • Mike Blumenkrantz, Valve

  • Piers Daniell, Nvidia

  • Tobias Hector, AMD

Description

This extension allows changing the provoking vertex convention between Vulkan’s default convention (first vertex) and OpenGL’s convention (last vertex).

This extension is intended for use by API-translation layers that implement APIs like OpenGL on top of Vulkan, and need to match the source API’s provoking vertex convention. Applications using Vulkan directly should use Vulkan’s default convention.

New Enum Constants

  • VK_EXT_PROVOKING_VERTEX_EXTENSION_NAME

  • VK_EXT_PROVOKING_VERTEX_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_PROVOKING_VERTEX_STATE_CREATE_INFO_EXT

Issues

1) At what granularity should this state be set?

RESOLVED: At pipeline bind, with an optional per-render pass restriction.

The most natural place to put this state is in the graphics pipeline object. Some implementations require it to be known when creating the pipeline, and pipeline state is convenient for implementing OpenGL 3.2’s glProvokingVertex, which can change the state between draw calls. However, some implementations can only change it approximately render pass granularity. To accommodate both, provoking vertex will be pipeline state, but implementations can require that only one mode is used within a render pass instance; the render pass’s mode is chosen implicitly when the first pipeline is bound.

2) Does the provoking vertex mode affect the order that vertices are written to transform feedback buffers?

RESOLVED: Yes, to enable layered implementations of OpenGL and D3D.

All of OpenGL, OpenGL ES, and Direct3D 11 require that vertices are written to transform feedback buffers such that flat-shaded attributes have the same value when drawing the contents of the transform feedback buffer as they did in the original drawing when the transform feedback buffer was written (assuming the provoking vertex mode has not changed, in APIs that support more than one mode).

Version History

  • Revision 1, (1c) 2021-02-22 (Jesse Hall)

    • Added VkPhysicalDeviceProvokingVertexPropertiesEXT::transformFeedbackPreservesTriangleFanProvokingVertex to accommodate implementations that cannot change the transform feedback vertex order for triangle fans.

  • Revision 1, (1b) 2020-06-14 (Jesse Hall)

    • Added VkPhysicalDeviceProvokingVertexFeaturesEXT::transformFeedbackPreservesProvokingVertex and required that transform feedback write vertices so as to preserve the provoking vertex of each primitive.

  • Revision 1, (1a) 2019-10-23 (Jesse Hall)

    • Initial draft, based on a proposal by Alexis Hétu

VK_EXT_queue_family_foreign

Name String

VK_EXT_queue_family_foreign

Extension Type

Device extension

Registered Extension Number

127

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-11-01

IP Status

No known IP claims.

Contributors
  • Lina Versace, Google

  • James Jones, NVIDIA

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • Daniel Rakos, AMD

  • Ray Smith, ARM

Description

This extension defines a special queue family, VK_QUEUE_FAMILY_FOREIGN_EXT, which can be used to transfer ownership of resources backed by external memory to foreign, external queues. This is similar to VK_QUEUE_FAMILY_EXTERNAL_KHR, defined in VK_KHR_external_memory. The key differences between the two are:

  • The queues represented by VK_QUEUE_FAMILY_EXTERNAL_KHR must share the same physical device and the same driver version as the current VkInstance. VK_QUEUE_FAMILY_FOREIGN_EXT has no such restrictions. It can represent devices and drivers from other vendors, and can even represent non-Vulkan-capable devices.

  • All resources backed by external memory support VK_QUEUE_FAMILY_EXTERNAL_KHR. Support for VK_QUEUE_FAMILY_FOREIGN_EXT is more restrictive.

  • Applications should expect transitions to/from VK_QUEUE_FAMILY_FOREIGN_EXT to be more expensive than transitions to/from VK_QUEUE_FAMILY_EXTERNAL_KHR.

New Enum Constants

  • VK_EXT_QUEUE_FAMILY_FOREIGN_EXTENSION_NAME

  • VK_EXT_QUEUE_FAMILY_FOREIGN_SPEC_VERSION

  • VK_QUEUE_FAMILY_FOREIGN_EXT

Version History

  • Revision 1, 2017-11-01 (Lina Versace)

    • Squashed internal revisions

VK_EXT_rasterization_order_attachment_access

Name String

VK_EXT_rasterization_order_attachment_access

Extension Type

Device extension

Registered Extension Number

464

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_rasterization_order_attachment_access

Other Extension Metadata

Last Modified Date

2022-07-04

IP Status

No known IP claims.

Contributors
  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, Arm

Description

This extension extends the mechanism of input attachments to allow access to framebuffer attachments that are used both as input and as color or depth/stencil attachments from one fragment to the next, in rasterization order, without explicit synchronization.

New Enum Constants

  • VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME

  • VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION

  • Extending VkPipelineColorBlendStateCreateFlagBits:

    • VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT

  • Extending VkPipelineDepthStencilStateCreateFlagBits:

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_EXT

  • Extending VkSubpassDescriptionFlagBits:

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_EXT

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT

Examples

None.

Version History

  • Revision 1, 2022-07-04 (Jan-Harald Fredriksen)

    • Initial draft

VK_EXT_rgba10x6_formats

Name String

VK_EXT_rgba10x6_formats

Extension Type

Device extension

Registered Extension Number

345

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-09-29

IP Status

No known IP claims.

Contributors
  • Jan-Harald Fredriksen, Arm

  • Graeme Leese, Broadcom

  • Spencer Fricke, Samsung

Description

This extension enables the VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 format to be used without a sampler Y′CBCR conversion enabled.

New Enum Constants

  • VK_EXT_RGBA10X6_FORMATS_EXTENSION_NAME

  • VK_EXT_RGBA10X6_FORMATS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RGBA10X6_FORMATS_FEATURES_EXT

Issues

1) Should we reuse the existing format enumeration or introduce a new one?

RESOLVED: We reuse an existing format enumeration, VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16, that was previously exclusively used for YCbCr and therefore had a set of limitations related to that usage. The alternative was to introduce a new format token with exactly the same bit representation as the existing token, but without the limitations.

2) Should we only introduce VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 or also 1-3 component variations?

RESOLVED: Only the 4-component format is introduced because the 1- and 2- component variations are already not exclusive to YCbCr, and the 3-component variation is not a good match for hardware capabilities.

Version History

  • Revision 1, 2021-09-29 (Jan-Harald Fredriksen)

    • Initial EXT version

VK_EXT_robustness2

Name String

VK_EXT_robustness2

Extension Type

Device extension

Registered Extension Number

287

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-01-29

IP Status

No known IP claims.

Contributors
  • Liam Middlebrook, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension adds stricter requirements for how out of bounds reads and writes are handled. Most accesses must be tightly bounds-checked, out of bounds writes must be discarded, out of bound reads must return zero. Rather than allowing multiple possible (0,0,0,x) vectors, the out of bounds values are treated as zero, and then missing components are inserted based on the format as described in Conversion to RGBA and vertex input attribute extraction.

These additional requirements may be expensive on some implementations, and should only be enabled when truly necessary.

This extension also adds support for “null descriptors”, where VK_NULL_HANDLE can be used instead of a valid handle. Accesses to null descriptors have well-defined behavior, and do not rely on robustness.

New Enum Constants

  • VK_EXT_ROBUSTNESS_2_EXTENSION_NAME

  • VK_EXT_ROBUSTNESS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_EXT

Issues

  1. Why do VkPhysicalDeviceRobustness2PropertiesEXT::robustUniformBufferAccessSizeAlignment and VkPhysicalDeviceRobustness2PropertiesEXT::robustStorageBufferAccessSizeAlignment exist?

RESOLVED: Some implementations cannot efficiently tightly bounds-check all buffer accesses. Rather, the size of the bound range is padded to some power of two multiple, up to 256 bytes for uniform buffers and up to 4 bytes for storage buffers, and that padded size is bounds-checked. This is sufficient to implement D3D-like behavior, because D3D only allows binding whole uniform buffers or ranges that are a multiple of 256 bytes, and D3D raw and structured buffers only support 32-bit accesses.

Examples

None.

Version History

  • Revision 1, 2019-11-01 (Jeff Bolz, Liam Middlebrook)

    • Initial draft

VK_EXT_sample_locations

Name String

VK_EXT_sample_locations

Extension Type

Device extension

Registered Extension Number

144

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-08-02

Contributors
  • Mais Alnasser, AMD

  • Matthaeus G. Chajdas, AMD

  • Maciej Jesionowski, AMD

  • Daniel Rakos, AMD

  • Slawomir Grajewski, Intel

  • Jeff Bolz, NVIDIA

  • Bill Licea-Kane, Qualcomm

Description

This extension allows an application to modify the locations of samples within a pixel used in rasterization. Additionally, it allows applications to specify different sample locations for each pixel in a group of adjacent pixels, which can increase antialiasing quality (particularly if a custom resolve shader is used that takes advantage of these different locations).

It is common for implementations to optimize the storage of depth values by storing values that can be used to reconstruct depth at each sample location, rather than storing separate depth values for each sample. For example, the depth values from a single triangle may be represented using plane equations. When the depth value for a sample is needed, it is automatically evaluated at the sample location. Modifying the sample locations causes the reconstruction to no longer evaluate the same depth values as when the samples were originally generated, thus the depth aspect of a depth/stencil attachment must be cleared before rendering to it using different sample locations.

Some implementations may need to evaluate depth image values while performing image layout transitions. To accommodate this, instances of the VkSampleLocationsInfoEXT structure can be specified for each situation where an explicit or automatic layout transition has to take place. VkSampleLocationsInfoEXT can be chained from VkImageMemoryBarrier structures to provide sample locations for layout transitions performed by vkCmdWaitEvents and vkCmdPipelineBarrier calls, and VkRenderPassSampleLocationsBeginInfoEXT can be chained from VkRenderPassBeginInfo to provide sample locations for layout transitions performed implicitly by a render pass instance.

New Enum Constants

  • VK_EXT_SAMPLE_LOCATIONS_EXTENSION_NAME

  • VK_EXT_SAMPLE_LOCATIONS_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MULTISAMPLE_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT

    • VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT

Version History

  • Revision 1, 2017-08-02 (Daniel Rakos)

    • Internal revisions

VK_EXT_shader_atomic_float

Name String

VK_EXT_shader_atomic_float

Extension Type

Device extension

Registered Extension Number

261

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-07-15

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension allows a shader to contain floating-point atomic operations on buffer, workgroup, and image memory. It also advertises the SPIR-V AtomicFloat32AddEXT and AtomicFloat64AddEXT capabilities that allows atomic addition on floating-points numbers. The supported operations include OpAtomicFAddEXT, OpAtomicExchange, OpAtomicLoad and OpAtomicStore.

New Enum Constants

  • VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME

  • VK_EXT_SHADER_ATOMIC_FLOAT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_FEATURES_EXT

New SPIR-V Capabilities

Version History

  • Revision 1, 2020-07-15 (Vikram Kushwaha)

    • Internal revisions

VK_EXT_shader_atomic_float2

Name String

VK_EXT_shader_atomic_float2

Extension Type

Device extension

Registered Extension Number

274

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-08-14

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Faith Ekstrand, Intel

Description

This extension allows a shader to perform 16-bit floating-point atomic operations on buffer and workgroup memory as well as floating-point atomic minimum and maximum operations on buffer, workgroup, and image memory. It advertises the SPIR-V AtomicFloat16AddEXT capability which allows atomic add operations on 16-bit floating-point numbers and the SPIR-V AtomicFloat16MinMaxEXT, AtomicFloat32MinMaxEXT and AtomicFloat64MinMaxEXT capabilities which allow atomic minimum and maximum operations on floating-point numbers. The supported operations include OpAtomicFAddEXT, OpAtomicFMinEXT and OpAtomicFMaxEXT.

New Enum Constants

  • VK_EXT_SHADER_ATOMIC_FLOAT_2_EXTENSION_NAME

  • VK_EXT_SHADER_ATOMIC_FLOAT_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_2_FEATURES_EXT

Issues

1) Should this extension add support for 16-bit image atomics?

RESOLVED: No. While Vulkan supports creating storage images with VK_FORMAT_R16_SFLOAT and doing load and store on them, the data in the shader has a 32-bit representation. Vulkan currently has no facility for even basic reading or writing such images using 16-bit float values in the shader. Adding such functionality would be required before 16-bit image atomics would make sense and is outside the scope of this extension.

Version History

  • Revision 1, 2020-08-14 (Faith Ekstrand)

    • Internal revisions

VK_EXT_shader_image_atomic_int64

Name String

VK_EXT_shader_image_atomic_int64

Extension Type

Device extension

Registered Extension Number

235

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-07-14

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Matthaeus Chajdas, AMD

  • Graham Wihlidal, Epic Games

  • Tobias Hector, AMD

  • Jeff Bolz, Nvidia

  • Faith Ekstrand, Intel

Description

This extension extends existing 64-bit integer atomic support to enable these operations on images as well.

When working with large 2- or 3-dimensional data sets (e.g. rasterization or screen-space effects), image accesses are generally more efficient than equivalent buffer accesses. This extension allows applications relying on 64-bit integer atomics in this manner to quickly improve performance with only relatively minor code changes.

64-bit integer atomic support is guaranteed for optimally tiled images with the VK_FORMAT_R64_UINT and VK_FORMAT_R64_SINT formats.

New Enum Constants

  • VK_EXT_SHADER_IMAGE_ATOMIC_INT64_EXTENSION_NAME

  • VK_EXT_SHADER_IMAGE_ATOMIC_INT64_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_ATOMIC_INT64_FEATURES_EXT

Version History

  • Revision 1, 2020-07-14 (Tobias Hector)

    • Initial draft

VK_EXT_shader_module_identifier

Name String

VK_EXT_shader_module_identifier

Extension Type

Device extension

Registered Extension Number

463

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_shader_module_identifier

Other Extension Metadata

Last Modified Date

2022-05-16

IP Status

No known IP claims.

Contributors
  • Hans-Kristian Arntzen, Valve

  • Ricardo Garcia, Igalia

  • Piers Daniell, NVIDIA

  • Jan-Harald Fredriksen, Arm

  • Tom Olson, Arm

  • Faith Ekstrand, Collabora

Description

Some applications generate SPIR-V code at runtime. When pipeline caches are primed, either explicitly through e.g. VkPipelineCache mechanisms, or implicitly through driver managed caches, having to re-generate SPIR-V modules is redundant. SPIR-V modules could be cached on disk by an application, but the extra disk size requirement might be prohibitive in some use cases.

This extension adds the ability for an application to query a small identifier associated with a VkShaderModule. On subsequent runs of the application, the same identifier can be provided in lieu of a VkShaderModule object. A pipeline creation call with such a module may succeed if a pipeline could be created without invoking compilation, and information inside the SPIR-V module is not required by the implementation.

VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT must be used if only the identifier is provided, and this use case is intended to work like a non-blocking, speculative compile. Applications can fallback as necessary.

The main motivation for identifying the module itself and not the entire pipeline is that pipeline identifiers change when a driver is updated, but module identifiers are expected to be stable for any particular driver implementation. This approach is helpful for shader pre-compilation systems which can prime pipeline caches ahead of time. When on-disk pipeline caches are updated, the same shader identifiers could lead to a pipeline cache hit.

New Enum Constants

  • VK_EXT_SHADER_MODULE_IDENTIFIER_EXTENSION_NAME

  • VK_EXT_SHADER_MODULE_IDENTIFIER_SPEC_VERSION

  • VK_MAX_SHADER_MODULE_IDENTIFIER_SIZE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_MODULE_IDENTIFIER_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SHADER_MODULE_IDENTIFIER_EXT

Version History

  • Revision 1, 2022-03-16 (Hans-Kristian Arntzen)

    • Initial draft

VK_EXT_shader_stencil_export

Name String

VK_EXT_shader_stencil_export

Extension Type

Device extension

Registered Extension Number

141

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-07-19

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Dominik Witczak, AMD

  • Daniel Rakos, AMD

  • Rex Xu, AMD

Description

This extension adds support for the SPIR-V extension SPV_EXT_shader_stencil_export, providing a mechanism whereby a shader may generate the stencil reference value per invocation. When stencil testing is enabled, this allows the test to be performed against the value generated in the shader.

New Enum Constants

  • VK_EXT_SHADER_STENCIL_EXPORT_EXTENSION_NAME

  • VK_EXT_SHADER_STENCIL_EXPORT_SPEC_VERSION

Version History

  • Revision 1, 2017-07-19 (Dominik Witczak)

    • Initial draft

VK_EXT_subpass_merge_feedback

Name String

VK_EXT_subpass_merge_feedback

Extension Type

Device extension

Registered Extension Number

459

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_subpass_merge_feedback

Other Extension Metadata

Last Modified Date

2022-05-24

IP Status

No known IP claims.

Contributors
  • Jan-Harald Fredriksen, Arm

  • Jorg Wagner, Arm

  • Ting Wei, Arm

Description

This extension adds a mechanism to provide feedback to an application about whether the subpasses specified on render pass creation are merged by the implementation. Additionally, it provides a control to enable or disable subpass merging in the render pass.

New Enum Constants

  • VK_EXT_SUBPASS_MERGE_FEEDBACK_EXTENSION_NAME

  • VK_EXT_SUBPASS_MERGE_FEEDBACK_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_MERGE_FEEDBACK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_CONTROL_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_FEEDBACK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_RENDER_PASS_SUBPASS_FEEDBACK_CREATE_INFO_EXT

Version History

  • Revision 1, 2022-03-10

    • Initial draft.

  • Revision 2, 2022-05-24

    • Fix structextends and constness issues.

VK_EXT_surface_maintenance1

Name String

VK_EXT_surface_maintenance1

Extension Type

Instance extension

Registered Extension Number

275

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_surface_maintenance1

Other Extension Metadata

Last Modified Date

2022-11-09

Contributors
  • Jeff Juliano, NVIDIA

  • Lionel Landwerlin, Intel

  • Shahbaz Youssefi, Google

  • Chris Forbes, Google

  • Ian Elliott, Google

  • Hans-Kristian Arntzen, Valve

  • Daniel Stone, Collabora

Description

VK_EXT_surface_maintenance1 adds a collection of window system integration features that were intentionally left out or overlooked in the original VK_KHR_surface extension.

The new features are as follows:

  • Allow querying number of min/max images from a surface for a particular presentation mode.

  • Allow querying a surface’s scaled presentation capabilities.

  • Allow querying a surface for the set of presentation modes which can be easily switched between without requiring swapchain recreation.

New Enum Constants

  • VK_EXT_SURFACE_MAINTENANCE_1_EXTENSION_NAME

  • VK_EXT_SURFACE_MAINTENANCE_1_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_COMPATIBILITY_EXT

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_MODE_EXT

    • VK_STRUCTURE_TYPE_SURFACE_PRESENT_SCALING_CAPABILITIES_EXT

Version History

  • Revision 0, 2019-02-27 (Lionel Landwerlin)

    • Internal revisions

  • Revision 1, 2022-11-09 (Shahbaz Youssefi)

    • Add functionality and complete spec

VK_EXT_swapchain_colorspace

Name String

VK_EXT_swapchain_colorspace

Extension Type

Instance extension

Registered Extension Number

105

Revision

4

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-04-26

IP Status

No known IP claims.

Contributors
  • Courtney Goeltzenleuchter, Google

Description

This extension expands VkColorSpaceKHR to add support for most standard color spaces beyond VK_COLOR_SPACE_SRGB_NONLINEAR_KHR. This extension also adds support for VK_COLOR_SPACE_PASS_THROUGH_EXT which allows applications to use color spaces not explicitly enumerated in VkColorSpaceKHR.

New Enum Constants

  • VK_EXT_SWAPCHAIN_COLOR_SPACE_EXTENSION_NAME

  • VK_EXT_SWAPCHAIN_COLOR_SPACE_SPEC_VERSION

  • Extending VkColorSpaceKHR:

    • VK_COLOR_SPACE_ADOBERGB_LINEAR_EXT

    • VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT

    • VK_COLOR_SPACE_BT2020_LINEAR_EXT

    • VK_COLOR_SPACE_BT709_LINEAR_EXT

    • VK_COLOR_SPACE_BT709_NONLINEAR_EXT

    • VK_COLOR_SPACE_DCI_P3_LINEAR_EXT

    • VK_COLOR_SPACE_DCI_P3_NONLINEAR_EXT

    • VK_COLOR_SPACE_DISPLAY_P3_LINEAR_EXT

    • VK_COLOR_SPACE_DISPLAY_P3_NONLINEAR_EXT

    • VK_COLOR_SPACE_DOLBYVISION_EXT

    • VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT

    • VK_COLOR_SPACE_EXTENDED_SRGB_NONLINEAR_EXT

    • VK_COLOR_SPACE_HDR10_HLG_EXT

    • VK_COLOR_SPACE_HDR10_ST2084_EXT

    • VK_COLOR_SPACE_PASS_THROUGH_EXT

Issues

1) Does the spec need to specify which kinds of image formats support the color spaces?

RESOLVED: Pixel format is independent of color space (though some color spaces really want / need floating point color components to be useful). Therefore, do not plan on documenting what formats support which color spaces. An application can call vkGetPhysicalDeviceSurfaceFormatsKHR to query what a particular implementation supports.

2) How does application determine if HW supports appropriate transfer function for a color space?

RESOLVED: Extension indicates that implementation must not do the OETF encoding if it is not sRGB. That responsibility falls to the application shaders. Any other native OETF / EOTF functions supported by an implementation can be described by separate extension.

Version History

  • Revision 1, 2016-12-27 (Courtney Goeltzenleuchter)

    • Initial version

  • Revision 2, 2017-01-19 (Courtney Goeltzenleuchter)

    • Add pass through and multiple options for BT2020.

    • Clean up some issues with equations not displaying properly.

  • Revision 3, 2017-06-23 (Courtney Goeltzenleuchter)

    • Add extended sRGB non-linear enum.

  • Revision 4, 2019-04-26 (Graeme Leese)

    • Clarify color space transfer function usage.

    • Refer to normative definitions in the Data Format Specification.

    • Clarify DCI-P3 and Display P3 usage.

VK_EXT_swapchain_maintenance1

Name String

VK_EXT_swapchain_maintenance1

Extension Type

Device extension

Registered Extension Number

276

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_EXT_swapchain_maintenance1

Other Extension Metadata

Last Modified Date

2022-10-28

Contributors
  • Jeff Juliano, NVIDIA

  • Shahbaz Youssefi, Google

  • Chris Forbes, Google

  • Ian Elliott, Google

  • Yiwei Zhang, Google

  • Charlie Lao, Google

  • Lina Versace, Google

  • Ralph Potter, Samsung

  • Igor Nazarov, Samsung

  • Hyunchang Kim, Samsung

  • Suenghwan Lee, Samsung

  • Munseong Kang, Samsung

  • Joonyong Park, Samsung

  • Hans-Kristian Arntzen, Valve

  • Lisa Wu, Arm

  • Daniel Stone, Collabora

  • Pan Gao, Huawei

Description

VK_EXT_swapchain_maintenance1 adds a collection of window system integration features that were intentionally left out or overlooked in the original VK_KHR_swapchain extension.

The new features are as follows:

  • Specify a fence that will be signaled when the resources associated with a present operation can be safely destroyed.

  • Allow changing the present mode a swapchain is using at per-present granularity.

  • Allow applications to define the behavior when presenting a swapchain image to a surface with different dimensions than the image. Using this feature may allow implementations to avoid returning VK_ERROR_OUT_OF_DATE_KHR in this situation.

  • Allow applications to defer swapchain memory allocation for improved startup time and memory footprint.

  • Allow applications to release previously acquired images without presenting them.

New Enum Constants

  • VK_EXT_SWAPCHAIN_MAINTENANCE_1_EXTENSION_NAME

  • VK_EXT_SWAPCHAIN_MAINTENANCE_1_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SWAPCHAIN_MAINTENANCE_1_FEATURES_EXT

    • VK_STRUCTURE_TYPE_RELEASE_SWAPCHAIN_IMAGES_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_FENCE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODES_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_MODE_INFO_EXT

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_SCALING_CREATE_INFO_EXT

  • Extending VkSwapchainCreateFlagBitsKHR:

    • VK_SWAPCHAIN_CREATE_DEFERRED_MEMORY_ALLOCATION_BIT_EXT

Version History

  • Revision 0, 2019-05-28

    • Initial revisions

  • Revision 1, 2022-08-21 (Shahbaz Youssefi)

    • Add functionality and complete spec

VK_EXT_transform_feedback

Name String

VK_EXT_transform_feedback

Extension Type

Device extension

Registered Extension Number

29

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Uses
Contact

Other Extension Metadata

Last Modified Date

2018-10-09

Contributors
  • Baldur Karlsson, Valve

  • Boris Zanin, Mobica

  • Daniel Rakos, AMD

  • Donald Scorgie, Imagination

  • Henri Verbeet, CodeWeavers

  • Jan-Harald Fredriksen, Arm

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Barker, Unity

  • Jesse Hall, Google

  • Pierre-Loup Griffais, Valve

  • Philip Rebohle, DXVK

  • Ruihao Zhang, Qualcomm

  • Samuel Pitoiset, Valve

  • Slawomir Grajewski, Intel

  • Stu Smith, Imagination Technologies

Description

This extension adds transform feedback to the Vulkan API by exposing the SPIR-V TransformFeedback and GeometryStreams capabilities to capture vertex, tessellation or geometry shader outputs to one or more buffers. It adds API functionality to bind transform feedback buffers to capture the primitives emitted by the graphics pipeline from SPIR-V outputs decorated for transform feedback. The transform feedback capture can be paused and resumed by way of storing and retrieving a byte counter. The captured data can be drawn again where the vertex count is derived from the byte counter without CPU intervention. If the implementation is capable, a vertex stream other than zero can be rasterized.

All these features are designed to match the full capabilities of OpenGL core transform feedback functionality and beyond. Many of the features are optional to allow base OpenGL ES GPUs to also implement this extension.

The primary purpose of the functionality exposed by this extension is to support translation layers from other 3D APIs. This functionality is not considered forward looking, and is not expected to be promoted to a KHR extension or to core Vulkan. Unless this is needed for translation, it is recommended that developers use alternative techniques of using the GPU to process and capture vertex data.

New Enum Constants

  • VK_EXT_TRANSFORM_FEEDBACK_EXTENSION_NAME

  • VK_EXT_TRANSFORM_FEEDBACK_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT

    • VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT

    • VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT

  • Extending VkQueryType:

    • VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT

Issues

1) Should we include pause/resume functionality?

RESOLVED: Yes, this is needed to ease layering other APIs which have this functionality. To pause use vkCmdEndTransformFeedbackEXT and provide valid buffer handles in the pCounterBuffers array and offsets in the pCounterBufferOffsets array for the implementation to save the resume points. Then to resume use vkCmdBeginTransformFeedbackEXT with the previous pCounterBuffers and pCounterBufferOffsets values. Between the pause and resume there needs to be a memory barrier for the counter buffers with a source access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT to a destination access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT.

2) How does this interact with multiview?

RESOLVED: Transform feedback cannot be made active in a render pass with multiview enabled.

3) How should queries be done?

RESOLVED: There is a new query type VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT. A query pool created with this type will capture 2 integers - numPrimitivesWritten and numPrimitivesNeeded - for the specified vertex stream output from the last pre-rasterization shader stage. The vertex stream output queried is zero by default, but can be specified with the new vkCmdBeginQueryIndexedEXT and vkCmdEndQueryIndexedEXT commands.

Version History

  • Revision 1, 2018-10-09 (Piers Daniell)

    • Internal revisions

VK_EXT_validation_cache

Name String

VK_EXT_validation_cache

Extension Type

Device extension

Registered Extension Number

161

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-08-29

IP Status

No known IP claims.

Contributors
  • Cort Stratton, Google

  • Chris Forbes, Google

Description

This extension provides a mechanism for caching the results of potentially expensive internal validation operations across multiple runs of a Vulkan application. At the core is the VkValidationCacheEXT object type, which is managed similarly to the existing VkPipelineCache.

The new struct VkShaderModuleValidationCacheCreateInfoEXT can be included in the pNext chain at vkCreateShaderModule time. It contains a VkValidationCacheEXT to use when validating the VkShaderModule.

New Object Types

New Enum Constants

  • VK_EXT_VALIDATION_CACHE_EXTENSION_NAME

  • VK_EXT_VALIDATION_CACHE_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_VALIDATION_CACHE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT

Version History

  • Revision 1, 2017-08-29 (Cort Stratton)

    • Initial draft

VK_EXT_validation_features

Name String

VK_EXT_validation_features

Extension Type

Instance extension

Registered Extension Number

248

Revision

5

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2018-11-14

IP Status

No known IP claims.

Contributors
  • Karl Schultz, LunarG

  • Dave Houlton, LunarG

  • Mark Lobodzinski, LunarG

  • Camden Stocker, LunarG

  • Tony Barbour, LunarG

  • John Zulauf, LunarG

Description

This extension provides the VkValidationFeaturesEXT struct that can be included in the pNext chain of the VkInstanceCreateInfo structure passed as the pCreateInfo parameter of vkCreateInstance. The structure contains an array of VkValidationFeatureEnableEXT enum values that enable specific validation features that are disabled by default. The structure also contains an array of VkValidationFeatureDisableEXT enum values that disable specific validation layer features that are enabled by default.

Note

The VK_EXT_validation_features extension subsumes all the functionality provided in the VK_EXT_validation_flags extension.

New Structures

New Enum Constants

  • VK_EXT_VALIDATION_FEATURES_EXTENSION_NAME

  • VK_EXT_VALIDATION_FEATURES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT

Version History

  • Revision 1, 2018-11-14 (Karl Schultz)

    • Initial revision

  • Revision 2, 2019-08-06 (Mark Lobodzinski)

    • Add Best Practices enable

  • Revision 3, 2020-03-04 (Tony Barbour)

    • Add Debug Printf enable

  • Revision 4, 2020-07-29 (John Zulauf)

    • Add Synchronization Validation enable

  • Revision 5, 2021-05-18 (Tony Barbour)

    • Add Shader Validation Cache disable

VK_EXT_vertex_attribute_divisor

Name String

VK_EXT_vertex_attribute_divisor

Extension Type

Device extension

Registered Extension Number

191

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-08-03

IP Status

No known IP claims.

Contributors
  • Vikram Kushwaha, NVIDIA

  • Faith Ekstrand, Intel

Description

This extension allows instance-rate vertex attributes to be repeated for certain number of instances instead of advancing for every instance when instanced rendering is enabled.

New Enum Constants

  • VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME

  • VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT

Issues

1) What is the effect of a non-zero value for firstInstance?

RESOLVED: The Vulkan API should follow the OpenGL convention and offset attribute fetching by firstInstance while computing vertex attribute offsets.

2) Should zero be an allowed divisor?

RESOLVED: Yes. A zero divisor means the vertex attribute is repeated for all instances.

Examples

To create a vertex binding such that the first binding uses instanced rendering and the same attribute is used for every 4 draw instances, an application could use the following set of structures:

    const VkVertexInputBindingDivisorDescriptionEXT divisorDesc =
    {
        .binding = 0,
        .divisor = 4
    };

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

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

    const VkPipelineVertexInputStateCreateInfo viInfo =
    {
        .sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_CREATE_INFO,
        .pNext = &divisorInfo,
        ...
    };
    //...

Version History

  • Revision 1, 2017-12-04 (Vikram Kushwaha)

    • First Version

  • Revision 2, 2018-07-16 (Faith Ekstrand)

    • Adjust the interaction between divisor and firstInstance to match the OpenGL convention.

    • Disallow divisors of zero.

  • Revision 3, 2018-08-03 (Vikram Kushwaha)

    • Allow a zero divisor.

    • Add a physical device features structure to query/enable this feature.

VK_EXT_vertex_input_dynamic_state

Name String

VK_EXT_vertex_input_dynamic_state

Extension Type

Device extension

Registered Extension Number

353

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-08-21

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Spencer Fricke, Samsung

  • Stu Smith, AMD

Description

One of the states that contributes to the combinatorial explosion of pipeline state objects that need to be created, is the vertex input binding and attribute descriptions. By allowing them to be dynamic applications may reduce the number of pipeline objects they need to create.

This extension adds dynamic state support for what is normally static state in VkPipelineVertexInputStateCreateInfo.

New Commands

New Enum Constants

  • VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_EXTENSION_NAME

  • VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_VERTEX_INPUT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_INPUT_DYNAMIC_STATE_FEATURES_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT

    • VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT

Version History

VK_EXT_ycbcr_image_arrays

Name String

VK_EXT_ycbcr_image_arrays

Extension Type

Device extension

Registered Extension Number

253

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-01-15

Contributors
  • Piers Daniell, NVIDIA

Description

This extension allows images of a format that requires Y′CBCR conversion to be created with multiple array layers, which is otherwise restricted.

New Enum Constants

  • VK_EXT_YCBCR_IMAGE_ARRAYS_EXTENSION_NAME

  • VK_EXT_YCBCR_IMAGE_ARRAYS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_IMAGE_ARRAYS_FEATURES_EXT

Version History

  • Revision 1, 2019-01-15 (Piers Daniell)

    • Initial revision

VK_AMD_buffer_marker

Name String

VK_AMD_buffer_marker

Extension Type

Device extension

Registered Extension Number

180

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2018-01-26

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Jaakko Konttinen, AMD

  • Daniel Rakos, AMD

Description

This extension adds a new operation to execute pipelined writes of small marker values into a VkBuffer object.

The primary purpose of these markers is to facilitate the development of debugging tools for tracking which pipelined command contributed to device loss.

New Enum Constants

  • VK_AMD_BUFFER_MARKER_EXTENSION_NAME

  • VK_AMD_BUFFER_MARKER_SPEC_VERSION

Examples

None.

Version History

  • Revision 1, 2018-01-26 (Jaakko Konttinen)

    • Initial revision

VK_AMD_device_coherent_memory

Name String

VK_AMD_device_coherent_memory

Extension Type

Device extension

Registered Extension Number

230

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-02-04

Contributors
  • Ping Fu, AMD

  • Timothy Lottes, AMD

  • Tobias Hector, AMD

Description

This extension adds the device coherent and device uncached memory types. Any device accesses to device coherent memory are automatically made visible to any other device access. Device uncached memory indicates to applications that caches are disabled for a particular memory type, which guarantees device coherence.

Device coherent and uncached memory are expected to have lower performance for general access than non-device coherent memory, but can be useful in certain scenarios; particularly so for debugging.

New Enum Constants

  • VK_AMD_DEVICE_COHERENT_MEMORY_EXTENSION_NAME

  • VK_AMD_DEVICE_COHERENT_MEMORY_SPEC_VERSION

  • Extending VkMemoryPropertyFlagBits:

    • VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD

    • VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COHERENT_MEMORY_FEATURES_AMD

Version History

  • Revision 1, 2019-02-04 (Tobias Hector)

    • Initial revision

VK_AMD_display_native_hdr

Name String

VK_AMD_display_native_hdr

Extension Type

Device extension

Registered Extension Number

214

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-12-18

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Aaron Hagan, AMD

  • Aric Cyr, AMD

  • Timothy Lottes, AMD

  • Derrick Owens, AMD

  • Daniel Rakos, AMD

Description

This extension introduces the following display native HDR features to Vulkan:

  • A new VkColorSpaceKHR enum for setting the native display color space. For example, this color space would be set by the swapchain to use the native color space in Freesync2 displays.

  • Local dimming control

New Commands

New Enum Constants

  • VK_AMD_DISPLAY_NATIVE_HDR_EXTENSION_NAME

  • VK_AMD_DISPLAY_NATIVE_HDR_SPEC_VERSION

  • Extending VkColorSpaceKHR:

    • VK_COLOR_SPACE_DISPLAY_NATIVE_AMD

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DISPLAY_NATIVE_HDR_SURFACE_CAPABILITIES_AMD

    • VK_STRUCTURE_TYPE_SWAPCHAIN_DISPLAY_NATIVE_HDR_CREATE_INFO_AMD

Issues

None.

Examples

None.

Version History

  • Revision 1, 2018-12-18 (Daniel Rakos)

    • Initial revision

VK_AMD_gcn_shader

Name String

VK_AMD_gcn_shader

Extension Type

Device extension

Registered Extension Number

26

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-05-30

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Dominik Witczak, AMD

  • Daniel Rakos, AMD

  • Rex Xu, AMD

  • Graham Sellers, AMD

Description

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

New Enum Constants

  • VK_AMD_GCN_SHADER_EXTENSION_NAME

  • VK_AMD_GCN_SHADER_SPEC_VERSION

Version History

  • Revision 1, 2016-05-30 (Dominik Witczak)

    • Initial draft

VK_AMD_memory_overallocation_behavior

Name String

VK_AMD_memory_overallocation_behavior

Extension Type

Device extension

Registered Extension Number

190

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-09-19

IP Status

No known IP claims.

Contributors
  • Martin Dinkov, AMD

  • Matthaeus Chajdas, AMD

  • Daniel Rakos, AMD

  • Jon Campbell, AMD

Description

This extension allows controlling whether explicit overallocation beyond the device memory heap sizes (reported by VkPhysicalDeviceMemoryProperties) is allowed or not. Overallocation may lead to performance loss and is not supported for all platforms.

New Enum Constants

  • VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_EXTENSION_NAME

  • VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_OVERALLOCATION_CREATE_INFO_AMD

Version History

  • Revision 1, 2018-09-19 (Martin Dinkov)

    • Initial draft.

VK_AMD_mixed_attachment_samples

Name String

VK_AMD_mixed_attachment_samples

Extension Type

Device extension

Registered Extension Number

137

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-07-24

Contributors
  • Mais Alnasser, AMD

  • Matthaeus G. Chajdas, AMD

  • Maciej Jesionowski, AMD

  • Daniel Rakos, AMD

Description

This extension enables applications to use multisampled rendering with a depth/stencil sample count that is larger than the color sample count. Having a depth/stencil sample count larger than the color sample count allows maintaining geometry and coverage information at a higher sample rate than color information. All samples are depth/stencil tested, but only the first color sample count number of samples get a corresponding color output.

New Enum Constants

  • VK_AMD_MIXED_ATTACHMENT_SAMPLES_EXTENSION_NAME

  • VK_AMD_MIXED_ATTACHMENT_SAMPLES_SPEC_VERSION

Issues

None.

Version History

  • Revision 1, 2017-07-24 (Daniel Rakos)

    • Internal revisions

VK_AMD_pipeline_compiler_control

Name String

VK_AMD_pipeline_compiler_control

Extension Type

Device extension

Registered Extension Number

184

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-07-26

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Daniel Rakos, AMD

  • Maciej Jesionowski, AMD

  • Tobias Hector, AMD

Description

This extension introduces VkPipelineCompilerControlCreateInfoAMD structure that can be chained to a pipeline’s creation information to specify additional flags that affect pipeline compilation.

New Enum Constants

  • VK_AMD_PIPELINE_COMPILER_CONTROL_EXTENSION_NAME

  • VK_AMD_PIPELINE_COMPILER_CONTROL_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_COMPILER_CONTROL_CREATE_INFO_AMD

Issues

None.

Examples

None.

Version History

  • Revision 1, 2019-07-26 (Tobias Hector)

    • Initial revision.

VK_AMD_rasterization_order

Name String

VK_AMD_rasterization_order

Extension Type

Device extension

Registered Extension Number

19

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-04-25

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Jaakko Konttinen, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Dominik Witczak, AMD

Description

This extension introduces the possibility for the application to control the order of primitive rasterization. In unextended Vulkan, the following stages are guaranteed to execute in API order:

  • depth bounds test

  • stencil test, stencil op, and stencil write

  • depth test and depth write

  • occlusion queries

  • blending, logic op, and color write

This extension enables applications to opt into a relaxed, implementation defined primitive rasterization order that may allow better parallel processing of primitives and thus enabling higher primitive throughput. It is applicable in cases where the primitive rasterization order is known to not affect the output of the rendering or any differences caused by a different rasterization order are not a concern from the point of view of the application’s purpose.

A few examples of cases when using the relaxed primitive rasterization order would not have an effect on the final rendering:

  • If the primitives rendered are known to not overlap in framebuffer space.

  • If depth testing is used with a comparison operator of VK_COMPARE_OP_LESS, VK_COMPARE_OP_LESS_OR_EQUAL, VK_COMPARE_OP_GREATER, or VK_COMPARE_OP_GREATER_OR_EQUAL, and the primitives rendered are known to not overlap in clip space.

  • If depth testing is not used and blending is enabled for all attachments with a commutative blend operator.

New Enum Constants

  • VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME

  • VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD

Issues

1) How is this extension useful to application developers?

RESOLVED: Allows them to increase primitive throughput for cases when strict API order rasterization is not important due to the nature of the content, the configuration used, or the requirements towards the output of the rendering.

2) How does this extension interact with content optimizations aiming to reduce overdraw by appropriately ordering the input primitives?

RESOLVED: While the relaxed rasterization order might somewhat limit the effectiveness of such content optimizations, most of the benefits of it are expected to be retained even when the relaxed rasterization order is used, so applications should still apply these optimizations even if they intend to use the extension.

3) Are there any guarantees about the primitive rasterization order when using the new relaxed mode?

RESOLVED: No. In this case the rasterization order is completely implementation-dependent, but in practice it is expected to partially still follow the order of incoming primitives.

4) Does the new relaxed rasterization order have any adverse effect on repeatability and other invariance rules of the API?

RESOLVED: Yes, in the sense that it extends the list of exceptions when the repeatability requirement does not apply.

Examples

None

Issues

None

Version History

  • Revision 1, 2016-04-25 (Daniel Rakos)

    • Initial draft.

VK_AMD_shader_ballot

Name String

VK_AMD_shader_ballot

Extension Type

Device extension

Registered Extension Number

38

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-09-19

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Qun Lin, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Rex Xu, AMD

  • Dominik Witczak, AMD

  • Matthäus G. Chajdas, AMD

Description

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

New Enum Constants

  • VK_AMD_SHADER_BALLOT_EXTENSION_NAME

  • VK_AMD_SHADER_BALLOT_SPEC_VERSION

Version History

  • Revision 1, 2016-09-19 (Dominik Witczak)

    • Initial draft

VK_AMD_shader_core_properties

Name String

VK_AMD_shader_core_properties

Extension Type

Device extension

Registered Extension Number

186

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-06-25

IP Status

No known IP claims.

Contributors
  • Martin Dinkov, AMD

  • Matthaeus G. Chajdas, AMD

Description

This extension exposes shader core properties for a target physical device through the VK_KHR_get_physical_device_properties2 extension. Please refer to the example below for proper usage.

New Enum Constants

  • VK_AMD_SHADER_CORE_PROPERTIES_EXTENSION_NAME

  • VK_AMD_SHADER_CORE_PROPERTIES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD

Examples

This example retrieves the shader core properties for a physical device.

extern VkInstance       instance;

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

VkPhysicalDeviceProperties2             general_props;
VkPhysicalDeviceShaderCorePropertiesAMD shader_core_properties;

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

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

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

printf("Number of shader engines: %d\n",
    m_shader_core_properties.shader_engine_count =
    shader_core_properties.shaderEngineCount;
printf("Number of shader arrays: %d\n",
    m_shader_core_properties.shader_arrays_per_engine_count =
    shader_core_properties.shaderArraysPerEngineCount;
printf("Number of CUs per shader array: %d\n",
    m_shader_core_properties.compute_units_per_shader_array =
    shader_core_properties.computeUnitsPerShaderArray;
printf("Number of SIMDs per compute unit: %d\n",
    m_shader_core_properties.simd_per_compute_unit =
    shader_core_properties.simdPerComputeUnit;
printf("Number of wavefront slots in each SIMD: %d\n",
    m_shader_core_properties.wavefronts_per_simd =
    shader_core_properties.wavefrontsPerSimd;
printf("Number of threads per wavefront: %d\n",
    m_shader_core_properties.wavefront_size =
    shader_core_properties.wavefrontSize;
printf("Number of physical SGPRs per SIMD: %d\n",
    m_shader_core_properties.sgprs_per_simd =
    shader_core_properties.sgprsPerSimd;
printf("Minimum number of SGPRs that can be allocated by a wave: %d\n",
    m_shader_core_properties.min_sgpr_allocation =
    shader_core_properties.minSgprAllocation;
printf("Number of available SGPRs: %d\n",
    m_shader_core_properties.max_sgpr_allocation =
    shader_core_properties.maxSgprAllocation;
printf("SGPRs are allocated in groups of this size: %d\n",
    m_shader_core_properties.sgpr_allocation_granularity =
    shader_core_properties.sgprAllocationGranularity;
printf("Number of physical VGPRs per SIMD: %d\n",
    m_shader_core_properties.vgprs_per_simd =
    shader_core_properties.vgprsPerSimd;
printf("Minimum number of VGPRs that can be allocated by a wave: %d\n",
    m_shader_core_properties.min_vgpr_allocation =
    shader_core_properties.minVgprAllocation;
printf("Number of available VGPRs: %d\n",
    m_shader_core_properties.max_vgpr_allocation =
    shader_core_properties.maxVgprAllocation;
printf("VGPRs are allocated in groups of this size: %d\n",
    m_shader_core_properties.vgpr_allocation_granularity =
    shader_core_properties.vgprAllocationGranularity;

Version History

  • Revision 2, 2019-06-25 (Matthaeus G. Chajdas)

    • Clarified the meaning of a few fields.

  • Revision 1, 2018-02-15 (Martin Dinkov)

    • Initial draft.

VK_AMD_shader_core_properties2

Name String

VK_AMD_shader_core_properties2

Extension Type

Device extension

Registered Extension Number

228

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-07-26

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Tobias Hector, AMD

Description

This extension exposes additional shader core properties for a target physical device through the VK_KHR_get_physical_device_properties2 extension.

New Enum Constants

  • VK_AMD_SHADER_CORE_PROPERTIES_2_EXTENSION_NAME

  • VK_AMD_SHADER_CORE_PROPERTIES_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_2_AMD

Examples

None.

Version History

  • Revision 1, 2019-07-26 (Matthaeus G. Chajdas)

    • Initial draft.

VK_AMD_shader_early_and_late_fragment_tests

Name String

VK_AMD_shader_early_and_late_fragment_tests

Extension Type

Device extension

Registered Extension Number

322

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_AMD_shader_early_and_late_fragment_tests

Other Extension Metadata

Last Modified Date

2021-09-14

Interactions and External Dependencies
Contributors
  • Tobias Hector, AMD

Description

This extension adds support for the SPV_AMD_shader_early_and_late_fragment_tests extension, allowing shaders to explicitly opt in to allowing both early and late fragment tests with the EarlyAndLateFragmentTestsAMD execution mode.

If VK_EXT_shader_stencil_export is supported, additional execution modes allowing early depth tests similar to DepthUnchanged, DepthLess, and DepthGreater are provided.

New Enum Constants

  • VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_EXTENSION_NAME

  • VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_FEATURES_AMD

Version History

  • Revision 1, 2021-09-14 (Tobias Hector)

    • Initial draft

VK_AMD_shader_explicit_vertex_parameter

Name String

VK_AMD_shader_explicit_vertex_parameter

Extension Type

Device extension

Registered Extension Number

22

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-05-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Rex Xu, AMD

Description

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

New Enum Constants

  • VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_EXTENSION_NAME

  • VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_SPEC_VERSION

Version History

  • Revision 1, 2016-05-10 (Daniel Rakos)

    • Initial draft

VK_AMD_shader_fragment_mask

Name String

VK_AMD_shader_fragment_mask

Extension Type

Device extension

Registered Extension Number

138

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-08-16

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Aaron Hagan, AMD

  • Daniel Rakos, AMD

  • Timothy Lottes, AMD

Description

This extension provides efficient read access to the fragment mask in compressed multisampled color surfaces. The fragment mask is a lookup table that associates color samples with color fragment values.

From a shader, the fragment mask can be fetched with a call to fragmentMaskFetchAMD, which returns a single uint where each subsequent four bits specify the color fragment index corresponding to the color sample, starting from the least significant bit. For example, when eight color samples are used, the color fragment index for color sample 0 will be in bits 0-3 of the fragment mask, for color sample 7 the index will be in bits 28-31.

The color fragment for a particular color sample may then be fetched with the corresponding fragment mask value using the fragmentFetchAMD shader function.

New Enum Constants

  • VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME

  • VK_AMD_SHADER_FRAGMENT_MASK_SPEC_VERSION

New SPIR-V Capabilities

Examples

This example shows a shader that queries the fragment mask from a multisampled compressed surface and uses it to query fragment values.

#version 450 core

#extension GL_AMD_shader_fragment_mask: enable

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

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

layout(location = 0) out vec4 fragColor;

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

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

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

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

    fragColor = fragOne;
}

Version History

  • Revision 1, 2017-08-16 (Aaron Hagan)

    • Initial draft

VK_AMD_shader_image_load_store_lod

Name String

VK_AMD_shader_image_load_store_lod

Extension Type

Device extension

Registered Extension Number

47

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-08-21

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Dominik Witczak, AMD

  • Qun Lin, AMD

  • Rex Xu, AMD

Description

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

New Enum Constants

  • VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_EXTENSION_NAME

  • VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_SPEC_VERSION

Version History

  • Revision 1, 2017-08-21 (Dominik Witczak)

    • Initial draft

VK_AMD_shader_info

Name String

VK_AMD_shader_info

Extension Type

Device extension

Registered Extension Number

43

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2017-10-09

IP Status

No known IP claims.

Contributors
  • Jaakko Konttinen, AMD

Description

This extension adds a way to query certain information about a compiled shader which is part of a pipeline. This information may include shader disassembly, shader binary and various statistics about a shader’s resource usage.

While this extension provides a mechanism for extracting this information, the details regarding the contents or format of this information are not specified by this extension and may be provided by the vendor externally.

Furthermore, all information types are optionally supported, and users should not assume every implementation supports querying every type of information.

New Commands

New Enum Constants

  • VK_AMD_SHADER_INFO_EXTENSION_NAME

  • VK_AMD_SHADER_INFO_SPEC_VERSION

Examples

This example extracts the register usage of a fragment shader within a particular graphics pipeline:

extern VkDevice device;
extern VkPipeline gfxPipeline;

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

VkShaderStatisticsInfoAMD statistics = {};

size_t dataSize = sizeof(statistics);

if (pfnGetShaderInfoAMD(device,
    gfxPipeline,
    VK_SHADER_STAGE_FRAGMENT_BIT,
    VK_SHADER_INFO_TYPE_STATISTICS_AMD,
    &dataSize,
    &statistics) == VK_SUCCESS)
{
    printf("VGPR usage: %d\n", statistics.resourceUsage.numUsedVgprs);
    printf("SGPR usage: %d\n", statistics.resourceUsage.numUsedSgprs);
}

The following example continues the previous example by subsequently attempting to query and print shader disassembly about the fragment shader:

// Query disassembly size (if available)
if (pfnGetShaderInfoAMD(device,
    gfxPipeline,
    VK_SHADER_STAGE_FRAGMENT_BIT,
    VK_SHADER_INFO_TYPE_DISASSEMBLY_AMD,
    &dataSize,
    nullptr) == VK_SUCCESS)
{
    printf("Fragment shader disassembly:\n");

    void* disassembly = malloc(dataSize);

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

    free(disassembly);
}

Version History

  • Revision 1, 2017-10-09 (Jaakko Konttinen)

    • Initial revision

VK_AMD_shader_trinary_minmax

Name String

VK_AMD_shader_trinary_minmax

Extension Type

Device extension

Registered Extension Number

21

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-05-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Rex Xu, AMD

Description

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

New Enum Constants

  • VK_AMD_SHADER_TRINARY_MINMAX_EXTENSION_NAME

  • VK_AMD_SHADER_TRINARY_MINMAX_SPEC_VERSION

Version History

  • Revision 1, 2016-05-10 (Daniel Rakos)

    • Initial draft

VK_AMD_texture_gather_bias_lod

Name String

VK_AMD_texture_gather_bias_lod

Extension Type

Device extension

Registered Extension Number

42

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-03-21

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Dominik Witczak, AMD

  • Daniel Rakos, AMD

  • Graham Sellers, AMD

  • Matthaeus G. Chajdas, AMD

  • Qun Lin, AMD

  • Rex Xu, AMD

  • Timothy Lottes, AMD

Description

This extension adds two related features.

Firstly, support for the following SPIR-V extension in Vulkan is added:

  • SPV_AMD_texture_gather_bias_lod

Secondly, the extension allows the application to query which formats can be used together with the new function prototypes introduced by the SPIR-V extension.

New Enum Constants

  • VK_AMD_TEXTURE_GATHER_BIAS_LOD_EXTENSION_NAME

  • VK_AMD_TEXTURE_GATHER_BIAS_LOD_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD

New SPIR-V Capabilities

Examples

struct VkTextureLODGatherFormatPropertiesAMD
{
    VkStructureType sType;
    const void*     pNext;
    VkBool32        supportsTextureGatherLODBiasAMD;
};

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

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

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

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

vkGetPhysicalDeviceImageFormatProperties2(physical_device, &formatInfo, &formatProps);

if (textureLODGatherSupport.supportsTextureGatherLODBiasAMD == VK_TRUE)
{
    // physical device supports SPV_AMD_texture_gather_bias_lod for the specified
    // format configuration.
}
else
{
    // physical device does not support SPV_AMD_texture_gather_bias_lod for the
    // specified format configuration.
}

Version History

  • Revision 1, 2017-03-21 (Dominik Witczak)

    • Initial draft

VK_ANDROID_external_memory_android_hardware_buffer

Name String

VK_ANDROID_external_memory_android_hardware_buffer

Extension Type

Device extension

Registered Extension Number

130

Revision

5

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-09-30

IP Status

No known IP claims.

Contributors
  • Ray Smith, ARM

  • Lina Versace, Google

  • Jesse Hall, Google

  • Tobias Hector, Imagination

  • James Jones, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Matthew Netsch, Qualcomm

  • Andrew Garrard, Samsung

Description

This extension enables an application to import Android AHardwareBuffer objects created outside of the Vulkan device into Vulkan memory objects, where they can be bound to images and buffers. It also allows exporting an AHardwareBuffer from a Vulkan memory object for symmetry with other operating systems. But since not all AHardwareBuffer usages and formats have Vulkan equivalents, exporting from Vulkan provides strictly less functionality than creating the AHardwareBuffer externally and importing it.

Some AHardwareBuffer images have implementation-defined external formats that may not correspond to Vulkan formats. Sampler Y′CBCR conversion can be used to sample from these images and convert them to a known color space.

New Base Types

New Enum Constants

  • VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME

  • VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_PROPERTIES_ANDROID

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_USAGE_ANDROID

    • VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID

    • VK_STRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID

    • VK_STRUCTURE_TYPE_MEMORY_GET_ANDROID_HARDWARE_BUFFER_INFO_ANDROID

If VK_KHR_format_feature_flags2 is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_2_ANDROID

Issues

1) Other external memory objects are represented as weakly-typed handles (e.g. Win32 HANDLE or POSIX file descriptor), and require a handle type parameter along with handles. AHardwareBuffer is strongly typed, so naming the handle type is redundant. Does symmetry justify adding handle type parameters/fields anyway?

RESOLVED: No. The handle type is already provided in places that treat external memory objects generically. In the places we would add it, the application code that would have to provide the handle type value is already dealing with AHardwareBuffer-specific commands/structures; the extra symmetry would not be enough to make that code generic.

2) The internal layout and therefore size of a AHardwareBuffer image may depend on native usage flags that do not have corresponding Vulkan counterparts. Do we provide this information to vkCreateImage somehow, or allow the allocation size reported by vkGetImageMemoryRequirements to be approximate?

RESOLVED: Allow the allocation size to be unspecified when allocating the memory. It has to work this way for exported image memory anyway, since AHardwareBuffer allocation happens in vkAllocateMemory, and internally is performed by a separate HAL, not the Vulkan implementation itself. There is a similar issue with vkGetImageSubresourceLayout: the layout is determined by the allocator HAL, so it is not known until the image is bound to memory.

3) Should the result of sampling an external-format image with the suggested Y′CBCR conversion parameters yield the same results as using a samplerExternalOES in OpenGL ES?

RESOLVED: This would be desirable, so that apps converting from OpenGL ES to Vulkan could get the same output given the same input. But since sampling and conversion from Y′CBCR images is so loosely defined in OpenGL ES, multiple implementations do it in a way that does not conform to Vulkan’s requirements. Modifying the OpenGL ES implementation would be difficult, and would change the output of existing unmodified applications. Changing the output only for applications that are being modified gives developers the chance to notice and mitigate any problems. Implementations are encouraged to minimize differences as much as possible without causing compatibility problems for existing OpenGL ES applications or violating Vulkan requirements.

4) Should an AHardwareBuffer with AHARDWAREBUFFER_USAGE_CPU_* usage be mappable in Vulkan? Should it be possible to export an AHardwareBuffers with such usage?

RESOLVED: Optional, and mapping in Vulkan is not the same as AHardwareBuffer_lock. The semantics of these are different: mapping in memory is persistent, just gives a raw view of the memory contents, and does not involve ownership. AHardwareBuffer_lock gives the host exclusive access to the buffer, is temporary, and allows for reformatting copy-in/copy-out. Implementations are not required to support host-visible memory types for imported Android hardware buffers or resources backed by them. If a host-visible memory type is supported and used, the memory can be mapped in Vulkan, but doing so follows Vulkan semantics: it is just a raw view of the data and does not imply ownership (this means implementations must not internally call AHardwareBuffer_lock to implement vkMapMemory, or assume the application has done so). Implementations are not required to support linear-tiled images backed by Android hardware buffers, even if the AHardwareBuffer has CPU usage. There is no reliable way to allocate memory in Vulkan that can be exported to a AHardwareBuffer with CPU usage.

5) Android may add new AHardwareBuffer formats and usage flags over time. Can reference to them be added to this extension, or do they need a new extension?

RESOLVED: This extension can document the interaction between the new AHB formats/usages and existing Vulkan features. No new Vulkan features or implementation requirements can be added. The extension version number will be incremented when this additional documentation is added, but the version number does not indicate that an implementation supports Vulkan memory or resources that map to the new AHardwareBuffer features: support for that must be queried with vkGetPhysicalDeviceImageFormatProperties2 or is implied by successfully allocating a AHardwareBuffer outside of Vulkan that uses the new feature and has a GPU usage flag.

In essence, these are new features added to a new Android API level, rather than new Vulkan features. The extension will only document how existing Vulkan features map to that new Android feature.

Version History

  • Revision 5, 2022-02-04 (Chris Forbes)

    • Describe mapping of flags for storage image support

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

  • Revision 3, 2019-08-27 (Jon Leech)

    • Update revision history to correspond to XML version number

  • Revision 2, 2018-04-09 (Petr Kraus)

    • Markup fixes and remove incorrect Draft status

  • Revision 1, 2018-03-04 (Jesse Hall)

    • Initial version

VK_ARM_shader_core_builtins

Name String

VK_ARM_shader_core_builtins

Extension Type

Device extension

Registered Extension Number

498

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-10-05

Interactions and External Dependencies
Contributors
  • Kevin Petit, Arm Ltd.

  • Jan-Harald Fredriksen, Arm Ltd.

Description

This extension provides the ability to determine device-specific properties on Arm GPUs. It exposes properties for the number of shader cores, the maximum number of warps that can run on a shader core, and shader builtins to enable invocations to identify which core and warp a shader invocation is executing on.

This extension enables support for the SPIR-V CoreBuiltinsARM capability.

These properties and built-ins can be used for debugging or performance optimisation purposes. A typical optimisation example would be to use CoreIDARM to select a per-shader-core instance of a data structure in algorithms that use atomics so as to reduce contention.

New Enum Constants

  • VK_ARM_SHADER_CORE_BUILTINS_EXTENSION_NAME

  • VK_ARM_SHADER_CORE_BUILTINS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_FEATURES_ARM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_BUILTINS_PROPERTIES_ARM

New or Modified Built-In Variables

New SPIR-V Capabilities

Issues

None.

Version History

  • Revision 1, 2022-10-05 (Kevin Petit)

    • Initial revision

  • Revision 2, 2022-10-26 (Kevin Petit)

    • Add shaderCoreMask property

VK_ARM_shader_core_properties

Name String

VK_ARM_shader_core_properties

Extension Type

Device extension

Registered Extension Number

416

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2023-02-07

IP Status

No known IP claims.

Contributors
  • Jan-Harald Fredriksen, Arm Ltd.

Description

This extension provides the ability to determine device-specific performance properties of Arm GPUs.

It exposes properties for the number of texel, pixel, and fused multiply-add operations per clock per shader core. This can be used in combination with the VK_ARM_shader_core_builtins extension that provides the ability to query the number of shader cores on the physical device.

New Enum Constants

  • VK_ARM_SHADER_CORE_PROPERTIES_EXTENSION_NAME

  • VK_ARM_SHADER_CORE_PROPERTIES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_ARM

Version History

  • Revision 1, 2023-02-07 (Jan-Harald Fredriksen)

    • Initial draft.

VK_FUCHSIA_buffer_collection

Name String

VK_FUCHSIA_buffer_collection

Extension Type

Device extension

Registered Extension Number

367

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-09-23

IP Status

No known IP claims.

Contributors
  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

Description

A buffer collection is a collection of one or more buffers which were allocated together as a group and which all have the same properties. These properties describe the buffers' internal representation such as its dimensions and memory layout. This ensures that all of the buffers can be used interchangeably by tasks that require swapping among multiple buffers, such as double-buffered graphics rendering.

By sharing such a collection of buffers between components, communication about buffer lifecycle can be made much simpler and more efficient. For example, when a content producer finishes writing to a buffer, it can message the consumer of the buffer with the buffer index, rather than passing a handle to the shared memory.

On Fuchsia, the Sysmem service uses buffer collections as a core construct in its design. VK_FUCHSIA_buffer_collection is the Vulkan extension that allows Vulkan applications to interoperate with the Sysmem service on Fuchsia.

New Object Types

New Enum Constants

  • VK_FUCHSIA_BUFFER_COLLECTION_EXTENSION_NAME

  • VK_FUCHSIA_BUFFER_COLLECTION_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_BUFFER_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_IMAGE_CREATE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_COLLECTION_PROPERTIES_FUCHSIA

    • VK_STRUCTURE_TYPE_BUFFER_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMAGE_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_CONSTRAINTS_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_BUFFER_COLLECTION_FUCHSIA

    • VK_STRUCTURE_TYPE_SYSMEM_COLOR_SPACE_FUCHSIA

If VK_EXT_debug_report is supported:

Issues

1) When configuring a VkImageConstraintsInfoFUCHSIA structure for constraint setting, should a NULL pFormatConstraints parameter be allowed ?

RESOLVED: No. Specifying a NULL pFormatConstraints results in logical complexity of interpreting the relationship between the VkImageCreateInfo::usage settings of the elements of the pImageCreateInfos array and the implied or desired VkFormatFeatureFlags.

The explicit requirement for pFormatConstraints to be non-NULL simplifies the implied logic of the implementation and expectations for the Vulkan application.

Version History

  • Revision 2, 2021-09-23 (John Rosasco)

    • Review passes

  • Revision 1, 2021-03-09 (John Rosasco)

    • Initial revision

VK_FUCHSIA_external_memory

Name String

VK_FUCHSIA_external_memory

Extension Type

Device extension

Registered Extension Number

365

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-03-01

IP Status

No known IP claims.

Contributors
  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

Description

Vulkan apps may wish to export or import device memory handles to or from other logical devices, instances or APIs.

This memory sharing can eliminate copies of memory buffers when different subsystems need to interoperate on them. Sharing memory buffers may also facilitate a better distribution of processing workload for more complex memory manipulation pipelines.

New Enum Constants

  • VK_FUCHSIA_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_FUCHSIA_EXTERNAL_MEMORY_SPEC_VERSION

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_ZIRCON_VMO_BIT_FUCHSIA

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_MEMORY_GET_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_MEMORY_ZIRCON_HANDLE_PROPERTIES_FUCHSIA

Issues

See VK_KHR_external_memory issues list for further information.

Version History

  • Revision 1, 2021-03-01 (John Rosasco)

    • Initial draft

VK_FUCHSIA_external_semaphore

Name String

VK_FUCHSIA_external_semaphore

Extension Type

Device extension

Registered Extension Number

366

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-03-08

IP Status

No known IP claims.

Contributors
  • Craig Stout, Google

  • John Bauman, Google

  • John Rosasco, Google

Description

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

New Enum Constants

  • VK_FUCHSIA_EXTERNAL_SEMAPHORE_EXTENSION_NAME

  • VK_FUCHSIA_EXTERNAL_SEMAPHORE_SPEC_VERSION

  • Extending VkExternalSemaphoreHandleTypeFlagBits:

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_ZIRCON_EVENT_BIT_FUCHSIA

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_ZIRCON_HANDLE_INFO_FUCHSIA

    • VK_STRUCTURE_TYPE_SEMAPHORE_GET_ZIRCON_HANDLE_INFO_FUCHSIA

Issues

1) Does the application need to close the Zircon event handle returned by vkGetSemaphoreZirconHandleFUCHSIA?

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

Version History

  • Revision 1, 2021-03-08 (John Rosasco)

    • Initial revision

VK_FUCHSIA_imagepipe_surface

Name String

VK_FUCHSIA_imagepipe_surface

Extension Type

Instance extension

Registered Extension Number

215

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-27

IP Status

No known IP claims.

Contributors
  • Craig Stout, Google

  • Ian Elliott, Google

  • Jesse Hall, Google

Description

The VK_FUCHSIA_imagepipe_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Fuchsia imagePipeHandle.

New Enum Constants

  • VK_FUCHSIA_IMAGEPIPE_SURFACE_EXTENSION_NAME

  • VK_FUCHSIA_IMAGEPIPE_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA

Version History

  • Revision 1, 2018-07-27 (Craig Stout)

    • Initial draft.

VK_GGP_frame_token

Name String

VK_GGP_frame_token

Extension Type

Device extension

Registered Extension Number

192

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Jean-Francois Roy jfroy

Other Extension Metadata

Last Modified Date

2019-01-28

IP Status

No known IP claims.

Contributors
  • Jean-Francois Roy, Google

  • Richard O’Grady, Google

Description

This extension allows an application that uses the VK_KHR_swapchain extension in combination with a Google Games Platform surface provided by the VK_GGP_stream_descriptor_surface extension to associate a Google Games Platform frame token with a present operation.

New Structures

New Enum Constants

  • VK_GGP_FRAME_TOKEN_EXTENSION_NAME

  • VK_GGP_FRAME_TOKEN_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PRESENT_FRAME_TOKEN_GGP

Version History

  • Revision 1, 2018-11-26 (Jean-Francois Roy)

    • Initial revision.

VK_GGP_stream_descriptor_surface

Name String

VK_GGP_stream_descriptor_surface

Extension Type

Instance extension

Registered Extension Number

50

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Jean-Francois Roy jfroy

Other Extension Metadata

Last Modified Date

2019-01-28

IP Status

No known IP claims.

Contributors
  • Jean-Francois Roy, Google

  • Brad Grantham, Google

  • Connor Smith, Google

  • Cort Stratton, Google

  • Hai Nguyen, Google

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Jim Ray, Google

  • Katherine Wu, Google

  • Kaye Mason, Google

  • Kuangye Guo, Google

  • Mark Segal, Google

  • Nicholas Vining, Google

  • Paul Lalonde, Google

  • Richard O’Grady, Google

Description

The VK_GGP_stream_descriptor_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) that refers to a Google Games Platform GgpStreamDescriptor.

New Enum Constants

  • VK_GGP_STREAM_DESCRIPTOR_SURFACE_EXTENSION_NAME

  • VK_GGP_STREAM_DESCRIPTOR_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_STREAM_DESCRIPTOR_SURFACE_CREATE_INFO_GGP

Version History

  • Revision 1, 2018-11-26 (Jean-Francois Roy)

    • Initial revision.

VK_GOOGLE_decorate_string

Name String

VK_GOOGLE_decorate_string

Extension Type

Device extension

Registered Extension Number

225

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-09

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Hai Nguyen, Google

  • Neil Henning, AMD

Description

The VK_GOOGLE_decorate_string extension allows use of the SPV_GOOGLE_decorate_string extension in SPIR-V shader modules.

New Enum Constants

  • VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME

  • VK_GOOGLE_DECORATE_STRING_SPEC_VERSION

Version History

  • Revision 1, 2018-07-09 (Neil Henning)

    • Initial draft

VK_GOOGLE_display_timing

Name String

VK_GOOGLE_display_timing

Extension Type

Device extension

Registered Extension Number

93

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-02-14

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • Jesse Hall, Google

Description

This device extension allows an application that uses the VK_KHR_swapchain extension to obtain information about the presentation engine’s display, to obtain timing information about each present, and to schedule a present to happen no earlier than a desired time. An application can use this to minimize various visual anomalies (e.g. stuttering).

Traditional game and real-time animation applications need to correctly position their geometry for when the presentable image will be presented to the user. To accomplish this, applications need various timing information about the presentation engine’s display. They need to know when presentable images were actually presented, and when they could have been presented. Applications also need to tell the presentation engine to display an image no sooner than a given time. This allows the application to avoid stuttering, so the animation looks smooth to the user.

This extension treats variable-refresh-rate (VRR) displays as if they are fixed-refresh-rate (FRR) displays.

New Enum Constants

  • VK_GOOGLE_DISPLAY_TIMING_EXTENSION_NAME

  • VK_GOOGLE_DISPLAY_TIMING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE

Examples

Note

The example code for the this extension (like the VK_KHR_surface and VK_GOOGLE_display_timing extensions) is contained in the cube demo that is shipped with the official Khronos SDK, and is being kept up-to-date in that location (see: https://github.com/KhronosGroup/Vulkan-Tools/blob/master/cube/cube.c ).

Version History

  • Revision 1, 2017-02-14 (Ian Elliott)

    • Internal revisions

VK_GOOGLE_hlsl_functionality1

Name String

VK_GOOGLE_hlsl_functionality1

Extension Type

Device extension

Registered Extension Number

224

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-09

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Hai Nguyen, Google

  • Neil Henning, AMD

Description

The VK_GOOGLE_hlsl_functionality1 extension allows use of the SPV_GOOGLE_hlsl_functionality1 extension in SPIR-V shader modules.

New Enum Constants

  • VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME

  • VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION

  • VK_GOOGLE_HLSL_FUNCTIONALITY_1_EXTENSION_NAME

  • VK_GOOGLE_HLSL_FUNCTIONALITY_1_SPEC_VERSION

Version History

  • Revision 1, 2018-07-09 (Neil Henning)

    • Initial draft

VK_GOOGLE_surfaceless_query

Name String

VK_GOOGLE_surfaceless_query

Extension Type

Instance extension

Registered Extension Number

434

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact
Extension Proposal

VK_GOOGLE_surfaceless_query

Other Extension Metadata

Last Modified Date

2022-08-03

IP Status

No known IP claims.

Contributors
  • Ian Elliott, Google

  • Shahbaz Youssefi, Google

  • James Jones, NVIDIA

Description

This extension allows the vkGetPhysicalDeviceSurfaceFormatsKHR and vkGetPhysicalDeviceSurfacePresentModesKHR functions to accept VK_NULL_HANDLE as their surface parameter, allowing potential surface formats, color spaces and present modes to be queried without providing a surface. Identically, vkGetPhysicalDeviceSurfaceFormats2KHR, vkGetPhysicalDeviceSurfacePresentModes2EXT, and vkGetPhysicalDeviceSurfaceCapabilities2KHR would accept VK_NULL_HANDLE in VkPhysicalDeviceSurfaceInfo2KHR::surface. This can only be supported on platforms where the results of these queries are surface-agnostic and a single presentation engine is the implicit target of all present operations.

New Enum Constants

  • VK_GOOGLE_SURFACELESS_QUERY_EXTENSION_NAME

  • VK_GOOGLE_SURFACELESS_QUERY_SPEC_VERSION

Version History

  • Revision 1, 2021-12-14 (Shahbaz Youssefi)

    • Internal revisions

  • Revision 2, 2022-08-03 (Shahbaz Youssefi)

    • Precisions to which parts of the query responses are defined when surfaceless

VK_GOOGLE_user_type

Name String

VK_GOOGLE_user_type

Extension Type

Device extension

Registered Extension Number

290

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-07-09

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Kaye Mason, Google

  • Hai Nguyen, Google

Description

The VK_GOOGLE_user_type extension allows use of the SPV_GOOGLE_user_type extension in SPIR-V shader modules.

New Enum Constants

  • VK_GOOGLE_USER_TYPE_EXTENSION_NAME

  • VK_GOOGLE_USER_TYPE_SPEC_VERSION

Version History

  • Revision 1, 2019-09-07 (Kaye Mason)

    • Initial draft

VK_HUAWEI_cluster_culling_shader

Name String

VK_HUAWEI_cluster_culling_shader

Extension Type

Device extension

Registered Extension Number

405

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_HUAWEI_cluster_culling_shader

Other Extension Metadata

Last Modified Date

2022-11-17

Interactions and External Dependencies
Contributors
  • Yuchang Wang, Huawei

  • Juntao Li, Huawei

  • Pan Gao, Huawei

  • Jie Cao, Huawei

  • Yunjin Zhang, Huawei

  • Shujie Zhou, Huawei

  • Chaojun Wang, Huawei

  • Jiajun Hu, Huawei

  • Cong Zhang, Huawei

Description

Cluster Culling Shaders (CCS) are similar to the existing compute shaders. Their main purpose is to provide an execution environment in order to perform coarse-level geometry culling and LOD selection more efficiently on the GPU.

The traditional 2-pass GPU culling solution using a compute shader sometimes needs a pipeline barrier between compute and graphics pipeline to optimize performance. An additional compaction process may also be required. This extension addresses these shortcomings, allowing compute shaders to directly emit visible clusters to the following graphics pipeline.

A set of new built-in output variables are used to express a visible cluster. In addition, a new built-in function is used to emit these variables from CCS to the IA stage. The IA stage can use these variables to fetches vertices of a visible cluster and drive vertex shaders to shading these vertices.

Note that CCS do not work with geometry or tessellation shaders, but both IA and vertex shaders are preserved. Vertex shaders are still used for vertex position shading, instead of directly outputting transformed vertices from the compute shader. This makes CCS more suitable for mobile GPUs.

New Enum Constants

  • VK_HUAWEI_CLUSTER_CULLING_SHADER_EXTENSION_NAME

  • VK_HUAWEI_CLUSTER_CULLING_SHADER_SPEC_VERSION

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_CLUSTER_CULLING_SHADER_BIT_HUAWEI

  • Extending VkQueryPipelineStatisticFlagBits:

    • VK_QUERY_PIPELINE_STATISTIC_CLUSTER_CULLING_SHADER_INVOCATIONS_BIT_HUAWEI

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_FEATURES_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CLUSTER_CULLING_SHADER_PROPERTIES_HUAWEI

New SPIR-V Capability

Sample code

Example of cluster culling in a GLSL shader

#extension GL_HUAWEI_cluster_culling_shader: enable

#define GPU_WARP_SIZE                   32
#define GPU_GROUP_SIZE                  GPU_WARP_SIZE

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

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


#define GPU_CLUSTER_DESCRIPTOR_BINDING      0
#define GPU_DRAW_BUFFER_BINDING             1
#define GPU_INSTANCE_DESCRIPTOR_BINDING     2

const float pi_half = 1.570795;
uint instance_id;

struct BoundingSphere
{
  vec3 center;
  float radius;
};

struct BoundingCone
{
  vec3 normal;
  float angle;
};

struct ClusterDescriptor
{
  BoundingSphere sphere;
  BoundingCone cone;
  uint instance_idx;
};

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

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

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

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


layout(binding = GPU_CLUSTER_DESCRIPTOR_BINDING, std430) readonly buffer cluster_descriptor_ssbo
{
        ClusterDescriptor cluster_descriptors[];
};


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

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


bool isFrontFaceVisible( vec3 sphere_center, float sphere_radius, vec3 cone_normal, float cone_angle )
{
  vec3 sphere_center_dir = normalize(sphere_center -
                           instance_descriptors[instance_id].instance_data.view_origin);

  float sin_cone_angle = sin(min(cone_angle, pi_half));
  return dot(cone_normal, sphere_center_dir) < sin_cone_angle;
}

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

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


void main()
{
    uint cluster_id = gl_GlobalInvocationID.x;
    ClusterDescriptor desc = cluster_descriptors[cluster_id];

    // get instance description
    instance_id = desc.instance_idx;
    InstanceDescriptor inst_desc = instance_descriptors[instance_id];

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

    if( instance_render)
    {
        // cluster based culling
        bool render = (!isSphereOutsideFrustum(desc.sphere.center,
        desc.sphere.radius) && isFrontFaceVisible(desc.sphere.center, desc.sphere.radius, desc.cone.norm
        al, desc.cone.angle));

        if (render)
        {
            // this cluster passed coarse-level culling, update built-in output variable.
            // in case of indexed mode:
            gl_IndexCountHUAWEI     = draw_commands[cluster_id].indexcount;
            gl_InstanceCountHUAWEI  = draw_commands[cluster_id].instanceCount;
            gl_FirstIndexHUAWEI     = draw_commands[cluster_id].firstIndex;
            gl_VertexOffsetHUAWEI   = draw_commands[cluster_id].vertexoffset;
            gl_FirstInstanceHUAWEI  = draw_commands[cluster_id].firstInstance;
            gl_ClusterIDHUAWEI      = draw_commands[cluster_id].cluster_id;

            // emit built-in output variables as a drawing command to subsequent
            // rendering pipeline.
            dispatchClusterHUAWEI();
        }
    }
}

Example of graphics pipeline creation with cluster culling shader

// create a cluster culling shader stage info structure.
VkPipelineShaderStageCreateInfo ccsStageInfo{};
ccsStageInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO;
ccsStageInfo.stage = VK_SHADER_STAGE_CLUSTER_CULLING_BIT_HUAWEI;
ccsStageInfo.module = clustercullingshaderModule;
ccsStageInfo.pName =  "main";

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

// create graphics pipeline
VkGraphicsPipelineCreateInfo pipelineInfo{};
pipelineInfo.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO;
pipelineInfo.stageCount = 3;
pipelineInfo.pStage = shaderStages;
pipelineInfo.pVertexInputState = &vertexInputInfo;
// ...
VkPipeline graphicsPipeline;
VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineInfo, nullptr, &graphicsPipeline);

Example of launching the execution of cluster culling shader

vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, graphicsPipeline);
vkCmdDrawClusterHUAWEI(commandBuffer, groupCountX, 1, 1);
vkCmdEndRenderPass(commandBuffer);

Version History

  • Revision 1, 2022-11-18 (YuChang Wang)

    • Internal revisions

  • Revision 2, 2023-04-02 (Jon Leech)

    • Grammar edits.

VK_HUAWEI_invocation_mask

Name String

VK_HUAWEI_invocation_mask

Extension Type

Device extension

Registered Extension Number

371

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_HUAWEI_invocation_mask

Other Extension Metadata

Last Modified Date

2021-05-27

Interactions and External Dependencies
Contributors
  • Yunpeng Zhu

  • Juntao Li, Huawei

  • Liang Chen, Huawei

  • Shaozhuang Shi, Huawei

  • Hailong Chu, Huawei

Description

The rays to trace may be sparse in some use cases. For example, the scene only have a few regions to reflect. Providing an invocation mask image to the ray tracing commands could potentially give the hardware the hint to do certain optimization without invoking an additional pass to compact the ray buffer.

New Enum Constants

  • VK_HUAWEI_INVOCATION_MASK_EXTENSION_NAME

  • VK_HUAWEI_INVOCATION_MASK_SPEC_VERSION

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_INVOCATION_MASK_READ_BIT_HUAWEI

  • Extending VkImageUsageFlagBits:

    • VK_IMAGE_USAGE_INVOCATION_MASK_BIT_HUAWEI

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_INVOCATION_MASK_BIT_HUAWEI

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INVOCATION_MASK_FEATURES_HUAWEI

Examples

RT mask is updated before each traceRay.

Step 1. Generate InvocationMask.

//the rt mask image bind as color attachment in the fragment shader
Layout(location = 2) out vec4 outRTmask
vec4 mask = vec4(x,x,x,x);
outRTmask = mask;

Step 2. traceRay with InvocationMask

vkCmdBindPipeline(
    commandBuffers[imageIndex],
    VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR, m_rtPipeline);
    vkCmdBindDescriptorSets(commandBuffers[imageIndex],
    VK_PIPELINE_BIND_POINT_RAY_TRACING_NV,
    m_rtPipelineLayout, 0, 1, &m_rtDescriptorSet,
    0, nullptr);

vkCmdBindInvocationMaskHUAWEI(
    commandBuffers[imageIndex],
    InvocationMaskimageView,
    InvocationMaskimageLayout);
    vkCmdTraceRaysKHR(commandBuffers[imageIndex],
    pRaygenShaderBindingTable,
    pMissShaderBindingTable,
    swapChainExtent.width,
    swapChainExtent.height, 1);

Version History

  • Revision 1, 2021-05-27 (Yunpeng Zhu)

    • Initial draft.

VK_HUAWEI_subpass_shading

Name String

VK_HUAWEI_subpass_shading

Extension Type

Device extension

Registered Extension Number

370

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-06-01

Interactions and External Dependencies
Contributors
  • Hueilong Wang

  • Juntao Li, Huawei

  • Renmiao Lu, Huawei

  • Pan Gao, Huawei

Description

This extension allows applications to execute a subpass shading pipeline in a subpass of a render pass in order to save memory bandwidth for algorithms like tile-based deferred rendering and forward plus. A subpass shading pipeline is a pipeline with the compute pipeline ability, allowed to read values from input attachments, and only allowed to be dispatched inside a stand-alone subpass. Its work dimension is defined by the render pass’s render area size. Its workgroup size (width, height) shall be a power-of-two number in width or height, with minimum value from 8, and maximum value shall be decided from the render pass attachments and sample counts but depends on implementation.

The GlobalInvocationId.xy of a subpass shading pipeline is equal to the FragCoord.xy of a graphic pipeline in the same render pass subtracted the offset of the VkRenderPassBeginInfo::renderArea. GlobalInvocationId.z is mapped to the Layer if VK_EXT_shader_viewport_index_layer is supported. The GlobalInvocationId.xy is equal to the index of the local workgroup multiplied by the size of the local workgroup plus the LocalInvocationId and the offset of the VkRenderPassBeginInfo::renderArea.

This extension allows a subpass’s pipeline bind point to be VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI.

New Enum Constants

  • VK_HUAWEI_SUBPASS_SHADING_EXTENSION_NAME

  • VK_HUAWEI_SUBPASS_SHADING_SPEC_VERSION

  • Extending VkPipelineBindPoint:

    • VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI

    • VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_SUBPASS_SHADING_BIT_HUAWEI

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_FEATURES_HUAWEI

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_SHADING_PROPERTIES_HUAWEI

    • VK_STRUCTURE_TYPE_SUBPASS_SHADING_PIPELINE_CREATE_INFO_HUAWEI

Sample Code

Example of subpass shading in a GLSL shader

#extension GL_HUAWEI_subpass_shading: enable
#extension GL_KHR_shader_subgroup_arithmetic: enable

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

void main()
{
  float d = subpassLoad(depth).x;
  float minD = subgroupMin(d);
  float maxD = subgroupMax(d);
}

Example of subpass shading dispatching in a subpass

vkCmdNextSubpass(commandBuffer, VK_SUBPASS_CONTENTS_INLINE);
vkCmdBindPipeline(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipeline);
vkCmdBindDescriptorSets(commandBuffer, VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI, subpassShadingPipelineLayout,
  firstSet, descriptorSetCount, pDescriptorSets, dynamicOffsetCount, pDynamicOffsets);
vkCmdSubpassShadingHUAWEI(commandBuffer)
vkCmdEndRenderPass(commandBuffer);

Example of subpass shading render pass creation

VkAttachmentDescription2 attachments[] = {
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_D24_UNORM_S8_UINT, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_DONT_CARE,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL
  },
  {
    VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2, NULL,
    0, VK_FORMAT_R8G8B8A8_UNORM, VK_SAMPLE_COUNT_1_BIT,
    VK_ATTACHMENT_LOAD_OP_CLEAR, VK_ATTACHMENT_STORE_OP_STORE,
    VK_ATTACHMENT_LOAD_OP_DONT_CARE, VK_ATTACHMENT_LOAD_OP_DONT_CARE,
    VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL
  }
};

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

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

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

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

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

VkRenderPassCreateInfo2 renderPassCreateInfo = {
  VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2, NULL, 0,
    sizeof(attachments)/sizeof(attachments[0]), attachments,
    sizeof(subpasses)/sizeof(subpasses[0]), subpasses,
    sizeof(dependencies)/sizeof(dependencies[0]), dependencies,
    0, NULL
};
VKRenderPass renderPass;
vkCreateRenderPass2(device, &renderPassCreateInfo, NULL, &renderPass);

Example of subpass shading pipeline creation

VkExtent2D maxWorkgroupSize;

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

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

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

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

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

VKPipeline pipeline;

vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI(device, renderPass, &maxWorkgroupSize);
vkCreateComputePipelines(device, pipelineCache, 1, &subpassShadingComputePipelineCreateInfo, NULL, &pipeline);

Version History

  • Revision 3, 2023-06-19 (Pan Gao)

    • Rename VK_PIPELINE_STAGE_2_SUBPASS_SHADING_BIT_HUAWEI to VK_PIPELINE_STAGE_2_SUBPASS_SHADER_BIT_HUAWEI to better aligned with naming of other pipeline stages

  • Revision 2, 2021-06-28 (Hueilong Wang)

    • Change vkGetSubpassShadingMaxWorkgroupSizeHUAWEI to vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI to resolve issue pub1564

  • Revision 1, 2020-12-15 (Hueilong Wang)

    • Initial draft.

VK_IMG_filter_cubic

Name String

VK_IMG_filter_cubic

Extension Type

Device extension

Registered Extension Number

16

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-02-23

Contributors
  • Tobias Hector, Imagination Technologies

Description

VK_IMG_filter_cubic adds an additional, high quality cubic filtering mode to Vulkan, using a Catmull-Rom bicubic filter. Performing this kind of filtering can be done in a shader by using 16 samples and a number of instructions, but this can be inefficient. The cubic filter mode exposes an optimized high quality texture sampling using fixed texture sampling functionality.

New Enum Constants

  • VK_IMG_FILTER_CUBIC_EXTENSION_NAME

  • VK_IMG_FILTER_CUBIC_SPEC_VERSION

  • Extending VkFilter:

    • VK_FILTER_CUBIC_IMG

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_IMG

Example

Creating a sampler with the new filter for both magnification and minification

    VkSamplerCreateInfo createInfo =
    {
        .sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
        // Other members set to application-desired values
    };

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

    VkSampler sampler;
    VkResult result = vkCreateSampler(
        device,
        &createInfo,
        &sampler);

Version History

  • Revision 1, 2016-02-23 (Tobias Hector)

    • Initial version

VK_INTEL_performance_query

Name String

VK_INTEL_performance_query

Extension Type

Device extension

Registered Extension Number

211

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2018-05-16

IP Status

No known IP claims.

Contributors
  • Lionel Landwerlin, Intel

  • Piotr Maciejewski, Intel

Description

This extension allows an application to capture performance data to be interpreted by a external application or library.

Such a library is available at : https://github.com/intel/metrics-discovery

Performance analysis tools such as Graphics Performance Analyzers make use of this extension and the metrics-discovery library to present the data in a human readable way.

New Enum Constants

  • VK_INTEL_PERFORMANCE_QUERY_EXTENSION_NAME

  • VK_INTEL_PERFORMANCE_QUERY_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_PERFORMANCE_CONFIGURATION_INTEL

  • Extending VkQueryType:

    • VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_MARKER_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_OVERRIDE_INFO_INTEL

    • VK_STRUCTURE_TYPE_PERFORMANCE_STREAM_MARKER_INFO_INTEL

    • VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL

    • VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_QUERY_CREATE_INFO_INTEL

Example Code

// A previously created device
VkDevice device;

// A queue derived from the device
VkQueue queue;

VkInitializePerformanceApiInfoINTEL performanceApiInfoIntel = {
  VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL,
  NULL,
  NULL
};

vkInitializePerformanceApiINTEL(
  device,
  &performanceApiInfoIntel);

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

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

VkQueryPool queryPool;

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

assert(VK_SUCCESS == result);

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

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

result = vkBeginCommandBuffer(commandBuffer, &commandBufferBeginInfo);

assert(VK_SUCCESS == result);

vkCmdResetQueryPool(
  commandBuffer,
  queryPool,
  0,
  1);

vkCmdBeginQuery(
  commandBuffer,
  queryPool,
  0,
  0);

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

// 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);

VkPerformanceConfigurationAcquireInfoINTEL performanceConfigurationAcquireInfo = {
  VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL,
  NULL,
  VK_PERFORMANCE_CONFIGURATION_TYPE_COMMAND_QUEUE_METRICS_DISCOVERY_ACTIVATED_INTEL
};

VkPerformanceConfigurationINTEL performanceConfigurationIntel;

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

vkQueueSetPerformanceConfigurationINTEL(queue, performanceConfigurationIntel);

assert(VK_SUCCESS == result);

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

result = vkReleasePerformanceConfigurationINTEL(
  device,
  performanceConfigurationIntel);

assert(VK_SUCCESS == result);

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

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

assert(VK_SUCCESS == result);

// The data can then be passed back to metrics-discovery from which
// human readable values can be queried.

Version History

  • Revision 2, 2020-03-06 (Lionel Landwerlin)

    • Rename VkQueryPoolCreateInfoINTEL in VkQueryPoolPerformanceQueryCreateInfoINTEL

  • Revision 1, 2018-05-16 (Lionel Landwerlin)

    • Initial revision

VK_INTEL_shader_integer_functions2

Name String

VK_INTEL_shader_integer_functions2

Extension Type

Device extension

Registered Extension Number

210

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-04-30

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Ian Romanick, Intel

  • Ben Ashbaugh, Intel

Description

This extension adds support for several new integer instructions in SPIR-V for use in graphics shaders. Many of these instructions have pre-existing counterparts in the Kernel environment.

The added integer functions are defined by the SPV_INTEL_shader_integer_functions2 SPIR-V extension and can be used with the GL_INTEL_shader_integer_functions2 GLSL extension.

New Enum Constants

  • VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_EXTENSION_NAME

  • VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_FUNCTIONS_2_FEATURES_INTEL

New SPIR-V Capabilities

Version History

  • Revision 1, 2019-04-30 (Ian Romanick)

    • Initial draft

VK_LUNARG_direct_driver_loading

Name String

VK_LUNARG_direct_driver_loading

Extension Type

Instance extension

Registered Extension Number

460

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_LUNARG_direct_driver_loading

Other Extension Metadata

Last Modified Date

2022-11-29

Contributors
  • Charles Giessen, LunarG

Description

This extension provides a mechanism for applications to add drivers to the implementation. This allows drivers to be included with an application without requiring installation and is capable of being used in any execution environment, such as a process running with elevated privileges.

New Function Pointers

New Enum Constants

  • VK_LUNARG_DIRECT_DRIVER_LOADING_EXTENSION_NAME

  • VK_LUNARG_DIRECT_DRIVER_LOADING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_INFO_LUNARG

    • VK_STRUCTURE_TYPE_DIRECT_DRIVER_LOADING_LIST_LUNARG

Version History

  • Revision 1, 2022-11-29 (Charles Giessen)

    • Initial version

VK_NN_vi_surface

Name String

VK_NN_vi_surface

Extension Type

Instance extension

Registered Extension Number

63

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Mathias Heyer mheyer

Other Extension Metadata

Last Modified Date

2016-12-02

IP Status

No known IP claims.

Contributors
  • Mathias Heyer, NVIDIA

  • Michael Chock, NVIDIA

  • Yasuhiro Yoshioka, Nintendo

  • Daniel Koch, NVIDIA

Description

The VK_NN_vi_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) associated with an nn::vi::Layer.

New Commands

New Structures

New Enum Constants

  • VK_NN_VI_SURFACE_EXTENSION_NAME

  • VK_NN_VI_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN

Issues

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

RESOLVED: No. It is currently always assumed that the device and display will always be compatible.

2) VkViSurfaceCreateInfoNN::pWindow is intended to store an nn::vi::NativeWindowHandle, but its declared type is a bare void* to store the window handle. Why the discrepancy?

RESOLVED: It is for C compatibility. The definition for the VI native window handle type is defined inside the nn::vi C++ namespace. This prevents its use in C source files. nn::vi::NativeWindowHandle is always defined to be void*, so this extension uses void* to match.

Version History

  • Revision 1, 2016-12-2 (Michael Chock)

    • Initial draft.

VK_NV_acquire_winrt_display

Name String

VK_NV_acquire_winrt_display

Extension Type

Device extension

Registered Extension Number

346

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-09-29

IP Status

No known IP claims.

Contributors
  • Jeff Juliano, NVIDIA

Description

This extension allows an application to take exclusive control of a display on Windows 10 provided that the display is not already controlled by a compositor. Examples of compositors include the Windows desktop compositor, other applications using this Vulkan extension, and applications that “Acquire” a “DisplayTarget” using a “WinRT” command such as “winrt::Windows::Devices::Display::Core::DisplayManager.TryAcquireTarget()”.

When control is acquired the application has exclusive access to the display until control is released or the application terminates. An application’s attempt to acquire is denied if a different application has already acquired the display.

New Enum Constants

  • VK_NV_ACQUIRE_WINRT_DISPLAY_EXTENSION_NAME

  • VK_NV_ACQUIRE_WINRT_DISPLAY_SPEC_VERSION

Issues

1) What should the platform substring be for this extension:

RESOLVED: The platform substring is “Winrt”.

The substring “Winrt” matches the fact that the OS API exposing the acquire and release functionality is called “WinRT”.

The substring “Win32” is wrong because the related “WinRT” API is explicitly not a “Win32” API. “WinRT” is a competing API family to the “Win32” API family.

The substring “Windows” is suboptimal because there could be more than one relevant API on the Windows platform. There is preference to use the more-specific substring “Winrt”.

2) Should vkAcquireWinrtDisplayNV take a winRT DisplayTarget, or a Vulkan display handle as input?

RESOLVED: A Vulkan display handle. This matches the design of vkAcquireXlibDisplayEXT.

3) Should the acquire command be platform-independent named “vkAcquireDisplayNV”, or platform-specific named “vkAcquireWinrtDisplayNV”?

RESOLVED: Add a platform-specific command.

The inputs to the Acquire command are all Vulkan types. None are WinRT types. This opens the possibility of the winrt extension defining a platform-independent acquire command.

The X11 acquire command does need to accept a platform-specific parameter. This could be handled by adding to a platform-independent acquire command a params struct to which platform-dependent types can be chained by pNext pointer.

The prevailing opinion is that it would be odd to create a second platform-independent function that is used on the Windows 10 platform, but that is not used for the X11 platform. Since a Windows 10 platform-specific command is needed anyway for converting between vkDisplayKHR and platform-native handles, opinion was to create a platform-specific acquire function.

4) Should the vkGetWinrtDisplayNV parameter identifying a display be named “deviceRelativeId” or “adapterRelativeId”?

RESOLVED: The WinRT name is “AdapterRelativeId”. The name “adapter” is the Windows analog to a Vulkan “physical device”. Vulkan already has precedent to use the name deviceLUID for the concept that Windows APIs call “AdapterLuid”. Keeping form with this precedent, the name “deviceRelativeId” is chosen.

5) Does vkAcquireWinrtDisplayNV cause the Windows desktop compositor to release a display?

RESOLVED: No. vkAcquireWinrtDisplayNV does not itself cause the Windows desktop compositor to release a display. This action must be performed outside of Vulkan.

Beginning with Windows 10 version 2004 it is possible to cause the Windows desktop compositor to release a display by using the “Advanced display settings” sub-page of the “Display settings” control panel. See https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors

6) Where can one find additional information about custom compositors for Windows 10?

RESOLVED: Relevant references are as follows.

According to Microsoft’s documentation on "building a custom compositor", the ability to write a custom compositor is not a replacement for a fullscreen desktop window. The feature is for writing compositor apps that drive specialized hardware.

Only certain editions of Windows 10 support custom compositors, "documented here". The product type can be queried from Windows 10. See https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getproductinfo

Version History

  • Revision 1, 2020-09-29 (Jeff Juliano)

    • Initial draft

VK_NV_clip_space_w_scaling

Name String

VK_NV_clip_space_w_scaling

Extension Type

Device extension

Registered Extension Number

88

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-02-15

Contributors
  • Eric Werness, NVIDIA

  • Kedarnath Thangudu, NVIDIA

Description

Virtual Reality (VR) applications often involve a post-processing step to apply a “barrel” distortion to the rendered image to correct the “pincushion” distortion introduced by the optics in a VR device. The barrel distorted image has lower resolution along the edges compared to the center. Since the original image is rendered at high resolution, which is uniform across the complete image, a lot of pixels towards the edges do not make it to the final post-processed image.

This extension provides a mechanism to render VR scenes at a non-uniform resolution, in particular a resolution that falls linearly from the center towards the edges. This is achieved by scaling the w coordinate of the vertices in the clip space before perspective divide. The clip space w coordinate of the vertices can be offset as of a function of x and y coordinates as follows:

w' = w + Ax + By

In the intended use case for viewport position scaling, an application should use a set of four viewports, one for each of the four quadrants of a Cartesian coordinate system. Each viewport is set to the dimension of the image, but is scissored to the quadrant it represents. The application should specify A and B coefficients of the w-scaling equation above, that have the same value, but different signs, for each of the viewports. The signs of A and B should match the signs of x and y for the quadrant that they represent such that the value of w' will always be greater than or equal to the original w value for the entire image. Since the offset to w, (Ax + By), is always positive, and increases with the absolute values of x and y, the effective resolution will fall off linearly from the center of the image to its edges.

New Enum Constants

  • VK_NV_CLIP_SPACE_W_SCALING_EXTENSION_NAME

  • VK_NV_CLIP_SPACE_W_SCALING_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV

Issues

1) Is the pipeline struct name too long?

RESOLVED: It fits with the naming convention.

2) Separate W scaling section or fold into coordinate transformations?

RESOLVED: Leaving it as its own section for now.

Examples

VkViewport viewports[4];
VkRect2D scissors[4];
VkViewportWScalingNV scalings[4];

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

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

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

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

VkPipelineViewportWScalingStateCreateInfoNV vpWScalingStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV };

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

VkPipelineViewportStateCreateInfo vpStateInfo = { VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO };
vpStateInfo.viewportCount = 4;
vpStateInfo.pViewports = &viewports[0];
vpStateInfo.scissorCount = 4;
vpStateInfo.pScissors = &scissors[0];
vpStateInfo.pNext = &vpWScalingStateInfo;

Example shader to read from a w-scaled texture:

// Vertex Shader
// Draw a triangle that covers the whole screen
const vec4 positions[3] = vec4[3](vec4(-1, -1, 0, 1),
                                  vec4( 3, -1, 0, 1),
                                  vec4(-1,  3, 0, 1));
out vec2 uv;
void main()
{
    vec4 pos = positions[ gl_VertexID ];
    gl_Position = pos;
    uv = pos.xy;
}

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

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

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

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

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

    Color = texture(tex, P * 0.5 + 0.5);
}

Version History

  • Revision 1, 2017-02-15 (Eric Werness)

    • Internal revisions

VK_NV_compute_shader_derivatives

Name String

VK_NV_compute_shader_derivatives

Extension Type

Device extension

Registered Extension Number

202

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-19

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

Description

This extension adds Vulkan support for the SPV_NV_compute_shader_derivatives SPIR-V extension.

The SPIR-V extension provides two new execution modes, both of which allow compute shaders to use built-ins that evaluate compute derivatives explicitly or implicitly. Derivatives will be computed via differencing over a 2x2 group of shader invocations. The DerivativeGroupQuadsNV execution mode assembles shader invocations into 2x2 groups, where each group has x and y coordinates of the local invocation ID of the form (2m+{0,1}, 2n+{0,1}). The DerivativeGroupLinearNV execution mode assembles shader invocations into 2x2 groups, where each group has local invocation index values of the form 4m+{0,1,2,3}.

New Enum Constants

  • VK_NV_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME

  • VK_NV_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV

Issues

(1) Should we specify that the groups of four shader invocations used for derivatives in a compute shader are the same groups of four invocations that form a “quad” in shader subgroups?

RESOLVED: Yes.

Examples

None.

Version History

  • Revision 1, 2018-07-19 (Pat Brown)

    • Initial draft

VK_NV_cooperative_matrix

Name String

VK_NV_cooperative_matrix

Extension Type

Device extension

Registered Extension Number

250

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-02-05

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Markus Tavenrath, NVIDIA

  • Daniel Koch, NVIDIA

Description

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

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

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

New Enum Constants

  • VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME

  • VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION

  • Extending VkComponentTypeKHR:

    • VK_COMPONENT_TYPE_FLOAT16_NV

    • VK_COMPONENT_TYPE_FLOAT32_NV

    • VK_COMPONENT_TYPE_FLOAT64_NV

    • VK_COMPONENT_TYPE_SINT16_NV

    • VK_COMPONENT_TYPE_SINT32_NV

    • VK_COMPONENT_TYPE_SINT64_NV

    • VK_COMPONENT_TYPE_SINT8_NV

    • VK_COMPONENT_TYPE_UINT16_NV

    • VK_COMPONENT_TYPE_UINT32_NV

    • VK_COMPONENT_TYPE_UINT64_NV

    • VK_COMPONENT_TYPE_UINT8_NV

  • Extending VkScopeKHR:

    • VK_SCOPE_DEVICE_NV

    • VK_SCOPE_QUEUE_FAMILY_NV

    • VK_SCOPE_SUBGROUP_NV

    • VK_SCOPE_WORKGROUP_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV

New SPIR-V Capabilities

Issues

(1) What matrix properties will be supported in practice?

RESOLVED: In NVIDIA’s initial implementation, we will support:

  • AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x16 scope = Subgroup

  • AType = BType = fp16 CType = DType = fp16 MxNxK = 16x8x8 scope = Subgroup

  • AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x16 scope = Subgroup

  • AType = BType = fp16 CType = DType = fp32 MxNxK = 16x8x8 scope = Subgroup

Version History

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

    • Internal revisions

VK_NV_copy_memory_indirect

Name String

VK_NV_copy_memory_indirect

Extension Type

Device extension

Registered Extension Number

427

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-10-14

Contributors
  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension adds support for performing copies between memory and image regions using indirect parameters that are read by the device from a buffer during execution. This functionality may be useful for performing copies where the copy parameters are not known during the command buffer creation time.

New Enum Constants

  • VK_NV_COPY_MEMORY_INDIRECT_EXTENSION_NAME

  • VK_NV_COPY_MEMORY_INDIRECT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COPY_MEMORY_INDIRECT_PROPERTIES_NV

Version History

  • Revision 1, 2022-10-14 (Vikram Kushwaha)

    • Initial draft

VK_NV_corner_sampled_image

Name String

VK_NV_corner_sampled_image

Extension Type

Device extension

Registered Extension Number

51

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-08-13

Contributors
  • Jeff Bolz, NVIDIA

  • Pat Brown, NVIDIA

  • Chris Lentini, NVIDIA

Description

This extension adds support for a new image organization, which this extension refers to as “corner-sampled” images. A corner-sampled image differs from a conventional image in the following ways:

This image organization is designed to facilitate a system like Ptex with separate textures for each face of a subdivision or polygon mesh. Placing sample locations at pixel corners allows applications to maintain continuity between adjacent patches by duplicating values along shared edges. Additionally, using the modified mipmapping logic along with texture dimensions of the form 2n+1 allows continuity across shared edges even if the adjacent patches use different LOD values.

New Enum Constants

  • VK_NV_CORNER_SAMPLED_IMAGE_EXTENSION_NAME

  • VK_NV_CORNER_SAMPLED_IMAGE_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CORNER_SAMPLED_IMAGE_FEATURES_NV

Issues

  1. What should this extension be named?

    DISCUSSION: While naming this extension, we chose the most distinctive aspect of the image organization and referred to such images as “corner-sampled images”. As a result, we decided to name the extension NV_corner_sampled_image.

  2. Do we need a format feature flag so formats can advertise if they support corner-sampling?

    DISCUSSION: Currently NVIDIA supports this for all 2D and 3D formats, but not for cube maps or depth-stencil formats. A format feature might be useful if other vendors would only support this on some formats.

  3. Do integer texel coordinates have a different range for corner-sampled images?

    RESOLVED: No, these are unchanged.

  4. Do unnormalized sampler coordinates work with corner-sampled images? Are there any functional differences?

    RESOLVED: Yes. Unnormalized coordinates are treated as already scaled for corner-sample usage.

  5. Should we have a diagram in the “Image Operations” chapter demonstrating different texel sampling locations?

    UNRESOLVED: Probably, but later.

Version History

  • Revision 1, 2018-08-14 (Daniel Koch)

    • Internal revisions

  • Revision 2, 2018-08-14 (Daniel Koch)

    • ???

VK_NV_coverage_reduction_mode

Name String

VK_NV_coverage_reduction_mode

Extension Type

Device extension

Registered Extension Number

251

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-01-29

Contributors
  • Kedarnath Thangudu, NVIDIA

  • Jeff Bolz, NVIDIA

Description

When using a framebuffer with mixed samples, a per-fragment coverage reduction operation is performed which generates color sample coverage from the pixel coverage. This extension defines the following modes to control how this reduction is performed.

  • Merge: When there are more samples in the pixel coverage than color samples, there is an implementation-dependent association of each pixel coverage sample to a color sample. In the merge mode, the color sample coverage is computed such that only if any associated sample in the pixel coverage is covered, the color sample is covered. This is the default mode.

  • Truncate: When there are more raster samples (N) than color samples(M), there is one to one association of the first M raster samples to the M color samples; other raster samples are ignored.

When the number of raster samples is equal to the color samples, there is a one to one mapping between them in either of the above modes.

The new command vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV can be used to query the various raster, color, depth/stencil sample count and reduction mode combinations that are supported by the implementation. This extension would allow an implementation to support the behavior of both VK_NV_framebuffer_mixed_samples and VK_AMD_mixed_attachment_samples extensions simultaneously.

New Enum Constants

  • VK_NV_COVERAGE_REDUCTION_MODE_EXTENSION_NAME

  • VK_NV_COVERAGE_REDUCTION_MODE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_MIXED_SAMPLES_COMBINATION_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COVERAGE_REDUCTION_MODE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_REDUCTION_STATE_CREATE_INFO_NV

Version History

  • Revision 1, 2019-01-29 (Kedarnath Thangudu)

    • Internal revisions

VK_NV_dedicated_allocation_image_aliasing

Name String

VK_NV_dedicated_allocation_image_aliasing

Extension Type

Device extension

Registered Extension Number

241

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-01-04

Contributors
  • Nuno Subtil, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Axel Gneiting, id Software

Description

This extension allows applications to alias images on dedicated allocations, subject to specific restrictions: the extent and the number of layers in the image being aliased must be smaller than or equal to those of the original image for which the allocation was created, and every other image parameter must match.

New Enum Constants

  • VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_EXTENSION_NAME

  • VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEDICATED_ALLOCATION_IMAGE_ALIASING_FEATURES_NV

Version History

  • Revision 1, 2019-01-04 (Nuno Subtil)

    • Internal revisions

VK_NV_device_diagnostic_checkpoints

Name String

VK_NV_device_diagnostic_checkpoints

Extension Type

Device extension

Registered Extension Number

207

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-16

Contributors
  • Oleg Kuznetsov, NVIDIA

  • Alex Dunn, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension allows applications to insert markers in the command stream and associate them with custom data.

If a device lost error occurs, the application may then query the implementation for the last markers to cross specific implementation-defined pipeline stages, in order to narrow down which commands were executing at the time and might have caused the failure.

New Enum Constants

  • VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_EXTENSION_NAME

  • VK_NV_DEVICE_DIAGNOSTIC_CHECKPOINTS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV

Version History

  • Revision 1, 2018-07-16 (Nuno Subtil)

    • Internal revisions

  • Revision 2, 2018-07-16 (Nuno Subtil)

    • ???

VK_NV_device_diagnostics_config

Name String

VK_NV_device_diagnostics_config

Extension Type

Device extension

Registered Extension Number

301

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-04-06

Contributors
  • Kedarnath Thangudu, NVIDIA

  • Thomas Klein, NVIDIA

Description

Applications using Nvidia Nsight Aftermath SDK for Vulkan to integrate device crash dumps into their error reporting mechanisms, may use this extension to configure options related to device crash dump creation.

Version 2 of this extension adds VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV which when set enables enhanced reporting of shader execution errors.

New Enum Constants

  • VK_NV_DEVICE_DIAGNOSTICS_CONFIG_EXTENSION_NAME

  • VK_NV_DEVICE_DIAGNOSTICS_CONFIG_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_DIAGNOSTICS_CONFIG_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DIAGNOSTICS_CONFIG_FEATURES_NV

Version History

  • Revision 1, 2019-11-21 (Kedarnath Thangudu)

    • Internal revisions

  • Revision 2, 2022-04-06 (Kedarnath Thangudu)

    • Added a config bit VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV

VK_NV_device_generated_commands

Name String

VK_NV_device_generated_commands

Extension Type

Device extension

Registered Extension Number

278

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-02-20

Interactions and External Dependencies
  • This extension requires Vulkan 1.1

  • This extension requires VK_EXT_buffer_device_address or VK_KHR_buffer_device_address or Vulkan 1.2 for the ability to bind vertex and index buffers on the device.

  • This extension interacts with VK_NV_mesh_shader. If the latter extension is not supported, remove the command token to initiate mesh tasks drawing in this extension.

Contributors
  • Christoph Kubisch, NVIDIA

  • Pierre Boudier, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

  • Yuriy O’Donnell, Epic Games

  • Baldur Karlsson, Valve

  • Mathias Schott, NVIDIA

  • Tyson Smith, NVIDIA

  • Ingo Esser, NVIDIA

Description

This extension allows the device to generate a number of critical graphics commands for command buffers.

When rendering a large number of objects, the device can be leveraged to implement a number of critical functions, like updating matrices, or implementing occlusion culling, frustum culling, front to back sorting, etc. Implementing those on the device does not require any special extension, since an application is free to define its own data structures, and just process them using shaders.

However, if the application desires to quickly kick off the rendering of the final stream of objects, then unextended Vulkan forces the application to read back the processed stream and issue graphics command from the host. For very large scenes, the synchronization overhead and cost to generate the command buffer can become the bottleneck. This extension allows an application to generate a device side stream of state changes and commands, and convert it efficiently into a command buffer without having to read it back to the host.

Furthermore, it allows incremental changes to such command buffers by manipulating only partial sections of a command stream — for example pipeline bindings. Unextended Vulkan requires re-creation of entire command buffers in such a scenario, or updates synchronized on the host.

The intended usage for this extension is for the application to:

  • create VkBuffer objects and retrieve physical addresses from them via vkGetBufferDeviceAddressEXT

  • create a graphics pipeline using VkGraphicsPipelineShaderGroupsCreateInfoNV for the ability to change shaders on the device.

  • create a VkIndirectCommandsLayoutNV, which lists the VkIndirectCommandsTokenTypeNV it wants to dynamically execute as an atomic command sequence. This step likely involves some internal device code compilation, since the intent is for the GPU to generate the command buffer in the pipeline.

  • fill the input stream buffers with the data for each of the inputs it needs. Each input is an array that will be filled with token-dependent data.

  • set up a preprocess VkBuffer that uses memory according to the information retrieved via vkGetGeneratedCommandsMemoryRequirementsNV.

  • optionally preprocess the generated content using vkCmdPreprocessGeneratedCommandsNV, for example on an asynchronous compute queue, or for the purpose of re-using the data in multiple executions.

  • call vkCmdExecuteGeneratedCommandsNV to create and execute the actual device commands for all sequences based on the inputs provided.

For each draw in a sequence, the following can be specified:

  • a different shader group

  • a number of vertex buffer bindings

  • a different index buffer, with an optional dynamic offset and index type

  • a number of different push constants

  • a flag that encodes the primitive winding

While the GPU can be faster than a CPU to generate the commands, it will not happen asynchronously to the device, therefore the primary use case is generating “less” total work (occlusion culling, classification to use specialized shaders, etc.).

New Object Types

New Enum Constants

  • VK_NV_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME

  • VK_NV_DEVICE_GENERATED_COMMANDS_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV

    • VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NV

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_INDIRECT_BINDABLE_BIT_NV

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_NV

    • VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_NV

    • VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_SHADER_GROUPS_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_GRAPHICS_SHADER_GROUP_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_NV

Issues

1) How to name this extension ?

VK_NV_device_generated_commands

As usual, one of the hardest issues ;)

Alternatives: VK_gpu_commands, VK_execute_commands, VK_device_commands, VK_device_execute_commands, VK_device_execute, VK_device_created_commands, VK_device_recorded_commands, VK_device_generated_commands VK_indirect_generated_commands

2) Should we use a serial stateful token stream or stateless sequence descriptions?

Similarly to VkPipeline, fixed layouts have the most likelihood to be cross-vendor adoptable. They also benefit from being processable in parallel. This is a different design choice compared to the serial command stream generated through GL_NV_command_list.

3) How to name a sequence description?

VkIndirectCommandsLayout as in the NVX extension predecessor.

Alternative: VkGeneratedCommandsLayout

4) Do we want to provide indirectCommands inputs with layout or at indirectCommands time?

Separate layout from data as Vulkan does. Provide full flexibility for indirectCommands.

5) Should the input be provided as SoA or AoS?

Both ways are desirable. AoS can provide portability to other APIs and easier to setup, while SoA allows to update individual inputs in a cache-efficient manner, when others remain static.

6) How do we make developers aware of the memory requirements of implementation-dependent data used for the generated commands?

Make the API explicit and introduce a preprocess VkBuffer. Developers have to allocate it using vkGetGeneratedCommandsMemoryRequirementsNV.

In the NVX version the requirements were hidden implicitly as part of the command buffer reservation process, however as the memory requirements can be substantial, we want to give developers the ability to budget the memory themselves. By lowering the maxSequencesCount the memory consumption can be reduced. Furthermore reuse of the memory is possible, for example for doing explicit preprocessing and execution in a ping-pong fashion.

The actual buffer size is implementation-dependent and may be zero, i.e. not always required.

When making use of Graphics Shader Groups, the programs should behave similar with regards to vertex inputs, clipping and culling outputs of the geometry stage, as well as sample shading behavior in fragment shaders, to reduce the amount of the worst-case memory approximation.

7) Should we allow additional per-sequence dynamic state changes?

Yes

Introduced a lightweight indirect state flag VkIndirectStateFlagBitsNV. So far only switching front face winding state is exposed. Especially in CAD/DCC mirrored transforms that require such changes are common, and similar flexibility is given in the ray tracing instance description.

The flag could be extended further, for example to switch between primitive-lists or -strips, or make other state modifications.

Furthermore, as new tokens can be added easily, future extension could add the ability to change any VkDynamicState.

8) How do we allow re-using already “generated” indirectCommands?

Expose a preprocessBuffer to reuse implementation-dependencyFlags data. Set the isPreprocessed to true in vkCmdExecuteGeneratedCommandsNV.

9) Under which conditions is vkCmdExecuteGeneratedCommandsNV legal?

It behaves like a regular draw call command.

10) Is vkCmdPreprocessGeneratedCommandsNV copying the input data or referencing it?

There are multiple implementations possible:

  • one could have some emulation code that parses the inputs, and generates an output command buffer, therefore copying the inputs.

  • one could just reference the inputs, and have the processing done in pipe at execution time.

If the data is mandated to be copied, then it puts a penalty on implementation that could process the inputs directly in pipe. If the data is “referenced”, then it allows both types of implementation.

The inputs are “referenced”, and must not be modified after the call to vkCmdExecuteGeneratedCommandsNV has completed.

11) Which buffer usage flags are required for the buffers referenced by VkGeneratedCommandsInfoNV ?

Reuse existing VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT

12) In which pipeline stage does the device generated command expansion happen?

vkCmdPreprocessGeneratedCommandsNV is treated as if it occurs in a separate logical pipeline from either graphics or compute, and that pipeline only includes VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, a new stage VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV, and VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT. This new stage has two corresponding new access types, VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV and VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV, used to synchronize reading the buffer inputs and writing the preprocess memory output.

The generated output written in the preprocess buffer memory by vkCmdExecuteGeneratedCommandsNV is considered to be consumed by the VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT pipeline stage.

Thus, to synchronize from writing the input buffers to preprocessing via vkCmdPreprocessGeneratedCommandsNV, use:

  • dstStageMask = VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • dstAccessMask = VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV

To synchronize from vkCmdPreprocessGeneratedCommandsNV to executing the generated commands by vkCmdExecuteGeneratedCommandsNV, use:

  • srcStageMask = VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV

  • srcAccessMask = VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV

  • dstStageMask = VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

  • dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT

When vkCmdExecuteGeneratedCommandsNV is used with a isPreprocessed of VK_FALSE, the generated commands are implicitly preprocessed, therefore one only needs to synchronize the inputs via:

  • dstStageMask = VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT

  • dstAccessMask = VK_ACCESS_INDIRECT_COMMAND_READ_BIT

13) What if most token data is “static”, but we frequently want to render a subsection?

Added “sequencesIndexBuffer”. This allows to easier sort and filter what should actually be executed.

14) What are the changes compared to the previous NVX extension?

  • Compute dispatch support was removed (was never implemented in drivers). There are different approaches how dispatching from the device should work, hence we defer this to a future extension.

  • The ObjectTableNVX was replaced by using physical buffer addresses and introducing Shader Groups for the graphics pipeline.

  • Less state changes are possible overall, but the important operations are still there (reduces complexity of implementation).

  • The API was redesigned so all inputs must be passed at both preprocessing and execution time (this was implicit in NVX, now it is explicit)

  • The reservation of intermediate command space is now mandatory and explicit through a preprocess buffer.

  • The VkIndirectStateFlagBitsNV were introduced

15) When porting from other APIs, their indirect buffers may use different enums, for example for index buffer types. How to solve this?

Added “pIndexTypeValues” to map custom uint32_t values to corresponding VkIndexType.

16) Do we need more shader group state overrides?

The NVX version allowed all PSO states to be different, however as the goal is not to replace all state setup, but focus on highly-frequent state changes for drawing lots of objects, we reduced the amount of state overrides. Especially VkPipelineLayout as well as VkRenderPass configuration should be left static, the rest is still open for discussion.

The current focus is just to allow VertexInput changes as well as shaders, while all shader groups use the same shader stages.

Too much flexibility will increase the test coverage requirement as well. However, further extensions could allow more dynamic state as well.

17) Do we need more detailed physical device feature queries/enables?

An EXT version would need detailed implementor feedback to come up with a good set of features. Please contact us if you are interested, we are happy to make more features optional, or add further restrictions to reduce the minimum feature set of an EXT.

18) Is there an interaction with VK_KHR_pipeline_library planned?

Yes, a future version of this extension will detail the interaction, once VK_KHR_pipeline_library is no longer provisional.

Example Code

Open-Source samples illustrating the usage of the extension can be found at the following location (may not yet exist at time of writing):

Version History

  • Revision 1, 2020-02-20 (Christoph Kubisch)

    • Initial version

  • Revision 2, 2020-03-09 (Christoph Kubisch)

    • Remove VK_EXT_debug_report interactions

  • Revision 3, 2020-03-09 (Christoph Kubisch)

    • Fix naming VkPhysicalDeviceGenerated to VkPhysicalDeviceDeviceGenerated

VK_NV_external_memory_rdma

Name String

VK_NV_external_memory_rdma

Extension Type

Device extension

Registered Extension Number

372

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-04-19

IP Status

No known IP claims.

Contributors
  • Carsten Rohde, NVIDIA

Description

This extension adds support for allocating memory which can be used for remote direct memory access (RDMA) from other devices.

New Base Types

New Enum Constants

  • VK_NV_EXTERNAL_MEMORY_RDMA_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_RDMA_SPEC_VERSION

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV

  • Extending VkMemoryPropertyFlagBits:

    • VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_RDMA_FEATURES_NV

Issues

Examples

VkPhysicalDeviceMemoryBudgetPropertiesEXT memoryBudgetProperties = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT };
VkPhysicalDeviceMemoryProperties2 memoryProperties2 = { VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2, &memoryBudgetProperties };
vkGetPhysicalDeviceMemoryProperties2(physicalDevice, &memoryProperties2);
uint32_t heapIndex = (uint32_t)-1;
for (uint32_t memoryType = 0; memoryType < memoryProperties2.memoryProperties.memoryTypeCount; memoryType++) {
    if (memoryProperties2.memoryProperties.memoryTypes[memoryType].propertyFlags & VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV) {
        heapIndex = memoryProperties2.memoryProperties.memoryTypes[memoryType].heapIndex;
        break;
    }
}
if ((heapIndex == (uint32_t)-1) ||
    (memoryBudgetProperties.heapBudget[heapIndex] < size)) {
    return;
}

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

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

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

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

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

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

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

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

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

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

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

VkRemoteAddressNV rdmaAddress;
vkGetMemoryRemoteAddressNV(device, &getMemoryRemoteAddressInfo, &rdmaAddress);
// address returned in 'rdmaAddress' can be used by external devices to initiate RDMA transfers

Version History

  • Revision 1, 2020-12-15 (Carsten Rohde)

    • Internal revisions

VK_NV_fill_rectangle

Name String

VK_NV_fill_rectangle

Extension Type

Device extension

Registered Extension Number

154

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-05-22

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension adds a new VkPolygonMode enum where a triangle is rasterized by computing and filling its axis-aligned screen-space bounding box, disregarding the actual triangle edges. This can be useful for drawing a rectangle without being split into two triangles with an internal edge. It is also useful to minimize the number of primitives that need to be drawn, particularly for a user interface.

New Enum Constants

  • VK_NV_FILL_RECTANGLE_EXTENSION_NAME

  • VK_NV_FILL_RECTANGLE_SPEC_VERSION

  • Extending VkPolygonMode:

    • VK_POLYGON_MODE_FILL_RECTANGLE_NV

Version History

  • Revision 1, 2017-05-22 (Jeff Bolz)

    • Internal revisions

VK_NV_fragment_coverage_to_color

Name String

VK_NV_fragment_coverage_to_color

Extension Type

Device extension

Registered Extension Number

150

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-05-21

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension allows the fragment coverage value, represented as an integer bitmask, to be substituted for a color output being written to a single-component color attachment with integer components (e.g. VK_FORMAT_R8_UINT). The functionality provided by this extension is different from simply writing the SampleMask fragment shader output, in that the coverage value written to the framebuffer is taken after stencil test and depth test, as well as after fragment operations such as alpha-to-coverage.

This functionality may be useful for deferred rendering algorithms, where the second pass needs to know which samples belong to which original fragments.

New Enum Constants

  • VK_NV_FRAGMENT_COVERAGE_TO_COLOR_EXTENSION_NAME

  • VK_NV_FRAGMENT_COVERAGE_TO_COLOR_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_TO_COLOR_STATE_CREATE_INFO_NV

Version History

  • Revision 1, 2017-05-21 (Jeff Bolz)

    • Internal revisions

VK_NV_fragment_shading_rate_enums

Name String

VK_NV_fragment_shading_rate_enums

Extension Type

Device extension

Registered Extension Number

327

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-09-02

Contributors
  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension builds on the fragment shading rate functionality provided by the VK_KHR_fragment_shading_rate extension, adding support for “supersample” fragment shading rates that trigger multiple fragment shader invocations per pixel as well as a “no invocations” shading rate that discards any portions of a primitive that would use that shading rate.

New Enum Constants

  • VK_NV_FRAGMENT_SHADING_RATE_ENUMS_EXTENSION_NAME

  • VK_NV_FRAGMENT_SHADING_RATE_ENUMS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_ENUM_STATE_CREATE_INFO_NV

Issues

  1. Why was this extension created? How should it be named?

    RESOLVED: The primary goal of this extension was to expose support for supersample and “no invocations” shading rates, which are supported by the VK_NV_shading_rate_image extension but not by VK_KHR_fragment_shading_rate. Because VK_KHR_fragment_shading_rate specifies the primitive shading rate using a fragment size in pixels, it lacks a good way to specify supersample rates. To deal with this, we defined enums covering shading rates supported by the KHR extension as well as the new shading rates and added structures and APIs accepting shading rate enums instead of fragment sizes.

    Since this extension adds two different types of shading rates, both expressed using enums, we chose the extension name VK_NV_fragment_shading_rate_enums.

  2. Is this a standalone extension?

    RESOLVED: No, this extension requires VK_KHR_fragment_shading_rate. In order to use the features of this extension, applications must enable the relevant features of KHR extension.

  3. How are the shading rate enums used, and how were the enum values assigned?

    RESOLVED: The shading rates supported by the enums in this extension are accepted as pipeline, primitive, and attachment shading rates and behave identically. For the shading rates also supported by the KHR extension, the values assigned to the corresponding enums are identical to the values already used for the primitive and attachment shading rates in the KHR extension. For those enums, bits 0 and 1 specify the base two logarithm of the fragment height and bits 2 and 3 specify the base two logarithm of the fragment width. For the new shading rates added by this extension, we chose to use 11 through 14 (10 plus the base two logarithm of the invocation count) for the supersample rates and 15 for the “no invocations” rate. None of those values are supported as primitive or attachment shading rates by the KHR extension.

  4. Between this extension, VK_KHR_fragment_shading_rate, and VK_NV_shading_rate_image, there are three different ways to specify shading rate state in a pipeline. How should we handle this?

    RESOLVED: We do not allow the concurrent use of VK_NV_shading_rate_image and VK_KHR_fragment_shading_rate; it is an error to enable shading rate features from both extensions. But we do allow applications to enable this extension together with VK_KHR_fragment_shading_rate together. While we expect that applications will never attach pipeline CreateInfo structures for both this extension and the KHR extension concurrently, Vulkan does not have any precedent forbidding such behavior and instead typically treats a pipeline created without an extension-specific CreateInfo structure as equivalent to one containing default values specified by the extension. Rather than adding such a rule considering the presence or absence of our new CreateInfo structure, we instead included a shadingRateType member to VkPipelineFragmentShadingRateEnumStateCreateInfoNV that selects between using state specified by that structure and state specified by VkPipelineFragmentShadingRateStateCreateInfoKHR.

Version History

  • Revision 1, 2020-09-02 (pbrown)

    • Internal revisions

VK_NV_framebuffer_mixed_samples

Name String

VK_NV_framebuffer_mixed_samples

Extension Type

Device extension

Registered Extension Number

153

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-06-04

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension allows multisample rendering with a raster and depth/stencil sample count that is larger than the color sample count. Rasterization and the results of the depth and stencil tests together determine the portion of a pixel that is “covered”. It can be useful to evaluate coverage at a higher frequency than color samples are stored. This coverage is then “reduced” to a collection of covered color samples, each having an opacity value corresponding to the fraction of the color sample covered. The opacity can optionally be blended into individual color samples.

Rendering with fewer color samples than depth/stencil samples greatly reduces the amount of memory and bandwidth consumed by the color buffer. However, converting the coverage values into opacity introduces artifacts where triangles share edges and may not be suitable for normal triangle mesh rendering.

One expected use case for this functionality is Stencil-then-Cover path rendering (similar to the OpenGL GL_NV_path_rendering extension). The stencil step determines the coverage (in the stencil buffer) for an entire path at the higher sample frequency, and then the cover step draws the path into the lower frequency color buffer using the coverage information to antialias path edges. With this two-step process, internal edges are fully covered when antialiasing is applied and there is no corruption on these edges.

The key features of this extension are:

  • It allows render pass and framebuffer objects to be created where the number of samples in the depth/stencil attachment in a subpass is a multiple of the number of samples in the color attachments in the subpass.

  • A coverage reduction step is added to Fragment Operations which converts a set of covered raster/depth/stencil samples to a set of color samples that perform blending and color writes. The coverage reduction step also includes an optional coverage modulation step, multiplying color values by a fractional opacity corresponding to the number of associated raster/depth/stencil samples covered.

New Enum Constants

  • VK_NV_FRAMEBUFFER_MIXED_SAMPLES_EXTENSION_NAME

  • VK_NV_FRAMEBUFFER_MIXED_SAMPLES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV

Version History

  • Revision 1, 2017-06-04 (Jeff Bolz)

    • Internal revisions

VK_NV_geometry_shader_passthrough

Name String

VK_NV_geometry_shader_passthrough

Extension Type

Device extension

Registered Extension Number

96

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-02-15

Interactions and External Dependencies
Contributors
  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

Description

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

  • SPV_NV_geometry_shader_passthrough

Geometry shaders provide the ability for applications to process each primitive sent through the graphics pipeline using a programmable shader. However, one common use case treats them largely as a “passthrough”. In this use case, the bulk of the geometry shader code simply copies inputs from each vertex of the input primitive to corresponding outputs in the vertices of the output primitive. Such shaders might also compute values for additional built-in or user-defined per-primitive attributes (e.g., Layer) to be assigned to all the vertices of the output primitive.

This extension provides access to the PassthroughNV decoration under the GeometryShaderPassthroughNV capability. Adding this to a geometry shader input variable specifies that the values of this input are copied to the corresponding vertex of the output primitive.

When using GLSL source-based shading languages, the passthrough layout qualifier from GL_NV_geometry_shader_passthrough maps to the PassthroughNV decoration. To use the passthrough layout, in GLSL the GL_NV_geometry_shader_passthrough extension must be enabled. Behaviour is described in the GL_NV_geometry_shader_passthrough extension specification.

New Enum Constants

  • VK_NV_GEOMETRY_SHADER_PASSTHROUGH_EXTENSION_NAME

  • VK_NV_GEOMETRY_SHADER_PASSTHROUGH_SPEC_VERSION

New Variable Decoration

New SPIR-V Capabilities

Issues

1) Should we require or allow a passthrough geometry shader to specify the output layout qualifiers for the output primitive type and maximum vertex count in the SPIR-V?

RESOLVED: Yes they should be required in the SPIR-V. Per GL_NV_geometry_shader_passthrough they are not permitted in the GLSL source shader, but SPIR-V is lower-level. It is straightforward for the GLSL compiler to infer them from the input primitive type and to explicitly emit them in the SPIR-V according to the following table.

Input Layout Implied Output Layout

points

layout(points, max_vertices=1)

lines

layout(line_strip, max_vertices=2)

triangles

layout(triangle_strip, max_vertices=3)

2) How does interface matching work with passthrough geometry shaders?

RESOLVED: This is described in Passthrough Interface Matching. In GL when using passthough geometry shaders in separable mode, all inputs must also be explicitly assigned location layout qualifiers. In Vulkan all SPIR-V shader inputs (except built-ins) must also have location decorations specified. Redeclarations of built-in variables that add the passthrough layout qualifier are exempted from the rule requiring location assignment because built-in variables do not have locations and are matched by BuiltIn decoration.

Sample Code

Consider the following simple geometry shader in unextended GLSL:

layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices=3) out;

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

void main()
{
    int layer = compute_layer();
    for (int i = 0; i < 3; i++) {
        gl_Position = gl_in[i].gl_Position;
        texcoord = v_in[i].texcoord;
        baseColor = v_in[i].baseColor;
        gl_Layer = layer;
        EmitVertex();
    }
}

In this shader, the inputs gl_Position, Inputs.texcoord, and Inputs.baseColor are simply copied from the input vertex to the corresponding output vertex. The only “interesting” work done by the geometry shader is computing and emitting a gl_Layer value for the primitive.

The following geometry shader, using this extension, is equivalent:

#extension GL_NV_geometry_shader_passthrough : require

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

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

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

// No output block declaration required.

void main()
{
    // The shader simply computes and writes gl_Layer.  We do not
    // loop over three vertices or call EmitVertex().
    gl_Layer = compute_layer();
}

Version History

  • Revision 1, 2017-02-15 (Daniel Koch)

    • Internal revisions

VK_NV_inherited_viewport_scissor

Name String

VK_NV_inherited_viewport_scissor

Extension Type

Device extension

Registered Extension Number

279

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-02-04

Contributors
  • David Zhao Akeley, NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Christoph Kubisch, NVIDIA

Description

This extension adds the ability for a secondary command buffer to inherit the dynamic viewport and scissor state from a primary command buffer, or a previous secondary command buffer executed within the same vkCmdExecuteCommands call. It addresses a frequent scenario in applications that deal with window resizing and want to improve utilization of re-usable secondary command buffers. The functionality is provided through VkCommandBufferInheritanceViewportScissorInfoNV. Viewport inheritance is effectively limited to the 2D rectangle; secondary command buffers must re-specify the inherited depth range values.

New Enum Constants

  • VK_NV_INHERITED_VIEWPORT_SCISSOR_EXTENSION_NAME

  • VK_NV_INHERITED_VIEWPORT_SCISSOR_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_VIEWPORT_SCISSOR_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INHERITED_VIEWPORT_SCISSOR_FEATURES_NV

Issues

(1) Why are viewport depth values configured in the VkCommandBufferInheritanceViewportScissorInfoNV struct, rather than by a vkCmd…​ function?

DISCUSSION:

We considered both adding a new vkCmdSetViewportDepthNV function, and modifying vkCmdSetViewport to ignore the x, y, width, and height values when called with a secondary command buffer that activates this extension.

The primary design considerations for this extension are debuggability and easy integration into existing applications. The main issue with adding a new vkCmdSetViewportDepthNV function is reducing ease-of-integration. A new function pointer will have to be loaded, but more importantly, a new function would require changes to be supported in graphics debuggers; this would delay widespread adoption of the extension.

The proposal to modify vkCmdSetViewport would avoid these issues. However, we expect that the intent of applications using this extension is to have the viewport values used for drawing exactly match the inherited values; thus, it would be better for debuggability if no function for modifying the viewport depth alone is provided. By specifying viewport depth values when starting secondary command buffer recording, and requiring the specified depth values to match the inherited depth values, we allow for validation layers that flag depth changes as errors.

This design also better matches the hardware model. In fact, there is no need to re-execute a depth-setting command. The graphics device retains the viewport depth state; it is the CPU-side state of VkCommandBuffer that must be re-initialized.

(2) Why are viewport depth values specified as a partial VkViewport struct, rather than a leaner depth-only struct?

DISCUSSION:

We considered adding a new VkViewportDepthNV struct containing only minDepth and maxDepth. However, as application developers would need to maintain both a VK_NV_inherited_viewport_scissor code path and a fallback code path (at least in the short term), we ultimately chose to continue using the existing VkViewport structure. Doing so would allow application developers to reuse the same VkViewport array for both code paths, rather than constructing separate VkViewportDepthNV and VkViewport arrays for each code path.

Version History

  • Revision 1, 2020-02-04 (David Zhao Akeley)

    • Internal revisions

VK_NV_linear_color_attachment

Name String

VK_NV_linear_color_attachment

Extension Type

Device extension

Registered Extension Number

431

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-12-02

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

  • Piers Daniell, NVIDIA

  • Sourav Parmar, NVIDIA

Description

This extension expands support for using VK_IMAGE_TILING_LINEAR images as color attachments when all the color attachments in the render pass instance have VK_IMAGE_TILING_LINEAR tiling. This extension adds a new flag bit VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV that extends the existing VkFormatFeatureFlagBits2KHR bits. This flag can be set for renderable color formats in the VkFormatProperties3KHR::linearTilingFeatures format properties structure member. Formats with the VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV flag may be used as color attachments as long as all the color attachments in the render pass instance have VK_IMAGE_TILING_LINEAR tiling, and the formats their images views are created with have VkFormatProperties3KHR::linearTilingFeatures which include VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV. This extension supports both dynamic rendering and traditional render passes.

New Enum Constants

  • VK_NV_LINEAR_COLOR_ATTACHMENT_EXTENSION_NAME

  • VK_NV_LINEAR_COLOR_ATTACHMENT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINEAR_COLOR_ATTACHMENT_FEATURES_NV

If VK_KHR_format_feature_flags2 is supported:

Version History

  • Revision 1, 2021-11-29 (sourav parmar)

    • Initial draft

VK_NV_low_latency

Name String

VK_NV_low_latency

Extension Type

Device extension

Registered Extension Number

311

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2023-02-10

Contributors
  • Charles Hansen, NVIDIA

Description

This extension adds the VkQueryLowLatencySupportNV structure, a structure used to query support for NVIDIA Reflex.

New Enum Constants

  • VK_NV_LOW_LATENCY_EXTENSION_NAME

  • VK_NV_LOW_LATENCY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_QUERY_LOW_LATENCY_SUPPORT_NV

Issues

1) Why does VkQueryLowLatencySupportNV have output parameters in an input chain?

RESOLVED: We are stuck with this for legacy reasons - we are aware this is bad behavior and this should not be used as a precedent for future extensions.

Version History

  • Revision 1, 2023-02-10 (Charles Hansen)

    • Internal revisions

VK_NV_memory_decompression

Name String

VK_NV_memory_decompression

Extension Type

Device extension

Registered Extension Number

428

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-01-31

Contributors
  • Vikram Kushwaha, NVIDIA

  • Jeff Bolz, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Piers Daniell, NVIDIA

Description

This extension adds support for performing memory to memory decompression.

New Enum Constants

  • VK_NV_MEMORY_DECOMPRESSION_EXTENSION_NAME

  • VK_NV_MEMORY_DECOMPRESSION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_DECOMPRESSION_PROPERTIES_NV

Version History

  • Revision 1, 2022-01-31 (Vikram Kushwaha)

    • Initial draft

VK_NV_mesh_shader

Name String

VK_NV_mesh_shader

Extension Type

Device extension

Registered Extension Number

203

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-07-19

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Piers Daniell, NVIDIA

  • Pierre Boudier, NVIDIA

Description

This extension provides a new mechanism allowing applications to generate collections of geometric primitives via programmable mesh shading. It is an alternative to the existing programmable primitive shading pipeline, which relied on generating input primitives by a fixed function assembler as well as fixed function vertex fetch.

There are new programmable shader types — the task and mesh shader — to generate these collections to be processed by fixed-function primitive assembly and rasterization logic. When task and mesh shaders are dispatched, they replace the core pre-rasterization stages, including vertex array attribute fetching, vertex shader processing, tessellation, and geometry shader processing.

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

New Enum Constants

  • VK_NV_MESH_SHADER_EXTENSION_NAME

  • VK_NV_MESH_SHADER_SPEC_VERSION

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_MESH_SHADER_BIT_NV

    • VK_PIPELINE_STAGE_TASK_SHADER_BIT_NV

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_MESH_BIT_NV

    • VK_SHADER_STAGE_TASK_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV

New or Modified Built-In Variables

New SPIR-V Capability

Issues

  1. How to name this extension?

    RESOLVED: VK_NV_mesh_shader

    Other options considered:

    • VK_NV_mesh_shading

    • VK_NV_programmable_mesh_shading

    • VK_NV_primitive_group_shading

    • VK_NV_grouped_drawing

  2. Do we need a new VkPrimitiveTopology?

    RESOLVED: No. We skip the InputAssembler stage.

  3. Should we allow Instancing?

    RESOLVED: No. There is no fixed function input, other than the IDs. However, allow offsetting with a “first” value.

  4. Should we use existing vkCmdDraw or introduce new functions?

    RESOLVED: Introduce new functions.

    New functions make it easier to separate from “programmable primitive shading” chapter, less “dual use” language about existing functions having alternative behavior. The text around the existing “draws” is heavily based around emitting vertices.

  5. If new functions, how to name?

    RESOLVED: CmdDrawMeshTasks*

    Other options considered:

    • CmdDrawMeshed

    • CmdDrawTasked

    • CmdDrawGrouped

  6. Should VK_SHADER_STAGE_ALL_GRAPHICS be updated to include the new stages?

    RESOLVED: No. If an application were to be recompiled with headers that include additional shader stage bits in VK_SHADER_STAGE_ALL_GRAPHICS, then the previously valid application would no longer be valid on implementations that do not support mesh or task shaders. This means the change would not be backwards compatible. It is too bad VkShaderStageFlagBits does not have a dedicated “all supported graphics stages” bit like VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT, which would have avoided this problem.

Version History

  • Revision 1, 2018-07-19 (Christoph Kubisch, Daniel Koch)

    • Internal revisions

VK_NV_optical_flow

Name String

VK_NV_optical_flow

Extension Type

Device extension

Registered Extension Number

465

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-09-26

Contributors
  • Carsten Rohde, NVIDIA

  • Vipul Parashar, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

Description

Optical flow are fundamental algorithms in computer vision (CV) area. This extension allows applications to estimate 2D displacement of pixels between two frames.

Note

This extension is designed to be used with upcoming NVIDIA Optical Flow SDK Version 5 which will be available on NVIDIA Developer webpage.

New Object Types

New Enum Constants

  • VK_NV_OPTICAL_FLOW_EXTENSION_NAME

  • VK_NV_OPTICAL_FLOW_SPEC_VERSION

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_OPTICAL_FLOW_READ_BIT_NV

    • VK_ACCESS_2_OPTICAL_FLOW_WRITE_BIT_NV

  • Extending VkFormat:

    • VK_FORMAT_R16G16_S10_5_NV

  • Extending VkFormatFeatureFlagBits2:

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_COST_BIT_NV

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_IMAGE_BIT_NV

    • VK_FORMAT_FEATURE_2_OPTICAL_FLOW_VECTOR_BIT_NV

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_OPTICAL_FLOW_SESSION_NV

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_OPTICAL_FLOW_BIT_NV

  • Extending VkQueueFlagBits:

    • VK_QUEUE_OPTICAL_FLOW_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_EXECUTE_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_OPTICAL_FLOW_SESSION_CREATE_PRIVATE_DATA_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_OPTICAL_FLOW_PROPERTIES_NV

Examples

// Example querying available input formats
VkOpticalFlowImageFormatInfoNV ofFormatInfo = { VK_STRUCTURE_TYPE_OPTICAL_FLOW_IMAGE_FORMAT_INFO_NV };
ofFormatInfo.usage = VK_OPTICAL_FLOW_USAGE_INPUT_BIT_NV;

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

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

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

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

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

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

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

"do the same for reference and output"

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

"allocate command buffer"

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

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

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

"submit command buffer"

Version History

  • Revision 1, 2022-09-26 (Carsten Rohde)

    • Internal revisions

VK_NV_present_barrier

Name String

VK_NV_present_barrier

Extension Type

Device extension

Registered Extension Number

293

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-05-16

Contributors
  • Liya Li, Nvidia

  • Martin Schwarzer, Nvidia

  • Andy Wolf, Nvidia

  • Ian Williams, Nvidia

  • Ben Morris, Nvidia

  • James Jones, Nvidia

  • Jeff Juliano, Nvidia

Description

This extension adds support for synchronizing corresponding presentation requests across multiple swapchains using the present barrier.

New Enum Constants

  • VK_NV_PRESENT_BARRIER_EXTENSION_NAME

  • VK_NV_PRESENT_BARRIER_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_BARRIER_FEATURES_NV

    • VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_PRESENT_BARRIER_NV

    • VK_STRUCTURE_TYPE_SWAPCHAIN_PRESENT_BARRIER_CREATE_INFO_NV

Issues

1) Is there a query interface to check if a swapchain is using the present barrier?

RESOLVED. There is no such query interface. When creating a swapchain, an application can specify to use the present barrier, and if the swapchain is created successfully, this swapchain will be using the present barrier.

2) Do we need an extra interface to set up the present barrier across distributed systems?

RESOLVED. If the required hardware is presented in the system, and all settings for the physical synchronization with other systems are set up, an implementation manages the configuration automatically when creating a swapchain, without any extra calls from the application.

Version History

  • Revision 1, 2022-07-20

    • Initial version

VK_NV_ray_tracing

Name String

VK_NV_ray_tracing

Extension Type

Device extension

Registered Extension Number

166

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-11-20

Interactions and External Dependencies
Contributors
  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

  • Robert Stepinski, NVIDIA

  • Nuno Subtil, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Martin Stich, NVIDIA

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

  • Joshua Barczak, Intel

  • Tobias Hector, AMD

  • Henrik Rydgard, NVIDIA

  • Pascal Gautron, NVIDIA

Description

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

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

  • Acceleration structure objects and build commands

  • A new pipeline type with new shader domains

  • An indirection table to link shader groups with acceleration structure items

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

  • SPV_NV_ray_tracing

New Object Types

New Enum Constants

  • VK_NV_RAY_TRACING_EXTENSION_NAME

  • VK_NV_RAY_TRACING_SPEC_VERSION

  • VK_SHADER_UNUSED_NV

  • Extending VkAccelerationStructureTypeKHR:

    • VK_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_NV

    • VK_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_NV

  • Extending VkAccessFlagBits:

    • VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_NV

    • VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_NV

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_RAY_TRACING_BIT_NV

  • Extending VkBuildAccelerationStructureFlagBitsKHR:

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_LOW_MEMORY_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_BUILD_BIT_NV

    • VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_TRACE_BIT_NV

  • Extending VkCopyAccelerationStructureModeKHR:

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NV

    • VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NV

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_NV

  • Extending VkGeometryFlagBitsKHR:

    • VK_GEOMETRY_NO_DUPLICATE_ANY_HIT_INVOCATION_BIT_NV

    • VK_GEOMETRY_OPAQUE_BIT_NV

  • Extending VkGeometryInstanceFlagBitsKHR:

    • VK_GEOMETRY_INSTANCE_FORCE_NO_OPAQUE_BIT_NV

    • VK_GEOMETRY_INSTANCE_FORCE_OPAQUE_BIT_NV

    • VK_GEOMETRY_INSTANCE_TRIANGLE_CULL_DISABLE_BIT_NV

    • VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_NV

  • Extending VkGeometryTypeKHR:

    • VK_GEOMETRY_TYPE_AABBS_NV

    • VK_GEOMETRY_TYPE_TRIANGLES_NV

  • Extending VkIndexType:

    • VK_INDEX_TYPE_NONE_NV

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV

  • Extending VkPipelineBindPoint:

    • VK_PIPELINE_BIND_POINT_RAY_TRACING_NV

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_DEFER_COMPILE_BIT_NV

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_NV

    • VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV

  • Extending VkQueryType:

    • VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_NV

  • Extending VkRayTracingShaderGroupTypeKHR:

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_GENERAL_NV

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_PROCEDURAL_HIT_GROUP_NV

    • VK_RAY_TRACING_SHADER_GROUP_TYPE_TRIANGLES_HIT_GROUP_NV

  • Extending VkShaderStageFlagBits:

    • VK_SHADER_STAGE_ANY_HIT_BIT_NV

    • VK_SHADER_STAGE_CALLABLE_BIT_NV

    • VK_SHADER_STAGE_CLOSEST_HIT_BIT_NV

    • VK_SHADER_STAGE_INTERSECTION_BIT_NV

    • VK_SHADER_STAGE_MISS_BIT_NV

    • VK_SHADER_STAGE_RAYGEN_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_INFO_NV

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MEMORY_REQUIREMENTS_INFO_NV

    • VK_STRUCTURE_TYPE_BIND_ACCELERATION_STRUCTURE_MEMORY_INFO_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_AABB_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_NV

    • VK_STRUCTURE_TYPE_GEOMETRY_TRIANGLES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_NV

If VK_EXT_debug_report is supported:

New SPIR-V Capabilities

Issues

1) Are there issues?

RESOLVED: Yes.

Sample Code

Example ray generation GLSL shader

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

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

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

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

   col.y = payload;

   imageStore(image, ivec2(gl_LaunchIDNV.xy), col);
}

Version History

  • Revision 1, 2018-09-11 (Robert Stepinski, Nuno Subtil, Eric Werness)

    • Internal revisions

  • Revision 2, 2018-10-19 (Eric Werness)

    • rename to VK_NV_ray_tracing, add support for callables.

    • too many updates to list

  • Revision 3, 2018-11-20 (Daniel Koch)

    • update to use InstanceId instead of InstanceIndex as implemented.

VK_NV_ray_tracing_invocation_reorder

Name String

VK_NV_ray_tracing_invocation_reorder

Extension Type

Device extension

Registered Extension Number

491

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-11-02

Interactions and External Dependencies
Contributors
  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

Description

The ray tracing pipeline API provides some ability to reorder for locality, but it is useful to have more control over how the reordering happens and what information is included in the reordering. The shader API provides a hit object to contain result information from the hit which can be used as part of the explicit sorting plus options that contain an integer for hint bits to use to add more locality.

New Enum Constants

  • VK_NV_RAY_TRACING_INVOCATION_REORDER_EXTENSION_NAME

  • VK_NV_RAY_TRACING_INVOCATION_REORDER_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_INVOCATION_REORDER_PROPERTIES_NV

HLSL Mapping

HLSL does not provide this functionality natively yet.

However, it is possible to use this functionality via SPIR-V Intrinsics.

The codes for shader invocation reorder are obtained from this page:

#define ShaderInvocationReorderNV 5383
#define HitObjectAttributeNV 5385

#define OpHitObjectRecordHitMotionNV 5249
#define OpHitObjectRecordHitWithIndexMotionNV 5250
#define OpHitObjectRecordMissMotionNV 5251
#define OpHitObjectGetWorldToObjectNV 5252
#define OpHitObjectGetObjectToWorldNV 5253
#define OpHitObjectGetObjectRayDirectionNV 5254
#define OpHitObjectGetObjectRayOriginNV 5255
#define OpHitObjectTraceRayMotionNV 5256
#define OpHitObjectGetShaderRecordBufferHandleNV 5257
#define OpHitObjectGetShaderBindingTableRecordIndexNV 5258
#define OpHitObjectRecordEmptyNV 5259
#define OpHitObjectTraceRayNV 5260
#define OpHitObjectRecordHitNV 5261
#define OpHitObjectRecordHitWithIndexNV 5262
#define OpHitObjectRecordMissNV 5263
#define OpHitObjectExecuteShaderNV 5264
#define OpHitObjectGetCurrentTimeNV 5265
#define OpHitObjectGetAttributesNV 5266
#define OpHitObjectGetHitKindNV 5267
#define OpHitObjectGetPrimitiveIndexNV 5268
#define OpHitObjectGetGeometryIndexNV 5269
#define OpHitObjectGetInstanceIdNV 5270
#define OpHitObjectGetInstanceCustomIndexNV 5271
#define OpHitObjectGetWorldRayDirectionNV 5272
#define OpHitObjectGetWorldRayOriginNV 5273
#define OpHitObjectGetRayTMaxNV 5274
#define OpHitObjectGetRayTMinNV 5275
#define OpHitObjectIsEmptyNV 5276
#define OpHitObjectIsHitNV 5277
#define OpHitObjectIsMissNV 5278
#define OpReorderThreadWithHitObjectNV 5279
#define OpReorderThreadWithHintNV 5280
#define OpTypeHitObjectNV 5281

The capability and extension need to be added:

[[vk::ext_capability(ShaderInvocationReorderNV)]]
[[vk::ext_extension("SPV_NV_shader_invocation_reorder")]]

The creation of the HitObject type can be done like this:

[[vk::ext_type_def(HitObjectAttributeNV, OpTypeHitObjectNV)]]
void createHitObjectNV();
#define HitObjectNV vk::ext_type<HitObjectAttributeNV>

The payload:

  • must be global

  • needs the RayPayloadKHR attribute as an extra storage class

struct [raypayload] HitPayload
{
  float hitT : write(closesthit, miss) : read(caller);
  int instanceIndex : write(closesthit) : read(caller);
  float3 pos : write(closesthit) : read(caller);
  float3 nrm : write(closesthit) : read(caller);
};

#define RayPayloadKHR 5338
[[vk::ext_storage_class(RayPayloadKHR)]] static HitPayload payload;

Here is the declaration of a few invocation reordering functions:

[[vk::ext_instruction(OpHitObjectRecordEmptyNV)]]
void hitObjectRecordEmptyNV([[vk::ext_reference]] HitObjectNV hitObject);

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

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

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

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

[[vk::ext_instruction(OpHitObjectIsHitNV)]]
bool hitObjectIsHitNV([[vk::ext_reference]] HitObjectNV hitObject);

Using the function in the code, can be done like this

  if (USE_SER == 1)
  {
    createHitObjectNV();
    HitObjectNV hObj; //  hitObjectNV hObj;
    hitObjectRecordEmptyNV(hObj); //Initialize to an empty hit object
    hitObjectTraceRayNV(hObj, topLevelAS, rayFlags, 0xFF, 0, 0, 0, r.Origin, 0.0, r.Direction, INFINITE, payload);
    reorderThreadWithHitObjectNV(hObj);
    hitObjectExecuteShaderNV(hObj, payload);
  }

Note:

  • createHitObjectNV() needs to be call at least once. This can be also done in the main entry of the shader.

  • Function with a payload parameter, needs to have the payload struct defined before. There are no templated declaration of the function.

Version History

  • Revision 1, 2020-09-12 (Eric Werness, Ashwin Lele)

    • Initial external release

VK_NV_ray_tracing_motion_blur

Name String

VK_NV_ray_tracing_motion_blur

Extension Type

Device extension

Registered Extension Number

328

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Eric Werness

Other Extension Metadata

Last Modified Date

2021-06-16

Interactions and External Dependencies
Contributors
  • Eric Werness, NVIDIA

  • Ashwin Lele, NVIDIA

Description

Ray tracing support in the API provides an efficient mechanism to intersect rays against static geometry, but rendering algorithms often want to support motion, which is more efficiently supported with motion-specific algorithms. This extension adds a set of mechanisms to support fast tracing of moving geometry:

  • A ray pipeline trace call which takes a time parameter

  • Flags to enable motion support in an acceleration structure

  • Support for time-varying vertex positions in a geometry

  • Motion instances to move existing instances over time

The motion represented here is parameterized across a normalized timestep between 0.0 and 1.0. A motion trace using OpTraceRayMotionNV provides a time within that normalized range to be used when intersecting that ray with geometry. The geometry can be provided with motion by a combination of adding a second vertex position for time of 1.0 using VkAccelerationStructureGeometryMotionTrianglesDataNV and providing multiple transforms in the instance using VkAccelerationStructureMotionInstanceNV.

New Enum Constants

  • VK_NV_RAY_TRACING_MOTION_BLUR_EXTENSION_NAME

  • VK_NV_RAY_TRACING_MOTION_BLUR_SPEC_VERSION

  • Extending VkAccelerationStructureCreateFlagBitsKHR:

    • VK_ACCELERATION_STRUCTURE_CREATE_MOTION_BIT_NV

  • Extending VkBuildAccelerationStructureFlagBitsKHR:

    • VK_BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RAY_TRACING_ALLOW_MOTION_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_MOTION_TRIANGLES_DATA_NV

    • VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MOTION_INFO_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MOTION_BLUR_FEATURES_NV

Issues

(1) What size is VkAccelerationStructureMotionInstanceNV?

  • Added a note on the structure size and made the stride explicit in the language.

(2) Allow arrayOfPointers for motion TLAS?

  • Yes, with a packed encoding to minimize the amount of data sent for metadata.

Version History

  • Revision 1, 2020-06-16 (Eric Werness, Ashwin Lele)

    • Initial external release

VK_NV_representative_fragment_test

Name String

VK_NV_representative_fragment_test

Extension Type

Device extension

Registered Extension Number

167

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-09-13

Contributors
  • Kedarnath Thangudu, NVIDIA

  • Christoph Kubisch, NVIDIA

  • Pierre Boudier, NVIDIA

  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

Description

This extension provides a new representative fragment test that allows implementations to reduce the amount of rasterization and fragment processing work performed for each point, line, or triangle primitive. For any primitive that produces one or more fragments that pass all other early fragment tests, the implementation is permitted to choose one or more “representative” fragments for processing and discard all other fragments. For draw calls rendering multiple points, lines, or triangles arranged in lists, strips, or fans, the representative fragment test is performed independently for each of those primitives.

This extension is useful for applications that use an early render pass to determine the full set of primitives that would be visible in the final scene. In this render pass, such applications would set up a fragment shader that enables early fragment tests and writes to an image or shader storage buffer to record the ID of the primitive that generated the fragment. Without this extension, the shader would record the ID separately for each visible fragment of each primitive. With this extension, fewer stores will be performed, particularly for large primitives.

The representative fragment test has no effect if early fragment tests are not enabled via the fragment shader. The set of fragments discarded by the representative fragment test is implementation-dependent and may vary from frame to frame. In some cases, the representative fragment test may not discard any fragments for a given primitive.

New Enum Constants

  • VK_NV_REPRESENTATIVE_FRAGMENT_TEST_EXTENSION_NAME

  • VK_NV_REPRESENTATIVE_FRAGMENT_TEST_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_REPRESENTATIVE_FRAGMENT_TEST_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_REPRESENTATIVE_FRAGMENT_TEST_STATE_CREATE_INFO_NV

Issues

(1) Is the representative fragment test guaranteed to have any effect?

RESOLVED: No. As specified, we only guarantee that each primitive with at least one fragment that passes prior tests will have one fragment passing the representative fragment tests. We do not guarantee that any particular fragment will fail the test.

In the initial implementation of this extension, the representative fragment test is treated as an optimization that may be completely disabled for some pipeline states. This feature was designed for a use case where the fragment shader records information on individual primitives using shader storage buffers or storage images, with no writes to color or depth buffers.

(2) Will the set of fragments that pass the representative fragment test be repeatable if you draw the same scene over and over again?

RESOLVED: No. The set of fragments that pass the representative fragment test is implementation-dependent and may vary due to the timing of operations performed by the GPU.

(3) What happens if you enable the representative fragment test with writes to color and/or depth render targets enabled?

RESOLVED: If writes to the color or depth buffer are enabled, they will be performed for any fragments that survive the relevant tests. Any fragments that fail the representative fragment test will not update color buffers. For the use cases intended for this feature, we do not expect color or depth writes to be enabled.

(4) How do derivatives and automatic texture LOD computations work with the representative fragment test enabled?

RESOLVED: If a fragment shader uses derivative functions or texture lookups using automatic LOD computation, derivatives will be computed identically whether or not the representative fragment test is enabled. For the use cases intended for this feature, we do not expect the use of derivatives in the fragment shader.

Version History

  • Revision 2, 2018-09-13 (pbrown)

    • Add issues.

  • Revision 1, 2018-08-22 (Kedarnath Thangudu)

    • Internal Revisions

VK_NV_sample_mask_override_coverage

Name String

VK_NV_sample_mask_override_coverage

Extension Type

Device extension

Registered Extension Number

95

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-12-08

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

Description

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

  • SPV_NV_sample_mask_override_coverage

The extension provides access to the OverrideCoverageNV decoration under the SampleMaskOverrideCoverageNV capability. Adding this decoration to a variable with the SampleMask builtin decoration allows the shader to modify the coverage mask and affect which samples are used to process the fragment.

When using GLSL source-based shader languages, the override_coverage layout qualifier from GL_NV_sample_mask_override_coverage maps to the OverrideCoverageNV decoration. To use the override_coverage layout qualifier in GLSL the GL_NV_sample_mask_override_coverage extension must be enabled. Behavior is described in the GL_NV_sample_mask_override_coverage extension spec.

New Enum Constants

  • VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_EXTENSION_NAME

  • VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_SPEC_VERSION

New Variable Decoration

New SPIR-V Capabilities

Version History

  • Revision 1, 2016-12-08 (Piers Daniell)

    • Internal revisions

VK_NV_scissor_exclusive

Name String

VK_NV_scissor_exclusive

Extension Type

Device extension

Registered Extension Number

206

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2023-01-18

IP Status

No known IP claims.

Interactions and External Dependencies

None

Contributors
  • Pat Brown, NVIDIA

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension adds support for an exclusive scissor test to Vulkan. The exclusive scissor test behaves like the scissor test, except that the exclusive scissor test fails for pixels inside the corresponding rectangle and passes for pixels outside the rectangle. If the same rectangle is used for both the scissor and exclusive scissor tests, the exclusive scissor test will pass if and only if the scissor test fails.

Version 2 of this extension introduces VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV and vkCmdSetExclusiveScissorEnableNV. Applications that use this dynamic state must ensure the implementation advertises at least specVersion 2 of this extension.

New Enum Constants

  • VK_NV_SCISSOR_EXCLUSIVE_EXTENSION_NAME

  • VK_NV_SCISSOR_EXCLUSIVE_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_ENABLE_NV

    • VK_DYNAMIC_STATE_EXCLUSIVE_SCISSOR_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXCLUSIVE_SCISSOR_FEATURES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_EXCLUSIVE_SCISSOR_STATE_CREATE_INFO_NV

Issues

1) For the scissor test, the viewport state must be created with a matching number of scissor and viewport rectangles. Should we have the same requirement for exclusive scissors?

RESOLVED: For exclusive scissors, we relax this requirement and allow an exclusive scissor rectangle count that is either zero or equal to the number of viewport rectangles. If you pass in an exclusive scissor count of zero, the exclusive scissor test is treated as disabled.

Version History

  • Revision 2, 2023-01-18 (Piers Daniell)

    • Add dynamic state for explicit exclusive scissor enables

  • Revision 1, 2018-07-31 (Pat Brown)

    • Internal revisions

VK_NV_shader_image_footprint

Name String

VK_NV_shader_image_footprint

Extension Type

Device extension

Registered Extension Number

205

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-09-13

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

  • Chris Lentini, NVIDIA

  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension adds Vulkan support for the SPV_NV_shader_image_footprint SPIR-V extension. That SPIR-V extension provides a new instruction OpImageSampleFootprintNV allowing shaders to determine the set of texels that would be accessed by an equivalent filtered texture lookup.

Instead of returning a filtered texture value, the instruction returns a structure that can be interpreted by shader code to determine the footprint of a filtered texture lookup. This structure includes integer values that identify a small neighborhood of texels in the image being accessed and a bitfield that indicates which texels in that neighborhood would be used. The structure also includes a bitfield where each bit identifies whether any texel in a small aligned block of texels would be fetched by the texture lookup. The size of each block is specified by an access granularity provided by the shader. The minimum granularity supported by this extension is 2x2 (for 2D textures) and 2x2x2 (for 3D textures); the maximum granularity is 256x256 (for 2D textures) or 64x32x32 (for 3D textures). Each footprint query returns the footprint from a single texture level. When using minification filters that combine accesses from multiple mipmap levels, shaders must perform separate queries for the two levels accessed (“fine” and “coarse”). The footprint query also returns a flag indicating if the texture lookup would access texels from only one mipmap level or from two neighboring levels.

This extension should be useful for multi-pass rendering operations that do an initial expensive rendering pass to produce a first image that is then used as a texture for a second pass. If the second pass ends up accessing only portions of the first image (e.g., due to visibility), the work spent rendering the non-accessed portion of the first image was wasted. With this feature, an application can limit this waste using an initial pass over the geometry in the second image that performs a footprint query for each visible pixel to determine the set of pixels that it needs from the first image. This pass would accumulate an aggregate footprint of all visible pixels into a separate “footprint image” using shader atomics. Then, when rendering the first image, the application can kill all shading work for pixels not in this aggregate footprint.

This extension has a number of limitations. The OpImageSampleFootprintNV instruction only supports for two- and three-dimensional textures. Footprint evaluation only supports the CLAMP_TO_EDGE wrap mode; results are undefined for all other wrap modes. Only a limited set of granularity values and that set does not support separate coverage information for each texel in the original image.

When using SPIR-V generated from the OpenGL Shading Language, the new instruction will be generated from code using the new textureFootprint*NV built-in functions from the GL_NV_shader_texture_footprint shading language extension.

New Enum Constants

  • VK_NV_SHADER_IMAGE_FOOTPRINT_EXTENSION_NAME

  • VK_NV_SHADER_IMAGE_FOOTPRINT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_FOOTPRINT_FEATURES_NV

New SPIR-V Capability

Issues

(1) The footprint returned by the SPIR-V instruction is a structure that includes an anchor, an offset, and a mask that represents a 8x8 or 4x4x4 neighborhood of texel groups. But the bits of the mask are not stored in simple pitch order. Why is the footprint built this way?

RESOLVED: We expect that applications using this feature will want to use a fixed granularity and accumulate coverage information from the returned footprints into an aggregate “footprint image” that tracks the portions of an image that would be needed by regular texture filtering. If an application is using a two-dimensional image with 4x4 pixel granularity, we expect that the footprint image will use 64-bit texels where each bit in an 8x8 array of bits corresponds to coverage for a 4x4 block in the original image. Texel (0,0) in the footprint image would correspond to texels (0,0) through (31,31) in the original image.

In the usual case, the footprint for a single access will fully contained in a 32x32 aligned region of the original texture, which corresponds to a single 64-bit texel in the footprint image. In that case, the implementation will return an anchor coordinate pointing at the single footprint image texel, an offset vector of (0,0), and a mask whose bits are aligned with the bits in the footprint texel. For this case, the shader can simply atomically OR the mask bits into the contents of the footprint texel to accumulate footprint coverage.

In the worst case, the footprint for a single access spans multiple 32x32 aligned regions and may require updates to four separate footprint image texels. In this case, the implementation will return an anchor coordinate pointing at the lower right footprint image texel and an offset will identify how many “columns” and “rows” of the returned 8x8 mask correspond to footprint texels to the left and above the anchor texel. If the anchor is (2,3), the 64 bits of the returned mask are arranged spatially as follows, where each 4x4 block is assigned a bit number that matches its bit number in the footprint image texels:

    +-------------------------+-------------------------+
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- 46 47 | 40 41 42 43 44 45 -- -- |
    | -- -- -- -- -- -- 54 55 | 48 49 50 51 52 53 -- -- |
    | -- -- -- -- -- -- 62 63 | 56 57 58 59 60 61 -- -- |
    +-------------------------+-------------------------+
    | -- -- -- -- -- -- 06 07 | 00 01 02 03 04 05 -- -- |
    | -- -- -- -- -- -- 14 15 | 08 09 10 11 12 13 -- -- |
    | -- -- -- -- -- -- 22 23 | 16 17 18 19 20 21 -- -- |
    | -- -- -- -- -- -- 30 31 | 24 25 26 27 28 29 -- -- |
    | -- -- -- -- -- -- 38 39 | 32 33 34 35 36 37 -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
    +-------------------------+-------------------------+

To accumulate coverage for each of the four footprint image texels, a shader can AND the returned mask with simple masks derived from the x and y offset values and then atomically OR the updated mask bits into the contents of the corresponding footprint texel.

    uint64_t returnedMask = (uint64_t(footprint.mask.x) | (uint64_t(footprint.mask.y) << 32));
    uint64_t rightMask    = ((0xFF >> footprint.offset.x) * 0x0101010101010101UL);
    uint64_t bottomMask   = 0xFFFFFFFFFFFFFFFFUL >> (8 * footprint.offset.y);
    uint64_t bottomRight  = returnedMask & bottomMask & rightMask;
    uint64_t bottomLeft   = returnedMask & bottomMask & (~rightMask);
    uint64_t topRight     = returnedMask & (~bottomMask) & rightMask;
    uint64_t topLeft      = returnedMask & (~bottomMask) & (~rightMask);

(2) What should an application do to ensure maximum performance when accumulating footprints into an aggregate footprint image?

RESOLVED: We expect that the most common usage of this feature will be to accumulate aggregate footprint coverage, as described in the previous issue. Even if you ignore the anisotropic filtering case where the implementation may return a granularity larger than that requested by the caller, each shader invocation will need to use atomic functions to update up to four footprint image texels for each LOD accessed. Having each active shader invocation perform multiple atomic operations can be expensive, particularly when neighboring invocations will want to update the same footprint image texels.

Techniques can be used to reduce the number of atomic operations performed when accumulating coverage include:

  • Have logic that detects returned footprints where all components of the returned offset vector are zero. In that case, the mask returned by the footprint function is guaranteed to be aligned with the footprint image texels and affects only a single footprint image texel.

  • Have fragment shaders communicate using built-in functions from the VK_NV_shader_subgroup_partitioned extension or other shader subgroup extensions. If you have multiple invocations in a subgroup that need to update the same texel (x,y) in the footprint image, compute an aggregate footprint mask across all invocations in the subgroup updating that texel and have a single invocation perform an atomic operation using that aggregate mask.

  • When the returned footprint spans multiple texels in the footprint image, each invocation need to perform four atomic operations. In the previous issue, we had an example that computed separate masks for “topLeft”, “topRight”, “bottomLeft”, and “bottomRight”. When the invocations in a subgroup have good locality, it might be the case the “top left” for some invocations might refer to footprint image texel (10,10), while neighbors might have their “top left” texels at (11,10), (10,11), and (11,11). If you compute separate masks for even/odd x and y values instead of left/right or top/bottom, the “odd/odd” mask for all invocations in the subgroup hold coverage for footprint image texel (11,11), which can be updated by a single atomic operation for the entire subgroup.

Examples

TBD

Version History

  • Revision 2, 2018-09-13 (Pat Brown)

    • Add issue (2) with performance tips.

  • Revision 1, 2018-08-12 (Pat Brown)

    • Initial draft

VK_NV_shader_sm_builtins

Name String

VK_NV_shader_sm_builtins

Extension Type

Device extension

Registered Extension Number

155

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-05-28

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Eric Werness, NVIDIA

Description

This extension provides the ability to determine device-specific properties on NVIDIA GPUs. It provides the number of streaming multiprocessors (SMs), the maximum number of warps (subgroups) that can run on an SM, and shader builtins to enable invocations to identify which SM and warp a shader invocation is executing on.

This extension enables support for the SPIR-V ShaderSMBuiltinsNV capability.

These properties and built-ins should typically only be used for debugging purposes.

New Enum Constants

  • VK_NV_SHADER_SM_BUILTINS_EXTENSION_NAME

  • VK_NV_SHADER_SM_BUILTINS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_PROPERTIES_NV

New or Modified Built-In Variables

New SPIR-V Capabilities

Issues

  1. What should we call this extension?

    RESOLVED: NV_shader_sm_builtins. Other options considered included:

    • NV_shader_smid - but SMID is really easy to typo/confuse as SIMD.

    • NV_shader_sm_info - but Info is typically reserved for input structures

Version History

  • Revision 1, 2019-05-28 (Daniel Koch)

    • Internal revisions

VK_NV_shader_subgroup_partitioned

Name String

VK_NV_shader_subgroup_partitioned

Extension Type

Device extension

Registered Extension Number

199

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2018-03-17

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

Description

This extension enables support for a new class of group operations on subgroups via the GL_NV_shader_subgroup_partitioned GLSL extension and SPV_NV_shader_subgroup_partitioned SPIR-V extension. Support for these new operations is advertised via the VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV bit.

This extension requires Vulkan 1.1, for general subgroup support.

New Enum Constants

  • VK_NV_SHADER_SUBGROUP_PARTITIONED_EXTENSION_NAME

  • VK_NV_SHADER_SUBGROUP_PARTITIONED_SPEC_VERSION

  • Extending VkSubgroupFeatureFlagBits:

    • VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV

Version History

  • Revision 1, 2018-03-17 (Jeff Bolz)

    • Internal revisions

VK_NV_shading_rate_image

Name String

VK_NV_shading_rate_image

Extension Type

Device extension

Registered Extension Number

165

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2019-07-18

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

  • Carsten Rohde, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Mathias Schott, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc.

Description

This extension allows applications to use a variable shading rate when processing fragments of rasterized primitives. By default, Vulkan will spawn one fragment shader for each pixel covered by a primitive. In this extension, applications can bind a shading rate image that can be used to vary the number of fragment shader invocations across the framebuffer. Some portions of the screen may be configured to spawn up to 16 fragment shaders for each pixel, while other portions may use a single fragment shader invocation for a 4x4 block of pixels. This can be useful for use cases like eye tracking, where the portion of the framebuffer that the user is looking at directly can be processed at high frequency, while distant corners of the image can be processed at lower frequency. Each texel in the shading rate image represents a fixed-size rectangle in the framebuffer, covering 16x16 pixels in the initial implementation of this extension. When rasterizing a primitive covering one of these rectangles, the Vulkan implementation reads a texel in the bound shading rate image and looks up the fetched value in a palette to determine a base shading rate.

In addition to the API support controlling rasterization, this extension also adds Vulkan support for the SPV_NV_shading_rate extension to SPIR-V. That extension provides two fragment shader variable decorations that allow fragment shaders to determine the shading rate used for processing the fragment:

  • FragmentSizeNV, which indicates the width and height of the set of pixels processed by the fragment shader.

  • InvocationsPerPixel, which indicates the maximum number of fragment shader invocations that could be spawned for the pixel(s) covered by the fragment.

When using SPIR-V in conjunction with the OpenGL Shading Language (GLSL), the fragment shader capabilities are provided by the GL_NV_shading_rate_image language extension and correspond to the built-in variables gl_FragmentSizeNV and gl_InvocationsPerPixelNV, respectively.

New Enum Constants

  • VK_NV_SHADING_RATE_IMAGE_EXTENSION_NAME

  • VK_NV_SHADING_RATE_IMAGE_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV

    • VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV

  • Extending VkImageUsageFlagBits:

    • VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_FEATURES_NV

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_PROPERTIES_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV

Issues

(1) When using shading rates specifying “coarse” fragments covering multiple pixels, we will generate a combined coverage mask that combines the coverage masks of all pixels covered by the fragment. By default, these masks are combined in an implementation-dependent order. Should we provide a mechanism allowing applications to query or specify an exact order?

RESOLVED: Yes, this feature is useful for cases where most of the fragment shader can be evaluated once for an entire coarse fragment, but where some per-pixel computations are also required. For example, a per-pixel alpha test may want to kill all the samples for some pixels in a coarse fragment. This sort of test can be implemented using an output sample mask, but such a shader would need to know which bit in the mask corresponds to each sample in the coarse fragment. We are including a mechanism to allow applications to specify the orders of coverage samples for each shading rate and sample count, either as static pipeline state or dynamically via a command buffer. This portion of the extension has its own feature bit.

We will not be providing a query to determine the implementation-dependent default ordering. The thinking here is that if an application cares enough about the coarse fragment sample ordering to perform such a query, it could instead just set its own order, also using custom per-pixel sample locations if required.

(2) For the pipeline stage VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV, should we specify a precise location in the pipeline the shading rate image is accessed (after geometry shading, but before the early fragment tests) or leave it under-specified in case there are other implementations that access the image in a different pipeline location?

RESOLVED We are specifying the pipeline stage to be between the final pre-rasterization shader stage (VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT) and before the first stage used for fragment processing (VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT), which seems to be the natural place to access the shading rate image.

(3) How do centroid-sampled variables work with fragments larger than one pixel?

RESOLVED For single-pixel fragments, fragment shader inputs decorated with Centroid are sampled at an implementation-dependent location in the intersection of the area of the primitive being rasterized and the area of the pixel that corresponds to the fragment. With multi-pixel fragments, we follow a similar pattern, using the intersection of the primitive and the set of pixels corresponding to the fragment.

One important thing to keep in mind when using such “coarse” shading rates is that fragment attributes are sampled at the center of the fragment by default, regardless of the set of pixels/samples covered by the fragment. For fragments with a size of 4x4 pixels, this center location will be more than two pixels (1.5 * sqrt(2)) away from the center of the pixels at the corners of the fragment. When rendering a primitive that covers only a small part of a coarse fragment, sampling a color outside the primitive can produce overly bright or dark color values if the color values have a large gradient. To deal with this, an application can use centroid sampling on attributes where “extrapolation” artifacts can lead to overly bright or dark pixels. Note that this same problem also exists for multisampling with single-pixel fragments, but is less severe because it only affects certain samples of a pixel and such bright/dark samples may be averaged with other samples that do not have a similar problem.

Version History

  • Revision 3, 2019-07-18 (Mathias Schott)

    • Fully list extension interfaces in this appendix.

  • Revision 2, 2018-09-13 (Pat Brown)

    • Miscellaneous edits preparing the specification for publication.

  • Revision 1, 2018-08-08 (Pat Brown)

    • Internal revisions

VK_NV_viewport_array2

Name String

VK_NV_viewport_array2

Extension Type

Device extension

Registered Extension Number

97

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-02-15

Interactions and External Dependencies
  • This extension requires SPV_NV_viewport_array2

  • This extension provides API support for GL_NV_viewport_array2

  • This extension requires the geometryShader and multiViewport features.

  • This extension interacts with the tessellationShader feature.

Contributors
  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

Description

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

  • SPV_NV_viewport_array2

which allows a single primitive to be broadcast to multiple viewports and/or multiple layers. A new shader built-in output ViewportMaskNV is provided, which allows a single primitive to be output to multiple viewports simultaneously. Also, a new SPIR-V decoration is added to control whether the effective viewport index is added into the variable decorated with the Layer built-in decoration. These capabilities allow a single primitive to be output to multiple layers simultaneously.

This extension allows variables decorated with the Layer and ViewportIndex built-ins to be exported from vertex or tessellation shaders, using the ShaderViewportIndexLayerNV capability.

This extension adds a new ViewportMaskNV built-in decoration that is available for output variables in vertex, tessellation evaluation, and geometry shaders, and a new ViewportRelativeNV decoration that can be added on variables decorated with Layer when using the ShaderViewportMaskNV capability.

When using GLSL source-based shading languages, the gl_ViewportMask[] built-in output variable and viewport_relative layout qualifier from GL_NV_viewport_array2 map to the ViewportMaskNV and ViewportRelativeNV decorations, respectively. Behaviour is described in the GL_NV_viewport_array2 extension specification.

Note

The ShaderViewportIndexLayerNV capability is equivalent to the ShaderViewportIndexLayerEXT capability added by VK_EXT_shader_viewport_index_layer.

New Enum Constants

  • VK_NV_VIEWPORT_ARRAY2_EXTENSION_NAME

  • VK_NV_VIEWPORT_ARRAY2_SPEC_VERSION

  • VK_NV_VIEWPORT_ARRAY_2_EXTENSION_NAME

  • VK_NV_VIEWPORT_ARRAY_2_SPEC_VERSION

New or Modified Built-In Variables

New Variable Decoration

Version History

  • Revision 1, 2017-02-15 (Daniel Koch)

    • Internal revisions

VK_NV_viewport_swizzle

Name String

VK_NV_viewport_swizzle

Extension Type

Device extension

Registered Extension Number

99

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2016-12-22

Interactions and External Dependencies
  • This extension requires multiViewport and geometryShader features to be useful.

Contributors
  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension provides a new per-viewport swizzle that can modify the position of primitives sent to each viewport. New viewport swizzle state is added for each viewport, and a new position vector is computed for each vertex by selecting from and optionally negating any of the four components of the original position vector.

This new viewport swizzle is useful for a number of algorithms, including single-pass cube map rendering (broadcasting a primitive to multiple faces and reorienting the vertex position for each face) and voxel rasterization. The per-viewport component remapping and negation provided by the swizzle allows application code to re-orient three-dimensional geometry with a view along any of the X, Y, or Z axes. If a perspective projection and depth buffering is required, 1/W buffering should be used, as described in the single-pass cube map rendering example in the “Issues” section below.

New Enum Constants

  • VK_NV_VIEWPORT_SWIZZLE_EXTENSION_NAME

  • VK_NV_VIEWPORT_SWIZZLE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SWIZZLE_STATE_CREATE_INFO_NV

Issues

1) Where does viewport swizzling occur in the pipeline?

RESOLVED: Despite being associated with the viewport, viewport swizzling must happen prior to the viewport transform. In particular, it needs to be performed before clipping and perspective division.

The viewport mask expansion (VK_NV_viewport_array2) and the viewport swizzle could potentially be performed before or after transform feedback, but feeding back several viewports worth of primitives with different swizzles does not seem particularly useful. This specification applies the viewport mask and swizzle after transform feedback, and makes primitive queries only count each primitive once.

2) Any interesting examples of how this extension, VK_NV_viewport_array2, and VK_NV_geometry_shader_passthrough can be used together in practice?

RESOLVED: One interesting use case for this extension is for single-pass rendering to a cube map. In this example, the application would attach a cube map texture to a layered FBO where the six cube faces are treated as layers. Vertices are sent through the vertex shader without applying a projection matrix, where the gl_Position output is (x,y,z,1) and the center of the cube map is at (0,0,0). With unextended Vulkan, one could have a conventional instanced geometry shader that looks something like the following:

layout(invocations = 6) in;     // separate invocation per face
layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices = 3) out;

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

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

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

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

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

    // Otherwise, emit a copy of the input primitive to the
    // appropriate face (using gl_Layer).
    for (int i = 0; i < 3; i++) {
        gl_Layer = face;
        gl_Position = positions[i];
        texcoord = v[i].texcoord;
        normal = v[i].normal;
        baseColor = v[i].baseColor;
        EmitVertex();
    }
}

With passthrough geometry shaders, this can be done using a much simpler shader:

layout(triangles) in;
layout(passthrough) in Inputs {
    vec2 texcoord;
    vec3 normal;
    vec4 baseColor;
}
layout(passthrough) in gl_PerVertex {
    vec4 gl_Position;
} gl_in[];
layout(viewport_relative) out int gl_Layer;

void main()
{
    // Figure out which faces the primitive projects onto and
    // generate a corresponding viewport mask.
    uint mask = 0;
    for (int i = 0; i < 6; i++) {
        if (!shouldCull(face)) {
        mask |= 1U << i;
        }
    }
    gl_ViewportMask = mask;
    gl_Layer = 0;
}

The application code is set up so that each of the six cube faces has a separate viewport (numbered 0 to 5). Each face also has a separate swizzle, programmed via the VkPipelineViewportSwizzleStateCreateInfoNV pipeline state. The viewport swizzle feature performs the coordinate transformation handled by the rotate() function in the original shader. The viewport_relative layout qualifier says that the viewport number (0 to 5) is added to the base gl_Layer value of 0 to determine which layer (cube face) the primitive should be sent to.

Note that the use of the passed through input normal in this example suggests that the fragment shader in this example would perform an operation like per-fragment lighting. The viewport swizzle would transform the position to be face-relative, but normal would remain in the original coordinate system. It seems likely that the fragment shader in either version of the example would want to perform lighting in the original coordinate system. It would likely do this by reconstructing the position of the fragment in the original coordinate system using gl_FragCoord, a constant or uniform holding the size of the cube face, and the input gl_ViewportIndex (or gl_Layer), which identifies the cube face. Since the value of normal is in the original coordinate system, it would not need to be modified as part of this coordinate transformation.

Note that while the rotate() operation in the regular geometry shader above could include an arbitrary post-rotation projection matrix, the viewport swizzle does not support arbitrary math. To get proper projection, 1/W buffering should be used. To do this:

  1. Program the viewport swizzles to move the pre-projection W eye coordinate (typically 1.0) into the Z coordinate of the swizzle output and the eye coordinate component used for depth into the W coordinate. For example, the viewport corresponding to the +Z face might use a swizzle of (+X, -Y, +W, +Z). The Z normalized device coordinate computed after swizzling would then be z'/w' = 1/Zeye.

  2. On NVIDIA implementations supporting floating-point depth buffers with values outside [0,1], prevent unwanted near plane clipping by enabling depthClampEnable. Ensure that the depth clamp does not mess up depth testing by programming the depth range to very large values, such as minDepthBounds=-z, maxDepthBounds=+z, where z = 2127. It should be possible to use IEEE infinity encodings also (0xFF800000 for -INF, 0x7F800000 for +INF). Even when near/far clipping is disabled, primitives extending behind the eye will still be clipped because one or more vertices will have a negative W coordinate and fail X/Y clipping tests.

    On other implementations, scale X, Y, and Z eye coordinates so that vertices on the near plane have a post-swizzle W coordinate of 1.0. For example, if the near plane is at Zeye = 1/256, scale X, Y, and Z by 256.

  3. Adjust depth testing to reflect the fact that 1/W values are large near the eye and small away from the eye. Clear the depth buffer to zero (infinitely far away) and use a depth test of VK_COMPARE_OP_GREATER instead of VK_COMPARE_OP_LESS.

Version History

  • Revision 1, 2016-12-22 (Piers Daniell)

    • Internal revisions

VK_NVX_binary_import

Name String

VK_NVX_binary_import

Extension Type

Device extension

Registered Extension Number

30

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-04-09

Contributors
  • Eric Werness, NVIDIA

  • Liam Middlebrook, NVIDIA

Description

This extension allows applications to import CuBIN binaries and execute them.

Note

There is currently no specification language written for this extension. The links to APIs defined by the extension are to stubs that only include generated content such as API declarations and implicit valid usage statements.

New Object Types

New Enum Constants

  • VK_NVX_BINARY_IMPORT_EXTENSION_NAME

  • VK_NVX_BINARY_IMPORT_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_CU_FUNCTION_NVX

    • VK_OBJECT_TYPE_CU_MODULE_NVX

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX

    • VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX

    • VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX

If VK_EXT_debug_report is supported:

  • Extending VkDebugReportObjectTypeEXT:

    • VK_DEBUG_REPORT_OBJECT_TYPE_CU_FUNCTION_NVX_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_CU_MODULE_NVX_EXT

Stub API References

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuFunctionNVX)

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkCuModuleNVX)

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
VkResult vkCreateCuFunctionNVX(
    VkDevice                                    device,
    const VkCuFunctionCreateInfoNVX*            pCreateInfo,
    const VkAllocationCallbacks*                pAllocator,
    VkCuFunctionNVX*                            pFunction);
Valid Usage (Implicit)
  • VUID-vkCreateCuFunctionNVX-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkCreateCuFunctionNVX-pCreateInfo-parameter
    pCreateInfo must be a valid pointer to a valid VkCuFunctionCreateInfoNVX structure

  • VUID-vkCreateCuFunctionNVX-pAllocator-parameter
    If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure

  • VUID-vkCreateCuFunctionNVX-pFunction-parameter
    pFunction must be a valid pointer to a VkCuFunctionNVX handle

Return Codes
Success
  • VK_SUCCESS

Failure
  • VK_ERROR_OUT_OF_HOST_MEMORY

  • VK_ERROR_INITIALIZATION_FAILED

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
typedef struct VkCuFunctionCreateInfoNVX {
    VkStructureType    sType;
    const void*        pNext;
    VkCuModuleNVX      module;
    const char*        pName;
} VkCuFunctionCreateInfoNVX;
Valid Usage (Implicit)
  • VUID-VkCuFunctionCreateInfoNVX-sType-sType
    sType must be VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX

  • VUID-VkCuFunctionCreateInfoNVX-pNext-pNext
    pNext must be NULL

  • VUID-VkCuFunctionCreateInfoNVX-module-parameter
    module must be a valid VkCuModuleNVX handle

  • VUID-VkCuFunctionCreateInfoNVX-pName-parameter
    pName must be a null-terminated UTF-8 string

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
void vkDestroyCuFunctionNVX(
    VkDevice                                    device,
    VkCuFunctionNVX                             function,
    const VkAllocationCallbacks*                pAllocator);
Valid Usage (Implicit)
  • VUID-vkDestroyCuFunctionNVX-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkDestroyCuFunctionNVX-function-parameter
    function must be a valid VkCuFunctionNVX handle

  • VUID-vkDestroyCuFunctionNVX-pAllocator-parameter
    If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure

  • VUID-vkDestroyCuFunctionNVX-function-parent
    function must have been created, allocated, or retrieved from device

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
VkResult vkCreateCuModuleNVX(
    VkDevice                                    device,
    const VkCuModuleCreateInfoNVX*              pCreateInfo,
    const VkAllocationCallbacks*                pAllocator,
    VkCuModuleNVX*                              pModule);
Valid Usage (Implicit)
  • VUID-vkCreateCuModuleNVX-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkCreateCuModuleNVX-pCreateInfo-parameter
    pCreateInfo must be a valid pointer to a valid VkCuModuleCreateInfoNVX structure

  • VUID-vkCreateCuModuleNVX-pAllocator-parameter
    If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure

  • VUID-vkCreateCuModuleNVX-pModule-parameter
    pModule must be a valid pointer to a VkCuModuleNVX handle

Return Codes
Success
  • VK_SUCCESS

Failure
  • VK_ERROR_OUT_OF_HOST_MEMORY

  • VK_ERROR_INITIALIZATION_FAILED

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
typedef struct VkCuModuleCreateInfoNVX {
    VkStructureType    sType;
    const void*        pNext;
    size_t             dataSize;
    const void*        pData;
} VkCuModuleCreateInfoNVX;
Valid Usage (Implicit)
  • VUID-VkCuModuleCreateInfoNVX-sType-sType
    sType must be VK_STRUCTURE_TYPE_CU_MODULE_CREATE_INFO_NVX

  • VUID-VkCuModuleCreateInfoNVX-pNext-pNext
    pNext must be NULL

  • VUID-VkCuModuleCreateInfoNVX-pData-parameter
    pData must be a valid pointer to an array of dataSize bytes

  • VUID-VkCuModuleCreateInfoNVX-dataSize-arraylength
    dataSize must be greater than 0

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
void vkDestroyCuModuleNVX(
    VkDevice                                    device,
    VkCuModuleNVX                               module,
    const VkAllocationCallbacks*                pAllocator);
Valid Usage (Implicit)
  • VUID-vkDestroyCuModuleNVX-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkDestroyCuModuleNVX-module-parameter
    module must be a valid VkCuModuleNVX handle

  • VUID-vkDestroyCuModuleNVX-pAllocator-parameter
    If pAllocator is not NULL, pAllocator must be a valid pointer to a valid VkAllocationCallbacks structure

  • VUID-vkDestroyCuModuleNVX-module-parent
    module must have been created, allocated, or retrieved from device

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
void vkCmdCuLaunchKernelNVX(
    VkCommandBuffer                             commandBuffer,
    const VkCuLaunchInfoNVX*                    pLaunchInfo);
Valid Usage (Implicit)
  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-parameter
    commandBuffer must be a valid VkCommandBuffer handle

  • VUID-vkCmdCuLaunchKernelNVX-pLaunchInfo-parameter
    pLaunchInfo must be a valid pointer to a valid VkCuLaunchInfoNVX structure

  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-recording
    commandBuffer must be in the recording state

  • VUID-vkCmdCuLaunchKernelNVX-commandBuffer-cmdpool
    The VkCommandPool that commandBuffer was allocated from must support graphics, or compute operations

  • VUID-vkCmdCuLaunchKernelNVX-videocoding
    This command must only be called outside of a video coding scope

Host Synchronization
  • Host access to the VkCommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties
Command Buffer Levels Render Pass Scope Video Coding Scope Supported Queue Types Command Type

Primary
Secondary

Both

Outside

Graphics
Compute

Action

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_NVX_binary_import
typedef struct VkCuLaunchInfoNVX {
    VkStructureType        sType;
    const void*            pNext;
    VkCuFunctionNVX        function;
    uint32_t               gridDimX;
    uint32_t               gridDimY;
    uint32_t               gridDimZ;
    uint32_t               blockDimX;
    uint32_t               blockDimY;
    uint32_t               blockDimZ;
    uint32_t               sharedMemBytes;
    size_t                 paramCount;
    const void* const *    pParams;
    size_t                 extraCount;
    const void* const *    pExtras;
} VkCuLaunchInfoNVX;
Valid Usage (Implicit)
  • VUID-VkCuLaunchInfoNVX-sType-sType
    sType must be VK_STRUCTURE_TYPE_CU_LAUNCH_INFO_NVX

  • VUID-VkCuLaunchInfoNVX-pNext-pNext
    pNext must be NULL

  • VUID-VkCuLaunchInfoNVX-function-parameter
    function must be a valid VkCuFunctionNVX handle

  • VUID-VkCuLaunchInfoNVX-pParams-parameter
    If paramCount is not 0, pParams must be a valid pointer to an array of paramCount bytes

  • VUID-VkCuLaunchInfoNVX-pExtras-parameter
    If extraCount is not 0, pExtras must be a valid pointer to an array of extraCount bytes

Version History

  • Revision 1, 2021-04-09 (Eric Werness)

    • Internal revisions

VK_NVX_image_view_handle

Name String

VK_NVX_image_view_handle

Extension Type

Device extension

Registered Extension Number

31

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-04-03

Contributors
  • Eric Werness, NVIDIA

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension allows applications to query an opaque handle from an image view for use as a sampled image or storage image. This provides no direct functionality itself.

New Enum Constants

  • VK_NVX_IMAGE_VIEW_HANDLE_EXTENSION_NAME

  • VK_NVX_IMAGE_VIEW_HANDLE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_ADDRESS_PROPERTIES_NVX

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_HANDLE_INFO_NVX

Version History

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

  • Revision 1, 2018-12-07 (Eric Werness)

    • Internal revisions

VK_NVX_multiview_per_view_attributes

Name String

VK_NVX_multiview_per_view_attributes

Extension Type

Device extension

Registered Extension Number

98

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2017-01-13

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

Description

This extension adds a new way to write shaders to be used with multiview subpasses, where the attributes for all views are written out by a single invocation of the pre-rasterization shader stages. Related SPIR-V and GLSL extensions SPV_NVX_multiview_per_view_attributes and GL_NVX_multiview_per_view_attributes introduce per-view position and viewport mask attributes arrays, and this extension defines how those per-view attribute arrays are interpreted by Vulkan. Pipelines using per-view attributes may only execute the pre-rasterization shader stages once for all views rather than once per-view, which reduces redundant shading work.

A subpass creation flag controls whether the subpass uses this extension. A subpass must either exclusively use this extension or not use it at all.

Some Vulkan implementations only support the position attribute varying between views in the X component. A subpass can declare via a second creation flag whether all pipelines compiled for this subpass will obey this restriction.

Shaders that use the new per-view outputs (e.g. gl_PositionPerViewNV) must also write the non-per-view output (gl_Position), and the values written must be such that gl_Position = gl_PositionPerViewNV[gl_ViewIndex] for all views in the subpass. Implementations are free to either use the per-view outputs or the non-per-view outputs, whichever would be more efficient.

If VK_NV_viewport_array2 is not also supported and enabled, the per-view viewport mask must not be used.

New Enum Constants

  • VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_EXTENSION_NAME

  • VK_NVX_MULTIVIEW_PER_VIEW_ATTRIBUTES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_ATTRIBUTES_PROPERTIES_NVX

  • Extending VkSubpassDescriptionFlagBits:

    • VK_SUBPASS_DESCRIPTION_PER_VIEW_ATTRIBUTES_BIT_NVX

    • VK_SUBPASS_DESCRIPTION_PER_VIEW_POSITION_X_ONLY_BIT_NVX

New Built-In Variables

New SPIR-V Capabilities

Examples

#version 450 core

#extension GL_KHX_multiview : enable
#extension GL_NVX_multiview_per_view_attributes : enable

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

void main()
{
    // Output both per-view positions and gl_Position as a function
    // of gl_ViewIndex
    gl_PositionPerViewNV[0] = buf.mvpPerView[0] * position;
    gl_PositionPerViewNV[1] = buf.mvpPerView[1] * position;
    gl_Position = buf.mvpPerView[gl_ViewIndex] * position;
}

Version History

  • Revision 1, 2017-01-13 (Jeff Bolz)

    • Internal revisions

VK_QCOM_fragment_density_map_offset

Name String

VK_QCOM_fragment_density_map_offset

Extension Type

Device extension

Registered Extension Number

426

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-09-03

Contributors
  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Jonathan Wicks, Qualcomm Technologies, Inc.

  • Jonathan Tinkham, Qualcomm Technologies, Inc.

  • Jeff Leger, Qualcomm Technologies, Inc.

Description

This extension allows an application to specify offsets to a fragment density map attachment, changing the framebuffer location where density values are applied to without having to regenerate the fragment density map.

New Enum Constants

  • VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_EXTENSION_NAME

  • VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_QCOM

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_PROPERTIES_QCOM

    • VK_STRUCTURE_TYPE_SUBPASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_QCOM

Version History

  • Revision 1, 2021-09-03 (Matthew Netsch)

    • Initial version

VK_QCOM_image_processing

Name String

VK_QCOM_image_processing

Extension Type

Device extension

Registered Extension Number

441

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_QCOM_image_processing

Other Extension Metadata

Last Modified Date

2022-07-08

Interactions and External Dependencies
Contributors
  • Jeff Leger, Qualcomm Technologies, Inc.

  • Ruihao Zhang, Qualcomm Technologies, Inc.

Description

GPUs are commonly used to process images for various applications from 3D graphics to UI and from composition to compute applications. Simple scaling and filtering can be done with bilinear filtering, which comes for free during texture sampling. However, as screen sizes get larger and more use cases rely on GPU such as camera and video post-processing needs, there is increasing demand for GPU to support higher order filtering and other advanced image processing.

This extension introduces a new set of SPIR-V built-in functions for image processing. It exposes the following new imaging operations

  • The OpImageSampleWeightedQCOM instruction takes 3 operands: sampled image, weight image, and texture coordinates. The instruction computes a weighted average of an MxN region of texels in the sampled image, using a set of MxN weights in the weight image.

  • The OpImageBoxFilterQCOM instruction takes 3 operands: sampled image, box size, and texture coordinates. Note that box size specifies a floating point width and height in texels. The instruction computes a weighted average of all texels in the sampled image that are covered (either partially or fully) by a box with the specified size and centered at the specified texture coordinates.

  • The OpImageBlockMatchSADQCOM and OpImageBlockMatchSSDQCOM instructions each takes 5 operands: target image, target coordinates, reference image, reference coordinates, and block size. Each instruction computes an error metric, that describes whether a block of texels in the target image matches a corresponding block of texels in the reference image. The error metric is computed per-component. OpImageBlockMatchSADQCOM computes "Sum Of Absolute Difference" and OpImageBlockMatchSSDQCOM computes "Sum of Squared Difference".

Each of the image processing instructions operate only on 2D images. The instructions do not-support sampling of mipmap, multi-plane, multi-layer, multi-sampled, or depth/stencil images. The instructions can be used in any shader stage.

Implementations of this this extension should support these operations natively at the HW instruction level, offering potential performance gains as well as ease of development.

New Enum Constants

  • VK_QCOM_IMAGE_PROCESSING_EXTENSION_NAME

  • VK_QCOM_IMAGE_PROCESSING_SPEC_VERSION

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM

    • VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM

  • Extending VkImageUsageFlagBits:

    • VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM

    • VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM

  • Extending VkSamplerCreateFlagBits:

    • VK_SAMPLER_CREATE_IMAGE_PROCESSING_BIT_QCOM

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_SAMPLE_WEIGHT_CREATE_INFO_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_PROPERTIES_QCOM

If VK_KHR_format_feature_flags2 is supported:

  • Extending VkFormatFeatureFlagBits2:

    • VK_FORMAT_FEATURE_2_BLOCK_MATCHING_BIT_QCOM

    • VK_FORMAT_FEATURE_2_BOX_FILTER_SAMPLED_BIT_QCOM

    • VK_FORMAT_FEATURE_2_WEIGHT_IMAGE_BIT_QCOM

    • VK_FORMAT_FEATURE_2_WEIGHT_SAMPLED_IMAGE_BIT_QCOM

Version History

  • Revision 1, 2022-07-08 (Jeff Leger)

VK_QCOM_multiview_per_view_render_areas

Name String

VK_QCOM_multiview_per_view_render_areas

Extension Type

Device extension

Registered Extension Number

511

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2023-01-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Leger, Qualcomm

  • Jonathan Tinkham, Qualcomm

  • Jonathan Wicks, Qualcomm

Description

Certain use cases (e.g., side-by-side VR rendering) use multiview and render to distinct regions of the framebuffer for each view. On some implementations, there may be a performance benefit for providing per-view render areas to the implementation. Such per-view render areas can be used by the implementation to reduce the pixels that are affected by attachment load, store, and multisample resolve operations.

The extension enables a multiview render pass instance to define per-view render areas. For each view of a multiview render pass instance, only those pixels in the per-view render area are affected by load, store and resolve operations.

New Enum Constants

  • VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_EXTENSION_NAME

  • VK_QCOM_MULTIVIEW_PER_VIEW_RENDER_AREAS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_RENDER_AREAS_RENDER_PASS_BEGIN_INFO_QCOM

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_RENDER_AREAS_FEATURES_QCOM

Issues

1) Do the per-view renderAreas interact with vkGetRenderAreaGranularity ?

RESOLVED: There is no change. The granularity returned by vkGetRenderAreaGranularity also applies to the per-view renderAreas.

2) How does this extension interact with VK_QCOM_render_pass_transform?

RESOLVED: When VK_QCOM_render_pass_transform is enabled, the application provides render area in non-rotated coordinates which is rotated by the implementation to the rotated coordinate system. When this extension is used in combination with VK_QCOM_render_pass_transform, then the renderArea provided in VkRenderingInfo::renderArea, VkRenderPassBeginInfo::renderArea, or VkCommandBufferInheritanceRenderPassTransformInfoQCOM::renderArea is rotated by the implementation. The per-view render areas are not rotated.

3) How does this extension interact with VK_QCOM_multiview_per_view_viewports

RESOLVED: There is no direct interaction. The per-view viewports and the per-view renderAreas are orthogonal features.

4) When a per-view renderArea is specified, must multiview rendering for each view of a multiview render pass be contained within the per-view renderArea?

RESOLVED: Yes, and the VK_QCOM_multiview_per_view_viewports may help here since it provides per-view scissors.

5) When per-view render areas are specified, what purpose if any do VkRenderPassBeginInfo::renderArea and VkRenderingInfo::renderArea serve?

RESOLVED: The per-view renderArea effectively overrides the per-renderpass renderArea. The per-view renderArea defines the regions of the attachments that are effected by load, store, and multisample resolve operations. A valid implementation could ignore the per-renderpass renderArea. However, as an aid to the implementation, the application must set the per-renderpass renderArea to an area that is at least as large as the union of all the per-view render areas. Pixels that are within the per-renderpass renderArea but not within any per-view render area must not be affected by load, store, or multisample resolve operations.

Version History

  • Revision 1, 2023-01-10 (Jeff Leger)

VK_QCOM_multiview_per_view_viewports

Name String

VK_QCOM_multiview_per_view_viewports

Extension Type

Device extension

Registered Extension Number

489

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-11-22

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Leger, Qualcomm

  • Jonathan Tinkham, Qualcomm

  • Jonathan Wicks, Qualcomm

Description

Certain use cases for multiview have a need for specifying a separate viewport and scissor for each view, without using shader-based viewport indexing as introduced with VK_EXT_shader_viewport_index_layer.

This extension adds a new way to control ViewportIndex with multiview. When the multiviewPerViewViewports feature is enabled and if the last pre-rasterization shader entry point’s interface does not use the ViewportIndex built-in decoration, then each view of a multiview render pass instance will use a viewport and scissor index equal to the ViewIndex.

New Enum Constants

  • VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_EXTENSION_NAME

  • VK_QCOM_MULTIVIEW_PER_VIEW_VIEWPORTS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PER_VIEW_VIEWPORTS_FEATURES_QCOM

Issues

1) Is is possible to enable/disable the multiviewPerViewViewports feature for individual render pass instances?

RESOLVED: No, when the multiviewPerViewViewports feature is enabled during vkCreateDevice, then all created render pass instances (including dynamic render passes from VK_KHR_dynamic_rendering) and all created VkPipelines will have the feature enabled. This approach was chosen because it simplifies application code and there is no known use case enable/disable the feature for individual render passes or pipelines.

2) When this extension is used, is the value of ViewportIndex implicitly written by the last pre-rasterization shader stage and can the value of ViewportIndex be read in the fragment shader?

RESOLVED: No, use of the extension extension does not add an implicit write to ViewportIndex in any shader stage, and additionally, the value of ViewportIndex in the fragment shader is undefined.

Version History

  • Revision 1, 2022-11-22 (Jeff Leger)

VK_QCOM_render_pass_shader_resolve

Name String

VK_QCOM_render_pass_shader_resolve

Extension Type

Device extension

Registered Extension Number

172

Revision

4

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Bill Licea-Kane wwlk

Other Extension Metadata

Last Modified Date

2019-11-07

IP Status

No known IP claims.

Interactions and External Dependencies

None.

Contributors
  • Srihari Babu Alla, Qualcomm

  • Bill Licea-Kane, Qualcomm

  • Jeff Leger, Qualcomm

Description

This extension allows a shader resolve to replace fixed-function resolve.

Fixed-function resolve is limited in function to simple filters of multisample buffers to a single sample buffer.

Fixed-function resolve is more performance efficient and/or power efficient than shader resolve for such simple filters.

Shader resolve allows a shader writer to create complex, non-linear filtering of a multisample buffer in the last subpass of a subpass dependency chain.

This extension also provides a bit which can be used to enlarge a sample region dependency to a fragment region dependency, so that a framebuffer-region dependency can replace a framebuffer-global dependency in some cases.

New Enum Constants

  • VK_QCOM_RENDER_PASS_SHADER_RESOLVE_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_SHADER_RESOLVE_SPEC_VERSION

  • Extending VkSubpassDescriptionFlagBits:

    • VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM

    • VK_SUBPASS_DESCRIPTION_SHADER_RESOLVE_BIT_QCOM

Issues

1) Should this extension be named render_pass_shader_resolve?

RESOLVED Yes.

This is part of suite of small extensions to render pass.

Following the style guide, instead of following VK_KHR_create_renderpass2.

2) Should the VK_SAMPLE_COUNT_1_BIT be required for each pColorAttachment and the DepthStencilAttachent?

RESOLVED No.

While this may not be a common use case, and while most fixed-function resolve hardware has this limitation, there is little reason to require a shader resolve to resolve to a single sample buffer.

3) Should a shader resolve subpass be the last subpass in a render pass?

RESOLVED Yes.

To be more specific, it should be the last subpass in a subpass dependency chain.

4) Do we need the VK_SUBPASS_DESCRIPTION_FRAGMENT_REGION_BIT_QCOM bit?

RESOLVED Yes.

This applies when an input attachment’s sample count is equal to rasterizationSamples. Further, if sampleShading is enabled (explicitly or implicitly) then minSampleShading must equal 0.0.

However, this bit may be set on any subpass, it is not restricted to a shader resolve subpass.

Version History

  • Revision 1, 2019-06-28 (wwlk)

    • Initial draft

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

    • General clean-up/spec updates

    • Added issues

  • Revision 3, 2019-11-07 (wwlk)

    • Typos

    • Additional issues

    • Clarified that a shader resolve subpass is the last subpass in a subpass dependency chain

  • Revision 4, 2020-01-06 (wwlk)

    • Change resolution of Issue 1 (render_pass, not renderpass)

VK_QCOM_render_pass_store_ops

Name String

VK_QCOM_render_pass_store_ops

Extension Type

Device extension

Registered Extension Number

302

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Bill Licea-Kane wwlk

Other Extension Metadata

Last Modified Date

2020-03-25

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

Description

Render pass attachments can be read-only for the duration of a render pass.

Examples include input attachments and depth attachments where depth tests are enabled but depth writes are not enabled.

In such cases, there can be no contents generated for an attachment within the render area.

This extension adds a new VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_NONE_QCOM specifying that the contents within the render area may not be written to memory, but that the prior contents of the attachment in memory are preserved. However, if any contents were generated within the render area during rendering, the contents of the attachment will be undefined inside the render area.

Note

The VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_STORE may force an implementation to assume that the attachment was written and force an implementation to flush data to memory or to a higher level cache. The VkAttachmentStoreOp VK_ATTACHMENT_STORE_OP_NONE_QCOM may allow an implementation to assume that the attachment was not written and allow an implementation to avoid such a flush.

New Enum Constants

  • VK_QCOM_RENDER_PASS_STORE_OPS_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_STORE_OPS_SPEC_VERSION

  • Extending VkAttachmentStoreOp:

    • VK_ATTACHMENT_STORE_OP_NONE_QCOM

Version History

  • Revision 1, 2019-12-20 (wwlk)

    • Initial version

  • Revision 2, 2020-03-25 (wwlk)

    • Minor renaming

VK_QCOM_render_pass_transform

Name String

VK_QCOM_render_pass_transform

Extension Type

Device extension

Registered Extension Number

283

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2022-07-21

Interactions and External Dependencies
Contributors
  • Jeff Leger, Qualcomm Technologies, Inc.

  • Brandon Light, Qualcomm Technologies, Inc.

  • Matthew Netsch, Qualcomm Technologies, Inc.

Description

This extension provides a mechanism for applications to enable driver support for render pass transform.

Mobile devices can be rotated and mobile applications need to render properly when a device is held in a landscape or portrait orientation. When the current orientation differs from the device’s native orientation, a rotation is required so that the “up” direction of the rendered scene matches the current orientation.

If the Display Processing Unit (DPU) does not natively support rotation, the Vulkan presentation engine can handle this rotation in a separate composition pass. Alternatively, the application can render frames “pre-rotated” to avoid this extra pass. The latter is preferred to reduce power consumption and achieve the best performance because it avoids tasking the GPU with extra work to perform the copy/rotate operation.

Unlike OpenGL ES, the burden of pre-rotation in Vulkan falls on the application. To implement pre-rotation, applications render into swapchain images matching the device native aspect ratio of the display and “pre-rotate” the rendering content to match the device’s current orientation. The burden is more than adjusting the Model View Projection (MVP) matrix in the vertex shader to account for rotation and aspect ratio. The coordinate systems of scissors, viewports, derivatives and several shader built-ins may need to be adapted to produce the correct result.

It is difficult for some game engines to manage this burden; many chose to simply accept the performance/power overhead of performing rotation in the presentation engine.

This extension allows applications to achieve the performance benefits of pre-rotated rendering by moving much of the above-mentioned burden to the graphics driver. The following is unchanged with this extension:

The following is changed with this extension:

New Enum Constants

  • VK_QCOM_RENDER_PASS_TRANSFORM_EXTENSION_NAME

  • VK_QCOM_RENDER_PASS_TRANSFORM_SPEC_VERSION

  • Extending VkRenderPassCreateFlagBits:

    • VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM

    • VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM

Issues

1) Some early Adreno drivers (October 2019 through March 2020) advertised support for this extension but expected VK_STRUCTURE_TYPE values different from those in the vukan headers. To cover all Adreno devices on the market, applications need to detect the driver version and use the appropriate VK_STRUCTURE_TYPE values from the table below.

The driver version reported in VkPhysicalDeviceProperties.driverVersion is a uint32_t type. You can decode the uint32_t value into a major.minor.patch version as shown below:

uint32_t  major = ((driverVersion) >> 22);
uint32_t  minor = ((driverVersion) >> 12) & 0x3ff);
uint32_t  patch = ((driverVersion) & 0xfff);

If the Adreno major.minor.patch version is greater than or equal to to 512.469.0, then simply use the VK_STRUCTURE_TYPE values as defined in vulkan_core.h. If the version is less than or equal to to 512.468.0, then use the alternate values for the two VK_STRUCTURE_TYPEs in the table below.

Table 96. Adreno Driver Requirements
Adreno Driver Version

512.468.0 and earlier

512.469.0 and later

VK_STRUCTURE_TYPE_ RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM

1000282000

1000282001

VK_STRUCTURE_TYPE_ COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM

1000282001

1000282000

2) Should the extension support only rotations (e.g. 90, 180, 270-degrees), or also mirror transforms (e.g. vertical flips)? Mobile use cases only require rotation. Other display systems such as projectors might require a flipped transform.

RESOLVED: In this version of the extension, the functionality is restricted to 90, 180, and 270-degree rotations to address mobile use cases.

3) How does this extension interact with VK_EXT_fragment_density_map?

RESOLVED Some implementations may not be able to support a render pass that enables both render pass transform and fragment density maps. For simplicity, this extension disallows enabling both features within a single render pass.

4) What should this extension be named?

We considered names such as “rotated_rendering”, “pre_rotation” and others. Since the functionality is limited to a render pass, it seemed the name should include “render_pass”. While the current extension is limited to rotations, it could be extended to other transforms (like mirror) in the future.

RESOLVED The name “render_pass_transform” seems like the most accurate description of the introduced functionality.

5) How does this extension interact with VK_KHR_fragment_shading_rate?

RESOLVED: For the same reasons as issue 3, this extension disallows enabling both pFragmentShadingRateAttachment and render pass transform within a single render pass.

However, pipeline shading rate and primitive shading rate are supported, and their respective fragmentSize and PrimitiveShadingRateKHR are provided in the current (non-rotated) coordinate system. The implementation is responsible for transforming them to the rotated coordinate system.

The set of supported shading rates may be different per transform. Supported rates queried from vkGetPhysicalDeviceFragmentShadingRatesKHR are in the native (rotated) coordinate system. This means that the application must swap the x/y of the reported rates to get the set of rates supported for 90 and 270 degree rotation.

Version History

  • Revision 1, 2020-02-05 (Jeff Leger)

  • Revision 2, 2021-03-09 (Matthew Netsch)

    • Adds interactions with VK_KHR_fragment_shading_rate

  • Revision 3, 2022-07-11 (Arpit Agarwal)

    • Adds interactions with VK_QCOM_tile_properties

VK_QCOM_rotated_copy_commands

Name String

VK_QCOM_rotated_copy_commands

Extension Type

Device extension

Registered Extension Number

334

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2020-09-18

Interactions and External Dependencies
  • None

Contributors
  • Jeff Leger, Qualcomm Technologies, Inc.

Description

This extension extends adds an optional rotation transform to copy commands vkCmdBlitImage2KHR, vkCmdCopyImageToBuffer2KHR and vkCmdCopyBufferToImage2KHR. When copying between two resources, where one resource contains rotated content and the other does not, a rotated copy may be desired. This extension may be used in combination with VK_QCOM_render_pass_transform which adds rotated render passes.

This extension adds an extension structure to the following commands: vkCmdBlitImage2KHR, vkCmdCopyImageToBuffer2KHR and vkCmdCopyBufferToImage2KHR

Issues

1) What is an appropriate name for the added extension structure? The style guide says “Structures which extend other structures through the pNext chain should reflect the name of the base structure they extend.”, but in this case a single extension structure is used to extend three base structures (vkCmdBlitImage2KHR, vkCmdCopyImageToBuffer2KHR and vkCmdCopyBufferToImage2KHR). Creating three identical structures with unique names seemed undesirable.

RESOLVED: Deviate from the style guide for extension structure naming.

2) Should this extension add a rotation capability to vkCmdCopyImage2KHR?

RESOLVED: No. Use of rotated vkCmdBlitImage2KHR can fully address this use case.

3) Should this extension add a rotation capability to vkCmdResolveImage2KHR?

RESOLVED No. Use of vkCmdResolveImage2KHR is very slow and extremely bandwidth intensive on Qualcomm’s GPU architecture and use of pResolveAttachments in vkRenderPass is the strongly preferred approach. Therefore, we choose not to introduce a rotation capability to vkCmdResolveImage2KHR.

New Enum Constants

  • VK_QCOM_ROTATED_COPY_COMMANDS_EXTENSION_NAME

  • VK_QCOM_ROTATED_COPY_COMMANDS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COPY_COMMAND_TRANSFORM_INFO_QCOM

Version History

  • Revision 1, 2020-09-19 (Jeff Leger)

VK_QCOM_tile_properties

Name String

VK_QCOM_tile_properties

Extension Type

Device extension

Registered Extension Number

485

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
Extension Proposal

VK_QCOM_tile_properties

Other Extension Metadata

Last Modified Date

2022-07-11

Interactions and External Dependencies
Contributors
  • Jonathan Wicks, Qualcomm Technologies, Inc.

  • Jonathan Tinkham, Qualcomm Technologies, Inc.

  • Arpit Agarwal, Qualcomm Technologies, Inc.

  • Jeff Leger, Qualcomm Technologies, Inc.

Description

This extension allows an application to query the tile properties. This extension supports both renderpasses and dynamic rendering.

New Enum Constants

  • VK_QCOM_TILE_PROPERTIES_EXTENSION_NAME

  • VK_QCOM_TILE_PROPERTIES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TILE_PROPERTIES_FEATURES_QCOM

    • VK_STRUCTURE_TYPE_TILE_PROPERTIES_QCOM

Version History

  • Revision 1, 2022-07-11 (Arpit Agarwal)

    • Initial version

VK_QNX_screen_surface

Name String

VK_QNX_screen_surface

Extension Type

Instance extension

Registered Extension Number

379

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact

Other Extension Metadata

Last Modified Date

2021-01-11

IP Status

No known IP claims.

Contributors
  • Mike Gorchak, BlackBerry Limited

Description

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

New Enum Constants

  • VK_QNX_SCREEN_SURFACE_EXTENSION_NAME

  • VK_QNX_SCREEN_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_SCREEN_SURFACE_CREATE_INFO_QNX

Version History

  • Revision 1, 2021-01-11 (Mike Gorchak)

    • Initial draft.

VK_SEC_amigo_profiling

Name String

VK_SEC_amigo_profiling

Extension Type

Device extension

Registered Extension Number

486

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Contact
  • Ralph Potter r_potter

Other Extension Metadata

Last Modified Date

2022-07-29

IP Status

No known IP claims.

Contributors
  • Ralph Potter, Samsung

  • Sangrak Oh, Samsung

  • Jinku Kang, Samsung

Description

This extension is intended to communicate information from layered API implementations such as ANGLE to internal proprietary system schedulers. It has no behavioural implications beyond enabling more intelligent behaviour from the system scheduler.

Application developers should avoid using this extension. It is documented solely for the benefit of tools and layer developers, who may need to manipulate pNext chains that include these structures.

Note

There is currently no specification language written for this extension. The links to APIs defined by the extension are to stubs that only include generated content such as API declarations and implicit valid usage statements.

Note

This extension is only intended for use in specific embedded environments with known implementation details, and is therefore undocumented.

New Enum Constants

  • VK_SEC_AMIGO_PROFILING_EXTENSION_NAME

  • VK_SEC_AMIGO_PROFILING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC

Stub API References

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_SEC_amigo_profiling
typedef struct VkPhysicalDeviceAmigoProfilingFeaturesSEC {
    VkStructureType    sType;
    void*              pNext;
    VkBool32           amigoProfiling;
} VkPhysicalDeviceAmigoProfilingFeaturesSEC;
Valid Usage (Implicit)
  • VUID-VkPhysicalDeviceAmigoProfilingFeaturesSEC-sType-sType
    sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_SEC_amigo_profiling
typedef struct VkAmigoProfilingSubmitInfoSEC {
    VkStructureType    sType;
    const void*        pNext;
    uint64_t           firstDrawTimestamp;
    uint64_t           swapBufferTimestamp;
} VkAmigoProfilingSubmitInfoSEC;
Valid Usage (Implicit)
  • VUID-VkAmigoProfilingSubmitInfoSEC-sType-sType
    sType must be VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC

Version History

  • Revision 1, 2022-07-29 (Ralph Potter)

    • Initial specification

VK_VALVE_descriptor_set_host_mapping

Name String

VK_VALVE_descriptor_set_host_mapping

Extension Type

Device extension

Registered Extension Number

421

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Special Use
Contact

Other Extension Metadata

Last Modified Date

2022-02-22

IP Status

No known IP claims.

Contributors
  • Hans-Kristian Arntzen, Valve

Description

This extension allows applications to directly query a host pointer for a VkDescriptorSet which can be used to copy descriptors between descriptor sets without the use of an API command. Memory offsets and sizes for descriptors can be queried from a VkDescriptorSetLayout as well.

Note

There is currently no specification language written for this extension. The links to APIs defined by the extension are to stubs that only include generated content such as API declarations and implicit valid usage statements.

Note

This extension is only intended for use in specific embedded environments with known implementation details, and is therefore undocumented.

New Enum Constants

  • VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_EXTENSION_NAME

  • VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE

Stub API References

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetLayoutHostMappingInfoVALVE(
    VkDevice                                    device,
    const VkDescriptorSetBindingReferenceVALVE* pBindingReference,
    VkDescriptorSetLayoutHostMappingInfoVALVE*  pHostMapping);
Valid Usage (Implicit)
  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pBindingReference-parameter
    pBindingReference must be a valid pointer to a valid VkDescriptorSetBindingReferenceVALVE structure

  • VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pHostMapping-parameter
    pHostMapping must be a valid pointer to a VkDescriptorSetLayoutHostMappingInfoVALVE structure

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_VALVE_descriptor_set_host_mapping
void vkGetDescriptorSetHostMappingVALVE(
    VkDevice                                    device,
    VkDescriptorSet                             descriptorSet,
    void**                                      ppData);
Valid Usage (Implicit)
  • VUID-vkGetDescriptorSetHostMappingVALVE-device-parameter
    device must be a valid VkDevice handle

  • VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parameter
    descriptorSet must be a valid VkDescriptorSet handle

  • VUID-vkGetDescriptorSetHostMappingVALVE-ppData-parameter
    ppData must be a valid pointer to a pointer value

  • VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parent
    descriptorSet must have been created, allocated, or retrieved from device

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE {
    VkStructureType    sType;
    void*              pNext;
    VkBool32           descriptorSetHostMapping;
} VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE;
Valid Usage (Implicit)
  • VUID-VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE-sType-sType
    sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetBindingReferenceVALVE {
    VkStructureType          sType;
    const void*              pNext;
    VkDescriptorSetLayout    descriptorSetLayout;
    uint32_t                 binding;
} VkDescriptorSetBindingReferenceVALVE;
Valid Usage (Implicit)
  • VUID-VkDescriptorSetBindingReferenceVALVE-sType-sType
    sType must be VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE

  • VUID-VkDescriptorSetBindingReferenceVALVE-pNext-pNext
    pNext must be NULL

  • VUID-VkDescriptorSetBindingReferenceVALVE-descriptorSetLayout-parameter
    descriptorSetLayout must be a valid VkDescriptorSetLayout handle

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

// Provided by VK_VALVE_descriptor_set_host_mapping
typedef struct VkDescriptorSetLayoutHostMappingInfoVALVE {
    VkStructureType    sType;
    void*              pNext;
    size_t             descriptorOffset;
    uint32_t           descriptorSize;
} VkDescriptorSetLayoutHostMappingInfoVALVE;
Valid Usage (Implicit)
  • VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-sType-sType
    sType must be VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE

  • VUID-VkDescriptorSetLayoutHostMappingInfoVALVE-pNext-pNext
    pNext must be NULL

Version History

  • Revision 1, 2022-02-22 (Hans-Kristian Arntzen)

    • Initial specification

List of Provisional Extensions

VK_KHR_portability_subset

Name String

VK_KHR_portability_subset

Extension Type

Device extension

Registered Extension Number

164

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
  • This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

Other Extension Metadata

Last Modified Date

2020-07-21

IP Status

No known IP claims.

Contributors
  • Bill Hollings, The Brenwill Workshop Ltd.

  • Daniel Koch, NVIDIA

  • Dzmitry Malyshau, Mozilla

  • Chip Davis, CodeWeavers

  • Dan Ginsburg, Valve

  • Mike Weiblen, LunarG

  • Neil Trevett, NVIDIA

  • Alexey Knyazev, Independent

Description

The VK_KHR_portability_subset extension allows a non-conformant Vulkan implementation to be built on top of another non-Vulkan graphics API, and identifies differences between that implementation and a fully-conformant native Vulkan implementation.

This extension provides Vulkan implementations with the ability to mark otherwise-required capabilities as unsupported, or to establish additional properties and limits that the application should adhere to in order to guarantee portable behaviour and operation across platforms, including platforms where Vulkan is not natively supported.

The goal of this specification is to document, and make queryable, capabilities which are required to be supported by a fully-conformant Vulkan 1.0 implementation, but may be optional for an implementation of the Vulkan 1.0 Portability Subset.

The intent is that this extension will be advertised only on implementations of the Vulkan 1.0 Portability Subset, and not on conformant implementations of Vulkan 1.0. Fully-conformant Vulkan implementations provide all the required capabilities, and so will not provide this extension. Therefore, the existence of this extension can be used to determine that an implementation is likely not fully conformant with the Vulkan spec.

If this extension is supported by the Vulkan implementation, the application must enable this extension.

This extension defines several new structures that can be chained to the existing structures used by certain standard Vulkan calls, in order to query for non-conformant portable behavior.

New Enum Constants

  • VK_KHR_PORTABILITY_SUBSET_EXTENSION_NAME

  • VK_KHR_PORTABILITY_SUBSET_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_PROPERTIES_KHR

Issues

None.

Version History

  • Revision 1, 2020-07-21 (Bill Hollings)

    • Initial draft.

VK_KHR_video_encode_queue

Name String

VK_KHR_video_encode_queue

Extension Type

Device extension

Registered Extension Number

300

Revision

10

Ratification Status

Ratified

Extension and Version Dependencies
  • This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

Other Extension Metadata

Last Modified Date

2023-07-19

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.

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

Issues

1) Why is there no VK_PIPELINE_STAGE_VIDEO_ENCODE_BIT_KHR?

RESOLVED: This extension requires VK_KHR_synchronization2 because the new access flags introduced did not fit in the 32-bit enum VkAccessFlagBits. Accordingly, all new pipeline stage and access flags have been added to the corresponding 64-bit enum and no new flags have been added to the legacy 32-bit enums. While the new pipeline stage flag introduced uses bit #27 which would also fit in the legacy VkPipelineStageFlagBits enum, there is no real benefit to include it. Instead the bit is marked reserved.

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

VK_EXT_video_encode_h264

Name String

VK_EXT_video_encode_h264

Extension Type

Device extension

Registered Extension Number

39

Revision

12

Ratification Status

Not ratified

Extension and Version Dependencies
  • This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

Other Extension Metadata

Last Modified Date

2023-07-19

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.

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.

New Enum Constants

  • VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME

  • VK_EXT_VIDEO_ENCODE_H264_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_CAPABILITIES_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_DPB_SLOT_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_GOP_REMAINING_FRAME_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_NALU_SLICE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PICTURE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PROFILE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_QUALITY_LEVEL_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_RATE_CONTROL_LAYER_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_ADD_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_FEEDBACK_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_SESSION_PARAMETERS_GET_INFO_EXT

  • Extending VkVideoCodecOperationFlagBitsKHR:

    • VK_VIDEO_CODEC_OPERATION_ENCODE_H264_BIT_EXT

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

VK_EXT_video_encode_h265

Name String

VK_EXT_video_encode_h265

Extension Type

Device extension

Registered Extension Number

40

Revision

12

Ratification Status

Not ratified

Extension and Version Dependencies
  • This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

Other Extension Metadata

Last Modified Date

2023-07-19

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.

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.

New Enum Constants

  • VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME

  • VK_EXT_VIDEO_ENCODE_H265_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_CAPABILITIES_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_DPB_SLOT_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_GOP_REMAINING_FRAME_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_NALU_SLICE_SEGMENT_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PICTURE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PROFILE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_QUALITY_LEVEL_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_RATE_CONTROL_LAYER_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_ADD_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_FEEDBACK_INFO_EXT

    • VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_SESSION_PARAMETERS_GET_INFO_EXT

  • Extending VkVideoCodecOperationFlagBitsKHR:

    • VK_VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_EXT

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 VkVideoEncodeH264RateControlLayerInfoEXT::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 VkVideoEncodeH264VclFrameInfoEXT and VkVideoEncodeH264NaluSliceInfoEXT 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

List of Deprecated Extensions

VK_KHR_16bit_storage

Name String

VK_KHR_16bit_storage

Extension Type

Device extension

Registered Extension Number

84

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, ARM

  • Jan-Harald Fredriksen, ARM

  • Joerg Wagner, ARM

  • Neil Henning, Codeplay

  • Jeff Bolz, Nvidia

  • Daniel Koch, Nvidia

  • David Neto, Google

  • John Kessenich, Google

Description

The VK_KHR_16bit_storage extension allows use of 16-bit types in shader input and output interfaces, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 16-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class. This extension allows 16-bit variables to be declared and used as user-defined shader inputs and outputs but does not change location assignment and component assignment rules.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. However, if Vulkan 1.1 is supported and this extension is not, the storageBuffer16BitAccess capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_16BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_16BIT_STORAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR

Version History

  • Revision 1, 2017-03-23 (Alexander Galazin)

    • Initial draft

VK_KHR_8bit_storage

Name String

VK_KHR_8bit_storage

Extension Type

Device extension

Registered Extension Number

178

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-02-05

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Alexander Galazin, Arm

Description

The VK_KHR_8bit_storage extension allows use of 8-bit types in uniform and storage buffers, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 8-bit data in Block-decorated objects in the Uniform and the StorageBuffer storage classes, and objects in the PushConstant storage class.

The StorageBuffer8BitAccess capability must be supported by all implementations of this extension. The other capabilities are optional.

Promotion to Vulkan 1.2

Functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the StorageBuffer8BitAccess capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_8BIT_STORAGE_EXTENSION_NAME

  • VK_KHR_8BIT_STORAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR

Version History

  • Revision 1, 2018-02-05 (Alexander Galazin)

    • Initial draft

VK_KHR_bind_memory2

Name String

VK_KHR_bind_memory2

Extension Type

Device extension

Registered Extension Number

158

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

Description

This extension provides versions of vkBindBufferMemory and vkBindImageMemory that allow multiple bindings to be performed at once, and are extensible.

This extension also introduces VK_IMAGE_CREATE_ALIAS_BIT_KHR, which allows “identical” images that alias the same memory to interpret the contents consistently, even across image layout changes.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_BIND_MEMORY_2_EXTENSION_NAME

  • VK_KHR_BIND_MEMORY_2_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_ALIAS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR

Version History

  • Revision 1, 2017-05-19 (Tobias Hector)

    • Pulled bind memory functions into their own extension

VK_KHR_buffer_device_address

Name String

VK_KHR_buffer_device_address

Extension Type

Device extension

Registered Extension Number

258

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-06-24

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Neil Henning, AMD

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Baldur Karlsson, Valve

  • Jan-Harald Fredriksen, Arm

Description

This extension allows the application to query a 64-bit buffer device address value for a buffer, which can be used to access the buffer memory via the PhysicalStorageBuffer storage class in the GL_EXT_buffer_reference GLSL extension and SPV_KHR_physical_storage_buffer SPIR-V extension.

Another way to describe this extension is that it adds “pointers to buffer memory in shaders”. By calling vkGetBufferDeviceAddress with a VkBuffer, it will return a VkDeviceAddress value which represents the address of the start of the buffer.

vkGetBufferOpaqueCaptureAddress and vkGetDeviceMemoryOpaqueCaptureAddress allow opaque addresses for buffers and memory objects to be queried for the current process. A trace capture and replay tool can then supply these addresses to be used at replay time to match the addresses used when the trace was captured. To enable tools to insert these queries, new memory allocation flags must be specified for memory objects that will be bound to buffers accessed via the PhysicalStorageBuffer storage class. Note that this mechanism is intended only to support capture/replay tools, and is not recommended for use in other applications.

There are various use cases this extension is designed for. It is required for ray tracing, useful for DX12 portability, and by allowing buffer addresses to be stored in memory it enables more complex data structures to be created.

This extension can also be used to hardcode a dedicated debug channel into all shaders by querying a pointer at startup and pushing that into shaders as a run-time constant (e.g. specialization constant) that avoids impacting other descriptor limits.

There are examples of usage in the GL_EXT_buffer_reference spec for how to use this in a high-level shading language such as GLSL. The GL_EXT_buffer_reference2 and GL_EXT_buffer_reference_uvec2 extensions were also added to help cover a few additional edge cases.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the bufferDeviceAddress feature is optional. The original type, enum and command names are still available as aliases of the core functionality.

Promotion to Vulkan 1.3

Support for the bufferDeviceAddress feature is mandatory in Vulkan 1.3, regardless of whether this extension is supported.

New Enum Constants

  • VK_KHR_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME

  • VK_KHR_BUFFER_DEVICE_ADDRESS_SPEC_VERSION

  • Extending VkBufferCreateFlagBits:

    • VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR

  • Extending VkMemoryAllocateFlagBits:

    • VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT_KHR

    • VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR

  • Extending VkResult:

    • VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_BUFFER_OPAQUE_CAPTURE_ADDRESS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_MEMORY_OPAQUE_CAPTURE_ADDRESS_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_OPAQUE_CAPTURE_ADDRESS_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_KHR

New SPIR-V Capabilities

Version History

  • Revision 1, 2019-06-24 (Jan-Harald Fredriksen)

    • Internal revisions based on VK_EXT_buffer_device_address

VK_KHR_copy_commands2

Name String

VK_KHR_copy_commands2

Extension Type

Device extension

Registered Extension Number

338

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-07-06

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

Interactions and External Dependencies
  • None

Contributors
  • Jeff Leger, Qualcomm

  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, ARM

  • Tom Olson, ARM

Description

This extension provides extensible versions of the Vulkan buffer and image copy commands. The new commands are functionally identical to the core commands, except that their copy parameters are specified using extensible structures that can be used to pass extension-specific information.

The following extensible copy commands are introduced with this extension: vkCmdCopyBuffer2KHR, vkCmdCopyImage2KHR, vkCmdCopyBufferToImage2KHR, vkCmdCopyImageToBuffer2KHR, vkCmdBlitImage2KHR, and vkCmdResolveImage2KHR. Each command contains an *Info2KHR structure parameter that includes sType/pNext members. Lower level structures describing each region to be copied are also extended with sType/pNext members.

New Enum Constants

  • VK_KHR_COPY_COMMANDS_2_EXTENSION_NAME

  • VK_KHR_COPY_COMMANDS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BLIT_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_COPY_2_KHR

    • VK_STRUCTURE_TYPE_BUFFER_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_BUFFER_TO_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_COPY_IMAGE_TO_BUFFER_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_BLIT_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_COPY_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR

    • VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2020-07-06 (Jeff Leger)

    • Internal revisions

VK_KHR_create_renderpass2

Name String

VK_KHR_create_renderpass2

Extension Type

Device extension

Registered Extension Number

110

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-02-07

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Tobias Hector

  • Jeff Bolz

Description

This extension provides a new entry point to create render passes in a way that can be easily extended by other extensions through the substructures of render pass creation. The Vulkan 1.0 render pass creation sub-structures do not include sType/pNext members. Additionally, the render pass begin/next/end commands have been augmented with new extensible structures for passing additional subpass information.

The VkRenderPassMultiviewCreateInfo and VkInputAttachmentAspectReference structures that extended the original VkRenderPassCreateInfo are not accepted into the new creation functions, and instead their parameters are folded into this extension as follows:

The details of these mappings are explained fully in the new structures.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME

  • VK_KHR_CREATE_RENDERPASS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR

Version History

  • Revision 1, 2018-02-07 (Tobias Hector)

    • Internal revisions

VK_KHR_dedicated_allocation

Name String

VK_KHR_dedicated_allocation

Extension Type

Device extension

Registered Extension Number

128

Revision

3

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Faith Ekstrand, Intel

Description

This extension enables resources to be bound to a dedicated allocation, rather than suballocated. For any particular resource, applications can query whether a dedicated allocation is recommended, in which case using a dedicated allocation may improve the performance of access to that resource. Normal device memory allocations must support multiple resources per allocation, memory aliasing and sparse binding, which could interfere with some optimizations. Applications should query the implementation for when a dedicated allocation may be beneficial by adding a VkMemoryDedicatedRequirementsKHR structure to the pNext chain of the VkMemoryRequirements2 structure passed as the pMemoryRequirements parameter of a call to vkGetBufferMemoryRequirements2 or vkGetImageMemoryRequirements2. Certain external handle types and external images or buffers may also depend on dedicated allocations on implementations that associate image or buffer metadata with OS-level memory objects.

This extension adds a two small structures to memory requirements querying and memory allocation: a new structure that flags whether an image/buffer should have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME

  • VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR

Examples

    // Create an image with a dedicated allocation based on the
    // implementation's preference

    VkImageCreateInfo imageCreateInfo =
    {
        // Image creation parameters
    };

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

    VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
        .pNext = NULL,
    };

    VkMemoryRequirements2 memoryRequirements =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
        .pNext = &dedicatedRequirements,
    };

    const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
    {
        .sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
        .pNext = NULL,
        .image = image
    };

    vkGetImageMemoryRequirements2(
        device,
        &imageRequirementsInfo,
        &memoryRequirements);

    if (dedicatedRequirements.prefersDedicatedAllocation) {
        // Allocate memory with VkMemoryDedicatedAllocateInfoKHR::image
        // pointing to the image we are allocating the memory for

        VkMemoryDedicatedAllocateInfoKHR dedicatedInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,
            .pNext = NULL,
            .image = image,
            .buffer = VK_NULL_HANDLE,
        };

        VkMemoryAllocateInfo memoryAllocateInfo =
        {
            .sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
            .pNext = &dedicatedInfo,
            .allocationSize = memoryRequirements.size,
            .memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
        };

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

        // Bind the image to the memory

        vkBindImageMemory(
            device,
            image,
            memory,
            0);
    } else {
        // Take the normal memory sub-allocation path
    }

Version History

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

    • Copy content from VK_NV_dedicated_allocation

    • Add some references to external object interactions to the overview.

  • Revision 2, 2017-03-27 (Faith Ekstrand)

    • Rework the extension to be query-based

  • Revision 3, 2017-07-31 (Faith Ekstrand)

    • Clarify that memory objects allocated with VkMemoryDedicatedAllocateInfoKHR can only have the specified resource bound and no others.

VK_KHR_depth_stencil_resolve

Name String

VK_KHR_depth_stencil_resolve

Extension Type

Device extension

Registered Extension Number

200

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-04-09

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Jan-Harald Fredriksen, Arm

  • Andrew Garrard, Samsung Electronics

  • Soowan Park, Samsung Electronics

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

Description

This extension adds support for automatically resolving multisampled depth/stencil attachments in a subpass in a similar manner as for color attachments.

Multisampled color attachments can be resolved at the end of a subpass by specifying pResolveAttachments entries corresponding to the pColorAttachments array entries. This does not allow for a way to map the resolve attachments to the depth/stencil attachment. The vkCmdResolveImage command does not allow for depth/stencil images. While there are other ways to resolve the depth/stencil attachment, they can give sub-optimal performance. Extending the VkSubpassDescription2 in this extension allows an application to add a pDepthStencilResolveAttachment, that is similar to the color pResolveAttachments, that the pDepthStencilAttachment can be resolved into.

Depth and stencil samples are resolved to a single value based on the resolve mode. The set of possible resolve modes is defined in the VkResolveModeFlagBits enum. The VK_RESOLVE_MODE_SAMPLE_ZERO_BIT mode is the only mode that is required of all implementations (that support the extension or support Vulkan 1.2 or higher). Some implementations may also support averaging (the same as color sample resolve) or taking the minimum or maximum sample, which may be more suitable for depth/stencil resolve.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Bitmasks

New Enum Constants

  • VK_KHR_DEPTH_STENCIL_RESOLVE_EXTENSION_NAME

  • VK_KHR_DEPTH_STENCIL_RESOLVE_SPEC_VERSION

  • Extending VkResolveModeFlagBits:

    • VK_RESOLVE_MODE_AVERAGE_BIT_KHR

    • VK_RESOLVE_MODE_MAX_BIT_KHR

    • VK_RESOLVE_MODE_MIN_BIT_KHR

    • VK_RESOLVE_MODE_NONE_KHR

    • VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR

Version History

  • Revision 1, 2018-04-09 (Jan-Harald Fredriksen)

    • Initial revision

VK_KHR_descriptor_update_template

Name String

VK_KHR_descriptor_update_template

Extension Type

Device extension

Registered Extension Number

86

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Michael Worcester, Imagination Technologies

Description

Applications may wish to update a fixed set of descriptors in a large number of descriptor sets very frequently, i.e. during initialization phase or if it is required to rebuild descriptor sets for each frame. For those cases it is also not unlikely that all information required to update a single descriptor set is stored in a single struct. This extension provides a way to update a fixed set of descriptors in a single VkDescriptorSet with a pointer to a user defined data structure describing the new descriptors.

Promotion to Vulkan 1.1

vkCmdPushDescriptorSetWithTemplateKHR is included as an interaction with VK_KHR_push_descriptor. If Vulkan 1.1 and VK_KHR_push_descriptor are supported, this is included by VK_KHR_push_descriptor.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME

  • VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_SPEC_VERSION

  • Extending VkDescriptorUpdateTemplateType:

    • VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET_KHR

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR

If VK_EXT_debug_report is supported:

If VK_KHR_push_descriptor is supported:

Version History

  • Revision 1, 2016-01-11 (Markus Tavenrath)

    • Initial draft

VK_KHR_device_group

Name String

VK_KHR_device_group

Extension Type

Device extension

Registered Extension Number

61

Revision

4

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-10-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Tobias Hector, Imagination Technologies

Description

This extension provides functionality to use a logical device that consists of multiple physical devices, as created with the VK_KHR_device_group_creation extension. A device group can allocate memory across the subdevices, bind memory from one subdevice to a resource on another subdevice, record command buffers where some work executes on an arbitrary subset of the subdevices, and potentially present a swapchain image from one or more subdevices.

Promotion to Vulkan 1.1

The following enums, types and commands are included as interactions with VK_KHR_swapchain:

If Vulkan 1.1 and VK_KHR_swapchain are supported, these are included by VK_KHR_swapchain.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_DEVICE_GROUP_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_SPEC_VERSION

  • Extending VkDependencyFlagBits:

    • VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR

  • Extending VkMemoryAllocateFlagBits:

    • VK_MEMORY_ALLOCATE_DEVICE_MASK_BIT_KHR

  • Extending VkPeerMemoryFeatureFlagBits:

    • VK_PEER_MEMORY_FEATURE_COPY_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_COPY_SRC_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT_KHR

    • VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT_KHR

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_DISPATCH_BASE_KHR

    • VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR

If VK_KHR_bind_memory2 is supported:

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR

If VK_KHR_surface is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR

If VK_KHR_swapchain is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR

  • Extending VkSwapchainCreateFlagBitsKHR:

    • VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR

New Built-in Variables

New SPIR-V Capabilities

Version History

  • Revision 1, 2016-10-19 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-05-19 (Tobias Hector)

    • Removed extended memory bind functions to VK_KHR_bind_memory2, added dependency on that extension, and device-group-specific structs for those functions.

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

    • Corrected Vulkan 1.1 interactions with the WSI extensions. All Vulkan 1.1 WSI interactions are with the VK_KHR_swapchain extension.

  • Revision 4, 2017-10-10 (Jeff Bolz)

    • Rename “SFR” bits and structure members to use the phrase “split instance bind regions”.

VK_KHR_device_group_creation

Name String

VK_KHR_device_group_creation

Extension Type

Instance extension

Registered Extension Number

71

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-19

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension provides instance-level commands to enumerate groups of physical devices, and to create a logical device from a subset of one of those groups. Such a logical device can then be used with new features in the VK_KHR_device_group extension.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_DEVICE_GROUP_CREATION_EXTENSION_NAME

  • VK_KHR_DEVICE_GROUP_CREATION_SPEC_VERSION

  • VK_MAX_DEVICE_GROUP_SIZE_KHR

  • Extending VkMemoryHeapFlagBits:

    • VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR

Examples

    VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
    // (not shown) fill out devCreateInfo as usual.
    uint32_t deviceGroupCount = 0;
    VkPhysicalDeviceGroupPropertiesKHR *props = NULL;

    // Query the number of device groups
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);

    // Allocate and initialize structures to query the device groups
    props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
    for (i = 0; i < deviceGroupCount; ++i) {
        props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
        props[i].pNext = NULL;
    }
    vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);

    // If the first device group has more than one physical device. create
    // a logical device using all of the physical devices.
    VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
    if (props[0].physicalDeviceCount > 1) {
        deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
        deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
        devCreateInfo.pNext = &deviceGroupInfo;
    }

    vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
    free(props);

Version History

  • Revision 1, 2016-10-19 (Jeff Bolz)

    • Internal revisions

VK_KHR_draw_indirect_count

Name String

VK_KHR_draw_indirect_count

Extension Type

Device extension

Registered Extension Number

170

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-08-25

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Derrick Owens, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Dominik Witczak, AMD

  • Piers Daniell, NVIDIA

Description

This extension is based off the VK_AMD_draw_indirect_count extension. This extension allows an application to source the number of draws for indirect drawing calls from a buffer.

Applications might want to do culling on the GPU via a compute shader prior to drawing. This enables the application to generate an arbitrary number of drawing commands and execute them without host intervention.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the entry points vkCmdDrawIndirectCount and vkCmdDrawIndexedIndirectCount are optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_DRAW_INDIRECT_COUNT_EXTENSION_NAME

  • VK_KHR_DRAW_INDIRECT_COUNT_SPEC_VERSION

Version History

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

    • Initial draft based off VK_AMD_draw_indirect_count

VK_KHR_driver_properties

Name String

VK_KHR_driver_properties

Extension Type

Device extension

Registered Extension Number

197

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-04-11

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

IP Status

No known IP claims.

Contributors
  • Baldur Karlsson

  • Matthaeus G. Chajdas, AMD

  • Piers Daniell, NVIDIA

  • Alexander Galazin, Arm

  • Jesse Hall, Google

  • Daniel Rakos, AMD

Description

This extension provides a new physical device query which allows retrieving information about the driver implementation, allowing applications to determine which physical device corresponds to which particular vendor’s driver, and which conformance test suite version the driver implementation is compliant with.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enums

New Enum Constants

  • VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME

  • VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION

  • VK_MAX_DRIVER_INFO_SIZE_KHR

  • VK_MAX_DRIVER_NAME_SIZE_KHR

  • Extending VkDriverId:

    • VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR

    • VK_DRIVER_ID_AMD_PROPRIETARY_KHR

    • VK_DRIVER_ID_ARM_PROPRIETARY_KHR

    • VK_DRIVER_ID_BROADCOM_PROPRIETARY_KHR

    • VK_DRIVER_ID_GGP_PROPRIETARY_KHR

    • VK_DRIVER_ID_GOOGLE_SWIFTSHADER_KHR

    • VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR

    • VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR

    • VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR

    • VK_DRIVER_ID_MESA_RADV_KHR

    • VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR

    • VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR

Version History

  • Revision 1, 2018-04-11 (Daniel Rakos)

    • Internal revisions

VK_KHR_dynamic_rendering

Name String

VK_KHR_dynamic_rendering

Extension Type

Device extension

Registered Extension Number

45

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact
Extension Proposal

VK_KHR_dynamic_rendering

Other Extension Metadata

Last Modified Date

2021-10-06

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

Contributors
  • Tobias Hector, AMD

  • Arseny Kapoulkine, Roblox

  • François Duranleau, Gameloft

  • Stuart Smith, AMD

  • Hai Nguyen, Google

  • Jean-François Roy, Google

  • Jeff Leger, Qualcomm

  • Jan-Harald Fredriksen, Arm

  • Piers Daniell, Nvidia

  • James Fitzpatrick, Imagination

  • Piotr Byszewski, Mobica

  • Jesse Hall, Google

  • Mike Blumenkrantz, Valve

Description

This extension allows applications to create single-pass render pass instances without needing to create render pass objects or framebuffers. Dynamic render passes can also span across multiple primary command buffers, rather than relying on secondary command buffers.

This extension also incorporates VK_ATTACHMENT_STORE_OP_NONE_KHR from VK_QCOM_render_pass_store_ops, enabling applications to avoid unnecessary synchronization when an attachment is not written during a render pass.

New Bitmasks

New Enum Constants

  • VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME

  • VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION

  • Extending VkAttachmentStoreOp:

    • VK_ATTACHMENT_STORE_OP_NONE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDERING_INFO_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_AMD

If VK_EXT_fragment_density_map is supported:

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT

    • VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_DENSITY_MAP_ATTACHMENT_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_DENSITY_MAP_ATTACHMENT_INFO_EXT

If VK_KHR_fragment_shading_rate is supported:

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

    • VK_PIPELINE_RASTERIZATION_STATE_CREATE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_RENDERING_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_NV

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MULTIVIEW_PER_VIEW_ATTRIBUTES_INFO_NVX

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2021-10-06 (Tobias Hector)

    • Initial revision

VK_KHR_external_fence

Name String

VK_KHR_external_fence

Extension Type

Device extension

Registered Extension Number

114

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-05-08

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors

Description

An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to create fences from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Structures

New Bitmasks

New Enum Constants

  • VK_KHR_EXTERNAL_FENCE_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_SPEC_VERSION

  • Extending VkFenceImportFlagBits:

    • VK_FENCE_IMPORT_TEMPORARY_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR

Issues

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

Version History

  • Revision 1, 2017-05-08 (Jesse Hall)

    • Initial revision

VK_KHR_external_fence_capabilities

Name String

VK_KHR_external_fence_capabilities

Extension Type

Instance extension

Registered Extension Number

113

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-05-08

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors

Description

An application may wish to reference device fences in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” fence handles an implementation supports for a given set of use cases.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_FENCE_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • Extending VkExternalFenceFeatureFlagBits:

    • VK_EXTERNAL_FENCE_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_FENCE_FEATURE_IMPORTABLE_BIT_KHR

  • Extending VkExternalFenceHandleTypeFlagBits:

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

    • VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

Version History

  • Revision 1, 2017-05-08 (Jesse Hall)

    • Initial version

VK_KHR_external_memory

Name String

VK_KHR_external_memory

Extension Type

Device extension

Registered Extension Number

73

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-20

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Faith Ekstrand, Intel

  • Ian Elliott, Google

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Daniel Rakos, AMD

  • Carsten Rohde, NVIDIA

  • Ray Smith, ARM

  • Lina Versace, Google

Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export non-Vulkan handles from Vulkan memory objects such that the underlying resources can be referenced outside the scope of the Vulkan logical device that created them.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_SPEC_VERSION

  • VK_QUEUE_FAMILY_EXTERNAL_KHR

  • Extending VkResult:

    • VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR

Issues

1) How do applications correlate two physical devices across process or Vulkan instance boundaries?

RESOLVED: New device ID fields have been introduced by VK_KHR_external_memory_capabilities. These fields, combined with the existing VkPhysicalDeviceProperties::driverVersion field can be used to identify compatible devices across processes, drivers, and APIs. VkPhysicalDeviceProperties::pipelineCacheUUID is not sufficient for this purpose because despite its description in the specification, it need only identify a unique pipeline cache format in practice. Multiple devices may be able to use the same pipeline cache data, and hence it would be desirable for all of them to have the same pipeline cache UUID. However, only the same concrete physical device can be used when sharing memory, so an actual unique device ID was introduced. Further, the pipeline cache UUID was specific to Vulkan, but correlation with other, non-extensible APIs is required to enable interoperation with those APIs.

2) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes. Applications must take care to obey all restrictions imposed on aliased resources when using memory across multiple Vulkan instances or other APIs.

3) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan- compatible, and those that are Vulkan-incompatible. Vulkan-incompatible APIs will require the image to be in the GENERAL layout whenever they are accessing them.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

4) Is a new barrier flag or operation of some type needed to prepare external memory for handoff to another Vulkan instance or API and/or receive it from another instance or API?

RESOLVED: Yes. Some implementations need to perform additional cache management when transitioning memory between address spaces and other APIs, instances, or processes which may operate in a separate address space. Options for defining this transition include:

A new structure has the advantage that the type of external transition can be described in as much detail as necessary. However, there is not currently a known need for anything beyond differentiating between external and internal accesses, so this is likely an over-engineered solution. The access flag bit has the advantage that it can be applied at buffer, image, or global granularity, and semantically it maps pretty well to the operation being described. Additionally, the API already includes VK_ACCESS_MEMORY_READ_BIT and VK_ACCESS_MEMORY_WRITE_BIT which appear to be intended for this purpose. However, there is no obvious pipeline stage that would correspond to an external access, and therefore no clear way to use VK_ACCESS_MEMORY_READ_BIT or VK_ACCESS_MEMORY_WRITE_BIT. VkDependencyFlags and VkPipelineStageFlags operate at command granularity rather than image or buffer granularity, which would make an entire pipeline barrier an internal→external or external→internal barrier. This may not be a problem in practice, but seems like the wrong scope. Another downside of VkDependencyFlags is that it lacks inherent directionality: there are no src and dst variants of it in the barrier or dependency description semantics, so two bits might need to be added to describe both internal→external and external→internal transitions. Transitioning a resource to a special queue family corresponds well with the operation of transitioning to a separate Vulkan instance, in that both operations ideally include scheduling a barrier on both sides of the transition: Both the releasing and the acquiring queue or process. Using a special queue family requires adding an additional reserved queue family index. Re-using VK_QUEUE_FAMILY_IGNORED would have left it unclear how to transition a concurrent usage resource from one process to another, since the semantics would have likely been equivalent to the currently-ignored transition of VK_QUEUE_FAMILY_IGNORED → VK_QUEUE_FAMILY_IGNORED. Fortunately, creating a new reserved queue family index is not invasive.

Based on the above analysis, the approach of transitioning to a special “external” queue family was chosen.

5) Do internal driver memory arrangements and/or other internal driver image properties need to be exported and imported when sharing images across processes or APIs.

RESOLVED: Some vendors claim this is necessary on their implementations, but it was determined that the security risks of allowing opaque metadata to be passed from applications to the driver were too high. Therefore, implementations which require metadata will need to associate it with the objects represented by the external handles, and rely on the dedicated allocation mechanism to associate the exported and imported memory objects with a single image or buffer.

6) Most prior interoperation and cross-process sharing APIs have been based on image-level sharing. Should Vulkan sharing be based on memory-object sharing or image sharing?

RESOLVED: These extensions have assumed memory-level sharing is the correct granularity. Vulkan is a lower-level API than most prior APIs, and as such attempts to closely align with to the underlying primitives of the hardware and system-level drivers it abstracts. In general, the resource that holds the backing store for both images and buffers of various types is memory. Images and buffers are merely metadata containing brief descriptions of the layout of bits within that memory.

Because memory object-based sharing is aligned with the overall Vulkan API design, it enables the full range of Vulkan capabilities with external objects. External memory can be used as backing for sparse images, for example, whereas such usage would be awkward at best with a sharing mechanism based on higher-level primitives such as images. Further, aligning the mechanism with the API in this way provides some hope of trivial compatibility with future API enhancements. If new objects backed by memory objects are added to the API, they too can be used across processes with minimal additions to the base external memory APIs.

Earlier APIs implemented interop at a higher level, and this necessitated entirely separate sharing APIs for images and buffers. To co-exist and interoperate with those APIs, the Vulkan external sharing mechanism must accommodate their model. However, if it can be agreed that memory-based sharing is the more desirable and forward-looking design, legacy interoperation constraints can be considered another reason to favor memory-based sharing: while native and legacy driver primitives that may be used to implement sharing may not be as low-level as the API here suggests, raw memory is still the least common denominator among the types. Image-based sharing can be cleanly derived from a set of base memory- object sharing APIs with minimal effort, whereas image-based sharing does not generalize well to buffer or raw-memory sharing. Therefore, following the general Vulkan design principle of minimalism, it is better to expose interopability with image-based native and external primitives via the memory sharing API, and place sufficient limits on their usage to ensure they can be used only as backing for equivalent Vulkan images. This provides a consistent API for applications regardless of which platform or external API they are targeting, which makes development of multi-API and multi-platform applications simpler.

7) Should Vulkan define a common external handle type and provide Vulkan functions to facilitate cross-process sharing of such handles rather than relying on native handles to define the external objects?

RESOLVED: No. Cross-process sharing of resources is best left to native platforms. There are myriad security and extensibility issues with such a mechanism, and attempting to re-solve all those issues within Vulkan does not align with Vulkan’s purpose as a graphics API. If desired, such a mechanism could be built as a layer or helper library on top of the opaque native handle defined in this family of extensions.

8) Must implementations provide additional guarantees about state implicitly included in memory objects for those memory objects that may be exported?

RESOLVED: Implementations must ensure that sharing memory objects does not transfer any information between the exporting and importing instances and APIs other than that required to share the data contained in the memory objects explicitly shared. As specific examples, data from previously freed memory objects that used the same underlying physical memory, and data from memory obects using adjacent physical memory must not be visible to applications importing an exported memory object.

9) Must implementations validate external handles the application provides as inputs to memory import operations?

RESOLVED: Implementations must return an error to the application if the provided memory handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

Version History

  • Revision 1, 2016-10-20 (James Jones)

    • Initial version

VK_KHR_external_memory_capabilities

Name String

VK_KHR_external_memory_capabilities

Extension Type

Instance extension

Registered Extension Number

72

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-17

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Ian Elliott, Google

  • Jesse Hall, Google

  • James Jones, NVIDIA

Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” memory handles an implementation supports for a given set of use cases.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • Extending VkExternalMemoryFeatureFlagBits:

    • VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR

    • VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR

  • Extending VkExternalMemoryHandleTypeFlagBits:

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

PROPOSED RESOLUTION: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.

2) Do the VkExternalImageFormatPropertiesKHR and VkExternalBufferPropertiesKHR structs need to include a list of memory type bits that support the given handle type?

PROPOSED RESOLUTION: No. The memory types that do not support the handle types will simply be filtered out of the results returned by vkGetImageMemoryRequirements and vkGetBufferMemoryRequirements when a set of handle types was specified at image or buffer creation time.

3) Should the non-opaque handle types be moved to their own extension?

PROPOSED RESOLUTION: Perhaps. However, defining the handle type bits does very little and does not require any platform-specific types on its own, and it is easier to maintain the bitfield values in a single extension for now. Presumably more handle types could be added by separate extensions though, and it would be midly weird to have some platform-specific ones defined in the core spec and some in extensions

4) Do we need a D3D11_TILEPOOL type?

PROPOSED RESOLUTION: No. This is technically possible, but the synchronization is awkward. D3D11 surfaces must be synchronized using shared mutexes, and these synchronization primitives are shared by the entire memory object, so D3D11 shared allocations divided among multiple buffer and image bindings may be difficult to synchronize.

5) Should the Windows 7-compatible handle types be named “KMT” handles or “GLOBAL_SHARE” handles?

PROPOSED RESOLUTION: KMT, simply because it is more concise.

6) How do applications identify compatible devices and drivers across instance, process, and API boundaries when sharing memory?

PROPOSED RESOLUTION: New device properties are exposed that allow applications to correctly correlate devices and drivers. A device and driver UUID that must both match to ensure sharing compatibility between two Vulkan instances, or a Vulkan instance and an extensible external API are added. To allow correlating with Direct3D devices, a device LUID is added that corresponds to a DXGI adapter LUID. A driver ID is not needed for Direct3D because mismatched driver component versions are not currently supported on the Windows OS. Should support for such configurations be introduced at the OS level, further Vulkan extensions would be needed to correlate userspace component builds.

Version History

  • Revision 1, 2016-10-17 (James Jones)

    • Initial version

VK_KHR_external_semaphore

Name String

VK_KHR_external_semaphore

Extension Type

Device extension

Registered Extension Number

78

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-21

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc.

  • Ray Smith, ARM

  • Lina Versace, Google

Description

An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to create semaphores from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION

  • Extending VkSemaphoreImportFlagBits:

    • VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR

Issues

1) Should there be restrictions on what side effects can occur when waiting on imported semaphores that are in an invalid state?

RESOLVED: Yes. Normally, validating such state would be the responsibility of the application, and the implementation would be free to enter an undefined state if valid usage rules were violated. However, this could cause security concerns when using imported semaphores, as it would require the importing application to trust the exporting application to ensure the state is valid. Requiring this level of trust is undesirable for many potential use cases.

2) Must implementations validate external handles the application provides as input to semaphore state import operations?

RESOLVED: Implementations must return an error to the application if the provided semaphore state handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

Version History

  • Revision 1, 2016-10-21 (James Jones)

    • Initial revision

VK_KHR_external_semaphore_capabilities

Name String

VK_KHR_external_semaphore_capabilities

Extension Type

Instance extension

Registered Extension Number

77

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-20

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

Description

An application may wish to reference device semaphores in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” semaphore handles an implementation supports for a given set of use cases.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME

  • VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_SPEC_VERSION

  • VK_LUID_SIZE_KHR

  • Extending VkExternalSemaphoreFeatureFlagBits:

    • VK_EXTERNAL_SEMAPHORE_FEATURE_EXPORTABLE_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_FEATURE_IMPORTABLE_BIT_KHR

  • Extending VkExternalSemaphoreHandleTypeFlagBits:

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR

    • VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_SEMAPHORE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR

Version History

  • Revision 1, 2016-10-20 (James Jones)

    • Initial revision

VK_KHR_format_feature_flags2

Name String

VK_KHR_format_feature_flags2

Extension Type

Device extension

Registered Extension Number

361

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2021-07-01

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Lionel Landwerlin, Intel

  • Faith Ekstrand, Intel

  • Tobias Hector, AMD

  • Spencer Fricke, Samsung Electronics

  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

Description

This extension adds a new VkFormatFeatureFlagBits2KHR 64bits format feature flag type to extend the existing VkFormatFeatureFlagBits which is limited to 31 flags. At the time of this writing 29 bits of VkFormatFeatureFlagBits are already used.

Because VkFormatProperties2 is already defined to extend the Vulkan 1.0 vkGetPhysicalDeviceFormatProperties entry point, this extension defines a new VkFormatProperties3KHR to extend the VkFormatProperties.

On top of replicating all the bits from VkFormatFeatureFlagBits, VkFormatFeatureFlagBits2KHR adds the following bits :

  • VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR and VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR indicate that an implementation supports respectively reading and writing a given VkFormat through storage operations without specifying the format in the shader.

  • VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR indicates that an implementation supports depth comparison performed by OpImage*Dref* instructions on a given VkFormat. Previously the result of executing a OpImage*Dref* instruction on an image view, where the format was not one of the depth/stencil formats with a depth component, was undefined. This bit clarifies on which formats such instructions can be used.

Prior to version 2 of this extension, implementations exposing the shaderStorageImageReadWithoutFormat and shaderStorageImageWriteWithoutFormat features may not report VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR and VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR in VkFormatProperties3KHR::bufferFeatures. Despite this, buffer reads/writes are supported as intended by the original features.

New Structures

New Enum Constants

  • VK_KHR_FORMAT_FEATURE_FLAGS_2_EXTENSION_NAME

  • VK_KHR_FORMAT_FEATURE_FLAGS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 2, 2022-07-20 (Lionel Landwerlin)

    • Clarify that VK_FORMAT_FEATURE_2_STORAGE_(READ|WRITE)_WITHOUT_FORMAT_BIT also apply to buffer views.

  • Revision 1, 2020-07-21 (Lionel Landwerlin)

    • Initial draft

VK_KHR_get_memory_requirements2

Name String

VK_KHR_get_memory_requirements2

Extension Type

Device extension

Registered Extension Number

147

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

Description

This extension provides new queries for memory requirements of images and buffers that can be easily extended by other extensions, without introducing any further entry points. The Vulkan 1.0 VkMemoryRequirements and VkSparseImageMemoryRequirements structures do not include sType and pNext members. This extension wraps them in new structures with these members, so an application can query a chain of memory requirements structures by constructing the chain and letting the implementation fill them in. A new command is added for each vkGet*MemoryRequrements command in core Vulkan 1.0.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME

  • VK_KHR_GET_MEMORY_REQUIREMENTS_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_SPARSE_MEMORY_REQUIREMENTS_INFO_2_KHR

    • VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_MEMORY_REQUIREMENTS_2_KHR

Version History

  • Revision 1, 2017-03-23 (Faith Ekstrand)

    • Internal revisions

VK_KHR_get_physical_device_properties2

Name String

VK_KHR_get_physical_device_properties2

Extension Type

Instance extension

Registered Extension Number

60

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Ian Elliott, Google

Description

This extension provides new queries for device features, device properties, and format properties that can be easily extended by other extensions, without introducing any further queries. The Vulkan 1.0 feature/limit/formatproperty structures do not include sType/pNext members. This extension wraps them in new structures with sType/pNext members, so an application can query a chain of feature/limit/formatproperty structures by constructing the chain and letting the implementation fill them in. A new command is added for each vkGetPhysicalDevice* command in core Vulkan 1.0. The new feature structure (and a pNext chain of extending structures) can also be passed in to device creation to enable features.

This extension also allows applications to use the physical-device components of device extensions before vkCreateDevice is called.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME

  • VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SPARSE_IMAGE_FORMAT_INFO_2_KHR

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2_KHR

    • VK_STRUCTURE_TYPE_SPARSE_IMAGE_FORMAT_PROPERTIES_2_KHR

Examples

    // Get features with a hypothetical future extension.
    VkHypotheticalExtensionFeaturesKHR hypotheticalFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
        .pNext = NULL,
    };

    VkPhysicalDeviceFeatures2KHR features =
    {
        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
        .pNext = &hypotheticalFeatures,
    };

    // After this call, features and hypotheticalFeatures have been filled out.
    vkGetPhysicalDeviceFeatures2KHR(physicalDevice, &features);

    // Properties/limits can be chained and queried similarly.

    // Enable some features:
    VkHypotheticalExtensionFeaturesKHR enabledHypotheticalFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,
        .pNext = NULL,
    };

    VkPhysicalDeviceFeatures2KHR enabledFeatures =
    {
        .sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,
        .pNext = &enabledHypotheticalFeatures,
    };

    enabledFeatures.features.xyz = VK_TRUE;
    enabledHypotheticalFeatures.abc = VK_TRUE;

    VkDeviceCreateInfo deviceCreateInfo =
    {
        .sType = VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
        .pNext = &enabledFeatures,
        ...
        .pEnabledFeatures = NULL,
    };

    VkDevice device;
    vkCreateDevice(physicalDevice, &deviceCreateInfo, NULL, &device);

Version History

  • Revision 1, 2016-09-12 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2016-11-02 (Ian Elliott)

    • Added ability for applications to use the physical-device components of device extensions before vkCreateDevice is called.

VK_KHR_image_format_list

Name String

VK_KHR_image_format_list

Extension Type

Device extension

Registered Extension Number

148

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-03-20

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

IP Status

No known IP claims.

Contributors
  • Faith Ekstrand, Intel

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Jeff Leger, Qualcomm

  • Neil Henning, Codeplay

Description

On some implementations, setting the VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT on image creation can cause access to that image to perform worse than an equivalent image created without VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT because the implementation does not know what view formats will be paired with the image.

This extension allows an application to provide the list of all formats that can be used with an image when it is created. The implementation may then be able to create a more efficient image that supports the subset of formats required by the application without having to support all formats in the format compatibility class of the image format.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_IMAGE_FORMAT_LIST_EXTENSION_NAME

  • VK_KHR_IMAGE_FORMAT_LIST_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_FORMAT_LIST_CREATE_INFO_KHR

Version History

  • Revision 1, 2017-03-20 (Faith Ekstrand)

    • Initial revision

VK_KHR_imageless_framebuffer

Name String

VK_KHR_imageless_framebuffer

Extension Type

Device extension

Registered Extension Number

109

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-12-14

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Tobias Hector

  • Graham Wihlidal

Description

This extension allows framebuffers to be created without the need for creating images first, allowing more flexibility in how they are used, and avoiding the need for many of the confusing compatibility rules.

Framebuffers are now created with a small amount of additional metadata about the image views that will be used in VkFramebufferAttachmentsCreateInfoKHR, and the actual image views are provided at render pass begin time via VkRenderPassAttachmentBeginInfoKHR.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_IMAGELESS_FRAMEBUFFER_EXTENSION_NAME

  • VK_KHR_IMAGELESS_FRAMEBUFFER_SPEC_VERSION

  • Extending VkFramebufferCreateFlagBits:

    • VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENTS_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENT_IMAGE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_ATTACHMENT_BEGIN_INFO_KHR

Version History

  • Revision 1, 2018-12-14 (Tobias Hector)

    • Internal revisions

VK_KHR_maintenance1

Name String

VK_KHR_maintenance1

Extension Type

Device extension

Registered Extension Number

70

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-03-13

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Dan Ginsburg, Valve

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • John Kessenich, Google

  • Michael Worcester, Imagination Technologies

  • Neil Henning, Codeplay Software Ltd.

  • Piers Daniell, NVIDIA

  • Slawomir Grajewski, Intel

  • Tobias Hector, Imagination Technologies

  • Tom Olson, ARM

Description

VK_KHR_maintenance1 adds a collection of minor features that were intentionally left out or overlooked from the original Vulkan 1.0 release.

The new features are as follows:

  • Allow 2D and 2D array image views to be created from 3D images, which can then be used as color framebuffer attachments. This allows applications to render to slices of a 3D image.

  • Support vkCmdCopyImage between 2D array layers and 3D slices. This extension allows copying from layers of a 2D array image to slices of a 3D image and vice versa.

  • Allow negative height to be specified in the VkViewport::height field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to use gl_Position.y = -gl_Position.y in shaders also targeting other APIs.

  • Allow implementations to express support for doing just transfers and clears of image formats that they otherwise support no other format features for. This is done by adding new format feature flags VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR and VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR.

  • Support vkCmdFillBuffer on transfer-only queues. Previously vkCmdFillBuffer was defined to only work on command buffers allocated from command pools which support graphics or compute queues. It is now allowed on queues that just support transfer operations.

  • Fix the inconsistency of how error conditions are returned between the vkCreateGraphicsPipelines and vkCreateComputePipelines functions and the vkAllocateDescriptorSets and vkAllocateCommandBuffers functions.

  • Add new VK_ERROR_OUT_OF_POOL_MEMORY_KHR error so implementations can give a more precise reason for vkAllocateDescriptorSets failures.

  • Add a new command vkTrimCommandPoolKHR which gives the implementation an opportunity to release any unused command pool memory back to the system.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Commands

New Enum Constants

  • VK_KHR_MAINTENANCE1_EXTENSION_NAME

  • VK_KHR_MAINTENANCE1_SPEC_VERSION

  • VK_KHR_MAINTENANCE_1_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_1_SPEC_VERSION

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR

    • VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT_KHR

  • Extending VkResult:

    • VK_ERROR_OUT_OF_POOL_MEMORY_KHR

Issues

  1. Are viewports with zero height allowed?

    RESOLVED: Yes, although they have low utility.

Version History

  • Revision 1, 2016-10-26 (Piers Daniell)

    • Internal revisions

  • Revision 2, 2018-03-13 (Jon Leech)

    • Add issue for zero-height viewports

VK_KHR_maintenance2

Name String

VK_KHR_maintenance2

Extension Type

Device extension

Registered Extension Number

118

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Michael Worcester, Imagination Technologies

  • Stuart Smith, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Jan-Harald Fredriksen, ARM

  • Daniel Rakos, AMD

  • Neil Henning, Codeplay

  • Piers Daniell, NVIDIA

Description

VK_KHR_maintenance2 adds a collection of minor features that were intentionally left out or overlooked from the original Vulkan 1.0 release.

The new features are as follows:

  • Allow the application to specify which aspect of an input attachment might be read for a given subpass.

  • Allow implementations to express the clipping behavior of points.

  • Allow creating images with usage flags that may not be supported for the base image’s format, but are supported for image views of the image that have a different but compatible format.

  • Allow creating uncompressed image views of compressed images.

  • Allow the application to select between an upper-left and lower-left origin for the tessellation domain space.

  • Adds two new image layouts for depth stencil images to allow either the depth or stencil aspect to be read-only while the other aspect is writable.

Input Attachment Specification

Input attachment specification allows an application to specify which aspect of a multi-aspect image (e.g. a depth/stencil format) will be accessed via a subpassLoad operation.

On some implementations there may be a performance penalty if the implementation does not know (at vkCreateRenderPass time) which aspect(s) of multi-aspect images can be accessed as input attachments.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_MAINTENANCE2_EXTENSION_NAME

  • VK_KHR_MAINTENANCE2_SPEC_VERSION

  • VK_KHR_MAINTENANCE_2_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_2_SPEC_VERSION

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR

    • VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR

  • Extending VkPointClippingBehavior:

    • VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR

    • VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR

  • Extending VkTessellationDomainOrigin:

    • VK_TESSELLATION_DOMAIN_ORIGIN_LOWER_LEFT_KHR

    • VK_TESSELLATION_DOMAIN_ORIGIN_UPPER_LEFT_KHR

Input Attachment Specification Example

Consider the case where a render pass has two subpasses and two attachments.

Attachment 0 has the format VK_FORMAT_D24_UNORM_S8_UINT, attachment 1 has some color format.

Subpass 0 writes to attachment 0, subpass 1 reads only the depth information from attachment 0 (using inputAttachmentRead) and writes to attachment 1.

    VkInputAttachmentAspectReferenceKHR references[] = {
        {
            .subpass = 1,
            .inputAttachmentIndex = 0,
            .aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
        }
    };

    VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
        .sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
        .pNext = NULL,
        .aspectReferenceCount = 1,
        .pAspectReferences = references
    };


    VkRenderPassCreateInfo createInfo = {
        ...
        .pNext = &specifyAspects,
        ...
    };

    vkCreateRenderPass(...);

Issues

1) What is the default tessellation domain origin?

RESOLVED: Vulkan 1.0 originally inadvertently documented a lower-left origin, but the conformance tests and all implementations implemented an upper-left origin. This extension adds a control to select between lower-left (for compatibility with OpenGL) and upper-left, and we retroactively fix unextended Vulkan to have a default of an upper-left origin.

Version History

  • Revision 1, 2017-04-28

VK_KHR_maintenance3

Name String

VK_KHR_maintenance3

Extension Type

Device extension

Registered Extension Number

169

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Jeff Bolz, NVIDIA

Description

VK_KHR_maintenance3 adds a collection of minor features that were intentionally left out or overlooked from the original Vulkan 1.0 release.

The new features are as follows:

  • A limit on the maximum number of descriptors that are supported in a single descriptor set layout. Some implementations have a limit on the total size of descriptors in a set, which cannot be expressed in terms of the limits in Vulkan 1.0.

  • A limit on the maximum size of a single memory allocation. Some platforms have kernel interfaces that limit the maximum size of an allocation.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_MAINTENANCE3_EXTENSION_NAME

  • VK_KHR_MAINTENANCE3_SPEC_VERSION

  • VK_KHR_MAINTENANCE_3_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_3_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_SUPPORT_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES_KHR

Version History

  • Revision 1, 2017-08-22

VK_KHR_maintenance4

Name String

VK_KHR_maintenance4

Extension Type

Device extension

Registered Extension Number

414

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2021-10-25

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

  • Requires SPIR-V 1.2 for LocalSizeId

Contributors
  • Lionel Duc, NVIDIA

  • Faith Ekstrand, Intel

  • Spencer Fricke, Samsung

  • Tobias Hector, AMD

  • Lionel Landwerlin, Intel

  • Graeme Leese, Broadcom

  • Tom Olson, Arm

  • Stu Smith, AMD

  • Yiwei Zhang, Google

Description

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

The new features are as follows:

  • Allow the application to destroy their VkPipelineLayout object immediately after it was used to create another object. It is no longer necessary to keep its handle valid while the created object is in use.

  • Add a new maxBufferSize implementation-defined limit for the maximum size VkBuffer that can be created.

  • Add support for the SPIR-V 1.2 LocalSizeId execution mode, which can be used as an alternative to LocalSize to specify the local workgroup size with specialization constants.

  • Add a guarantee that images created with identical creation parameters will always have the same alignment requirements.

  • Add new vkGetDeviceBufferMemoryRequirementsKHR, vkGetDeviceImageMemoryRequirementsKHR, and vkGetDeviceImageSparseMemoryRequirementsKHR to allow the application to query the image memory requirements without having to create an image object and query it.

  • Relax the requirement that push constants must be initialized before they are dynamically accessed.

  • Relax the interface matching rules to allow a larger output vector to match with a smaller input vector, with additional values being discarded.

  • Add a guarantee for buffer memory requirement that the size memory requirement is never greater than the result of aligning create size with the alignment memory requirement.

New Enum Constants

  • VK_KHR_MAINTENANCE_4_EXTENSION_NAME

  • VK_KHR_MAINTENANCE_4_SPEC_VERSION

  • Extending VkImageAspectFlagBits:

    • VK_IMAGE_ASPECT_NONE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_BUFFER_MEMORY_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_DEVICE_IMAGE_MEMORY_REQUIREMENTS_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_PROPERTIES_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

None.

Version History

  • Revision 1, 2021-08-18 (Piers Daniell)

    • Internal revisions

  • Revision 2, 2021-10-25 (Yiwei Zhang)

    • More guarantees on buffer memory requirements

VK_KHR_multiview

Name String

VK_KHR_multiview

Extension Type

Device extension

Registered Extension Number

54

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-10-28

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

Description

This extension has the same goal as the OpenGL ES GL_OVR_multiview extension. Multiview is a rendering technique originally designed for VR where it is more efficient to record a single set of commands to be executed with slightly different behavior for each “view”.

It includes a concise way to declare a render pass with multiple views, and gives implementations freedom to render the views in the most efficient way possible. This is done with a multiview configuration specified during render pass creation with the VkRenderPassMultiviewCreateInfo passed into VkRenderPassCreateInfo::pNext.

This extension enables the use of the SPV_KHR_multiview shader extension, which adds a new ViewIndex built-in type that allows shaders to control what to do for each view. If using GLSL there is also the GL_EXT_multiview extension that introduces a highp int gl_ViewIndex; built-in variable for vertex, tessellation, geometry, and fragment shaders.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_MULTIVIEW_EXTENSION_NAME

  • VK_KHR_MULTIVIEW_SPEC_VERSION

  • Extending VkDependencyFlagBits:

    • VK_DEPENDENCY_VIEW_LOCAL_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR

New Built-In Variables

New SPIR-V Capabilities

Version History

  • Revision 1, 2016-10-28 (Jeff Bolz)

    • Internal revisions

VK_KHR_relaxed_block_layout

Name String

VK_KHR_relaxed_block_layout

Extension Type

Device extension

Registered Extension Number

145

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-03-26

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • John Kessenich, Google

Description

The VK_KHR_relaxed_block_layout extension allows implementations to indicate they can support more variation in block Offset decorations. For example, placing a vector of three floats at an offset of 16×N + 4.

See Offset and Stride Assignment for details.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_RELAXED_BLOCK_LAYOUT_EXTENSION_NAME

  • VK_KHR_RELAXED_BLOCK_LAYOUT_SPEC_VERSION

Version History

  • Revision 1, 2017-03-26 (JohnK)

VK_KHR_sampler_mirror_clamp_to_edge

Name String

VK_KHR_sampler_mirror_clamp_to_edge

Extension Type

Device extension

Registered Extension Number

15

Revision

3

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-08-17

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Tobias Hector, Imagination Technologies

  • Jon Leech, Khronos

Description

VK_KHR_sampler_mirror_clamp_to_edge extends the set of sampler address modes to include an additional mode (VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE) that effectively uses a texture map twice as large as the original image in which the additional half of the new image is a mirror image of the original image.

This new mode relaxes the need to generate images whose opposite edges match by using the original image to generate a matching “mirror image”. This mode allows the texture to be mirrored only once in the negative s, t, and r directions.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2. However, if Vulkan 1.2 is supported and this extension is not, the VkSamplerAddressMode VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE is optional. Since the original extension did not use an author suffix on the enum VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE, it is used by both core and extension implementations.

New Enum Constants

  • VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_EXTENSION_NAME

  • VK_KHR_SAMPLER_MIRROR_CLAMP_TO_EDGE_SPEC_VERSION

  • Extending VkSamplerAddressMode:

    • VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE

    • VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE_KHR

Example

Creating a sampler with the new address mode in each dimension

    VkSamplerCreateInfo createInfo =
    {
        .sType = VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO,
        // Other members set to application-desired values
    };

    createInfo.addressModeU = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeV = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;
    createInfo.addressModeW = VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE;

    VkSampler sampler;
    VkResult result = vkCreateSampler(
        device,
        &createInfo,
        &sampler);

Issues

1) Why are both KHR and core versions of the VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE token present?

RESOLVED: This functionality was intended to be required in Vulkan 1.0. We realized shortly before public release that not all implementations could support it, and moved the functionality into an optional extension, but did not apply the KHR extension suffix. Adding a KHR-suffixed alias of the non-suffixed enum has been done to comply with our own naming rules.

In a related change, before spec revision 1.1.121 this extension was hardwiring into the spec Makefile so it was always included with the Specification, even in the core-only versions. This has now been reverted, and it is treated as any other extension.

Version History

  • Revision 1, 2016-02-16 (Tobias Hector)

    • Initial draft

  • Revision 2, 2019-08-14 (Jon Leech)

    • Add KHR-suffixed alias of non-suffixed enum.

  • Revision 3, 2019-08-17 (Jon Leech)

    • Add an issue explaining the reason for the extension API not being suffixed with KHR.

VK_KHR_sampler_ycbcr_conversion

Name String

VK_KHR_sampler_ycbcr_conversion

Extension Type

Device extension

Registered Extension Number

157

Revision

14

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-08-11

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.1 Core

Contributors
  • Andrew Garrard, Samsung Electronics

  • Tobias Hector, Imagination Technologies

  • James Jones, NVIDIA

  • Daniel Koch, NVIDIA

  • Daniel Rakos, AMD

  • Romain Guy, Google

  • Jesse Hall, Google

  • Tom Cooksey, ARM Ltd

  • Jeff Leger, Qualcomm Technologies, Inc

  • Jan-Harald Fredriksen, ARM Ltd

  • Jan Outters, Samsung Electronics

  • Alon Or-bach, Samsung Electronics

  • Michael Worcester, Imagination Technologies

  • Jeff Bolz, NVIDIA

  • Tony Zlatinski, NVIDIA

  • Matthew Netsch, Qualcomm Technologies, Inc

Description

The use of Y′CBCR sampler conversion is an area in 3D graphics not used by most Vulkan developers. It is mainly used for processing inputs from video decoders and cameras. The use of the extension assumes basic knowledge of Y′CBCR concepts.

This extension provides the ability to perform specified color space conversions during texture sampling operations for the Y′CBCR color space natively. It also adds a selection of multi-planar formats, image aspect plane, and the ability to bind memory to the planes of an image collectively or separately.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. However, if Vulkan 1.1 is supported and this extension is not, the samplerYcbcrConversion capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Object Types

New Enum Constants

  • VK_KHR_SAMPLER_YCBCR_CONVERSION_EXTENSION_NAME

  • VK_KHR_SAMPLER_YCBCR_CONVERSION_SPEC_VERSION

  • Extending VkChromaLocation:

    • VK_CHROMA_LOCATION_COSITED_EVEN_KHR

    • VK_CHROMA_LOCATION_MIDPOINT_KHR

  • Extending VkFormat:

    • VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_B16G16R16G16_422_UNORM_KHR

    • VK_FORMAT_B8G8R8G8_422_UNORM_KHR

    • VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16_KHR

    • VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16_KHR

    • VK_FORMAT_G16B16G16R16_422_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16R16_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM_KHR

    • VK_FORMAT_G8B8G8R8_422_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8R8_2PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM_KHR

    • VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM_KHR

    • VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16_KHR

    • VK_FORMAT_R10X6G10X6_UNORM_2PACK16_KHR

    • VK_FORMAT_R10X6_UNORM_PACK16_KHR

    • VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16_KHR

    • VK_FORMAT_R12X4G12X4_UNORM_2PACK16_KHR

    • VK_FORMAT_R12X4_UNORM_PACK16_KHR

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_DISJOINT_BIT_KHR

    • VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR

  • Extending VkImageAspectFlagBits:

    • VK_IMAGE_ASPECT_PLANE_0_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_1_BIT_KHR

    • VK_IMAGE_ASPECT_PLANE_2_BIT_KHR

  • Extending VkImageCreateFlagBits:

    • VK_IMAGE_CREATE_DISJOINT_BIT_KHR

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR

  • Extending VkSamplerYcbcrModelConversion:

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_RGB_IDENTITY_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_601_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_709_KHR

    • VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_IDENTITY_KHR

  • Extending VkSamplerYcbcrRange:

    • VK_SAMPLER_YCBCR_RANGE_ITU_FULL_KHR

    • VK_SAMPLER_YCBCR_RANGE_ITU_NARROW_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BIND_IMAGE_PLANE_MEMORY_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_PLANE_MEMORY_REQUIREMENTS_INFO_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_IMAGE_FORMAT_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO_KHR

If VK_EXT_debug_report is supported:

  • Extending VkDebugReportObjectTypeEXT:

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR_EXT

Version History

  • Revision 1, 2017-01-24 (Andrew Garrard)

    • Initial draft

  • Revision 2, 2017-01-25 (Andrew Garrard)

    • After initial feedback

  • Revision 3, 2017-01-27 (Andrew Garrard)

    • Higher bit depth formats, renaming, swizzle

  • Revision 4, 2017-02-22 (Andrew Garrard)

    • Added query function, formats as RGB, clarifications

  • Revision 5, 2017-04-?? (Andrew Garrard)

    • Simplified query and removed output conversions

  • Revision 6, 2017-04-24 (Andrew Garrard)

    • Tidying, incorporated new image query, restored transfer functions

  • Revision 7, 2017-04-25 (Andrew Garrard)

    • Added cosited option/midpoint requirement for formats, “bypassConversion”

  • Revision 8, 2017-04-25 (Andrew Garrard)

    • Simplified further

  • Revision 9, 2017-04-27 (Andrew Garrard)

    • Disjoint no more

  • Revision 10, 2017-04-28 (Andrew Garrard)

    • Restored disjoint

  • Revision 11, 2017-04-29 (Andrew Garrard)

    • Now Ycbcr conversion, and KHR

  • Revision 12, 2017-06-06 (Andrew Garrard)

    • Added conversion to image view creation

  • Revision 13, 2017-07-13 (Andrew Garrard)

    • Allowed cosited-only chroma samples for formats

  • Revision 14, 2017-08-11 (Andrew Garrard)

    • Reflected quantization changes in BT.2100-1

VK_KHR_separate_depth_stencil_layouts

Name String

VK_KHR_separate_depth_stencil_layouts

Extension Type

Device extension

Registered Extension Number

242

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-06-25

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Daniel Koch, NVIDIA

  • Jeff Bolz, NVIDIA

  • Jesse Barker, Unity

  • Tobias Hector, AMD

Description

This extension allows image memory barriers for depth/stencil images to have just one of the VK_IMAGE_ASPECT_DEPTH_BIT or VK_IMAGE_ASPECT_STENCIL_BIT aspect bits set, rather than require both. This allows their layouts to be set independently. To support depth/stencil images with different layouts for the depth and stencil aspects, the depth/stencil attachment interface has been updated to support a separate layout for stencil.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_EXTENSION_NAME

  • VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_SPEC_VERSION

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_STENCIL_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_STENCIL_READ_ONLY_OPTIMAL_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_STENCIL_LAYOUT_KHR

    • VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_STENCIL_LAYOUT_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SEPARATE_DEPTH_STENCIL_LAYOUTS_FEATURES_KHR

Version History

  • Revision 1, 2019-06-25 (Piers Daniell)

    • Internal revisions

VK_KHR_shader_atomic_int64

Name String

VK_KHR_shader_atomic_int64

Extension Type

Device extension

Registered Extension Number

181

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-07-05

Interactions and External Dependencies
Contributors
  • Aaron Hagan, AMD

  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Neil Henning, Codeplay

Description

This extension advertises the SPIR-V Int64Atomics capability for Vulkan, which allows a shader to contain 64-bit atomic operations on signed and unsigned integers. The supported operations include OpAtomicMin, OpAtomicMax, OpAtomicAnd, OpAtomicOr, OpAtomicXor, OpAtomicAdd, OpAtomicExchange, and OpAtomicCompareExchange.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the shaderBufferInt64Atomics capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME

  • VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR

New SPIR-V Capabilities

Version History

  • Revision 1, 2018-07-05 (Aaron Hagan)

    • Internal revisions

VK_KHR_shader_draw_parameters

Name String

VK_KHR_shader_draw_parameters

Extension Type

Device extension

Registered Extension Number

64

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Daniel Koch, NVIDIA Corporation

  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

  • Jan-Harald Fredriksen, ARM

  • John Kessenich, Google

  • Stuart Smith, IMG

Description

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

  • SPV_KHR_shader_draw_parameters

The extension provides access to three additional built-in shader variables in Vulkan:

  • BaseInstance, containing the firstInstance parameter passed to drawing commands,

  • BaseVertex, containing the firstVertex or vertexOffset parameter passed to drawing commands, and

  • DrawIndex, containing the index of the draw call currently being processed from an indirect drawing call.

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

  • in int gl_BaseInstanceARB;BaseInstance,

  • in int gl_BaseVertexARB;BaseVertex, and

  • in int gl_DrawIDARB;DrawIndex.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1. However, the shaderDrawParameters feature bit was added to distinguish whether it is actually available or not.

New Enum Constants

  • VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME

  • VK_KHR_SHADER_DRAW_PARAMETERS_SPEC_VERSION

New Built-In Variables

New SPIR-V Capabilities

Issues

1) Is this the same functionality as GL_ARB_shader_draw_parameters?

RESOLVED: It is actually a superset, as it also adds in support for arrayed drawing commands.

In GL for GL_ARB_shader_draw_parameters, gl_BaseVertexARB holds the integer value passed to the parameter to the command that resulted in the current shader invocation. In the case where the command has no baseVertex parameter, the value of gl_BaseVertexARB is zero. This means that gl_BaseVertexARB = baseVertex (for glDrawElements commands with baseVertex) or 0. In particular there are no glDrawArrays commands that take a baseVertex parameter.

Now in Vulkan, we have BaseVertex = vertexOffset (for indexed drawing commands) or firstVertex (for arrayed drawing commands), and so Vulkan’s version is really a superset of GL functionality.

Version History

  • Revision 1, 2016-10-05 (Daniel Koch)

    • Internal revisions

VK_KHR_shader_float16_int8

Name String

VK_KHR_shader_float16_int8

Extension Type

Device extension

Registered Extension Number

83

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-03-07

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

Description

The VK_KHR_shader_float16_int8 extension allows use of 16-bit floating-point types and 8-bit integer types in shaders for arithmetic operations.

It introduces two new optional features shaderFloat16 and shaderInt8 which directly map to the Float16 and the Int8 SPIR-V capabilities. The VK_KHR_shader_float16_int8 extension also specifies precision requirements for half-precision floating-point SPIR-V operations. This extension does not enable use of 8-bit integer types or 16-bit floating-point types in any shader input and output interfaces and therefore does not supersede the VK_KHR_8bit_storage or VK_KHR_16bit_storage extensions.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, both the shaderFloat16 and shaderInt8 capabilities are optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SHADER_FLOAT16_INT8_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT16_INT8_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT16_INT8_FEATURES_KHR

Version History

  • Revision 1, 2018-03-07 (Alexander Galazin)

    • Initial draft

VK_KHR_shader_float_controls

Name String

VK_KHR_shader_float_controls

Extension Type

Device extension

Registered Extension Number

198

Revision

4

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-09-11

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Alexander Galazin, Arm

  • Jan-Harald Fredriksen, Arm

  • Jeff Bolz, NVIDIA

  • Graeme Leese, Broadcom

  • Daniel Rakos, AMD

Description

The VK_KHR_shader_float_controls extension enables efficient use of floating-point computations through the ability to query and override the implementation’s default behavior for rounding modes, denormals, signed zero, and infinity.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SHADER_FLOAT_CONTROLS_EXTENSION_NAME

  • VK_KHR_SHADER_FLOAT_CONTROLS_SPEC_VERSION

  • Extending VkShaderFloatControlsIndependence:

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY_KHR

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_ALL_KHR

    • VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_NONE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR

Issues

1) Which instructions must flush denorms?

RESOLVED: Only floating-point conversion, floating-point arithmetic, floating-point relational (except OpIsNaN, OpIsInf), and floating-point GLSL.std.450 extended instructions must flush denormals.

2) What is the denorm behavior for intermediate results?

RESOLVED: When a SPIR-V instruction is implemented as a sequence of other instructions:

  • in the DenormFlushToZero execution mode, the intermediate instructions may flush denormals, the final result of the sequence must not be denormal.

  • in the DenormPreserve execution mode, denormals must be preserved throughout the whole sequence.

3) Do denorm and rounding mode controls apply to OpSpecConstantOp?

RESOLVED: Yes, except when the opcode is OpQuantizeToF16.

4) The SPIR-V specification says that OpConvertFToU and OpConvertFToS unconditionally round towards zero. Do the rounding mode controls specified through the execution modes apply to them?

RESOLVED: No, these instructions unconditionally round towards zero.

5) Do any of the “Pack” GLSL.std.450 instructions count as conversion instructions and have the rounding mode applied?

RESOLVED: No, only instructions listed in “section 3.32.11. Conversion Instructions” of the SPIR-V specification count as conversion instructions.

6) When using inf/nan-ignore mode, what is expected of OpIsNan and OpIsInf?

RESOLVED: These instructions must always accurately detect inf/nan if it is passed to them.

Version 4 API incompatibility

The original versions of VK_KHR_shader_float_controls shipped with booleans named “separateDenormSettings” and “separateRoundingModeSettings”, which at first glance could have indicated “they can all be set independently, or not”. However the spec language as written indicated that the 32-bit value could always be set independently, and only the 16- and 64-bit controls needed to be the same if these values were VK_FALSE.

As a result of this slight disparity, and lack of test coverage for this facet of the extension, we ended up with two different behaviors in the wild, where some implementations worked as written, and others worked based on the naming. As these are hard limits in hardware with reasons for exposure as written, it was not possible to standardise on a single way to make this work within the existing API.

No known users of this part of the extension exist in the wild, and as such the Vulkan WG took the unusual step of retroactively changing the once boolean value into a tri-state enum, breaking source compatibility. This was however done in such a way as to retain ABI compatibility, in case any code using this did exist; with the numerical values 0 and 1 retaining their original specified meaning, and a new value signifying the additional “all need to be set together” state. If any applications exist today, compiled binaries will continue to work as written in most cases, but will need changes before the code can be recompiled.

Version History

  • Revision 4, 2019-06-18 (Tobias Hector)

  • Revision 3, 2018-09-11 (Alexander Galazin)

    • Minor restructuring

  • Revision 2, 2018-04-17 (Alexander Galazin)

    • Added issues and resolutions

  • Revision 1, 2018-04-11 (Alexander Galazin)

    • Initial draft

VK_KHR_shader_integer_dot_product

Name String

VK_KHR_shader_integer_dot_product

Extension Type

Device extension

Registered Extension Number

281

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact
Extension Proposal

VK_KHR_shader_integer_dot_product

Other Extension Metadata

Last Modified Date

2021-06-16

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Kévin Petit, Arm Ltd.

  • Jeff Bolz, NVidia

  • Spencer Fricke, Samsung

  • Jesse Hall, Google

  • John Kessenich, Google

  • Graeme Leese, Broadcom

  • Einar Hov, Arm Ltd.

  • Stuart Brady, Arm Ltd.

  • Pablo Cascon, Arm Ltd.

  • Tobias Hector, AMD

  • Jeff Leger, Qualcomm

  • Ruihao Zhang, Qualcomm

  • Pierre Boudier, NVidia

  • Jon Leech, The Khronos Group

  • Tom Olson, Arm Ltd.

Description

This extension adds support for the integer dot product SPIR-V instructions defined in SPV_KHR_integer_dot_product. These instructions are particularly useful for neural network inference and training but find uses in other general-purpose compute applications as well.

New Enum Constants

  • VK_KHR_SHADER_INTEGER_DOT_PRODUCT_EXTENSION_NAME

  • VK_KHR_SHADER_INTEGER_DOT_PRODUCT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_PROPERTIES_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2021-06-16 (Kévin Petit)

    • Initial revision

VK_KHR_shader_non_semantic_info

Name String

VK_KHR_shader_non_semantic_info

Extension Type

Device extension

Registered Extension Number

294

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-10-16

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Baldur Karlsson, Valve

Description

This extension allows the use of the SPV_KHR_non_semantic_info extension in SPIR-V shader modules.

New Enum Constants

  • VK_KHR_SHADER_NON_SEMANTIC_INFO_EXTENSION_NAME

  • VK_KHR_SHADER_NON_SEMANTIC_INFO_SPEC_VERSION

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3 Because the extension has no API controlling its functionality, this results only in a change to the SPIR-V Extensions table.

Version History

  • Revision 1, 2019-10-16 (Baldur Karlsson)

    • Initial revision

VK_KHR_shader_subgroup_extended_types

Name String

VK_KHR_shader_subgroup_extended_types

Extension Type

Device extension

Registered Extension Number

176

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-01-08

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Jan-Harald Fredriksen, Arm

  • Neil Henning, AMD

  • Daniel Koch, NVIDIA

  • Jeff Leger, Qualcomm

  • Graeme Leese, Broadcom

  • David Neto, Google

  • Daniel Rakos, AMD

Description

This extension enables the Non Uniform Group Operations in SPIR-V to support 8-bit integer, 16-bit integer, 64-bit integer, 16-bit floating-point, and vectors of these types.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_EXTENSION_NAME

  • VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_EXTENDED_TYPES_FEATURES_KHR

Version History

  • Revision 1, 2019-01-08 (Neil Henning)

    • Initial draft

VK_KHR_shader_terminate_invocation

Name String

VK_KHR_shader_terminate_invocation

Extension Type

Device extension

Registered Extension Number

216

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-08-11

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Alan Baker, Google

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • Ralph Potter, Samsung

  • Tom Olson, Arm

Description

This extension adds Vulkan support for the SPV_KHR_terminate_invocation SPIR-V extension. That SPIR-V extension provides a new instruction, OpTerminateInvocation, which causes a shader invocation to immediately terminate and sets the coverage of shaded samples to 0; only previously executed instructions will have observable effects. The OpTerminateInvocation instruction, along with the OpDemoteToHelperInvocation instruction from the VK_EXT_shader_demote_to_helper_invocation extension, together replace the OpKill instruction, which could behave like either of these instructions. OpTerminateInvocation provides the behavior required by the GLSL discard statement, and should be used when available by GLSL compilers and applications that need the GLSL discard behavior.

New Enum Constants

  • VK_KHR_SHADER_TERMINATE_INVOCATION_EXTENSION_NAME

  • VK_KHR_SHADER_TERMINATE_INVOCATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TERMINATE_INVOCATION_FEATURES_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2020-08-11 (Jesse Hall)

VK_KHR_spirv_1_4

Name String

VK_KHR_spirv_1_4

Extension Type

Device extension

Registered Extension Number

237

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-04-01

IP Status

No known IP claims.

Interactions and External Dependencies
  • Requires SPIR-V 1.4.

  • Promoted to Vulkan 1.2 Core

Contributors
  • Alexander Galazin, Arm

  • David Neto, Google

  • Jesse Hall, Google

  • John Kessenich, Google

  • Neil Henning, AMD

  • Tom Olson, Arm

Description

This extension allows the use of SPIR-V 1.4 shader modules. SPIR-V 1.4’s new features primarily make it an easier target for compilers from high-level languages, rather than exposing new hardware functionality.

SPIR-V 1.4 incorporates features that are also available separately as extensions. SPIR-V 1.4 shader modules do not need to enable those extensions with the OpExtension opcode, since they are integral parts of SPIR-V 1.4.

SPIR-V 1.4 introduces new floating point execution mode capabilities, also available via SPV_KHR_float_controls. Implementations are not required to support all of these new capabilities; support can be queried using VkPhysicalDeviceFloatControlsPropertiesKHR from the VK_KHR_shader_float_controls extension.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_SPIRV_1_4_EXTENSION_NAME

  • VK_KHR_SPIRV_1_4_SPEC_VERSION

Issues

1. Should we have an extension specific to this SPIR-V version, or add a version-generic query for SPIR-V version? SPIR-V 1.4 does not need any other API changes.

RESOLVED: Just expose SPIR-V 1.4.

Most new SPIR-V versions introduce optionally-required capabilities or have implementation-defined limits, and would need more API and specification changes specific to that version to make them available in Vulkan. For example, to support the subgroup capabilities added in SPIR-V 1.3 required introducing VkPhysicalDeviceSubgroupProperties to allow querying the supported group operation categories, maximum supported subgroup size, etc. While we could expose the parts of a new SPIR-V version that do not need accompanying changes generically, we will still end up writing extensions specific to each version for the remaining parts. Thus the generic mechanism will not reduce future spec-writing effort. In addition, making it clear which parts of a future version are supported by the generic mechanism and which cannot be used without specific support would be difficult to get right ahead of time.

2. Can different stages of the same pipeline use shaders with different SPIR-V versions?

RESOLVED: Yes.

Mixing SPIR-V versions 1.0-1.3 in the same pipeline has not been disallowed, so it would be inconsistent to disallow mixing 1.4 with previous versions. SPIR-V 1.4 does not introduce anything that should cause new difficulties here.

3. Must Vulkan extensions corresponding to SPIR-V extensions that were promoted to core in 1.4 be enabled in order to use that functionality in a SPIR-V 1.4 module?

RESOLVED: No, with caveats.

The SPIR-V 1.4 module does not need to declare the SPIR-V extensions, since the functionality is now part of core, so there is no need to enable the Vulkan extension that allows SPIR-V modules to declare the SPIR-V extension. However, when the functionality that is now core in SPIR-V 1.4 is optionally supported, the query for support is provided by a Vulkan extension, and that query can only be used if the extension is enabled.

This applies to any SPIR-V version; specifically for SPIR-V 1.4 this only applies to the functionality from SPV_KHR_float_controls, which was made available in Vulkan by VK_KHR_shader_float_controls. Even though the extension was promoted in SPIR-V 1.4, the capabilities are still optional in implementations that support VK_KHR_spirv_1_4.

A SPIR-V 1.4 module does not need to enable SPV_KHR_float_controls in order to use the capabilities, so if the application has a priori knowledge that the implementation supports the capabilities, it does not need to enable VK_KHR_shader_float_controls. However, if it does not have this knowledge and has to query for support at runtime, it must enable VK_KHR_shader_float_controls in order to use VkPhysicalDeviceFloatControlsPropertiesKHR.

Version History

  • Revision 1, 2019-04-01 (Jesse Hall)

    • Internal draft versions

VK_KHR_storage_buffer_storage_class

Name String

VK_KHR_storage_buffer_storage_class

Extension Type

Device extension

Registered Extension Number

132

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Alexander Galazin, ARM

  • David Neto, Google

Description

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

  • SPV_KHR_storage_buffer_storage_class

This extension provides a new SPIR-V StorageBuffer storage class. A Block-decorated object in this class is equivalent to a BufferBlock-decorated object in the Uniform storage class.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1.

New Enum Constants

  • VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_EXTENSION_NAME

  • VK_KHR_STORAGE_BUFFER_STORAGE_CLASS_SPEC_VERSION

Version History

  • Revision 1, 2017-03-23 (Alexander Galazin)

    • Initial draft

VK_KHR_synchronization2

Name String

VK_KHR_synchronization2

Extension Type

Device extension

Registered Extension Number

315

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-12-03

Interactions and External Dependencies
Contributors
  • Tobias Hector

Description

This extension modifies the original core synchronization APIs to simplify the interface and improve usability of these APIs. It also adds new pipeline stage and access flag types that extend into the 64-bit range, as we have run out within the 32-bit range. The new flags are identical to the old values within the 32-bit range, with new stages and bits beyond that.

Pipeline stages and access flags are now specified together in memory barrier structures, making the connection between the two more obvious. Additionally, scoping the pipeline stages into the barrier structs allows the use of the MEMORY_READ and MEMORY_WRITE flags without sacrificing precision. The per-stage access flags should be used to disambiguate specific accesses in a given stage or set of stages - for instance, between uniform reads and sampling operations.

Layout transitions have been simplified as well; rather than requiring a different set of layouts for depth/stencil/color attachments, there are generic VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR and VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR layouts which are contextually applied based on the image format. For example, for a depth format image, VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR is equivalent to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR. VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR also functionally replaces VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.

Events are now more efficient, because they include memory dependency information when you set them on the device. Previously, this information was only known when waiting on an event, so the dependencies could not be satisfied until the wait occurred. That sometimes meant stalling the pipeline when the wait occurred. The new API provides enough information for implementations to satisfy these dependencies in parallel with other tasks.

Queue submission has been changed to wrap command buffers and semaphores in extensible structures, which incorporate changes from Vulkan 1.1, VK_KHR_device_group, and VK_KHR_timeline_semaphore. This also adds a pipeline stage to the semaphore signal operation, mirroring the existing pipeline stage specification for wait operations.

Other miscellaneous changes include:

  • Events can now be specified as interacting only with the device, allowing more efficient access to the underlying object.

  • Image memory barriers that do not perform an image layout transition can be specified by setting oldLayout equal to newLayout.

    • E.g. the old and new layout can both be set to VK_IMAGE_LAYOUT_UNDEFINED, without discarding data in the image.

  • Queue family ownership transfer parameters are simplified in some cases.

  • Where two synchronization commands need to be matched up (queue transfer operations, events), the dependency information specified in each place must now match completely for consistency.

  • Extensions with commands or functions with a VkPipelineStageFlags or VkPipelineStageFlagBits parameter have had those APIs replaced with equivalents using VkPipelineStageFlags2KHR.

  • The new event and barrier interfaces are now more extensible for future changes.

  • Relevant pipeline stage masks can now be specified as empty with the new VK_PIPELINE_STAGE_NONE_KHR and VK_PIPELINE_STAGE_2_NONE_KHR values.

  • VkMemoryBarrier2KHR can be chained to VkSubpassDependency2, overriding the original 32-bit stage and access masks.

New Base Types

New Enum Constants

  • VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME

  • VK_KHR_SYNCHRONIZATION_2_SPEC_VERSION

  • Extending VkAccessFlagBits:

    • VK_ACCESS_NONE_KHR

  • Extending VkEventCreateFlagBits:

    • VK_EVENT_CREATE_DEVICE_ONLY_BIT_KHR

  • Extending VkImageLayout:

    • VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR

    • VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR

  • Extending VkPipelineStageFlagBits:

    • VK_PIPELINE_STAGE_NONE_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_COMMAND_BUFFER_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_DEPENDENCY_INFO_KHR

    • VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SYNCHRONIZATION_2_FEATURES_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_SUBMIT_INFO_KHR

    • VK_STRUCTURE_TYPE_SUBMIT_INFO_2_KHR

If VK_EXT_conditional_rendering is supported:

If VK_EXT_fragment_density_map is supported:

If VK_EXT_mesh_shader is supported:

If VK_EXT_transform_feedback is supported:

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT

    • VK_ACCESS_2_TRANSFORM_FEEDBACK_WRITE_BIT_EXT

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_TRANSFORM_FEEDBACK_BIT_EXT

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_KHR

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_KHR

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_KHR

If VK_KHR_fragment_shading_rate is supported:

If VK_KHR_ray_tracing_pipeline is supported:

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_CHECKPOINT_DATA_2_NV

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_2_NV

If VK_NV_mesh_shader is supported:

If VK_NV_ray_tracing is supported:

  • Extending VkAccessFlagBits2:

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_NV

    • VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_NV

  • Extending VkPipelineStageFlagBits2:

    • VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_NV

    • VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_NV

If VK_NV_shading_rate_image is supported:

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2020-12-03 (Tobias Hector)

    • Internal revisions

VK_KHR_timeline_semaphore

Name String

VK_KHR_timeline_semaphore

Extension Type

Device extension

Registered Extension Number

208

Revision

2

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-06-12

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Yuriy O’Donnell, Epic Games

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

  • James Jones, NVIDIA

  • Jeff Juliano, NVIDIA

  • Daniel Rakos, AMD

  • Ray Smith, Arm

Description

This extension introduces a new type of semaphore that has an integer payload identifying a point in a timeline. Such timeline semaphores support the following operations:

  • Host query - A host operation that allows querying the payload of the timeline semaphore.

  • Host wait - A host operation that allows a blocking wait for a timeline semaphore to reach a specified value.

  • Host signal - A host operation that allows advancing the timeline semaphore to a specified value.

  • Device wait - A device operation that allows waiting for a timeline semaphore to reach a specified value.

  • Device signal - A device operation that allows advancing the timeline semaphore to a specified value.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_TIMELINE_SEMAPHORE_EXTENSION_NAME

  • VK_KHR_TIMELINE_SEMAPHORE_SPEC_VERSION

  • Extending VkSemaphoreType:

    • VK_SEMAPHORE_TYPE_BINARY_KHR

    • VK_SEMAPHORE_TYPE_TIMELINE_KHR

  • Extending VkSemaphoreWaitFlagBits:

    • VK_SEMAPHORE_WAIT_ANY_BIT_KHR

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_PROPERTIES_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_SIGNAL_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO_KHR

    • VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO_KHR

    • VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO_KHR

Issues

1) Do we need a new object type for this?

RESOLVED: No, we just introduce a new type of semaphore object, as VK_KHR_external_semaphore_win32 already uses semaphores as the destination for importing D3D12 fence objects, which are semantically close/identical to the proposed synchronization primitive.

2) What type of payload the new synchronization primitive has?

RESOLVED: A 64-bit unsigned integer that can only be set to strictly increasing values by signal operations and is not changed by wait operations.

3) Does the new synchronization primitive have the same signal-before-wait requirement as the existing semaphores do?

RESOLVED: No. Timeline semaphores support signaling and waiting entirely asynchronously. It is the responsibility of the client to avoid deadlock.

4) Does the new synchronization primitive allow resetting its payload?

RESOLVED: No, allowing the payload value to “go backwards” is problematic. Applications looking for reset behavior should create a new instance of the synchronization primitive instead.

5) How do we enable host waits on the synchronization primitive?

RESOLVED: Both a non-blocking query of the current payload value of the synchronization primitive, and a blocking wait operation are provided.

6) How do we enable device waits and signals on the synchronization primitive?

RESOLVED: Similar to VK_KHR_external_semaphore_win32, this extension introduces a new structure that can be chained to VkSubmitInfo to specify the values signaled semaphores should be set to, and the values waited semaphores need to reach.

7) Can the new synchronization primitive be used to synchronize presentation and swapchain image acquisition operations?

RESOLVED: Some implementations may have problems with supporting that directly, thus it is not allowed in this extension.

8) Do we want to support external sharing of the new synchronization primitive type?

RESOLVED: Yes. Timeline semaphore specific external sharing capabilities can be queried using vkGetPhysicalDeviceExternalSemaphoreProperties by chaining the new VkSemaphoreTypeCreateInfoKHR structure to its pExternalSemaphoreInfo structure. This allows having a different set of external semaphore handle types supported for timeline semaphores vs. binary semaphores.

9) Do we need to add a host signal operation for the new synchronization primitive type?

RESOLVED: Yes. This helps in situations where one host thread submits a workload but another host thread has the information on when the workload is ready to be executed.

10) How should the new synchronization primitive interact with the ordering requirements of the original VkSemaphore?

RESOLVED: Prior to calling any command which may cause a wait operation on a binary semaphore, the client must ensure that the semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution.

11) Should we have separate feature bits for different sub-features of timeline semaphores?

RESOLVED: No. The only feature which cannot be supported universally is timeline semaphore import/export. For import/export, the client is already required to query available external handle types via vkGetPhysicalDeviceExternalSemaphoreProperties and provide the semaphore type by adding a VkSemaphoreTypeCreateInfoKHR structure to the pNext chain of VkPhysicalDeviceExternalSemaphoreInfo so no new feature bit is required.

Version History

  • Revision 1, 2018-05-10 (Faith Ekstrand)

    • Initial version

  • Revision 2, 2019-06-12 (Faith Ekstrand)

    • Added an initialValue parameter to timeline semaphore creation

VK_KHR_uniform_buffer_standard_layout

Name String

VK_KHR_uniform_buffer_standard_layout

Extension Type

Device extension

Registered Extension Number

254

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-01-25

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Graeme Leese, Broadcom

  • Jeff Bolz, NVIDIA

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Neil Henning, AMD

Description

This extension enables tighter array and struct packing to be used with uniform buffers.

It modifies the alignment rules for uniform buffers, allowing for tighter packing of arrays and structures. This allows, for example, the std430 layout, as defined in GLSL to be supported in uniform buffers.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_EXTENSION_NAME

  • VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFORM_BUFFER_STANDARD_LAYOUT_FEATURES_KHR

Version History

  • Revision 1, 2019-01-25 (Graeme Leese)

    • Initial draft

VK_KHR_variable_pointers

Name String

VK_KHR_variable_pointers

Extension Type

Device extension

Registered Extension Number

121

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-09-05

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • John Kessenich, Google

  • Neil Henning, Codeplay

  • David Neto, Google

  • Daniel Koch, Nvidia

  • Graeme Leese, Broadcom

  • Weifeng Zhang, Qualcomm

  • Stephen Clarke, Imagination Technologies

  • Faith Ekstrand, Intel

  • Jesse Hall, Google

Description

The VK_KHR_variable_pointers extension allows implementations to indicate their level of support for the SPV_KHR_variable_pointers SPIR-V extension. The SPIR-V extension allows shader modules to use invocation-private pointers into uniform and/or storage buffers, where the pointer values can be dynamic and non-uniform.

The SPV_KHR_variable_pointers extension introduces two capabilities. The first, VariablePointersStorageBuffer, must be supported by all implementations of this extension. The second, VariablePointers, is optional.

Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted, however support for the variablePointersStorageBuffer feature is made optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME

  • VK_KHR_VARIABLE_POINTERS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTERS_FEATURES_KHR

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR

Issues

1) Do we need an optional property for the SPIR-V VariablePointersStorageBuffer capability or should it be mandatory when this extension is advertised?

RESOLVED: Add it as a distinct feature, but make support mandatory. Adding it as a feature makes the extension easier to include in a future core API version. In the extension, the feature is mandatory, so that presence of the extension guarantees some functionality. When included in a core API version, the feature would be optional.

2) Can support for these capabilities vary between shader stages?

RESOLVED: No, if the capability is supported in any stage it must be supported in all stages.

3) Should the capabilities be features or limits?

RESOLVED: Features, primarily for consistency with other similar extensions.

Version History

  • Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)

    • Internal revisions

VK_KHR_vulkan_memory_model

Name String

VK_KHR_vulkan_memory_model

Extension Type

Device extension

Registered Extension Number

212

Revision

3

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-12-10

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Alan Baker, Google

  • Tobias Hector, AMD

  • David Neto, Google

  • Robert Simpson, Qualcomm Technologies, Inc.

  • Brian Sumner, AMD

Description

The VK_KHR_vulkan_memory_model extension allows use of the features guarded by the VulkanMemoryModel, VulkanMemoryModelDeviceScope, and VulkanMemoryModelAvailabilityVisibilityChains capabilities in shader modules. The Vulkan Memory Model formally defines how to synchronize memory accesses to the same memory locations performed by multiple shader invocations.

Note

Version 3 of the spec added a member (vulkanMemoryModelAvailabilityVisibilityChains) to VkPhysicalDeviceVulkanMemoryModelFeaturesKHR, which is an incompatible change from version 2.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the vulkanMemoryModel capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME

  • VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR

New SPIR-V Capabilities

Version History

  • Revision 1, 2018-06-24 (Jeff Bolz)

    • Initial draft

  • Revision 3, 2018-12-10 (Jeff Bolz)

    • Add vulkanMemoryModelAvailabilityVisibilityChains member to the VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure.

VK_KHR_zero_initialize_workgroup_memory

Name String

VK_KHR_zero_initialize_workgroup_memory

Extension Type

Device extension

Registered Extension Number

326

Revision

1

Ratification Status

Ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-11-18

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Alan Baker, Google

  • Jeff Bolz, Nvidia

  • Faith Ekstrand, Intel

Description

This extension allows the use of a null constant initializer on shader Workgroup memory variables, allowing implementations to expose any special hardware or instructions they may have. Zero initialization is commonly used by applications running untrusted content (e.g. web browsers) as way of defeating memory-scraping attacks.

New Enum Constants

  • VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_EXTENSION_NAME

  • VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_WORKGROUP_MEMORY_FEATURES_KHR

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2020-11-18 (Alan Baker)

    • Internal draft version

VK_EXT_4444_formats

Name String

VK_EXT_4444_formats

Extension Type

Device extension

Registered Extension Number

341

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-07-28

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Joshua Ashton, Valve

  • Faith Ekstrand, Intel

Description

This extension defines the VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT and VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT formats which are defined in other current graphics APIs.

This extension may be useful for building translation layers for those APIs or for porting applications that use these formats without having to resort to swizzles.

When VK_EXT_custom_border_color is used, these formats are not subject to the same restrictions for border color without format as with VK_FORMAT_B4G4R4A4_UNORM_PACK16.

New Enum Constants

  • VK_EXT_4444_FORMATS_EXTENSION_NAME

  • VK_EXT_4444_FORMATS_SPEC_VERSION

  • Extending VkFormat:

    • VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT

    • VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_4444_FORMATS_FEATURES_EXT

Promotion to Vulkan 1.3

This extension has been partially promoted. The format enumerants introduced by the extension are included in core Vulkan 1.3, with the EXT suffix omitted. However, runtime support for these formats is optional in core Vulkan 1.3, while if this extension is supported, runtime support is mandatory. The feature structure is not promoted. The original enum names are still available as aliases of the core functionality.

Version History

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

    • Initial draft

VK_EXT_buffer_device_address

Name String

VK_EXT_buffer_device_address

Extension Type

Device extension

Registered Extension Number

245

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-01-06

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Neil Henning, AMD

  • Tobias Hector, AMD

  • Faith Ekstrand, Intel

  • Baldur Karlsson, Valve

Description

This extension allows the application to query a 64-bit buffer device address value for a buffer, which can be used to access the buffer memory via the PhysicalStorageBufferEXT storage class in the GL_EXT_buffer_reference GLSL extension and SPV_EXT_physical_storage_buffer SPIR-V extension.

It also allows buffer device addresses to be provided by a trace replay tool, so that it matches the address used when the trace was captured.

New Enum Constants

  • VK_EXT_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME

  • VK_EXT_BUFFER_DEVICE_ADDRESS_SPEC_VERSION

  • Extending VkBufferCreateFlagBits:

    • VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT

  • Extending VkBufferUsageFlagBits:

    • VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT

  • Extending VkResult:

    • VK_ERROR_INVALID_DEVICE_ADDRESS_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT

New SPIR-V Capabilities

Issues

1) Where is VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT and VkPhysicalDeviceBufferAddressFeaturesEXT?

RESOLVED: They were renamed as VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT and VkPhysicalDeviceBufferDeviceAddressFeaturesEXT accordingly for consistency. Even though, the old names can still be found in the generated header files for compatibility.

Version History

  • Revision 1, 2018-11-01 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2019-01-06 (Jon Leech)

    • Minor updates to appendix for publication

VK_EXT_debug_marker

Name String

VK_EXT_debug_marker

Extension Type

Device extension

Registered Extension Number

23

Revision

4

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Special Use
Contact

Other Extension Metadata

Last Modified Date

2017-01-31

IP Status

No known IP claims.

Contributors
  • Baldur Karlsson

  • Dan Ginsburg, Valve

  • Jon Ashburn, LunarG

  • Kyle Spagnoli, NVIDIA

Description

The VK_EXT_debug_marker extension is a device extension. It introduces concepts of object naming and tagging, for better tracking of Vulkan objects, as well as additional commands for recording annotations of named sections of a workload to aid organization and offline analysis in external tools.

New Enum Constants

  • VK_EXT_DEBUG_MARKER_EXTENSION_NAME

  • VK_EXT_DEBUG_MARKER_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_TAG_INFO_EXT

Examples

Example 1

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

    extern VkDevice device;
    extern VkImage image;

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

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

    pfnDebugMarkerSetObjectNameEXT(device, &imageNameInfo);

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

Example 2

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

    extern VkDevice device;
    extern VkCommandBuffer commandBuffer;

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

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

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

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

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

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

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

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

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

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

Issues

1) Should the tag or name for an object be specified using the pNext parameter in the object’s Vk*CreateInfo structure?

RESOLVED: No. While this fits with other Vulkan patterns and would allow more type safety and future proofing against future objects, it has notable downsides. In particular passing the name at Vk*CreateInfo time does not allow renaming, prevents late binding of naming information, and does not allow naming of implicitly created objects such as queues and swapchain images.

2) Should the command annotation functions vkCmdDebugMarkerBeginEXT and vkCmdDebugMarkerEndEXT support the ability to specify a color?

RESOLVED: Yes. The functions have been expanded to take an optional color which can be used at will by implementations consuming the command buffer annotations in their visualisation.

3) Should the functions added in this extension accept an extensible structure as their parameter for a more flexible API, as opposed to direct function parameters? If so, which functions?

RESOLVED: Yes. All functions have been modified to take a structure type with extensible pNext pointer, to allow future extensions to add additional annotation information in the same commands.

Version History

  • Revision 1, 2016-02-24 (Baldur Karlsson)

    • Initial draft, based on LunarG marker spec

  • Revision 2, 2016-02-26 (Baldur Karlsson)

    • Renamed Dbg to DebugMarker in function names

    • Allow markers in secondary command buffers under certain circumstances

    • Minor language tweaks and edits

  • Revision 3, 2016-04-23 (Baldur Karlsson)

    • Reorganise spec layout to closer match desired organisation

    • Added optional color to markers (both regions and inserted labels)

    • Changed functions to take extensible structs instead of direct function parameters

  • Revision 4, 2017-01-31 (Baldur Karlsson)

    • Added explicit dependency on VK_EXT_debug_report

    • Moved definition of VkDebugReportObjectTypeEXT to debug report chapter.

    • Fixed typo in dates in revision history

VK_EXT_debug_report

Name String

VK_EXT_debug_report

Extension Type

Instance extension

Registered Extension Number

12

Revision

10

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Special Use
Contact

Other Extension Metadata

Last Modified Date

2020-12-14

IP Status

No known IP claims.

Contributors
  • Courtney Goeltzenleuchter, LunarG

  • Dan Ginsburg, Valve

  • Jon Ashburn, LunarG

  • Mark Lobodzinski, LunarG

Description

Due to the nature of the Vulkan interface, there is very little error information available to the developer and application. By enabling optional validation layers and using the VK_EXT_debug_report extension, developers can obtain much more detailed feedback on the application’s use of Vulkan. This extension defines a way for layers and the implementation to call back to the application for events of interest to the application.

New Object Types

New Function Pointers

New Bitmasks

New Enum Constants

  • VK_EXT_DEBUG_REPORT_EXTENSION_NAME

  • VK_EXT_DEBUG_REPORT_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT

  • Extending VkResult:

    • VK_ERROR_VALIDATION_FAILED_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT

If Version 1.1 is supported:

  • Extending VkDebugReportObjectTypeEXT:

    • VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_EXT

    • VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_EXT

Examples

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

To capture events that occur while creating or destroying an instance an application can link a VkDebugReportCallbackCreateInfoEXT structure to the pNext 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.

    VkResult res;
    VkDebugReportCallbackEXT cb1, cb2, cb3;

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

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

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

    ...

    /* remove callbacks when cleaning up */
    vkDestroyDebugReportCallbackEXT(instance, cb1);
    vkDestroyDebugReportCallbackEXT(instance, cb2);
    vkDestroyDebugReportCallbackEXT(instance, cb3);
Note

In the initial release of the VK_EXT_debug_report extension, the token VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT was used. Starting in version 2 of the extension branch, VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT is used instead for consistency with Vulkan naming rules. The older enum is still available for backwards compatibility.

Note

In the initial release of the VK_EXT_debug_report extension, the token VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_EXT was used. Starting in version 8 of the extension branch, VK_DEBUG_REPORT_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT_EXT is used instead for consistency with Vulkan naming rules. The older enum is still available for backwards compatibility.

Issues

1) What is the hierarchy / seriousness of the message flags? E.g. ERROR > WARN > PERF_WARN …​

RESOLVED: There is no specific hierarchy. Each bit is independent and should be checked via bitwise AND. For example:

    if (localFlags & VK_DEBUG_REPORT_ERROR_BIT_EXT) {
        process error message
    }
    if (localFlags & VK_DEBUG_REPORT_DEBUG_BIT_EXT) {
        process debug message
    }

The validation layers do use them in a hierarchical way (ERROR > WARN > PERF, WARN > DEBUG > INFO) and they (at least at the time of this writing) only set one bit at a time. But it is not a requirement of this extension.

It is possible that a layer may intercept and change, or augment the flags with extension values the application’s debug report handler may not be familiar with, so it is important to treat each flag independently.

2) Should there be a VU requiring VkDebugReportCallbackCreateInfoEXT::flags to be non-zero?

RESOLVED: It may not be very useful, but we do not need VU statement requiring the VkDebugReportCallbackCreateInfoEXT::msgFlags at create-time to be non-zero. One can imagine that apps may prefer it as it allows them to set the mask as desired - including nothing - at runtime without having to check.

3) What is the difference between VK_DEBUG_REPORT_DEBUG_BIT_EXT and VK_DEBUG_REPORT_INFORMATION_BIT_EXT?

RESOLVED: VK_DEBUG_REPORT_DEBUG_BIT_EXT specifies information that could be useful debugging the Vulkan implementation itself.

4) How do you compare handles returned by the debug_report callback to the application’s handles?

RESOLVED: Due to the different nature of dispatchable and nondispatchable handles there is no generic way (that we know of) that works for common compilers with 32bit, 64bit, C and C++. We recommend applications use the same cast that the validation layers use:

+

reinterpret_cast<uint64_t &>(dispatchableHandle)
(uint64_t)(nondispatchableHandle)

+ This does require that the app treat dispatchable and nondispatchable handles differently.

Version History

  • Revision 1, 2015-05-20 (Courtney Goetzenleuchter)

    • Initial draft, based on LunarG KHR spec, other KHR specs

  • Revision 2, 2016-02-16 (Courtney Goetzenleuchter)

    • Update usage, documentation

  • Revision 3, 2016-06-14 (Courtney Goetzenleuchter)

    • Update VK_EXT_DEBUG_REPORT_SPEC_VERSION to indicate added support for vkCreateInstance and vkDestroyInstance

  • Revision 4, 2016-12-08 (Mark Lobodzinski)

    • Added Display_KHR, DisplayModeKHR extension objects

    • Added ObjectTable_NVX, IndirectCommandsLayout_NVX extension objects

    • Bumped spec revision

    • Retroactively added version history

  • Revision 5, 2017-01-31 (Baldur Karlsson)

  • Revision 6, 2017-01-31 (Baldur Karlsson)

    • Added VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT

  • Revision 7, 2017-04-20 (Courtney Goeltzenleuchter)

    • Clarify wording and address questions from developers.

  • Revision 8, 2017-04-21 (Courtney Goeltzenleuchter)

    • Remove unused enum VkDebugReportErrorEXT

  • Revision 9, 2017-09-12 (Tobias Hector)

    • Added interactions with Vulkan 1.1

  • Revision 10, 2020-12-14 (Courtney Goetzenleuchter)

    • Add issue 4 discussing matching handles returned by the extension, based on suggestion in public issue 368.

VK_EXT_descriptor_indexing

Name String

VK_EXT_descriptor_indexing

Extension Type

Device extension

Registered Extension Number

162

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-10-02

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Daniel Rakos, AMD

  • Slawomir Grajewski, Intel

  • Tobias Hector, Imagination Technologies

Description

This extension adds several small features which together enable applications to create large descriptor sets containing substantially all of their resources, and selecting amongst those resources with dynamic (non-uniform) indexes in the shader. There are feature enables and SPIR-V capabilities for non-uniform descriptor indexing in the shader, and non-uniform indexing in the shader requires use of a new NonUniformEXT decoration defined in the SPV_EXT_descriptor_indexing SPIR-V extension. There are descriptor set layout binding creation flags enabling several features:

  • Descriptors can be updated after they are bound to a command buffer, such that the execution of the command buffer reflects the most recent update to the descriptors.

  • Descriptors that are not used by any pending command buffers can be updated, which enables writing new descriptors for frame N+1 while frame N is executing.

  • Relax the requirement that all descriptors in a binding that is “statically used” must be valid, such that descriptors that are not accessed by a submission need not be valid and can be updated while that submission is executing.

  • The final binding in a descriptor set layout can have a variable size (and unsized arrays of resources are allowed in the GL_EXT_nonuniform_qualifier and SPV_EXT_descriptor_indexing extensions).

Note that it is valid for multiple descriptor arrays in a shader to use the same set and binding number, as long as they are all compatible with the descriptor type in the pipeline layout. This means a single array binding in the descriptor set can serve multiple texture dimensionalities, or an array of buffer descriptors can be used with multiple different block layouts.

There are new descriptor set layout and descriptor pool creation flags that are required to opt in to the update-after-bind functionality, and there are separate maxPerStage* and maxDescriptorSet* limits that apply to these descriptor set layouts which may be much higher than the pre-existing limits. The old limits only count descriptors in non-updateAfterBind descriptor set layouts, and the new limits count descriptors in all descriptor set layouts in the pipeline layout.

New Enum Constants

  • VK_EXT_DESCRIPTOR_INDEXING_EXTENSION_NAME

  • VK_EXT_DESCRIPTOR_INDEXING_SPEC_VERSION

  • Extending VkDescriptorBindingFlagBits:

    • VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT_EXT

    • VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT

    • VK_DESCRIPTOR_BINDING_UPDATE_UNUSED_WHILE_PENDING_BIT_EXT

    • VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT

  • Extending VkDescriptorPoolCreateFlagBits:

    • VK_DESCRIPTOR_POOL_CREATE_UPDATE_AFTER_BIND_BIT_EXT

  • Extending VkDescriptorSetLayoutCreateFlagBits:

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT

  • Extending VkResult:

    • VK_ERROR_FRAGMENTATION_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_ALLOCATE_INFO_EXT

    • VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_LAYOUT_SUPPORT_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_PROPERTIES_EXT

Promotion to Vulkan 1.2

Functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the descriptorIndexing capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2017-07-26 (Jeff Bolz)

    • Internal revisions

  • Revision 2, 2017-10-02 (Jeff Bolz)

    • ???

VK_EXT_extended_dynamic_state

Name String

VK_EXT_extended_dynamic_state

Extension Type

Device extension

Registered Extension Number

268

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-12-09

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Dan Ginsburg, Valve Corporation

  • Graeme Leese, Broadcom

  • Hans-Kristian Arntzen, Valve Corporation

  • Jan-Harald Fredriksen, Arm Limited

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Jesse Hall, Google

  • Philip Rebohle, Valve Corporation

  • Stuart Smith, Imagination Technologies

  • Tobias Hector, AMD

Description

This extension adds some more dynamic state to support applications that need to reduce the number of pipeline state objects they compile and bind.

New Enum Constants

  • VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_CULL_MODE_EXT

    • VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_COMPARE_OP_EXT

    • VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE_EXT

    • VK_DYNAMIC_STATE_FRONT_FACE_EXT

    • VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY_EXT

    • VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT_EXT

    • VK_DYNAMIC_STATE_STENCIL_OP_EXT

    • VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE_EXT

    • VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE_EXT

    • VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_FEATURES_EXT

Promotion to Vulkan 1.3

This extension has been partially promoted. All dynamic state enumerants and entry points in this extension are included in core Vulkan 1.3, with the EXT suffix omitted. The feature structure is not promoted. Extension interfaces that were promoted remain available as aliases of the core functionality.

Issues

Why are the values of pStrides in vkCmdBindVertexBuffers2 limited to be between 0 and the maximum extent of the binding, when this restriction is not present for the same static state?

Implementing these edge cases adds overhead to some implementations that would require significant cost when calling this function, and the intention is that this state should be more or less free to change.

VK_EXT_vertex_input_dynamic_state allows the stride to be changed freely when supported via vkCmdSetVertexInputEXT[].

Version History

  • Revision 1, 2019-12-09 (Piers Daniell)

    • Internal revisions

VK_EXT_extended_dynamic_state2

Name String

VK_EXT_extended_dynamic_state2

Extension Type

Device extension

Registered Extension Number

378

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2021-04-12

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Vikram Kushwaha, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension adds some more dynamic state to support applications that need to reduce the number of pipeline state objects they compile and bind.

New Enum Constants

  • VK_EXT_EXTENDED_DYNAMIC_STATE_2_EXTENSION_NAME

  • VK_EXT_EXTENDED_DYNAMIC_STATE_2_SPEC_VERSION

  • Extending VkDynamicState:

    • VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT

    • VK_DYNAMIC_STATE_LOGIC_OP_EXT

    • VK_DYNAMIC_STATE_PATCH_CONTROL_POINTS_EXT

    • VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT

    • VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_2_FEATURES_EXT

Promotion to Vulkan 1.3

This extension has been partially promoted. The dynamic state enumerants VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT, VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT, and VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT; and the corresponding entry points in this extension are included in core Vulkan 1.3, with the EXT suffix omitted. The enumerants and entry points for dynamic logic operation and patch control points are not promoted, nor is the feature structure. Extension interfaces that were promoted remain available as aliases of the core functionality.

Version History

  • Revision 1, 2021-04-12 (Vikram Kushwaha)

    • Internal revisions

VK_EXT_global_priority

Name String

VK_EXT_global_priority

Extension Type

Device extension

Registered Extension Number

175

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-10-06

IP Status

No known IP claims.

Contributors
  • Andres Rodriguez, Valve

  • Pierre-Loup Griffais, Valve

  • Dan Ginsburg, Valve

  • Mitch Singer, AMD

Description

In Vulkan, users can specify device-scope queue priorities. In some cases it may be useful to extend this concept to a system-wide scope. This extension provides a mechanism for callers to set their system-wide priority. The default queue priority is VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT.

The driver implementation will attempt to skew hardware resource allocation in 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_EXT_GLOBAL_PRIORITY_EXTENSION_NAME

  • VK_EXT_GLOBAL_PRIORITY_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_NOT_PERMITTED_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_QUEUE_GLOBAL_PRIORITY_CREATE_INFO_EXT

Version History

  • Revision 2, 2017-11-03 (Andres Rodriguez)

    • Fixed VkQueueGlobalPriorityEXT missing _EXT suffix

  • Revision 1, 2017-10-06 (Andres Rodriguez)

    • First version.

VK_EXT_global_priority_query

Name String

VK_EXT_global_priority_query

Extension Type

Device extension

Registered Extension Number

389

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2021-03-29

IP Status

No known IP claims.

Contributors
  • Yiwei Zhang, Google

Description

This device extension allows applications to query the global queue priorities supported by a queue family. It allows implementations to report which global priority levels are treated differently by the implementation, instead of silently mapping multiple requested global priority levels to the same internal priority, or using device creation failure to signal that a requested priority is not supported. It is intended primarily for use by system integration along with certain platform-specific priority enforcement rules.

New Enum Constants

  • VK_EXT_GLOBAL_PRIORITY_QUERY_EXTENSION_NAME

  • VK_EXT_GLOBAL_PRIORITY_QUERY_SPEC_VERSION

  • VK_MAX_GLOBAL_PRIORITY_SIZE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_EXT

    • VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_EXT

Issues

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

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

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

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

Version History

  • Revision 1, 2021-03-29 (Yiwei Zhang)

VK_EXT_host_query_reset

Name String

VK_EXT_host_query_reset

Extension Type

Device extension

Registered Extension Number

262

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-03-06

IP Status

No known IP claims.

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Bas Nieuwenhuizen, Google

  • Faith Ekstrand, Intel

  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

Description

This extension adds a new function to reset queries from the host.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Commands

New Enum Constants

  • VK_EXT_HOST_QUERY_RESET_EXTENSION_NAME

  • VK_EXT_HOST_QUERY_RESET_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_QUERY_RESET_FEATURES_EXT

Version History

  • Revision 1, 2019-03-12 (Bas Nieuwenhuizen)

    • Initial draft

VK_EXT_image_robustness

Name String

VK_EXT_image_robustness

Extension Type

Device extension

Registered Extension Number

336

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-04-27

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Graeme Leese, Broadcom

  • Jan-Harald Fredriksen, ARM

  • Jeff Bolz, NVIDIA

  • Spencer Fricke, Samsung

  • Courtney Goeltzenleuchter, Google

  • Slawomir Cygan, Intel

Description

This extension adds stricter requirements for how out of bounds reads from images are handled. Rather than returning undefined values, most out of bounds reads return R, G, and B values of zero and alpha values of either zero or one. Components not present in the image format may be set to zero or to values based on the format as described in Conversion to RGBA.

New Enum Constants

  • VK_EXT_IMAGE_ROBUSTNESS_EXTENSION_NAME

  • VK_EXT_IMAGE_ROBUSTNESS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ROBUSTNESS_FEATURES_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

  1. How does this extension differ from VK_EXT_robustness2?

The guarantees provided by this extension are a subset of those provided by the robustImageAccess2 feature of VK_EXT_robustness2. Where this extension allows return values of (0, 0, 0, 0) or (0, 0, 0, 1), robustImageAccess2 requires that a particular value dependent on the image format be returned. This extension provides no guarantees about the values returned for an access to an invalid Lod.

Examples

None.

Version History

  • Revision 1, 2020-04-27 (Graeme Leese)

  • Initial draft

VK_EXT_inline_uniform_block

Name String

VK_EXT_inline_uniform_block

Extension Type

Device extension

Registered Extension Number

139

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-08-01

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Daniel Rakos, AMD

  • Jeff Bolz, NVIDIA

  • Slawomir Grajewski, Intel

  • Neil Henning, Codeplay

Description

This extension introduces the ability to back uniform blocks directly with descriptor sets by storing inline uniform data within descriptor pool storage. Compared to push constants this new construct allows uniform data to be reused across multiple disjoint sets of drawing or dispatching commands and may enable uniform data to be accessed with fewer indirections compared to uniforms backed by buffer memory.

New Enum Constants

  • VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME

  • VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Do we need a new storage class for inline uniform blocks vs. uniform blocks?

RESOLVED: No. The Uniform storage class is used to allow the same syntax used for both uniform buffers and inline uniform blocks.

2) Is the descriptor array index and array size expressed in terms of bytes or dwords for inline uniform block descriptors?

RESOLVED: In bytes, but both must be a multiple of 4, similar to how push constant ranges are specified. The descriptorCount of VkDescriptorSetLayoutBinding thus provides the total number of bytes a particular binding with an inline uniform block descriptor type can hold, while the srcArrayElement, dstArrayElement, and descriptorCount members of VkWriteDescriptorSet, VkCopyDescriptorSet, and VkDescriptorUpdateTemplateEntry (where applicable) specify the byte offset and number of bytes to write/copy to the binding’s backing store. Additionally, the stride member of VkDescriptorUpdateTemplateEntry is ignored for inline uniform blocks and a default value of one is used, meaning that the data to update inline uniform block bindings with must be contiguous in memory.

3) What layout rules apply for uniform blocks corresponding to inline constants?

RESOLVED: They use the same layout rules as uniform buffers.

4) Do we need to add non-uniform indexing features/properties as introduced by VK_EXT_descriptor_indexing for inline uniform blocks?

RESOLVED: No, because inline uniform blocks are not allowed to be “arrayed”. A single binding with an inline uniform block descriptor type corresponds to a single uniform block instance and the array indices inside that binding refer to individual offsets within the uniform block (see issue #2). However, this extension does introduce new features/properties about the level of support for update-after-bind inline uniform blocks.

5) Is the descriptorBindingVariableDescriptorCount feature introduced by VK_EXT_descriptor_indexing supported for inline uniform blocks?

RESOLVED: Yes, as long as other inline uniform block specific limits are respected.

6) Do the robustness guarantees of robustBufferAccess apply to inline uniform block accesses?

RESOLVED: No, similarly to push constants, as they are not backed by buffer memory like uniform buffers.

Version History

  • Revision 1, 2018-08-01 (Daniel Rakos)

    • Internal revisions

VK_EXT_pipeline_creation_cache_control

Name String

VK_EXT_pipeline_creation_cache_control

Extension Type

Device extension

Registered Extension Number

298

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-03-23

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Gregory Grebe, AMD

  • Tobias Hector, AMD

  • Matthaeus Chajdas, AMD

  • Mitch Singer, AMD

  • Spencer Fricke, Samsung Electronics

  • Stuart Smith, Imagination Technologies

  • Jeff Bolz, NVIDIA Corporation

  • Daniel Koch, NVIDIA Corporation

  • Dan Ginsburg, Valve Corporation

  • Jeff Leger, QUALCOMM

  • Michal Pietrasiuk, Intel

  • Jan-Harald Fredriksen, Arm Limited

Description

This extension adds flags to Vk*PipelineCreateInfo and VkPipelineCacheCreateInfo structures with the aim of improving the predictability of pipeline creation cost. The goal is to provide information about potentially expensive hazards within the client driver during pipeline creation to the application before carrying them out rather than after.

Background

Pipeline creation is a costly operation, and the explicit nature of the Vulkan design means that cost is not hidden from the developer. Applications are also expected to schedule, prioritize, and load balance all calls for pipeline creation. It is strongly advised that applications create pipelines sufficiently ahead of their usage. Failure to do so will result in an unresponsive application, intermittent stuttering, or other poor user experiences. Proper usage of pipeline caches and/or derivative pipelines help mitigate this but is not assured to eliminate disruption in all cases. In the event that an ahead-of-time creation is not possible, considerations should be taken to ensure that the current execution context is suitable for the workload of pipeline creation including possible shader compilation.

Applications making API calls to create a pipeline must be prepared for any of the following to occur:

  • OS/kernel calls to be made by the ICD

  • Internal memory allocation not tracked by the pAllocator passed to vkCreate*Pipelines

  • Internal thread synchronization or yielding of the current thread’s core

  • Extremely long (multi-millisecond+), blocking, compilation times

  • Arbitrary call stacks depths and stack memory usage

The job or task based game engines that are being developed to take advantage of explicit graphics APIs like Vulkan may behave exceptionally poorly if any of the above scenarios occur. However, most game engines are already built to “stream” in assets dynamically as the user plays the game. By adding control by way of VkPipelineCreateFlags, we can require an ICD to report back a failure in critical execution paths rather than forcing an unexpected wait.

Applications can prevent unexpected compilation by setting VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT on Vk*PipelineCreateInfo::flags. When set, an ICD must not attempt pipeline or shader compilation to create the pipeline object. In such a case, if the implementation fails to create a pipeline without compilation, the implementation must return the result VK_PIPELINE_COMPILE_REQUIRED_EXT and return VK_NULL_HANDLE for the pipeline.

By default vkCreate*Pipelines calls must attempt to create all pipelines before returning. Setting VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT on Vk*PipelineCreateInfo::flags can be used as an escape hatch for batched pipeline creates.

Hidden locks also add to the unpredictability of the cost of pipeline creation. The most common case of locks inside the vkCreate*Pipelines is internal synchronization of the VkPipelineCache object. VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT can be set when calling vkCreatePipelineCache to state the cache is externally synchronized.

The hope is that armed with this information application and engine developers can leverage existing asset streaming systems to recover from "just-in-time" pipeline creation stalls.

New Enum Constants

  • VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_EXTENSION_NAME

  • VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_SPEC_VERSION

  • Extending VkPipelineCacheCreateFlagBits:

    • VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT

  • Extending VkPipelineCreateFlagBits:

    • VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT

    • VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT

  • Extending VkResult:

    • VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT

    • VK_PIPELINE_COMPILE_REQUIRED_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CREATION_CACHE_CONTROL_FEATURES_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2019-11-01 (Gregory Grebe)

    • Initial revision

  • Revision 2, 2020-02-24 (Gregory Grebe)

    • Initial public revision

  • Revision 3, 2020-03-23 (Tobias Hector)

    • Changed VK_PIPELINE_COMPILE_REQUIRED_EXT to a success code, adding an alias for the original VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT. Also updated the xml to include these codes as return values.

VK_EXT_pipeline_creation_feedback

Name String

VK_EXT_pipeline_creation_feedback

Extension Type

Device extension

Registered Extension Number

193

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Special Use
Contact
  • Jean-Francois Roy jfroy

Other Extension Metadata

Last Modified Date

2019-03-12

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Jean-Francois Roy, Google

  • Hai Nguyen, Google

  • Andrew Ellem, Google

  • Bob Fraser, Google

  • Sujeevan Rajayogam, Google

  • Jan-Harald Fredriksen, ARM

  • Jeff Leger, Qualcomm Technologies, Inc.

  • Jeff Bolz, NVIDIA

  • Daniel Koch, NVIDIA

  • Neil Henning, AMD

Description

This extension adds a mechanism to provide feedback to an application about pipeline creation, with the specific goal of allowing a feedback loop between build systems and in-the-field application executions to ensure effective pipeline caches are shipped to customers.

New Enum Constants

  • VK_EXT_PIPELINE_CREATION_FEEDBACK_EXTENSION_NAME

  • VK_EXT_PIPELINE_CREATION_FEEDBACK_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PIPELINE_CREATION_FEEDBACK_CREATE_INFO_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2019-03-12 (Jean-Francois Roy)

    • Initial revision

VK_EXT_private_data

Name String

VK_EXT_private_data

Extension Type

Device extension

Registered Extension Number

296

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-03-25

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Matthew Rusch, NVIDIA

  • Nuno Subtil, NVIDIA

  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

Description

This extension is a device extension which enables attaching arbitrary payloads to Vulkan objects. It introduces the idea of private data slots as a means of storing a 64-bit unsigned integer of application defined data. Private data slots can be created or destroyed any time an associated device is available. Private data slots can be reserved at device creation time, and limiting use to the amount reserved will allow the extension to exhibit better performance characteristics.

New Object Types

New Enum Constants

  • VK_EXT_PRIVATE_DATA_EXTENSION_NAME

  • VK_EXT_PRIVATE_DATA_SPEC_VERSION

  • Extending VkObjectType:

    • VK_OBJECT_TYPE_PRIVATE_DATA_SLOT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEVICE_PRIVATE_DATA_CREATE_INFO_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIVATE_DATA_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PRIVATE_DATA_SLOT_CREATE_INFO_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Examples

  • In progress

Issues

(1) If I have to create a VkPrivateDataSlot to store and retrieve data on an object, how does this extension help me? Will I not need to store the VkPrivateDataSlot mapping with each object, and if I am doing that, I might as well just store the original data!

RESOLVED: The VkPrivateDataSlot can be thought of as an opaque index into storage that is reserved in each object. That is, you can use the same VkPrivateDataSlot with each object for a specific piece of information. For example, if a layer wishes to track per-object information, the layer only needs to allocate one VkPrivateDataSlot per device and it can use that private data slot for all of the device’s child objects. This allows multiple layers to store private data without conflicting with each other’s and/or the application’s private data.

(2) What if I need to store more than 64-bits of information per object?

RESOLVED: The data that you store per object could be a pointer to another object or structure of your own allocation.

Version History

  • Revision 1, 2020-01-15 (Matthew Rusch)

    • Initial draft

VK_EXT_sampler_filter_minmax

Name String

VK_EXT_sampler_filter_minmax

Extension Type

Device extension

Registered Extension Number

131

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-05-19

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

  • Piers Daniell, NVIDIA

Description

In unextended Vulkan, minification and magnification filters such as LINEAR allow sampled image lookups to return a filtered texel value produced by computing a weighted average of a collection of texels in the neighborhood of the texture coordinate provided.

This extension provides a new sampler parameter which allows applications to produce a filtered texel value by computing a component-wise minimum (MIN) or maximum (MAX) of the texels that would normally be averaged. The reduction mode is orthogonal to the minification and magnification filter parameters. The filter parameters are used to identify the set of texels used to produce a final filtered value; the reduction mode identifies how these texels are combined.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_EXT_SAMPLER_FILTER_MINMAX_EXTENSION_NAME

  • VK_EXT_SAMPLER_FILTER_MINMAX_SPEC_VERSION

  • Extending VkFormatFeatureFlagBits:

    • VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT

  • Extending VkSamplerReductionMode:

    • VK_SAMPLER_REDUCTION_MODE_MAX_EXT

    • VK_SAMPLER_REDUCTION_MODE_MIN_EXT

    • VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT

Version History

  • Revision 2, 2017-05-19 (Piers Daniell)

    • Renamed to EXT

  • Revision 1, 2017-03-25 (Jeff Bolz)

    • Internal revisions

VK_EXT_scalar_block_layout

Name String

VK_EXT_scalar_block_layout

Extension Type

Device extension

Registered Extension Number

222

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-11-14

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

Contributors
  • Jeff Bolz

  • Jan-Harald Fredriksen

  • Graeme Leese

  • Faith Ekstrand

  • John Kessenich

Description

This extension enables C-like structure layout for SPIR-V blocks. It modifies the alignment rules for uniform buffers, storage buffers and push constants, allowing non-scalar types to be aligned solely based on the size of their components, without additional requirements.

Promotion to Vulkan 1.2

Functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the scalarBlockLayout capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME

  • VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT

Version History

  • Revision 1, 2018-11-14 (Tobias Hector)

    • Initial draft

VK_EXT_separate_stencil_usage

Name String

VK_EXT_separate_stencil_usage

Extension Type

Device extension

Registered Extension Number

247

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-11-08

Interactions and External Dependencies
  • Promoted to Vulkan 1.2 Core

IP Status

No known IP claims.

Contributors
  • Daniel Rakos, AMD

  • Jordan Logan, AMD

Description

This extension allows specifying separate usage flags for the stencil aspect of images with a depth-stencil format at image creation time.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME

  • VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT

Version History

  • Revision 1, 2018-11-08 (Daniel Rakos)

    • Internal revisions.

VK_EXT_shader_demote_to_helper_invocation

Name String

VK_EXT_shader_demote_to_helper_invocation

Extension Type

Device extension

Registered Extension Number

277

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-06-01

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

Description

This extension adds Vulkan support for the SPV_EXT_demote_to_helper_invocation SPIR-V extension. That SPIR-V extension provides a new instruction OpDemoteToHelperInvocationEXT allowing shaders to “demote” a fragment shader invocation to behave like a helper invocation for its duration. The demoted invocation will have no further side effects and will not output to the framebuffer, but remains active and can participate in computing derivatives and in group operations. This is a better match for the “discard” instruction in HLSL.

New Enum Constants

  • VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_EXTENSION_NAME

  • VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DEMOTE_TO_HELPER_INVOCATION_FEATURES_EXT

New SPIR-V Capability

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2019-06-01 (Jeff Bolz)

    • Initial draft

VK_EXT_shader_subgroup_ballot

Name String

VK_EXT_shader_subgroup_ballot

Extension Type

Device extension

Registered Extension Number

65

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-11-28

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Jeff Bolz, NVIDIA

  • Neil Henning, Codeplay

  • Daniel Koch, NVIDIA Corporation

Description

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

  • SPV_KHR_shader_ballot

This extension provides the ability for a group of invocations, which execute in parallel, to do limited forms of cross-invocation communication via a group broadcast of a invocation value, or broadcast of a bitarray representing a predicate value from each invocation in the group.

This extension provides access to a number of additional built-in shader variables in Vulkan:

  • SubgroupEqMaskKHR, containing the subgroup mask of the current subgroup invocation,

  • SubgroupGeMaskKHR, containing the subgroup mask of the invocations greater than or equal to the current invocation,

  • SubgroupGtMaskKHR, containing the subgroup mask of the invocations greater than the current invocation,

  • SubgroupLeMaskKHR, containing the subgroup mask of the invocations less than or equal to the current invocation,

  • SubgroupLtMaskKHR, containing the subgroup mask of the invocations less than the current invocation,

  • SubgroupLocalInvocationId, containing the index of an invocation within a subgroup, and

  • SubgroupSize, containing the maximum number of invocations in a subgroup.

Additionally, this extension provides access to the new SPIR-V instructions:

  • OpSubgroupBallotKHR,

  • OpSubgroupFirstInvocationKHR, and

  • OpSubgroupReadInvocationKHR,

When using GLSL source-based shader languages, the following variables and shader functions from GL_ARB_shader_ballot can map to these SPIR-V built-in decorations and instructions:

  • in uint64_t gl_SubGroupEqMaskARB;SubgroupEqMaskKHR,

  • in uint64_t gl_SubGroupGeMaskARB;SubgroupGeMaskKHR,

  • in uint64_t gl_SubGroupGtMaskARB;SubgroupGtMaskKHR,

  • in uint64_t gl_SubGroupLeMaskARB;SubgroupLeMaskKHR,

  • in uint64_t gl_SubGroupLtMaskARB;SubgroupLtMaskKHR,

  • in uint gl_SubGroupInvocationARB;SubgroupLocalInvocationId,

  • uniform uint gl_SubGroupSizeARB;SubgroupSize,

  • ballotARB() → OpSubgroupBallotKHR,

  • readFirstInvocationARB() → OpSubgroupFirstInvocationKHR, and

  • readInvocationARB() → OpSubgroupReadInvocationKHR.

Deprecated by Vulkan 1.2

Most of the functionality in this extension is superseded by the core Vulkan 1.1 subgroup operations. However, Vulkan 1.1 required the OpGroupNonUniformBroadcast “Id” to be constant. This restriction was removed in Vulkan 1.2 with the addition of the subgroupBroadcastDynamicId feature.

New Enum Constants

  • VK_EXT_SHADER_SUBGROUP_BALLOT_EXTENSION_NAME

  • VK_EXT_SHADER_SUBGROUP_BALLOT_SPEC_VERSION

New SPIR-V Capabilities

Version History

  • Revision 1, 2016-11-28 (Daniel Koch)

    • Initial draft

VK_EXT_shader_subgroup_vote

Name String

VK_EXT_shader_subgroup_vote

Extension Type

Device extension

Registered Extension Number

66

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-11-28

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Neil Henning, Codeplay

  • Daniel Koch, NVIDIA Corporation

Description

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

  • SPV_KHR_subgroup_vote

This extension provides new SPIR-V instructions:

  • OpSubgroupAllKHR,

  • OpSubgroupAnyKHR, and

  • OpSubgroupAllEqualKHR.

to compute the composite of a set of boolean conditions across a group of shader invocations that are running concurrently (a subgroup). These composite results may be used to execute shaders more efficiently on a VkPhysicalDevice.

When using GLSL source-based shader languages, the following shader functions from GL_ARB_shader_group_vote can map to these SPIR-V instructions:

  • anyInvocationARB() → OpSubgroupAnyKHR,

  • allInvocationsARB() → OpSubgroupAllKHR, and

  • allInvocationsEqualARB() → OpSubgroupAllEqualKHR.

The subgroup across which the boolean conditions are evaluated is implementation-dependent, and this extension provides no guarantee over how individual shader invocations are assigned to subgroups. In particular, a subgroup has no necessary relationship with the compute shader local workgroup — any pair of shader invocations in a compute local workgroup may execute in different subgroups as used by these instructions.

Compute shaders operate on an explicitly specified group of threads (a local workgroup), but many implementations will also group non-compute shader invocations and execute them concurrently. When executing code like

if (condition) {
  result = do_fast_path();
} else {
  result = do_general_path();
}

where condition diverges between invocations, an implementation might first execute do_fast_path() for the invocations where condition is true and leave the other invocations dormant. Once do_fast_path() returns, it might call do_general_path() for invocations where condition is false and leave the other invocations dormant. In this case, the shader executes both the fast and the general path and might be better off just using the general path for all invocations.

This extension provides the ability to avoid divergent execution by evaluating a condition across an entire subgroup using code like:

if (allInvocationsARB(condition)) {
  result = do_fast_path();
} else {
  result = do_general_path();
}

The built-in function allInvocationsARB() will return the same value for all invocations in the group, so the group will either execute do_fast_path() or do_general_path(), but never both. For example, shader code might want to evaluate a complex function iteratively by starting with an approximation of the result and then refining the approximation. Some input values may require a small number of iterations to generate an accurate result (do_fast_path) while others require a larger number (do_general_path). In another example, shader code might want to evaluate a complex function (do_general_path) that can be greatly simplified when assuming a specific value for one of its inputs (do_fast_path).

Deprecated by Vulkan 1.1

All functionality in this extension is superseded by the core Vulkan 1.1 subgroup operations.

New Enum Constants

  • VK_EXT_SHADER_SUBGROUP_VOTE_EXTENSION_NAME

  • VK_EXT_SHADER_SUBGROUP_VOTE_SPEC_VERSION

New SPIR-V Capabilities

Version History

  • Revision 1, 2016-11-28 (Daniel Koch)

    • Initial draft

VK_EXT_shader_viewport_index_layer

Name String

VK_EXT_shader_viewport_index_layer

Extension Type

Device extension

Registered Extension Number

163

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2017-08-08

Interactions and External Dependencies
Contributors
  • Piers Daniell, NVIDIA

  • Jeff Bolz, NVIDIA

  • Jan-Harald Fredriksen, ARM

  • Daniel Rakos, AMD

  • Slawomir Grajeswki, Intel

Description

This extension adds support for the ShaderViewportIndexLayerEXT capability from the SPV_EXT_shader_viewport_index_layer extension in Vulkan.

This extension allows variables decorated with the Layer and ViewportIndex built-ins to be exported from vertex or tessellation shaders, using the ShaderViewportIndexLayerEXT capability.

When using GLSL source-based shading languages, the gl_ViewportIndex and gl_Layer built-in variables map to the SPIR-V ViewportIndex and Layer built-in decorations, respectively. Behaviour of these variables is extended as described in the GL_ARB_shader_viewport_layer_array (or the precursor GL_AMD_vertex_shader_layer, GL_AMD_vertex_shader_viewport_index, and GL_NV_viewport_array2 extensions).

Note

The ShaderViewportIndexLayerEXT capability is equivalent to the ShaderViewportIndexLayerNV capability added by VK_NV_viewport_array2.

Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2.

The single ShaderViewportIndexLayerEXT capability from the SPV_EXT_shader_viewport_index_layer extension is replaced by the ShaderViewportIndex and ShaderLayer capabilities from SPIR-V 1.5 which are enabled by the shaderOutputViewportIndex and shaderOutputLayer features, respectively. Additionally, if Vulkan 1.2 is supported but this extension is not, these capabilities are optional.

Enabling both features is equivalent to enabling the VK_EXT_shader_viewport_index_layer extension.

New Enum Constants

  • VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_EXTENSION_NAME

  • VK_EXT_SHADER_VIEWPORT_INDEX_LAYER_SPEC_VERSION

New or Modified Built-In Variables

New SPIR-V Capabilities

Version History

  • Revision 1, 2017-08-08 (Daniel Koch)

    • Internal drafts

VK_EXT_subgroup_size_control

Name String

VK_EXT_subgroup_size_control

Extension Type

Device extension

Registered Extension Number

226

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-03-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

Contributors
  • Jeff Bolz, NVIDIA

  • Faith Ekstrand, Intel

  • Sławek Grajewski, Intel

  • Jesse Hall, Google

  • Neil Henning, AMD

  • Daniel Koch, NVIDIA

  • Jeff Leger, Qualcomm

  • Graeme Leese, Broadcom

  • Allan MacKinnon, Google

  • Mariusz Merecki, Intel

  • Graham Wihlidal, Electronic Arts

Description

This extension enables an implementation to control the subgroup size by allowing a varying subgroup size and also specifying a required subgroup size.

It extends the subgroup support in Vulkan 1.1 to allow an implementation to expose a varying subgroup size. Previously Vulkan exposed a single subgroup size per physical device, with the expectation that implementations will behave as if all subgroups have the same size. Some implementations may dispatch shaders with a varying subgroup size for different subgroups. As a result they could implicitly split a large subgroup into smaller subgroups or represent a small subgroup as a larger subgroup, some of whose invocations were inactive on launch.

To aid developers in understanding the performance characteristics of their programs, this extension exposes a minimum and maximum subgroup size that a physical device supports and a pipeline create flag to enable that pipeline to vary its subgroup size. If enabled, any SubgroupSize decorated variables in the SPIR-V shader modules provided to pipeline creation may vary between the minimum and maximum subgroup sizes.

An implementation is also optionally allowed to support specifying a required subgroup size for a given pipeline stage. Implementations advertise which stages support a required subgroup size, and any pipeline of a supported stage can be passed a VkPipelineShaderStageRequiredSubgroupSizeCreateInfoEXT structure to set the subgroup size for that shader stage of the pipeline. For compute shaders, this requires the developer to query the maxComputeWorkgroupSubgroups and ensure that:

Developers can also specify a new pipeline shader stage create flag that requires the implementation to have fully populated subgroups within local workgroups. This requires the workgroup size in the X dimension to be a multiple of the subgroup size.

New Enum Constants

  • VK_EXT_SUBGROUP_SIZE_CONTROL_EXTENSION_NAME

  • VK_EXT_SUBGROUP_SIZE_CONTROL_SPEC_VERSION

  • Extending VkPipelineShaderStageCreateFlagBits:

    • VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT

    • VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_PROPERTIES_EXT

    • VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Version History

VK_EXT_texel_buffer_alignment

Name String

VK_EXT_texel_buffer_alignment

Extension Type

Device extension

Registered Extension Number

282

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-06-06

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension adds more expressive alignment requirements for uniform and storage texel buffers. Some implementations have single texel alignment requirements that cannot be expressed via VkPhysicalDeviceLimits::minTexelBufferOffsetAlignment.

New Enum Constants

  • VK_EXT_TEXEL_BUFFER_ALIGNMENT_EXTENSION_NAME

  • VK_EXT_TEXEL_BUFFER_ALIGNMENT_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_FEATURES_EXT

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_PROPERTIES_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. However, only the properties structure is promoted. The feature structure is not promoted and texelBufferAlignment is enabled if using a Vulkan 1.3 instance. The original type name is still available as an alias of the core functionality.

Version History

  • Revision 1, 2019-06-06 (Jeff Bolz)

    • Initial draft

VK_EXT_texture_compression_astc_hdr

Name String

VK_EXT_texture_compression_astc_hdr

Extension Type

Device extension

Registered Extension Number

67

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-05-28

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known issues.

Contributors
  • Jan-Harald Fredriksen, Arm

Description

This extension adds support for textures compressed using the Adaptive Scalable Texture Compression (ASTC) High Dynamic Range (HDR) profile.

When this extension is enabled, the HDR profile is supported for all ASTC formats listed in ASTC Compressed Image Formats.

New Enum Constants

  • VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_EXTENSION_NAME

  • VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_SPEC_VERSION

  • Extending VkFormat:

    • VK_FORMAT_ASTC_10x10_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_10x8_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_12x10_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_12x12_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_4x4_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_5x4_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_5x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_6x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_6x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x5_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x6_SFLOAT_BLOCK_EXT

    • VK_FORMAT_ASTC_8x8_SFLOAT_BLOCK_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_HDR_FEATURES_EXT

Promotion to Vulkan 1.3

This extension has been partially promoted. Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. However, the feature is made optional in Vulkan 1.3. The original type, enum and command names are still available as aliases of the core functionality.

Issues

1) Should we add a feature or limit for this functionality?

Yes. It is consistent with the ASTC LDR support to add a feature like textureCompressionASTC_HDR.

The feature is strictly speaking redundant as long as this is just an extension; it would be sufficient to just enable the extension. But adding the feature is more forward-looking if wanted to make this an optional core feature in the future.

2) Should we introduce new format enums for HDR?

Yes. Vulkan 1.0 describes the ASTC format enums as UNORM, e.g. VK_FORMAT_ASTC_4x4_UNORM_BLOCK, so it is confusing to make these contain HDR data. Note that the OpenGL (ES) extensions did not make this distinction because a single ASTC HDR texture may contain both unorm and float blocks. Implementations may not be able to distinguish between LDR and HDR ASTC textures internally and just treat them as the same format, i.e. if this extension is supported then sampling from a VK_FORMAT_ASTC_4x4_UNORM_BLOCK image format may return HDR results. Applications can get predictable results by using the appropriate image format.

Version History

  • Revision 1, 2019-05-28 (Jan-Harald Fredriksen)

    • Initial version

VK_EXT_tooling_info

Name String

VK_EXT_tooling_info

Extension Type

Device extension

Registered Extension Number

246

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-11-05

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

Contributors
  • Rolando Caloca

  • Matthaeus Chajdas

  • Baldur Karlsson

  • Daniel Rakos

Description

When an error occurs during application development, a common question is "What tools are actually running right now?" This extension adds the ability to query that information directly from the Vulkan implementation.

Outdated versions of one tool might not play nicely with another, or perhaps a tool is not actually running when it should have been. Trying to figure that out can cause headaches as it is necessary to consult each known tool to figure out what is going on — in some cases the tool might not even be known.

Typically, the expectation is that developers will simply print out this information for visual inspection when an issue occurs, however a small amount of semantic information about what the tool is doing is provided to help identify it programmatically. For example, if the advertised limits or features of an implementation are unexpected, is there a tool active which modifies these limits? Or if an application is providing debug markers, but the implementation is not actually doing anything with that information, this can quickly point that out.

New Bitmasks

New Enum Constants

  • VK_EXT_TOOLING_INFO_EXTENSION_NAME

  • VK_EXT_TOOLING_INFO_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TOOL_PROPERTIES_EXT

If VK_EXT_debug_marker is supported:

If VK_EXT_debug_report is supported:

If VK_EXT_debug_utils is supported:

  • Extending VkToolPurposeFlagBits:

    • VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT

    • VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT

Promotion to Vulkan 1.3

Functionality in this extension is included in core Vulkan 1.3, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

Examples

Printing Tool Information
uint32_t num_tools;
VkPhysicalDeviceToolPropertiesEXT *pToolProperties;
vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, NULL);

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

vkGetPhysicalDeviceToolPropertiesEXT(physicalDevice, &num_tools, pToolProperties);

for (int i = 0; i < num_tools; ++i) {
    printf("%s:\n", pToolProperties[i].name);
    printf("Version:\n");
    printf("%s:\n", pToolProperties[i].version);
    printf("Description:\n");
    printf("\t%s\n", pToolProperties[i].description);
    printf("Purposes:\n");
    printf("\t%s\n", VkToolPurposeFlagBitsEXT_to_string(pToolProperties[i].purposes));
    if (strnlen_s(pToolProperties[i].layer,VK_MAX_EXTENSION_NAME_SIZE) > 0) {
        printf("Corresponding Layer:\n");
        printf("\t%s\n", pToolProperties[i].layer);
    }
}

Issues

1) Why is this information separate from the layer mechanism?

Some tooling may be built into a driver, or be part of the Vulkan loader etc. Tying this information directly to layers would have been awkward at best.

Version History

  • Revision 1, 2018-11-05 (Tobias Hector)

    • Initial draft

VK_EXT_validation_flags

Name String

VK_EXT_validation_flags

Extension Type

Instance extension

Registered Extension Number

62

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Special Use
Contact

Other Extension Metadata

Last Modified Date

2019-08-19

IP Status

No known IP claims.

Contributors
  • Tobin Ehlis, Google

  • Courtney Goeltzenleuchter, Google

Description

This extension provides the VkValidationFlagsEXT struct that can be included in the pNext chain of the VkInstanceCreateInfo structure passed as the pCreateInfo parameter of vkCreateInstance. The structure contains an array of VkValidationCheckEXT values that will be disabled by the validation layers.

Deprecation by VK_EXT_validation_features

Functionality in this extension is subsumed into the VK_EXT_validation_features extension.

New Structures

New Enum Constants

  • VK_EXT_VALIDATION_FLAGS_EXTENSION_NAME

  • VK_EXT_VALIDATION_FLAGS_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT

Version History

  • Revision 2, 2019-08-19 (Mark Lobodzinski)

    • Marked as deprecated

  • Revision 1, 2016-08-26 (Courtney Goeltzenleuchter)

    • Initial draft

VK_EXT_ycbcr_2plane_444_formats

Name String

VK_EXT_ycbcr_2plane_444_formats

Extension Type

Device extension

Registered Extension Number

331

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-07-28

Interactions and External Dependencies
  • Promoted to Vulkan 1.3 Core

IP Status

No known IP claims.

Contributors
  • Piers Daniell, NVIDIA

  • Ping Liu, Intel

Description

This extension adds some Y′CBCR formats that are in common use for video encode and decode, but were not part of the VK_KHR_sampler_ycbcr_conversion extension.

New Enum Constants

  • VK_EXT_YCBCR_2PLANE_444_FORMATS_EXTENSION_NAME

  • VK_EXT_YCBCR_2PLANE_444_FORMATS_SPEC_VERSION

  • Extending VkFormat:

    • VK_FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16_EXT

    • VK_FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16_EXT

    • VK_FORMAT_G16_B16R16_2PLANE_444_UNORM_EXT

    • VK_FORMAT_G8_B8R8_2PLANE_444_UNORM_EXT

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_2_PLANE_444_FORMATS_FEATURES_EXT

Promotion to Vulkan 1.3

This extension has been partially promoted. The format enumerants introduced by the extension are included in core Vulkan 1.3, with the EXT suffix omitted. However, runtime support for these formats is optional in core Vulkan 1.3, while if this extension is supported, runtime support is mandatory. The feature structure is not promoted. The original enum names are still available as aliases of the core functionality.

Version History

  • Revision 1, 2020-03-08 (Piers Daniell)

    • Initial draft

VK_AMD_draw_indirect_count

Name String

VK_AMD_draw_indirect_count

Extension Type

Device extension

Registered Extension Number

34

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-08-23

Interactions and External Dependencies
IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Derrick Owens, AMD

  • Graham Sellers, AMD

  • Daniel Rakos, AMD

  • Dominik Witczak, AMD

Description

This extension allows an application to source the number of draws for indirect drawing commands from a buffer. This enables applications to generate an arbitrary number of drawing commands and execute them without host intervention.

Promotion to VK_KHR_draw_indirect_count

All functionality in this extension is included in VK_KHR_draw_indirect_count, with the suffix changed to KHR. The original type, enum and command names are still available as aliases of the core functionality.

New Enum Constants

  • VK_AMD_DRAW_INDIRECT_COUNT_EXTENSION_NAME

  • VK_AMD_DRAW_INDIRECT_COUNT_SPEC_VERSION

Version History

  • Revision 2, 2016-08-23 (Dominik Witczak)

    • Minor fixes

  • Revision 1, 2016-07-21 (Matthaeus Chajdas)

    • Initial draft

VK_AMD_gpu_shader_half_float

Name String

VK_AMD_gpu_shader_half_float

Extension Type

Device extension

Registered Extension Number

37

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-04-11

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Daniel Rakos, AMD

  • Dominik Witczak, AMD

  • Donglin Wei, AMD

  • Graham Sellers, AMD

  • Qun Lin, AMD

  • Rex Xu, AMD

Description

This extension adds support for using half float variables in shaders.

Deprecation by VK_KHR_shader_float16_int8

Functionality in this extension was included in VK_KHR_shader_float16_int8 extension, when VkPhysicalDeviceShaderFloat16Int8FeaturesKHR::shaderFloat16 is enabled.

New Enum Constants

  • VK_AMD_GPU_SHADER_HALF_FLOAT_EXTENSION_NAME

  • VK_AMD_GPU_SHADER_HALF_FLOAT_SPEC_VERSION

Version History

  • Revision 2, 2019-04-11 (Tobias Hector)

    • Marked as deprecated

  • Revision 1, 2016-09-21 (Dominik Witczak)

    • Initial draft

VK_AMD_gpu_shader_int16

Name String

VK_AMD_gpu_shader_int16

Extension Type

Device extension

Registered Extension Number

133

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2019-04-11

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Daniel Rakos, AMD

  • Dominik Witczak, AMD

  • Matthaeus G. Chajdas, AMD

  • Rex Xu, AMD

  • Timothy Lottes, AMD

  • Zhi Cai, AMD

Description

This extension adds support for using 16-bit integer variables in shaders.

Deprecation by VK_KHR_shader_float16_int8

Functionality in this extension was included in VK_KHR_shader_float16_int8 extension, when VkPhysicalDeviceFeatures::shaderInt16 and VkPhysicalDeviceShaderFloat16Int8FeaturesKHR::shaderFloat16 are enabled.

New Enum Constants

  • VK_AMD_GPU_SHADER_INT16_EXTENSION_NAME

  • VK_AMD_GPU_SHADER_INT16_SPEC_VERSION

Version History

  • Revision 2, 2019-04-11 (Tobias Hector)

    • Marked as deprecated

  • Revision 1, 2017-06-18 (Dominik Witczak)

    • First version

VK_AMD_negative_viewport_height

Name String

VK_AMD_negative_viewport_height

Extension Type

Device extension

Registered Extension Number

36

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-09-02

IP Status

No known IP claims.

Contributors
  • Matthaeus G. Chajdas, AMD

  • Graham Sellers, AMD

  • Baldur Karlsson

Description

This extension allows an application to specify a negative viewport height. The result is that the viewport transformation will flip along the y-axis.

  • Allow negative height to be specified in the VkViewport::height field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to use gl_Position.y = -gl_Position.y in shaders also targeting other APIs.

Obsoletion by VK_KHR_maintenance1 and Vulkan 1.1

Functionality in this extension is included in VK_KHR_maintenance1 and subsequently Vulkan 1.1. Due to some slight behavioral differences, this extension must not be enabled alongside VK_KHR_maintenance1, or in an instance created with version 1.1 or later requested in VkApplicationInfo::apiVersion.

New Enum Constants

  • VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_EXTENSION_NAME

  • VK_AMD_NEGATIVE_VIEWPORT_HEIGHT_SPEC_VERSION

Version History

  • Revision 1, 2016-09-02 (Matthaeus Chajdas)

    • Initial draft

VK_ARM_rasterization_order_attachment_access

Name String

VK_ARM_rasterization_order_attachment_access

Extension Type

Device extension

Registered Extension Number

343

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2021-11-12

IP Status

No known IP claims.

Contributors
  • Tobias Hector, AMD

  • Jan-Harald Fredriksen, Arm

Description

Render passes, and specifically subpass dependencies, enable much of the same functionality as the framebuffer fetch and pixel local storage extensions did for OpenGL ES. But certain techniques such as programmable blending are awkward or impractical to implement with these alone, in part because a self-dependency is required every time a fragment will read a value at a given sample coordinate.

This extension extends the mechanism of input attachments to allow access to framebuffer attachments when used as both input and color, or depth/stencil, attachments from one fragment to the next, in rasterization order, without explicit synchronization.

New Enum Constants

  • VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME

  • VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION

  • Extending VkPipelineColorBlendStateCreateFlagBits:

    • VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_ARM

  • Extending VkPipelineDepthStencilStateCreateFlagBits:

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM

    • VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_ARM

  • Extending VkSubpassDescriptionFlagBits:

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_ARM

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM

    • VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM

Issues

1) Is there any interaction with the VK_KHR_dynamic_rendering extension?

No. This extension only affects reads from input attachments. Render pass instances begun with vkCmdBeginRenderingKHR do not have input attachments and a different mechanism will be needed to provide similar functionality in this case.

Examples

None.

Version History

  • Revision 1, 2021-11-12 (Jan-Harald Fredriksen)

    • Initial draft

VK_IMG_format_pvrtc

Name String

VK_IMG_format_pvrtc

Extension Type

Device extension

Registered Extension Number

55

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
  • Deprecated without replacement

Contact
  • Stuart Smith

Other Extension Metadata

Last Modified Date

2019-09-02

IP Status

Imagination Technologies Proprietary

Contributors
  • Stuart Smith, Imagination Technologies

Description

VK_IMG_format_pvrtc provides additional texture compression functionality specific to Imagination Technologies PowerVR Texture compression format (called PVRTC).

Deprecation

Both PVRTC1 and PVRTC2 are slower than standard image formats on PowerVR GPUs, and support will be removed from future hardware.

New Enum Constants

  • VK_IMG_FORMAT_PVRTC_EXTENSION_NAME

  • VK_IMG_FORMAT_PVRTC_SPEC_VERSION

  • Extending VkFormat:

    • VK_FORMAT_PVRTC1_2BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC1_4BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC1_4BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC2_2BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC2_2BPP_UNORM_BLOCK_IMG

    • VK_FORMAT_PVRTC2_4BPP_SRGB_BLOCK_IMG

    • VK_FORMAT_PVRTC2_4BPP_UNORM_BLOCK_IMG

Version History

  • Revision 1, 2019-09-02 (Stuart Smith)

    • Initial version

VK_MVK_ios_surface

Name String

VK_MVK_ios_surface

Extension Type

Instance extension

Registered Extension Number

123

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-07-31

IP Status

No known IP claims.

Contributors
  • Bill Hollings, The Brenwill Workshop Ltd.

Description

The VK_MVK_ios_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) based on a UIView, the native surface type of iOS, which is underpinned by a CAMetalLayer, to support rendering to the surface using Apple’s Metal framework.

Deprecation by VK_EXT_metal_surface

The VK_MVK_ios_surface extension is considered deprecated and has been superseded by the VK_EXT_metal_surface extension.

New Commands

New Structures

New Enum Constants

  • VK_MVK_IOS_SURFACE_EXTENSION_NAME

  • VK_MVK_IOS_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_IOS_SURFACE_CREATE_INFO_MVK

Version History

  • Revision 1, 2017-02-15 (Bill Hollings)

    • Initial draft.

  • Revision 2, 2017-02-24 (Bill Hollings)

    • Minor syntax fix to emphasize firm requirement for UIView to be backed by a CAMetalLayer.

  • Revision 3, 2020-07-31 (Bill Hollings)

    • Update documentation on requirements for UIView.

    • Mark as deprecated by VK_EXT_metal_surface.

VK_MVK_macos_surface

Name String

VK_MVK_macos_surface

Extension Type

Instance extension

Registered Extension Number

124

Revision

3

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2020-07-31

IP Status

No known IP claims.

Contributors
  • Bill Hollings, The Brenwill Workshop Ltd.

Description

The VK_MVK_macos_surface extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the VK_KHR_surface extension) based on an NSView, the native surface type of macOS, which is underpinned by a CAMetalLayer, to support rendering to the surface using Apple’s Metal framework.

Deprecation by VK_EXT_metal_surface

The VK_MVK_macos_surface extension is considered deprecated and has been superseded by the VK_EXT_metal_surface extension.

New Enum Constants

  • VK_MVK_MACOS_SURFACE_EXTENSION_NAME

  • VK_MVK_MACOS_SURFACE_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK

Version History

  • Revision 1, 2017-02-15 (Bill Hollings)

    • Initial draft.

  • Revision 2, 2017-02-24 (Bill Hollings)

    • Minor syntax fix to emphasize firm requirement for NSView to be backed by a CAMetalLayer.

  • Revision 3, 2020-07-31 (Bill Hollings)

    • Update documentation on requirements for NSView.

    • Mark as deprecated by VK_EXT_metal_surface.

VK_NV_dedicated_allocation

Name String

VK_NV_dedicated_allocation

Extension Type

Device extension

Registered Extension Number

27

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-05-31

IP Status

No known IP claims.

Contributors
  • Jeff Bolz, NVIDIA

Description

This extension allows device memory to be allocated for a particular buffer or image resource, which on some devices can significantly improve the performance of that resource. Normal device memory allocations must support memory aliasing and sparse binding, which could interfere with optimizations like framebuffer compression or efficient page table usage. This is important for render targets and very large resources, but need not (and probably should not) be used for smaller resources that can benefit from suballocation.

This extension adds a few small structures to resource creation and memory allocation: a new structure that flags whether am image/buffer will have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

New Enum Constants

  • VK_NV_DEDICATED_ALLOCATION_EXTENSION_NAME

  • VK_NV_DEDICATED_ALLOCATION_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_BUFFER_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV

    • VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV

Examples

    // Create an image with
    // VkDedicatedAllocationImageCreateInfoNV::dedicatedAllocation
    // set to VK_TRUE

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

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

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

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

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

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

    VkMemoryAllocateInfo memoryAllocateInfo =
    {
        .sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
        .pNext = &dedicatedInfo,
        .allocationSize = memoryRequirements.size,
        .memoryTypeIndex = FindMemoryTypeIndex(memoryRequirements.memoryTypeBits),
    };

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

    // Bind the image to the memory

    vkBindImageMemory(
        device,
        image,
        memory,
        0);

Version History

  • Revision 1, 2016-05-31 (Jeff Bolz)

    • Internal revisions

VK_NV_external_memory

Name String

VK_NV_external_memory

Extension Type

Device extension

Registered Extension Number

57

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-08-19

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

Description

Applications may wish to export memory to other Vulkan instances or other APIs, or import memory from other Vulkan instances or other APIs to enable Vulkan workloads to be split up across application module, process, or API boundaries. This extension enables applications to create exportable Vulkan memory objects such that the underlying resources can be referenced outside the Vulkan instance that created them.

New Enum Constants

  • VK_NV_EXTERNAL_MEMORY_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV

    • VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV

Issues

1) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes, but strict exceptions to the rules are added to allow some forms of aliasing in these cases. Further, other extensions may build upon these new aliasing rules to define specific support usage within Vulkan for imported native memory objects, or memory objects from other APIs.

2) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: No. Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan compatible (a term to be defined by subsequent interopability extensions), or Vulkan incompatible. When sharing images with Vulkan incompatible APIs, the Vulkan image must be transitioned to the VK_IMAGE_LAYOUT_GENERAL layout before handing it off to the external API.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

Examples

    // TODO: Write some sample code here.

Version History

  • Revision 1, 2016-08-19 (James Jones)

    • Initial draft

VK_NV_external_memory_capabilities

Name String

VK_NV_external_memory_capabilities

Extension Type

Instance extension

Registered Extension Number

56

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-08-19

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • James Jones, NVIDIA

Description

Applications may wish to import memory from the Direct 3D API, or export memory to other Vulkan instances. This extension provides a set of capability queries that allow applications determine what types of win32 memory handles an implementation supports for a given set of use cases.

New Enum Constants

  • VK_NV_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION

Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

RESOLVED: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.

2) Does the VkExternalImageFormatPropertiesNV struct need to include a list of memory type bits that support the given handle type?

RESOLVED: No. The memory types that do not support the handle types will simply be filtered out of the results returned by vkGetImageMemoryRequirements when a set of handle types was specified at image creation time.

3) Should the non-opaque handle types be moved to their own extension?

RESOLVED: Perhaps. However, defining the handle type bits does very little and does not require any platform-specific types on its own, and it is easier to maintain the bitmask values in a single extension for now. Presumably more handle types could be added by separate extensions though, and it would be midly weird to have some platform-specific ones defined in the core spec and some in extensions

Version History

  • Revision 1, 2016-08-19 (James Jones)

    • Initial version

VK_NV_external_memory_win32

Name String

VK_NV_external_memory_win32

Extension Type

Device extension

Registered Extension Number

58

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-08-19

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

Description

Applications may wish to export memory to other Vulkan instances or other APIs, or import memory from other Vulkan instances or other APIs to enable Vulkan workloads to be split up across application module, process, or API boundaries. This extension enables win32 applications to export win32 handles from Vulkan memory objects such that the underlying resources can be referenced outside the Vulkan instance that created them, and import win32 handles created in the Direct3D API to Vulkan memory objects.

New Enum Constants

  • VK_NV_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME

  • VK_NV_EXTERNAL_MEMORY_WIN32_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV

    • VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_NV

Issues

1) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes, but strict exceptions to the rules are added to allow some forms of aliasing in these cases. Further, other extensions may build upon these new aliasing rules to define specific support usage within Vulkan for imported native memory objects, or memory objects from other APIs.

2) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: No. Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan compatible (a term to be defined by subsequent interopability extensions), or Vulkan incompatible. When sharing images with Vulkan incompatible APIs, the Vulkan image must be transitioned to the VK_IMAGE_LAYOUT_GENERAL layout before handing it off to the external API.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

3) Do applications need to call CloseHandle() on the values returned from vkGetMemoryWin32HandleNV when handleType is VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV?

RESOLVED: Yes, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application, while an import transfers ownership to the associated driver. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource.

Examples

    //
    // Create an exportable memory object and export an external
    // handle from it.
    //

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

    extern VkPhysicalDevice physicalDevice;
    extern VkDevice device;

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

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

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

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

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

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

    vkGetImageMemoryRequirements(device,
                                 image,
                                 &imageMemoryRequirements);

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

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

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

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

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

    // Get the external memory opaque FD handle
    vkGetMemoryWin32HandleNV(device, memory, &memoryHnd);

Version History

  • Revision 1, 2016-08-11 (James Jones)

    • Initial draft

VK_NV_fragment_shader_barycentric

Name String

VK_NV_fragment_shader_barycentric

Extension Type

Device extension

Registered Extension Number

204

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2018-08-03

IP Status

No known IP claims.

Interactions and External Dependencies
Contributors
  • Pat Brown, NVIDIA

  • Daniel Koch, NVIDIA

Description

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

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

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

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

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

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

  • in vec3 gl_BaryCoordNV;BaryCoordNV

  • in vec3 gl_BaryCoordNoPerspNV;BaryCoordNoPerspNV

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

Promotion to VK_KHR_fragment_shader_barycentric

All functionality in this extension is included in VK_KHR_fragment_shader_barycentric, with the suffix changed to KHR.

New Enum Constants

  • VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME

  • VK_NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV

New Built-In Variables

New SPIR-V Decorations

New SPIR-V Capabilities

Issues

(1) The AMD_shader_explicit_vertex_parameter extension provides similar functionality. Why write a new extension, and how is this extension different?

RESOLVED: For the purposes of Vulkan/SPIR-V, we chose to implement a separate extension due to several functional differences.

First, the hardware supporting this extension can provide a three-component barycentric weight vector for variables decorated with BaryCoordNV, while variables decorated with BaryCoordSmoothAMD provide only two components. In some cases, it may be more efficient to explicitly interpolate an attribute via:

float value = (baryCoordNV.x * v[0].attrib +
               baryCoordNV.y * v[1].attrib +
               baryCoordNV.z * v[2].attrib);

instead of

float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
               baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
               v[2].attrib);

Additionally, the semantics of the decoration BaryCoordPullModelAMD do not appear to map to anything supported by the initial hardware implementation of this extension.

This extension provides a smaller number of decorations than the AMD extension, as we expect that shaders could derive variables decorated with things like BaryCoordNoPerspCentroidAMD with explicit attribute interpolation instructions. One other relevant difference is that explicit per-vertex attribute access using this extension does not require a constant vertex number.

(2) Why do the built-in SPIR-V decorations for this extension include two separate built-ins BaryCoordNV and BaryCoordNoPerspNV when a “no perspective” variable could be decorated with BaryCoordNV and NoPerspective?

RESOLVED: The SPIR-V extension for this feature chose to mirror the behavior of the GLSL extension, which provides two built-in variables. Additionally, it is not clear that its a good idea (or even legal) to have two variables using the “same attribute”, but with different interpolation modifiers.

Version History

  • Revision 1, 2018-08-03 (Pat Brown)

    • Internal revisions

VK_NV_glsl_shader

Name String

VK_NV_glsl_shader

Extension Type

Device extension

Registered Extension Number

13

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
  • Deprecated without replacement

Contact

Other Extension Metadata

Last Modified Date

2016-02-14

IP Status

No known IP claims.

Contributors
  • Piers Daniell, NVIDIA

Description

This extension allows GLSL shaders written to the GL_KHR_vulkan_glsl extension specification to be used instead of SPIR-V. The implementation will automatically detect whether the shader is SPIR-V or GLSL, and compile it appropriately.

Deprecation

Functionality in this extension is outside of the scope of Vulkan and is better served by a compiler library such as glslang. No new implementations will support this extension, so applications should not use it.

New Enum Constants

  • VK_NV_GLSL_SHADER_EXTENSION_NAME

  • VK_NV_GLSL_SHADER_SPEC_VERSION

  • Extending VkResult:

    • VK_ERROR_INVALID_SHADER_NV

Examples

Example 1

Passing in GLSL code

    char const vss[] =
        "#version 450 core\n"
        "layout(location = 0) in vec2 aVertex;\n"
        "layout(location = 1) in vec4 aColor;\n"
        "out vec4 vColor;\n"
        "void main()\n"
        "{\n"
        "    vColor = aColor;\n"
        "    gl_Position = vec4(aVertex, 0, 1);\n"
        "}\n"
    ;
    VkShaderModuleCreateInfo vertexShaderInfo = { VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO };
    vertexShaderInfo.codeSize = sizeof vss;
    vertexShaderInfo.pCode = vss;
    VkShaderModule vertexShader;
    vkCreateShaderModule(device, &vertexShaderInfo, 0, &vertexShader);

Version History

  • Revision 1, 2016-02-14 (Piers Daniell)

    • Initial draft

VK_NV_win32_keyed_mutex

Name String

VK_NV_win32_keyed_mutex

Extension Type

Device extension

Registered Extension Number

59

Revision

2

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Contact

Other Extension Metadata

Last Modified Date

2016-08-19

IP Status

No known IP claims.

Contributors
  • James Jones, NVIDIA

  • Carsten Rohde, NVIDIA

Description

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

New Enum Constants

  • VK_NV_WIN32_KEYED_MUTEX_EXTENSION_NAME

  • VK_NV_WIN32_KEYED_MUTEX_SPEC_VERSION

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV

Examples

    //
    // Import a memory object from Direct3D 11, and synchronize
    // access to it in Vulkan using keyed mutex objects.
    //

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

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

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

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

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

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

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

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

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

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

    // Allocate the external memory object.
    memset(&exportMemoryAllocateInfo, 0, sizeof(exportMemoryAllocateInfo));
    exportMemoryAllocateInfo.sType =
        VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV;
    importMemoryInfo.handleTypes = handleType;
    importMemoryInfo.handle = sharedNtHandle;

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

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

    vkBindImageMemory(device, image, mem, 0);

    ...

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

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

    VkSubmitInfo submit_info = { VK_STRUCTURE_TYPE_SUBMIT_INFO, &keyedMutex };
    submit_info.commandBufferCount = 1;
    submit_info.pCommandBuffers = &cmd_buf;
    vkQueueSubmit(queue, 1, &submit_info, VK_NULL_HANDLE);

Version History

  • Revision 2, 2016-08-11 (James Jones)

    • Updated sample code based on the NV external memory extensions.

    • Renamed from NVX to NV extension.

    • Added Overview and Description sections.

    • Updated sample code to use the NV external memory extensions.

  • Revision 1, 2016-06-14 (Carsten Rohde)

    • Initial draft.

VK_VALVE_mutable_descriptor_type

Name String

VK_VALVE_mutable_descriptor_type

Extension Type

Device extension

Registered Extension Number

352

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies
Deprecation state
Special Use
Contact

Other Extension Metadata

Last Modified Date

2020-12-02

IP Status

No known IP claims.

Contributors
  • Joshua Ashton, Valve

  • Hans-Kristian Arntzen, Valve

Description

This extension allows applications to reduce descriptor memory footprint by allowing a descriptor to be able to mutate to a given list of descriptor types depending on which descriptor types are written into, or copied into a descriptor set.

The main use case this extension intends to address is descriptor indexing with VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT where the descriptor types are completely generic, as this means applications can allocate one large descriptor set, rather than having one large descriptor set per descriptor type, which significantly bloats descriptor memory usage and causes performance issues.

This extension also adds a mechanism to declare that a descriptor pool, and therefore the descriptor sets that are allocated from it, reside only in host memory; as such these descriptors can only be updated/copied, but not bound.

These features together allow much more efficient emulation of the raw D3D12 binding model. This extension is primarily intended to be useful for API layering efforts.

New Enum Constants

  • VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME

  • VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION

  • Extending VkDescriptorPoolCreateFlagBits:

    • VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_VALVE

  • Extending VkDescriptorSetLayoutCreateFlagBits:

    • VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_VALVE

  • Extending VkDescriptorType:

    • VK_DESCRIPTOR_TYPE_MUTABLE_VALVE

  • Extending VkStructureType:

    • VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_VALVE

    • VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_VALVE

Version History

  • Revision 1, 2020-12-01 (Joshua Ashton, Hans-Kristian Arntzen)

    • Initial specification, squashed from public draft.