Author: The Khronos® Vulkan Working Group

# Vulkan® 1.3.227 - A Specification (with all registered extensions)

The Khronos® Vulkan Working Group
version 1.3.227, 2022-09-08 16:48:57Z
from git branch: Git branch not available commit: Git commit not available

Loading… please wait.

Search:

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

https://registry.khronos.org/vulkan/

and allows generating versions of the Specification incorporating different extensions.

Most of the content previously in this appendix does not specify use of specific Vulkan extensions and layers, but rather specifies the processes by which extensions and layers are created. As of version 1.0.21 of the Vulkan Specification, this content has been migrated to the Vulkan Documentation and Extensions document. Authors creating extensions and layers must follow the mandatory procedures in that document.

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.

| Note As of the initial Vulkan 1.1 public release, the `KHX` author ID is no longer used. All `KHX` extensions have been promoted to `KHR` status. Previously, this author ID was used to indicate that an extension was experimental, and is being considered for standardization in future `KHR` or core Vulkan API versions. We no longer use this mechanism for exposing experimental functionality. Some vendors may use an alternate author ID ending in `X` for some of their extensions. The exact meaning of such an author ID is defined by each vendor, and may not be equivalent to `KHX`, but it is likely to indicate a lesser degree of interface stability than a non-`X` extension from the same vendor.

### List of Current Extensions

- `VK_KHR_acceleration_structure`

- `VK_KHR_android_surface`

- `VK_KHR_deferred_host_operations`

- `VK_KHR_display`

- `VK_KHR_display_swapchain`

- `VK_KHR_external_fence_fd`

- `VK_KHR_external_fence_win32`

- `VK_KHR_external_memory_fd`

- `VK_KHR_external_memory_win32`

- `VK_KHR_external_semaphore_fd`

- `VK_KHR_external_semaphore_win32`

- `VK_KHR_fragment_shader_barycentric`

- `VK_KHR_fragment_shading_rate`

- `VK_KHR_get_display_properties2`

- `VK_KHR_get_surface_capabilities2`

- `VK_KHR_global_priority`

- `VK_KHR_incremental_present`

- `VK_KHR_performance_query`

- `VK_KHR_pipeline_executable_properties`

- `VK_KHR_pipeline_library`

- `VK_KHR_portability_enumeration`

- `VK_KHR_present_id`

- `VK_KHR_present_wait`

- `VK_KHR_push_descriptor`

- `VK_KHR_ray_query`

- `VK_KHR_ray_tracing_maintenance1`

- `VK_KHR_ray_tracing_pipeline`

- `VK_KHR_shader_clock`

- `VK_KHR_shader_subgroup_uniform_control_flow`

- `VK_KHR_shared_presentable_image`

- `VK_KHR_surface`

- `VK_KHR_surface_protected_capabilities`

- `VK_KHR_swapchain`

- `VK_KHR_swapchain_mutable_format`

- `VK_KHR_wayland_surface`

- `VK_KHR_win32_keyed_mutex`

- `VK_KHR_win32_surface`

- `VK_KHR_workgroup_memory_explicit_layout`

- `VK_KHR_xcb_surface`

- `VK_KHR_xlib_surface`

- `VK_EXT_acquire_drm_display`

- `VK_EXT_acquire_xlib_display`

- `VK_EXT_astc_decode_mode`

- `VK_EXT_attachment_feedback_loop_layout`

- `VK_EXT_blend_operation_advanced`

- `VK_EXT_border_color_swizzle`

- `VK_EXT_calibrated_timestamps`

- `VK_EXT_color_write_enable`

- `VK_EXT_conditional_rendering`

- `VK_EXT_conservative_rasterization`

- `VK_EXT_custom_border_color`

- `VK_EXT_debug_utils`

- `VK_EXT_depth_clamp_zero_one`

- `VK_EXT_depth_clip_control`

- `VK_EXT_depth_clip_enable`

- `VK_EXT_depth_range_unrestricted`

- `VK_EXT_device_memory_report`

- `VK_EXT_direct_mode_display`

- `VK_EXT_directfb_surface`

- `VK_EXT_discard_rectangles`

- `VK_EXT_display_control`

- `VK_EXT_display_surface_counter`

- `VK_EXT_external_memory_dma_buf`

- `VK_EXT_external_memory_host`

- `VK_EXT_filter_cubic`

- `VK_EXT_fragment_density_map`

- `VK_EXT_fragment_density_map2`

- `VK_EXT_fragment_shader_interlock`

- `VK_EXT_full_screen_exclusive`

- `VK_EXT_graphics_pipeline_library`

- `VK_EXT_hdr_metadata`

- `VK_EXT_headless_surface`

- `VK_EXT_image_2d_view_of_3d`

- `VK_EXT_image_compression_control`

- `VK_EXT_image_compression_control_swapchain`

- `VK_EXT_image_drm_format_modifier`

- `VK_EXT_image_view_min_lod`

- `VK_EXT_index_type_uint8`

- `VK_EXT_legacy_dithering`

- `VK_EXT_line_rasterization`

- `VK_EXT_load_store_op_none`

- `VK_EXT_memory_budget`

- `VK_EXT_memory_priority`

- `VK_EXT_mesh_shader`

- `VK_EXT_metal_objects`

- `VK_EXT_metal_surface`

- `VK_EXT_multi_draw`

- `VK_EXT_multisampled_render_to_single_sampled`

- `VK_EXT_non_seamless_cube_map`

- `VK_EXT_pageable_device_local_memory`

- `VK_EXT_pci_bus_info`

- `VK_EXT_physical_device_drm`

- `VK_EXT_pipeline_properties`

- `VK_EXT_pipeline_robustness`

- `VK_EXT_post_depth_coverage`

- `VK_EXT_primitive_topology_list_restart`

- `VK_EXT_primitives_generated_query`

- `VK_EXT_provoking_vertex`

- `VK_EXT_queue_family_foreign`

- `VK_EXT_rasterization_order_attachment_access`

- `VK_EXT_rgba10x6_formats`

- `VK_EXT_robustness2`

- `VK_EXT_sample_locations`

- `VK_EXT_shader_atomic_float`

- `VK_EXT_shader_atomic_float2`

- `VK_EXT_shader_image_atomic_int64`

- `VK_EXT_shader_module_identifier`

- `VK_EXT_shader_stencil_export`

- `VK_EXT_subpass_merge_feedback`

- `VK_EXT_swapchain_colorspace`

- `VK_EXT_transform_feedback`

- `VK_EXT_validation_cache`

- `VK_EXT_validation_features`

- `VK_EXT_vertex_attribute_divisor`

- `VK_EXT_vertex_input_dynamic_state`

- `VK_EXT_ycbcr_image_arrays`

- `VK_AMD_buffer_marker`

- `VK_AMD_device_coherent_memory`

- `VK_AMD_display_native_hdr`

- `VK_AMD_gcn_shader`

- `VK_AMD_memory_overallocation_behavior`

- `VK_AMD_mixed_attachment_samples`

- `VK_AMD_pipeline_compiler_control`

- `VK_AMD_rasterization_order`

- `VK_AMD_shader_ballot`

- `VK_AMD_shader_core_properties`

- `VK_AMD_shader_core_properties2`

- `VK_AMD_shader_early_and_late_fragment_tests`

- `VK_AMD_shader_explicit_vertex_parameter`

- `VK_AMD_shader_fragment_mask`

- `VK_AMD_shader_image_load_store_lod`

- `VK_AMD_shader_info`

- `VK_AMD_shader_trinary_minmax`

- `VK_AMD_texture_gather_bias_lod`

- `VK_ANDROID_external_memory_android_hardware_buffer`

- `VK_FUCHSIA_buffer_collection`

- `VK_FUCHSIA_external_memory`

- `VK_FUCHSIA_external_semaphore`

- `VK_FUCHSIA_imagepipe_surface`

- `VK_GGP_frame_token`

- `VK_GGP_stream_descriptor_surface`

- `VK_GOOGLE_decorate_string`

- `VK_GOOGLE_display_timing`

- `VK_GOOGLE_hlsl_functionality1`

- `VK_GOOGLE_surfaceless_query`

- `VK_GOOGLE_user_type`

- `VK_HUAWEI_invocation_mask`

- `VK_HUAWEI_subpass_shading`

- `VK_IMG_filter_cubic`

- `VK_IMG_format_pvrtc`

- `VK_INTEL_performance_query`

- `VK_INTEL_shader_integer_functions2`

- `VK_NN_vi_surface`

- `VK_NV_acquire_winrt_display`

- `VK_NV_clip_space_w_scaling`

- `VK_NV_compute_shader_derivatives`

- `VK_NV_cooperative_matrix`

- `VK_NV_corner_sampled_image`

- `VK_NV_coverage_reduction_mode`

- `VK_NV_dedicated_allocation_image_aliasing`

- `VK_NV_device_diagnostic_checkpoints`

- `VK_NV_device_diagnostics_config`

- `VK_NV_device_generated_commands`

- `VK_NV_external_memory_rdma`

- `VK_NV_fill_rectangle`

- `VK_NV_fragment_coverage_to_color`

- `VK_NV_fragment_shading_rate_enums`

- `VK_NV_framebuffer_mixed_samples`

- `VK_NV_geometry_shader_passthrough`

- `VK_NV_inherited_viewport_scissor`

- `VK_NV_linear_color_attachment`

- `VK_NV_mesh_shader`

- `VK_NV_ray_tracing`

- `VK_NV_ray_tracing_motion_blur`

- `VK_NV_representative_fragment_test`

- `VK_NV_sample_mask_override_coverage`

- `VK_NV_scissor_exclusive`

- `VK_NV_shader_image_footprint`

- `VK_NV_shader_sm_builtins`

- `VK_NV_shader_subgroup_partitioned`

- `VK_NV_shading_rate_image`

- `VK_NV_viewport_array2`

- `VK_NV_viewport_swizzle`

- `VK_NVX_binary_import`

- `VK_NVX_image_view_handle`

- `VK_NVX_multiview_per_view_attributes`

- `VK_QCOM_fragment_density_map_offset`

- `VK_QCOM_image_processing`

- `VK_QCOM_render_pass_shader_resolve`

- `VK_QCOM_render_pass_store_ops`

- `VK_QCOM_render_pass_transform`

- `VK_QCOM_rotated_copy_commands`

- `VK_QCOM_tile_properties`

- `VK_QNX_screen_surface`

- `VK_SEC_amigo_profiling`

- `VK_VALVE_descriptor_set_host_mapping`

- `VK_VALVE_mutable_descriptor_type`

#### VK_KHR_acceleration_structure

Name String

  `VK_KHR_acceleration_structure`

Extension Type

  Device extension

Registered Extension Number

  151

Revision

  13

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_EXT_descriptor_indexing` to be enabled for any device-level functionality

  - Requires `VK_KHR_buffer_device_address` to be enabled for any device-level functionality

  - Requires `VK_KHR_deferred_host_operations` to be enabled for any device-level functionality

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2021-09-30

Contributors

  - Samuel Bourasseau, Adobe

  - Matthäus Chajdas, AMD

  - Greg Grebe, AMD

  - Nicolai Hähnle, AMD

  - Tobias Hector, AMD

  - Dave Oldcorn, AMD

  - Skyler Saleh, AMD

  - Mathieu Robart, Arm

  - Marius Bjorge, Arm

  - Tom Olson, Arm

  - Sebastian Tafuri, EA

  - Henrik Rydgard, Embark

  - Juan Cañada, Epic Games

  - Patrick Kelly, Epic Games

  - Yuriy O’Donnell, Epic Games

  - Michael Doggett, Facebook/Oculus

  - Ricardo Garcia, Igalia

  - Andrew Garrard, Imagination

  - Don Scorgie, Imagination

  - Dae Kim, Imagination

  - Joshua Barczak, Intel

  - Slawek Grajewski, Intel

  - Jeff Bolz, NVIDIA

  - Pascal Gautron, NVIDIA

  - Daniel Koch, NVIDIA

  - Christoph Kubisch, NVIDIA

  - Ashwin Lele, NVIDIA

  - Robert Stepinski, NVIDIA

  - Martin Stich, NVIDIA

  - Nuno Subtil, NVIDIA

  - Eric Werness, NVIDIA

  - Jon Leech, Khronos

  - Jeroen van Schijndel, OTOY

  - Juul Joosten, OTOY

  - Alex Bourd, Qualcomm

  - Roman Larionov, Qualcomm

  - David McAllister, Qualcomm

  - Lewis Gordon, Samsung

  - Ralph Potter, Samsung

  - Jasper Bekkers, Traverse Research

  - Jesse Barker, Unity

  - Baldur Karlsson, Valve

#### Description

In order to be efficient, rendering techniques such as ray tracing need a quick way to identify which primitives may be intersected by a ray traversing the geometries. Acceleration structures are the most common way to represent the geometry spatially sorted, in order to quickly identify such potential intersections.

This extension adds new functionalities:

- Acceleration structure objects and build commands

- Structures to describe geometry inputs to acceleration structure builds

- Acceleration structure copy commands

#### New Object Types

- VkAccelerationStructureKHR

#### New Commands

- vkBuildAccelerationStructuresKHR

- vkCmdBuildAccelerationStructuresIndirectKHR

- vkCmdBuildAccelerationStructuresKHR

- vkCmdCopyAccelerationStructureKHR

- vkCmdCopyAccelerationStructureToMemoryKHR

- vkCmdCopyMemoryToAccelerationStructureKHR

- vkCmdWriteAccelerationStructuresPropertiesKHR

- vkCopyAccelerationStructureKHR

- vkCopyAccelerationStructureToMemoryKHR

- vkCopyMemoryToAccelerationStructureKHR

- vkCreateAccelerationStructureKHR

- vkDestroyAccelerationStructureKHR

- vkGetAccelerationStructureBuildSizesKHR

- vkGetAccelerationStructureDeviceAddressKHR

- vkGetDeviceAccelerationStructureCompatibilityKHR

- vkWriteAccelerationStructuresPropertiesKHR

#### New Structures

- VkAabbPositionsKHR

- VkAccelerationStructureBuildGeometryInfoKHR

- VkAccelerationStructureBuildRangeInfoKHR

- VkAccelerationStructureBuildSizesInfoKHR

- VkAccelerationStructureCreateInfoKHR

- VkAccelerationStructureDeviceAddressInfoKHR

- VkAccelerationStructureGeometryAabbsDataKHR

- VkAccelerationStructureGeometryInstancesDataKHR

- VkAccelerationStructureGeometryKHR

- VkAccelerationStructureGeometryTrianglesDataKHR

- VkAccelerationStructureInstanceKHR

- VkAccelerationStructureVersionInfoKHR

- VkCopyAccelerationStructureInfoKHR

- VkCopyAccelerationStructureToMemoryInfoKHR

- VkCopyMemoryToAccelerationStructureInfoKHR

- VkTransformMatrixKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceAccelerationStructureFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceAccelerationStructurePropertiesKHR

- Extending VkWriteDescriptorSet:

  - VkWriteDescriptorSetAccelerationStructureKHR

#### New Unions

- VkAccelerationStructureGeometryDataKHR

- VkDeviceOrHostAddressConstKHR

- VkDeviceOrHostAddressKHR

#### New Enums

- VkAccelerationStructureBuildTypeKHR

- VkAccelerationStructureCompatibilityKHR

- VkAccelerationStructureCreateFlagBitsKHR

- VkAccelerationStructureTypeKHR

- VkBuildAccelerationStructureFlagBitsKHR

- VkBuildAccelerationStructureModeKHR

- VkCopyAccelerationStructureModeKHR

- VkGeometryFlagBitsKHR

- VkGeometryInstanceFlagBitsKHR

- VkGeometryTypeKHR

#### New Bitmasks

- VkAccelerationStructureCreateFlagsKHR

- VkBuildAccelerationStructureFlagsKHR

- VkGeometryFlagsKHR

- VkGeometryInstanceFlagsKHR

#### New Enum Constants

- `VK_KHR_ACCELERATION_STRUCTURE_EXTENSION_NAME`

- `VK_KHR_ACCELERATION_STRUCTURE_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_KHR`

  - `VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_KHR`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR`

  - `VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR`

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR_EXT`

- Extending VkDescriptorType:

  - `VK_DESCRIPTOR_TYPE_ACCELERATION_STRUCTURE_KHR`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR`

- Extending VkIndexType:

  - `VK_INDEX_TYPE_NONE_KHR`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_ACCELERATION_STRUCTURE_KHR`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_COMPACTED_SIZE_KHR`

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_SIZE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_GEOMETRY_INFO_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_DEVICE_ADDRESS_INFO_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_AABBS_DATA_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_INSTANCES_DATA_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_TRIANGLES_DATA_KHR`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR`

  - `VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_COPY_ACCELERATION_STRUCTURE_TO_MEMORY_INFO_KHR`

  - `VK_STRUCTURE_TYPE_COPY_MEMORY_TO_ACCELERATION_STRUCTURE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_ACCELERATION_STRUCTURE_KHR`

If VK_KHR_format_feature_flags2 is supported:

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR`

#### Issues

(1) How does this extension differ from VK_NV_ray_tracing?

DISCUSSION:

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

- added acceleration structure serialization / deserialization (`VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR`, `VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR`, vkCmdCopyAccelerationStructureToMemoryKHR, vkCmdCopyMemoryToAccelerationStructureKHR)

- document inactive primitives and instances

- added VkPhysicalDeviceAccelerationStructureFeaturesKHR structure

- added indirect and batched acceleration structure builds (vkCmdBuildAccelerationStructuresIndirectKHR)

- added host acceleration structure commands

- reworked geometry structures so they could be better shared between device, host, and indirect builds

- explicitly made VkAccelerationStructureKHR use device addresses

- added acceleration structure compatibility check function (vkGetDeviceAccelerationStructureCompatibilityKHR)

- add parameter for requesting memory requirements for host and/or device build

- added format feature for acceleration structure build vertex formats (`VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR`)

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

DISCUSSION:

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

- Aliased functionality — enums, structures, and commands that are considered equivalent:

  - VkGeometryTypeNV ↔ VkGeometryTypeKHR

  - VkAccelerationStructureTypeNV ↔ VkAccelerationStructureTypeKHR

  - VkCopyAccelerationStructureModeNV ↔ VkCopyAccelerationStructureModeKHR

  - VkGeometryFlagsNV ↔ VkGeometryFlagsKHR

  - VkGeometryFlagBitsNV ↔ VkGeometryFlagBitsKHR

  - VkGeometryInstanceFlagsNV ↔ VkGeometryInstanceFlagsKHR

  - VkGeometryInstanceFlagBitsNV ↔ VkGeometryInstanceFlagBitsKHR

  - VkBuildAccelerationStructureFlagsNV ↔ VkBuildAccelerationStructureFlagsKHR

  - VkBuildAccelerationStructureFlagBitsNV ↔ VkBuildAccelerationStructureFlagBitsKHR

  - VkTransformMatrixNV ↔ VkTransformMatrixKHR (added to VK_NV_ray_tracing for descriptive purposes)

  - VkAabbPositionsNV ↔ VkAabbPositionsKHR (added to VK_NV_ray_tracing for descriptive purposes)

  - VkAccelerationStructureInstanceNV ↔ VkAccelerationStructureInstanceKHR (added to VK_NV_ray_tracing for descriptive purposes)

- Changed enums, structures, and commands:

  - renamed `VK_GEOMETRY_INSTANCE_TRIANGLE_CULL_DISABLE_BIT_NV` → `VK_GEOMETRY_INSTANCE_TRIANGLE_FACING_CULL_DISABLE_BIT_KHR` in VkGeometryInstanceFlagBitsKHR

  - VkGeometryTrianglesNV → VkAccelerationStructureGeometryTrianglesDataKHR (device or host address instead of buffer+offset)

  - VkGeometryAABBNV → VkAccelerationStructureGeometryAabbsDataKHR (device or host address instead of buffer+offset)

  - VkGeometryDataNV → VkAccelerationStructureGeometryDataKHR (union of triangle/aabbs/instances)

  - VkGeometryNV → VkAccelerationStructureGeometryKHR (changed type of geometry)

  - VkAccelerationStructureCreateInfoNV → VkAccelerationStructureCreateInfoKHR (reshuffle geometry layout/information)

  - VkPhysicalDeviceRayTracingPropertiesNV → VkPhysicalDeviceAccelerationStructurePropertiesKHR (for acceleration structure properties, renamed `maxTriangleCount` to `maxPrimitiveCount`, added per stage and update after bind limits) and VkPhysicalDeviceRayTracingPipelinePropertiesKHR (for ray tracing pipeline properties)

  - VkAccelerationStructureMemoryRequirementsInfoNV (deleted - replaced by allocating on top of VkBuffer)

  - VkWriteDescriptorSetAccelerationStructureNV → VkWriteDescriptorSetAccelerationStructureKHR (different acceleration structure type)

  - vkCreateAccelerationStructureNV → vkCreateAccelerationStructureKHR (device address, different geometry layout/information)

  - vkGetAccelerationStructureMemoryRequirementsNV (deleted - replaced by allocating on top of VkBuffer)

  - vkCmdBuildAccelerationStructureNV → vkCmdBuildAccelerationStructuresKHR (params moved to structs, layout differences)

  - vkCmdCopyAccelerationStructureNV → vkCmdCopyAccelerationStructureKHR (params to struct, extendable)

  - vkGetAccelerationStructureHandleNV → vkGetAccelerationStructureDeviceAddressKHR (device address instead of handle)

  - VkAccelerationStructureMemoryRequirementsTypeNV → size queries for scratch space moved to vkGetAccelerationStructureBuildSizesKHR

  - vkDestroyAccelerationStructureNV → vkDestroyAccelerationStructureKHR (different acceleration structure types)

  - vkCmdWriteAccelerationStructuresPropertiesNV → vkCmdWriteAccelerationStructuresPropertiesKHR (different acceleration structure types)

- Added enums, structures and commands:

  - `VK_GEOMETRY_TYPE_INSTANCES_KHR` to VkGeometryTypeKHR enum

  - `VK_COPY_ACCELERATION_STRUCTURE_MODE_SERIALIZE_KHR`, `VK_COPY_ACCELERATION_STRUCTURE_MODE_DESERIALIZE_KHR` to VkCopyAccelerationStructureModeKHR enum

  - VkPhysicalDeviceAccelerationStructureFeaturesKHR structure

  - VkAccelerationStructureBuildTypeKHR enum

  - VkBuildAccelerationStructureModeKHR enum

  - VkDeviceOrHostAddressKHR and VkDeviceOrHostAddressConstKHR unions

  - VkAccelerationStructureBuildRangeInfoKHR struct

  - VkAccelerationStructureGeometryInstancesDataKHR struct

  - VkAccelerationStructureDeviceAddressInfoKHR struct

  - VkAccelerationStructureVersionInfoKHR struct

  - VkStridedDeviceAddressRegionKHR struct

  - VkCopyAccelerationStructureToMemoryInfoKHR struct

  - VkCopyMemoryToAccelerationStructureInfoKHR struct

  - VkCopyAccelerationStructureInfoKHR struct

  - vkBuildAccelerationStructuresKHR command (host build)

  - vkCopyAccelerationStructureKHR command (host copy)

  - vkCopyAccelerationStructureToMemoryKHR (host serialize)

  - vkCopyMemoryToAccelerationStructureKHR (host deserialize)

  - vkWriteAccelerationStructuresPropertiesKHR (host properties)

  - vkCmdCopyAccelerationStructureToMemoryKHR (device serialize)

  - vkCmdCopyMemoryToAccelerationStructureKHR (device deserialize)

  - vkGetDeviceAccelerationStructureCompatibilityKHR (serialization)

(3) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the internal provisional (VK_KHR_ray_tracing v9) release?

- added `geometryFlags` to `VkAccelerationStructureCreateGeometryTypeInfoKHR` (later reworked to obsolete this)

- added `minAccelerationStructureScratchOffsetAlignment` property to VkPhysicalDeviceRayTracingPropertiesKHR

- fix naming and return enum from vkGetDeviceAccelerationStructureCompatibilityKHR

  - renamed `VkAccelerationStructureVersionKHR` to VkAccelerationStructureVersionInfoKHR

  - renamed `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_KHR` to `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_VERSION_INFO_KHR`

  - removed `VK_ERROR_INCOMPATIBLE_VERSION_KHR`

  - added VkAccelerationStructureCompatibilityKHR enum

  - remove return value from vkGetDeviceAccelerationStructureCompatibilityKHR and added return enum parameter

- Require Vulkan 1.1

- added creation time capture and replay flags

  - added VkAccelerationStructureCreateFlagBitsKHR and VkAccelerationStructureCreateFlagsKHR

  - renamed the `flags` member of VkAccelerationStructureCreateInfoKHR to `buildFlags` (later removed) and added the `createFlags` member

- change vkCmdBuildAccelerationStructuresIndirectKHR to use buffer device address for indirect parameter

- make `VK_KHR_deferred_host_operations` an interaction instead of a required extension (later went back on this)

- renamed `VkAccelerationStructureBuildOffsetInfoKHR` to VkAccelerationStructureBuildRangeInfoKHR

  - renamed the `ppOffsetInfos` parameter of vkCmdBuildAccelerationStructuresKHR to `ppBuildRangeInfos`

- Re-unify geometry description between build and create

  - remove `VkAccelerationStructureCreateGeometryTypeInfoKHR` and `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_GEOMETRY_TYPE_INFO_KHR`

  - added `VkAccelerationStructureCreateSizeInfoKHR` structure (later removed)

  - change type of the `pGeometryInfos` member of VkAccelerationStructureCreateInfoKHR from `VkAccelerationStructureCreateGeometryTypeInfoKHR` to VkAccelerationStructureGeometryKHR (later removed)

  - added `pCreateSizeInfos` member to VkAccelerationStructureCreateInfoKHR (later removed)

- Fix ppGeometries ambiguity, add pGeometries

  - remove `geometryArrayOfPointers` member of VkAccelerationStructureBuildGeometryInfoKHR

  - disambiguate two meanings of `ppGeometries` by explicitly adding `pGeometries` to the VkAccelerationStructureBuildGeometryInfoKHR structure and require one of them be `NULL`

- added `nullDescriptor` support for acceleration structures

- changed the `update` member of VkAccelerationStructureBuildGeometryInfoKHR from a bool to the `mode` VkBuildAccelerationStructureModeKHR enum which allows future extensibility in update types

- Clarify deferred host ops for pipeline creation

  - VkDeferredOperationKHR is now a top-level parameter for vkBuildAccelerationStructuresKHR, vkCreateRayTracingPipelinesKHR, vkCopyAccelerationStructureToMemoryKHR, vkCopyAccelerationStructureKHR, and vkCopyMemoryToAccelerationStructureKHR

  - removed `VkDeferredOperationInfoKHR` structure

  - change deferred host creation/return parameter behavior such that the implementation can modify such parameters until the deferred host operation completes

  - `VK_KHR_deferred_host_operations` is required again

- Change acceleration structure build to always be sized

  - de-alias `VkAccelerationStructureMemoryRequirementsTypeNV` and `VkAccelerationStructureMemoryRequirementsTypeKHR`, and remove `VkAccelerationStructureMemoryRequirementsTypeKHR`

  - add vkGetAccelerationStructureBuildSizesKHR command and VkAccelerationStructureBuildSizesInfoKHR structure and `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_BUILD_SIZES_INFO_KHR` enum to query sizes for acceleration structures and scratch storage

  - move size queries for scratch space to vkGetAccelerationStructureBuildSizesKHR

  - remove `compactedSize`, `buildFlags`, `maxGeometryCount`, `pGeometryInfos`, `pCreateSizeInfos` members of VkAccelerationStructureCreateInfoKHR and add the `size` member

  - add `maxVertex` member to VkAccelerationStructureGeometryTrianglesDataKHR structure

  - remove `VkAccelerationStructureCreateSizeInfoKHR` structure

(4) What are the changes between the internal provisional (VK_KHR_ray_tracing v9) release and the final (VK_KHR_acceleration_structure v11) release?

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

  - `VK_KHR_acceleration_structure` (for acceleration structure operations)

  - `VK_KHR_ray_tracing_pipeline` (for ray tracing pipeline and shader stages)

  - `VK_KHR_ray_query` (for ray queries in existing shader stages)

- clarify buffer usage flags for ray tracing

  - `VK_BUFFER_USAGE_RAY_TRACING_BIT_NV` is left alone in `VK_NV_ray_tracing` (required on `scratch` and `instanceData`)

  - `VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR` is added as an alias of `VK_BUFFER_USAGE_RAY_TRACING_BIT_NV` in `VK_KHR_ray_tracing_pipeline` and is required on shader binding table buffers

  - `VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_BUILD_INPUT_READ_ONLY_BIT_KHR` is added in `VK_KHR_acceleration_structure` for all vertex, index, transform, aabb, and instance buffer data referenced by device build commands

  - `VK_BUFFER_USAGE_STORAGE_BUFFER_BIT` is used for `scratchData`

- add max primitive counts (`ppMaxPrimitiveCounts`) to vkCmdBuildAccelerationStructuresIndirectKHR

- Allocate acceleration structures from `VkBuffers` and add a mode to constrain the device address

  - de-alias `VkBindAccelerationStructureMemoryInfoNV` and `vkBindAccelerationStructureMemoryNV`, and remove `VkBindAccelerationStructureMemoryInfoKHR`, `VkAccelerationStructureMemoryRequirementsInfoKHR`, and `vkGetAccelerationStructureMemoryRequirementsKHR`

  - acceleration structures now take a VkBuffer and offset at creation time for memory placement

  - add a new `VK_BUFFER_USAGE_ACCELERATION_STRUCTURE_STORAGE_BIT_KHR` buffer usage for such buffers

  - add a new `VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR` acceleration structure type for layering

- move `VK_GEOMETRY_TYPE_INSTANCES_KHR` to main enum instead of being added via extension

- make build commands more consistent - all now build multiple acceleration structures and are named plurally (vkCmdBuildAccelerationStructuresIndirectKHR, vkCmdBuildAccelerationStructuresKHR, vkBuildAccelerationStructuresKHR)

- add interactions with `VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT` for acceleration structures, including a new feature (`descriptorBindingAccelerationStructureUpdateAfterBind`) and 3 new properties (`maxPerStageDescriptorAccelerationStructures`, `maxPerStageDescriptorUpdateAfterBindAccelerationStructures`, `maxDescriptorSetUpdateAfterBindAccelerationStructures`)

- extension is no longer provisional

- define synchronization requirements for builds, traces, and copies

- define synchronization requirements for AS build inputs and indirect build buffer

(5) What is `VK_ACCELERATION_STRUCTURE_TYPE_GENERIC_KHR` for?

RESOLVED: It is primarily intended for API layering. In DXR, the acceleration structure is basically just a buffer in a special layout, and you do not know at creation time whether it will be used as a top or bottom level acceleration structure. We thus added a generic acceleration structure type whose type is unknown at creation time, but is specified at build time instead. Applications which are written directly for Vulkan should not use it.

#### Version History

- Revision 1, 2019-12-05 (Members of the Vulkan Ray Tracing TSG)

  - Internal revisions (forked from VK_NV_ray_tracing)

- Revision 2, 2019-12-20 (Daniel Koch, Eric Werness)

  - Add const version of DeviceOrHostAddress (!3515)

  - Add VU to clarify that only handles in the current pipeline are valid (!3518)

  - Restore some missing VUs and add in-place update language (#1902, !3522)

  - rename VkAccelerationStructureInstanceKHR member from accelerationStructure to accelerationStructureReference to better match its type (!3523)

  - Allow VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS for pipeline creation if shader group handles cannot be reused (!3523)

  - update documentation for the VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS error code and add missing documentation for new return codes from VK_KHR_deferred_host_operations (!3523)

  - list new query types for VK_KHR_ray_tracing (!3523)

  - Fix VU statements for VkAccelerationStructureGeometryKHR referring to correct union members and update to use more current wording (!3523)

- Revision 3, 2020-01-10 (Daniel Koch, Jon Leech, Christoph Kubisch)

  - Fix 'instance of' and 'that/which contains/defines' markup issues (!3528)

  - factor out VK_KHR_pipeline_library as stand-alone extension (!3540)

  - Resolve Vulkan-hpp issues (!3543)

    - add missing require for VkGeometryInstanceFlagsKHR

    - de-alias VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_CREATE_INFO_NV since the KHR structure is no longer equivalent

    - add len to pDataSize attribute for vkWriteAccelerationStructuresPropertiesKHR

- Revision 4, 2020-01-23 (Daniel Koch, Eric Werness)

  - Improve vkWriteAccelerationStructuresPropertiesKHR, add return value and VUs (#1947)

  - Clarify language to allow multiple raygen shaders (#1959)

  - Various editorial feedback (!3556)

  - Add language to help deal with looped self-intersecting fans (#1901)

  - Change vkCmdTraceRays{,Indirect}KHR args to pointers (!3559)

  - Add scratch address validation language (#1941, !3551)

  - Fix definition and add hierarchy information for shader call scope (#1977, !3571)

- Revision 5, 2020-02-04 (Eric Werness, Jeff Bolz, Daniel Koch)

  - remove vestigial accelerationStructureUUID (!3582)

  - update definition of repack instructions and improve memory model interactions (#1910, #1913, !3584)

  - Fix wrong sType for VkPhysicalDeviceRayTracingFeaturesKHR (#1988)

  - Use provisional SPIR-V capabilities (#1987)

  - require rayTraversalPrimitiveCulling if rayQuery is supported (#1927)

  - Miss shaders do not have object parameters (!3592)

  - Fix missing required types in XML (!3592)

  - clarify matching conditions for update (!3592)

  - add goal that host and device builds be similar (!3592)

  - clarify that `maxPrimitiveCount` limit should apply to triangles and AABBs (!3592)

  - Require alignment for instance arrayOfPointers (!3592)

  - Zero is a valid value for instance flags (!3592)

  - Add some alignment VUs that got lost in refactoring (!3592)

  - Recommend TMin epsilon rather than culling (!3592)

  - Get angle from dot product not cross product (!3592)

  - Clarify that AH can access the payload and attributes (!3592)

  - Match DXR behavior for inactive primitive definition (!3592)

  - Use a more generic term than degenerate for inactive to avoid confusion (!3592)

- Revision 6, 2020-02-20 (Daniel Koch)

  - fix some dangling NV references (#1996)

  - rename VkCmdTraceRaysIndirectCommandKHR to VkTraceRaysIndirectCommandKHR (!3607)

  - update contributor list (!3611)

  - use uint64_t instead of VkAccelerationStructureReferenceKHR in VkAccelerationStructureInstanceKHR (#2004)

- Revision 7, 2020-02-28 (Tobias Hector)

  - remove HitTKHR SPIR-V builtin (spirv/spirv-extensions#7)

- Revision 8, 2020-03-06 (Tobias Hector, Dae Kim, Daniel Koch, Jeff Bolz, Eric Werness)

  - explicitly state that Tmax is updated when new closest intersection is accepted (#2020,!3536)

  - Made references to min and max t values consistent (!3644)

  - finish enumerating differences relative to VK_NV_ray_tracing in issues (1) and (2) (#1974,!3642)

  - fix formatting in some math equations (!3642)

  - Restrict the Hit Kind operand of `OpReportIntersectionKHR` to 7-bits (spirv/spirv-extensions#8,!3646)

  - Say ray tracing 'should' be watertight (#2008,!3631)

  - Clarify memory requirements for ray tracing buffers (#2005,!3649)

  - Add callable size limits (#1997,!3652)

- Revision 9, 2020-04-15 (Eric Werness, Daniel Koch, Tobias Hector, Joshua Barczak)

  - Add geometry flags to acceleration structure creation (!3672)

  - add build scratch memory alignment (minAccelerationStructureScratchOffsetAlignment) (#2065,!3725)

  - fix naming and return enum from vkGetDeviceAccelerationStructureCompatibilityKHR (#2051,!3726)

  - require SPIR-V 1.4 (#2096,!3777)

  - added creation time capture/replay flags (#2104,!3774)

  - require Vulkan 1.1 (#2133,!3806)

  - use device addresses instead of VkBuffers for ray tracing commands (#2074,!3815)

  - add interactions with Vulkan 1.2 and VK_KHR_vulkan_memory_model (#2133,!3830)

  - make VK_KHR_pipeline_library an interaction instead of required (#2045,#2108,!3830)

  - make VK_KHR_deferred_host_operations an interaction instead of required (#2045,!3830)

  - removed maxCallableSize and added explicit stack size management for ray pipelines (#1997,!3817,!3772,!3844)

  - improved documentation for VkAccelerationStructureVersionInfoKHR (#2135,3835)

  - rename VkAccelerationStructureBuildOffsetInfoKHR to VkAccelerationStructureBuildRangeInfoKHR (#2058,!3754)

  - Re-unify geometry description between build and create (!3754)

  - Fix ppGeometries ambiguity, add pGeometries (#2032,!3811)

  - add interactions with VK_EXT_robustness2 and allow nullDescriptor support for acceleration structures (#1920,!3848)

  - added future extensibility for AS updates (#2114,!3849)

  - Fix VU for dispatchrays and add a limit on the size of the full grid (#2160,!3851)

  - Add shaderGroupHandleAlignment property (#2180,!3875)

  - Clarify deferred host ops for pipeline creation (#2067,!3813)

  - Change acceleration structure build to always be sized (#2131,#2197,#2198,!3854,!3883,!3880)

- Revision 10, 2020-07-03 (Mathieu Robart, Daniel Koch, Eric Werness, Tobias Hector)

  - Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_acceleration_structure (#1918,!3912)

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

  - add max primitive counts to build indirect command (#2233,!3944)

  - Allocate acceleration structures from VkBuffers and add a mode to constrain the device address (#2131,!3936)

  - Move VK_GEOMETRY_TYPE_INSTANCES_KHR to main enum (#2243,!3952)

  - make build commands more consistent (#2247,!3958)

  - add interactions with UPDATE_AFTER_BIND (#2128,!3986)

  - correct and expand build command VUs (!4020)

  - fix copy command VUs (!4018)

  - added various alignment requirements (#2229,!3943)

  - fix valid usage for arrays of geometryCount items (#2198,!4010)

  - define what is allowed to change on RTAS updates and relevant VUs (#2177,!3961)

- Revision 11, 2020-11-12 (Eric Werness, Josh Barczak, Daniel Koch, Tobias Hector)

  - de-alias NV and KHR acceleration structure types and associated commands (#2271,!4035)

  - specify alignment for host copy commands (#2273,!4037)

  - document `VK_FORMAT_FEATURE_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR`

  - specify that acceleration structures are non-linear (#2289,!4068)

  - add several missing VUs for strides, vertexFormat, and indexType (#2315,!4069)

  - restore VUs for VkAccelerationStructureBuildGeometryInfoKHR (#2337,!4098)

  - ban multi-instance memory for host operations (#2324,!4102)

  - allow dstAccelerationStructure to be null for vkGetAccelerationStructureBuildSizesKHR (#2330,!4111)

  - more build VU cleanup (#2138,#4130)

  - specify host endianness for AS serialization (#2261,!4136)

  - add invertible transform matrix VU (#1710,!4140)

  - require geometryCount to be 1 for TLAS builds (!4145)

  - improved validity conditions for build addresses (#4142)

  - add single statement SPIR-V VUs, build limit VUs (!4158)

  - document limits for vertex and aabb strides (#2390,!4184)

  - specify that `VK_PIPELINE_STAGE_ACCELERATION_STRUCTURE_BUILD_BIT_KHR` applies to AS copies (#2382,#4173)

  - define sync for AS build inputs and indirect buffer (#2407,!4208)

- Revision 12, 2021-08-06 (Samuel Bourasseau)

  - rename VK_GEOMETRY_INSTANCE_TRIANGLE_FRONT_COUNTERCLOCKWISE_BIT_KHR to VK_GEOMETRY_INSTANCE_TRIANGLE_FLIP_FACING_BIT_KHR (keep previous as alias).

  - Clarify description and add note.

- Revision 13, 2021-09-30 (Jon Leech)

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

#### VK_KHR_android_surface

Name String

  `VK_KHR_android_surface`

Extension Type

  Instance extension

Registered Extension Number

  9

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2016-01-14

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Jason Ekstrand, Intel

  - Ian Elliott, LunarG

  - Courtney Goeltzenleuchter, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Antoine Labour, Google

  - Jon Leech, Khronos

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Ray Smith, ARM

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

#### Description

The `VK_KHR_android_surface` extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the `VK_KHR_surface` extension) that refers to an `ANativeWindow`, Android’s native surface type. The `ANativeWindow` represents the producer endpoint of any buffer queue, regardless of consumer endpoint. Common consumer endpoints for `ANativeWindows` are the system window compositor, video encoders, and application-specific compositors importing the images through a `SurfaceTexture`.

#### New Base Types

- `ANativeWindow`

#### New Commands

- vkCreateAndroidSurfaceKHR

#### New Structures

- VkAndroidSurfaceCreateInfoKHR

#### New Bitmasks

- VkAndroidSurfaceCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_ANDROID_SURFACE_EXTENSION_NAME`

- `VK_KHR_ANDROID_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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

#### Version History

- Revision 1, 2015-09-23 (Jesse Hall)

  - Initial draft.

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

  - Renamed from VK_EXT_KHR_android_surface to VK_KHR_android_surface.

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

  - Added allocation callbacks to surface creation function.

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

  - Removed VK_ERROR_INVALID_ANDROID_WINDOW_KHR.

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

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

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

  - Moved VK_ERROR_NATIVE_WINDOW_IN_USE_KHR from the VK_KHR_android_surface to the VK_KHR_surface extension.

#### VK_KHR_deferred_host_operations

Name String

  `VK_KHR_deferred_host_operations`

Extension Type

  Device extension

Registered Extension Number

  269

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Josh Barczak jbarczak

#### Other Extension Metadata

Last Modified Date

  2020-11-12

IP Status

  No known IP claims.

Contributors

  - Joshua Barczak, Intel

  - Jeff Bolz, NVIDIA

  - Daniel Koch, NVIDIA

  - Slawek Grajewski, Intel

  - Tobias Hector, AMD

  - Yuriy O’Donnell, Epic

  - Eric Werness, NVIDIA

  - Baldur Karlsson, Valve

  - Jesse Barker, Unity

  - Contributors to VK_KHR_acceleration_structure, VK_KHR_ray_tracing_pipeline

#### Description

The `VK_KHR_deferred_host_operations` extension defines the infrastructure and usage patterns for deferrable commands, but does not specify any commands as deferrable. This is left to additional dependent extensions. Commands must not be deferred unless the deferral is specifically allowed by another extension which depends on `VK_KHR_deferred_host_operations`.

#### New Object Types

- VkDeferredOperationKHR

#### New Commands

- vkCreateDeferredOperationKHR

- vkDeferredOperationJoinKHR

- vkDestroyDeferredOperationKHR

- vkGetDeferredOperationMaxConcurrencyKHR

- vkGetDeferredOperationResultKHR

#### New Enum Constants

- `VK_KHR_DEFERRED_HOST_OPERATIONS_EXTENSION_NAME`

- `VK_KHR_DEFERRED_HOST_OPERATIONS_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_DEFERRED_OPERATION_KHR`

- Extending VkResult:

  - `VK_OPERATION_DEFERRED_KHR`

  - `VK_OPERATION_NOT_DEFERRED_KHR`

  - `VK_THREAD_DONE_KHR`

  - `VK_THREAD_IDLE_KHR`

#### Code Examples

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

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

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

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

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

            result = vkGetDeferredOperationResultKHR(device, hOp);

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

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

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

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

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

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

    std::vector<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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - James Jones cubanismo

  - Norbert Nopper FslNopper

#### Other Extension Metadata

Last Modified Date

  2017-03-13

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Norbert Nopper, Freescale

  - Jeff Vigil, Qualcomm

  - Daniel Rakos, AMD

#### Description

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

#### New Object Types

- VkDisplayKHR

- VkDisplayModeKHR

#### New Commands

- vkCreateDisplayModeKHR

- vkCreateDisplayPlaneSurfaceKHR

- vkGetDisplayModePropertiesKHR

- vkGetDisplayPlaneCapabilitiesKHR

- vkGetDisplayPlaneSupportedDisplaysKHR

- vkGetPhysicalDeviceDisplayPlanePropertiesKHR

- vkGetPhysicalDeviceDisplayPropertiesKHR

#### New Structures

- VkDisplayModeCreateInfoKHR

- VkDisplayModeParametersKHR

- VkDisplayModePropertiesKHR

- VkDisplayPlaneCapabilitiesKHR

- VkDisplayPlanePropertiesKHR

- VkDisplayPropertiesKHR

- VkDisplaySurfaceCreateInfoKHR

#### New Enums

- VkDisplayPlaneAlphaFlagBitsKHR

#### New Bitmasks

- VkDisplayModeCreateFlagsKHR

- VkDisplayPlaneAlphaFlagsKHR

- VkDisplaySurfaceCreateFlagsKHR

- VkSurfaceTransformFlagsKHR

#### New Enum Constants

- `VK_KHR_DISPLAY_EXTENSION_NAME`

- `VK_KHR_DISPLAY_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_DISPLAY_KHR`

  - `VK_OBJECT_TYPE_DISPLAY_MODE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DISPLAY_MODE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DISPLAY_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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.

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_display` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2017-03-13

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Jeff Vigil, Qualcomm

  - Jesse Hall, Google

#### Description

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

#### New Commands

- vkCreateSharedSwapchainsKHR

#### New Structures

- Extending VkPresentInfoKHR:

  - VkDisplayPresentInfoKHR

#### New Enum Constants

- `VK_KHR_DISPLAY_SWAPCHAIN_EXTENSION_NAME`

- `VK_KHR_DISPLAY_SWAPCHAIN_SPEC_VERSION`

- Extending VkResult:

  - `VK_ERROR_INCOMPATIBLE_DISPLAY_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DISPLAY_PRESENT_INFO_KHR`

#### Issues

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

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

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

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

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

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

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

RESOLVED: By calling vkCreateSharedSwapchainsKHR.

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

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

#### 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 swap chains 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_fence` to be enabled for any device-level functionality

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2017-05-08

IP Status

  No known IP claims.

Contributors

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Cass Everitt, Oculus

  - Contributors to `VK_KHR_external_semaphore_fd`

#### Description

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

#### New Commands

- vkGetFenceFdKHR

- vkImportFenceFdKHR

#### New Structures

- VkFenceGetFdInfoKHR

- VkImportFenceFdInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_FENCE_FD_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_FENCE_FD_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FENCE_GET_FD_INFO_KHR`

  - `VK_STRUCTURE_TYPE_IMPORT_FENCE_FD_INFO_KHR`

#### Issues

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

#### Version History

- Revision 1, 2017-05-08 (Jesse Hall)

  - Initial revision

#### VK_KHR_external_fence_win32

Name String

  `VK_KHR_external_fence_win32`

Extension Type

  Device extension

Registered Extension Number

  115

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_fence` to be enabled for any device-level functionality

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2017-05-08

IP Status

  No known IP claims.

Contributors

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Cass Everitt, Oculus

  - Contributors to `VK_KHR_external_semaphore_win32`

#### Description

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

#### New Commands

- vkGetFenceWin32HandleKHR

- vkImportFenceWin32HandleKHR

#### New Structures

- VkFenceGetWin32HandleInfoKHR

- VkImportFenceWin32HandleInfoKHR

- Extending VkFenceCreateInfo:

  - VkExportFenceWin32HandleInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_FENCE_WIN32_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_FENCE_WIN32_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_FENCE_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_FENCE_GET_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_IMPORT_FENCE_WIN32_HANDLE_INFO_KHR`

#### Issues

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

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

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

#### Version History

- Revision 1, 2017-05-08 (Jesse Hall)

  - Initial revision

#### VK_KHR_external_memory_fd

Name String

  `VK_KHR_external_memory_fd`

Extension Type

  Device extension

Registered Extension Number

  75

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

#### Description

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

#### New Commands

- vkGetMemoryFdKHR

- vkGetMemoryFdPropertiesKHR

#### New Structures

- VkMemoryFdPropertiesKHR

- VkMemoryGetFdInfoKHR

- Extending VkMemoryAllocateInfo:

  - VkImportMemoryFdInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_MEMORY_FD_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_MEMORY_FD_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMPORT_MEMORY_FD_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_FD_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_GET_FD_INFO_KHR`

#### Issues

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

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

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

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

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

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

#### Version History

- Revision 1, 2016-10-21 (James Jones)

  - Initial revision

#### VK_KHR_external_memory_win32

Name String

  `VK_KHR_external_memory_win32`

Extension Type

  Device extension

Registered Extension Number

  74

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

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

#### New Commands

- vkGetMemoryWin32HandleKHR

- vkGetMemoryWin32HandlePropertiesKHR

#### New Structures

- VkMemoryGetWin32HandleInfoKHR

- VkMemoryWin32HandlePropertiesKHR

- Extending VkMemoryAllocateInfo:

  - VkExportMemoryWin32HandleInfoKHR

  - VkImportMemoryWin32HandleInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_MEMORY_WIN32_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_GET_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR`

#### Issues

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

| 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_semaphore` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Contributors

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

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

#### New Commands

- vkGetSemaphoreFdKHR

- vkImportSemaphoreFdKHR

#### New Structures

- VkImportSemaphoreFdInfoKHR

- VkSemaphoreGetFdInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_SEMAPHORE_FD_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_GET_FD_INFO_KHR`

#### Issues

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

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

#### Version History

- Revision 1, 2016-10-21 (Jesse Hall)

  - Initial revision

#### VK_KHR_external_semaphore_win32

Name String

  `VK_KHR_external_semaphore_win32`

Extension Type

  Device extension

Registered Extension Number

  79

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_semaphore` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

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

#### New Commands

- vkGetSemaphoreWin32HandleKHR

- vkImportSemaphoreWin32HandleKHR

#### New Structures

- VkImportSemaphoreWin32HandleInfoKHR

- VkSemaphoreGetWin32HandleInfoKHR

- Extending VkSemaphoreCreateInfo:

  - VkExportSemaphoreWin32HandleInfoKHR

- Extending VkSubmitInfo:

  - VkD3D12FenceSubmitInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_SEMAPHORE_WIN32_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_D3D12_FENCE_SUBMIT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_WIN32_HANDLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_GET_WIN32_HANDLE_INFO_KHR`

#### Issues

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

RESOLVED: Yes, 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Stu Smith

Extension Proposal

  VK_KHR_fragment_shader_barycentric

#### Other Extension Metadata

Last Modified Date

  2022-03-10

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_fragment_shader_barycentric`

  - This extension provides API support for `GL_EXT_fragment_shader_barycentric`

Contributors

  - Stu Smith, AMD

  - Tobias Hector, AMD

  - Graeme Leese, Broadcom

  - Jan-Harald Fredriksen, Arm

  - Slawek Grajewski, Intel

  - Pat Brown, NVIDIA

  - Hans-Kristian Arntzen, Valve

  - Contributors to the VK_NV_fragment_shader_barycentric specification

#### Description

This extension is based on the `VK_NV_fragment_shader_barycentric` extension, and adds support for the following SPIR-V extension in Vulkan:

- `SPV_KHR_fragment_shader_barycentric`

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

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

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

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

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

- `in vec3 gl_BaryCoordEXT;` → `BaryCoordKHR`

- `in vec3 gl_BaryCoordNoPerspEXT;` → `BaryCoordNoPerspKHR`

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShaderBarycentricFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentShaderBarycentricPropertiesKHR

#### New Enum Constants

- `VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME`

- `VK_KHR_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_PROPERTIES_KHR`

#### New Built-In Variables

- `BaryCoordKHR`

- `BaryCoordNoPerspKHR`

#### New SPIR-V Decorations

- `PerVertexKHR`

#### New SPIR-V Capabilities

- `FragmentBarycentricKHR`

#### Issues

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

RESOLVED: The inputs decorated with `BaryCoordKHR` or `BaryCoordNoPerspKHR` may also be decorated with the `Centroid` or `Sample` qualifiers to specify interpolation, like any other fragment shader input. If `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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_create_renderpass2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Tobias Hector tobski

Extension Proposal

  VK_KHR_fragment_shading_rate

#### Other Extension Metadata

Last Modified Date

  2021-09-30

Interactions and External Dependencies

  - This extension requires `SPV_KHR_fragment_shading_rate`.

  - This extension provides API support for `GL_EXT_fragment_shading_rate`

Contributors

  - Tobias Hector, AMD

  - Guennadi Riguer, AMD

  - Matthaeus Chajdas, AMD

  - Pat Brown, Nvidia

  - Matthew Netsch, Qualcomm

  - Slawomir Grajewski, Intel

  - Jan-Harald Fredriksen, Arm

  - Jeff Bolz, Nvidia

  - Arseny Kapoulkine, Roblox

  - Contributors to the VK_NV_shading_rate_image specification

  - Contributors to the VK_EXT_fragment_density_map specification

#### Description

This extension adds the ability to change the rate at which fragments are shaded. Rather than the usual single fragment invocation for each pixel covered by a primitive, multiple pixels can be shaded by a single fragment shader invocation.

Up to three methods are available to the application to change the fragment shading rate:

- Pipeline Fragment Shading Rate, which allows the specification of a rate per-draw.

- Primitive Fragment Shading Rate, which allows the specification of a rate per primitive, specified during shading.

- Attachment Fragment Shading Rate, which allows the specification of a rate per-region of the framebuffer, specified in a specialized image attachment.

Additionally, these rates can all be specified and combined in order to adjust the overall detail in the image at each point.

This functionality can be used to focus shading efforts where higher levels of detail are needed in some parts of a scene compared to others. This can be particularly useful in high resolution rendering, or for XR contexts.

This extension also adds support for the `SPV_KHR_fragment_shading_rate` extension which enables setting the primitive fragment shading rate, and allows querying the final shading rate from a fragment shader.

#### New Commands

- vkCmdSetFragmentShadingRateKHR

- vkGetPhysicalDeviceFragmentShadingRatesKHR

#### New Structures

- VkPhysicalDeviceFragmentShadingRateKHR

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineFragmentShadingRateStateCreateInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShadingRateFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentShadingRatePropertiesKHR

- Extending VkSubpassDescription2:

  - VkFragmentShadingRateAttachmentInfoKHR

#### New Enums

- VkFragmentShadingRateCombinerOpKHR

#### New Enum Constants

- `VK_KHR_FRAGMENT_SHADING_RATE_EXTENSION_NAME`

- `VK_KHR_FRAGMENT_SHADING_RATE_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_FRAGMENT_SHADING_RATE_KHR`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_FRAGMENT_SHADING_RATE_ATTACHMENT_OPTIMAL_KHR`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FRAGMENT_SHADING_RATE_ATTACHMENT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_STATE_CREATE_INFO_KHR`

If VK_KHR_format_feature_flags2 is supported:

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR`

#### Version History

- Revision 1, 2020-05-06 (Tobias Hector)

  - Initial revision

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

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

#### VK_KHR_get_display_properties2

Name String

  `VK_KHR_get_display_properties2`

Extension Type

  Instance extension

Registered Extension Number

  122

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_display` to be enabled

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2017-02-21

IP Status

  No known IP claims.

Contributors

  - Ian Elliott, Google

  - James Jones, NVIDIA

#### Description

This extension provides new entry points to query device display properties and capabilities in a way that can be easily extended by other extensions, without introducing any further entry points. This extension can be considered the `VK_KHR_display` equivalent of the `VK_KHR_get_physical_device_properties2` extension.

#### New Commands

- vkGetDisplayModeProperties2KHR

- vkGetDisplayPlaneCapabilities2KHR

- vkGetPhysicalDeviceDisplayPlaneProperties2KHR

- vkGetPhysicalDeviceDisplayProperties2KHR

#### New Structures

- VkDisplayModeProperties2KHR

- VkDisplayPlaneCapabilities2KHR

- VkDisplayPlaneInfo2KHR

- VkDisplayPlaneProperties2KHR

- VkDisplayProperties2KHR

#### New Enum Constants

- `VK_KHR_GET_DISPLAY_PROPERTIES_2_EXTENSION_NAME`

- `VK_KHR_GET_DISPLAY_PROPERTIES_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DISPLAY_MODE_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_DISPLAY_PLANE_CAPABILITIES_2_KHR`

  - `VK_STRUCTURE_TYPE_DISPLAY_PLANE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_DISPLAY_PLANE_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_DISPLAY_PROPERTIES_2_KHR`

#### Issues

1) What should this extension be named?

RESOLVED: `VK_KHR_get_display_properties2`. Other alternatives:

- `VK_KHR_display2`

- One extension, combined with `VK_KHR_surface_capabilites2`.

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

RESOLVED:

- vkGetPhysicalDeviceDisplayProperties2KHR: No. The only current input is a VkPhysicalDevice. Other inputs would not make sense.

- vkGetPhysicalDeviceDisplayPlaneProperties2KHR: No. The only current input is a VkPhysicalDevice. Other inputs would not make sense.

- vkGetDisplayModeProperties2KHR: No. The only current inputs are a VkPhysicalDevice and a VkDisplayModeKHR. Other inputs would not make sense.

3) Should additional display query functions be extended?

RESOLVED:

- vkGetDisplayPlaneSupportedDisplaysKHR: No. Extensions should instead extend vkGetDisplayPlaneCapabilitiesKHR().

#### Version History

- Revision 1, 2017-02-21 (James Jones)

  - Initial draft.

#### VK_KHR_get_surface_capabilities2

Name String

  `VK_KHR_get_surface_capabilities2`

Extension Type

  Instance extension

Registered Extension Number

  120

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2017-02-27

IP Status

  No known IP claims.

Contributors

  - Ian Elliott, Google

  - James Jones, NVIDIA

  - Alon Or-bach, Samsung

#### Description

This extension provides new entry points to query device surface capabilities in a way that can be easily extended by other extensions, without introducing any further entry points. This extension can be considered the `VK_KHR_surface` equivalent of the `VK_KHR_get_physical_device_properties2` extension.

#### New Commands

- vkGetPhysicalDeviceSurfaceCapabilities2KHR

- vkGetPhysicalDeviceSurfaceFormats2KHR

#### New Structures

- VkPhysicalDeviceSurfaceInfo2KHR

- VkSurfaceCapabilities2KHR

- VkSurfaceFormat2KHR

#### New Enum Constants

- `VK_KHR_GET_SURFACE_CAPABILITIES_2_EXTENSION_NAME`

- `VK_KHR_GET_SURFACE_CAPABILITIES_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SURFACE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_KHR`

  - `VK_STRUCTURE_TYPE_SURFACE_FORMAT_2_KHR`

#### Issues

1) What should this extension be named?

RESOLVED: `VK_KHR_get_surface_capabilities2`. Other alternatives:

- `VK_KHR_surface2`

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

2) Should additional WSI query functions be extended?

RESOLVED:

- vkGetPhysicalDeviceSurfaceCapabilitiesKHR: Yes. The need for this motivated the extension.

- vkGetPhysicalDeviceSurfaceSupportKHR: No. Currently only has boolean output. Extensions should instead extend vkGetPhysicalDeviceSurfaceCapabilities2KHR.

- vkGetPhysicalDeviceSurfaceFormatsKHR: Yes.

- vkGetPhysicalDeviceSurfacePresentModesKHR: No. Recent discussion concluded this introduced too much variability for applications to deal with. Extensions should instead extend vkGetPhysicalDeviceSurfaceCapabilities2KHR.

- vkGetPhysicalDeviceXlibPresentationSupportKHR: Not in this extension.

- vkGetPhysicalDeviceXcbPresentationSupportKHR: Not in this extension.

- vkGetPhysicalDeviceWaylandPresentationSupportKHR: Not in this extension.

- vkGetPhysicalDeviceWin32PresentationSupportKHR: Not in this extension.

#### Version History

- Revision 1, 2017-02-27 (James Jones)

  - Initial draft.

#### VK_KHR_global_priority

Name String

  `VK_KHR_global_priority`

Extension Type

  Device extension

Registered Extension Number

  189

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2021-10-22

Contributors

  - Tobias Hector, AMD

  - Contributors to `VK_EXT_global_priority`

  - Contributors to `VK_EXT_global_priority_query`

#### Description

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

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

The driver implementation will attempt to skew hardware resource allocation in 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 Structures

- Extending VkDeviceQueueCreateInfo:

  - VkDeviceQueueGlobalPriorityCreateInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceGlobalPriorityQueryFeaturesKHR

- Extending VkQueueFamilyProperties2:

  - VkQueueFamilyGlobalPriorityPropertiesKHR

#### New Enums

- VkQueueGlobalPriorityKHR

#### New Enum Constants

- `VK_KHR_GLOBAL_PRIORITY_EXTENSION_NAME`

- `VK_KHR_GLOBAL_PRIORITY_SPEC_VERSION`

- `VK_MAX_GLOBAL_PRIORITY_SIZE_KHR`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2016-11-02

IP Status

  No known IP claims.

Contributors

  - Ian Elliott, Google

  - Jesse Hall, Google

  - Alon Or-bach, Samsung

  - James Jones, NVIDIA

  - Daniel Rakos, AMD

  - Ray Smith, ARM

  - Mika Isojarvi, Google

  - Jeff Juliano, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

This extension is leveraged from the `EGL_KHR_swap_buffers_with_damage` extension.

#### New Structures

- VkPresentRegionKHR

- VkRectLayerKHR

- Extending VkPresentInfoKHR:

  - VkPresentRegionsKHR

#### New Enum Constants

- `VK_KHR_INCREMENTAL_PRESENT_EXTENSION_NAME`

- `VK_KHR_INCREMENTAL_PRESENT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PRESENT_REGIONS_KHR`

#### Issues

1) How should we handle steroescopic-3D swapchains? We need to add a layer for each rectangle. One approach is to create another 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - Developer tools

Contact

  - Alon Or-bach alonorbach

#### Other Extension Metadata

Last Modified Date

  2019-10-08

IP Status

  No known IP claims.

Contributors

  - Jesse Barker, Unity Technologies

  - Kenneth Benzie, Codeplay

  - Jan-Harald Fredriksen, ARM

  - Jeff Leger, Qualcomm

  - Jesse Hall, Google

  - Tobias Hector, AMD

  - Neil Henning, Codeplay

  - Baldur Karlsson

  - Lionel Landwerlin, Intel

  - Peter Lohrmann, AMD

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Niklas Smedberg, Unity Technologies

  - Igor Ostrowski, Intel

#### Description

The `VK_KHR_performance_query` extension adds a mechanism to allow querying of performance counters for use in applications and by profiling tools.

Each queue family may expose counters that can be enabled on a queue of that family. We extend VkQueryType to add a new query type for performance queries, and chain a structure on VkQueryPoolCreateInfo to specify the performance queries to enable.

#### New Commands

- vkAcquireProfilingLockKHR

- vkEnumeratePhysicalDeviceQueueFamilyPerformanceQueryCountersKHR

- vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR

- vkReleaseProfilingLockKHR

#### New Structures

- VkAcquireProfilingLockInfoKHR

- VkPerformanceCounterDescriptionKHR

- VkPerformanceCounterKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePerformanceQueryFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePerformanceQueryPropertiesKHR

- Extending VkQueryPoolCreateInfo:

  - VkQueryPoolPerformanceCreateInfoKHR

- Extending VkSubmitInfo, VkSubmitInfo2:

  - VkPerformanceQuerySubmitInfoKHR

#### New Unions

- VkPerformanceCounterResultKHR

#### New Enums

- VkAcquireProfilingLockFlagBitsKHR

- VkPerformanceCounterDescriptionFlagBitsKHR

- VkPerformanceCounterScopeKHR

- VkPerformanceCounterStorageKHR

- VkPerformanceCounterUnitKHR

#### New Bitmasks

- VkAcquireProfilingLockFlagsKHR

- VkPerformanceCounterDescriptionFlagsKHR

#### New Enum Constants

- `VK_KHR_PERFORMANCE_QUERY_EXTENSION_NAME`

- `VK_KHR_PERFORMANCE_QUERY_SPEC_VERSION`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_DESCRIPTION_KHR`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_COUNTER_KHR`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_QUERY_SUBMIT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PERFORMANCE_QUERY_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR`

#### Issues

1) Should this extension include a mechanism to begin a query in command buffer 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 = {
      VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_CREATE_INFO_KHR,
      NULL,

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

      // The number of counters to enable
      enabledCounterCount,

      // The array of indices of counters to enable
      enabledCounters
    };

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

    vkGetPhysicalDeviceQueueFamilyPerformanceQueryPassesKHR(
      physicalDevice,
      &performanceQueryCreateInfo,
      &numPasses);

    VkQueryPoolCreateInfo queryPoolCreateInfo = {
      VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
      &performanceQueryCreateInfo,
      0,

      // Using our new query type here
      VK_QUERY_TYPE_PERFORMANCE_QUERY_KHR,

      1,

      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 = {
      VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO,
      NULL,
      0,
      NULL
    };

    VkAcquireProfilingLockInfoKHR lockInfo = {
      VK_STRUCTURE_TYPE_ACQUIRE_PROFILING_LOCK_INFO_KHR,
      NULL,
      0,
      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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - Developer tools

Contact

  - Jason Ekstrand jekstrand

#### Other Extension Metadata

Last Modified Date

  2019-05-28

IP Status

  No known IP claims.

Interactions and External Dependencies
Contributors

  - Jason Ekstrand, Intel

  - Ian Romanick, Intel

  - Kenneth Graunke, Intel

  - Baldur Karlsson, Valve

  - Jesse Hall, Google

  - Jeff Bolz, Nvidia

  - Piers Daniel, Nvidia

  - Tobias Hector, AMD

  - Jan-Harald Fredriksen, ARM

  - Tom Olson, ARM

  - Daniel Koch, Nvidia

  - Spencer Fricke, Samsung

#### Description

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

#### New Commands

- vkGetPipelineExecutableInternalRepresentationsKHR

- vkGetPipelineExecutablePropertiesKHR

- vkGetPipelineExecutableStatisticsKHR

#### New Structures

- VkPipelineExecutableInfoKHR

- VkPipelineExecutableInternalRepresentationKHR

- VkPipelineExecutablePropertiesKHR

- VkPipelineExecutableStatisticKHR

- VkPipelineInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePipelineExecutablePropertiesFeaturesKHR

#### New Unions

- VkPipelineExecutableStatisticValueKHR

#### New Enums

- VkPipelineExecutableStatisticFormatKHR

#### New Enum Constants

- `VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_EXTENSION_NAME`

- `VK_KHR_PIPELINE_EXECUTABLE_PROPERTIES_SPEC_VERSION`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_CAPTURE_INTERNAL_REPRESENTATIONS_BIT_KHR`

  - `VK_PIPELINE_CREATE_CAPTURE_STATISTICS_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_EXECUTABLE_PROPERTIES_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_INTERNAL_REPRESENTATION_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_EXECUTABLE_STATISTIC_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_INFO_KHR`

#### Issues

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

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

#### Version History

- Revision 1, 2019-05-28 (Jason Ekstrand)

  - Initial draft

#### VK_KHR_pipeline_library

Name String

  `VK_KHR_pipeline_library`

Extension Type

  Device extension

Registered Extension Number

  291

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Christoph Kubisch pixeljetstream

#### Other Extension Metadata

Last Modified Date

  2020-01-08

IP Status

  No known IP claims.

Contributors

  - See contributors to `VK_KHR_ray_tracing_pipeline`

#### Description

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

#### New Structures

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineLibraryCreateInfoKHR

#### New Enum Constants

- `VK_KHR_PIPELINE_LIBRARY_EXTENSION_NAME`

- `VK_KHR_PIPELINE_LIBRARY_SPEC_VERSION`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_LIBRARY_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_LIBRARY_CREATE_INFO_KHR`

#### Version History

- Revision 1, 2020-01-08 (Christoph Kubisch)

  - Initial draft.

#### VK_KHR_portability_enumeration

Name String

  `VK_KHR_portability_enumeration`

Extension Type

  Instance extension

Registered Extension Number

  395

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Charles Giessen charles-lunarg

#### Other Extension Metadata

Last Modified Date

  2021-06-02

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with `VK_KHR_portability_subset`

Contributors

  - Lenny Komow, LunarG

  - Charles Giessen, LunarG

#### Description

This extension allows applications to control whether devices that expose the `VK_KHR_portability_subset` extension are included in the results of physical device enumeration. Since devices which support the `VK_KHR_portability_subset` extension are not fully conformant Vulkan implementations, the Vulkan loader does not report those devices unless the application explicitly asks for them. This prevents applications which may not be aware of non-conformant devices from accidentally using them, as any device which supports the `VK_KHR_portability_subset` extension mandates that the extension must be enabled if that device is used.

This extension is implemented in the loader.

#### New Enum Constants

- `VK_KHR_PORTABILITY_ENUMERATION_EXTENSION_NAME`

- `VK_KHR_PORTABILITY_ENUMERATION_SPEC_VERSION`

- Extending VkInstanceCreateFlagBits:

  - `VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR`

#### Version History

- Revision 1, 2021-06-02 (Lenny Komow)

  - Initial version

#### VK_KHR_present_id

Name String

  `VK_KHR_present_id`

Extension Type

  Device extension

Registered Extension Number

  295

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - Keith Packard keithp

#### Other Extension Metadata

Last Modified Date

  2019-05-15

IP Status

  No known IP claims.

Contributors

  - Keith Packard, Valve

  - Ian Elliott, Google

  - Alon Or-bach, Samsung

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePresentIdFeaturesKHR

- Extending VkPresentInfoKHR:

  - VkPresentIdKHR

#### New Enum Constants

- `VK_KHR_PRESENT_ID_EXTENSION_NAME`

- `VK_KHR_PRESENT_ID_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_ID_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PRESENT_ID_KHR`

#### Issues

None.

#### Examples

#### Version History

- Revision 1, 2019-05-15 (Keith Packard)

  - Initial version

#### VK_KHR_present_wait

Name String

  `VK_KHR_present_wait`

Extension Type

  Device extension

Registered Extension Number

  249

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_present_id` to be enabled for any device-level functionality

Contact

  - Keith Packard keithp

#### Other Extension Metadata

Last Modified Date

  2019-05-15

IP Status

  No known IP claims.

Contributors

  - Keith Packard, Valve

  - Ian Elliott, Google

  - Tobias Hector, AMD

  - Daniel Stone, Collabora

#### Description

This device extension allows an application that uses the `VK_KHR_swapchain` extension to wait for present operations to complete. An application can use this to monitor and control the pacing of the application by managing the number of outstanding images yet to be presented.

#### New Commands

- vkWaitForPresentKHR

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePresentWaitFeaturesKHR

#### New Enum Constants

- `VK_KHR_PRESENT_WAIT_EXTENSION_NAME`

- `VK_KHR_PRESENT_WAIT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRESENT_WAIT_FEATURES_KHR`

#### Issues

1) When does the wait finish?

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

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

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

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

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

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

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

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-09-12

IP Status

  No known IP claims.

Contributors

  - Jeff Bolz, NVIDIA

  - Michael Worcester, Imagination Technologies

#### Description

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

#### New Commands

- vkCmdPushDescriptorSetKHR

If VK_KHR_descriptor_update_template is supported:

- vkCmdPushDescriptorSetWithTemplateKHR

If Version 1.1 is supported:

- vkCmdPushDescriptorSetWithTemplateKHR

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePushDescriptorPropertiesKHR

#### New Enum Constants

- `VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME`

- `VK_KHR_PUSH_DESCRIPTOR_SPEC_VERSION`

- Extending VkDescriptorSetLayoutCreateFlagBits:

  - `VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PUSH_DESCRIPTOR_PROPERTIES_KHR`

If VK_KHR_descriptor_update_template is supported:

- Extending VkDescriptorUpdateTemplateType:

  - `VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR`

If Version 1.1 is supported:

- Extending VkDescriptorUpdateTemplateType:

  - `VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_spirv_1_4` to be enabled for any device-level functionality

  - Requires `VK_KHR_acceleration_structure` to be enabled for any device-level functionality

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2020-11-12

Interactions and External Dependencies

  - This extension requires `SPV_KHR_ray_query`

  - This extension provides API support for `GLSL_EXT_ray_query`

Contributors

  - Matthäus Chajdas, AMD

  - Greg Grebe, AMD

  - Nicolai Hähnle, AMD

  - Tobias Hector, AMD

  - Dave Oldcorn, AMD

  - Skyler Saleh, AMD

  - Mathieu Robart, Arm

  - Marius Bjorge, Arm

  - Tom Olson, Arm

  - Sebastian Tafuri, EA

  - Henrik Rydgard, Embark

  - Juan Cañada, Epic Games

  - Patrick Kelly, Epic Games

  - Yuriy O’Donnell, Epic Games

  - Michael Doggett, Facebook/Oculus

  - Andrew Garrard, Imagination

  - Don Scorgie, Imagination

  - Dae Kim, Imagination

  - Joshua Barczak, Intel

  - Slawek Grajewski, Intel

  - Jeff Bolz, NVIDIA

  - Pascal Gautron, NVIDIA

  - Daniel Koch, NVIDIA

  - Christoph Kubisch, NVIDIA

  - Ashwin Lele, NVIDIA

  - Robert Stepinski, NVIDIA

  - Martin Stich, NVIDIA

  - Nuno Subtil, NVIDIA

  - Eric Werness, NVIDIA

  - Jon Leech, Khronos

  - Jeroen van Schijndel, OTOY

  - Juul Joosten, OTOY

  - Alex Bourd, Qualcomm

  - Roman Larionov, Qualcomm

  - David McAllister, Qualcomm

  - Spencer Fricke, Samsung

  - Lewis Gordon, Samsung

  - Ralph Potter, Samsung

  - Jasper Bekkers, Traverse Research

  - Jesse Barker, Unity

  - Baldur Karlsson, Valve

#### Description

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

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

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

- `SPV_KHR_ray_query`

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRayQueryFeaturesKHR

#### New Enum Constants

- `VK_KHR_RAY_QUERY_EXTENSION_NAME`

- `VK_KHR_RAY_QUERY_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_QUERY_FEATURES_KHR`

#### New SPIR-V Capabilities

- `RayQueryKHR`

- `RayTraversalPrimitiveCullingKHR`

#### Sample Code

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

    rayQueryEXT rq;

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

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

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

#### Issues

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

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

  - `VK_KHR_acceleration_structure` (for acceleration structure operations)

  - `VK_KHR_ray_tracing_pipeline` (for ray tracing pipeline and shader stages)

  - `VK_KHR_ray_query` (for ray queries in existing shader stages)

- Update SPIRV capabilities to use `RayQueryKHR`

- extension is no longer provisional

#### Version History

- Revision 1, 2020-11-12 (Mathieu Robart, Daniel Koch, Andrew Garrard)

  - Decomposition of the specification, from VK_KHR_ray_tracing to VK_KHR_ray_query (#1918,!3912)

  - update to use `RayQueryKHR` SPIR-V capability

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

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

  - restrict traces to TLAS (#2239,!4141)

  - require `HitT` to be in ray interval for `OpRayQueryGenerateIntersectionKHR` (#2359,!4146)

  - add ray query shader stages for AS read bit (#2407,!4203)

#### VK_KHR_ray_tracing_maintenance1

Name String

  `VK_KHR_ray_tracing_maintenance1`

Extension Type

  Device extension

Registered Extension Number

  387

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_acceleration_structure` to be enabled for any device-level functionality

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2022-02-21

Interactions and External Dependencies

  - This extension requires `SPV_KHR_ray_cull_mask`

  - This extension provides API support for `GLSL_EXT_ray_cull_mask`

  - Interacts with `VK_KHR_ray_tracing_pipeline`

  - Interacts with `VK_KHR_synchronization2`

Contributors

  - Stu Smith, AMD

  - Tobias Hector, AMD

  - Marius Bjorge, Arm

  - Tom Olson, Arm

  - Yuriy O’Donnell, Epic Games

  - Yunpeng Zhu, Huawei

  - Andrew Garrard, Imagination

  - Dae Kim, Imagination

  - Joshua Barczak, Intel

  - Lionel Landwerlin, Intel

  - Daniel Koch, NVIDIA

  - Eric Werness, NVIDIA

  - Spencer Fricke, Samsung

#### Description

`VK_KHR_ray_tracing_maintenance1` adds a collection of minor ray tracing features, none of which would warrant an entire extension of their own.

The new features are as follows:

- Adds support for the `SPV_KHR_ray_cull_mask` SPIR-V extension in Vulkan. This extension provides access to built-in `CullMaskKHR` shader variable which contains the value of the `OpTrace*` `Cull Mask` parameter. This new shader variable is accessible in the intersection, any-hit, closest-hit and miss shader stages.

- Adds support for a new pipeline stage and access mask built on top of `VK_KHR_synchronization2`:

  - `VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR` to specify execution of acceleration structure copy commands

  - `VK_ACCESS_2_SHADER_BINDING_TABLE_READ_BIT_KHR` to specify read access to a shader binding table in any shader pipeline stage

- Adds two new acceleration structure query parameters:

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR` to query the acceleration structure size on the device timeline

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR` to query the number of bottom level acceleration structure pointers for serialization

- Adds an optional new indirect ray tracing dispatch command, vkCmdTraceRaysIndirect2KHR, which sources the shader binding table parameters as well as the dispatch dimensions from the device. The `rayTracingPipelineTraceRaysIndirect2` feature indicates whether this functionality is supported.

#### New Commands

If VK_KHR_ray_tracing_pipeline is supported:

- vkCmdTraceRaysIndirect2KHR

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRayTracingMaintenance1FeaturesKHR

If VK_KHR_ray_tracing_pipeline is supported:

- VkTraceRaysIndirectCommand2KHR

#### New Enum Constants

- `VK_KHR_RAY_TRACING_MAINTENANCE_1_EXTENSION_NAME`

- `VK_KHR_RAY_TRACING_MAINTENANCE_1_SPEC_VERSION`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SERIALIZATION_BOTTOM_LEVEL_POINTERS_KHR`

  - `VK_QUERY_TYPE_ACCELERATION_STRUCTURE_SIZE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MAINTENANCE_1_FEATURES_KHR`

If VK_KHR_synchronization2 is supported:

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_COPY_BIT_KHR`

If VK_KHR_synchronization2 and VK_KHR_ray_tracing_pipeline is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_SHADER_BINDING_TABLE_READ_BIT_KHR`

#### New Built-In Variables

- `CullMaskKHR`

#### New SPIR-V Capabilities

- `RayCullMaskKHR`

#### Issues

None Yet!

#### Version History

- Revision 1, 2022-02-21 (Members of the Vulkan Ray Tracing TSG)

  - internal revisions

#### VK_KHR_ray_tracing_pipeline

Name String

  `VK_KHR_ray_tracing_pipeline`

Extension Type

  Device extension

Registered Extension Number

  348

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_spirv_1_4` to be enabled for any device-level functionality

  - Requires `VK_KHR_acceleration_structure` to be enabled for any device-level functionality

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2020-11-12

Interactions and External Dependencies

  - This extension requires `SPV_KHR_ray_tracing`

  - This extension provides API support for `GLSL_EXT_ray_tracing`

  - This extension interacts with Vulkan 1.2 and `VK_KHR_vulkan_memory_model`, adding the shader-call-related relation of invocations, shader-call-order partial order of dynamic instances of instructions, and the `ShaderCallKHR` scope.

  - This extension interacts with `VK_KHR_pipeline_library`, enabling pipeline libraries to be used with ray tracing pipelines and enabling usage of VkRayTracingPipelineInterfaceCreateInfoKHR.

Contributors

  - Matthäus Chajdas, AMD

  - Greg Grebe, AMD

  - Nicolai Hähnle, AMD

  - Tobias Hector, AMD

  - Dave Oldcorn, AMD

  - Skyler Saleh, AMD

  - Mathieu Robart, Arm

  - Marius Bjorge, Arm

  - Tom Olson, Arm

  - Sebastian Tafuri, EA

  - Henrik Rydgard, Embark

  - Juan Cañada, Epic Games

  - Patrick Kelly, Epic Games

  - Yuriy O’Donnell, Epic Games

  - Michael Doggett, Facebook/Oculus

  - Andrew Garrard, Imagination

  - Don Scorgie, Imagination

  - Dae Kim, Imagination

  - Joshua Barczak, Intel

  - Slawek Grajewski, Intel

  - Jeff Bolz, NVIDIA

  - Pascal Gautron, NVIDIA

  - Daniel Koch, NVIDIA

  - Christoph Kubisch, NVIDIA

  - Ashwin Lele, NVIDIA

  - Robert Stepinski, NVIDIA

  - Martin Stich, NVIDIA

  - Nuno Subtil, NVIDIA

  - Eric Werness, NVIDIA

  - Jon Leech, Khronos

  - Jeroen van Schijndel, OTOY

  - Juul Joosten, OTOY

  - Alex Bourd, Qualcomm

  - Roman Larionov, Qualcomm

  - David McAllister, Qualcomm

  - Spencer Fricke, Samsung

  - Lewis Gordon, Samsung

  - Ralph Potter, Samsung

  - Jasper Bekkers, Traverse Research

  - Jesse Barker, Unity

  - Baldur Karlsson, Valve

#### Description

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

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

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

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

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

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

- `SPV_KHR_ray_tracing`

#### New Commands

- vkCmdSetRayTracingPipelineStackSizeKHR

- vkCmdTraceRaysIndirectKHR

- vkCmdTraceRaysKHR

- vkCreateRayTracingPipelinesKHR

- vkGetRayTracingCaptureReplayShaderGroupHandlesKHR

- vkGetRayTracingShaderGroupHandlesKHR

- vkGetRayTracingShaderGroupStackSizeKHR

#### New Structures

- VkRayTracingPipelineCreateInfoKHR

- VkRayTracingPipelineInterfaceCreateInfoKHR

- VkRayTracingShaderGroupCreateInfoKHR

- VkStridedDeviceAddressRegionKHR

- VkTraceRaysIndirectCommandKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRayTracingPipelineFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceRayTracingPipelinePropertiesKHR

#### New Enums

- VkRayTracingShaderGroupTypeKHR

- VkShaderGroupShaderKHR

#### New Enum Constants

- `VK_KHR_RAY_TRACING_PIPELINE_EXTENSION_NAME`

- `VK_KHR_RAY_TRACING_PIPELINE_SPEC_VERSION`

- `VK_SHADER_UNUSED_KHR`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR`

- Extending VkPipelineBindPoint:

  - `VK_PIPELINE_BIND_POINT_RAY_TRACING_KHR`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR`

  - `VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_KHR`

- Extending VkShaderStageFlagBits:

  - `VK_SHADER_STAGE_ANY_HIT_BIT_KHR`

  - `VK_SHADER_STAGE_CALLABLE_BIT_KHR`

  - `VK_SHADER_STAGE_CLOSEST_HIT_BIT_KHR`

  - `VK_SHADER_STAGE_INTERSECTION_BIT_KHR`

  - `VK_SHADER_STAGE_MISS_BIT_KHR`

  - `VK_SHADER_STAGE_RAYGEN_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_PIPELINE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_RAY_TRACING_PIPELINE_INTERFACE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_RAY_TRACING_SHADER_GROUP_CREATE_INFO_KHR`

#### New or Modified Built-In Variables

- `LaunchIdKHR`

- `LaunchSizeKHR`

- `WorldRayOriginKHR`

- `WorldRayDirectionKHR`

- `ObjectRayOriginKHR`

- `ObjectRayDirectionKHR`

- `RayTminKHR`

- `RayTmaxKHR`

- `InstanceCustomIndexKHR`

- `InstanceId`

- `ObjectToWorldKHR`

- `WorldToObjectKHR`

- `HitKindKHR`

- `IncomingRayFlagsKHR`

- `RayGeometryIndexKHR`

- (modified)`PrimitiveId`

#### New SPIR-V Capabilities

- `RayTracingKHR`

- `RayTraversalPrimitiveCullingKHR`

#### Issues

(1) How does this extension differ from VK_NV_ray_tracing?

DISCUSSION:

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

- added support for indirect ray tracing (vkCmdTraceRaysIndirectKHR)

- uses SPV_KHR_ray_tracing instead of SPV_NV_ray_tracing

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

  - added `RayGeometryIndexKHR` built-in

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

- added VkPhysicalDeviceRayTracingPipelineFeaturesKHR structure

- extended VkPhysicalDeviceRayTracingPipelinePropertiesKHR structure

  - renamed `maxRecursionDepth` to `maxRayRecursionDepth` and it has a minimum of 1 instead of 31

  - require `shaderGroupHandleSize` to be 32 bytes

  - added `maxRayDispatchInvocationCount`, `shaderGroupHandleAlignment` and `maxRayHitAttributeSize`

- reworked geometry structures so they could be better shared between device, host, and indirect builds

- changed SBT parameters to a structure and added size (VkStridedDeviceAddressRegionKHR)

- add parameter for requesting memory requirements for host and/or device build

- added pipeline library support for ray tracing

- added watertightness guarantees

- added no-null-shader pipeline flags (`VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_*_SHADERS_BIT_KHR`)

- added memory model interactions with ray tracing and define how subgroups work and can be repacked

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

DISCUSSION:

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

- Aliased functionality — enums, structures, and commands that are considered equivalent:

  - VkRayTracingShaderGroupTypeNV ↔ VkRayTracingShaderGroupTypeKHR

  - vkGetRayTracingShaderGroupHandlesNV ↔ vkGetRayTracingShaderGroupHandlesKHR

- Changed enums, structures, and commands:

  - VkRayTracingShaderGroupCreateInfoNV → VkRayTracingShaderGroupCreateInfoKHR (added `pShaderGroupCaptureReplayHandle`)

  - VkRayTracingPipelineCreateInfoNV → VkRayTracingPipelineCreateInfoKHR (changed type of `pGroups`, added `libraries`, `pLibraryInterface`, and `pDynamicState`)

  - VkPhysicalDeviceRayTracingPropertiesNV → VkPhysicalDeviceRayTracingPropertiesKHR (renamed `maxTriangleCount` to `maxPrimitiveCount`, added `shaderGroupHandleCaptureReplaySize`)

  - vkCmdTraceRaysNV → vkCmdTraceRaysKHR (params to struct)

  - vkCreateRayTracingPipelinesNV → vkCreateRayTracingPipelinesKHR (different struct, changed functionality)

- Added enums, structures and commands:

  - `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_ANY_HIT_SHADERS_BIT_KHR` `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_CLOSEST_HIT_SHADERS_BIT_KHR`, `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_MISS_SHADERS_BIT_KHR`, `VK_PIPELINE_CREATE_RAY_TRACING_NO_NULL_INTERSECTION_SHADERS_BIT_KHR`, `VK_PIPELINE_CREATE_RAY_TRACING_SKIP_TRIANGLES_BIT_KHR`, `VK_PIPELINE_CREATE_RAY_TRACING_SKIP_AABBS_BIT_KHR` to VkPipelineCreateFlagBits

  - VkPhysicalDeviceRayTracingPipelineFeaturesKHR structure

  - VkDeviceOrHostAddressKHR and VkDeviceOrHostAddressConstKHR unions

  - VkPipelineLibraryCreateInfoKHR struct

  - VkRayTracingPipelineInterfaceCreateInfoKHR struct

  - VkStridedDeviceAddressRegionKHR struct

  - vkCmdTraceRaysIndirectKHR command and VkTraceRaysIndirectCommandKHR struct

  - vkGetRayTracingCaptureReplayShaderGroupHandlesKHR (shader group capture/replay)

  - vkCmdSetRayTracingPipelineStackSizeKHR and vkGetRayTracingShaderGroupStackSizeKHR commands for stack size control

- Functionality removed:

  - `VK_PIPELINE_CREATE_DEFER_COMPILE_BIT_NV`

  - vkCompileDeferredNV command (replaced with `VK_KHR_deferred_host_operations`)

(3) What are the changes between the public provisional (VK_KHR_ray_tracing v8) release and the internal provisional (VK_KHR_ray_tracing v9) release?

- Require Vulkan 1.1 and SPIR-V 1.4

- Added interactions with Vulkan 1.2 and `VK_KHR_vulkan_memory_model`

- added creation time capture and replay flags

  - added `VK_PIPELINE_CREATE_RAY_TRACING_SHADER_GROUP_HANDLE_CAPTURE_REPLAY_BIT_KHR` to VkPipelineCreateFlagBits

- replace `VkStridedBufferRegionKHR` with VkStridedDeviceAddressRegionKHR and change vkCmdTraceRaysKHR, vkCmdTraceRaysIndirectKHR, to take these for the shader binding table and use device addresses instead of buffers.

- require the shader binding table buffers to have the `VK_BUFFER_USAGE_RAY_TRACING_BIT_KHR` set

- make `VK_KHR_pipeline_library` an interaction instead of required extension

- rename the `libraries` member of VkRayTracingPipelineCreateInfoKHR to `pLibraryInfo` and make it a pointer

- make `VK_KHR_deferred_host_operations` an interaction instead of a required extension (later went back on this)

- added explicit stack size management for ray tracing pipelines

  - removed the `maxCallableSize` member of VkRayTracingPipelineInterfaceCreateInfoKHR

  - added the `pDynamicState` member to VkRayTracingPipelineCreateInfoKHR

  - added `VK_DYNAMIC_STATE_RAY_TRACING_PIPELINE_STACK_SIZE_KHR` dynamic state for ray tracing pipelines

  - added vkGetRayTracingShaderGroupStackSizeKHR and vkCmdSetRayTracingPipelineStackSizeKHR commands

  - added VkShaderGroupShaderKHR enum

- Added `maxRayDispatchInvocationCount` limit to VkPhysicalDeviceRayTracingPipelinePropertiesKHR

- Added `shaderGroupHandleAlignment` property to VkPhysicalDeviceRayTracingPipelinePropertiesKHR

- Added `maxRayHitAttributeSize` property to VkPhysicalDeviceRayTracingPipelinePropertiesKHR

- Clarify deferred host ops for pipeline creation

  - VkDeferredOperationKHR is now a top-level parameter for vkCreateRayTracingPipelinesKHR

  - removed `VkDeferredOperationInfoKHR` structure

  - change deferred host creation/return parameter behavior such that the implementation can modify such parameters until the deferred host operation completes

  - `VK_KHR_deferred_host_operations` is required again

(4) What are the changes between the internal provisional (VK_KHR_ray_tracing v9) release and the final (VK_KHR_acceleration_structure v11 / VK_KHR_ray_tracing_pipeline v1) release?

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

  - `VK_KHR_acceleration_structure` (for acceleration structure operations)

  - `VK_KHR_ray_tracing_pipeline` (for ray tracing pipeline and shader stages)

  - `VK_KHR_ray_query` (for ray queries in existing shader stages)

- Require `Volatile` for the following builtins in the ray generation, closest hit, miss, intersection, and callable shader stages:

  - `SubgroupSize`, `SubgroupLocalInvocationId`, `SubgroupEqMask`, `SubgroupGeMask`, `SubgroupGtMask`, `SubgroupLeMask`, `SubgroupLtMask`

  - `SMIDNV`, `WarpIDNV`

- clarify buffer usage flags for ray tracing

  - `VK_BUFFER_USAGE_SHADER_BINDING_TABLE_BIT_KHR` is added as an alias of `VK_BUFFER_USAGE_RAY_TRACING_BIT_NV` and is required on shader binding table buffers

  - `VK_BUFFER_USAGE_STORAGE_BUFFER_BIT` is used in `VK_KHR_acceleration_structure` for `scratchData`

- rename `maxRecursionDepth` to `maxRayPipelineRecursionDepth` (pipeline creation) and `maxRayRecursionDepth` (limit) to reduce confusion

- Add queryable `maxRayHitAttributeSize` limit and rename members of VkRayTracingPipelineInterfaceCreateInfoKHR to `maxPipelineRayPayloadSize` and `maxPipelineRayHitAttributeSize` for clarity

- Update SPIRV capabilities to use `RayTracingKHR`

- extension is no longer provisional

- define synchronization requirements for indirect trace rays and indirect buffer

(5) This extension adds gl_InstanceID for the intersection, any-hit, and closest hit shaders, but in KHR_vulkan_glsl, gl_InstanceID is replaced with gl_InstanceIndex. Which should be used for Vulkan in this extension?

RESOLVED: This extension uses gl_InstanceID and maps it to `InstanceId` in SPIR-V. It is acknowledged that this is different than other shader stages in Vulkan. There are two main reasons for the difference here:

- symmetry with gl_PrimitiveID which is also available in these shaders

- there is no “baseInstance” relevant for these shaders, and so ID makes it more obvious that this is zero-based.

(6) Why is `VK_KHR_pipeline_library` an interaction instead of a required dependency, particularly when the “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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Aaron Hagan ahagan

#### Other Extension Metadata

Last Modified Date

  2019-4-25

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_shader_clock`.

  - This extension provides API support for `ARB_shader_clock` and `EXT_shader_realtime_clock`

Contributors

  - Aaron Hagan, AMD

  - Daniel Koch, NVIDIA

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderClockFeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_CLOCK_EXTENSION_NAME`

- `VK_KHR_SHADER_CLOCK_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CLOCK_FEATURES_KHR`

#### New SPIR-V Capabilities

- `ShaderClockKHR`

#### Version History

- Revision 1, 2019-4-25 (Aaron Hagan)

  - Initial revision

#### VK_KHR_shader_subgroup_uniform_control_flow

Name String

  `VK_KHR_shader_subgroup_uniform_control_flow`

Extension Type

  Device extension

Registered Extension Number

  324

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Contact

  - Alan Baker alan-baker

#### Other Extension Metadata

Last Modified Date

  2020-08-27

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Requires SPIR-V 1.3.

  - This extension requires `SPV_KHR_subgroup_uniform_control_flow`

  - This extension provides API support for `GL_EXT_subgroupuniform_qualifier`

Contributors

  - Alan Baker, Google

  - Jeff Bolz, NVIDIA

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderSubgroupUniformControlFlowFeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_EXTENSION_NAME`

- `VK_KHR_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_UNIFORM_CONTROL_FLOW_FEATURES_KHR`

#### Version History

- Revision 1, 2020-08-27 (Alan Baker)

  - Internal draft version

#### VK_KHR_shared_presentable_image

Name String

  `VK_KHR_shared_presentable_image`

Extension Type

  Device extension

Registered Extension Number

  112

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_surface_capabilities2` to be enabled for any device-level functionality

Contact

  - Alon Or-bach alonorbach

#### Other Extension Metadata

Last Modified Date

  2017-03-20

IP Status

  No known IP claims.

Contributors

  - Alon Or-bach, Samsung Electronics

  - Ian Elliott, Google

  - Jesse Hall, Google

  - Pablo Ceballos, Google

  - Chris Forbes, Google

  - Jeff Juliano, NVIDIA

  - James Jones, NVIDIA

  - Daniel Rakos, AMD

  - Tobias Hector, Imagination Technologies

  - Graham Connor, Imagination Technologies

  - Michael Worcester, Imagination Technologies

  - Cass Everitt, Oculus

  - Johannes Van Waveren, Oculus

#### Description

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

#### New Commands

- vkGetSwapchainStatusKHR

#### New Structures

- Extending VkSurfaceCapabilities2KHR:

  - VkSharedPresentSurfaceCapabilitiesKHR

#### New Enum Constants

- `VK_KHR_SHARED_PRESENTABLE_IMAGE_EXTENSION_NAME`

- `VK_KHR_SHARED_PRESENTABLE_IMAGE_SPEC_VERSION`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR`

- Extending VkPresentModeKHR:

  - `VK_PRESENT_MODE_SHARED_CONTINUOUS_REFRESH_KHR`

  - `VK_PRESENT_MODE_SHARED_DEMAND_REFRESH_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SHARED_PRESENT_SURFACE_CAPABILITIES_KHR`

#### Issues

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

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

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

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

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

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

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

RESOLVED: Shared presentable image / shared present.

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

RESOLVED: `minImageCount` must be 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - James Jones cubanismo

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2016-08-25

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Ian Elliott, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

  - Jason Ekstrand, Intel

#### Description

The `VK_KHR_surface` extension is an instance extension. It introduces VkSurfaceKHR objects, which abstract native platform surface or window objects for use with Vulkan. It also provides a way to determine whether a queue family in a physical device supports presenting to particular surface.

Separate extensions for each platform provide the mechanisms for creating VkSurfaceKHR objects, but once created they may be used in this and other platform-independent extensions, in particular the `VK_KHR_swapchain` extension.

#### New Object Types

- VkSurfaceKHR

#### New Commands

- vkDestroySurfaceKHR

- vkGetPhysicalDeviceSurfaceCapabilitiesKHR

- vkGetPhysicalDeviceSurfaceFormatsKHR

- vkGetPhysicalDeviceSurfacePresentModesKHR

- vkGetPhysicalDeviceSurfaceSupportKHR

#### New Structures

- VkSurfaceCapabilitiesKHR

- VkSurfaceFormatKHR

#### New Enums

- VkColorSpaceKHR

- VkCompositeAlphaFlagBitsKHR

- VkPresentModeKHR

- VkSurfaceTransformFlagBitsKHR

#### New Bitmasks

- VkCompositeAlphaFlagsKHR

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_get_surface_capabilities2` to be enabled

Contact

  - Sandeep Shinde sashinde

#### Other Extension Metadata

Last Modified Date

  2018-12-18

IP Status

  No known IP claims.

Contributors

  - Sandeep Shinde, NVIDIA

  - James Jones, NVIDIA

  - Daniel Koch, NVIDIA

#### Description

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

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

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

#### New Structures

- Extending VkSurfaceCapabilities2KHR:

  - VkSurfaceProtectedCapabilitiesKHR

#### New Enum Constants

- `VK_KHR_SURFACE_PROTECTED_CAPABILITIES_EXTENSION_NAME`

- `VK_KHR_SURFACE_PROTECTED_CAPABILITIES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SURFACE_PROTECTED_CAPABILITIES_KHR`

#### Version History

- Revision 1, 2018-12-18 (Sandeep Shinde, Daniel Koch)

  - Internal revisions.

#### VK_KHR_swapchain

Name String

  `VK_KHR_swapchain`

Extension Type

  Device extension

Registered Extension Number

  2

Revision

  70

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2017-10-06

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with Vulkan 1.1

Contributors

  - Patrick Doane, Blizzard

  - Ian Elliott, LunarG

  - Jesse Hall, Google

  - Mathias Heyer, NVIDIA

  - James Jones, NVIDIA

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

  - Jason Ekstrand, Intel

  - Matthaeus G. Chajdas, AMD

  - Ray Smith, ARM

#### Description

The `VK_KHR_swapchain` extension is the device-level companion to the `VK_KHR_surface` extension. It introduces VkSwapchainKHR objects, which provide the ability to present rendering results to a surface.

#### New Object Types

- VkSwapchainKHR

#### New Commands

- vkAcquireNextImageKHR

- vkCreateSwapchainKHR

- vkDestroySwapchainKHR

- vkGetSwapchainImagesKHR

- vkQueuePresentKHR

If Version 1.1 is supported:

- vkAcquireNextImage2KHR

- vkGetDeviceGroupPresentCapabilitiesKHR

- vkGetDeviceGroupSurfacePresentModesKHR

- vkGetPhysicalDevicePresentRectanglesKHR

#### New Structures

- VkPresentInfoKHR

- VkSwapchainCreateInfoKHR

If Version 1.1 is supported:

- VkAcquireNextImageInfoKHR

- VkDeviceGroupPresentCapabilitiesKHR

- Extending VkBindImageMemoryInfo:

  - VkBindImageMemorySwapchainInfoKHR

- Extending VkImageCreateInfo:

  - VkImageSwapchainCreateInfoKHR

- Extending VkPresentInfoKHR:

  - VkDeviceGroupPresentInfoKHR

- Extending VkSwapchainCreateInfoKHR:

  - VkDeviceGroupSwapchainCreateInfoKHR

#### New Enums

- VkSwapchainCreateFlagBitsKHR

If Version 1.1 is supported:

- VkDeviceGroupPresentModeFlagBitsKHR

#### New Bitmasks

- VkSwapchainCreateFlagsKHR

If Version 1.1 is supported:

- VkDeviceGroupPresentModeFlagsKHR

#### New Enum Constants

- `VK_KHR_SWAPCHAIN_EXTENSION_NAME`

- `VK_KHR_SWAPCHAIN_SPEC_VERSION`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_SWAPCHAIN_KHR`

- Extending VkResult:

  - `VK_ERROR_OUT_OF_DATE_KHR`

  - `VK_SUBOPTIMAL_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PRESENT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR`

If 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 (Jason Ekstrand)

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

- Revision 36, 2015-06-26 (Jason 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 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_maintenance2` to be enabled for any device-level functionality

  - Requires `VK_KHR_image_format_list` to be enabled for any device-level functionality

Contact

  - Daniel Rakos drakos-arm

#### Other Extension Metadata

Last Modified Date

  2018-03-28

IP Status

  No known IP claims.

Contributors

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

Name String

  `VK_KHR_wayland_surface`

Extension Type

  Instance extension

Registered Extension Number

  7

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jesse Hall critsec

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2015-11-28

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Jason Ekstrand, Intel

  - Ian Elliott, LunarG

  - Courtney Goeltzenleuchter, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Antoine Labour, Google

  - Jon Leech, Khronos

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Ray Smith, ARM

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

#### Description

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

#### New Commands

- vkCreateWaylandSurfaceKHR

- vkGetPhysicalDeviceWaylandPresentationSupportKHR

#### New Structures

- VkWaylandSurfaceCreateInfoKHR

#### New Bitmasks

- VkWaylandSurfaceCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_WAYLAND_SURFACE_EXTENSION_NAME`

- `VK_KHR_WAYLAND_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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

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

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

#### Version History

- Revision 1, 2015-09-23 (Jesse Hall)

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

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

  - Added vkGetPhysicalDeviceWaylandPresentationSupportKHR() to resolve issue #1.

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

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

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

  - Renamed from VK_EXT_KHR_wayland_surface to VK_KHR_wayland_surface.

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

  - Added allocation callbacks to vkCreateWaylandSurfaceKHR.

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

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

- Revision 6, 2017-02-08 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory_win32` to be enabled for any device-level functionality

Contact

  - Carsten Rohde crohde

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

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

#### New Structures

- Extending VkSubmitInfo, VkSubmitInfo2:

  - VkWin32KeyedMutexAcquireReleaseInfoKHR

#### New Enum Constants

- `VK_KHR_WIN32_KEYED_MUTEX_EXTENSION_NAME`

- `VK_KHR_WIN32_KEYED_MUTEX_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_KHR`

#### Version History

- Revision 1, 2016-10-21 (James Jones)

  - Initial revision

#### VK_KHR_win32_surface

Name String

  `VK_KHR_win32_surface`

Extension Type

  Instance extension

Registered Extension Number

  10

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jesse Hall critsec

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2017-04-24

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Jason Ekstrand, Intel

  - Ian Elliott, LunarG

  - Courtney Goeltzenleuchter, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Antoine Labour, Google

  - Jon Leech, Khronos

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Ray Smith, ARM

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

#### Description

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

#### New Commands

- vkCreateWin32SurfaceKHR

- vkGetPhysicalDeviceWin32PresentationSupportKHR

#### New Structures

- VkWin32SurfaceCreateInfoKHR

#### New Bitmasks

- VkWin32SurfaceCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_WIN32_SURFACE_EXTENSION_NAME`

- `VK_KHR_WIN32_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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

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

RESOLVED: Yes.

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

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

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

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

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

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

Technical details include:

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

- Calling GDI’s `SetPixelFormat` (needed by OpenGL’s WGL layer) on a window object alters the object for the remainder of its lifetime. The MSDN documentation for `SetPixelFormat` explains that a window object’s pixel format can be set only one time.

- Creating a VkSwapchainKHR over a window object can alter the object for its remaining lifetime. Either of the above alterations may occur as a side effect of vkCreateSwapchainKHR.

#### Version History

- Revision 1, 2015-09-23 (Jesse Hall)

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

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

  - Added presentation support query for win32 desktops.

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

  - Renamed from VK_EXT_KHR_win32_surface to VK_KHR_win32_surface.

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

  - Added allocation callbacks to vkCreateWin32SurfaceKHR.

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

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

- Revision 6, 2017-04-24 (Jeff Juliano)

  - Add issue 2 addressing reuse of a native window object in a different Graphics API, or by a different Vulkan ICD.

#### VK_KHR_workgroup_memory_explicit_layout

Name String

  `VK_KHR_workgroup_memory_explicit_layout`

Extension Type

  Device extension

Registered Extension Number

  337

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Caio Marcelo de Oliveira Filho cmarcelo

#### Other Extension Metadata

Last Modified Date

  2020-06-01

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_workgroup_memory_explicit_layout`

  - This extension provides API support for `GL_EXT_shared_memory_block`

Contributors

  - Caio Marcelo de Oliveira Filho, Intel

  - Jeff Bolz, NVIDIA

  - Graeme Leese, Broadcom

  - Jason Ekstrand, Intel

  - Daniel Koch, NVIDIA

#### Description

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

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceWorkgroupMemoryExplicitLayoutFeaturesKHR

#### New Enum Constants

- `VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_EXTENSION_NAME`

- `VK_KHR_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_WORKGROUP_MEMORY_EXPLICIT_LAYOUT_FEATURES_KHR`

#### New SPIR-V Capabilities

- `WorkgroupMemoryExplicitLayoutKHR`

- `WorkgroupMemoryExplicitLayout8BitAccessKHR`

- `WorkgroupMemoryExplicitLayout16BitAccessKHR`

#### Version History

- Revision 1, 2020-06-01 (Caio Marcelo de Oliveira Filho)

  - Initial version

#### VK_KHR_xcb_surface

Name String

  `VK_KHR_xcb_surface`

Extension Type

  Instance extension

Registered Extension Number

  6

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jesse Hall critsec

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2015-11-28

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Jason Ekstrand, Intel

  - Ian Elliott, LunarG

  - Courtney Goeltzenleuchter, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Antoine Labour, Google

  - Jon Leech, Khronos

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Ray Smith, ARM

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

#### Description

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

#### New Commands

- vkCreateXcbSurfaceKHR

- vkGetPhysicalDeviceXcbPresentationSupportKHR

#### New Structures

- VkXcbSurfaceCreateInfoKHR

#### New Bitmasks

- VkXcbSurfaceCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_XCB_SURFACE_EXTENSION_NAME`

- `VK_KHR_XCB_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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

#### Version History

- Revision 1, 2015-09-23 (Jesse Hall)

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

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

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

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

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

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

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

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

  - Renamed from VK_EXT_KHR_xcb_surface to VK_KHR_xcb_surface.

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

  - Added allocation callbacks to vkCreateXcbSurfaceKHR.

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

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

#### VK_KHR_xlib_surface

Name String

  `VK_KHR_xlib_surface`

Extension Type

  Instance extension

Registered Extension Number

  5

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jesse Hall critsec

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2015-11-28

IP Status

  No known IP claims.

Contributors

  - Patrick Doane, Blizzard

  - Jason Ekstrand, Intel

  - Ian Elliott, LunarG

  - Courtney Goeltzenleuchter, LunarG

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Antoine Labour, Google

  - Jon Leech, Khronos

  - David Mao, AMD

  - Norbert Nopper, Freescale

  - Alon Or-bach, Samsung

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Ray Smith, ARM

  - Jeff Vigil, Qualcomm

  - Chia-I Wu, LunarG

#### Description

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

#### New Commands

- vkCreateXlibSurfaceKHR

- vkGetPhysicalDeviceXlibPresentationSupportKHR

#### New Structures

- VkXlibSurfaceCreateInfoKHR

#### New Bitmasks

- VkXlibSurfaceCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_XLIB_SURFACE_EXTENSION_NAME`

- `VK_KHR_XLIB_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR`

#### Issues

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

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

#### Version History

- Revision 1, 2015-09-23 (Jesse Hall)

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

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

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

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

  - Added appropriate X errors.

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

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

  - Renamed this extension from VK_EXT_KHR_x11_surface to VK_EXT_KHR_xlib_surface.

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

  - Renamed from VK_EXT_KHR_xlib_surface to VK_KHR_xlib_surface.

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

  - Added allocation callbacks to vkCreateXlibSurfaceKHR.

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

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

#### VK_EXT_acquire_drm_display

Name String

  `VK_EXT_acquire_drm_display`

Extension Type

  Instance extension

Registered Extension Number

  286

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_direct_mode_display` to be enabled

Contact

  - Drew DeVault sir@cmpwn.com

#### Other Extension Metadata

Last Modified Date

  2021-06-09

IP Status

  No known IP claims.

Contributors

  - Simon Zeni, Status Holdings, Ltd.

#### Description

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

#### New Commands

- vkAcquireDrmDisplayEXT

- vkGetDrmDisplayEXT

#### New Enum Constants

- `VK_EXT_ACQUIRE_DRM_DISPLAY_EXTENSION_NAME`

- `VK_EXT_ACQUIRE_DRM_DISPLAY_SPEC_VERSION`

#### Issues

None.

#### Version History

- Revision 1, 2021-05-11 (Simon Zeni)

  - Initial draft

#### VK_EXT_acquire_xlib_display

Name String

  `VK_EXT_acquire_xlib_display`

Extension Type

  Instance extension

Registered Extension Number

  90

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_direct_mode_display` to be enabled

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-12-13

IP Status

  No known IP claims.

Contributors

  - Dave Airlie, Red Hat

  - Pierre Boudier, NVIDIA

  - James Jones, NVIDIA

  - Damien Leone, NVIDIA

  - Pierre-Loup Griffais, Valve

  - Liam Middlebrook, NVIDIA

  - Daniel Vetter, Intel

#### Description

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

#### New Commands

- vkAcquireXlibDisplayEXT

- vkGetRandROutputDisplayEXT

#### New Enum Constants

- `VK_EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME`

- `VK_EXT_ACQUIRE_XLIB_DISPLAY_SPEC_VERSION`

#### Issues

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

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

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

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

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

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

#### Version History

- Revision 1, 2016-12-13 (James Jones)

  - Initial draft

#### VK_EXT_astc_decode_mode

Name String

  `VK_EXT_astc_decode_mode`

Extension Type

  Device extension

Registered Extension Number

  68

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### Other Extension Metadata

Last Modified Date

  2018-08-07

Contributors

  - Jan-Harald Fredriksen, Arm

#### Description

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

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

Three decoding options are provided:

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

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

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

#### New Structures

- Extending VkImageViewCreateInfo:

  - VkImageViewASTCDecodeModeEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceASTCDecodeFeaturesEXT

#### New Enum Constants

- `VK_EXT_ASTC_DECODE_MODE_EXTENSION_NAME`

- `VK_EXT_ASTC_DECODE_MODE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT`

#### Issues

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

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

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

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

#### Example

Create an image view that decodes to `VK_FORMAT_R8G8B8A8_UNORM` precision:

        VkImageViewASTCDecodeModeEXT decodeMode =
        {
            VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT, // sType
            NULL, // pNext
            VK_FORMAT_R8G8B8A8_UNORM // decode mode
        };

        VkImageViewCreateInfo createInfo =
        {
            VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO, // sType
            &decodeMode, // pNext
            // flags, image, viewType set to application-desired values
            VK_FORMAT_ASTC_8x8_UNORM_BLOCK, // format
            // 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Joshua Ashton Joshua-Ashton

Extension Proposal

  VK_EXT_attachment_feedback_loop_layout

#### Other Extension Metadata

Last Modified Date

  2022-04-04

IP Status

  No known IP claims.

Contributors

  - Joshua Ashton, Valve

  - Jason Ekstrand, Collabora

  - Bas Nieuwenhuizen, Google

  - Samuel Iglesias Gonsálvez, Igalia

  - Ralph Potter, Samsung

  - Jan-Harald Fredriksen, Arm

  - Ricardo Garcia, Igalia

#### Description

This extension adds a new image layout, `VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT`, which allows applications to have an image layout in which they are able to both render to and sample/fetch from the same subresource of an image in a given render pass.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceAttachmentFeedbackLoopLayoutFeaturesEXT

#### New Enum Constants

- `VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_EXTENSION_NAME`

- `VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_SPEC_VERSION`

- Extending VkDependencyFlagBits:

  - `VK_DEPENDENCY_FEEDBACK_LOOP_BIT_EXT`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_COLOR_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT`

  - `VK_PIPELINE_CREATE_DEPTH_STENCIL_ATTACHMENT_FEEDBACK_LOOP_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_FEATURES_EXT`

#### Version History

- Revision 2, 2022-04-04 (Joshua Ashton)

  - Renamed from VALVE to EXT.

- Revision 1, 2021-03-09 (Joshua Ashton)

  - Initial draft.

#### VK_EXT_blend_operation_advanced

Name String

  `VK_EXT_blend_operation_advanced`

Extension Type

  Device extension

Registered Extension Number

  149

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-06-12

Contributors

  - Jeff Bolz, NVIDIA

#### Description

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

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

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

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

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

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

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceBlendOperationAdvancedFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceBlendOperationAdvancedPropertiesEXT

- Extending VkPipelineColorBlendStateCreateInfo:

  - VkPipelineColorBlendAdvancedStateCreateInfoEXT

#### New Enums

- VkBlendOverlapEXT

#### New Enum Constants

- `VK_EXT_BLEND_OPERATION_ADVANCED_EXTENSION_NAME`

- `VK_EXT_BLEND_OPERATION_ADVANCED_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT`

- Extending VkBlendOp:

  - `VK_BLEND_OP_BLUE_EXT`

  - `VK_BLEND_OP_COLORBURN_EXT`

  - `VK_BLEND_OP_COLORDODGE_EXT`

  - `VK_BLEND_OP_CONTRAST_EXT`

  - `VK_BLEND_OP_DARKEN_EXT`

  - `VK_BLEND_OP_DIFFERENCE_EXT`

  - `VK_BLEND_OP_DST_ATOP_EXT`

  - `VK_BLEND_OP_DST_EXT`

  - `VK_BLEND_OP_DST_IN_EXT`

  - `VK_BLEND_OP_DST_OUT_EXT`

  - `VK_BLEND_OP_DST_OVER_EXT`

  - `VK_BLEND_OP_EXCLUSION_EXT`

  - `VK_BLEND_OP_GREEN_EXT`

  - `VK_BLEND_OP_HARDLIGHT_EXT`

  - `VK_BLEND_OP_HARDMIX_EXT`

  - `VK_BLEND_OP_HSL_COLOR_EXT`

  - `VK_BLEND_OP_HSL_HUE_EXT`

  - `VK_BLEND_OP_HSL_LUMINOSITY_EXT`

  - `VK_BLEND_OP_HSL_SATURATION_EXT`

  - `VK_BLEND_OP_INVERT_EXT`

  - `VK_BLEND_OP_INVERT_OVG_EXT`

  - `VK_BLEND_OP_INVERT_RGB_EXT`

  - `VK_BLEND_OP_LIGHTEN_EXT`

  - `VK_BLEND_OP_LINEARBURN_EXT`

  - `VK_BLEND_OP_LINEARDODGE_EXT`

  - `VK_BLEND_OP_LINEARLIGHT_EXT`

  - `VK_BLEND_OP_MINUS_CLAMPED_EXT`

  - `VK_BLEND_OP_MINUS_EXT`

  - `VK_BLEND_OP_MULTIPLY_EXT`

  - `VK_BLEND_OP_OVERLAY_EXT`

  - `VK_BLEND_OP_PINLIGHT_EXT`

  - `VK_BLEND_OP_PLUS_CLAMPED_ALPHA_EXT`

  - `VK_BLEND_OP_PLUS_CLAMPED_EXT`

  - `VK_BLEND_OP_PLUS_DARKER_EXT`

  - `VK_BLEND_OP_PLUS_EXT`

  - `VK_BLEND_OP_RED_EXT`

  - `VK_BLEND_OP_SCREEN_EXT`

  - `VK_BLEND_OP_SOFTLIGHT_EXT`

  - `VK_BLEND_OP_SRC_ATOP_EXT`

  - `VK_BLEND_OP_SRC_EXT`

  - `VK_BLEND_OP_SRC_IN_EXT`

  - `VK_BLEND_OP_SRC_OUT_EXT`

  - `VK_BLEND_OP_SRC_OVER_EXT`

  - `VK_BLEND_OP_VIVIDLIGHT_EXT`

  - `VK_BLEND_OP_XOR_EXT`

  - `VK_BLEND_OP_ZERO_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BLEND_OPERATION_ADVANCED_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT`

#### Issues

None.

#### Version History

- Revision 1, 2017-06-12 (Jeff Bolz)

  - Internal revisions

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

  - Internal revisions

#### VK_EXT_border_color_swizzle

Name String

  `VK_EXT_border_color_swizzle`

Extension Type

  Device extension

Registered Extension Number

  412

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_custom_border_color` to be enabled for any device-level functionality

Special Uses

  - OpenGL / ES support

  - D3D support

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2021-10-12

IP Status

  No known IP claims.

Contributors

  - Graeme Leese, Broadcom

  - Jan-Harald Fredriksen, Arm

  - Ricardo Garcia, Igalia

  - Shahbaz Youssefi, Google

  - Stu Smith, AMD

#### Description

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

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceBorderColorSwizzleFeaturesEXT

- Extending VkSamplerCreateInfo:

  - VkSamplerBorderColorComponentMappingCreateInfoEXT

#### New Enum Constants

- `VK_EXT_BORDER_COLOR_SWIZZLE_EXTENSION_NAME`

- `VK_EXT_BORDER_COLOR_SWIZZLE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BORDER_COLOR_SWIZZLE_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_SAMPLER_BORDER_COLOR_COMPONENT_MAPPING_CREATE_INFO_EXT`

#### Issues

None.

#### Version History

- Revision 1, 2021-10-12 (Piers Daniell)

  - Internal revisions.

#### VK_EXT_calibrated_timestamps

Name String

  `VK_EXT_calibrated_timestamps`

Extension Type

  Device extension

Registered Extension Number

  185

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Daniel Rakos drakos-amd

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

  - Jason Ekstrand, Intel

  - Keith Packard, Valve

#### Description

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

#### New Commands

- vkGetCalibratedTimestampsEXT

- vkGetPhysicalDeviceCalibrateableTimeDomainsEXT

#### New Structures

- VkCalibratedTimestampInfoEXT

#### New Enums

- VkTimeDomainEXT

#### New Enum Constants

- `VK_EXT_CALIBRATED_TIMESTAMPS_EXTENSION_NAME`

- `VK_EXT_CALIBRATED_TIMESTAMPS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_CALIBRATED_TIMESTAMP_INFO_EXT`

#### Issues

1) Is the device timestamp value returned in the same time domain as the timestamp values written by vkCmdWriteTimestamp?

RESOLVED: Yes.

2) What time domain is the host timestamp returned in?

RESOLVED: A query is provided to determine the calibrateable time domains. The expected host time domain used on Windows is that of QueryPerformanceCounter, and on Linux that of CLOCK_MONOTONIC.

3) Should we support other time domain combinations than just one host and the device time domain?

RESOLVED: Supporting that would need the application to query the set of supported time domains, while supporting only one host and the device time domain would only need a query for the host time domain type. The proposed API chooses the general approach for the sake of extensibility.

4) Should we use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC?

RESOLVED: CLOCK_MONOTONIC is usable in a wider set of situations, however, it is subject to NTP adjustments so some use cases may prefer CLOCK_MONOTONIC_RAW. Thus this extension allows both to be exposed.

5) How can the application extrapolate future device timestamp values from the calibrated timestamp value?

RESOLVED: VkPhysicalDeviceLimits::`timestampPeriod` makes it possible to calculate future device timestamps as follows:

6) In what queue are timestamp values in time domain `VK_TIME_DOMAIN_DEVICE_EXT` captured by vkGetCalibratedTimestampsEXT?

RESOLVED: An implementation supporting this extension will have all its VkQueue share the same time domain.

    futureTimestamp = calibratedTimestamp + deltaNanoseconds / timestampPeriod

6) Can the host and device timestamp values drift apart over longer periods of time?

RESOLVED: Yes, especially as some time domains by definition allow for that to happen (e.g. CLOCK_MONOTONIC is subject to NTP adjustments). Thus it is recommended that applications re-calibrate from time to time.

7) Should we add a query for reporting the maximum deviation of the timestamp values returned by calibrated timestamp queries?

RESOLVED: A global query seems inappropriate and difficult to enforce. However, it is possible to return the maximum deviation any single calibrated timestamp query can have by sampling one of the time domains twice as follows:

    timestampX = timestampX_before = SampleTimeDomain(X)
    for each time domain Y != X
        timestampY = SampleTimeDomain(Y)
    timestampX_after = SampleTimeDomain(X)
    maxDeviation = timestampX_after - timestampX_before

8) Can the maximum deviation reported ever be zero?

RESOLVED: Unless the tick of each clock corresponding to the set of time domains coincides and all clocks can literally be sampled simultaneously, there is not really a possibility for the maximum deviation to be zero, so by convention the maximum deviation is always at least the maximum of the length of the ticks of the set of time domains calibrated and thus can never be zero.

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Sharif Elcott selcott

#### Other Extension Metadata

Last Modified Date

  2020-02-25

IP Status

  No known IP claims.

Contributors

  - Sharif Elcott, Google

  - Tobias Hector, AMD

  - Piers Daniell, NVIDIA

#### Description

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

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

#### New Commands

- vkCmdSetColorWriteEnableEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceColorWriteEnableFeaturesEXT

- Extending VkPipelineColorBlendStateCreateInfo:

  - VkPipelineColorWriteCreateInfoEXT

#### New Enum Constants

- `VK_EXT_COLOR_WRITE_ENABLE_EXTENSION_NAME`

- `VK_EXT_COLOR_WRITE_ENABLE_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COLOR_WRITE_ENABLE_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_COLOR_WRITE_CREATE_INFO_EXT`

#### Version History

- Revision 1, 2020-01-25 (Sharif Elcott)

  - Internal revisions

#### VK_EXT_conditional_rendering

Name String

  `VK_EXT_conditional_rendering`

Extension Type

  Device extension

Registered Extension Number

  82

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Vikram Kushwaha vkushwaha

#### Other Extension Metadata

Last Modified Date

  2018-05-21

IP Status

  No known IP claims.

Contributors

  - Vikram Kushwaha, NVIDIA

  - Daniel Rakos, AMD

  - Jesse Hall, Google

  - Jeff Bolz, NVIDIA

  - Piers Daniell, NVIDIA

  - Stuart Smith, Imagination Technologies

#### Description

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

#### New Commands

- vkCmdBeginConditionalRenderingEXT

- vkCmdEndConditionalRenderingEXT

#### New Structures

- VkConditionalRenderingBeginInfoEXT

- Extending VkCommandBufferInheritanceInfo:

  - VkCommandBufferInheritanceConditionalRenderingInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceConditionalRenderingFeaturesEXT

#### New Enums

- VkConditionalRenderingFlagBitsEXT

#### New Bitmasks

- VkConditionalRenderingFlagsEXT

#### New Enum Constants

- `VK_EXT_CONDITIONAL_RENDERING_EXTENSION_NAME`

- `VK_EXT_CONDITIONAL_RENDERING_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_CONDITIONAL_RENDERING_READ_BIT_EXT`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_CONDITIONAL_RENDERING_BIT_EXT`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_CONDITIONAL_RENDERING_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_CONDITIONAL_RENDERING_INFO_EXT`

  - `VK_STRUCTURE_TYPE_CONDITIONAL_RENDERING_BEGIN_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONDITIONAL_RENDERING_FEATURES_EXT`

#### Issues

1) Should conditional rendering affect copy and blit commands?

RESOLVED: Conditional rendering should not affect copies and blits.

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

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

#### Examples

None.

#### Version History

- Revision 1, 2018-04-19 (Vikram Kushwaha)

  - First Version

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

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

#### VK_EXT_conservative_rasterization

Name String

  `VK_EXT_conservative_rasterization`

Extension Type

  Device extension

Registered Extension Number

  102

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2020-06-09

Interactions and External Dependencies

  - This extension requires `SPV_EXT_fragment_fully_covered` if the `VkPhysicalDeviceConservativeRasterizationPropertiesEXT`::`fullyCoveredFragmentShaderInputVariable` feature is used.

  - This extension requires `SPV_KHR_post_depth_coverage`if the `VkPhysicalDeviceConservativeRasterizationPropertiesEXT`::`conservativeRasterizationPostDepthCoverage` feature is used.

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

Contributors

  - Daniel Koch, NVIDIA

  - Daniel Rakos, AMD

  - Jeff Bolz, NVIDIA

  - Slawomir Grajewski, Intel

  - Stu Smith, Imagination Technologies

#### Description

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

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

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

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

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceConservativeRasterizationPropertiesEXT

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationConservativeStateCreateInfoEXT

#### New Enums

- VkConservativeRasterizationModeEXT

#### New Bitmasks

- VkPipelineRasterizationConservativeStateCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_CONSERVATIVE_RASTERIZATION_EXTENSION_NAME`

- `VK_EXT_CONSERVATIVE_RASTERIZATION_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CONSERVATIVE_RASTERIZATION_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_CONSERVATIVE_STATE_CREATE_INFO_EXT`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Uses

  - OpenGL / ES support

  - D3D support

Contact

  - Liam Middlebrook liam-middlebrook

#### Other Extension Metadata

Last Modified Date

  2020-04-16

IP Status

  No known IP claims.

Contributors

  - Joshua Ashton, Valve

  - Hans-Kristian Arntzen, Valve

  - Philip Rebohle, Valve

  - Liam Middlebrook, NVIDIA

  - Jeff Bolz, NVIDIA

  - Tobias Hector, AMD

  - Jason Ekstrand, Intel

  - Spencer Fricke, Samsung Electronics

  - Graeme Leese, Broadcom

  - Jesse Hall, Google

  - Jan-Harald Fredriksen, ARM

  - Tom Olson, ARM

  - Stuart Smith, Imagination Technologies

  - Donald Scorgie, Imagination Technologies

  - Alex Walters, Imagination Technologies

  - Peter Quayle, Imagination Technologies

#### Description

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

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

- `VK_BORDER_COLOR_FLOAT_CUSTOM_EXT`

- `VK_BORDER_COLOR_INT_CUSTOM_EXT`

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceCustomBorderColorFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceCustomBorderColorPropertiesEXT

- Extending VkSamplerCreateInfo:

  - VkSamplerCustomBorderColorCreateInfoEXT

#### New Enum Constants

- `VK_EXT_CUSTOM_BORDER_COLOR_EXTENSION_NAME`

- `VK_EXT_CUSTOM_BORDER_COLOR_SPEC_VERSION`

- Extending VkBorderColor:

  - `VK_BORDER_COLOR_FLOAT_CUSTOM_EXT`

  - `VK_BORDER_COLOR_INT_CUSTOM_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CUSTOM_BORDER_COLOR_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_SAMPLER_CUSTOM_BORDER_COLOR_CREATE_INFO_EXT`

#### Issues

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

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

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

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

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

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

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

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

#### Version History

- Revision 1, 2019-10-10 (Joshua Ashton)

  - Internal revisions.

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

  - Remove VkCustomBorderColor object and associated functions

  - Add issues concerning HW limitations for custom border color count

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

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

  - Add extra details about border color tracking

  - Fix typos

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

  - Changed maxUniqueCustomBorderColors to a uint32_t from a VkDeviceSize

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

  - Added features bit

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

  - Type-ize VK_BORDER_COLOR_CUSTOM

  - Fix const-ness on `pNext` of VkSamplerCustomBorderColorCreateInfoEXT

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

  - Renamed maxUniqueCustomBorderColors to maxCustomBorderColors

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

  - Renamed borderColor member of VkSamplerCustomBorderColorCreateInfoEXT to customBorderColor

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

  - Renamed maxCustomBorderColors to maxCustomBorderColorSamplers

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

  - Added format to VkSamplerCustomBorderColorCreateInfoEXT and feature bit

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

  - Dropped UINT/SINT border color differences, consolidated types

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

  - Renamed VK_BORDER_COLOR_CUSTOM_FLOAT_EXT to VK_BORDER_COLOR_FLOAT_CUSTOM_EXT for consistency

#### VK_EXT_debug_utils

Name String

  `VK_EXT_debug_utils`

Extension Type

  Instance extension

Registered Extension Number

  129

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - Debugging tools

Contact

  - Mark Young marky-lunarg

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

- VkDebugUtilsMessengerEXT

#### New Commands

- vkCmdBeginDebugUtilsLabelEXT

- vkCmdEndDebugUtilsLabelEXT

- vkCmdInsertDebugUtilsLabelEXT

- vkCreateDebugUtilsMessengerEXT

- vkDestroyDebugUtilsMessengerEXT

- vkQueueBeginDebugUtilsLabelEXT

- vkQueueEndDebugUtilsLabelEXT

- vkQueueInsertDebugUtilsLabelEXT

- vkSetDebugUtilsObjectNameEXT

- vkSetDebugUtilsObjectTagEXT

- vkSubmitDebugUtilsMessageEXT

#### New Structures

- VkDebugUtilsLabelEXT

- VkDebugUtilsMessengerCallbackDataEXT

- VkDebugUtilsObjectTagInfoEXT

- Extending VkInstanceCreateInfo:

  - VkDebugUtilsMessengerCreateInfoEXT

- Extending VkPipelineShaderStageCreateInfo:

  - VkDebugUtilsObjectNameInfoEXT

#### New Function Pointers

- PFN_vkDebugUtilsMessengerCallbackEXT

#### New Enums

- VkDebugUtilsMessageSeverityFlagBitsEXT

- VkDebugUtilsMessageTypeFlagBitsEXT

#### New Bitmasks

- VkDebugUtilsMessageSeverityFlagsEXT

- VkDebugUtilsMessageTypeFlagsEXT

- VkDebugUtilsMessengerCallbackDataFlagsEXT

- VkDebugUtilsMessengerCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_DEBUG_UTILS_EXTENSION_NAME`

- `VK_EXT_DEBUG_UTILS_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_DEBUG_UTILS_MESSENGER_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CALLBACK_DATA_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_TAG_INFO_EXT`

#### Examples

Example 1

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

To capture events that occur while creating or destroying an instance an application can link a VkDebugUtilsMessengerCreateInfoEXT structure to the `pNext` 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 = {
                VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,  // sType
                NULL,                                                     // pNext
                0,                                                        // flags
                VK_DEBUG_UTILS_MESSAGE_SEVERITY_ERROR_BIT_EXT |           // messageSeverity
                VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,
                VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |             // messageType
                VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
                myOutputDebugString,                                      // pfnUserCallback
                NULL                                                      // pUserData
        };
        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 = {
                VK_STRUCTURE_TYPE_DEBUG_UTILS_MESSENGER_CREATE_INFO_EXT,  // sType
                NULL,                                                     // pNext
                0,                                                        // flags
                VK_DEBUG_UTILS_MESSAGE_SEVERITY_WARNING_BIT_EXT,          // messageSeverity
                VK_DEBUG_UTILS_MESSAGE_TYPE_GENERAL_BIT_EXT |             // messageType
                VK_DEBUG_UTILS_MESSAGE_TYPE_VALIDATION_BIT_EXT,
                mystdOutLogger,                                           // pfnUserCallback
                NULL                                                      // pUserData
        };
        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 =
        {
            VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT, // sType
            NULL,                                               // pNext
            VK_OBJECT_TYPE_IMAGE,                               // objectType
            (uint64_t)image,                                    // objectHandle
            "Brick Diffuse Texture",                            // pObjectName
        };

        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 =
        {
            VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT, // sType
            NULL,                                    // pNext
            "Brick House",                           // pLabelName
            { 1.0f, 0.0f, 0.0f, 1.0f },              // color
        };

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

            // 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 =
        {
            VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT, // sType
            NULL,                                    // pNext
            "Main Render Work",                      // pLabelName
            { 0.0f, 1.0f, 0.0f, 1.0f },              // color
        };

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

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

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

#### Issues

1) Should we just name this extension `VK_EXT_debug_report2`

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

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

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

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

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

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

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

#### Version History

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

  - Initial draft, based on `VK_EXT_debug_report` and `VK_EXT_debug_marker` in addition to previous feedback supplied from various companies including Valve, Epic, and Oxide games.

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

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

#### VK_EXT_depth_clamp_zero_one

Name String

  `VK_EXT_depth_clamp_zero_one`

Extension Type

  Device extension

Registered Extension Number

  422

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Graeme Leese gnl21

#### Other Extension Metadata

Last Modified Date

  2021-07-29

Contributors

  - Graeme Leese, Broadcom

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDepthClampZeroOneFeaturesEXT

#### New Enum Constants

- `VK_EXT_DEPTH_CLAMP_ZERO_ONE_EXTENSION_NAME`

- `VK_EXT_DEPTH_CLAMP_ZERO_ONE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLAMP_ZERO_ONE_FEATURES_EXT`

#### Version History

- Revision 1, 2021-07-29 (Graeme Leese)

  - Internal revisions

#### VK_EXT_depth_clip_control

Name String

  `VK_EXT_depth_clip_control`

Extension Type

  Device extension

Registered Extension Number

  356

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - OpenGL / ES support

Contact

  - Shahbaz Youssefi syoussefi

#### Other Extension Metadata

Last Modified Date

  2021-11-09

Contributors

  - Spencer Fricke, Samsung Electronics

  - Shahbaz Youssefi, Google

  - Ralph Potter, Samsung Electronics

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDepthClipControlFeaturesEXT

- Extending VkPipelineViewportStateCreateInfo:

  - VkPipelineViewportDepthClipControlCreateInfoEXT

#### New Enum Constants

- `VK_EXT_DEPTH_CLIP_CONTROL_EXTENSION_NAME`

- `VK_EXT_DEPTH_CLIP_CONTROL_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_CONTROL_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_DEPTH_CLIP_CONTROL_CREATE_INFO_EXT`

#### Issues

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

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

2) Should this pipeline state be dynamic?

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

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

RESOLVED: No. It is highly unlikely that the depth range is changed to anything other than [0, 1] in the future. Should that happen a new extension will be required to extend such an enum, and that extension might as well add a new 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - D3D support

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2018-12-20

Contributors

  - Daniel Rakos, AMD

  - Henri Verbeet, CodeWeavers

  - Jeff Bolz, NVIDIA

  - Philip Rebohle, DXVK

  - Tobias Hector, AMD

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDepthClipEnableFeaturesEXT

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationDepthClipStateCreateInfoEXT

#### New Bitmasks

- VkPipelineRasterizationDepthClipStateCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_DEPTH_CLIP_ENABLE_EXTENSION_NAME`

- `VK_EXT_DEPTH_CLIP_ENABLE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_DEPTH_CLIP_STATE_CREATE_INFO_EXT`

#### Version History

- Revision 1, 2018-12-20 (Piers Daniell)

  - Internal revisions

#### VK_EXT_depth_range_unrestricted

Name String

  `VK_EXT_depth_range_unrestricted`

Extension Type

  Device extension

Registered Extension Number

  14

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2017-06-22

Contributors

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

#### New Enum Constants

- `VK_EXT_DEPTH_RANGE_UNRESTRICTED_EXTENSION_NAME`

- `VK_EXT_DEPTH_RANGE_UNRESTRICTED_SPEC_VERSION`

#### Issues

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

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

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

RESOLVED: This situation can also arise without this extension (when fragment shaders replace depth values, for example), and this extension does not change the 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_device_memory_report

Name String

  `VK_EXT_device_memory_report`

Extension Type

  Device extension

Registered Extension Number

  285

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - Developer tools

Contact

  - Yiwei Zhang zhangyiwei

#### Other Extension Metadata

Last Modified Date

  2021-01-06

IP Status

  No known IP claims.

Contributors

  - Yiwei Zhang, Google

  - Jesse Hall, Google

#### Description

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

#### New Structures

- VkDeviceMemoryReportCallbackDataEXT

- Extending VkDeviceCreateInfo:

  - VkDeviceDeviceMemoryReportCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDeviceMemoryReportFeaturesEXT

#### New Function Pointers

- PFN_vkDeviceMemoryReportCallbackEXT

#### New Enums

- VkDeviceMemoryReportEventTypeEXT

#### New Bitmasks

- VkDeviceMemoryReportFlagsEXT

#### New Enum Constants

- `VK_EXT_DEVICE_MEMORY_REPORT_EXTENSION_NAME`

- `VK_EXT_DEVICE_MEMORY_REPORT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_DEVICE_MEMORY_REPORT_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEVICE_MEMORY_REPORT_CALLBACK_DATA_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_MEMORY_REPORT_FEATURES_EXT`

#### Issues

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

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

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

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

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

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

The callbacks are clearly specified as only callable within the context of a call from the 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_display` to be enabled

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-12-13

IP Status

  No known IP claims.

Contributors

  - Pierre Boudier, NVIDIA

  - James Jones, NVIDIA

  - Damien Leone, NVIDIA

  - Pierre-Loup Griffais, Valve

  - Liam Middlebrook, NVIDIA

#### Description

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

#### New Commands

- vkReleaseDisplayEXT

#### New Enum Constants

- `VK_EXT_DIRECT_MODE_DISPLAY_EXTENSION_NAME`

- `VK_EXT_DIRECT_MODE_DISPLAY_SPEC_VERSION`

#### Issues

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

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

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

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

#### Version History

- Revision 1, 2016-12-13 (James Jones)

  - Initial draft

#### VK_EXT_directfb_surface

Name String

  `VK_EXT_directfb_surface`

Extension Type

  Instance extension

Registered Extension Number

  347

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Nicolas Caramelli caramelli

#### Other Extension Metadata

Last Modified Date

  2020-06-16

IP Status

  No known IP claims.

Contributors

  - Nicolas Caramelli

#### Description

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

#### New Commands

- vkCreateDirectFBSurfaceEXT

- vkGetPhysicalDeviceDirectFBPresentationSupportEXT

#### New Structures

- VkDirectFBSurfaceCreateInfoEXT

#### New Bitmasks

- VkDirectFBSurfaceCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_DIRECTFB_SURFACE_EXTENSION_NAME`

- `VK_EXT_DIRECTFB_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DIRECTFB_SURFACE_CREATE_INFO_EXT`

#### Version History

- Revision 1, 2020-06-16 (Nicolas Caramelli)

  - Initial version

#### VK_EXT_discard_rectangles

Name String

  `VK_EXT_discard_rectangles`

Extension Type

  Device extension

Registered Extension Number

  100

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2016-12-22

Interactions and External Dependencies

  - Interacts with `VK_KHR_device_group`

  - Interacts with Vulkan 1.1

Contributors

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

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

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

#### New Commands

- vkCmdSetDiscardRectangleEXT

#### New Structures

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineDiscardRectangleStateCreateInfoEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDiscardRectanglePropertiesEXT

#### New Enums

- VkDiscardRectangleModeEXT

#### New Bitmasks

- VkPipelineDiscardRectangleStateCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_DISCARD_RECTANGLES_EXTENSION_NAME`

- `VK_EXT_DISCARD_RECTANGLES_SPEC_VERSION`

- Extending VkDynamicState:

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_display_surface_counter` to be enabled for any device-level functionality

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-12-13

IP Status

  No known IP claims.

Contributors

  - Pierre Boudier, NVIDIA

  - James Jones, NVIDIA

  - Damien Leone, NVIDIA

  - Pierre-Loup Griffais, Valve

  - Daniel Vetter, Intel

#### Description

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

#### New Commands

- vkDisplayPowerControlEXT

- vkGetSwapchainCounterEXT

- vkRegisterDeviceEventEXT

- vkRegisterDisplayEventEXT

#### New Structures

- VkDeviceEventInfoEXT

- VkDisplayEventInfoEXT

- VkDisplayPowerInfoEXT

- Extending VkSwapchainCreateInfoKHR:

  - VkSwapchainCounterCreateInfoEXT

#### New Enums

- VkDeviceEventTypeEXT

- VkDisplayEventTypeEXT

- VkDisplayPowerStateEXT

#### New Enum Constants

- `VK_EXT_DISPLAY_CONTROL_EXTENSION_NAME`

- `VK_EXT_DISPLAY_CONTROL_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_EVENT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DISPLAY_EVENT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DISPLAY_POWER_INFO_EXT`

  - `VK_STRUCTURE_TYPE_SWAPCHAIN_COUNTER_CREATE_INFO_EXT`

#### Issues

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

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

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

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

3) Should vblank or scanline events be exposed?

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

#### Version History

- Revision 1, 2016-12-13 (James Jones)

  - Initial draft

#### VK_EXT_display_surface_counter

Name String

  `VK_EXT_display_surface_counter`

Extension Type

  Instance extension

Registered Extension Number

  91

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_display` to be enabled

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-12-13

IP Status

  No known IP claims.

Contributors

  - Pierre Boudier, NVIDIA

  - James Jones, NVIDIA

  - Damien Leone, NVIDIA

  - Pierre-Loup Griffais, Valve

  - Daniel Vetter, Intel

#### Description

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

#### New Commands

- vkGetPhysicalDeviceSurfaceCapabilities2EXT

#### New Structures

- VkSurfaceCapabilities2EXT

#### New Enums

- VkSurfaceCounterFlagBitsEXT

#### New Bitmasks

- VkSurfaceCounterFlagsEXT

#### New Enum Constants

- `VK_EXT_DISPLAY_SURFACE_COUNTER_EXTENSION_NAME`

- `VK_EXT_DISPLAY_SURFACE_COUNTER_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT`

  - `VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT`

#### Version History

- Revision 1, 2016-12-13 (James Jones)

  - Initial draft

#### VK_EXT_external_memory_dma_buf

Name String

  `VK_EXT_external_memory_dma_buf`

Extension Type

  Device extension

Registered Extension Number

  126

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory_fd` to be enabled for any device-level functionality

Contact

  - Chad Versace chadversary

#### Other Extension Metadata

Last Modified Date

  2017-10-10

IP Status

  No known IP claims.

Contributors

  - Chad Versace, Google

  - James Jones, NVIDIA

  - Jason 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 (Chad 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - Daniel Rakos drakos-amd

#### Other Extension Metadata

Last Modified Date

  2017-11-10

IP Status

  No known IP claims.

Contributors

  - Jaakko Konttinen, AMD

  - David Mao, AMD

  - Daniel Rakos, AMD

  - Tobias Hector, Imagination Technologies

  - Jason Ekstrand, Intel

  - James Jones, NVIDIA

#### Description

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

#### New Commands

- vkGetMemoryHostPointerPropertiesEXT

#### New Structures

- VkMemoryHostPointerPropertiesEXT

- Extending VkMemoryAllocateInfo:

  - VkImportMemoryHostPointerInfoEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceExternalMemoryHostPropertiesEXT

#### New Enum Constants

- `VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME`

- `VK_EXT_EXTERNAL_MEMORY_HOST_SPEC_VERSION`

- Extending VkExternalMemoryHandleTypeFlagBits:

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_ALLOCATION_BIT_EXT`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_HOST_MAPPED_FOREIGN_MEMORY_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMPORT_MEMORY_HOST_POINTER_INFO_EXT`

  - `VK_STRUCTURE_TYPE_MEMORY_HOST_POINTER_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_HOST_PROPERTIES_EXT`

#### Issues

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

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

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

RESOLVED: Yes. However, usual synchronization requirements apply.

3) Can the application free the host allocation?

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

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

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

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

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

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

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

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

RESOLVED: No.

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

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

#### Version History

- Revision 1, 2017-11-10 (Daniel Rakos)

  - Internal revisions

#### VK_EXT_filter_cubic

Name String

  `VK_EXT_filter_cubic`

Extension Type

  Device extension

Registered Extension Number

  171

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

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-Herald Fredericksen, ARM

  - Jeff Leger, Qualcomm Technologies, Inc.

  - Tobias Hector, AMD

  - Tom Olson, ARM

  - Stuart Smith, Imagination Technologies

#### Description

`VK_EXT_filter_cubic` extends `VK_IMG_filter_cubic`.

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

#### New Structures

- Extending VkImageFormatProperties2:

  - VkFilterCubicImageViewImageFormatPropertiesEXT

- Extending VkPhysicalDeviceImageFormatInfo2:

  - VkPhysicalDeviceImageViewImageFormatInfoEXT

#### New Enum Constants

- `VK_EXT_FILTER_CUBIC_EXTENSION_NAME`

- `VK_EXT_FILTER_CUBIC_SPEC_VERSION`

- Extending VkFilter:

  - `VK_FILTER_CUBIC_EXT`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FILTER_CUBIC_IMAGE_VIEW_IMAGE_FORMAT_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_IMAGE_FORMAT_INFO_EXT`

#### Version History

- Revision 3, 2019-12-13 (wwlk)

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

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

  - Clarify 1D optional

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

  - Initial version

#### VK_EXT_fragment_density_map

Name String

  `VK_EXT_fragment_density_map`

Extension Type

  Device extension

Registered Extension Number

  219

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Matthew Netsch mnetsch

#### Other Extension Metadata

Last Modified Date

  2021-09-30

Interactions and External Dependencies

  - This extension requires `SPV_EXT_fragment_invocation_density`

  - This extension provides API support for `GL_EXT_fragment_invocation_density`

Contributors

  - Matthew Netsch, Qualcomm Technologies, Inc.

  - Robert VanReenen, Qualcomm Technologies, Inc.

  - Jonathan Wicks, Qualcomm Technologies, Inc.

  - Tate Hornbeck, Qualcomm Technologies, Inc.

  - Sam Holmes, Qualcomm Technologies, Inc.

  - Jeff Leger, Qualcomm Technologies, Inc.

  - Jan-Harald Fredriksen, ARM

  - Jeff Bolz, NVIDIA

  - Pat Brown, NVIDIA

  - Daniel Rakos, AMD

  - Piers Daniell, NVIDIA

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentDensityMapFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentDensityMapPropertiesEXT

- Extending VkRenderPassCreateInfo, VkRenderPassCreateInfo2:

  - VkRenderPassFragmentDensityMapCreateInfoEXT

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

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXT`

#### New or Modified Built-In Variables

- `FragInvocationCountEXT`

- `FragSizeEXT`

#### New SPIR-V Capabilities

- `FragmentDensityEXT`

#### Version History

- Revision 1, 2018-09-25 (Matthew Netsch)

  - Initial version

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

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

#### VK_EXT_fragment_density_map2

Name String

  `VK_EXT_fragment_density_map2`

Extension Type

  Device extension

Registered Extension Number

  333

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_fragment_density_map` to be enabled for any device-level functionality

Contact

  - Matthew Netsch mnetsch

#### Other Extension Metadata

Last Modified Date

  2020-06-16

Interactions and External Dependencies

  - Interacts with Vulkan 1.1

Contributors

  - Matthew Netsch, Qualcomm Technologies, Inc.

  - Jonathan Tinkham, Qualcomm Technologies, Inc.

  - Jonathan Wicks, Qualcomm Technologies, Inc.

  - Jan-Harald Fredriksen, ARM

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentDensityMap2FeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentDensityMap2PropertiesEXT

#### New Enum Constants

- `VK_EXT_FRAGMENT_DENSITY_MAP_2_EXTENSION_NAME`

- `VK_EXT_FRAGMENT_DENSITY_MAP_2_SPEC_VERSION`

- Extending VkImageViewCreateFlagBits:

  - `VK_IMAGE_VIEW_CREATE_FRAGMENT_DENSITY_MAP_DEFERRED_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_2_PROPERTIES_EXT`

#### Version History

- Revision 1, 2020-06-16 (Matthew Netsch)

  - Initial version

#### VK_EXT_fragment_shader_interlock

Name String

  `VK_EXT_fragment_shader_interlock`

Extension Type

  Device extension

Registered Extension Number

  252

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2019-05-02

Interactions and External Dependencies

  - This extension requires `SPV_EXT_fragment_shader_interlock`

  - This extension provides API support for `GL_ARB_fragment_shader_interlock`

Contributors

  - Daniel Koch, NVIDIA

  - Graeme Leese, Broadcom

  - Jan-Harald Fredriksen, Arm

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Ruihao Zhang, Qualcomm

  - Slawomir Grajewski, Intel

  - Spencer Fricke, Samsung

#### Description

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

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShaderInterlockFeaturesEXT

#### New Enum Constants

- `VK_EXT_FRAGMENT_SHADER_INTERLOCK_EXTENSION_NAME`

- `VK_EXT_FRAGMENT_SHADER_INTERLOCK_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_INTERLOCK_FEATURES_EXT`

#### New SPIR-V Capabilities

- `FragmentShaderInterlockEXT`

- `FragmentShaderPixelInterlockEXT`

- `FragmentShaderShadingRateInterlockEXT`

#### Version History

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

  - Internal revisions

#### VK_EXT_full_screen_exclusive

Name String

  `VK_EXT_full_screen_exclusive`

Extension Type

  Device extension

Registered Extension Number

  256

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_surface` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_surface_capabilities2` to be enabled for any device-level functionality

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2019-03-12

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with Vulkan 1.1

  - Interacts with `VK_KHR_device_group`

  - Interacts with `VK_KHR_win32_surface`

Contributors

  - Hans-Kristian Arntzen, ARM

  - Slawomir Grajewski, Intel

  - Tobias Hector, AMD

  - James Jones, NVIDIA

  - Daniel Rakos, AMD

  - Jeff Juliano, NVIDIA

  - Joshua Schnarr, NVIDIA

  - Aaron Hagan, AMD

#### Description

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

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

#### New Commands

- vkAcquireFullScreenExclusiveModeEXT

- vkGetPhysicalDeviceSurfacePresentModes2EXT

- vkReleaseFullScreenExclusiveModeEXT

If VK_KHR_device_group is supported:

- vkGetDeviceGroupSurfacePresentModes2EXT

If Version 1.1 is supported:

- vkGetDeviceGroupSurfacePresentModes2EXT

#### New Structures

- Extending VkPhysicalDeviceSurfaceInfo2KHR, VkSwapchainCreateInfoKHR:

  - VkSurfaceFullScreenExclusiveInfoEXT

- Extending VkSurfaceCapabilities2KHR:

  - VkSurfaceCapabilitiesFullScreenExclusiveEXT

If VK_KHR_win32_surface is supported:

- Extending VkPhysicalDeviceSurfaceInfo2KHR, VkSwapchainCreateInfoKHR:

  - VkSurfaceFullScreenExclusiveWin32InfoEXT

#### New Enums

- VkFullScreenExclusiveEXT

#### New Enum Constants

- `VK_EXT_FULL_SCREEN_EXCLUSIVE_EXTENSION_NAME`

- `VK_EXT_FULL_SCREEN_EXCLUSIVE_SPEC_VERSION`

- Extending VkResult:

  - `VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_FULL_SCREEN_EXCLUSIVE_EXT`

  - `VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_INFO_EXT`

If VK_KHR_win32_surface is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SURFACE_FULL_SCREEN_EXCLUSIVE_WIN32_INFO_EXT`

#### Issues

1) What should the extension & flag be called?

RESOLVED: VK_EXT_full_screen_exclusive.

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

- VK_EXT_smooth_fullscreen_transition

- VK_EXT_fullscreen_behavior

- VK_EXT_fullscreen_preference

- VK_EXT_fullscreen_hint

- VK_EXT_fast_fullscreen_transition

- VK_EXT_avoid_fullscreen_exclusive

2) Do we need more than a boolean toggle?

RESOLVED: Yes.

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

3) Should this be a KHR or EXT extension?

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

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

RESOLVED: Yes on both accounts.

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

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

RESOLVED: Two words.

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

#### Version History

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

  - Added application-controlled mode, and related functions

  - Tidied up appendix

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

  - Renamed to VK_EXT_full_screen_exclusive

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

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

  - Renamed to VK_KHR_fullscreen_behavior

  - Switched from boolean flag to tri-state enum

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

  - Internal revision

#### VK_EXT_graphics_pipeline_library

Name String

  `VK_EXT_graphics_pipeline_library`

Extension Type

  Device extension

Registered Extension Number

  321

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_pipeline_library` to be enabled for any device-level functionality

Contact

  - Tobias Hector tobski

Extension Proposal

  VK_EXT_graphics_pipeline_library

#### Other Extension Metadata

Last Modified Date

  2021-08-17

Contributors

  - Tobias Hector, AMD

  - Chris Glover, Google

  - Jeff Leger, Qualcomm

  - Jan-Harald Fredriksen, Arm

  - Piers Daniell, NVidia

  - Boris Zanin, Mobica

  - Krzysztof Niski, NVidia

  - Dan Ginsburg, Valve

  - Sebastian Aaltonen, Unity

  - Arseny Kapoulkine, Roblox

  - Calle Lejdfors, Ubisoft

  - Tiago Rodrigues, Ubisoft

  - Francois Duranleau, Gameloft

#### Description

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

#### New Structures

- Extending VkGraphicsPipelineCreateInfo:

  - VkGraphicsPipelineLibraryCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceGraphicsPipelineLibraryFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceGraphicsPipelineLibraryPropertiesEXT

#### New Enums

- VkGraphicsPipelineLibraryFlagBitsEXT

- VkPipelineLayoutCreateFlagBits

#### New Bitmasks

- VkGraphicsPipelineLibraryFlagsEXT

#### New Enum Constants

- `VK_EXT_GRAPHICS_PIPELINE_LIBRARY_EXTENSION_NAME`

- `VK_EXT_GRAPHICS_PIPELINE_LIBRARY_SPEC_VERSION`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_LINK_TIME_OPTIMIZATION_BIT_EXT`

  - `VK_PIPELINE_CREATE_RETAIN_LINK_TIME_OPTIMIZATION_INFO_BIT_EXT`

- Extending VkPipelineLayoutCreateFlagBits:

  - `VK_PIPELINE_LAYOUT_CREATE_INDEPENDENT_SETS_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_LIBRARY_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GRAPHICS_PIPELINE_LIBRARY_PROPERTIES_EXT`

#### Version History

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

  - Initial draft.

#### VK_EXT_hdr_metadata

Name String

  `VK_EXT_hdr_metadata`

Extension Type

  Device extension

Registered Extension Number

  106

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - Courtney Goeltzenleuchter courtney-g

#### Other Extension Metadata

Last Modified Date

  2018-12-19

IP Status

  No known IP claims.

Contributors

  - Courtney Goeltzenleuchter, Google

#### Description

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

While the general 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

- vkSetHdrMetadataEXT

#### New Structures

- VkHdrMetadataEXT

- VkXYColorEXT

#### New Enum Constants

- `VK_EXT_HDR_METADATA_EXTENSION_NAME`

- `VK_EXT_HDR_METADATA_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_HDR_METADATA_EXT`

#### Issues

1) Do we need a query function?

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Lisa Wu chengtianww

#### Other Extension Metadata

Last Modified Date

  2019-03-21

IP Status

  No known IP claims.

Contributors

  - Ray Smith, Arm

#### Description

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

Because there is no real presentation target, future extensions can layer on top of the headless surface to introduce arbitrary or 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 Commands

- vkCreateHeadlessSurfaceEXT

#### New Structures

- VkHeadlessSurfaceCreateInfoEXT

#### New Bitmasks

- VkHeadlessSurfaceCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_HEADLESS_SURFACE_EXTENSION_NAME`

- `VK_EXT_HEADLESS_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_HEADLESS_SURFACE_CREATE_INFO_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_image_2d_view_of_3d

Name String

  `VK_EXT_image_2d_view_of_3d`

Extension Type

  Device extension

Registered Extension Number

  394

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_maintenance1` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - OpenGL / ES support

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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImage2DViewOf3DFeaturesEXT

#### New Enum Constants

- `VK_EXT_IMAGE_2D_VIEW_OF_3D_EXTENSION_NAME`

- `VK_EXT_IMAGE_2D_VIEW_OF_3D_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_2D_VIEW_OF_3D_FEATURES_EXT`

#### Version History

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

  - Internal revisions

#### VK_EXT_image_compression_control

Name String

  `VK_EXT_image_compression_control`

Extension Type

  Device extension

Registered Extension Number

  339

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

Extension Proposal

  VK_EXT_image_compression_control

#### Other Extension Metadata

Last Modified Date

  2022-05-02

IP Status

  No known IP claims.

Contributors

  - Jan-Harald Fredriksen, Arm

  - Graeme Leese, Broadcom

  - Andrew Garrard, Imagination

  - Lisa Wu, Arm

  - Peter Kohaut, Arm

#### Description

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

#### New Commands

- vkGetImageSubresourceLayout2EXT

#### New Structures

- VkImageSubresource2EXT

- VkSubresourceLayout2EXT

- Extending VkImageCreateInfo, VkSwapchainCreateInfoKHR, VkPhysicalDeviceImageFormatInfo2:

  - VkImageCompressionControlEXT

- Extending VkImageFormatProperties2, VkSurfaceFormat2KHR, VkSubresourceLayout2EXT:

  - VkImageCompressionPropertiesEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImageCompressionControlFeaturesEXT

#### New Enums

- VkImageCompressionFixedRateFlagBitsEXT

- VkImageCompressionFlagBitsEXT

#### New Bitmasks

- VkImageCompressionFixedRateFlagsEXT

- VkImageCompressionFlagsEXT

#### New Enum Constants

- `VK_EXT_IMAGE_COMPRESSION_CONTROL_EXTENSION_NAME`

- `VK_EXT_IMAGE_COMPRESSION_CONTROL_SPEC_VERSION`

- Extending VkResult:

  - `VK_ERROR_COMPRESSION_EXHAUSTED_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_CONTROL_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_COMPRESSION_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_SUBRESOURCE_2_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_SUBRESOURCE_LAYOUT_2_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_image_compression_control_swapchain

Name String

  `VK_EXT_image_compression_control_swapchain`

Extension Type

  Device extension

Registered Extension Number

  438

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_image_compression_control` to be enabled for any device-level functionality

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### Other Extension Metadata

Last Modified Date

  2022-05-02

IP Status

  No known IP claims.

Contributors

  - Jan-Harald Fredriksen, Arm

  - Graeme Leese, Broadcom

  - Andrew Garrard, Imagination

  - Lisa Wu, Arm

  - Peter Kohaut, Arm

  - Ian Elliott, Google

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImageCompressionControlSwapchainFeaturesEXT

#### New Enum Constants

- `VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_EXTENSION_NAME`

- `VK_EXT_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN_FEATURES_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_image_drm_format_modifier

Name String

  `VK_EXT_image_drm_format_modifier`

Extension Type

  Device extension

Registered Extension Number

  159

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_bind_memory2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_image_format_list` to be enabled for any device-level functionality

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

Contact

  - Chad Versace chadversary

#### Other Extension Metadata

Last Modified Date

  2021-09-30

IP Status

  No known IP claims.

Contributors

  - Antoine Labour, Google

  - Bas Nieuwenhuizen, Google

  - Chad Versace, Google

  - James Jones, NVIDIA

  - Jason Ekstrand, Intel

  - Jőrg Wagner, ARM

  - Kristian Høgsberg Kristensen, Google

  - Ray Smith, ARM

#### Description

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

Its functionality closely overlaps with `EGL_EXT_image_dma_buf_import_modifiers`2 and `EGL_MESA_image_dma_buf_export`3. 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 colorspace.

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

#### Usage Patterns

Three primary usage patterns are intended for this extension:

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

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

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

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

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

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

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

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

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

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

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

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

#### Prior Art

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

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

Extension `EGL_MESA_image_dma_buf_export`3 is the inverse of `EGL_EXT_image_dma_buf_import_modifiers`.

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

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

#### New Commands

- vkGetImageDrmFormatModifierPropertiesEXT

#### New Structures

- VkDrmFormatModifierPropertiesEXT

- VkImageDrmFormatModifierPropertiesEXT

- Extending VkFormatProperties2:

  - VkDrmFormatModifierPropertiesListEXT

- Extending VkImageCreateInfo:

  - VkImageDrmFormatModifierExplicitCreateInfoEXT

  - VkImageDrmFormatModifierListCreateInfoEXT

- Extending VkPhysicalDeviceImageFormatInfo2:

  - VkPhysicalDeviceImageDrmFormatModifierInfoEXT

If VK_KHR_format_feature_flags2 is supported:

- VkDrmFormatModifierProperties2EXT

- Extending VkFormatProperties2:

  - VkDrmFormatModifierPropertiesList2EXT

#### New Enum Constants

- `VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME`

- `VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION`

- Extending VkImageAspectFlagBits:

  - `VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT`

  - `VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT`

  - `VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT`

  - `VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT`

- Extending VkImageTiling:

  - `VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT`

- Extending VkResult:

  - `VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_EXPLICIT_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT`

If VK_KHR_format_feature_flags2 is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_2_EXT`

#### Issues

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

+

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

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

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

+

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

DISCUSSION: Prior art, such as `EGL_EXT_image_dma_buf_import_modifiers`2, `struct drm_mode_fb_cmd2`4, and `struct gbm_import_fd_modifier_data`5, omits from the API the size of each plane. Instead, the APIs infer each plane’s size from the import parameters, which include the image’s pixel format and a dma_buf, offset, and row pitch for each plane.

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

Differences in Image Creation

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

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

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

Problematic Plane Size Calculations

- Padding. Some plane of the image may require implementation-dependent padding.

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

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

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

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

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

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

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

##### References

1. `EGL_EXT_image_dma_buf_import`

2. `EGL_EXT_image_dma_buf_import_modifiers`

3. `EGL_MESA_image_dma_buf_export`

4. `struct drm_mode_fb_cmd2`

5. `gbm.h`

##### Version History

- Revision 1, 2018-08-29 (Chad Versace)

  - First stable revision

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

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

#### VK_EXT_image_view_min_lod

Name String

  `VK_EXT_image_view_min_lod`

Extension Type

  Device extension

Registered Extension Number

  392

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Joshua Ashton Joshua-Ashton

#### Other Extension Metadata

Last Modified Date

  2021-11-09

IP Status

  No known IP claims.

Contributors

  - Joshua Ashton, Valve

  - Hans-Kristian Arntzen, Valve

  - Samuel Iglesias Gonsalvez, Igalia

  - Tobias Hector, AMD

  - Jason Ekstrand, Intel

  - Tom Olson, ARM

#### Description

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

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

#### New Structures

- Extending VkImageViewCreateInfo:

  - VkImageViewMinLodCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImageViewMinLodFeaturesEXT

#### New Enum Constants

- `VK_EXT_IMAGE_VIEW_MIN_LOD_EXTENSION_NAME`

- `VK_EXT_IMAGE_VIEW_MIN_LOD_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_MIN_LOD_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_VIEW_MIN_LOD_FEATURES_EXT`

#### Version History

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

  - Initial version

#### VK_EXT_index_type_uint8

Name String

  `VK_EXT_index_type_uint8`

Extension Type

  Device extension

Registered Extension Number

  266

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2019-05-02

IP Status

  No known IP claims.

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension allows `uint8_t` indices to be used with vkCmdBindIndexBuffer.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceIndexTypeUint8FeaturesEXT

#### New Enum Constants

- `VK_EXT_INDEX_TYPE_UINT8_EXTENSION_NAME`

- `VK_EXT_INDEX_TYPE_UINT8_SPEC_VERSION`

- Extending VkIndexType:

  - `VK_INDEX_TYPE_UINT8_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_EXT`

#### Version History

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

  - Internal revisions

#### VK_EXT_legacy_dithering

Name String

  `VK_EXT_legacy_dithering`

Extension Type

  Device extension

Registered Extension Number

  466

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - OpenGL / ES support

Contact

  - Shahbaz Youssefi syoussefi

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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceLegacyDitheringFeaturesEXT

#### New Enum Constants

- `VK_EXT_LEGACY_DITHERING_EXTENSION_NAME`

- `VK_EXT_LEGACY_DITHERING_SPEC_VERSION`

- Extending VkRenderingFlagBits:

  - `VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LEGACY_DITHERING_FEATURES_EXT`

- Extending VkSubpassDescriptionFlagBits:

  - `VK_SUBPASS_DESCRIPTION_ENABLE_LEGACY_DITHERING_BIT_EXT`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - CAD support

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2019-05-09

IP Status

  No known IP claims.

Contributors

  - Jeff Bolz, NVIDIA

  - Allen Jensen, NVIDIA

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

- vkCmdSetLineStippleEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceLineRasterizationFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceLineRasterizationPropertiesEXT

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationLineStateCreateInfoEXT

#### New Enums

- VkLineRasterizationModeEXT

#### New Enum Constants

- `VK_EXT_LINE_RASTERIZATION_EXTENSION_NAME`

- `VK_EXT_LINE_RASTERIZATION_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_LINE_STIPPLE_EXT`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Shahbaz Youssefi syoussefi

#### Other Extension Metadata

Last Modified Date

  2021-06-06

Contributors

  - Shahbaz Youssefi, Google

  - Bill Licea-Kane, Qualcomm Technologies, Inc.

  - Tobias Hector, AMD

#### Description

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

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

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2018-10-08

Contributors

  - Jeff Bolz, NVIDIA

  - Jeff Juliano, NVIDIA

#### Description

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

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

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

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

#### New Structures

- Extending VkPhysicalDeviceMemoryProperties2:

  - VkPhysicalDeviceMemoryBudgetPropertiesEXT

#### New Enum Constants

- `VK_EXT_MEMORY_BUDGET_EXTENSION_NAME`

- `VK_EXT_MEMORY_BUDGET_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT`

#### Version History

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

  - Initial revision

#### VK_EXT_memory_priority

Name String

  `VK_EXT_memory_priority`

Extension Type

  Device extension

Registered Extension Number

  239

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2018-10-08

Contributors

  - Jeff Bolz, NVIDIA

  - Jeff Juliano, NVIDIA

#### Description

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

#### New Structures

- Extending VkMemoryAllocateInfo:

  - VkMemoryPriorityAllocateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMemoryPriorityFeaturesEXT

#### New Enum Constants

- `VK_EXT_MEMORY_PRIORITY_EXTENSION_NAME`

- `VK_EXT_MEMORY_PRIORITY_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MEMORY_PRIORITY_ALLOCATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PRIORITY_FEATURES_EXT`

#### Version History

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

  - Initial revision

#### VK_EXT_mesh_shader

Name String

  `VK_EXT_mesh_shader`

Extension Type

  Device extension

Registered Extension Number

  329

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_spirv_1_4` to be enabled for any device-level functionality

Contact

  - Christoph Kubisch pixeljetstream

Extension Proposal

  VK_EXT_mesh_shader

#### Other Extension Metadata

Last Modified Date

  2022-01-20

Interactions and External Dependencies

  - This extension requires `SPV_EXT_mesh_shader`

  - This extension provides API support for `GLSL_EXT_mesh_shader`

  - Interacts with Vulkan 1.1

  - Interacts with `VK_KHR_multiview`

  - Interacts with `VK_KHR_fragment_shading_rate`

Contributors

  - Christoph Kubisch, NVIDIA

  - Pat Brown, NVIDIA

  - Jeff Bolz, NVIDIA

  - Daniel Koch, NVIDIA

  - Piers Daniell, NVIDIA

  - Pierre Boudier, NVIDIA

  - Patrick Mours, NVIDIA

  - David Zhao Akeley, NVIDIA

  - Kedarnath Thangudu, NVIDIA

  - Timur Kristóf, Valve

  - Hans-Kristian Arntzen, Valve

  - Philip Rebohle, Valve

  - Mike Blumenkrantz, Valve

  - Slawomir Grajewski, Intel

  - Michal Pietrasiuk, Intel

  - Mariusz Merecki, Intel

  - Tom Olson, ARM

  - Jan-Harald Fredriksen, ARM

  - Sandeep Kakarlapudi, ARM

  - Ruihao Zhang, QUALCOMM

  - Ricardo Garcia, Igalia, S.L.

  - Tobias Hector, AMD

  - Stu Smith, AMD

#### Description

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

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

- `SPV_EXT_mesh_shader`

#### New Commands

- vkCmdDrawMeshTasksEXT

- vkCmdDrawMeshTasksIndirectCountEXT

- vkCmdDrawMeshTasksIndirectEXT

#### New Structures

- VkDrawMeshTasksIndirectCommandEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMeshShaderFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMeshShaderPropertiesEXT

#### New Enum Constants

- `VK_EXT_MESH_SHADER_EXTENSION_NAME`

- `VK_EXT_MESH_SHADER_SPEC_VERSION`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_MESH_SHADER_BIT_EXT`

  - `VK_PIPELINE_STAGE_TASK_SHADER_BIT_EXT`

- Extending VkQueryPipelineStatisticFlagBits:

  - `VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT`

  - `VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_MESH_PRIMITIVES_GENERATED_EXT`

- Extending VkShaderStageFlagBits:

  - `VK_SHADER_STAGE_MESH_BIT_EXT`

  - `VK_SHADER_STAGE_TASK_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_EXT`

If VK_NV_device_generated_commands is supported:

- Extending VkIndirectCommandsTokenTypeNV:

  - `VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_MESH_TASKS_NV`

#### New or Modified Built-In Variables

- CullPrimitiveEXT

- PrimitivePointIndicesEXT

- PrimitiveLineIndicesEXT

- PrimitiveTriangleIndicesEXT

- (modified)`Position`

- (modified)`PointSize`

- (modified)`ClipDistance`

- (modified)`CullDistance`

- (modified)`PrimitiveId`

- (modified)`Layer`

- (modified)`ViewportIndex`

- (modified)`NumWorkgroups`

- (modified)`WorkgroupSize`

- (modified)`WorkgroupId`

- (modified)`LocalInvocationId`

- (modified)`GlobalInvocationId`

- (modified)`LocalInvocationIndex`

- (modified)`NumSubgroups`

- (modified)`SubgroupId`

- (modified)`DrawIndex`

- (modified)`PrimitiveShadingRateKHR`

- (modified)`ViewIndex`

#### New SPIR-V Capability

- MeshShadingEXT

#### Version History

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

  - Initial revision

#### VK_EXT_metal_objects

Name String

  `VK_EXT_metal_objects`

Extension Type

  Device extension

Registered Extension Number

  312

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Bill Hollings billhollings

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

- `IOSurfaceRef`

- `MTLBuffer_id`

- `MTLCommandQueue_id`

- `MTLDevice_id`

- `MTLSharedEvent_id`

- `MTLTexture_id`

#### New Commands

- vkExportMetalObjectsEXT

#### New Structures

- VkExportMetalObjectsInfoEXT

- Extending VkExportMetalObjectsInfoEXT:

  - VkExportMetalBufferInfoEXT

  - VkExportMetalCommandQueueInfoEXT

  - VkExportMetalDeviceInfoEXT

  - VkExportMetalIOSurfaceInfoEXT

  - VkExportMetalSharedEventInfoEXT

  - VkExportMetalTextureInfoEXT

- Extending VkImageCreateInfo:

  - VkImportMetalIOSurfaceInfoEXT

  - VkImportMetalTextureInfoEXT

- Extending VkInstanceCreateInfo, VkMemoryAllocateInfo, VkImageCreateInfo, VkImageViewCreateInfo, VkBufferViewCreateInfo, VkSemaphoreCreateInfo, VkEventCreateInfo:

  - VkExportMetalObjectCreateInfoEXT

- Extending VkMemoryAllocateInfo:

  - VkImportMetalBufferInfoEXT

- Extending VkSemaphoreCreateInfo, VkEventCreateInfo:

  - VkImportMetalSharedEventInfoEXT

#### New Enums

- VkExportMetalObjectTypeFlagBitsEXT

#### New Bitmasks

- VkExportMetalObjectTypeFlagsEXT

#### New Enum Constants

- `VK_EXT_METAL_OBJECTS_EXTENSION_NAME`

- `VK_EXT_METAL_OBJECTS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_BUFFER_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_COMMAND_QUEUE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_DEVICE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_IO_SURFACE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECTS_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_OBJECT_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_SHARED_EVENT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_EXPORT_METAL_TEXTURE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMPORT_METAL_BUFFER_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMPORT_METAL_IO_SURFACE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMPORT_METAL_SHARED_EVENT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_IMPORT_METAL_TEXTURE_INFO_EXT`

#### Issues

None.

#### Version History

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

  - Initial draft.

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

#### VK_EXT_metal_surface

Name String

  `VK_EXT_metal_surface`

Extension Type

  Instance extension

Registered Extension Number

  218

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Dzmitry Malyshau kvark

#### Other Extension Metadata

Last Modified Date

  2018-10-01

IP Status

  No known IP claims.

Contributors

  - Dzmitry Malyshau, Mozilla Corp.

#### Description

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

#### New Base Types

- `CAMetalLayer`

#### New Commands

- vkCreateMetalSurfaceEXT

#### New Structures

- VkMetalSurfaceCreateInfoEXT

#### New Bitmasks

- VkMetalSurfaceCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_METAL_SURFACE_EXTENSION_NAME`

- `VK_EXT_METAL_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_METAL_SURFACE_CREATE_INFO_EXT`

#### Version History

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

  - Initial version

#### VK_EXT_multi_draw

Name String

  `VK_EXT_multi_draw`

Extension Type

  Device extension

Registered Extension Number

  393

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

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

  - Jason Ekstrand, INTEL

  - Spencer Fricke, SAMSUNG

  - Ricardo Garcia, IGALIA

  - Jon Leech, KHRONOS

  - Stu Smith, AMD

#### Description

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

#### New Commands

- vkCmdDrawMultiEXT

- vkCmdDrawMultiIndexedEXT

#### New Structures

- VkMultiDrawIndexedInfoEXT

- VkMultiDrawInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMultiDrawFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMultiDrawPropertiesEXT

#### New Enum Constants

- `VK_EXT_MULTI_DRAW_EXTENSION_NAME`

- `VK_EXT_MULTI_DRAW_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTI_DRAW_PROPERTIES_EXT`

#### New or Modified Built-In Variables

- (modified)`DrawIndex`

#### Version History

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

  - Initial version

#### VK_EXT_multisampled_render_to_single_sampled

Name String

  `VK_EXT_multisampled_render_to_single_sampled`

Extension Type

  Device extension

Registered Extension Number

  377

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_create_renderpass2` to be enabled for any device-level functionality

  - Requires `VK_KHR_depth_stencil_resolve` to be enabled for any device-level functionality

Contact

  - Shahbaz Youssefi syoussefi

Extension Proposal

  VK_EXT_multisampled_render_to_single_sampled

#### Other Extension Metadata

Last Modified Date

  2021-04-16

IP Status

  No known IP claims.

Contributors

  - Shahbaz Youssefi, Google

  - Jan-Harald Fredriksen, Arm

  - Jörg Wagner, Arm

  - Matthew Netsch, Qualcomm Technologies, Inc.

  - Jarred Davies, Imagination Technologies

#### Description

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

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

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

#### New Structures

- Extending VkFormatProperties2:

  - VkSubpassResolvePerformanceQueryEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMultisampledRenderToSingleSampledFeaturesEXT

- Extending VkSubpassDescription2, VkRenderingInfo:

  - VkMultisampledRenderToSingleSampledInfoEXT

#### New Enum Constants

- `VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_EXTENSION_NAME`

- `VK_EXT_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_SUBPASS_RESOLVE_PERFORMANCE_QUERY_EXT`

#### Issues

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

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

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

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

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

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

#### Version History

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

#### VK_EXT_non_seamless_cube_map

Name String

  `VK_EXT_non_seamless_cube_map`

Extension Type

  Device extension

Registered Extension Number

  423

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Uses

  - D3D support

  - OpenGL / ES support

Contact

  - Georg Lehmann DadSchoorse

Extension Proposal

  VK_EXT_non_seamless_cube_map

#### Other Extension Metadata

Last Modified Date

  2021-09-04

IP Status

  No known IP claims.

Contributors

  - Georg Lehmann

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceNonSeamlessCubeMapFeaturesEXT

#### New Enum Constants

- `VK_EXT_NON_SEAMLESS_CUBE_MAP_EXTENSION_NAME`

- `VK_EXT_NON_SEAMLESS_CUBE_MAP_SPEC_VERSION`

- Extending VkSamplerCreateFlagBits:

  - `VK_SAMPLER_CREATE_NON_SEAMLESS_CUBE_MAP_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_NON_SEAMLESS_CUBE_MAP_FEATURES_EXT`

#### Version History

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

  - First Version

#### VK_EXT_pageable_device_local_memory

Name String

  `VK_EXT_pageable_device_local_memory`

Extension Type

  Device extension

Registered Extension Number

  413

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_memory_priority` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2021-08-24

Contributors

  - Hans-Kristian Arntzen, Valve

  - Axel Gneiting, id Software

  - Billy Khan, id Software

  - Daniel Koch, NVIDIA

  - Chris Lentini, NVIDIA

  - Joshua Schnarr, NVIDIA

  - Stu Smith, AMD

#### Description

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

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

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

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

#### New Commands

- vkSetDeviceMemoryPriorityEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePageableDeviceLocalMemoryFeaturesEXT

#### New Enum Constants

- `VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_EXTENSION_NAME`

- `VK_EXT_PAGEABLE_DEVICE_LOCAL_MEMORY_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PAGEABLE_DEVICE_LOCAL_MEMORY_FEATURES_EXT`

#### Version History

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

  - Initial revision

#### VK_EXT_pci_bus_info

Name String

  `VK_EXT_pci_bus_info`

Extension Type

  Device extension

Registered Extension Number

  213

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2018-12-10

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Daniel Rakos, AMD

#### Description

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

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

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

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePCIBusInfoPropertiesEXT

#### New Enum Constants

- `VK_EXT_PCI_BUS_INFO_EXTENSION_NAME`

- `VK_EXT_PCI_BUS_INFO_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT`

#### Version History

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

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

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

  - Initial revision

#### VK_EXT_physical_device_drm

Name String

  `VK_EXT_physical_device_drm`

Extension Type

  Device extension

Registered Extension Number

  354

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Simon Ser emersion

#### Other Extension Metadata

Last Modified Date

  2021-06-09

IP Status

  No known IP claims.

Contributors

  - Simon Ser

#### Description

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

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

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

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

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDrmPropertiesEXT

#### New Enum Constants

- `VK_EXT_PHYSICAL_DEVICE_DRM_EXTENSION_NAME`

- `VK_EXT_PHYSICAL_DEVICE_DRM_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRM_PROPERTIES_EXT`

#### References

1. `EGL_EXT_device_drm`

#### Version History

- Revision 1, 2021-06-09

  - First stable revision

#### VK_EXT_pipeline_properties

Name String

  `VK_EXT_pipeline_properties`

Extension Type

  Device extension

Registered Extension Number

  373

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Mukund Keshava mkeshavanv

#### Other Extension Metadata

Last Modified Date

  2022-04-19

IP Status

  No known IP claims.

Contributors

  - Mukund Keshava, NVIDIA

  - Daniel Koch, NVIDIA

  - Mark Bellamy, Arm

#### Description

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

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

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

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

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

#### New Commands

- vkGetPipelinePropertiesEXT

#### New Structures

- VkPipelineInfoEXT

- VkPipelinePropertiesIdentifierEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePipelinePropertiesFeaturesEXT

#### New Enum Constants

- `VK_EXT_PIPELINE_PROPERTIES_EXTENSION_NAME`

- `VK_EXT_PIPELINE_PROPERTIES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_PROPERTIES_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_PROPERTIES_IDENTIFIER_EXT`

#### Issues

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

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

(2) This is intended to be a general pipeline properties query, but is currently only retrieving the pipeline identifier. Should the pipeline identifier query be mandatory for this extension and for all queries using this 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_robustness

Name String

  `VK_EXT_pipeline_robustness`

Extension Type

  Device extension

Registered Extension Number

  69

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jarred Davies

#### Other Extension Metadata

Last Modified Date

  2022-07-12

Interactions and External Dependencies

  - Interacts with `VK_EXT_robustness2`

  - Interacts with `VK_EXT_image_robustness`

  - Interacts with `VK_KHR_ray_tracing_pipeline`

Contributors

  - Jarred Davies, Imagination Technologies

  - Alex Walters, Imagination Technologies

  - Piers Daniell, NVIDIA

  - Graeme Leese, Broadcom Corporation

  - Jeff Leger, Qualcomm Technologies, Inc.

  - Jason Ekstrand, Intel

  - Lionel Landwerlin, Intel

  - Shahbaz Youssefi, Google, Inc.

#### Description

`VK_EXT_pipeline_robustness` allows users to request robustness on a per-pipeline stage basis.

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

#### New Structures

- Extending VkGraphicsPipelineCreateInfo, VkComputePipelineCreateInfo, VkPipelineShaderStageCreateInfo, VkRayTracingPipelineCreateInfoKHR:

  - VkPipelineRobustnessCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePipelineRobustnessFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePipelineRobustnessPropertiesEXT

#### New Enums

- VkPipelineRobustnessBufferBehaviorEXT

- VkPipelineRobustnessImageBehaviorEXT

#### New Enum Constants

- `VK_EXT_PIPELINE_ROBUSTNESS_EXTENSION_NAME`

- `VK_EXT_PIPELINE_ROBUSTNESS_SPEC_VERSION`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2017-07-17

Interactions and External Dependencies

  - This extension requires `SPV_KHR_post_depth_coverage`

  - This extension provides API support for `GL_ARB_post_depth_coverage` and `GL_EXT_post_depth_coverage`

Contributors

  - Jeff Bolz, NVIDIA

#### Description

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

- `SPV_KHR_post_depth_coverage`

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

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

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

#### New Enum Constants

- `VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME`

- `VK_EXT_POST_DEPTH_COVERAGE_SPEC_VERSION`

#### New SPIR-V Capabilities

- `SampleMaskPostDepthCoverage`

#### Version History

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

  - Internal revisions

#### VK_EXT_primitive_topology_list_restart

Name String

  `VK_EXT_primitive_topology_list_restart`

Extension Type

  Device extension

Registered Extension Number

  357

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - OpenGL / ES support

Contact

  - Shahbaz Youssefi syoussefi

#### Other Extension Metadata

Last Modified Date

  2021-01-11

IP Status

  No known IP claims.

Contributors

  - Courtney Goeltzenleuchter, Google

  - Shahbaz Youssefi, Google

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePrimitiveTopologyListRestartFeaturesEXT

#### New Enum Constants

- `VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_EXTENSION_NAME`

- `VK_EXT_PRIMITIVE_TOPOLOGY_LIST_RESTART_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVE_TOPOLOGY_LIST_RESTART_FEATURES_EXT`

#### Version History

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

  - Internal revisions

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

  - Add the `primitiveTopologyPatchListRestart` feature

  - Internal revisions

#### VK_EXT_primitives_generated_query

Name String

  `VK_EXT_primitives_generated_query`

Extension Type

  Device extension

Registered Extension Number

  383

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_transform_feedback` to be enabled for any device-level functionality

Special Use

  - OpenGL / ES support

Contact

  - Shahbaz Youssefi syoussefi

Extension Proposal

  VK_EXT_primitives_generated_query

#### Other Extension Metadata

Last Modified Date

  2022-01-24

Contributors

  - Shahbaz Youssefi, Google

  - Piers Daniell, NVIDIA

  - Jason Ekstrand, Collabora

  - Jan-Harald Fredriksen, Arm

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePrimitivesGeneratedQueryFeaturesEXT

#### New Enum Constants

- `VK_EXT_PRIMITIVES_GENERATED_QUERY_EXTENSION_NAME`

- `VK_EXT_PRIMITIVES_GENERATED_QUERY_SPEC_VERSION`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIMITIVES_GENERATED_QUERY_FEATURES_EXT`

#### Issues

1) Can the query from `VK_EXT_transform_feedback` be used instead?

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

2) Can `VK_QUERY_PIPELINE_STATISTIC_CLIPPING_INVOCATIONS_BIT` be used instead?

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

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

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

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

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

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

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

#### Version History

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

  - Internal revisions

#### VK_EXT_provoking_vertex

Name String

  `VK_EXT_provoking_vertex`

Extension Type

  Device extension

Registered Extension Number

  255

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Use

  - OpenGL / ES support

Contact

  - Jesse Hall jessehall

#### Other Extension Metadata

Last Modified Date

  2021-02-22

IP Status

  No known IP claims.

Contributors

  - Alexis Hétu, Google

  - Bill Licea-Kane, Qualcomm

  - Daniel Koch, Nvidia

  - Jamie Madill, Google

  - Jan-Harald Fredriksen, Arm

  - Jason Ekstrand, Intel

  - Jeff Bolz, Nvidia

  - Jeff Leger, Qualcomm

  - Jesse Hall, Google

  - Jörg Wagner, Arm

  - Matthew Netsch, Qualcomm

  - Mike Blumenkrantz, Valve

  - Piers Daniell, Nvidia

  - Tobias Hector, AMD

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceProvokingVertexFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceProvokingVertexPropertiesEXT

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationProvokingVertexStateCreateInfoEXT

#### New Enums

- VkProvokingVertexModeEXT

#### New Enum Constants

- `VK_EXT_PROVOKING_VERTEX_EXTENSION_NAME`

- `VK_EXT_PROVOKING_VERTEX_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROVOKING_VERTEX_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_PROVOKING_VERTEX_STATE_CREATE_INFO_EXT`

#### Issues

1) At what granularity should this state be set?

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

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

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

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

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

#### Version History

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

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

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

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

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

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

#### VK_EXT_queue_family_foreign

Name String

  `VK_EXT_queue_family_foreign`

Extension Type

  Device extension

Registered Extension Number

  127

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - Chad Versace chadversary

#### Other Extension Metadata

Last Modified Date

  2017-11-01

IP Status

  No known IP claims.

Contributors

  - Chad Versace, Google

  - James Jones, NVIDIA

  - Jason 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 (Chad 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRasterizationOrderAttachmentAccessFeaturesEXT

#### New Enums

- VkPipelineColorBlendStateCreateFlagBits

- VkPipelineDepthStencilStateCreateFlagBits

#### New Enum Constants

- `VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME`

- `VK_EXT_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION`

- Extending VkPipelineColorBlendStateCreateFlagBits:

  - `VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT`

- Extending VkPipelineDepthStencilStateCreateFlagBits:

  - `VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT`

  - `VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_EXT`

- Extending VkSubpassDescriptionFlagBits:

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_EXT`

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_EXT`

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_EXT`

#### Examples

None.

#### Version History

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

  - Initial draft

#### VK_EXT_rgba10x6_formats

Name String

  `VK_EXT_rgba10x6_formats`

Extension Type

  Device extension

Registered Extension Number

  345

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### Other Extension Metadata

Last Modified Date

  2021-09-29

IP Status

  No known IP claims.

Contributors

  - Jan-Harald Fredriksen, Arm

  - Graeme Leese, Broadcom

  - Spencer Fricke, Samsung

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRGBA10X6FormatsFeaturesEXT

#### New Enum Constants

- `VK_EXT_RGBA10X6_FORMATS_EXTENSION_NAME`

- `VK_EXT_RGBA10X6_FORMATS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RGBA10X6_FORMATS_FEATURES_EXT`

#### Issues

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

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

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

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

#### Version History

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

  - Initial EXT version

#### VK_EXT_robustness2

Name String

  `VK_EXT_robustness2`

Extension Type

  Device extension

Registered Extension Number

  287

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Liam Middlebrook liam-middlebrook

#### Other Extension Metadata

Last Modified Date

  2020-01-29

IP Status

  No known IP claims.

Contributors

  - Liam Middlebrook, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

This extension adds stricter requirements for how out of bounds reads and writes are handled. Most accesses must be tightly bounds-checked, out of bounds writes must be discarded, out of bound reads must return zero. Rather than allowing multiple possible (0,0,0,x) vectors, the out of bounds values are treated as zero, and then missing components are inserted based on the format as described in 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRobustness2FeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceRobustness2PropertiesEXT

#### New Enum Constants

- `VK_EXT_ROBUSTNESS_2_EXTENSION_NAME`

- `VK_EXT_ROBUSTNESS_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ROBUSTNESS_2_PROPERTIES_EXT`

#### Issues

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Daniel Rakos drakos-amd

#### Other Extension Metadata

Last Modified Date

  2017-08-02

Contributors

  - Mais Alnasser, AMD

  - Matthaeus G. Chajdas, AMD

  - Maciej Jesionowski, AMD

  - Daniel Rakos, AMD

  - Slawomir Grajewski, Intel

  - Jeff Bolz, NVIDIA

  - Bill Licea-Kane, Qualcomm

#### Description

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

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

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

#### New Commands

- vkCmdSetSampleLocationsEXT

- vkGetPhysicalDeviceMultisamplePropertiesEXT

#### New Structures

- VkAttachmentSampleLocationsEXT

- VkMultisamplePropertiesEXT

- VkSampleLocationEXT

- VkSubpassSampleLocationsEXT

- Extending VkImageMemoryBarrier, VkImageMemoryBarrier2:

  - VkSampleLocationsInfoEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceSampleLocationsPropertiesEXT

- Extending VkPipelineMultisampleStateCreateInfo:

  - VkPipelineSampleLocationsStateCreateInfoEXT

- Extending VkRenderPassBeginInfo:

  - VkRenderPassSampleLocationsBeginInfoEXT

#### New Enum Constants

- `VK_EXT_SAMPLE_LOCATIONS_EXTENSION_NAME`

- `VK_EXT_SAMPLE_LOCATIONS_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MULTISAMPLE_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT`

  - `VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Vikram Kushwaha vkushwaha-nv

#### Other Extension Metadata

Last Modified Date

  2020-07-15

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_EXT_shader_atomic_float_add`

  - This extension provides API support for `GL_EXT_shader_atomic_float`

Contributors

  - Vikram Kushwaha, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderAtomicFloatFeaturesEXT

#### New Enum Constants

- `VK_EXT_SHADER_ATOMIC_FLOAT_EXTENSION_NAME`

- `VK_EXT_SHADER_ATOMIC_FLOAT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_FEATURES_EXT`

#### New SPIR-V Capabilities

- `AtomicFloat32AddEXT`

- `AtomicFloat64AddEXT`

#### Version History

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

  - Internal revisions

#### VK_EXT_shader_atomic_float2

Name String

  `VK_EXT_shader_atomic_float2`

Extension Type

  Device extension

Registered Extension Number

  274

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_shader_atomic_float` to be enabled for any device-level functionality

Contact

  - Jason Ekstrand jekstrand

#### Other Extension Metadata

Last Modified Date

  2020-08-14

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires the VK_EXT_shader_atomic_float extension.

  - This extension requires `SPV_EXT_shader_atomic_float_min_max` and `SPV_EXT_shader_atomic_float16_add`

  - This extension provides API support for `GLSL_EXT_shader_atomic_float2`

Contributors

  - Jason Ekstrand, Intel

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderAtomicFloat2FeaturesEXT

#### New Enum Constants

- `VK_EXT_SHADER_ATOMIC_FLOAT_2_EXTENSION_NAME`

- `VK_EXT_SHADER_ATOMIC_FLOAT_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_FLOAT_2_FEATURES_EXT`

#### Issues

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

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

#### New SPIR-V Capabilities

- `AtomicFloat32MinMaxEXT`

- `AtomicFloat32MinMaxEXT`

- `AtomicFloat32MinMaxEXT`

- `AtomicFloat64MinMaxEXT`

#### Version History

- Revision 1, 2020-08-14 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2020-07-14

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_EXT_shader_image_int64`

  - This extension provides API support for `GLSL_EXT_shader_image_int64`

Contributors

  - Matthaeus Chajdas, AMD

  - Graham Wihlidal, Epic Games

  - Tobias Hector, AMD

  - Jeff Bolz, Nvidia

  - Jason Ekstrand, Intel

#### Description

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

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderImageAtomicInt64FeaturesEXT

#### New Enum Constants

- `VK_EXT_SHADER_IMAGE_ATOMIC_INT64_EXTENSION_NAME`

- `VK_EXT_SHADER_IMAGE_ATOMIC_INT64_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_ATOMIC_INT64_FEATURES_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_shader_module_identifier

Name String

  `VK_EXT_shader_module_identifier`

Extension Type

  Device extension

Registered Extension Number

  463

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_EXT_pipeline_creation_cache_control` to be enabled for any device-level functionality

Contact

  - Hans-Kristian Arntzen HansKristian-Work

Extension Proposal

  VK_EXT_shader_module_identifier

#### Other Extension Metadata

Last Modified Date

  2022-05-16

IP Status

  No known IP claims.

Contributors

  - Hans-Kristian Arntzen, Valve

  - Ricardo Garcia, Igalia

  - Piers Daniell, NVIDIA

  - Jan-Harald Fredriksen, Arm

  - Tom Olson, Arm

  - Jason Ekstrand, Collabora

#### Description

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

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

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

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

#### New Commands

- vkGetShaderModuleCreateInfoIdentifierEXT

- vkGetShaderModuleIdentifierEXT

#### New Structures

- VkShaderModuleIdentifierEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderModuleIdentifierFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShaderModuleIdentifierPropertiesEXT

- Extending VkPipelineShaderStageCreateInfo:

  - VkPipelineShaderStageModuleIdentifierCreateInfoEXT

#### New Enum Constants

- `VK_EXT_SHADER_MODULE_IDENTIFIER_EXTENSION_NAME`

- `VK_EXT_SHADER_MODULE_IDENTIFIER_SPEC_VERSION`

- `VK_MAX_SHADER_MODULE_IDENTIFIER_SIZE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_MODULE_IDENTIFIER_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_MODULE_IDENTIFIER_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_SHADER_MODULE_IDENTIFIER_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_shader_stencil_export

Name String

  `VK_EXT_shader_stencil_export`

Extension Type

  Device extension

Registered Extension Number

  141

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Dominik Witczak dominikwitczakamd

#### Other Extension Metadata

Last Modified Date

  2017-07-19

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_EXT_shader_stencil_export`

  - This extension provides API support for `GL_ARB_shader_stencil_export`

Contributors

  - Dominik Witczak, AMD

  - Daniel Rakos, AMD

  - Rex Xu, AMD

#### Description

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

#### New Enum Constants

- `VK_EXT_SHADER_STENCIL_EXPORT_EXTENSION_NAME`

- `VK_EXT_SHADER_STENCIL_EXPORT_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_EXT_subpass_merge_feedback

Name String

  `VK_EXT_subpass_merge_feedback`

Extension Type

  Device extension

Registered Extension Number

  459

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Ting Wei catweiting

Extension Proposal

  VK_EXT_subpass_merge_feedback

#### Other Extension Metadata

Last Modified Date

  2022-05-24

IP Status

  No known IP claims.

Contributors

  - Jan-Harald Fredriksen, Arm

  - Jorg Wagner, Arm

  - Ting Wei, Arm

#### Description

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

#### New Structures

- VkRenderPassCreationFeedbackInfoEXT

- VkRenderPassSubpassFeedbackInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSubpassMergeFeedbackFeaturesEXT

- Extending VkRenderPassCreateInfo2:

  - VkRenderPassCreationFeedbackCreateInfoEXT

- Extending VkRenderPassCreateInfo2, VkSubpassDescription2:

  - VkRenderPassCreationControlEXT

- Extending VkSubpassDescription2:

  - VkRenderPassSubpassFeedbackCreateInfoEXT

#### New Enums

- VkSubpassMergeStatusEXT

#### New Enum Constants

- `VK_EXT_SUBPASS_MERGE_FEEDBACK_EXTENSION_NAME`

- `VK_EXT_SUBPASS_MERGE_FEEDBACK_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBPASS_MERGE_FEEDBACK_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_CONTROL_EXT`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_CREATION_FEEDBACK_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_SUBPASS_FEEDBACK_CREATE_INFO_EXT`

#### Version History

- Revision 1, 2022-03-10

  - Initial draft.

- Revision 2, 2022-05-24

  - Fix structextends and constness issues.

#### VK_EXT_swapchain_colorspace

Name String

  `VK_EXT_swapchain_colorspace`

Extension Type

  Instance extension

Registered Extension Number

  105

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Courtney Goeltzenleuchter courtney-g

#### Other Extension Metadata

Last Modified Date

  2019-04-26

IP Status

  No known IP claims.

Contributors

  - Courtney Goeltzenleuchter, Google

#### Description

To be done.

#### 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 colorspaces. 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 colorspace?

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 colorspace transfer function usage.

  - Refer to normative definitions in the Data Format Specification.

  - Clarify DCI-P3 and Display P3 usage.

#### VK_EXT_transform_feedback

Name String

  `VK_EXT_transform_feedback`

Extension Type

  Device extension

Registered Extension Number

  29

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Special Uses

  - OpenGL / ES support

  - D3D support

  - Developer tools

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2018-10-09

Contributors

  - Baldur Karlsson, Valve

  - Boris Zanin, Mobica

  - Daniel Rakos, AMD

  - Donald Scorgie, Imagination

  - Henri Verbeet, CodeWeavers

  - Jan-Harald Fredriksen, Arm

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Jesse Barker, Unity

  - Jesse Hall, Google

  - Pierre-Loup Griffais, Valve

  - Philip Rebohle, DXVK

  - Ruihao Zhang, Qualcomm

  - Samuel Pitoiset, Valve

  - Slawomir Grajewski, Intel

  - Stu Smith, Imagination Technologies

#### Description

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

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

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

#### New Commands

- vkCmdBeginQueryIndexedEXT

- vkCmdBeginTransformFeedbackEXT

- vkCmdBindTransformFeedbackBuffersEXT

- vkCmdDrawIndirectByteCountEXT

- vkCmdEndQueryIndexedEXT

- vkCmdEndTransformFeedbackEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTransformFeedbackFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceTransformFeedbackPropertiesEXT

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationStateStreamCreateInfoEXT

#### New Bitmasks

- VkPipelineRasterizationStateStreamCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_TRANSFORM_FEEDBACK_EXTENSION_NAME`

- `VK_EXT_TRANSFORM_FEEDBACK_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT`

  - `VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT`

  - `VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_BUFFER_BIT_EXT`

  - `VK_BUFFER_USAGE_TRANSFORM_FEEDBACK_COUNTER_BUFFER_BIT_EXT`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_STREAM_CREATE_INFO_EXT`

#### Issues

1) Should we include pause/resume functionality?

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

2) How does this interact with multiview?

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

3) How should queries be done?

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

#### Version History

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

  - Internal revisions

#### VK_EXT_validation_cache

Name String

  `VK_EXT_validation_cache`

Extension Type

  Device extension

Registered Extension Number

  161

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Cort Stratton cdwfs

#### Other Extension Metadata

Last Modified Date

  2017-08-29

IP Status

  No known IP claims.

Contributors

  - Cort Stratton, Google

  - Chris Forbes, Google

#### Description

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

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

- VkValidationCacheEXT

#### New Commands

- vkCreateValidationCacheEXT

- vkDestroyValidationCacheEXT

- vkGetValidationCacheDataEXT

- vkMergeValidationCachesEXT

#### New Structures

- VkValidationCacheCreateInfoEXT

- Extending VkShaderModuleCreateInfo, VkPipelineShaderStageCreateInfo:

  - VkShaderModuleValidationCacheCreateInfoEXT

#### New Enums

- VkValidationCacheHeaderVersionEXT

#### New Bitmasks

- VkValidationCacheCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_VALIDATION_CACHE_EXTENSION_NAME`

- `VK_EXT_VALIDATION_CACHE_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_VALIDATION_CACHE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT`

#### Version History

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

  - Initial draft

#### VK_EXT_validation_features

Name String

  `VK_EXT_validation_features`

Extension Type

  Instance extension

Registered Extension Number

  248

Revision

  5

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - Debugging tools

Contact

  - Karl Schultz karl-lunarg

#### Other Extension Metadata

Last Modified Date

  2018-11-14

IP Status

  No known IP claims.

Contributors

  - Karl Schultz, LunarG

  - Dave Houlton, LunarG

  - Mark Lobodzinski, LunarG

  - Camden Stocker, LunarG

  - Tony Barbour, LunarG

  - John Zulauf, LunarG

#### Description

This extension provides the VkValidationFeaturesEXT 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

- Extending VkInstanceCreateInfo:

  - VkValidationFeaturesEXT

#### New Enums

- VkValidationFeatureDisableEXT

- VkValidationFeatureEnableEXT

#### New Enum Constants

- `VK_EXT_VALIDATION_FEATURES_EXTENSION_NAME`

- `VK_EXT_VALIDATION_FEATURES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT`

#### Version History

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

  - Initial revision

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

  - Add Best Practices enable

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

  - Add Debug Printf enable

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

  - Add Synchronization Validation enable

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

  - Add Shader Validation Cache disable

#### VK_EXT_vertex_attribute_divisor

Name String

  `VK_EXT_vertex_attribute_divisor`

Extension Type

  Device extension

Registered Extension Number

  191

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Vikram Kushwaha vkushwaha

#### Other Extension Metadata

Last Modified Date

  2018-08-03

IP Status

  No known IP claims.

Contributors

  - Vikram Kushwaha, NVIDIA

  - Jason Ekstrand, Intel

#### Description

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

#### New Structures

- VkVertexInputBindingDivisorDescriptionEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT

- Extending VkPipelineVertexInputStateCreateInfo:

  - VkPipelineVertexInputDivisorStateCreateInfoEXT

#### New Enum Constants

- `VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_EXTENSION_NAME`

- `VK_EXT_VERTEX_ATTRIBUTE_DIVISOR_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT`

#### Issues

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

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

2) Should zero be an allowed divisor?

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

#### Examples

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

        const VkVertexInputBindingDivisorDescriptionEXT divisorDesc =
        {
            0,
            4
        };

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

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

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

#### Version History

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

  - First Version

- Revision 2, 2018-07-16 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2020-08-21

IP Status

  No known IP claims.

Contributors

  - Jeff Bolz, NVIDIA

  - Spencer Fricke, Samsung

  - Stu Smith, AMD

#### Description

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

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

#### New Commands

- vkCmdSetVertexInputEXT

#### New Structures

- VkVertexInputAttributeDescription2EXT

- VkVertexInputBindingDescription2EXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceVertexInputDynamicStateFeaturesEXT

#### New Enum Constants

- `VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_EXTENSION_NAME`

- `VK_EXT_VERTEX_INPUT_DYNAMIC_STATE_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_VERTEX_INPUT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_INPUT_DYNAMIC_STATE_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_VERTEX_INPUT_ATTRIBUTE_DESCRIPTION_2_EXT`

  - `VK_STRUCTURE_TYPE_VERTEX_INPUT_BINDING_DESCRIPTION_2_EXT`

#### Version History

- Revision 2, 2020-11-05 (Piers Daniell)

  - Make VkVertexInputBindingDescription2EXT extensible

  - Add new VkVertexInputAttributeDescription2EXT struct for the `pVertexAttributeDescriptions` parameter to vkCmdSetVertexInputEXT so it is also extensible

- Revision 1, 2020-08-21 (Piers Daniell)

  - Internal revisions

#### VK_EXT_ycbcr_image_arrays

Name String

  `VK_EXT_ycbcr_image_arrays`

Extension Type

  Device extension

Registered Extension Number

  253

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2019-01-15

Contributors

  - Piers Daniell, NVIDIA

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceYcbcrImageArraysFeaturesEXT

#### New Enum Constants

- `VK_EXT_YCBCR_IMAGE_ARRAYS_EXTENSION_NAME`

- `VK_EXT_YCBCR_IMAGE_ARRAYS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_IMAGE_ARRAYS_FEATURES_EXT`

#### Version History

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

  - Initial revision

#### VK_AMD_buffer_marker

Name String

  `VK_AMD_buffer_marker`

Extension Type

  Device extension

Registered Extension Number

  180

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - Developer tools

Contact

  - Daniel Rakos drakos-amd

#### Other Extension Metadata

Last Modified Date

  2018-01-26

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Jaakko Konttinen, AMD

  - Daniel Rakos, AMD

#### Description

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

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

#### New Commands

- vkCmdWriteBufferMarkerAMD

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2019-02-04

Contributors

  - Ping Fu, AMD

  - Timothy Lottes, AMD

  - Tobias Hector, AMD

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceCoherentMemoryFeaturesAMD

#### New Enum Constants

- `VK_AMD_DEVICE_COHERENT_MEMORY_EXTENSION_NAME`

- `VK_AMD_DEVICE_COHERENT_MEMORY_SPEC_VERSION`

- Extending VkMemoryPropertyFlagBits:

  - `VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD`

  - `VK_MEMORY_PROPERTY_DEVICE_UNCACHED_BIT_AMD`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COHERENT_MEMORY_FEATURES_AMD`

#### Version History

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

  - Initial revision

#### VK_AMD_display_native_hdr

Name String

  `VK_AMD_display_native_hdr`

Extension Type

  Device extension

Registered Extension Number

  214

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_surface_capabilities2` to be enabled for any device-level functionality

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2018-12-18

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Aaron Hagan, AMD

  - Aric Cyr, AMD

  - Timothy Lottes, AMD

  - Derrick Owens, AMD

  - Daniel Rakos, AMD

#### Description

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

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

- Local dimming control

#### New Commands

- vkSetLocalDimmingAMD

#### New Structures

- Extending VkSurfaceCapabilities2KHR:

  - VkDisplayNativeHdrSurfaceCapabilitiesAMD

- Extending VkSwapchainCreateInfoKHR:

  - VkSwapchainDisplayNativeHdrCreateInfoAMD

#### New Enum Constants

- `VK_AMD_DISPLAY_NATIVE_HDR_EXTENSION_NAME`

- `VK_AMD_DISPLAY_NATIVE_HDR_SPEC_VERSION`

- Extending VkColorSpaceKHR:

  - `VK_COLOR_SPACE_DISPLAY_NATIVE_AMD`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DISPLAY_NATIVE_HDR_SURFACE_CAPABILITIES_AMD`

  - `VK_STRUCTURE_TYPE_SWAPCHAIN_DISPLAY_NATIVE_HDR_CREATE_INFO_AMD`

#### Issues

None.

#### Examples

None.

#### Version History

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

  - Initial revision

#### VK_AMD_gcn_shader

Name String

  `VK_AMD_gcn_shader`

Extension Type

  Device extension

Registered Extension Number

  26

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Dominik Witczak dominikwitczakamd

#### Other Extension Metadata

Last Modified Date

  2016-05-30

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_gcn_shader`

  - This extension provides API support for `GL_AMD_gcn_shader`

Contributors

  - Dominik Witczak, AMD

  - Daniel Rakos, AMD

  - Rex Xu, AMD

  - Graham Sellers, AMD

#### Description

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

- `SPV_AMD_gcn_shader`

#### New Enum Constants

- `VK_AMD_GCN_SHADER_EXTENSION_NAME`

- `VK_AMD_GCN_SHADER_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_AMD_memory_overallocation_behavior

Name String

  `VK_AMD_memory_overallocation_behavior`

Extension Type

  Device extension

Registered Extension Number

  190

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Martin Dinkov mdinkov

#### Other Extension Metadata

Last Modified Date

  2018-09-19

IP Status

  No known IP claims.

Contributors

  - Martin Dinkov, AMD

  - Matthaeus Chajdas, AMD

  - Daniel Rakos, AMD

  - Jon Campbell, AMD

#### Description

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

#### New Structures

- Extending VkDeviceCreateInfo:

  - VkDeviceMemoryOverallocationCreateInfoAMD

#### New Enums

- VkMemoryOverallocationBehaviorAMD

#### New Enum Constants

- `VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_EXTENSION_NAME`

- `VK_AMD_MEMORY_OVERALLOCATION_BEHAVIOR_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_MEMORY_OVERALLOCATION_CREATE_INFO_AMD`

#### Version History

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

  - Initial draft.

#### VK_AMD_mixed_attachment_samples

Name String

  `VK_AMD_mixed_attachment_samples`

Extension Type

  Device extension

Registered Extension Number

  137

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2017-07-24

Contributors

  - Mais Alnasser, AMD

  - Matthaeus G. Chajdas, AMD

  - Maciej Jesionowski, AMD

  - Daniel Rakos, AMD

#### Description

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

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2019-07-26

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Daniel Rakos, AMD

  - Maciej Jesionowski, AMD

  - Tobias Hector, AMD

#### Description

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

#### New Structures

- Extending VkGraphicsPipelineCreateInfo, VkComputePipelineCreateInfo:

  - VkPipelineCompilerControlCreateInfoAMD

#### New Enums

- VkPipelineCompilerControlFlagBitsAMD

#### New Bitmasks

- VkPipelineCompilerControlFlagsAMD

#### New Enum Constants

- `VK_AMD_PIPELINE_COMPILER_CONTROL_EXTENSION_NAME`

- `VK_AMD_PIPELINE_COMPILER_CONTROL_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_COMPILER_CONTROL_CREATE_INFO_AMD`

#### Issues

None.

#### Examples

None.

#### Version History

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

  - Initial revision.

#### VK_AMD_rasterization_order

Name String

  `VK_AMD_rasterization_order`

Extension Type

  Device extension

Registered Extension Number

  19

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Daniel Rakos drakos-amd

#### Other Extension Metadata

Last Modified Date

  2016-04-25

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Jaakko Konttinen, AMD

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Dominik Witczak, AMD

#### Description

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

- depth bounds test

- stencil test, stencil op, and stencil write

- depth test and depth write

- occlusion queries

- blending, logic op, and color write

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

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

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

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

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

#### New Structures

- Extending VkPipelineRasterizationStateCreateInfo:

  - VkPipelineRasterizationStateRasterizationOrderAMD

#### New Enums

- VkRasterizationOrderAMD

#### New Enum Constants

- `VK_AMD_RASTERIZATION_ORDER_EXTENSION_NAME`

- `VK_AMD_RASTERIZATION_ORDER_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD`

#### Issues

1) How is this extension useful to application developers?

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

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

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

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

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

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

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

#### Examples

None

#### Issues

None

#### Version History

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

  - Initial draft.

#### VK_AMD_shader_ballot

Name String

  `VK_AMD_shader_ballot`

Extension Type

  Device extension

Registered Extension Number

  38

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Dominik Witczak dominikwitczakamd

#### Other Extension Metadata

Last Modified Date

  2016-09-19

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_ballot`

  - This extension provides API support for `GL_AMD_shader_ballot`

Contributors

  - Qun Lin, AMD

  - Graham Sellers, AMD

  - Daniel Rakos, AMD

  - Rex Xu, AMD

  - Dominik Witczak, AMD

  - Matthäus G. Chajdas, AMD

#### Description

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

- `SPV_AMD_shader_ballot`

#### New Enum Constants

- `VK_AMD_SHADER_BALLOT_EXTENSION_NAME`

- `VK_AMD_SHADER_BALLOT_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_AMD_shader_core_properties

Name String

  `VK_AMD_shader_core_properties`

Extension Type

  Device extension

Registered Extension Number

  186

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Martin Dinkov mdinkov

#### Other Extension Metadata

Last Modified Date

  2019-06-25

IP Status

  No known IP claims.

Contributors

  - Martin Dinkov, AMD

  - Matthaeus G. Chajdas, AMD

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShaderCorePropertiesAMD

#### New Enum Constants

- `VK_AMD_SHADER_CORE_PROPERTIES_EXTENSION_NAME`

- `VK_AMD_SHADER_CORE_PROPERTIES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD`

#### Examples

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

    extern VkInstance       instance;

    PFN_vkGetPhysicalDeviceProperties2 pfnVkGetPhysicalDeviceProperties2 =
        reinterpret_cast<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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_AMD_shader_core_properties` to be enabled for any device-level functionality

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2019-07-26

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Tobias Hector, AMD

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShaderCoreProperties2AMD

#### New Enums

- VkShaderCorePropertiesFlagBitsAMD

#### New Bitmasks

- VkShaderCorePropertiesFlagsAMD

#### New Enum Constants

- `VK_AMD_SHADER_CORE_PROPERTIES_2_EXTENSION_NAME`

- `VK_AMD_SHADER_CORE_PROPERTIES_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_2_AMD`

#### Examples

None.

#### Version History

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

  - Initial draft.

#### VK_AMD_shader_early_and_late_fragment_tests

Name String

  `VK_AMD_shader_early_and_late_fragment_tests`

Extension Type

  Device extension

Registered Extension Number

  322

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Tobias Hector tobski

Extension Proposal

  VK_AMD_shader_early_and_late_fragment_tests

#### Other Extension Metadata

Last Modified Date

  2021-09-14

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_early_and_late_fragment_tests`

  - This extension interacts with `VK_EXT_shader_stencil_export`

Contributors

  - Tobias Hector, AMD

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderEarlyAndLateFragmentTestsFeaturesAMD

#### New Enum Constants

- `VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_EXTENSION_NAME`

- `VK_AMD_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EARLY_AND_LATE_FRAGMENT_TESTS_FEATURES_AMD`

#### Version History

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

  - Initial draft

#### VK_AMD_shader_explicit_vertex_parameter

Name String

  `VK_AMD_shader_explicit_vertex_parameter`

Extension Type

  Device extension

Registered Extension Number

  22

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Qun Lin linqun

#### Other Extension Metadata

Last Modified Date

  2016-05-10

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_explicit_vertex_parameter`

  - This extension provides API support for `GL_AMD_shader_explicit_vertex_parameter`

Contributors

  - Matthaeus G. Chajdas, AMD

  - Qun Lin, AMD

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Rex Xu, AMD

#### Description

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

- `SPV_AMD_shader_explicit_vertex_parameter`

#### New Enum Constants

- `VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_EXTENSION_NAME`

- `VK_AMD_SHADER_EXPLICIT_VERTEX_PARAMETER_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_AMD_shader_fragment_mask

Name String

  `VK_AMD_shader_fragment_mask`

Extension Type

  Device extension

Registered Extension Number

  138

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Aaron Hagan AaronHaganAMD

#### Other Extension Metadata

Last Modified Date

  2017-08-16

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_fragment_mask`

  - This extension provides API support for `GL_AMD_shader_fragment_mask`

Contributors

  - Aaron Hagan, AMD

  - Daniel Rakos, AMD

  - Timothy Lottes, AMD

#### Description

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

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

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

#### New Enum Constants

- `VK_AMD_SHADER_FRAGMENT_MASK_EXTENSION_NAME`

- `VK_AMD_SHADER_FRAGMENT_MASK_SPEC_VERSION`

#### New SPIR-V Capabilities

- `FragmentMaskAMD`

#### Examples

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

    #version 450 core

    #extension GL_AMD_shader_fragment_mask: enable

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

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

    layout(location = 0) out vec4 fragColor;

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

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

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

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

        fragColor = fragOne;
    }

#### Version History

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

  - Initial draft

#### VK_AMD_shader_image_load_store_lod

Name String

  `VK_AMD_shader_image_load_store_lod`

Extension Type

  Device extension

Registered Extension Number

  47

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Dominik Witczak dominikwitczakamd

#### Other Extension Metadata

Last Modified Date

  2017-08-21

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_image_load_store_lod`

  - This extension provides API support for `GL_AMD_shader_image_load_store_lod`

IP Status

  No known IP claims.

Contributors

  - Dominik Witczak, AMD

  - Qun Lin, AMD

  - Rex Xu, AMD

#### Description

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

- `SPV_AMD_shader_image_load_store_lod`

#### New Enum Constants

- `VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_EXTENSION_NAME`

- `VK_AMD_SHADER_IMAGE_LOAD_STORE_LOD_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_AMD_shader_info

Name String

  `VK_AMD_shader_info`

Extension Type

  Device extension

Registered Extension Number

  43

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - Developer tools

Contact

  - Jaakko Konttinen jaakkoamd

#### Other Extension Metadata

Last Modified Date

  2017-10-09

IP Status

  No known IP claims.

Contributors

  - Jaakko Konttinen, AMD

#### Description

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

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

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

#### New Commands

- vkGetShaderInfoAMD

#### New Structures

- VkShaderResourceUsageAMD

- VkShaderStatisticsInfoAMD

#### New Enums

- VkShaderInfoTypeAMD

#### New Enum Constants

- `VK_AMD_SHADER_INFO_EXTENSION_NAME`

- `VK_AMD_SHADER_INFO_SPEC_VERSION`

#### Examples

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

    extern VkDevice device;
    extern VkPipeline gfxPipeline;

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

    VkShaderStatisticsInfoAMD statistics = {};

    size_t dataSize = sizeof(statistics);

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

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

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

        void* disassembly = malloc(dataSize);

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

        free(disassembly);
    }

#### Version History

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

  - Initial revision

#### VK_AMD_shader_trinary_minmax

Name String

  `VK_AMD_shader_trinary_minmax`

Extension Type

  Device extension

Registered Extension Number

  21

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Qun Lin linqun

#### Other Extension Metadata

Last Modified Date

  2016-05-10

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_shader_trinary_minmax`

  - This extension provides API support for `GL_AMD_shader_trinary_minmax`

Contributors

  - Matthaeus G. Chajdas, AMD

  - Qun Lin, AMD

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Rex Xu, AMD

#### Description

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

- `SPV_AMD_shader_trinary_minmax`

#### New Enum Constants

- `VK_AMD_SHADER_TRINARY_MINMAX_EXTENSION_NAME`

- `VK_AMD_SHADER_TRINARY_MINMAX_SPEC_VERSION`

#### Version History

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

  - Initial draft

#### VK_AMD_texture_gather_bias_lod

Name String

  `VK_AMD_texture_gather_bias_lod`

Extension Type

  Device extension

Registered Extension Number

  42

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Rex Xu amdrexu

#### Other Extension Metadata

Last Modified Date

  2017-03-21

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_texture_gather_bias_lod`

  - This extension provides API support for `GL_AMD_texture_gather_bias_lod`

Contributors

  - Dominik Witczak, AMD

  - Daniel Rakos, AMD

  - Graham Sellers, AMD

  - Matthaeus G. Chajdas, AMD

  - Qun Lin, AMD

  - Rex Xu, AMD

  - Timothy Lottes, AMD

#### Description

This extension adds two related features.

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

- `SPV_AMD_texture_gather_bias_lod`

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

#### New Structures

- Extending VkImageFormatProperties2:

  - VkTextureLODGatherFormatPropertiesAMD

#### New Enum Constants

- `VK_AMD_TEXTURE_GATHER_BIAS_LOD_EXTENSION_NAME`

- `VK_AMD_TEXTURE_GATHER_BIAS_LOD_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_TEXTURE_LOD_GATHER_FORMAT_PROPERTIES_AMD`

#### New SPIR-V Capabilities

- `ImageGatherBiasLodAMD`

#### Examples

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

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

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

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

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

    vkGetPhysicalDeviceImageFormatProperties2(physical_device, &formatInfo, &formatProps);

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

#### Version History

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

  - Initial draft

#### VK_ANDROID_external_memory_android_hardware_buffer

Name String

  `VK_ANDROID_external_memory_android_hardware_buffer`

Extension Type

  Device extension

Registered Extension Number

  130

Revision

  5

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

  - Requires `VK_EXT_queue_family_foreign` to be enabled for any device-level functionality

  - Requires `VK_KHR_dedicated_allocation` to be enabled for any device-level functionality

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2021-09-30

IP Status

  No known IP claims.

Contributors

  - Ray Smith, ARM

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

- `AHardwareBuffer`

#### New Commands

- vkGetAndroidHardwareBufferPropertiesANDROID

- vkGetMemoryAndroidHardwareBufferANDROID

#### New Structures

- VkAndroidHardwareBufferPropertiesANDROID

- VkMemoryGetAndroidHardwareBufferInfoANDROID

- Extending VkAndroidHardwareBufferPropertiesANDROID:

  - VkAndroidHardwareBufferFormatPropertiesANDROID

- Extending VkImageCreateInfo, VkSamplerYcbcrConversionCreateInfo:

  - VkExternalFormatANDROID

- Extending VkImageFormatProperties2:

  - VkAndroidHardwareBufferUsageANDROID

- Extending VkMemoryAllocateInfo:

  - VkImportAndroidHardwareBufferInfoANDROID

If VK_KHR_format_feature_flags2 is supported:

- Extending VkAndroidHardwareBufferPropertiesANDROID:

  - VkAndroidHardwareBufferFormatProperties2ANDROID

#### New Enum Constants

- `VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME`

- `VK_ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION`

- Extending VkExternalMemoryHandleTypeFlagBits:

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID`

  - `VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_PROPERTIES_ANDROID`

  - `VK_STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_USAGE_ANDROID`

  - `VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID`

  - `VK_STRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID`

  - `VK_STRUCTURE_TYPE_MEMORY_GET_ANDROID_HARDWARE_BUFFER_INFO_ANDROID`

If VK_KHR_format_feature_flags2 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)

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

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

  - Update revision history to correspond to XML version number

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

  - Markup fixes and remove incorrect Draft status

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

  - Initial version

#### VK_FUCHSIA_buffer_collection

Name String

  `VK_FUCHSIA_buffer_collection`

Extension Type

  Device extension

Registered Extension Number

  367

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_FUCHSIA_external_memory` to be enabled for any device-level functionality

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

Contact

  - John Rosasco rosasco

#### Other Extension Metadata

Last Modified Date

  2021-09-23

IP Status

  No known IP claims.

Contributors

  - Craig Stout, Google

  - John Bauman, Google

  - John Rosasco, Google

#### Description

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

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

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

#### New Object Types

- VkBufferCollectionFUCHSIA

#### New Commands

- vkCreateBufferCollectionFUCHSIA

- vkDestroyBufferCollectionFUCHSIA

- vkGetBufferCollectionPropertiesFUCHSIA

- vkSetBufferCollectionBufferConstraintsFUCHSIA

- vkSetBufferCollectionImageConstraintsFUCHSIA

#### New Structures

- VkBufferCollectionConstraintsInfoFUCHSIA

- VkBufferCollectionCreateInfoFUCHSIA

- VkBufferCollectionPropertiesFUCHSIA

- VkBufferConstraintsInfoFUCHSIA

- VkImageConstraintsInfoFUCHSIA

- VkImageFormatConstraintsInfoFUCHSIA

- VkSysmemColorSpaceFUCHSIA

- Extending VkBufferCreateInfo:

  - VkBufferCollectionBufferCreateInfoFUCHSIA

- Extending VkImageCreateInfo:

  - VkBufferCollectionImageCreateInfoFUCHSIA

- Extending VkMemoryAllocateInfo:

  - VkImportMemoryBufferCollectionFUCHSIA

#### New Enums

- VkImageConstraintsInfoFlagBitsFUCHSIA

#### New Bitmasks

- VkImageConstraintsInfoFlagsFUCHSIA

- VkImageFormatConstraintsFlagsFUCHSIA

#### New Enum Constants

- `VK_FUCHSIA_BUFFER_COLLECTION_EXTENSION_NAME`

- `VK_FUCHSIA_BUFFER_COLLECTION_SPEC_VERSION`

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_BUFFER_COLLECTION_FUCHSIA_EXT`

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

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory_capabilities` to be enabled for any device-level functionality

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - John Rosasco rosasco

#### Other Extension Metadata

Last Modified Date

  2021-03-01

IP Status

  No known IP claims.

Contributors

  - Craig Stout, Google

  - John Bauman, Google

  - John Rosasco, Google

#### Description

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

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

#### New Commands

- vkGetMemoryZirconHandleFUCHSIA

- vkGetMemoryZirconHandlePropertiesFUCHSIA

#### New Structures

- VkMemoryGetZirconHandleInfoFUCHSIA

- VkMemoryZirconHandlePropertiesFUCHSIA

- Extending VkMemoryAllocateInfo:

  - VkImportMemoryZirconHandleInfoFUCHSIA

#### New Enum Constants

- `VK_FUCHSIA_EXTERNAL_MEMORY_EXTENSION_NAME`

- `VK_FUCHSIA_EXTERNAL_MEMORY_SPEC_VERSION`

- Extending VkExternalMemoryHandleTypeFlagBits:

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_ZIRCON_VMO_BIT_FUCHSIA`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMPORT_MEMORY_ZIRCON_HANDLE_INFO_FUCHSIA`

  - `VK_STRUCTURE_TYPE_MEMORY_GET_ZIRCON_HANDLE_INFO_FUCHSIA`

  - `VK_STRUCTURE_TYPE_MEMORY_ZIRCON_HANDLE_PROPERTIES_FUCHSIA`

#### Issues

See `VK_KHR_external_memory` issues list for further information.

#### Version History

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

  - Initial draft

#### VK_FUCHSIA_external_semaphore

Name String

  `VK_FUCHSIA_external_semaphore`

Extension Type

  Device extension

Registered Extension Number

  366

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_semaphore_capabilities` to be enabled for any device-level functionality

  - Requires `VK_KHR_external_semaphore` to be enabled for any device-level functionality

Contact

  - John Rosasco rosasco

#### Other Extension Metadata

Last Modified Date

  2021-03-08

IP Status

  No known IP claims.

Contributors

  - Craig Stout, Google

  - John Bauman, Google

  - John Rosasco, Google

#### Description

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

#### New Commands

- vkGetSemaphoreZirconHandleFUCHSIA

- vkImportSemaphoreZirconHandleFUCHSIA

#### New Structures

- VkImportSemaphoreZirconHandleInfoFUCHSIA

- VkSemaphoreGetZirconHandleInfoFUCHSIA

#### New Enum Constants

- `VK_FUCHSIA_EXTERNAL_SEMAPHORE_EXTENSION_NAME`

- `VK_FUCHSIA_EXTERNAL_SEMAPHORE_SPEC_VERSION`

- Extending VkExternalSemaphoreHandleTypeFlagBits:

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_ZIRCON_EVENT_BIT_FUCHSIA`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_ZIRCON_HANDLE_INFO_FUCHSIA`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_GET_ZIRCON_HANDLE_INFO_FUCHSIA`

#### Issues

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

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

#### Version History

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

  - Initial revision

#### VK_FUCHSIA_imagepipe_surface

Name String

  `VK_FUCHSIA_imagepipe_surface`

Extension Type

  Instance extension

Registered Extension Number

  215

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Craig Stout cdotstout

#### Other Extension Metadata

Last Modified Date

  2018-07-27

IP Status

  No known IP claims.

Contributors

  - Craig Stout, Google

  - Ian Elliott, Google

  - Jesse Hall, Google

#### Description

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

#### New Commands

- vkCreateImagePipeSurfaceFUCHSIA

#### New Structures

- VkImagePipeSurfaceCreateInfoFUCHSIA

#### New Bitmasks

- VkImagePipeSurfaceCreateFlagsFUCHSIA

#### New Enum Constants

- `VK_FUCHSIA_IMAGEPIPE_SURFACE_EXTENSION_NAME`

- `VK_FUCHSIA_IMAGEPIPE_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGEPIPE_SURFACE_CREATE_INFO_FUCHSIA`

#### Version History

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

  - Initial draft.

#### VK_GGP_frame_token

Name String

  `VK_GGP_frame_token`

Extension Type

  Device extension

Registered Extension Number

  192

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_GGP_stream_descriptor_surface` to be enabled for any device-level functionality

Contact

  - Jean-Francois Roy jfroy

#### Other Extension Metadata

Last Modified Date

  2019-01-28

IP Status

  No known IP claims.

Contributors

  - Jean-Francois Roy, Google

  - Richard O’Grady, Google

#### Description

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

#### New Structures

- Extending VkPresentInfoKHR:

  - VkPresentFrameTokenGGP

#### New Enum Constants

- `VK_GGP_FRAME_TOKEN_EXTENSION_NAME`

- `VK_GGP_FRAME_TOKEN_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PRESENT_FRAME_TOKEN_GGP`

#### Version History

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

  - Initial revision.

#### VK_GGP_stream_descriptor_surface

Name String

  `VK_GGP_stream_descriptor_surface`

Extension Type

  Instance extension

Registered Extension Number

  50

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Jean-Francois Roy jfroy

#### Other Extension Metadata

Last Modified Date

  2019-01-28

IP Status

  No known IP claims.

Contributors

  - Jean-Francois Roy, Google

  - Brad Grantham, Google

  - Connor Smith, Google

  - Cort Stratton, Google

  - Hai Nguyen, Google

  - Ian Elliott, Google

  - Jesse Hall, Google

  - Jim Ray, Google

  - Katherine Wu, Google

  - Kaye Mason, Google

  - Kuangye Guo, Google

  - Mark Segal, Google

  - Nicholas Vining, Google

  - Paul Lalonde, Google

  - Richard O’Grady, Google

#### Description

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

#### New Commands

- vkCreateStreamDescriptorSurfaceGGP

#### New Structures

- VkStreamDescriptorSurfaceCreateInfoGGP

#### New Bitmasks

- VkStreamDescriptorSurfaceCreateFlagsGGP

#### New Enum Constants

- `VK_GGP_STREAM_DESCRIPTOR_SURFACE_EXTENSION_NAME`

- `VK_GGP_STREAM_DESCRIPTOR_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_STREAM_DESCRIPTOR_SURFACE_CREATE_INFO_GGP`

#### Version History

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

  - Initial revision.

#### VK_GOOGLE_decorate_string

Name String

  `VK_GOOGLE_decorate_string`

Extension Type

  Device extension

Registered Extension Number

  225

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Hai Nguyen chaoticbob

#### Other Extension Metadata

Last Modified Date

  2018-07-09

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_GOOGLE_decorate_string`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

Contact

  - Ian Elliott ianelliottus

#### Other Extension Metadata

Last Modified Date

  2017-02-14

IP Status

  No known IP claims.

Contributors

  - Ian Elliott, Google

  - Jesse Hall, Google

#### Description

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

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

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

#### New Commands

- vkGetPastPresentationTimingGOOGLE

- vkGetRefreshCycleDurationGOOGLE

#### New Structures

- VkPastPresentationTimingGOOGLE

- VkPresentTimeGOOGLE

- VkRefreshCycleDurationGOOGLE

- Extending VkPresentInfoKHR:

  - VkPresentTimesInfoGOOGLE

#### New Enum Constants

- `VK_GOOGLE_DISPLAY_TIMING_EXTENSION_NAME`

- `VK_GOOGLE_DISPLAY_TIMING_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PRESENT_TIMES_INFO_GOOGLE`

#### Examples

| 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Hai Nguyen chaoticbob

#### Other Extension Metadata

Last Modified Date

  2018-07-09

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_GOOGLE_hlsl_functionality1`

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

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Special Use

  - OpenGL / ES support

Contact

  - Shahbaz Youssefi syoussefi

Extension Proposal

  VK_GOOGLE_surfaceless_query

#### Other Extension Metadata

Last Modified Date

  2021-12-14

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, colorspaces and present modes to be queried without providing a surface. Identically, vkGetPhysicalDeviceSurfaceFormats2KHR and vkGetPhysicalDeviceSurfacePresentModes2EXT 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

#### VK_GOOGLE_user_type

Name String

  `VK_GOOGLE_user_type`

Extension Type

  Device extension

Registered Extension Number

  290

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Kaye Mason chaleur

#### Other Extension Metadata

Last Modified Date

  2019-07-09

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_GOOGLE_user_type`

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_invocation_mask

Name String

  `VK_HUAWEI_invocation_mask`

Extension Type

  Device extension

Registered Extension Number

  371

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_ray_tracing_pipeline` to be enabled for any device-level functionality

  - Requires `VK_KHR_synchronization2` to be enabled for any device-level functionality

Contact

  - Pan Gao PanGao-h

Extension Proposal

  VK_HUAWEI_invocation_mask

#### Other Extension Metadata

Last Modified Date

  2021-05-27

Interactions and External Dependencies

  - This extension requires `VK_KHR_ray_tracing_pipeline`, which allow to bind an invocation mask image before the ray tracing command

  - This extension requires `VK_KHR_synchronization2`, which allows new pipeline stage for the invocation mask image

Contributors

  - Yunpeng Zhu

  - Juntao Li, Huawei

  - Liang Chen, Huawei

  - Shaozhuang Shi, Huawei

  - Hailong Chu, Huawei

#### Description

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

#### New Commands

- vkCmdBindInvocationMaskHUAWEI

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceInvocationMaskFeaturesHUAWEI

#### New Enum Constants

- `VK_HUAWEI_INVOCATION_MASK_EXTENSION_NAME`

- `VK_HUAWEI_INVOCATION_MASK_SPEC_VERSION`

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_INVOCATION_MASK_READ_BIT_HUAWEI`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_INVOCATION_MASK_BIT_HUAWEI`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_INVOCATION_MASK_BIT_HUAWEI`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INVOCATION_MASK_FEATURES_HUAWEI`

#### Examples

RT mask is updated before each traceRay.

Step 1. Generate InvocationMask.

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

Step 2. traceRay with InvocationMask

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

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

#### Version History

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

  - Initial draft.

#### VK_HUAWEI_subpass_shading

Name String

  `VK_HUAWEI_subpass_shading`

Extension Type

  Device extension

Registered Extension Number

  370

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_create_renderpass2` to be enabled for any device-level functionality

  - Requires `VK_KHR_synchronization2` to be enabled for any device-level functionality

Contact

  - Pan Gao PanGao-h

#### Other Extension Metadata

Last Modified Date

  2021-06-01

Interactions and External Dependencies

  - This extension requires `SPV_HUAWEI_subpass_shading`.

  - This extension provides API support for `GL_HUAWEI_subpass_shading`.

Contributors

  - Hueilong Wang

  - Juntao Li, Huawei

  - Renmiao Lu, Huawei

  - Pan Gao, Huawei

#### Description

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

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

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

#### New Commands

- vkCmdSubpassShadingHUAWEI

- vkGetDeviceSubpassShadingMaxWorkgroupSizeHUAWEI

#### New Structures

- Extending VkComputePipelineCreateInfo:

  - VkSubpassShadingPipelineCreateInfoHUAWEI

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSubpassShadingFeaturesHUAWEI

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceSubpassShadingPropertiesHUAWEI

#### New Enum Constants

- `VK_HUAWEI_SUBPASS_SHADING_EXTENSION_NAME`

- `VK_HUAWEI_SUBPASS_SHADING_SPEC_VERSION`

- Extending VkPipelineBindPoint:

  - `VK_PIPELINE_BIND_POINT_SUBPASS_SHADING_HUAWEI`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_SUBPASS_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_SHADING_BIT_HUAWEI, VK_ACCESS_INPUT_ATTACHMENT_READ_BIT
    };

    VkMemoryBarrier2KHR subpassShadingToFragment = {
      VK_STRUCTURE_TYPE_MEMORY_BARRIER_2_KHR, NULL,
      VK_PIPELINE_STAGE_2_SUBPASS_SHADING_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 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2016-02-23

Contributors

  - Tobias Hector, Imagination Technologies

#### Description

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

#### New Enum Constants

- `VK_IMG_FILTER_CUBIC_EXTENSION_NAME`

- `VK_IMG_FILTER_CUBIC_SPEC_VERSION`

- Extending VkFilter:

  - `VK_FILTER_CUBIC_IMG`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_IMG`

#### Example

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

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

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

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

#### Version History

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

  - Initial version

#### VK_IMG_format_pvrtc

Name String

  `VK_IMG_format_pvrtc`

Extension Type

  Device extension

Registered Extension Number

  55

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

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

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

Name String

  `VK_INTEL_performance_query`

Extension Type

  Device extension

Registered Extension Number

  211

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - Developer tools

Contact

  - Lionel Landwerlin llandwerlin

#### Other Extension Metadata

Last Modified Date

  2018-05-16

IP Status

  No known IP claims.

Contributors

  - Lionel Landwerlin, Intel

  - Piotr Maciejewski, Intel

#### Description

This extension allows an application to capture performance data to be interpreted by 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 Object Types

- VkPerformanceConfigurationINTEL

#### New Commands

- vkAcquirePerformanceConfigurationINTEL

- vkCmdSetPerformanceMarkerINTEL

- vkCmdSetPerformanceOverrideINTEL

- vkCmdSetPerformanceStreamMarkerINTEL

- vkGetPerformanceParameterINTEL

- vkInitializePerformanceApiINTEL

- vkQueueSetPerformanceConfigurationINTEL

- vkReleasePerformanceConfigurationINTEL

- vkUninitializePerformanceApiINTEL

#### New Structures

- VkInitializePerformanceApiInfoINTEL

- VkPerformanceConfigurationAcquireInfoINTEL

- VkPerformanceMarkerInfoINTEL

- VkPerformanceOverrideInfoINTEL

- VkPerformanceStreamMarkerInfoINTEL

- VkPerformanceValueINTEL

- Extending VkQueryPoolCreateInfo:

  - VkQueryPoolCreateInfoINTEL

  - VkQueryPoolPerformanceQueryCreateInfoINTEL

#### New Unions

- VkPerformanceValueDataINTEL

#### New Enums

- VkPerformanceConfigurationTypeINTEL

- VkPerformanceOverrideTypeINTEL

- VkPerformanceParameterTypeINTEL

- VkPerformanceValueTypeINTEL

- VkQueryPoolSamplingModeINTEL

#### New Enum Constants

- `VK_INTEL_PERFORMANCE_QUERY_EXTENSION_NAME`

- `VK_INTEL_PERFORMANCE_QUERY_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_PERFORMANCE_CONFIGURATION_INTEL`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_CONFIGURATION_ACQUIRE_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_MARKER_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_OVERRIDE_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_PERFORMANCE_STREAM_MARKER_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO_INTEL`

  - `VK_STRUCTURE_TYPE_QUERY_POOL_PERFORMANCE_QUERY_CREATE_INFO_INTEL`

#### Example Code

    // A previously created device
    VkDevice device;

    // A queue derived from the device
    VkQueue queue;

    VkInitializePerformanceApiInfoINTEL performanceApiInfoIntel = {
      VK_STRUCTURE_TYPE_INITIALIZE_PERFORMANCE_API_INFO_INTEL,
      NULL,
      NULL
    };

    vkInitializePerformanceApiINTEL(
      device,
      &performanceApiInfoIntel);

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

    VkQueryPoolCreateInfo queryPoolCreateInfo = {
      VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
      &queryPoolIntel,
      0,
      VK_QUERY_TYPE_PERFORMANCE_QUERY_INTEL,
      1,
      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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Ian Romanick ianromanick

#### Other Extension Metadata

Last Modified Date

  2019-04-30

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_INTEL_shader_integer_functions2`.

  - This extension provides API support for `GL_INTEL_shader_integer_functions2`.

Contributors

  - Ian Romanick, Intel

  - Ben Ashbaugh, Intel

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderIntegerFunctions2FeaturesINTEL

#### New Enum Constants

- `VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_EXTENSION_NAME`

- `VK_INTEL_SHADER_INTEGER_FUNCTIONS_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_FUNCTIONS_2_FEATURES_INTEL`

#### New SPIR-V Capabilities

- `IntegerFunctions2INTEL`

#### Version History

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

  - Initial draft

#### VK_NN_vi_surface

Name String

  `VK_NN_vi_surface`

Extension Type

  Instance extension

Registered Extension Number

  63

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Mathias Heyer mheyer

#### Other Extension Metadata

Last Modified Date

  2016-12-02

IP Status

  No known IP claims.

Contributors

  - Mathias Heyer, NVIDIA

  - Michael Chock, NVIDIA

  - Yasuhiro Yoshioka, Nintendo

  - Daniel Koch, NVIDIA

#### Description

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

#### New Commands

- vkCreateViSurfaceNN

#### New Structures

- VkViSurfaceCreateInfoNN

#### New Bitmasks

- VkViSurfaceCreateFlagsNN

#### New Enum Constants

- `VK_NN_VI_SURFACE_EXTENSION_NAME`

- `VK_NN_VI_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN`

#### Issues

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

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

2) VkViSurfaceCreateInfoNN::`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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_direct_mode_display` to be enabled for any device-level functionality

Contact

  - Jeff Juliano jjuliano

#### Other Extension Metadata

Last Modified Date

  2020-09-29

IP Status

  No known IP claims.

Contributors

  - Jeff Juliano, NVIDIA

#### Description

This extension allows an application to take exclusive control of a display on Windows 10 provided that the display is not already controlled by a compositor. Examples of compositors include the Windows desktop compositor, other applications using this Vulkan extension, and applications that “Acquire” 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 Commands

- vkAcquireWinrtDisplayNV

- vkGetWinrtDisplayNV

#### New Enum Constants

- `VK_NV_ACQUIRE_WINRT_DISPLAY_EXTENSION_NAME`

- `VK_NV_ACQUIRE_WINRT_DISPLAY_SPEC_VERSION`

#### Issues

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

RESOLVED: The platform substring is “Winrt”.

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

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

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

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

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

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

RESOLVED: Add a platform-specific command.

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

The X11 acquire command does need to accept a platform-specific parameter. This could be handled by adding to a platform-independent acquire command a params 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Eric Werness ewerness-nv

#### Other Extension Metadata

Last Modified Date

  2017-02-15

Contributors

  - Eric Werness, NVIDIA

  - Kedarnath Thangudu, NVIDIA

#### Description

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

This extension provides a mechanism to render VR scenes at a non-uniform resolution, in particular a resolution that falls linearly from the center towards the edges. This is achieved by scaling the 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 Commands

- vkCmdSetViewportWScalingNV

#### New Structures

- VkViewportWScalingNV

- Extending VkPipelineViewportStateCreateInfo:

  - VkPipelineViewportWScalingStateCreateInfoNV

#### New Enum Constants

- `VK_NV_CLIP_SPACE_W_SCALING_EXTENSION_NAME`

- `VK_NV_CLIP_SPACE_W_SCALING_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_VIEWPORT_W_SCALING_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_W_SCALING_STATE_CREATE_INFO_NV`

#### Issues

1) Is the pipeline 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2018-07-19

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_NV_compute_shader_derivatives`

  - This extension provides API support for `GL_NV_compute_shader_derivatives`

Contributors

  - Pat Brown, NVIDIA

#### Description

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

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceComputeShaderDerivativesFeaturesNV

#### New Enum Constants

- `VK_NV_COMPUTE_SHADER_DERIVATIVES_EXTENSION_NAME`

- `VK_NV_COMPUTE_SHADER_DERIVATIVES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV`

#### New SPIR-V Capability

- `ComputeDerivativeGroupQuadsNV`

- `ComputeDerivativeGroupLinearNV`

#### Issues

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

RESOLVED: Yes.

#### Examples

None.

#### Version History

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

  - Initial draft

#### VK_NV_cooperative_matrix

Name String

  `VK_NV_cooperative_matrix`

Extension Type

  Device extension

Registered Extension Number

  250

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2019-02-05

Interactions and External Dependencies

  - This extension requires `SPV_NV_cooperative_matrix`

  - This extension provides API support for `GL_NV_cooperative_matrix`

Contributors

  - Jeff Bolz, NVIDIA

  - Markus Tavenrath, NVIDIA

  - Daniel Koch, NVIDIA

#### Description

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

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

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

#### New Commands

- vkGetPhysicalDeviceCooperativeMatrixPropertiesNV

#### New Structures

- VkCooperativeMatrixPropertiesNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceCooperativeMatrixFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceCooperativeMatrixPropertiesNV

#### New Enums

- VkComponentTypeNV

- VkScopeNV

#### New Enum Constants

- `VK_NV_COOPERATIVE_MATRIX_EXTENSION_NAME`

- `VK_NV_COOPERATIVE_MATRIX_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COOPERATIVE_MATRIX_PROPERTIES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COOPERATIVE_MATRIX_PROPERTIES_NV`

#### New SPIR-V Capabilities

- `CooperativeMatrixNV`

#### Issues

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

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

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

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

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

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

#### Version History

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

  - Internal revisions

#### VK_NV_corner_sampled_image

Name String

  `VK_NV_corner_sampled_image`

Extension Type

  Device extension

Registered Extension Number

  51

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2018-08-13

Contributors

  - Jeff Bolz, NVIDIA

  - Pat Brown, NVIDIA

  - Chris Lentini, NVIDIA

#### Description

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

- Texels are centered on integer coordinates. See Unnormalized Texel Coordinate Operations

- Normalized coordinates are scaled using coord × (dim - 1) rather than coord × dim, where dim is the size of one dimension of the image. See normalized texel coordinate transform.

- Partial derivatives are scaled using coord × (dim - 1) rather than coord × dim. See Scale Factor Operation.

- Calculation of the next higher lod size goes according to ⌈dim / 2⌉ rather than ⌊dim / 2⌋. See Image Miplevel Sizing.

- The minimum level size is 2x2 for 2D images and 2x2x2 for 3D images. See Image Miplevel Sizing.

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceCornerSampledImageFeaturesNV

#### New Enum Constants

- `VK_NV_CORNER_SAMPLED_IMAGE_EXTENSION_NAME`

- `VK_NV_CORNER_SAMPLED_IMAGE_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_CORNER_SAMPLED_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_CORNER_SAMPLED_IMAGE_FEATURES_NV`

#### Issues

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_NV_framebuffer_mixed_samples` to be enabled for any device-level functionality

Contact

  - Kedarnath Thangudu kthangudu

#### Other Extension Metadata

Last Modified Date

  2019-01-29

Contributors

  - Kedarnath Thangudu, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

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

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

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

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

#### New Commands

- vkGetPhysicalDeviceSupportedFramebufferMixedSamplesCombinationsNV

#### New Structures

- VkFramebufferMixedSamplesCombinationNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceCoverageReductionModeFeaturesNV

- Extending VkPipelineMultisampleStateCreateInfo:

  - VkPipelineCoverageReductionStateCreateInfoNV

#### New Enums

- VkCoverageReductionModeNV

#### New Bitmasks

- VkPipelineCoverageReductionStateCreateFlagsNV

#### New Enum Constants

- `VK_NV_COVERAGE_REDUCTION_MODE_EXTENSION_NAME`

- `VK_NV_COVERAGE_REDUCTION_MODE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FRAMEBUFFER_MIXED_SAMPLES_COMBINATION_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COVERAGE_REDUCTION_MODE_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_REDUCTION_STATE_CREATE_INFO_NV`

#### Version History

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

  - Internal revisions

#### VK_NV_dedicated_allocation_image_aliasing

Name String

  `VK_NV_dedicated_allocation_image_aliasing`

Extension Type

  Device extension

Registered Extension Number

  241

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_dedicated_allocation` to be enabled for any device-level functionality

Contact

  - Nuno Subtil nsubtil

#### Other Extension Metadata

Last Modified Date

  2019-01-04

Contributors

  - Nuno Subtil, NVIDIA

  - Jeff Bolz, NVIDIA

  - Eric Werness, NVIDIA

  - Axel Gneiting, id Software

#### Description

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

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDedicatedAllocationImageAliasingFeaturesNV

#### New Enum Constants

- `VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_EXTENSION_NAME`

- `VK_NV_DEDICATED_ALLOCATION_IMAGE_ALIASING_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEDICATED_ALLOCATION_IMAGE_ALIASING_FEATURES_NV`

#### Version History

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

  - Internal revisions

#### VK_NV_device_diagnostic_checkpoints

Name String

  `VK_NV_device_diagnostic_checkpoints`

Extension Type

  Device extension

Registered Extension Number

  207

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Nuno Subtil nsubtil

#### Other Extension Metadata

Last Modified Date

  2018-07-16

Contributors

  - Oleg Kuznetsov, NVIDIA

  - Alex Dunn, NVIDIA

  - Jeff Bolz, NVIDIA

  - Eric Werness, NVIDIA

  - Daniel Koch, NVIDIA

#### Description

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

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

#### New Commands

- vkCmdSetCheckpointNV

- vkGetQueueCheckpointDataNV

#### New Structures

- VkCheckpointDataNV

- Extending VkQueueFamilyProperties2:

  - VkQueueFamilyCheckpointPropertiesNV

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Kedarnath Thangudu kthangudu

#### Other Extension Metadata

Last Modified Date

  2022-04-06

Contributors

  - Kedarnath Thangudu, NVIDIA

  - Thomas Klein, NVIDIA

#### Description

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

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

#### New Structures

- Extending VkDeviceCreateInfo:

  - VkDeviceDiagnosticsConfigCreateInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDiagnosticsConfigFeaturesNV

#### New Enums

- VkDeviceDiagnosticsConfigFlagBitsNV

#### New Bitmasks

- VkDeviceDiagnosticsConfigFlagsNV

#### New Enum Constants

- `VK_NV_DEVICE_DIAGNOSTICS_CONFIG_EXTENSION_NAME`

- `VK_NV_DEVICE_DIAGNOSTICS_CONFIG_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_DIAGNOSTICS_CONFIG_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DIAGNOSTICS_CONFIG_FEATURES_NV`

#### Version History

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

  - Internal revisions

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

  - Added a config bit `VK_DEVICE_DIAGNOSTICS_CONFIG_ENABLE_SHADER_ERROR_REPORTING_BIT_NV`

#### VK_NV_device_generated_commands

Name String

  `VK_NV_device_generated_commands`

Extension Type

  Device extension

Registered Extension Number

  278

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_buffer_device_address` to be enabled for any device-level functionality

Contact

  - Christoph Kubisch pixeljetstream

#### Other Extension Metadata

Last Modified Date

  2020-02-20

Interactions and External Dependencies

  - This extension requires Vulkan 1.1

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

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

Contributors

  - Christoph Kubisch, NVIDIA

  - Pierre Boudier, NVIDIA

  - Jeff Bolz, NVIDIA

  - Eric Werness, NVIDIA

  - Yuriy O’Donnell, Epic Games

  - Baldur Karlsson, Valve

  - Mathias Schott, NVIDIA

  - Tyson Smith, NVIDIA

  - Ingo Esser, NVIDIA

#### Description

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

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

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

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

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

- create `VkBuffer` objects and retrieve physical addresses from them via vkGetBufferDeviceAddressEXT

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

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

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

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

- optionally preprocess the generated content using vkCmdPreprocessGeneratedCommandsNV, for example on an asynchronous compute queue, or for the purpose of 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

- VkIndirectCommandsLayoutNV

#### New Commands

- vkCmdBindPipelineShaderGroupNV

- vkCmdExecuteGeneratedCommandsNV

- vkCmdPreprocessGeneratedCommandsNV

- vkCreateIndirectCommandsLayoutNV

- vkDestroyIndirectCommandsLayoutNV

- vkGetGeneratedCommandsMemoryRequirementsNV

#### New Structures

- VkBindIndexBufferIndirectCommandNV

- VkBindShaderGroupIndirectCommandNV

- VkBindVertexBufferIndirectCommandNV

- VkGeneratedCommandsInfoNV

- VkGeneratedCommandsMemoryRequirementsInfoNV

- VkGraphicsShaderGroupCreateInfoNV

- VkIndirectCommandsLayoutCreateInfoNV

- VkIndirectCommandsLayoutTokenNV

- VkIndirectCommandsStreamNV

- VkSetStateFlagsIndirectCommandNV

- Extending VkGraphicsPipelineCreateInfo:

  - VkGraphicsPipelineShaderGroupsCreateInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDeviceGeneratedCommandsFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDeviceGeneratedCommandsPropertiesNV

#### New Enums

- VkIndirectCommandsLayoutUsageFlagBitsNV

- VkIndirectCommandsTokenTypeNV

- VkIndirectStateFlagBitsNV

#### New Bitmasks

- VkIndirectCommandsLayoutUsageFlagsNV

- VkIndirectStateFlagsNV

#### New Enum Constants

- `VK_NV_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME`

- `VK_NV_DEVICE_GENERATED_COMMANDS_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV`

  - `VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_INDIRECT_COMMANDS_LAYOUT_NV`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_INDIRECT_BINDABLE_BIT_NV`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_NV`

  - `VK_STRUCTURE_TYPE_GENERATED_COMMANDS_MEMORY_REQUIREMENTS_INFO_NV`

  - `VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_SHADER_GROUPS_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_GRAPHICS_SHADER_GROUP_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_TOKEN_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEVICE_GENERATED_COMMANDS_PROPERTIES_NV`

#### Issues

1) How to name this extension ?

`VK_NV_device_generated_commands`

As usual, one of the hardest issues ;)

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

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

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

3) How to name a sequence description?

`VkIndirectCommandsLayout` as in the NVX extension predecessor.

Alternative: `VkGeneratedCommandsLayout`

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

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

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

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

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

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

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

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

When making use of Graphics Shader Groups, the programs should behave 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`

- VkGeneratedCommandsInfoNV::`preprocessBuffer`

- VkGeneratedCommandsInfoNV::`sequencesCountBuffer`

- VkGeneratedCommandsInfoNV::`sequencesIndexBuffer`

- VkIndirectCommandsStreamNV::`buffer`

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

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

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

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

- `dstStageMask` = `VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV`

- `dstAccessMask` = `VK_ACCESS_COMMAND_PREPROCESS_READ_BIT_NV`

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

- `srcStageMask` = `VK_PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV`

- `srcAccessMask` = `VK_ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV`

- `dstStageMask` = `VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT`

- `dstAccessMask` = `VK_ACCESS_INDIRECT_COMMAND_READ_BIT`

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

- `dstStageMask` = `VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT`

- `dstAccessMask` = `VK_ACCESS_INDIRECT_COMMAND_READ_BIT`

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

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

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

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

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

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

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

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

- The VkIndirectStateFlagBitsNV were introduced

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

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

16) Do we need more shader group state overrides?

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

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

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

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

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

18) Is there an interaction with VK_KHR_pipeline_library planned?

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

#### Example Code

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

https://github.com/nvpro-samples/vk_device_generated_cmds

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory` to be enabled for any device-level functionality

Contact

  - Carsten Rohde crohde

#### Other Extension Metadata

Last Modified Date

  2021-04-19

IP Status

  No known IP claims.

Contributors

  - Carsten Rohde, NVIDIA

#### Description

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

#### New Base Types

- `VkRemoteAddressNV`

#### New Commands

- vkGetMemoryRemoteAddressNV

#### New Structures

- VkMemoryGetRemoteAddressInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceExternalMemoryRDMAFeaturesNV

#### New Enum Constants

- `VK_NV_EXTERNAL_MEMORY_RDMA_EXTENSION_NAME`

- `VK_NV_EXTERNAL_MEMORY_RDMA_SPEC_VERSION`

- Extending VkExternalMemoryHandleTypeFlagBits:

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_RDMA_ADDRESS_BIT_NV`

- Extending VkMemoryPropertyFlagBits:

  - `VK_MEMORY_PROPERTY_RDMA_CAPABLE_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MEMORY_GET_REMOTE_ADDRESS_INFO_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_MEMORY_RDMA_FEATURES_NV`

#### Issues

#### Examples

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

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

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

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

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

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

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

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

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

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

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

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

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

#### Version History

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

  - Internal revisions

#### VK_NV_fill_rectangle

Name String

  `VK_NV_fill_rectangle`

Extension Type

  Device extension

Registered Extension Number

  154

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-05-22

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension adds a new VkPolygonMode `enum` where a triangle is rasterized by computing and filling its axis-aligned screen-space bounding box, disregarding the actual triangle edges. This can be useful for drawing a rectangle without being split into two triangles with an internal edge. It is also useful to minimize the number of primitives that need to be drawn, particularly for a user interface.

#### New Enum Constants

- `VK_NV_FILL_RECTANGLE_EXTENSION_NAME`

- `VK_NV_FILL_RECTANGLE_SPEC_VERSION`

- Extending VkPolygonMode:

  - `VK_POLYGON_MODE_FILL_RECTANGLE_NV`

#### Version History

- Revision 1, 2017-05-22 (Jeff Bolz)

  - Internal revisions

#### VK_NV_fragment_coverage_to_color

Name String

  `VK_NV_fragment_coverage_to_color`

Extension Type

  Device extension

Registered Extension Number

  150

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-05-21

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension allows the fragment coverage value, represented as an integer bitmask, to be substituted for a color output being written to a single-component color attachment with integer components (e.g. `VK_FORMAT_R8_UINT`). The functionality provided by this extension is different from simply writing the `SampleMask` fragment shader output, in that the coverage value written to the framebuffer is taken after stencil test and depth test, as well as after fragment operations such as alpha-to-coverage.

This functionality may be useful for deferred rendering algorithms, where the second pass needs to know which samples belong to which original fragments.

#### New Structures

- Extending VkPipelineMultisampleStateCreateInfo:

  - VkPipelineCoverageToColorStateCreateInfoNV

#### New Bitmasks

- VkPipelineCoverageToColorStateCreateFlagsNV

#### New Enum Constants

- `VK_NV_FRAGMENT_COVERAGE_TO_COLOR_EXTENSION_NAME`

- `VK_NV_FRAGMENT_COVERAGE_TO_COLOR_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_TO_COLOR_STATE_CREATE_INFO_NV`

#### Version History

- Revision 1, 2017-05-21 (Jeff Bolz)

  - Internal revisions

#### VK_NV_fragment_shading_rate_enums

Name String

  `VK_NV_fragment_shading_rate_enums`

Extension Type

  Device extension

Registered Extension Number

  327

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_fragment_shading_rate` to be enabled for any device-level functionality

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2020-09-02

Contributors

  - Pat Brown, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

This extension builds on the fragment shading rate functionality provided by the VK_KHR_fragment_shading_rate extension, adding support for “supersample” fragment shading rates that trigger multiple fragment shader invocations per pixel as well as a “no invocations” shading rate that discards any portions of a primitive that would use that shading rate.

#### New Commands

- vkCmdSetFragmentShadingRateEnumNV

#### New Structures

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineFragmentShadingRateEnumStateCreateInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShadingRateEnumsFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentShadingRateEnumsPropertiesNV

#### New Enums

- VkFragmentShadingRateNV

- VkFragmentShadingRateTypeNV

#### New Enum Constants

- `VK_NV_FRAGMENT_SHADING_RATE_ENUMS_EXTENSION_NAME`

- `VK_NV_FRAGMENT_SHADING_RATE_ENUMS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADING_RATE_ENUMS_PROPERTIES_NV`

  - `VK_STRUCTURE_TYPE_PIPELINE_FRAGMENT_SHADING_RATE_ENUM_STATE_CREATE_INFO_NV`

#### Issues

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-06-04

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension allows multisample rendering with a raster and depth/stencil sample count that is larger than the color sample count. Rasterization and the results of the depth and stencil tests together determine the portion of a pixel that is “covered”. It can be useful to evaluate coverage at a higher frequency than color samples are stored. This coverage is then “reduced” to a collection of covered color samples, each having an opacity value corresponding to the fraction of the color sample covered. The opacity can optionally be blended into individual color samples.

Rendering with fewer color samples than depth/stencil samples greatly reduces the amount of memory and bandwidth consumed by the color buffer. However, converting the coverage values into opacity introduces artifacts where triangles share edges and may not be suitable for normal triangle mesh rendering.

One expected use case for this functionality is Stencil-then-Cover path rendering (similar to the OpenGL GL_NV_path_rendering extension). The stencil step determines the coverage (in the stencil buffer) for an entire path at the higher sample frequency, and then the cover step draws the path into the lower frequency color buffer using the coverage information to antialias path edges. With this two-step process, internal edges are fully covered when antialiasing is applied and there is no corruption on these edges.

The key features of this extension are:

- It allows render pass and framebuffer objects to be created where the number of samples in the depth/stencil attachment in a subpass is a multiple of the number of samples in the color attachments in the subpass.

- A coverage reduction step is added to Fragment Operations which converts a set of covered raster/depth/stencil samples to a set of color samples that perform blending and color writes. The coverage reduction step also includes an optional coverage modulation step, multiplying color values by a fractional opacity corresponding to the number of associated raster/depth/stencil samples covered.

#### New Structures

- Extending VkPipelineMultisampleStateCreateInfo:

  - VkPipelineCoverageModulationStateCreateInfoNV

#### New Enums

- VkCoverageModulationModeNV

#### New Bitmasks

- VkPipelineCoverageModulationStateCreateFlagsNV

#### New Enum Constants

- `VK_NV_FRAMEBUFFER_MIXED_SAMPLES_EXTENSION_NAME`

- `VK_NV_FRAMEBUFFER_MIXED_SAMPLES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2017-02-15

Interactions and External Dependencies

  - This extension requires `SPV_NV_geometry_shader_passthrough`

  - This extension provides API support for `GL_NV_geometry_shader_passthrough`

  - This extension requires the `geometryShader` feature.

Contributors

  - Piers Daniell, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

- `SPV_NV_geometry_shader_passthrough`

Geometry shaders provide the ability for applications to process each primitive sent through the graphics pipeline using a programmable shader. However, one common use case treats them largely as a “passthrough”. In this use case, the bulk of the geometry shader code simply copies inputs from each vertex of the input primitive to corresponding outputs in the vertices of the output primitive. Such shaders might also compute values for additional built-in or user-defined per-primitive attributes (e.g., `Layer`) to be assigned to all the vertices of the output primitive.

This extension provides access to the `PassthroughNV` decoration under the `GeometryShaderPassthroughNV` capability. Adding this to a geometry shader input variable specifies that the values of this input are copied to the corresponding vertex of the output primitive.

When using GLSL source-based shading languages, the `passthrough` layout qualifier from `GL_NV_geometry_shader_passthrough` maps to the `PassthroughNV` decoration. To use the `passthrough` layout, in GLSL the `GL_NV_geometry_shader_passthrough` extension must be enabled. 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

- `PassthroughNV` in Geometry Shader Passthrough

#### New SPIR-V Capabilities

- `GeometryShaderPassthroughNV`

#### Issues

1) Should we require or allow a passthrough geometry shader to specify the output layout qualifiers for the output primitive type and maximum vertex count in the SPIR-V?

RESOLVED: Yes they should be required in the SPIR-V. Per GL_NV_geometry_shader_passthrough they are not permitted in the GLSL source shader, but SPIR-V is lower-level. It is straightforward for the GLSL compiler to infer them from the input primitive type and to explicitly emit them in the SPIR-V according to the following table.

Input Layout | Implied Output Layout
--- | ---
points | `layout(points, max_vertices=1)`
lines | `layout(line_strip, max_vertices=2)`
triangles | `layout(triangle_strip, max_vertices=3)`

2) How does interface matching work with passthrough geometry shaders?

RESOLVED: This is described in Passthrough Interface Matching. In GL when using 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - David Zhao Akeley akeley98

#### Other Extension Metadata

Last Modified Date

  2021-02-04

Contributors

  - David Zhao Akeley, NVIDIA

  - Jeff Bolz, NVIDIA

  - Piers Daniell, NVIDIA

  - Christoph Kubisch, NVIDIA

#### Description

This extension adds the ability for a secondary command buffer to inherit the dynamic viewport and scissor state from a primary command buffer, or a previous secondary command buffer executed within the same vkCmdExecuteCommands call. It addresses a frequent scenario in applications that deal with window resizing and want to improve utilization of 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 Structures

- Extending VkCommandBufferInheritanceInfo:

  - VkCommandBufferInheritanceViewportScissorInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceInheritedViewportScissorFeaturesNV

#### New Enum Constants

- `VK_NV_INHERITED_VIEWPORT_SCISSOR_EXTENSION_NAME`

- `VK_NV_INHERITED_VIEWPORT_SCISSOR_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_VIEWPORT_SCISSOR_INFO_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INHERITED_VIEWPORT_SCISSOR_FEATURES_NV`

#### Issues

(1) Why are viewport depth values configured in the VkCommandBufferInheritanceViewportScissorInfoNV struct, rather than by 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - sourav parmar souravpNV

#### Other Extension Metadata

Last Modified Date

  2021-12-02

Interactions and External Dependencies

  - This extension requires `VK_KHR_format_feature_flags2`

Contributors

  - Pat Brown, NVIDIA

  - Piers Daniell, NVIDIA

  - Sourav Parmar, NVIDIA

#### Description

This extension expands support for using `VK_IMAGE_TILING_LINEAR` images as color attachments when all the color attachments in the render pass instance have `VK_IMAGE_TILING_LINEAR` tiling. This extension adds a new flag bit `VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV` that extends the existing VkFormatFeatureFlagBits2KHR bits. This flag can be set for renderable color formats in the VkFormatProperties3KHR::`linearTilingFeatures` format properties structure member. Formats with the `VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV` flag may be used as color attachments as long as all the color attachments in the render pass instance have `VK_IMAGE_TILING_LINEAR` tiling, and the formats their images views are created with have VkFormatProperties3KHR::`linearTilingFeatures` which include `VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV`. This extension supports both dynamic rendering and traditional render passes.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceLinearColorAttachmentFeaturesNV

#### New Enum Constants

- `VK_NV_LINEAR_COLOR_ATTACHMENT_EXTENSION_NAME`

- `VK_NV_LINEAR_COLOR_ATTACHMENT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_LINEAR_COLOR_ATTACHMENT_FEATURES_NV`

If VK_KHR_format_feature_flags2 is supported:

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_LINEAR_COLOR_ATTACHMENT_BIT_NV`

#### Version History

- Revision 1, 2021-11-29 (sourav parmar)

  - Initial draft

#### VK_NV_mesh_shader

Name String

  `VK_NV_mesh_shader`

Extension Type

  Device extension

Registered Extension Number

  203

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Christoph Kubisch pixeljetstream

#### Other Extension Metadata

Last Modified Date

  2018-07-19

Interactions and External Dependencies

  - This extension requires `SPV_NV_mesh_shader`

  - This extension provides API support for `GLSL_NV_mesh_shader`

Contributors

  - Pat Brown, NVIDIA

  - Jeff Bolz, NVIDIA

  - Daniel Koch, NVIDIA

  - Piers Daniell, NVIDIA

  - Pierre Boudier, NVIDIA

#### Description

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

There are new programmable shader types — the task and mesh shader — to generate these collections to be processed by fixed-function primitive assembly and rasterization logic. When task and mesh shaders are dispatched, they replace the core pre-rasterization stages, including vertex array attribute fetching, vertex shader processing, tessellation, and geometry shader processing.

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

- `SPV_NV_mesh_shader`

#### New Commands

- vkCmdDrawMeshTasksIndirectCountNV

- vkCmdDrawMeshTasksIndirectNV

- vkCmdDrawMeshTasksNV

#### New Structures

- VkDrawMeshTasksIndirectCommandNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMeshShaderFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMeshShaderPropertiesNV

#### New Enum Constants

- `VK_NV_MESH_SHADER_EXTENSION_NAME`

- `VK_NV_MESH_SHADER_SPEC_VERSION`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_MESH_SHADER_BIT_NV`

  - `VK_PIPELINE_STAGE_TASK_SHADER_BIT_NV`

- Extending VkShaderStageFlagBits:

  - `VK_SHADER_STAGE_MESH_BIT_NV`

  - `VK_SHADER_STAGE_TASK_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MESH_SHADER_PROPERTIES_NV`

#### New or Modified Built-In Variables

- TaskCountNV

- PrimitiveCountNV

- PrimitiveIndicesNV

- ClipDistancePerViewNV

- CullDistancePerViewNV

- LayerPerViewNV

- MeshViewCountNV

- MeshViewIndicesNV

- (modified)`Position`

- (modified)`PointSize`

- (modified)`ClipDistance`

- (modified)`CullDistance`

- (modified)`PrimitiveId`

- (modified)`Layer`

- (modified)`ViewportIndex`

- (modified)`WorkgroupSize`

- (modified)`WorkgroupId`

- (modified)`LocalInvocationId`

- (modified)`GlobalInvocationId`

- (modified)`LocalInvocationIndex`

- (modified)`DrawIndex`

- (modified)`ViewportMaskNV`

- (modified)`PositionPerViewNV`

- (modified)`ViewportMaskPerViewNV`

#### New SPIR-V Capability

- `MeshShadingNV`

#### Issues

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_ray_tracing

Name String

  `VK_NV_ray_tracing`

Extension Type

  Device extension

Registered Extension Number

  166

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_memory_requirements2` to be enabled for any device-level functionality

Contact

  - Eric Werness ewerness-nv

#### Other Extension Metadata

Last Modified Date

  2018-11-20

Interactions and External Dependencies

  - This extension requires `SPV_NV_ray_tracing`

  - This extension provides API support for `GL_NV_ray_tracing`

Contributors

  - Eric Werness, NVIDIA

  - Ashwin Lele, NVIDIA

  - Robert Stepinski, NVIDIA

  - Nuno Subtil, NVIDIA

  - Christoph Kubisch, NVIDIA

  - Martin Stich, NVIDIA

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

  - Joshua Barczak, Intel

  - Tobias Hector, AMD

  - Henrik Rydgard, NVIDIA

  - Pascal Gautron, NVIDIA

#### Description

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

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

- Acceleration structure objects and build commands

- A new pipeline type with new shader domains

- An indirection table to link shader groups with acceleration structure items

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

- `SPV_NV_ray_tracing`

#### New Object Types

- VkAccelerationStructureNV

#### New Commands

- vkBindAccelerationStructureMemoryNV

- vkCmdBuildAccelerationStructureNV

- vkCmdCopyAccelerationStructureNV

- vkCmdTraceRaysNV

- vkCmdWriteAccelerationStructuresPropertiesNV

- vkCompileDeferredNV

- vkCreateAccelerationStructureNV

- vkCreateRayTracingPipelinesNV

- vkDestroyAccelerationStructureNV

- vkGetAccelerationStructureHandleNV

- vkGetAccelerationStructureMemoryRequirementsNV

- vkGetRayTracingShaderGroupHandlesNV

#### New Structures

- VkAabbPositionsNV

- VkAccelerationStructureCreateInfoNV

- VkAccelerationStructureInfoNV

- VkAccelerationStructureInstanceNV

- VkAccelerationStructureMemoryRequirementsInfoNV

- VkBindAccelerationStructureMemoryInfoNV

- VkGeometryAABBNV

- VkGeometryDataNV

- VkGeometryNV

- VkGeometryTrianglesNV

- VkMemoryRequirements2KHR

- VkRayTracingPipelineCreateInfoNV

- VkRayTracingShaderGroupCreateInfoNV

- VkTransformMatrixNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceRayTracingPropertiesNV

- Extending VkWriteDescriptorSet:

  - VkWriteDescriptorSetAccelerationStructureNV

#### New Enums

- VkAccelerationStructureMemoryRequirementsTypeNV

- VkAccelerationStructureTypeNV

- VkBuildAccelerationStructureFlagBitsNV

- VkCopyAccelerationStructureModeNV

- VkGeometryFlagBitsNV

- VkGeometryInstanceFlagBitsNV

- VkGeometryTypeNV

- VkRayTracingShaderGroupTypeNV

#### New Bitmasks

- VkBuildAccelerationStructureFlagsNV

- VkGeometryFlagsNV

- VkGeometryInstanceFlagsNV

#### New Enum Constants

- `VK_NV_RAY_TRACING_EXTENSION_NAME`

- `VK_NV_RAY_TRACING_SPEC_VERSION`

- `VK_SHADER_UNUSED_NV`

- Extending VkAccelerationStructureTypeKHR:

  - `VK_ACCELERATION_STRUCTURE_TYPE_BOTTOM_LEVEL_NV`

  - `VK_ACCELERATION_STRUCTURE_TYPE_TOP_LEVEL_NV`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_ACCELERATION_STRUCTURE_READ_BIT_NV`

  - `VK_ACCESS_ACCELERATION_STRUCTURE_WRITE_BIT_NV`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_RAY_TRACING_BIT_NV`

- Extending VkBuildAccelerationStructureFlagBitsKHR:

  - `VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_COMPACTION_BIT_NV`

  - `VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_UPDATE_BIT_NV`

  - `VK_BUILD_ACCELERATION_STRUCTURE_LOW_MEMORY_BIT_NV`

  - `VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_BUILD_BIT_NV`

  - `VK_BUILD_ACCELERATION_STRUCTURE_PREFER_FAST_TRACE_BIT_NV`

- Extending VkCopyAccelerationStructureModeKHR:

  - `VK_COPY_ACCELERATION_STRUCTURE_MODE_CLONE_NV`

  - `VK_COPY_ACCELERATION_STRUCTURE_MODE_COMPACT_NV`

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_ACCELERATION_STRUCTURE_NV_EXT`

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

#### New or Modified Built-In Variables

- `LaunchIdNV`

- `LaunchSizeNV`

- `WorldRayOriginNV`

- `WorldRayDirectionNV`

- `ObjectRayOriginNV`

- `ObjectRayDirectionNV`

- `RayTminNV`

- `RayTmaxNV`

- `InstanceCustomIndexNV`

- `InstanceId`

- `ObjectToWorldNV`

- `WorldToObjectNV`

- `HitTNV`

- `HitKindNV`

- `IncomingRayFlagsNV`

- (modified)`PrimitiveId`

#### New SPIR-V Capabilities

- `RayTracingNV`

#### Issues

1) Are there issues?

RESOLVED: Yes.

#### Sample Code

Example ray generation GLSL shader

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

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

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

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

       col.y = payload;

       imageStore(image, ivec2(gl_LaunchIDNV.xy), col);
    }

#### Version History

- Revision 1, 2018-09-11 (Robert Stepinski, Nuno Subtil, Eric Werness)

  - Internal revisions

- Revision 2, 2018-10-19 (Eric Werness)

  - rename to VK_NV_ray_tracing, add support for callables.

  - too many updates to list

- Revision 3, 2018-11-20 (Daniel Koch)

  - update to use InstanceId instead of InstanceIndex as implemented.

#### VK_NV_ray_tracing_motion_blur

Name String

  `VK_NV_ray_tracing_motion_blur`

Extension Type

  Device extension

Registered Extension Number

  328

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_ray_tracing_pipeline` to be enabled for any device-level functionality

Contact

  - Eric Werness

#### Other Extension Metadata

Last Modified Date

  2021-06-16

Interactions and External Dependencies

  - This extension requires `SPV_NV_ray_tracing_motion_blur`

  - This extension provides API support for `GL_NV_ray_tracing_motion_blur`

Contributors

  - Eric Werness, NVIDIA

  - Ashwin Lele, NVIDIA

#### Description

Ray tracing support in the API provides an efficient mechanism to intersect rays against static geometry, but rendering algorithms often want to support motion, which is more efficiently supported with motion-specific algorithms. This extension adds a set of mechanisms to support fast tracing of moving geometry:

- A ray pipeline trace call which takes a time parameter

- Flags to enable motion support in an acceleration structure

- Support for time-varying vertex positions in a geometry

- Motion instances to move existing instances over time

The motion represented here is parameterized across a normalized timestep between 0.0 and 1.0. A motion trace using `OpTraceRayMotionNV` provides a time within that normalized range to be used when intersecting that ray with geometry. The geometry can be provided with motion by a combination of adding a second vertex position for time of 1.0 using `VkAccelerationStructureGeometryMotionTrianglesDataNV` and providing multiple transforms in the instance using `VkAccelerationStructureMotionInstanceNV`.

#### New Structures

- VkAccelerationStructureMatrixMotionInstanceNV

- VkAccelerationStructureMotionInstanceNV

- VkAccelerationStructureSRTMotionInstanceNV

- VkSRTDataNV

- Extending VkAccelerationStructureCreateInfoKHR:

  - VkAccelerationStructureMotionInfoNV

- Extending VkAccelerationStructureGeometryTrianglesDataKHR:

  - VkAccelerationStructureGeometryMotionTrianglesDataNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRayTracingMotionBlurFeaturesNV

#### New Unions

- VkAccelerationStructureMotionInstanceDataNV

#### New Enums

- VkAccelerationStructureMotionInstanceTypeNV

#### New Bitmasks

- VkAccelerationStructureMotionInfoFlagsNV

- VkAccelerationStructureMotionInstanceFlagsNV

#### New Enum Constants

- `VK_NV_RAY_TRACING_MOTION_BLUR_EXTENSION_NAME`

- `VK_NV_RAY_TRACING_MOTION_BLUR_SPEC_VERSION`

- Extending VkAccelerationStructureCreateFlagBitsKHR:

  - `VK_ACCELERATION_STRUCTURE_CREATE_MOTION_BIT_NV`

- Extending VkBuildAccelerationStructureFlagBitsKHR:

  - `VK_BUILD_ACCELERATION_STRUCTURE_MOTION_BIT_NV`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_RAY_TRACING_ALLOW_MOTION_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_GEOMETRY_MOTION_TRIANGLES_DATA_NV`

  - `VK_STRUCTURE_TYPE_ACCELERATION_STRUCTURE_MOTION_INFO_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAY_TRACING_MOTION_BLUR_FEATURES_NV`

#### Issues

(1) What size is VkAccelerationStructureMotionInstanceNV?

- Added a note on the structure size and made the stride explicit in the language.

(2) Allow arrayOfPointers for motion TLAS?

- Yes, with a packed encoding to minimize the amount of data sent for metadata.

#### Version History

- Revision 1, 2020-06-16 (Eric Werness, Ashwin Lele)

  - Initial external release

#### VK_NV_representative_fragment_test

Name String

  `VK_NV_representative_fragment_test`

Extension Type

  Device extension

Registered Extension Number

  167

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Kedarnath Thangudu kthangudu

#### Other Extension Metadata

Last Modified Date

  2018-09-13

Contributors

  - Kedarnath Thangudu, NVIDIA

  - Christoph Kubisch, NVIDIA

  - Pierre Boudier, NVIDIA

  - Pat Brown, NVIDIA

  - Jeff Bolz, NVIDIA

  - Eric Werness, NVIDIA

#### Description

This extension provides a new representative fragment test that allows implementations to reduce the amount of rasterization and fragment processing work performed for each point, line, or triangle primitive. For any primitive that produces one or more fragments that pass all other early fragment tests, the implementation is permitted to choose one or more “representative” fragments for processing and discard all other fragments. For draw calls rendering multiple points, lines, or triangles arranged in lists, strips, or fans, the representative fragment test is performed independently for each of those primitives.

This extension is useful for applications that use an early render pass to determine the full set of primitives that would be visible in the final scene. In this render pass, such applications would set up a fragment shader that enables early fragment tests and writes to an image or shader storage buffer to record the ID of the primitive that generated the fragment. Without this extension, the shader would record the ID separately for each visible fragment of each primitive. With this extension, fewer stores will be performed, particularly for large primitives.

The representative fragment test has no effect if early fragment tests are not enabled via the fragment shader. The set of fragments discarded by the representative fragment test is implementation-dependent and may vary from frame to frame. In some cases, the representative fragment test may not discard any fragments for a given primitive.

#### New Structures

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineRepresentativeFragmentTestStateCreateInfoNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRepresentativeFragmentTestFeaturesNV

#### New Enum Constants

- `VK_NV_REPRESENTATIVE_FRAGMENT_TEST_EXTENSION_NAME`

- `VK_NV_REPRESENTATIVE_FRAGMENT_TEST_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_REPRESENTATIVE_FRAGMENT_TEST_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PIPELINE_REPRESENTATIVE_FRAGMENT_TEST_STATE_CREATE_INFO_NV`

#### Issues

(1) Is the representative fragment test guaranteed to have any effect?

RESOLVED: No. As specified, we only guarantee that each primitive with at least one fragment that passes prior tests will have one fragment passing the representative fragment tests. We do not guarantee that any particular fragment will fail the test.

In the initial implementation of this extension, the representative fragment test is treated as an optimization that may be completely disabled for some pipeline states. This feature was designed for a use case where the fragment shader records information on individual primitives using shader storage buffers or storage images, with no writes to color or depth buffers.

(2) Will the set of fragments that pass the representative fragment test be repeatable if you draw the same scene over and over again?

RESOLVED: No. The set of fragments that pass the representative fragment test is implementation-dependent and may vary due to the timing of operations performed by the GPU.

(3) What happens if you enable the representative fragment test with writes to color and/or depth render targets enabled?

RESOLVED: If writes to the color or depth buffer are enabled, they will be performed for any fragments that survive the relevant tests. Any fragments that fail the representative fragment test will not update color buffers. For the use cases intended for this feature, we do not expect color or depth writes to be enabled.

(4) How do derivatives and automatic texture level of detail computations work with the representative fragment test enabled?

RESOLVED: If a fragment shader uses derivative functions or texture lookups using automatic level of detail 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2016-12-08

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_NV_sample_mask_override_coverage`

  - This extension provides API support for `GL_NV_sample_mask_override_coverage`

Contributors

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

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

- `SPV_NV_sample_mask_override_coverage`

The extension provides access to the `OverrideCoverageNV` decoration under the `SampleMaskOverrideCoverageNV` capability. Adding this decoration to a variable with the `SampleMask` builtin decoration allows the shader to modify the coverage mask and affect which samples are used to process the fragment.

When using GLSL source-based shader languages, the `override_coverage` layout qualifier from `GL_NV_sample_mask_override_coverage` maps to the `OverrideCoverageNV` decoration. To use the `override_coverage` layout qualifier in GLSL the `GL_NV_sample_mask_override_coverage` extension must be enabled. Behavior is described in the `GL_NV_sample_mask_override_coverage` extension spec.

#### New Enum Constants

- `VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_EXTENSION_NAME`

- `VK_NV_SAMPLE_MASK_OVERRIDE_COVERAGE_SPEC_VERSION`

#### New Variable Decoration

- OverrideCoverageNV in SampleMask

#### New SPIR-V Capabilities

- `SampleMaskOverrideCoverageNV`

#### Version History

- Revision 1, 2016-12-08 (Piers Daniell)

  - Internal revisions

#### VK_NV_scissor_exclusive

Name String

  `VK_NV_scissor_exclusive`

Extension Type

  Device extension

Registered Extension Number

  206

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2018-07-31

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.

#### New Commands

- vkCmdSetExclusiveScissorNV

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceExclusiveScissorFeaturesNV

- Extending VkPipelineViewportStateCreateInfo:

  - VkPipelineViewportExclusiveScissorStateCreateInfoNV

#### New Enum Constants

- `VK_NV_SCISSOR_EXCLUSIVE_EXTENSION_NAME`

- `VK_NV_SCISSOR_EXCLUSIVE_SPEC_VERSION`

- Extending VkDynamicState:

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2018-09-13

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_NV_shader_image_footprint`

  - This extension provides API support for `GL_NV_shader_texture_footprint`

Contributors

  - Pat Brown, NVIDIA

  - Chris Lentini, NVIDIA

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

This extension adds Vulkan support for the `SPV_NV_shader_image_footprint` SPIR-V extension. That SPIR-V extension provides a new instruction `OpImageSampleFootprintNV` allowing shaders to determine the set of texels that would be accessed by an equivalent filtered texture lookup.

Instead of returning a filtered texture value, the instruction returns a structure that can be interpreted by shader code to determine the footprint of a filtered texture lookup. This structure includes integer values that identify a small neighborhood of texels in the image being accessed and a bitfield that indicates which texels in that neighborhood would be used. The structure also includes a bitfield where each bit identifies whether any texel in a small aligned block of texels would be fetched by the texture lookup. The size of each block is specified by an access granularity provided by the shader. The minimum granularity supported by this extension is 2x2 (for 2D textures) and 2x2x2 (for 3D textures); the maximum granularity is 256x256 (for 2D textures) or 64x32x32 (for 3D textures). Each footprint query returns the footprint from a single texture level. When using minification filters that combine accesses from multiple mipmap levels, shaders must perform separate queries for the two levels accessed (“fine” and “coarse”). The footprint query also returns a flag indicating if the texture lookup would access texels from only one mipmap level or from two neighboring levels.

This extension should be useful for multi-pass rendering operations that do an initial expensive rendering pass to produce a first image that is then used as a texture for a second pass. If the second pass ends up accessing only portions of the first image (e.g., due to visibility), the work spent rendering the non-accessed portion of the first image was wasted. With this feature, an application can limit this waste using an initial pass over the geometry in the second image that performs a footprint query for each visible pixel to determine the set of pixels that it needs from the first image. This pass would accumulate an aggregate footprint of all visible pixels into a separate “footprint image” using shader atomics. Then, when rendering the first image, the application can kill all shading work for pixels not in this aggregate footprint.

This extension has a number of limitations. The `OpImageSampleFootprintNV` instruction only supports for two- and three-dimensional textures. Footprint evaluation only supports the CLAMP_TO_EDGE wrap mode; results are 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderImageFootprintFeaturesNV

#### New Enum Constants

- `VK_NV_SHADER_IMAGE_FOOTPRINT_EXTENSION_NAME`

- `VK_NV_SHADER_IMAGE_FOOTPRINT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_IMAGE_FOOTPRINT_FEATURES_NV`

#### New SPIR-V Capability

- `ImageFootprintNV`

#### Issues

(1) The footprint returned by the SPIR-V instruction is a structure that includes an anchor, an offset, and a mask that represents a 8x8 or 4x4x4 neighborhood of texel groups. But the bits of the mask are not stored in simple pitch order. Why is the footprint built this way?

RESOLVED: We expect that applications using this feature will want to use a fixed granularity and accumulate coverage information from the returned footprints into an aggregate “footprint image” that tracks the portions of an image that would be needed by regular texture filtering. If an application is using a two-dimensional image with 4x4 pixel granularity, we expect that the footprint image will use 64-bit texels where each bit in an 8x8 array of bits corresponds to coverage for a 4x4 block in the original image. Texel (0,0) in the footprint image would correspond to texels (0,0) through (31,31) in the original image.

In the usual case, the footprint for a single access will fully contained in a 32x32 aligned region of the original texture, which corresponds to a single 64-bit texel in the footprint image. In that case, the implementation will return an anchor coordinate pointing at the single footprint image texel, an offset vector of (0,0), and a mask whose bits are aligned with the bits in the footprint texel. For this case, the shader can simply atomically OR the mask bits into the contents of the footprint texel to accumulate footprint coverage.

In the worst case, the footprint for a single access spans multiple 32x32 aligned regions and may require updates to four separate footprint image texels. In this case, the implementation will return an anchor coordinate pointing at the lower right footprint image texel and an offset will identify how many “columns” and “rows” of the returned 8x8 mask correspond to footprint texels to the left and above the anchor texel. If the anchor is (2,3), the 64 bits of the returned mask are arranged spatially as follows, where each 4x4 block is assigned a bit number that matches its bit number in the footprint image texels:

        +-------------------------+-------------------------+
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- 46 47 | 40 41 42 43 44 45 -- -- |
        | -- -- -- -- -- -- 54 55 | 48 49 50 51 52 53 -- -- |
        | -- -- -- -- -- -- 62 63 | 56 57 58 59 60 61 -- -- |
        +-------------------------+-------------------------+
        | -- -- -- -- -- -- 06 07 | 00 01 02 03 04 05 -- -- |
        | -- -- -- -- -- -- 14 15 | 08 09 10 11 12 13 -- -- |
        | -- -- -- -- -- -- 22 23 | 16 17 18 19 20 21 -- -- |
        | -- -- -- -- -- -- 30 31 | 24 25 26 27 28 29 -- -- |
        | -- -- -- -- -- -- 38 39 | 32 33 34 35 36 37 -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        | -- -- -- -- -- -- -- -- | -- -- -- -- -- -- -- -- |
        +-------------------------+-------------------------+

To accumulate coverage for each of the four footprint image texels, a shader can AND the returned mask with simple masks derived from the x and y offset values and then atomically OR the updated mask bits into the contents of the corresponding footprint texel.

        uint64_t returnedMask = (uint64_t(footprint.mask.x) | (uint64_t(footprint.mask.y) << 32));
        uint64_t rightMask    = ((0xFF >> footprint.offset.x) * 0x0101010101010101UL);
        uint64_t bottomMask   = 0xFFFFFFFFFFFFFFFFUL >> (8 * footprint.offset.y);
        uint64_t bottomRight  = returnedMask & bottomMask & rightMask;
        uint64_t bottomLeft   = returnedMask & bottomMask & (~rightMask);
        uint64_t topRight     = returnedMask & (~bottomMask) & rightMask;
        uint64_t topLeft      = returnedMask & (~bottomMask) & (~rightMask);

(2) What should an application do to ensure maximum performance when accumulating footprints into an aggregate footprint image?

RESOLVED: We expect that the most common usage of this feature will be to accumulate aggregate footprint coverage, as described in the previous issue. Even if you ignore the anisotropic filtering case where the implementation may return a granularity larger than that requested by the caller, each shader invocation will need to use atomic functions to update up to four footprint image texels for each level of detail 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2019-05-28

Interactions and External Dependencies

  - This extension requires `SPV_NV_shader_sm_builtins`.

  - This extension provides API support for `GL_NV_shader_sm_builtins`

Contributors

  - Jeff Bolz, NVIDIA

  - Eric Werness, NVIDIA

#### Description

This extension provides the ability to determine device-specific properties on NVIDIA GPUs. It provides the number of streaming multiprocessors (SMs), the maximum number of warps (subgroups) that can run on an SM, and shader builtins to enable invocations to identify which SM and warp a shader invocation is executing on.

This extension enables support for the SPIR-V `ShaderSMBuiltinsNV` capability.

These properties and built-ins should typically only be used for debugging purposes.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderSMBuiltinsFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShaderSMBuiltinsPropertiesNV

#### New Enum Constants

- `VK_NV_SHADER_SM_BUILTINS_EXTENSION_NAME`

- `VK_NV_SHADER_SM_BUILTINS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SM_BUILTINS_PROPERTIES_NV`

#### New or Modified Built-In Variables

- `WarpsPerSMNV`

- `SMCountNV`

- `WarpIDNV`

- `SMIDNV`

#### New SPIR-V Capabilities

- `ShaderSMBuiltinsNV`

#### Issues

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2018-03-17

Interactions and External Dependencies

  - This extension requires `SPV_NV_shader_subgroup_partitioned`

  - This extension provides API support for `GL_NV_shader_subgroup_partitioned`

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension enables support for a new class of group operations on subgroups via the `GL_NV_shader_subgroup_partitioned` GLSL extension and `SPV_NV_shader_subgroup_partitioned` SPIR-V extension. Support for these new operations is advertised via the `VK_SUBGROUP_FEATURE_PARTITIONED_BIT_NV` bit.

This extension requires Vulkan 1.1, for general subgroup support.

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2019-07-18

Interactions and External Dependencies

  - This extension requires `SPV_NV_shading_rate`

  - This extension provides API support for `GL_NV_shading_rate_image`

Contributors

  - Pat Brown, NVIDIA

  - Carsten Rohde, NVIDIA

  - Jeff Bolz, NVIDIA

  - Daniel Koch, NVIDIA

  - Mathias Schott, NVIDIA

  - Matthew Netsch, Qualcomm Technologies, Inc.

#### Description

This extension allows applications to use a variable shading rate when processing fragments of rasterized primitives. By default, Vulkan will spawn one fragment shader for each pixel covered by a primitive. In this extension, applications can bind a shading rate image that can be used to vary the number of fragment shader invocations across the framebuffer. Some portions of the screen may be configured to spawn up to 16 fragment shaders for each pixel, while other portions may use a single fragment shader invocation for a 4x4 block of pixels. This can be useful for use cases like eye tracking, where the portion of the framebuffer that the user is looking at directly can be processed at high frequency, while distant corners of the image can be processed at lower frequency. Each texel in the shading rate image represents a fixed-size rectangle in the framebuffer, covering 16x16 pixels in the initial implementation of this extension. When rasterizing a primitive covering one of these rectangles, the Vulkan implementation reads a texel in the bound shading rate image and looks up the fetched value in a palette to determine a base shading rate.

In addition to the API support controlling rasterization, this extension also adds Vulkan support for the `SPV_NV_shading_rate` extension to SPIR-V. That extension provides two fragment shader variable decorations that allow fragment shaders to determine the shading rate used for processing the fragment:

- `FragmentSizeNV`, which indicates the width and height of the set of pixels processed by the fragment shader.

- `InvocationsPerPixel`, which indicates the maximum number of fragment shader invocations that could be spawned for the pixel(s) covered by the fragment.

When using SPIR-V in conjunction with the OpenGL Shading Language (GLSL), the fragment shader capabilities are provided by the `GL_NV_shading_rate_image` language extension and correspond to the built-in variables `gl_FragmentSizeNV` and `gl_InvocationsPerPixelNV`, respectively.

#### New Commands

- vkCmdBindShadingRateImageNV

- vkCmdSetCoarseSampleOrderNV

- vkCmdSetViewportShadingRatePaletteNV

#### New Structures

- VkCoarseSampleLocationNV

- VkCoarseSampleOrderCustomNV

- VkShadingRatePaletteNV

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShadingRateImageFeaturesNV

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShadingRateImagePropertiesNV

- Extending VkPipelineViewportStateCreateInfo:

  - VkPipelineViewportCoarseSampleOrderStateCreateInfoNV

  - VkPipelineViewportShadingRateImageStateCreateInfoNV

#### New Enums

- VkCoarseSampleOrderTypeNV

- VkShadingRatePaletteEntryNV

#### New Enum Constants

- `VK_NV_SHADING_RATE_IMAGE_EXTENSION_NAME`

- `VK_NV_SHADING_RATE_IMAGE_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_VIEWPORT_COARSE_SAMPLE_ORDER_NV`

  - `VK_DYNAMIC_STATE_VIEWPORT_SHADING_RATE_PALETTE_NV`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_SHADING_RATE_OPTIMAL_NV`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_SHADING_RATE_IMAGE_BIT_NV`

- Extending VkPipelineStageFlagBits:

  - `VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_FEATURES_NV`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADING_RATE_IMAGE_PROPERTIES_NV`

  - `VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_COARSE_SAMPLE_ORDER_STATE_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SHADING_RATE_IMAGE_STATE_CREATE_INFO_NV`

#### Issues

(1) When using shading rates specifying “coarse” fragments covering multiple pixels, we will generate a combined coverage mask that combines the coverage masks of all pixels covered by the fragment. By default, these masks are combined in an implementation-dependent order. Should we provide a mechanism allowing applications to query or specify an exact order?

RESOLVED: Yes, this feature is useful for cases where most of the fragment shader can be evaluated once for an entire coarse fragment, but where some per-pixel computations are also required. For example, a per-pixel alpha test may want to kill all the samples for some pixels in a coarse fragment. This sort of test can be implemented using an output sample mask, but such a shader would need to know which bit in the mask corresponds to each sample in the coarse fragment. We are including a mechanism to allow applications to specify the orders of coverage samples for each shading rate and sample count, either as static pipeline state or dynamically via a command buffer. This portion of the extension has its own feature bit.

We will not be providing a query to determine the implementation-dependent default ordering. The thinking here is that if an application cares enough about the coarse fragment sample ordering to perform such a query, it could instead just set its own order, also using custom per-pixel sample locations if required.

(2) For the pipeline stage `VK_PIPELINE_STAGE_SHADING_RATE_IMAGE_BIT_NV`, should we specify a precise location in the pipeline the shading rate image is accessed (after geometry shading, but before the early fragment tests) or leave it under-specified in case there are other implementations that access the image in a different pipeline location?

RESOLVED We are specifying the pipeline stage to be between the final pre-rasterization shader stage (`VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT`) and before the first stage used for fragment processing (`VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT`), which seems to be the natural place to access the shading rate image.

(3) How do centroid-sampled variables work with fragments larger than one pixel?

RESOLVED For single-pixel fragments, fragment shader inputs decorated with `Centroid` are sampled at an implementation-dependent location in the intersection of the area of the primitive being rasterized and the area of the pixel that corresponds to the fragment. With multi-pixel fragments, we follow a similar pattern, using the intersection of the primitive and the set of pixels corresponding to the fragment.

One important thing to keep in mind when using such “coarse” shading rates is that fragment attributes are sampled at the center of the fragment by default, regardless of the set of pixels/samples covered by the fragment. For fragments with a size of 4x4 pixels, this center location will be more than two pixels (1.5 * sqrt(2)) away from the center of the pixels at the corners of the fragment. When rendering a primitive that covers only a small part of a coarse fragment, sampling a color outside the primitive can produce overly bright or dark color values if the color values have a large gradient. To deal with this, an application can use centroid sampling on attributes where “extrapolation” artifacts can lead to overly bright or dark pixels. Note that this same problem also exists for multisampling with single-pixel fragments, but is less severe because it only affects certain samples of a pixel and such bright/dark samples may be averaged with other samples that do not have a similar problem.

#### Version History

- Revision 3, 2019-07-18 (Mathias Schott)

  - Fully list extension interfaces in this appendix.

- Revision 2, 2018-09-13 (Pat Brown)

  - Miscellaneous edits preparing the specification for publication.

- Revision 1, 2018-08-08 (Pat Brown)

  - Internal revisions

#### VK_NV_viewport_array2

Name String

  `VK_NV_viewport_array2`

Extension Type

  Device extension

Registered Extension Number

  97

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Daniel Koch dgkoch

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

- (modified) `Layer`

- (modified) `ViewportIndex`

- `ViewportMaskNV`

#### New Variable Decoration

- `ViewportRelativeNV` in `Layer`

#### New SPIR-V Capabilities

- `ShaderViewportIndexLayerNV`

- `ShaderViewportMaskNV`

#### Version History

- Revision 1, 2017-02-15 (Daniel Koch)

  - Internal revisions

#### VK_NV_viewport_swizzle

Name String

  `VK_NV_viewport_swizzle`

Extension Type

  Device extension

Registered Extension Number

  99

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2016-12-22

Interactions and External Dependencies

  - This extension requires `multiViewport` and `geometryShader` features to be useful.

Contributors

  - Daniel Koch, NVIDIA

  - Jeff Bolz, NVIDIA

#### Description

This extension provides a new per-viewport swizzle that can modify the position of primitives sent to each viewport. New viewport swizzle state is added for each viewport, and a new position vector is computed for each vertex by selecting from and optionally negating any of the four components of the original position vector.

This new viewport swizzle is useful for a number of algorithms, including single-pass cube map rendering (broadcasting a primitive to multiple faces and reorienting the vertex position for each face) and voxel rasterization. The per-viewport component remapping and negation provided by the swizzle allows application code to re-orient three-dimensional geometry with a view along any of the 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 Structures

- VkViewportSwizzleNV

- Extending VkPipelineViewportStateCreateInfo:

  - VkPipelineViewportSwizzleStateCreateInfoNV

#### New Enums

- VkViewportCoordinateSwizzleNV

#### New Bitmasks

- VkPipelineViewportSwizzleStateCreateFlagsNV

#### New Enum Constants

- `VK_NV_VIEWPORT_SWIZZLE_EXTENSION_NAME`

- `VK_NV_VIEWPORT_SWIZZLE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_SWIZZLE_STATE_CREATE_INFO_NV`

#### Issues

1) Where does viewport swizzling occur in the pipeline?

RESOLVED: Despite being associated with the viewport, viewport swizzling must happen prior to the viewport transform. In particular, it needs to be performed before clipping and perspective division.

The viewport mask expansion (`VK_NV_viewport_array2`) and the viewport swizzle could potentially be performed before or after transform feedback, but feeding back several viewports worth of primitives with different swizzles does not seem particularly useful. This specification applies the viewport mask and swizzle after transform feedback, and makes primitive queries only count each primitive once.

2) Any interesting examples of how this extension, `VK_NV_viewport_array2`, and `VK_NV_geometry_shader_passthrough` can be used together in practice?

RESOLVED: One interesting use case for this extension is for single-pass rendering to a cube map. In this example, the application would attach a cube map texture to a layered FBO where the six cube faces are treated as layers. Vertices are sent through the vertex shader without applying a projection matrix, where the `gl_Position` output is (x,y,z,1) and the center of the cube map is at (0,0,0). With unextended Vulkan, one could have a conventional instanced geometry shader that looks something like the following:

    layout(invocations = 6) in;     // separate invocation per face
    layout(triangles) in;
    layout(triangle_strip) out;
    layout(max_vertices = 3) out;

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

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

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

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

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

        // Otherwise, emit a copy of the input primitive to the
        // appropriate face (using gl_Layer).
        for (int i = 0; i < 3; i++) {
            gl_Layer = face;
            gl_Position = positions[i];
            texcoord = v[i].texcoord;
            normal = v[i].normal;
            baseColor = v[i].baseColor;
            EmitVertex();
        }
    }

With passthrough geometry shaders, this can be done using a much simpler shader:

    layout(triangles) in;
    layout(passthrough) in Inputs {
        vec2 texcoord;
        vec3 normal;
        vec4 baseColor;
    }
    layout(passthrough) in gl_PerVertex {
        vec4 gl_Position;
    } gl_in[];
    layout(viewport_relative) out int gl_Layer;

    void main()
    {
        // Figure out which faces the primitive projects onto and
        // generate a corresponding viewport mask.
        uint mask = 0;
        for (int i = 0; i < 6; i++) {
            if (!shouldCull(face)) {
            mask |= 1U << i;
            }
        }
        gl_ViewportMask = mask;
        gl_Layer = 0;
    }

The application code is set up so that each of the six cube faces has a separate viewport (numbered 0 to 5). Each face also has a separate swizzle, programmed via the VkPipelineViewportSwizzleStateCreateInfoNV pipeline state. The viewport swizzle feature performs the coordinate transformation handled by the `rotate`() function in the original shader. The `viewport_relative` layout qualifier says that the viewport number (0 to 5) is added to the base `gl_Layer` value of 0 to determine which layer (cube face) the primitive should be sent to.

Note that the use of the passed through input `normal` in this example suggests that the fragment shader in this example would perform an operation like per-fragment lighting. The viewport swizzle would transform the position to be face-relative, but `normal` would remain in the original coordinate system. It seems likely that the fragment shader in either version of the example would want to perform lighting in the original coordinate system. It would likely do this by reconstructing the position of the fragment in the original coordinate system using `gl_FragCoord`, a constant or uniform holding the size of the cube face, and the input `gl_ViewportIndex` (or `gl_Layer`), which identifies the cube face. Since the value of `normal` is in the original coordinate system, it would not need to be modified as part of this coordinate transformation.

Note that while the `rotate`() operation in the regular geometry shader above could include an arbitrary post-rotation projection matrix, the viewport swizzle does not support arbitrary math. To get proper projection, 1/W buffering should be used. To do this:

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Eric Werness ewerness-nv

  - Liam Middlebrook liam-middlebrook

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

- VkCuFunctionNVX

- VkCuModuleNVX

#### New Commands

- vkCmdCuLaunchKernelNVX

- vkCreateCuFunctionNVX

- vkCreateCuModuleNVX

- vkDestroyCuFunctionNVX

- vkDestroyCuModuleNVX

#### New Structures

- VkCuFunctionCreateInfoNVX

- VkCuLaunchInfoNVX

- VkCuModuleCreateInfoNVX

#### New Enum Constants

- `VK_NVX_BINARY_IMPORT_EXTENSION_NAME`

- `VK_NVX_BINARY_IMPORT_SPEC_VERSION`

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_CU_FUNCTION_NVX_EXT`

  - `VK_DEBUG_REPORT_OBJECT_TYPE_CU_MODULE_NVX_EXT`

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

#### 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
--- | --- | --- | ---
Primary Secondary | Both | Outside | Graphics Compute

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Eric Werness ewerness-nv

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

- vkGetImageViewAddressNVX

- vkGetImageViewHandleNVX

#### New Structures

- VkImageViewAddressPropertiesNVX

- VkImageViewHandleInfoNVX

#### New Enum Constants

- `VK_NVX_IMAGE_VIEW_HANDLE_EXTENSION_NAME`

- `VK_NVX_IMAGE_VIEW_HANDLE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_ADDRESS_PROPERTIES_NVX`

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_HANDLE_INFO_NVX`

#### Version History

- Revision 2, 2020-04-03 (Piers Daniell)

  - Add vkGetImageViewAddressNVX

- Revision 1, 2018-12-07 (Eric Werness)

  - Internal revisions

#### VK_NVX_multiview_per_view_attributes

Name String

  `VK_NVX_multiview_per_view_attributes`

Extension Type

  Device extension

Registered Extension Number

  98

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_multiview` to be enabled for any device-level functionality

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-01-13

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_NVX_multiview_per_view_attributes`

  - This extension provides API support for `GL_NVX_multiview_per_view_attributes`

  - This extension interacts with `VK_NV_viewport_array2`.

Contributors

  - Jeff Bolz, NVIDIA

  - Daniel Koch, NVIDIA

#### Description

This extension adds a new way to write shaders to be used with multiview subpasses, where the attributes for all views are written out by a single invocation of the pre-rasterization shader stages. Related SPIR-V and GLSL extensions `SPV_NVX_multiview_per_view_attributes` and `GL_NVX_multiview_per_view_attributes` introduce per-view position and viewport mask attributes arrays, and this extension defines how those per-view attribute arrays are interpreted by Vulkan. Pipelines using per-view attributes may only execute the pre-rasterization shader stages once for all views rather than once per-view, which reduces redundant shading work.

A subpass creation flag controls whether the subpass uses this extension. A subpass must either exclusively use this extension or not use it at all.

Some Vulkan implementations only support the position attribute varying between views in the X component. A subpass can declare via a second creation flag whether all pipelines compiled for this subpass will obey this restriction.

Shaders that use the new per-view outputs (e.g. `gl_PositionPerViewNV`) must also write the non-per-view output (`gl_Position`), and the values written must be such that `gl_Position = gl_PositionPerViewNV[gl_ViewIndex]` for all views in the subpass. Implementations are free to either use the per-view outputs or the non-per-view outputs, whichever would be more efficient.

If `VK_NV_viewport_array2` is not also supported and enabled, the per-view viewport mask must not be used.

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMultiviewPerViewAttributesPropertiesNVX

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

- `PositionPerViewNV`

- `ViewportMaskPerViewNV`

#### New SPIR-V Capabilities

- `PerViewAttributesNV`

#### Examples

    #version 450 core

    #extension GL_KHX_multiview : enable
    #extension GL_NVX_multiview_per_view_attributes : enable

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

    void main()
    {
        // Output both per-view positions and gl_Position as a function
        // of gl_ViewIndex
        gl_PositionPerViewNV[0] = buf.mvpPerView[0] * position;
        gl_PositionPerViewNV[1] = buf.mvpPerView[1] * position;
        gl_Position = buf.mvpPerView[gl_ViewIndex] * position;
    }

#### Version History

- Revision 1, 2017-01-13 (Jeff Bolz)

  - Internal revisions

#### VK_QCOM_fragment_density_map_offset

Name String

  `VK_QCOM_fragment_density_map_offset`

Extension Type

  Device extension

Registered Extension Number

  426

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_EXT_fragment_density_map` to be enabled for any device-level functionality

Contact

  - Matthew Netsch mnetsch

#### 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentDensityMapOffsetFeaturesQCOM

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFragmentDensityMapOffsetPropertiesQCOM

- Extending VkSubpassEndInfo:

  - VkSubpassFragmentDensityMapOffsetEndInfoQCOM

#### New Enum Constants

- `VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_EXTENSION_NAME`

- `VK_QCOM_FRAGMENT_DENSITY_MAP_OFFSET_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_QCOM`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_FEATURES_QCOM`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_DENSITY_MAP_OFFSET_PROPERTIES_QCOM`

  - `VK_STRUCTURE_TYPE_SUBPASS_FRAGMENT_DENSITY_MAP_OFFSET_END_INFO_QCOM`

#### Version History

- Revision 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_format_feature_flags2` to be enabled for any device-level functionality

Contact

  - Jeff Leger jackohound

Extension Proposal

  VK_QCOM_image_processing

#### Other Extension Metadata

Last Modified Date

  2022-07-08

Interactions and External Dependencies

  - This extension requires `SPV_QCOM_image_processing`

  - This extension provides API support for `GL_QCOM_image_processing`

Contributors

  - Jeff Leger, Qualcomm Technologies, Inc.

  - Ruihao Zhang, Qualcomm Technologies, Inc.

#### Description

GPUs are commonly used to process images for various applications from 3D graphics to UI and from composition to compute applications. Simple scaling and filtering can be done with bilinear filtering, which comes for free during texture sampling. However, as screen sizes get larger and more use-cases rely on GPU such as camera and video post-processing needs, there is increasing demand for GPU to support higher order filtering and other advanced image processing.

This extension introduces a new set of SPIR-V built-in functions for image processing. It exposes the following new imaging operations

- The `OpImageSampleWeightedQCOM` instruction takes 3 operands: sampled image, weight image, and texture coordinates. The instruction computes a weighted average of an MxN region of texels in the sampled image, using a set of MxN weights in the weight image.

- The `OpImageBoxFilterQCOM` instruction takes 3 operands: sampled image, box size, and texture coordinates. Note that box size specifies a floating point width and height in texels. The instruction computes a weighted average of all texels in the sampled image that are covered (either partially or fully) by a box with the specified size and centered at the specified texture coordinates.

- The `OpImageBlockMatchSADQCOM` and `OpImageBlockMatchSSDQCOM` instructions each takes 5 operands: target image, target coordinates, reference image, reference coordinates, and block size. Each instruction computes an error metric, that describes whether a block of texels in the target image matches a corresponding block of texels in the reference image. The error metric is computed per-component. `OpImageBlockMatchSADQCOM` computes "Sum Of Absolute Difference" and `OpImageBlockMatchSSDQCOM` computes "Sum of Squared Difference".

Each of the image processing instructions operate only on 2D images. The instructions do not-support sampling of mipmap, multi-plane, multi-layer, multi-sampled, or depth/stencil images. The instructions can be used in any shader stage.

Implementations of this this extension should support these operations natively at the HW instruction level, offering potential performance gains as well as ease of development.

#### New Structures

- Extending VkImageViewCreateInfo:

  - VkImageViewSampleWeightCreateInfoQCOM

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImageProcessingFeaturesQCOM

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceImageProcessingPropertiesQCOM

#### New Enum Constants

- `VK_QCOM_IMAGE_PROCESSING_EXTENSION_NAME`

- `VK_QCOM_IMAGE_PROCESSING_SPEC_VERSION`

- Extending VkDescriptorType:

  - `VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM`

  - `VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM`

  - `VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM`

- Extending VkSamplerCreateFlagBits:

  - `VK_SAMPLER_CREATE_IMAGE_PROCESSING_BIT_QCOM`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_SAMPLE_WEIGHT_CREATE_INFO_QCOM`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_FEATURES_QCOM`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_PROCESSING_PROPERTIES_QCOM`

If VK_KHR_format_feature_flags2 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_render_pass_shader_resolve

Name String

  `VK_QCOM_render_pass_shader_resolve`

Extension Type

  Device extension

Registered Extension Number

  172

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Contact

  - Bill Licea-Kane wwlk

#### Other Extension Metadata

Last Modified Date

  2020-03-25

Contributors

  - Bill Licea-Kane, Qualcomm Technologies, Inc.

#### Description

Renderpass 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_surface` to be enabled for any device-level functionality

Contact

  - Jeff Leger jackohound

#### Other Extension Metadata

Last Modified Date

  2022-07-21

Interactions and External Dependencies

  - This extension requires `VK_KHR_swapchain`

  - This extension interacts with `VK_EXT_fragment_density_map`

  - This extension interacts with `VK_KHR_fragment_shading_rate`

  - This extension interacts with `VK_QCOM_tile_properties`

Contributors

  - Jeff Leger, Qualcomm Technologies, Inc.

  - Brandon Light, Qualcomm Technologies, Inc.

  - Matthew Netsch, Qualcomm Technologies, Inc.

#### Description

This extension provides a mechanism for applications to enable driver support for render pass transform.

Mobile devices can be rotated and mobile applications need to render properly when a device is held in a landscape or portrait orientation. When the current orientation differs from the device’s native orientation, a rotation is required so that the “up” direction of the rendered scene matches the current orientation.

If the Display Processing Unit (DPU) does not natively support rotation, the Vulkan presentation engine can handle this rotation in a separate composition pass. Alternatively, the application can render frames “pre-rotated” to avoid this extra pass. The latter is preferred to reduce power consumption and achieve the best performance because it avoids tasking the GPU with extra work to perform the copy/rotate operation.

Unlike OpenGL ES, the burden of pre-rotation in Vulkan falls on the application. To implement pre-rotation, applications render into swapchain images matching the device native aspect ratio of the display and “pre-rotate” the rendering content to match the device’s current orientation. The burden is more than adjusting the Model View Projection (MVP) matrix in the vertex shader to account for rotation and aspect ratio. The coordinate systems of scissors, viewports, derivatives and several shader built-ins may need to be adapted to produce the correct result.

It is difficult for some game engines to manage this burden; many chose to simply accept the performance/power overhead of performing rotation in the presentation engine.

This extension allows applications to achieve the performance benefits of pre-rotated rendering by moving much of the above-mentioned burden to the graphics driver. The following is unchanged with this extension:

- Applications create a swapchain matching the native orientation of the display. Applications must also set the VkSwapchainCreateInfoKHR::`preTransform` equal to the `currentTransform` as returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR.

The following is changed with this extension:

- At vkCmdBeginRenderPass, the application provides extension struct VkRenderPassTransformBeginInfoQCOM specifying the render pass transform parameters.

- At vkBeginCommandBuffer for secondary command buffers, the application provides extension struct VkCommandBufferInheritanceRenderPassTransformInfoQCOM specifying the render pass transform parameters.

- The `renderArea`, viewports, scissors, and `fragmentSize` are all provided in the current (non-rotated) coordinate system. The implementation will transform those into the native (rotated) coordinate system.

- The implementation is responsible for transforming shader built-ins (`FragCoord`, `PointCoord`, `SamplePosition`, `PrimitiveShadingRateKHR`, interpolateAt(), dFdx, dFdy, fWidth) into the rotated coordinate system.

- The implementation is responsible for transforming `position` to the rotated coordinate system.

- If this extension is used with `VK_QCOM_tile_properties`, then vkGetFramebufferTilePropertiesQCOM and vkGetDynamicRenderingTilePropertiesQCOM return tile properties in the rotated coordinate space.

#### New Structures

- Extending VkCommandBufferInheritanceInfo:

  - VkCommandBufferInheritanceRenderPassTransformInfoQCOM

- Extending VkRenderPassBeginInfo:

  - VkRenderPassTransformBeginInfoQCOM

#### New Enum Constants

- `VK_QCOM_RENDER_PASS_TRANSFORM_EXTENSION_NAME`

- `VK_QCOM_RENDER_PASS_TRANSFORM_SPEC_VERSION`

- Extending VkRenderPassCreateFlagBits:

  - `VK_RENDER_PASS_CREATE_TRANSFORM_BIT_QCOM`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDER_PASS_TRANSFORM_INFO_QCOM`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_TRANSFORM_BEGIN_INFO_QCOM`

#### Issues

1) Some early Adreno drivers (October 2019 through March 2020) advertised support for this extension but expected VK_STRUCTURE_TYPE values different from those in the 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 92. `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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_swapchain` to be enabled for any device-level functionality

  - Requires `VK_KHR_copy_commands2` to be enabled for any device-level functionality

Contact

  - Jeff Leger jackohound

#### 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 Structures

- Extending VkBufferImageCopy2, VkImageBlit2:

  - VkCopyCommandTransformInfoQCOM

#### New Enum Constants

- `VK_QCOM_ROTATED_COPY_COMMANDS_EXTENSION_NAME`

- `VK_QCOM_ROTATED_COPY_COMMANDS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COPY_COMMAND_TRANSFORM_INFO_QCOM`

#### Version History

- Revision 1, 2020-09-19 (Jeff Leger)

#### VK_QCOM_tile_properties

Name String

  `VK_QCOM_tile_properties`

Extension Type

  Device extension

Registered Extension Number

  485

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Contact

  - Jeff Leger jackohound

Extension Proposal

  VK_QCOM_tile_properties

#### Other Extension Metadata

Last Modified Date

  2022-07-11

Interactions and External Dependencies

  - This extension interacts with `VK_EXT_subpass_merge_feedback`

Contributors

  - Jonathan Wicks, Qualcomm Technologies, Inc.

  - Jonathan Tinkham, Qualcomm Technologies, Inc.

  - Arpit Agarwal, Qualcomm Technologies, Inc.

  - Jeff Leger, Qualcomm Technologies, Inc.

#### Description

This extension allows an application to query the tile properties. This extension supports both renderpasses and dynamic rendering.

#### New Commands

- vkGetDynamicRenderingTilePropertiesQCOM

- vkGetFramebufferTilePropertiesQCOM

#### New Structures

- VkRenderingInfoKHR

- VkTilePropertiesQCOM

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTilePropertiesFeaturesQCOM

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Contact

  - Mike Gorchak mgorchak-blackberry

#### Other Extension Metadata

Last Modified Date

  2021-01-11

IP Status

  No known IP claims.

Contributors

  - Mike Gorchak, BlackBerry Limited

#### Description

The `VK_QNX_screen_surface` extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the `VK_KHR_surface` extension) that refers to a QNX Screen `window`, as well as a query to determine support for rendering to a QNX Screen compositor.

#### New Commands

- vkCreateScreenSurfaceQNX

- vkGetPhysicalDeviceScreenPresentationSupportQNX

#### New Structures

- VkScreenSurfaceCreateInfoQNX

#### New Bitmasks

- VkScreenSurfaceCreateFlagsQNX

#### New Enum Constants

- `VK_QNX_SCREEN_SURFACE_EXTENSION_NAME`

- `VK_QNX_SCREEN_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_SCREEN_SURFACE_CREATE_INFO_QNX`

#### Version History

- Revision 1, 2021-01-11 (Mike Gorchak)

  - Initial draft.

#### VK_SEC_amigo_profiling

Name String

  `VK_SEC_amigo_profiling`

Extension Type

  Device extension

Registered Extension Number

  486

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceAmigoProfilingFeaturesSEC

- Extending VkSubmitInfo:

  - VkAmigoProfilingSubmitInfoSEC

#### New Enum Constants

- `VK_SEC_AMIGO_PROFILING_EXTENSION_NAME`

- `VK_SEC_AMIGO_PROFILING_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_AMIGO_PROFILING_SUBMIT_INFO_SEC`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC`

#### Stub API References

There is currently no specification language written for this type. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

    // Provided by VK_SEC_amigo_profiling
    typedef struct VkPhysicalDeviceAmigoProfilingFeaturesSEC {
        VkStructureType    sType;
        void*              pNext;
        VkBool32           amigoProfiling;
    } VkPhysicalDeviceAmigoProfilingFeaturesSEC;

Valid Usage (Implicit)

- VUID-VkPhysicalDeviceAmigoProfilingFeaturesSEC-sType-sType
  `sType` must be `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_AMIGO_PROFILING_FEATURES_SEC`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Special Use

  - D3D support

Contact

  - Hans-Kristian Arntzen HansKristian-Work

#### Other Extension Metadata

Last Modified Date

  2022-02-22

IP Status

  No known IP claims.

Contributors

  - Hans-Kristian Arntzen, Valve

#### Description

This extension allows applications to directly query a host pointer for a VkDescriptorSet which can be used to copy descriptors between descriptor sets without the use of an API command. Memory offsets and sizes for descriptors can be queried from a VkDescriptorSetLayout as well.

| 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 Commands

- vkGetDescriptorSetHostMappingVALVE

- vkGetDescriptorSetLayoutHostMappingInfoVALVE

#### New Structures

- VkDescriptorSetBindingReferenceVALVE

- VkDescriptorSetLayoutHostMappingInfoVALVE

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDescriptorSetHostMappingFeaturesVALVE

#### New Enum Constants

- `VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_EXTENSION_NAME`

- `VK_VALVE_DESCRIPTOR_SET_HOST_MAPPING_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_BINDING_REFERENCE_VALVE`

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_HOST_MAPPING_INFO_VALVE`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_SET_HOST_MAPPING_FEATURES_VALVE`

#### Stub API References

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

    // Provided by VK_VALVE_descriptor_set_host_mapping
    void vkGetDescriptorSetLayoutHostMappingInfoVALVE(
        VkDevice                                    device,
        const VkDescriptorSetBindingReferenceVALVE* pBindingReference,
        VkDescriptorSetLayoutHostMappingInfoVALVE*  pHostMapping);

Valid Usage (Implicit)

- VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pBindingReference-parameter
  `pBindingReference` must be a valid pointer to a valid VkDescriptorSetBindingReferenceVALVE structure

- VUID-vkGetDescriptorSetLayoutHostMappingInfoVALVE-pHostMapping-parameter
  `pHostMapping` must be a valid pointer to a VkDescriptorSetLayoutHostMappingInfoVALVE structure

There is currently no specification language written for this command. This section acts only as placeholder and to avoid dead links in the specification and reference pages.

    // Provided by VK_VALVE_descriptor_set_host_mapping
    void vkGetDescriptorSetHostMappingVALVE(
        VkDevice                                    device,
        VkDescriptorSet                             descriptorSet,
        void**                                      ppData);

Valid Usage (Implicit)

- VUID-vkGetDescriptorSetHostMappingVALVE-device-parameter
  `device` must be a valid VkDevice handle

- VUID-vkGetDescriptorSetHostMappingVALVE-descriptorSet-parameter
  `descriptorSet` must be a valid VkDescriptorSet handle

- VUID-vkGetDescriptorSetHostMappingVALVE-ppData-parameter
  `ppData` must be a valid pointer to a pointer value

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

#### VK_VALVE_mutable_descriptor_type

Name String

  `VK_VALVE_mutable_descriptor_type`

Extension Type

  Device extension

Registered Extension Number

  352

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_maintenance3` to be enabled for any device-level functionality

Special Use

  - D3D support

Contact

  - Joshua Ashton Joshua-Ashton

  - Hans-Kristian Arntzen HansKristian-Work

#### Other Extension Metadata

Last Modified Date

  2020-12-02

IP Status

  No known IP claims.

Contributors

  - Joshua Ashton, Valve

  - Hans-Kristian Arntzen, Valve

#### Description

This extension allows applications to reduce descriptor memory footprint by allowing a descriptor to be able to mutate to a given list of descriptor types depending on which descriptor types are written into, or copied into a descriptor set.

The main use case this extension intends to address is descriptor indexing with `VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT` where the descriptor types are completely generic, as this means applications can allocate one large descriptor set, rather than having one large descriptor set per descriptor type, which significantly bloats descriptor memory usage and causes performance issues.

This extension also adds a mechanism to declare that a descriptor pool, and therefore the descriptor sets that are allocated from it, reside only in host memory; as such these descriptors can only be updated/copied, but not bound.

These features together allow much more efficient emulation of the raw D3D12 binding model. This extension is primarily intended to be useful for API layering efforts.

#### New Structures

- VkMutableDescriptorTypeListVALVE

- Extending VkDescriptorSetLayoutCreateInfo, VkDescriptorPoolCreateInfo:

  - VkMutableDescriptorTypeCreateInfoVALVE

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMutableDescriptorTypeFeaturesVALVE

#### New Enum Constants

- `VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_EXTENSION_NAME`

- `VK_VALVE_MUTABLE_DESCRIPTOR_TYPE_SPEC_VERSION`

- Extending VkDescriptorPoolCreateFlagBits:

  - `VK_DESCRIPTOR_POOL_CREATE_HOST_ONLY_BIT_VALVE`

- Extending VkDescriptorSetLayoutCreateFlagBits:

  - `VK_DESCRIPTOR_SET_LAYOUT_CREATE_HOST_ONLY_POOL_BIT_VALVE`

- Extending VkDescriptorType:

  - `VK_DESCRIPTOR_TYPE_MUTABLE_VALVE`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MUTABLE_DESCRIPTOR_TYPE_CREATE_INFO_VALVE`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MUTABLE_DESCRIPTOR_TYPE_FEATURES_VALVE`

#### Version History

- Revision 1, 2020-12-01 (Joshua Ashton, Hans-Kristian Arntzen)

  - Initial specification, squashed from public draft.

### List of Provisional Extensions

- `VK_KHR_portability_subset`

- `VK_KHR_video_decode_queue`

- `VK_KHR_video_encode_queue`

- `VK_KHR_video_queue`

- `VK_EXT_video_decode_h264`

- `VK_EXT_video_decode_h265`

- `VK_EXT_video_encode_h264`

- `VK_EXT_video_encode_h265`

#### VK_KHR_portability_subset

Name String

  `VK_KHR_portability_subset`

Extension Type

  Device extension

Registered Extension Number

  164

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - Bill Hollings billhollings

#### Other Extension Metadata

Last Modified Date

  2020-07-21

IP Status

  No known IP claims.

Contributors

  - Bill Hollings, The Brenwill Workshop Ltd.

  - Daniel Koch, NVIDIA

  - Dzmitry Malyshau, Mozilla

  - Chip Davis, CodeWeavers

  - Dan Ginsburg, Valve

  - Mike Weiblen, LunarG

  - Neil Trevett, NVIDIA

  - Alexey Knyazev, Independent

#### Description

The `VK_KHR_portability_subset extension allows a non-conformant Vulkan implementation to be built on top of another non-Vulkan graphics API, and identifies differences between that implementation and a fully-conformant native Vulkan implementation.

This extension provides Vulkan implementations with the ability to mark otherwise-required capabilities as unsupported, or to establish additional properties and limits that the application should adhere to in order to guarantee portable 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePortabilitySubsetFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePortabilitySubsetPropertiesKHR

#### New Enum Constants

- `VK_KHR_PORTABILITY_SUBSET_EXTENSION_NAME`

- `VK_KHR_PORTABILITY_SUBSET_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PORTABILITY_SUBSET_PROPERTIES_KHR`

#### Issues

None.

#### Version History

- Revision 1, 2020-07-21 (Bill Hollings)

  - Initial draft.

#### VK_KHR_video_decode_queue

Name String

  `VK_KHR_video_decode_queue`

Extension Type

  Device extension

Registered Extension Number

  25

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_queue` to be enabled for any device-level functionality

  - Requires `VK_KHR_synchronization2` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - jake.beju@amd.com

#### Other Extension Metadata

Last Modified Date

  2022-08-12

IP Status

  No known IP claims.

Contributors

  - Ahmed Abdelkhalek, AMD

  - Jake Beju, AMD

  - Olivier Lapicque, NVIDIA

  - Peter Fang, AMD

  - Piers Daniell, NVIDIA

  - Srinath Kumarapuram, NVIDIA

  - Tony Zlatinski, NVIDIA

  - Daniel Rakos, RasterGrid

#### Description

This extension builds upon the `VK_KHR_video_queue` extension by adding common APIs specific to video decoding and thus enabling implementations to expose queue families supporting video decode operations.

More specifically, it adds video decode specific capabilities and a new command buffer command that allows recording video decode operations against a video session.

This extension is to be used in conjunction with other codec specific video decode extensions that enable decoding video sequences of specific video compression standards.

#### New Commands

- vkCmdDecodeVideoKHR

#### New Structures

- VkVideoDecodeInfoKHR

- Extending VkVideoCapabilitiesKHR:

  - VkVideoDecodeCapabilitiesKHR

- Extending VkVideoProfileInfoKHR:

  - VkVideoDecodeUsageInfoKHR

#### New Enums

- VkVideoDecodeCapabilityFlagBitsKHR

- VkVideoDecodeUsageFlagBitsKHR

#### New Bitmasks

- VkVideoDecodeCapabilityFlagsKHR

- VkVideoDecodeFlagsKHR

- VkVideoDecodeUsageFlagsKHR

#### New Enum Constants

- `VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME`

- `VK_KHR_VIDEO_DECODE_QUEUE_SPEC_VERSION`

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_VIDEO_DECODE_READ_BIT_KHR`

  - `VK_ACCESS_2_VIDEO_DECODE_WRITE_BIT_KHR`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_VIDEO_DECODE_DST_BIT_KHR`

  - `VK_BUFFER_USAGE_VIDEO_DECODE_SRC_BIT_KHR`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_VIDEO_DECODE_DPB_BIT_KHR`

  - `VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR`

  - `VK_IMAGE_LAYOUT_VIDEO_DECODE_DST_KHR`

  - `VK_IMAGE_LAYOUT_VIDEO_DECODE_SRC_KHR`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR`

  - `VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR`

  - `VK_IMAGE_USAGE_VIDEO_DECODE_SRC_BIT_KHR`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_VIDEO_DECODE_BIT_KHR`

- Extending VkQueueFlagBits:

  - `VK_QUEUE_VIDEO_DECODE_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_CAPABILITIES_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_USAGE_INFO_KHR`

If VK_KHR_format_feature_flags2 is supported:

- Extending VkFormatFeatureFlagBits2:

  - `VK_FORMAT_FEATURE_2_VIDEO_DECODE_DPB_BIT_KHR`

  - `VK_FORMAT_FEATURE_2_VIDEO_DECODE_OUTPUT_BIT_KHR`

#### Issues

1) Why is there no `VK_PIPELINE_STAGE_VIDEO_DECODE_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 #26 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-6-11 (Peter Fang)

  - Initial draft

- Revision 1.5, Nov 09 2018 (Tony Zlatinski)

  - API Updates

- Revision 1.6, Jan 08 2020 (Tony Zlatinski)

  - API unify with the video_encode_queue spec

- Revision 1.7, March 29 2021 (Tony Zlatinski)

  - Spec and API updates.

- Revision 2, September 30 2021 (Jon Leech)

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

- Revision 3, 2022-02-25 (Ahmed Abdelkhalek)

  - Add VkVideoDecodeCapabilitiesKHR with new flags to report support for decode DPB and output coinciding in the same image, or in distinct images.

- Revision 4, 2022-03-31 (Ahmed Abdelkhalek)

  - Remove redundant VkVideoDecodeInfoKHR.coded{Offset|Extent}

- Revision 5, 2022-07-18 (Daniel Rakos)

  - Remove `VkVideoDecodeFlagBitsKHR` as it contains no defined flags for now

- Revision 6, 2022-08-12 (Daniel Rakos)

  - Add VkVideoDecodeUsageInfoKHR structure and related flags

#### VK_KHR_video_encode_queue

Name String

  `VK_KHR_video_encode_queue`

Extension Type

  Device extension

Registered Extension Number

  300

Revision

  7

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_queue` to be enabled for any device-level functionality

  - Requires `VK_KHR_synchronization2` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - Ahmed Abdelkhalek aabdelkh

#### Other Extension Metadata

Last Modified Date

  2022-08-12

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

  - Yang Liu, AMD

  - Daniel Rakos, RasterGrid

#### Description

This extension builds upon the `VK_KHR_video_queue` extension by adding common APIs specific to video encoding and thus enabling implementations to expose queue families supporting video encode operations.

More specifically, it adds video encode specific capabilities and a new command buffer command that allows recording video encode operations against a video session.

This extension is to be used in conjunction with other codec specific video encode extensions that enable encoding video sequences of specific video compression standards.

#### New Commands

- vkCmdEncodeVideoKHR

#### New Structures

- VkVideoEncodeInfoKHR

- Extending VkVideoCapabilitiesKHR:

  - VkVideoEncodeCapabilitiesKHR

- Extending VkVideoCodingControlInfoKHR:

  - VkVideoEncodeRateControlInfoKHR

  - VkVideoEncodeRateControlLayerInfoKHR

- Extending VkVideoProfileInfoKHR:

  - VkVideoEncodeUsageInfoKHR

#### New Enums

- VkVideoEncodeCapabilityFlagBitsKHR

- VkVideoEncodeContentFlagBitsKHR

- VkVideoEncodeRateControlModeFlagBitsKHR

- VkVideoEncodeTuningModeKHR

- VkVideoEncodeUsageFlagBitsKHR

#### New Bitmasks

- VkVideoEncodeCapabilityFlagsKHR

- VkVideoEncodeContentFlagsKHR

- VkVideoEncodeFlagsKHR

- VkVideoEncodeRateControlFlagsKHR

- VkVideoEncodeRateControlModeFlagsKHR

- VkVideoEncodeUsageFlagsKHR

#### New Enum Constants

- `VK_KHR_VIDEO_ENCODE_QUEUE_EXTENSION_NAME`

- `VK_KHR_VIDEO_ENCODE_QUEUE_SPEC_VERSION`

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_VIDEO_ENCODE_READ_BIT_KHR`

  - `VK_ACCESS_2_VIDEO_ENCODE_WRITE_BIT_KHR`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_VIDEO_ENCODE_DST_BIT_KHR`

  - `VK_BUFFER_USAGE_VIDEO_ENCODE_SRC_BIT_KHR`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_VIDEO_ENCODE_DPB_BIT_KHR`

  - `VK_FORMAT_FEATURE_VIDEO_ENCODE_INPUT_BIT_KHR`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_VIDEO_ENCODE_DPB_KHR`

  - `VK_IMAGE_LAYOUT_VIDEO_ENCODE_DST_KHR`

  - `VK_IMAGE_LAYOUT_VIDEO_ENCODE_SRC_KHR`

- Extending VkImageUsageFlagBits:

  - `VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR`

  - `VK_IMAGE_USAGE_VIDEO_ENCODE_DST_BIT_KHR`

  - `VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_VIDEO_ENCODE_BIT_KHR`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_VIDEO_ENCODE_BITSTREAM_BUFFER_RANGE_KHR`

- Extending VkQueueFlagBits:

  - `VK_QUEUE_VIDEO_ENCODE_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_CAPABILITIES_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_INFO_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_USAGE_INFO_KHR`

- Extending VkVideoCodingControlFlagBitsKHR:

  - `VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR`

  - `VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_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)

  - Add interaction with `VK_KHR_format_feature_flags2` to `vk.xml`

- Revision 4, 2022-02-10 (Ahmed Abdelkhalek)

  - Updates to encode capability interface

- Revision 5, 2022-03-31 (Ahmed Abdelkhalek)

  - Remove redundant VkVideoEncodeInfoKHR.codedExtent

- Revision 6, 2022-07-18 (Daniel Rakos)

  - Remove `VkVideoEncodeRateControlFlagBitsKHR` and `VkVideoEncodeFlagBitsKHR` as they contain no defined flags for now

  - Add `VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR` and `VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_LAYER_BIT_KHR` to indicate rate control and rate control layer change requests, respectively, in video coding control operations

- Revision 7, 2022-08-12 (Daniel Rakos)

  - Add VkVideoEncodeUsageInfoKHR structure and related flags

#### VK_KHR_video_queue

Name String

  `VK_KHR_video_queue`

Extension Type

  Device extension

Registered Extension Number

  24

Revision

  5

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_synchronization2` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - Tony Zlatinski tzlatinski

#### Other Extension Metadata

Last Modified Date

  2022-08-11

IP Status

  No known IP claims.

Contributors

  - Ahmed Abdelkhalek, AMD

  - George Hao, AMD

  - Jake Beju, AMD

  - Piers Daniell, NVIDIA

  - Srinath Kumarapuram, NVIDIA

  - Tobias Hector, AMD

  - Tony Zlatinski, NVIDIA

  - Daniel Rakos, RasterGrid

#### Description

This extension provides common APIs to enable exposing queue families with support for video codec operations by introducing the following new object types and related functionalities:

- Video session objects that represent and maintain the state needed to perform video codec operations.

- Video session parameters objects that act as a container for codec specific parameters.

In addition, it also introduces query commands that allow applications to determine video coding related capabilities, and command buffer commands that enable recording video coding operations against a video session.

This extension is to be used in conjunction with other extensions that enable specific video coding operations.

#### New Object Types

- VkVideoSessionKHR

- VkVideoSessionParametersKHR

#### New Commands

- vkBindVideoSessionMemoryKHR

- vkCmdBeginVideoCodingKHR

- vkCmdControlVideoCodingKHR

- vkCmdEndVideoCodingKHR

- vkCreateVideoSessionKHR

- vkCreateVideoSessionParametersKHR

- vkDestroyVideoSessionKHR

- vkDestroyVideoSessionParametersKHR

- vkGetPhysicalDeviceVideoCapabilitiesKHR

- vkGetPhysicalDeviceVideoFormatPropertiesKHR

- vkGetVideoSessionMemoryRequirementsKHR

- vkUpdateVideoSessionParametersKHR

#### New Structures

- VkBindVideoSessionMemoryInfoKHR

- VkPhysicalDeviceVideoFormatInfoKHR

- VkVideoBeginCodingInfoKHR

- VkVideoCapabilitiesKHR

- VkVideoCodingControlInfoKHR

- VkVideoEndCodingInfoKHR

- VkVideoFormatPropertiesKHR

- VkVideoPictureResourceInfoKHR

- VkVideoReferenceSlotInfoKHR

- VkVideoSessionCreateInfoKHR

- VkVideoSessionMemoryRequirementsKHR

- VkVideoSessionParametersCreateInfoKHR

- VkVideoSessionParametersUpdateInfoKHR

- Extending VkPhysicalDeviceImageFormatInfo2, VkPhysicalDeviceVideoFormatInfoKHR, VkImageCreateInfo, VkBufferCreateInfo:

  - VkVideoProfileListInfoKHR

- Extending VkQueryPoolCreateInfo:

  - VkVideoProfileInfoKHR

- Extending VkQueueFamilyProperties2:

  - VkQueueFamilyQueryResultStatusPropertiesKHR

  - VkQueueFamilyVideoPropertiesKHR

#### New Enums

- VkQueryResultStatusKHR

- VkVideoCapabilityFlagBitsKHR

- VkVideoChromaSubsamplingFlagBitsKHR

- VkVideoCodecOperationFlagBitsKHR

- VkVideoCodingControlFlagBitsKHR

- VkVideoComponentBitDepthFlagBitsKHR

- VkVideoSessionCreateFlagBitsKHR

#### New Bitmasks

- VkVideoBeginCodingFlagsKHR

- VkVideoCapabilityFlagsKHR

- VkVideoChromaSubsamplingFlagsKHR

- VkVideoCodecOperationFlagsKHR

- VkVideoCodingControlFlagsKHR

- VkVideoComponentBitDepthFlagsKHR

- VkVideoEndCodingFlagsKHR

- VkVideoSessionCreateFlagsKHR

- VkVideoSessionParametersCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_VIDEO_QUEUE_EXTENSION_NAME`

- `VK_KHR_VIDEO_QUEUE_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_VIDEO_SESSION_KHR`

  - `VK_OBJECT_TYPE_VIDEO_SESSION_PARAMETERS_KHR`

- Extending VkQueryResultFlagBits:

  - `VK_QUERY_RESULT_WITH_STATUS_BIT_KHR`

- Extending VkQueryType:

  - `VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR`

- Extending VkResult:

  - `VK_ERROR_IMAGE_USAGE_NOT_SUPPORTED_KHR`

  - `VK_ERROR_VIDEO_PICTURE_LAYOUT_NOT_SUPPORTED_KHR`

  - `VK_ERROR_VIDEO_PROFILE_CODEC_NOT_SUPPORTED_KHR`

  - `VK_ERROR_VIDEO_PROFILE_FORMAT_NOT_SUPPORTED_KHR`

  - `VK_ERROR_VIDEO_PROFILE_OPERATION_NOT_SUPPORTED_KHR`

  - `VK_ERROR_VIDEO_STD_VERSION_NOT_SUPPORTED_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BIND_VIDEO_SESSION_MEMORY_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_FORMAT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_QUEUE_FAMILY_QUERY_RESULT_STATUS_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_QUEUE_FAMILY_VIDEO_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_BEGIN_CODING_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_CAPABILITIES_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_CODING_CONTROL_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_END_CODING_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_FORMAT_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_PICTURE_RESOURCE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_PROFILE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_PROFILE_LIST_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_REFERENCE_SLOT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_SESSION_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_SESSION_MEMORY_REQUIREMENTS_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_VIDEO_SESSION_PARAMETERS_UPDATE_INFO_KHR`

#### Version History

- Revision 0.1, 2019-11-21 (Tony Zlatinski)

  - Initial draft

- Revision 0.2, 2019-11-27 (Tony Zlatinski)

  - Make vulkan video core common between decode and encode

- Revision 1, March 29 2021 (Tony Zlatinski)

  - Spec and API updates.

- Revision 2, August 1 2021 (Srinath Kumarapuram)

  - Rename `VkVideoCapabilitiesFlagBitsKHR` to `VkVideoCapabilityFlagBitsKHR` (along with the names of enumerants it defines) and `VkVideoCapabilitiesFlagsKHR` to `VkVideoCapabilityFlagsKHR`, following Vulkan naming conventions.

- Revision 3, 2022-03-16 (Ahmed Abdelkhalek)

  - Relocate Std header version reporting/requesting from codec-operation specific extensions to this extension.

  - Make Std header versions codec-operation specific instead of only codec-specific.

- Revision 4, 2022-05-30 (Daniel Rakos)

  - Refactor the video format query APIs and related language

  - Extend VkResult with video-specific error codes

- Revision 5, 2022-08-11 (Daniel Rakos)

  - Add `VkVideoSessionParametersCreateFlagsKHR`

  - Remove `VkVideoCodingQualityPresetFlagsKHR`

  - Rename `VkQueueFamilyQueryResultStatusProperties2KHR` to `VkQueueFamilyQueryResultStatusPropertiesKHR`

  - Rename `VkVideoQueueFamilyProperties2KHR` to `VkQueueFamilyVideoPropertiesKHR`

  - Rename `VkVideoProfileKHR` to `VkVideoProfileInfoKHR`

  - Rename `VkVideoProfilesKHR` to `VkVideoProfileListInfoKHR`

  - Rename `VkVideoGetMemoryPropertiesKHR` to `VkVideoSessionMemoryRequirementsKHR`

  - Rename `VkVideoBindMemoryKHR` to `VkBindVideoSessionMemoryInfoKHR`

  - Fix `pNext` constness of `VkPhysicalDeviceVideoFormatInfoKHR` and `VkVideoSessionMemoryRequirementsKHR`

  - Fix incorrectly named value enums in bit enum types `VkVideoCodecOperationFlagBitsKHR` and `VkVideoChromaSubsamplingFlagBitsKHR`

  - Remove unnecessary default values from `VkVideoSessionCreateFlagBitsKHR` and `VkVideoCodingControlFlagBitsKHR`

  - Eliminate nested pointer in `VkVideoSessionMemoryRequirementsKHR`

  - Rename `VkVideoPictureResourceKHR` to `VkVideoPictureResourceInfoKHR`

  - Rename `VkVideoReferenceSlotKHR` to `VkVideoReferenceSlotInfoKHR`

#### VK_EXT_video_decode_h264

Name String

  `VK_EXT_video_decode_h264`

Extension Type

  Device extension

Registered Extension Number

  41

Revision

  6

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_decode_queue` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - peter.fang@amd.com

#### Other Extension Metadata

Last Modified Date

  2022-08-09

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.

#### New Structures

- Extending VkVideoCapabilitiesKHR:

  - VkVideoDecodeH264CapabilitiesEXT

- Extending VkVideoDecodeH264PictureInfoEXT:

  - VkVideoDecodeH264MvcInfoEXT

- Extending VkVideoDecodeInfoKHR:

  - VkVideoDecodeH264PictureInfoEXT

- Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:

  - VkVideoDecodeH264ProfileInfoEXT

- Extending VkVideoReferenceSlotInfoKHR:

  - VkVideoDecodeH264DpbSlotInfoEXT

- Extending VkVideoSessionParametersCreateInfoKHR:

  - VkVideoDecodeH264SessionParametersCreateInfoEXT

- Extending VkVideoSessionParametersUpdateInfoKHR:

  - VkVideoDecodeH264SessionParametersAddInfoEXT

#### New Enums

- VkVideoDecodeH264PictureLayoutFlagBitsEXT

#### New Bitmasks

- VkVideoDecodeH264PictureLayoutFlagsEXT

#### New Enum Constants

- `VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME`

- `VK_EXT_VIDEO_DECODE_H264_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_CAPABILITIES_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_DPB_SLOT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_MVC_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PICTURE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PROFILE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_ADD_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_SESSION_PARAMETERS_CREATE_INFO_EXT`

- Extending VkVideoCodecOperationFlagBitsKHR:

  - `VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_EXT`

#### 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`

#### VK_EXT_video_decode_h265

Name String

  `VK_EXT_video_decode_h265`

Extension Type

  Device extension

Registered Extension Number

  188

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_decode_queue` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - peter.fang@amd.com

#### Other Extension Metadata

Last Modified Date

  2022-08-09

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.

#### New Structures

- Extending VkVideoCapabilitiesKHR:

  - VkVideoDecodeH265CapabilitiesEXT

- Extending VkVideoDecodeInfoKHR:

  - VkVideoDecodeH265PictureInfoEXT

- Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:

  - VkVideoDecodeH265ProfileInfoEXT

- Extending VkVideoReferenceSlotInfoKHR:

  - VkVideoDecodeH265DpbSlotInfoEXT

- Extending VkVideoSessionParametersCreateInfoKHR:

  - VkVideoDecodeH265SessionParametersCreateInfoEXT

- Extending VkVideoSessionParametersUpdateInfoKHR:

  - VkVideoDecodeH265SessionParametersAddInfoEXT

#### New Enum Constants

- `VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME`

- `VK_EXT_VIDEO_DECODE_H265_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_CAPABILITIES_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_DPB_SLOT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PICTURE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PROFILE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_ADD_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_SESSION_PARAMETERS_CREATE_INFO_EXT`

- Extending VkVideoCodecOperationFlagBitsKHR:

  - `VK_VIDEO_CODEC_OPERATION_DECODE_H265_BIT_EXT`

#### 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`

#### VK_EXT_video_encode_h264

Name String

  `VK_EXT_video_encode_h264`

Extension Type

  Device extension

Registered Extension Number

  39

Revision

  8

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_encode_queue` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - Ahmed Abdelkhalek aabdelkh

#### Other Extension Metadata

Last Modified Date

  2022-07-18

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

  - Yang Liu, AMD

  - Daniel Rakos, RasterGrid

#### Description

This extension builds upon the `VK_KHR_video_encode_queue` extension by adding support for encoding elementary video stream sequences compliant with the H.264/AVC video compression standard.

#### New Structures

- VkVideoEncodeH264DpbSlotInfoEXT

- VkVideoEncodeH264FrameSizeEXT

- VkVideoEncodeH264NaluSliceInfoEXT

- VkVideoEncodeH264QpEXT

- VkVideoEncodeH264ReferenceListsInfoEXT

- Extending VkVideoCapabilitiesKHR:

  - VkVideoEncodeH264CapabilitiesEXT

- Extending VkVideoCodingControlInfoKHR:

  - VkVideoEncodeH264RateControlInfoEXT

- Extending VkVideoCodingControlInfoKHR, VkVideoEncodeRateControlLayerInfoKHR:

  - VkVideoEncodeH264RateControlLayerInfoEXT

- Extending VkVideoEncodeInfoKHR:

  - VkVideoEncodeH264EmitPictureParametersInfoEXT

  - VkVideoEncodeH264VclFrameInfoEXT

- Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:

  - VkVideoEncodeH264ProfileInfoEXT

- Extending VkVideoSessionParametersCreateInfoKHR:

  - VkVideoEncodeH264SessionParametersCreateInfoEXT

- Extending VkVideoSessionParametersUpdateInfoKHR:

  - VkVideoEncodeH264SessionParametersAddInfoEXT

#### New Enums

- VkVideoEncodeH264CapabilityFlagBitsEXT

- VkVideoEncodeH264InputModeFlagBitsEXT

- VkVideoEncodeH264OutputModeFlagBitsEXT

- VkVideoEncodeH264RateControlStructureEXT

#### New Bitmasks

- VkVideoEncodeH264CapabilityFlagsEXT

- VkVideoEncodeH264InputModeFlagsEXT

- VkVideoEncodeH264OutputModeFlagsEXT

#### 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_EMIT_PICTURE_PARAMETERS_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_NALU_SLICE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_H264_PROFILE_INFO_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_REFERENCE_LISTS_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_VCL_FRAME_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`

#### VK_EXT_video_encode_h265

Name String

  `VK_EXT_video_encode_h265`

Extension Type

  Device extension

Registered Extension Number

  40

Revision

  8

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_video_encode_queue` to be enabled for any device-level functionality

  - This is a provisional extension and must be used with caution. See the description of provisional header files for enablement and stability details.

Contact

  - Ahmed Abdelkhalek aabdelkh

#### Other Extension Metadata

Last Modified Date

  2022-07-18

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

  - Daniel Rakos, RasterGrid

#### Description

This extension builds upon the `VK_KHR_video_encode_queue` extension by adding support for encoding elementary video stream sequences compliant with the H.265/HEVC video compression standard.

#### New Structures

- VkVideoEncodeH265DpbSlotInfoEXT

- VkVideoEncodeH265FrameSizeEXT

- VkVideoEncodeH265NaluSliceSegmentInfoEXT

- VkVideoEncodeH265QpEXT

- VkVideoEncodeH265ReferenceListsInfoEXT

- Extending VkVideoCapabilitiesKHR:

  - VkVideoEncodeH265CapabilitiesEXT

- Extending VkVideoCodingControlInfoKHR:

  - VkVideoEncodeH265RateControlInfoEXT

- Extending VkVideoCodingControlInfoKHR, VkVideoEncodeRateControlLayerInfoKHR:

  - VkVideoEncodeH265RateControlLayerInfoEXT

- Extending VkVideoEncodeInfoKHR:

  - VkVideoEncodeH265EmitPictureParametersInfoEXT

  - VkVideoEncodeH265VclFrameInfoEXT

- Extending VkVideoProfileInfoKHR, VkQueryPoolCreateInfo:

  - VkVideoEncodeH265ProfileInfoEXT

- Extending VkVideoSessionParametersCreateInfoKHR:

  - VkVideoEncodeH265SessionParametersCreateInfoEXT

- Extending VkVideoSessionParametersUpdateInfoKHR:

  - VkVideoEncodeH265SessionParametersAddInfoEXT

#### New Enums

- VkVideoEncodeH265CapabilityFlagBitsEXT

- VkVideoEncodeH265CtbSizeFlagBitsEXT

- VkVideoEncodeH265InputModeFlagBitsEXT

- VkVideoEncodeH265OutputModeFlagBitsEXT

- VkVideoEncodeH265RateControlStructureEXT

- VkVideoEncodeH265TransformBlockSizeFlagBitsEXT

#### New Bitmasks

- VkVideoEncodeH265CapabilityFlagsEXT

- VkVideoEncodeH265CtbSizeFlagsEXT

- VkVideoEncodeH265InputModeFlagsEXT

- VkVideoEncodeH265OutputModeFlagsEXT

- VkVideoEncodeH265TransformBlockSizeFlagsEXT

#### 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_EMIT_PICTURE_PARAMETERS_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_NALU_SLICE_SEGMENT_INFO_EXT`

  - `VK_STRUCTURE_TYPE_VIDEO_ENCODE_H265_PROFILE_INFO_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_REFERENCE_LISTS_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_VCL_FRAME_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`

### List of Deprecated Extensions

- `VK_KHR_16bit_storage`

- `VK_KHR_8bit_storage`

- `VK_KHR_bind_memory2`

- `VK_KHR_buffer_device_address`

- `VK_KHR_copy_commands2`

- `VK_KHR_create_renderpass2`

- `VK_KHR_dedicated_allocation`

- `VK_KHR_depth_stencil_resolve`

- `VK_KHR_descriptor_update_template`

- `VK_KHR_device_group`

- `VK_KHR_device_group_creation`

- `VK_KHR_draw_indirect_count`

- `VK_KHR_driver_properties`

- `VK_KHR_dynamic_rendering`

- `VK_KHR_external_fence`

- `VK_KHR_external_fence_capabilities`

- `VK_KHR_external_memory`

- `VK_KHR_external_memory_capabilities`

- `VK_KHR_external_semaphore`

- `VK_KHR_external_semaphore_capabilities`

- `VK_KHR_format_feature_flags2`

- `VK_KHR_get_memory_requirements2`

- `VK_KHR_get_physical_device_properties2`

- `VK_KHR_image_format_list`

- `VK_KHR_imageless_framebuffer`

- `VK_KHR_maintenance1`

- `VK_KHR_maintenance2`

- `VK_KHR_maintenance3`

- `VK_KHR_maintenance4`

- `VK_KHR_multiview`

- `VK_KHR_relaxed_block_layout`

- `VK_KHR_sampler_mirror_clamp_to_edge`

- `VK_KHR_sampler_ycbcr_conversion`

- `VK_KHR_separate_depth_stencil_layouts`

- `VK_KHR_shader_atomic_int64`

- `VK_KHR_shader_draw_parameters`

- `VK_KHR_shader_float16_int8`

- `VK_KHR_shader_float_controls`

- `VK_KHR_shader_integer_dot_product`

- `VK_KHR_shader_non_semantic_info`

- `VK_KHR_shader_subgroup_extended_types`

- `VK_KHR_shader_terminate_invocation`

- `VK_KHR_spirv_1_4`

- `VK_KHR_storage_buffer_storage_class`

- `VK_KHR_synchronization2`

- `VK_KHR_timeline_semaphore`

- `VK_KHR_uniform_buffer_standard_layout`

- `VK_KHR_variable_pointers`

- `VK_KHR_vulkan_memory_model`

- `VK_KHR_zero_initialize_workgroup_memory`

- `VK_EXT_4444_formats`

- `VK_EXT_buffer_device_address`

- `VK_EXT_debug_marker`

- `VK_EXT_debug_report`

- `VK_EXT_descriptor_indexing`

- `VK_EXT_extended_dynamic_state`

- `VK_EXT_extended_dynamic_state2`

- `VK_EXT_global_priority`

- `VK_EXT_global_priority_query`

- `VK_EXT_host_query_reset`

- `VK_EXT_image_robustness`

- `VK_EXT_inline_uniform_block`

- `VK_EXT_pipeline_creation_cache_control`

- `VK_EXT_pipeline_creation_feedback`

- `VK_EXT_private_data`

- `VK_EXT_sampler_filter_minmax`

- `VK_EXT_scalar_block_layout`

- `VK_EXT_separate_stencil_usage`

- `VK_EXT_shader_demote_to_helper_invocation`

- `VK_EXT_shader_subgroup_ballot`

- `VK_EXT_shader_subgroup_vote`

- `VK_EXT_shader_viewport_index_layer`

- `VK_EXT_subgroup_size_control`

- `VK_EXT_texel_buffer_alignment`

- `VK_EXT_texture_compression_astc_hdr`

- `VK_EXT_tooling_info`

- `VK_EXT_validation_flags`

- `VK_EXT_ycbcr_2plane_444_formats`

- `VK_AMD_draw_indirect_count`

- `VK_AMD_gpu_shader_half_float`

- `VK_AMD_gpu_shader_int16`

- `VK_AMD_negative_viewport_height`

- `VK_ARM_rasterization_order_attachment_access`

- `VK_MVK_ios_surface`

- `VK_MVK_macos_surface`

- `VK_NV_dedicated_allocation`

- `VK_NV_external_memory`

- `VK_NV_external_memory_capabilities`

- `VK_NV_external_memory_win32`

- `VK_NV_fragment_shader_barycentric`

- `VK_NV_glsl_shader`

- `VK_NV_win32_keyed_mutex`

#### VK_KHR_16bit_storage

Name String

  `VK_KHR_16bit_storage`

Extension Type

  Device extension

Registered Extension Number

  84

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_storage_buffer_storage_class` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

  - This extension requires `SPV_KHR_16bit_storage`

  - This extension provides API support for `GL_EXT_shader_16bit_storage`

Contributors

  - Alexander Galazin, ARM

  - Jan-Harald Fredriksen, ARM

  - Joerg Wagner, ARM

  - Neil Henning, Codeplay

  - Jeff Bolz, Nvidia

  - Daniel Koch, Nvidia

  - David Neto, Google

  - John Kessenich, Google

#### Description

The `VK_KHR_16bit_storage` extension allows use of 16-bit types in shader input and output interfaces, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 16-bit data in `Block`-decorated objects in the `Uniform` and the `StorageBuffer` storage classes, and objects in the `PushConstant` storage class. This extension allows 16-bit variables to be declared and used as user-defined shader inputs and outputs but does not change location assignment and component assignment rules.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. However, if Vulkan 1.1 is supported and this extension is not, the `storageBuffer16BitAccess` capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevice16BitStorageFeaturesKHR

#### New Enum Constants

- `VK_KHR_16BIT_STORAGE_EXTENSION_NAME`

- `VK_KHR_16BIT_STORAGE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR`

#### New SPIR-V Capabilities

- `StorageBuffer16BitAccess`

- `UniformAndStorageBuffer16BitAccess`

- `StoragePushConstant16`

- `StorageInputOutput16`

#### Version History

- Revision 1, 2017-03-23 (Alexander Galazin)

  - Initial draft

#### VK_KHR_8bit_storage

Name String

  `VK_KHR_8bit_storage`

Extension Type

  Device extension

Registered Extension Number

  178

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_storage_buffer_storage_class` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Alexander Galazin alegal-arm

#### Other Extension Metadata

Last Modified Date

  2018-02-05

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_KHR_8bit_storage`

  - This extension provides API support for `GL_EXT_shader_16bit_storage`

IP Status

  No known IP claims.

Contributors

  - Alexander Galazin, Arm

#### Description

The `VK_KHR_8bit_storage` extension allows use of 8-bit types in uniform and storage buffers, and push constant blocks. This extension introduces several new optional features which map to SPIR-V capabilities and allow access to 8-bit data in `Block`-decorated objects in the `Uniform` and the `StorageBuffer` storage classes, and objects in the `PushConstant` storage class.

The `StorageBuffer8BitAccess` capability must be supported by all implementations of this extension. The other capabilities are optional.

#### Promotion to Vulkan 1.2

Functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the `StorageBuffer8BitAccess` capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevice8BitStorageFeaturesKHR

#### New Enum Constants

- `VK_KHR_8BIT_STORAGE_EXTENSION_NAME`

- `VK_KHR_8BIT_STORAGE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR`

#### New SPIR-V Capabilities

- `StorageBuffer8BitAccess`

- `UniformAndStorageBuffer8BitAccess`

- `StoragePushConstant8`

#### Version History

- Revision 1, 2018-02-05 (Alexander Galazin)

  - Initial draft

#### VK_KHR_bind_memory2

Name String

  `VK_KHR_bind_memory2`

Extension Type

  Device extension

Registered Extension Number

  158

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

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 Commands

- vkBindBufferMemory2KHR

- vkBindImageMemory2KHR

#### New Structures

- VkBindBufferMemoryInfoKHR

- VkBindImageMemoryInfoKHR

#### New Enum Constants

- `VK_KHR_BIND_MEMORY_2_EXTENSION_NAME`

- `VK_KHR_BIND_MEMORY_2_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_ALIAS_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_INFO_KHR`

  - `VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_INFO_KHR`

#### Version History

- Revision 1, 2017-05-19 (Tobias Hector)

  - Pulled bind memory functions into their own extension

#### VK_KHR_buffer_device_address

Name String

  `VK_KHR_buffer_device_address`

Extension Type

  Device extension

Registered Extension Number

  258

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2019-06-24

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_KHR_physical_storage_buffer`

  - This extension provides API support for `GL_EXT_buffer_reference` and `GL_EXT_buffer_reference2` and `GL_EXT_buffer_reference_uvec2`

Contributors

  - Jeff Bolz, NVIDIA

  - Neil Henning, AMD

  - Tobias Hector, AMD

  - Jason 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 Commands

- vkGetBufferDeviceAddressKHR

- vkGetBufferOpaqueCaptureAddressKHR

- vkGetDeviceMemoryOpaqueCaptureAddressKHR

#### New Structures

- VkBufferDeviceAddressInfoKHR

- VkDeviceMemoryOpaqueCaptureAddressInfoKHR

- Extending VkBufferCreateInfo:

  - VkBufferOpaqueCaptureAddressCreateInfoKHR

- Extending VkMemoryAllocateInfo:

  - VkMemoryOpaqueCaptureAddressAllocateInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceBufferDeviceAddressFeaturesKHR

#### New Enum Constants

- `VK_KHR_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME`

- `VK_KHR_BUFFER_DEVICE_ADDRESS_SPEC_VERSION`

- Extending VkBufferCreateFlagBits:

  - `VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_KHR`

- Extending VkMemoryAllocateFlagBits:

  - `VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_BIT_KHR`

  - `VK_MEMORY_ALLOCATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_KHR`

- Extending VkResult:

  - `VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_KHR`

  - `VK_STRUCTURE_TYPE_BUFFER_OPAQUE_CAPTURE_ADDRESS_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_MEMORY_OPAQUE_CAPTURE_ADDRESS_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_OPAQUE_CAPTURE_ADDRESS_ALLOCATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_KHR`

#### New SPIR-V Capabilities

- `PhysicalStorageBufferAddresses`

#### Version History

- Revision 1, 2019-06-24 (Jan-Harald Fredriksen)

  - Internal revisions based on VK_EXT_buffer_device_address

#### VK_KHR_copy_commands2

Name String

  `VK_KHR_copy_commands2`

Extension Type

  Device extension

Registered Extension Number

  338

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Jeff Leger jackohound

#### 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 Commands

- vkCmdBlitImage2KHR

- vkCmdCopyBuffer2KHR

- vkCmdCopyBufferToImage2KHR

- vkCmdCopyImage2KHR

- vkCmdCopyImageToBuffer2KHR

- vkCmdResolveImage2KHR

#### New Structures

- VkBlitImageInfo2KHR

- VkBufferCopy2KHR

- VkBufferImageCopy2KHR

- VkCopyBufferInfo2KHR

- VkCopyBufferToImageInfo2KHR

- VkCopyImageInfo2KHR

- VkCopyImageToBufferInfo2KHR

- VkImageBlit2KHR

- VkImageCopy2KHR

- VkImageResolve2KHR

- VkResolveImageInfo2KHR

#### New Enum Constants

- `VK_KHR_COPY_COMMANDS_2_EXTENSION_NAME`

- `VK_KHR_COPY_COMMANDS_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BLIT_IMAGE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_BUFFER_COPY_2_KHR`

  - `VK_STRUCTURE_TYPE_BUFFER_IMAGE_COPY_2_KHR`

  - `VK_STRUCTURE_TYPE_COPY_BUFFER_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_COPY_BUFFER_TO_IMAGE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_COPY_IMAGE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_COPY_IMAGE_TO_BUFFER_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_BLIT_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_COPY_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_RESOLVE_2_KHR`

  - `VK_STRUCTURE_TYPE_RESOLVE_IMAGE_INFO_2_KHR`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_multiview` to be enabled for any device-level functionality

  - Requires `VK_KHR_maintenance2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Tobias Hector tobias

#### 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:

- Elements of VkRenderPassMultiviewCreateInfo::`pViewMasks` are now specified in VkSubpassDescription2KHR::`viewMask`.

- Elements of VkRenderPassMultiviewCreateInfo::`pViewOffsets` are now specified in VkSubpassDependency2KHR::`viewOffset`.

- VkRenderPassMultiviewCreateInfo::`correlationMaskCount` and VkRenderPassMultiviewCreateInfo::`pCorrelationMasks` are directly specified in VkRenderPassCreateInfo2KHR.

- VkInputAttachmentAspectReference::`aspectMask` is now specified in the relevant input attachment description in VkAttachmentDescription2KHR::`aspectMask`

The details of these mappings are explained fully in the new structures.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkCmdBeginRenderPass2KHR

- vkCmdEndRenderPass2KHR

- vkCmdNextSubpass2KHR

- vkCreateRenderPass2KHR

#### New Structures

- VkAttachmentDescription2KHR

- VkAttachmentReference2KHR

- VkRenderPassCreateInfo2KHR

- VkSubpassBeginInfoKHR

- VkSubpassDependency2KHR

- VkSubpassDescription2KHR

- VkSubpassEndInfoKHR

#### New Enum Constants

- `VK_KHR_CREATE_RENDERPASS_2_EXTENSION_NAME`

- `VK_KHR_CREATE_RENDERPASS_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_2_KHR`

  - `VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_2_KHR`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_SUBPASS_BEGIN_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SUBPASS_DEPENDENCY_2_KHR`

  - `VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_2_KHR`

  - `VK_STRUCTURE_TYPE_SUBPASS_END_INFO_KHR`

#### Version History

- Revision 1, 2018-02-07 (Tobias Hector)

  - Internal revisions

#### VK_KHR_dedicated_allocation

Name String

  `VK_KHR_dedicated_allocation`

Extension Type

  Device extension

Registered Extension Number

  128

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_memory_requirements2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jeff Bolz, NVIDIA

  - Jason Ekstrand, Intel

#### Description

This extension enables resources to be bound to a dedicated allocation, rather than suballocated. For any particular resource, applications can query whether a dedicated allocation is recommended, in which case using a dedicated allocation may improve the performance of access to that resource. Normal device memory allocations must support multiple resources per allocation, memory aliasing and sparse binding, which could interfere with some optimizations. Applications should query the implementation for when a dedicated allocation may be beneficial by adding a `VkMemoryDedicatedRequirementsKHR` structure to the `pNext` chain of the `VkMemoryRequirements2` structure passed as the `pMemoryRequirements` parameter of a call to `vkGetBufferMemoryRequirements2` or `vkGetImageMemoryRequirements2`. Certain external handle types and external images or buffers may also depend on dedicated allocations on implementations that associate image or buffer metadata with OS-level memory objects.

This extension adds a two small structures to memory requirements querying and memory allocation: a new structure that flags whether an image/buffer should have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkMemoryAllocateInfo:

  - VkMemoryDedicatedAllocateInfoKHR

- Extending VkMemoryRequirements2:

  - VkMemoryDedicatedRequirementsKHR

#### New Enum Constants

- `VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME`

- `VK_KHR_DEDICATED_ALLOCATION_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR`

#### Examples

        // Create an image with a dedicated allocation based on the
        // implementation's preference

        VkImageCreateInfo imageCreateInfo =
        {
            // Image creation parameters
        };

        VkImage image;
        VkResult result = vkCreateImage(
            device,
            &imageCreateInfo,
            NULL,                               // pAllocator
            &image);

        VkMemoryDedicatedRequirementsKHR dedicatedRequirements =
        {
            VK_STRUCTURE_TYPE_MEMORY_DEDICATED_REQUIREMENTS_KHR,
            NULL,                               // pNext
        };

        VkMemoryRequirements2 memoryRequirements =
        {
            VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2,
            &dedicatedRequirements,             // pNext
        };

        const VkImageMemoryRequirementsInfo2 imageRequirementsInfo =
        {
            VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2,
            NULL,                               // pNext
            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 =
            {
                VK_STRUCTURE_TYPE_MEMORY_DEDICATED_ALLOCATE_INFO_KHR,   // sType
                NULL,                                                   // pNext
                image,                                                  // image
                VK_NULL_HANDLE,                                         // buffer
            };

            VkMemoryAllocateInfo memoryAllocateInfo =
            {
                VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,                 // sType
                &dedicatedInfo,                                         // pNext
                memoryRequirements.size,                                // allocationSize
                FindMemoryTypeIndex(memoryRequirements.memoryTypeBits), // memoryTypeIndex
            };

            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 (Jason Ekstrand)

  - Rework the extension to be query-based

- Revision 3, 2017-07-31 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_create_renderpass2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jan-Harald Fredriksen janharald

#### 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 Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDepthStencilResolvePropertiesKHR

- Extending VkSubpassDescription2:

  - VkSubpassDescriptionDepthStencilResolveKHR

#### New Enums

- VkResolveModeFlagBitsKHR

#### New Bitmasks

- VkResolveModeFlagsKHR

#### New Enum Constants

- `VK_KHR_DEPTH_STENCIL_RESOLVE_EXTENSION_NAME`

- `VK_KHR_DEPTH_STENCIL_RESOLVE_SPEC_VERSION`

- Extending VkResolveModeFlagBits:

  - `VK_RESOLVE_MODE_AVERAGE_BIT_KHR`

  - `VK_RESOLVE_MODE_MAX_BIT_KHR`

  - `VK_RESOLVE_MODE_MIN_BIT_KHR`

  - `VK_RESOLVE_MODE_NONE_KHR`

  - `VK_RESOLVE_MODE_SAMPLE_ZERO_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_STENCIL_RESOLVE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR`

#### Version History

- Revision 1, 2018-04-09 (Jan-Harald Fredriksen)

  - Initial revision

#### VK_KHR_descriptor_update_template

Name String

  `VK_KHR_descriptor_update_template`

Extension Type

  Device extension

Registered Extension Number

  86

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Markus Tavenrath mtavenrath

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with `VK_KHR_push_descriptor`

  - Promoted to Vulkan 1.1 Core

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 Object Types

- VkDescriptorUpdateTemplateKHR

#### New Commands

- vkCreateDescriptorUpdateTemplateKHR

- vkDestroyDescriptorUpdateTemplateKHR

- vkUpdateDescriptorSetWithTemplateKHR

If VK_KHR_push_descriptor is supported:

- vkCmdPushDescriptorSetWithTemplateKHR

#### New Structures

- VkDescriptorUpdateTemplateCreateInfoKHR

- VkDescriptorUpdateTemplateEntryKHR

#### New Enums

- VkDescriptorUpdateTemplateTypeKHR

#### New Bitmasks

- VkDescriptorUpdateTemplateCreateFlagsKHR

#### New Enum Constants

- `VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME`

- `VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_SPEC_VERSION`

- Extending VkDescriptorUpdateTemplateType:

  - `VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_DESCRIPTOR_SET_KHR`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR`

If VK_EXT_debug_report is supported:

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT`

If VK_KHR_push_descriptor is supported:

- Extending VkDescriptorUpdateTemplateType:

  - `VK_DESCRIPTOR_UPDATE_TEMPLATE_TYPE_PUSH_DESCRIPTORS_KHR`

#### Version History

- Revision 1, 2016-01-11 (Markus Tavenrath)

  - Initial draft

#### VK_KHR_device_group

Name String

  `VK_KHR_device_group`

Extension Type

  Device extension

Registered Extension Number

  61

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_device_group_creation` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-10-10

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_device_group`

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jeff Bolz, NVIDIA

  - Tobias Hector, Imagination Technologies

#### Description

This extension provides functionality to use a logical device that consists of multiple physical devices, as created with the `VK_KHR_device_group_creation` extension. A device group can allocate memory across the subdevices, bind memory from one subdevice to a resource on another subdevice, record command buffers where some work executes on an arbitrary subset of the subdevices, and potentially present a swapchain image from one or more subdevices.

#### Promotion to Vulkan 1.1

The following enums, types and commands are included as interactions with `VK_KHR_swapchain`:

- `VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR`

- `VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR`

- `VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR`

- `VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR`

- `VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR`

- `VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR`

- `VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR`

- VkDeviceGroupPresentModeFlagBitsKHR

- VkDeviceGroupPresentCapabilitiesKHR

- VkImageSwapchainCreateInfoKHR

- VkBindImageMemorySwapchainInfoKHR

- VkAcquireNextImageInfoKHR

- VkDeviceGroupPresentInfoKHR

- VkDeviceGroupSwapchainCreateInfoKHR

- vkGetDeviceGroupPresentCapabilitiesKHR

- vkGetDeviceGroupSurfacePresentModesKHR

- vkGetPhysicalDevicePresentRectanglesKHR

- vkAcquireNextImage2KHR

If Vulkan 1.1 and `VK_KHR_swapchain` are supported, these are included by `VK_KHR_swapchain`.

The base functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkCmdDispatchBaseKHR

- vkCmdSetDeviceMaskKHR

- vkGetDeviceGroupPeerMemoryFeaturesKHR

If VK_KHR_surface is supported:

- vkGetDeviceGroupPresentCapabilitiesKHR

- vkGetDeviceGroupSurfacePresentModesKHR

- vkGetPhysicalDevicePresentRectanglesKHR

If VK_KHR_swapchain is supported:

- vkAcquireNextImage2KHR

#### New Structures

- Extending VkBindSparseInfo:

  - VkDeviceGroupBindSparseInfoKHR

- Extending VkCommandBufferBeginInfo:

  - VkDeviceGroupCommandBufferBeginInfoKHR

- Extending VkMemoryAllocateInfo:

  - VkMemoryAllocateFlagsInfoKHR

- Extending VkRenderPassBeginInfo, VkRenderingInfo:

  - VkDeviceGroupRenderPassBeginInfoKHR

- Extending VkSubmitInfo:

  - VkDeviceGroupSubmitInfoKHR

If VK_KHR_bind_memory2 is supported:

- Extending VkBindBufferMemoryInfo:

  - VkBindBufferMemoryDeviceGroupInfoKHR

- Extending VkBindImageMemoryInfo:

  - VkBindImageMemoryDeviceGroupInfoKHR

If VK_KHR_surface is supported:

- VkDeviceGroupPresentCapabilitiesKHR

If VK_KHR_swapchain is supported:

- VkAcquireNextImageInfoKHR

- Extending VkBindImageMemoryInfo:

  - VkBindImageMemorySwapchainInfoKHR

- Extending VkImageCreateInfo:

  - VkImageSwapchainCreateInfoKHR

- Extending VkPresentInfoKHR:

  - VkDeviceGroupPresentInfoKHR

- Extending VkSwapchainCreateInfoKHR:

  - VkDeviceGroupSwapchainCreateInfoKHR

#### New Enums

- VkMemoryAllocateFlagBitsKHR

- VkPeerMemoryFeatureFlagBitsKHR

If VK_KHR_surface is supported:

- VkDeviceGroupPresentModeFlagBitsKHR

#### New Bitmasks

- VkMemoryAllocateFlagsKHR

- VkPeerMemoryFeatureFlagsKHR

If VK_KHR_surface is supported:

- VkDeviceGroupPresentModeFlagsKHR

#### New Enum Constants

- `VK_KHR_DEVICE_GROUP_EXTENSION_NAME`

- `VK_KHR_DEVICE_GROUP_SPEC_VERSION`

- Extending VkDependencyFlagBits:

  - `VK_DEPENDENCY_DEVICE_GROUP_BIT_KHR`

- Extending VkMemoryAllocateFlagBits:

  - `VK_MEMORY_ALLOCATE_DEVICE_MASK_BIT_KHR`

- Extending VkPeerMemoryFeatureFlagBits:

  - `VK_PEER_MEMORY_FEATURE_COPY_DST_BIT_KHR`

  - `VK_PEER_MEMORY_FEATURE_COPY_SRC_BIT_KHR`

  - `VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT_KHR`

  - `VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT_KHR`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_DISPATCH_BASE_KHR`

  - `VK_PIPELINE_CREATE_VIEW_INDEX_FROM_DEVICE_INDEX_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_BIND_SPARSE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_COMMAND_BUFFER_BEGIN_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_RENDER_PASS_BEGIN_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_SUBMIT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_FLAGS_INFO_KHR`

If VK_KHR_bind_memory2 is supported:

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BIND_BUFFER_MEMORY_DEVICE_GROUP_INFO_KHR`

  - `VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_DEVICE_GROUP_INFO_KHR`

If VK_KHR_surface is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_CAPABILITIES_KHR`

If VK_KHR_swapchain is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ACQUIRE_NEXT_IMAGE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_BIND_IMAGE_MEMORY_SWAPCHAIN_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_PRESENT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_SWAPCHAIN_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_SWAPCHAIN_CREATE_INFO_KHR`

- Extending VkSwapchainCreateFlagBitsKHR:

  - `VK_SWAPCHAIN_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT_KHR`

#### New Built-in Variables

- `DeviceIndex`

#### New SPIR-V Capabilities

- `DeviceGroup`

#### Version History

- Revision 1, 2016-10-19 (Jeff Bolz)

  - Internal revisions

- Revision 2, 2017-05-19 (Tobias Hector)

  - Removed extended memory bind functions to VK_KHR_bind_memory2, added dependency on that extension, and device-group-specific structs for those functions.

- Revision 3, 2017-10-06 (Ian Elliott)

  - Corrected Vulkan 1.1 interactions with the WSI extensions. All Vulkan 1.1 WSI interactions are with the VK_KHR_swapchain extension.

- Revision 4, 2017-10-10 (Jeff Bolz)

  - Rename “SFR” bits and structure members to use the phrase “split instance bind regions”.

#### VK_KHR_device_group_creation

Name String

  `VK_KHR_device_group_creation`

Extension Type

  Instance extension

Registered Extension Number

  71

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2016-10-19

IP Status

  No known IP claims.

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 Commands

- vkEnumeratePhysicalDeviceGroupsKHR

#### New Structures

- VkPhysicalDeviceGroupPropertiesKHR

- Extending VkDeviceCreateInfo:

  - VkDeviceGroupDeviceCreateInfoKHR

#### New Enum Constants

- `VK_KHR_DEVICE_GROUP_CREATION_EXTENSION_NAME`

- `VK_KHR_DEVICE_GROUP_CREATION_SPEC_VERSION`

- `VK_MAX_DEVICE_GROUP_SIZE_KHR`

- Extending VkMemoryHeapFlagBits:

  - `VK_MEMORY_HEAP_MULTI_INSTANCE_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR`

#### Examples

        VkDeviceCreateInfo devCreateInfo = { VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO };
        // (not shown) fill out devCreateInfo as usual.
        uint32_t deviceGroupCount = 0;
        VkPhysicalDeviceGroupPropertiesKHR *props = NULL;

        // Query the number of device groups
        vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, NULL);

        // Allocate and initialize structures to query the device groups
        props = (VkPhysicalDeviceGroupPropertiesKHR *)malloc(deviceGroupCount*sizeof(VkPhysicalDeviceGroupPropertiesKHR));
        for (i = 0; i < deviceGroupCount; ++i) {
            props[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES_KHR;
            props[i].pNext = NULL;
        }
        vkEnumeratePhysicalDeviceGroupsKHR(g_vkInstance, &deviceGroupCount, props);

        // If the first device group has more than one physical device. create
        // a logical device using all of the physical devices.
        VkDeviceGroupDeviceCreateInfoKHR deviceGroupInfo = { VK_STRUCTURE_TYPE_DEVICE_GROUP_DEVICE_CREATE_INFO_KHR };
        if (props[0].physicalDeviceCount > 1) {
            deviceGroupInfo.physicalDeviceCount = props[0].physicalDeviceCount;
            deviceGroupInfo.pPhysicalDevices = props[0].physicalDevices;
            devCreateInfo.pNext = &deviceGroupInfo;
        }

        vkCreateDevice(props[0].physicalDevices[0], &devCreateInfo, NULL, &g_vkDevice);
        free(props);

#### Version History

- Revision 1, 2016-10-19 (Jeff Bolz)

  - Internal revisions

#### VK_KHR_draw_indirect_count

Name String

  `VK_KHR_draw_indirect_count`

Extension Type

  Device extension

Registered Extension Number

  170

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Piers Daniell pdaniell-nv

#### 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 Commands

- vkCmdDrawIndexedIndirectCountKHR

- vkCmdDrawIndirectCountKHR

#### New Enum Constants

- `VK_KHR_DRAW_INDIRECT_COUNT_EXTENSION_NAME`

- `VK_KHR_DRAW_INDIRECT_COUNT_SPEC_VERSION`

#### Version History

- Revision 1, 2017-08-25 (Piers Daniell)

  - Initial draft based 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Daniel Rakos drakos-amd

#### 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 Structures

- VkConformanceVersionKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDriverPropertiesKHR

#### New Enums

- VkDriverIdKHR

#### New Enum Constants

- `VK_KHR_DRIVER_PROPERTIES_EXTENSION_NAME`

- `VK_KHR_DRIVER_PROPERTIES_SPEC_VERSION`

- `VK_MAX_DRIVER_INFO_SIZE_KHR`

- `VK_MAX_DRIVER_NAME_SIZE_KHR`

- Extending VkDriverId:

  - `VK_DRIVER_ID_AMD_OPEN_SOURCE_KHR`

  - `VK_DRIVER_ID_AMD_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_ARM_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_BROADCOM_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_GGP_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_GOOGLE_SWIFTSHADER_KHR`

  - `VK_DRIVER_ID_IMAGINATION_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR`

  - `VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS_KHR`

  - `VK_DRIVER_ID_MESA_RADV_KHR`

  - `VK_DRIVER_ID_NVIDIA_PROPRIETARY_KHR`

  - `VK_DRIVER_ID_QUALCOMM_PROPRIETARY_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR`

#### Version History

- Revision 1, 2018-04-11 (Daniel Rakos)

  - Internal revisions

#### VK_KHR_dynamic_rendering

Name String

  `VK_KHR_dynamic_rendering`

Extension Type

  Device extension

Registered Extension Number

  45

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_depth_stencil_resolve` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Tobias Hector tobski

Extension Proposal

  VK_KHR_dynamic_rendering

#### Other Extension Metadata

Last Modified Date

  2021-10-06

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 Commands

- vkCmdBeginRenderingKHR

- vkCmdEndRenderingKHR

#### New Structures

- VkRenderingAttachmentInfoKHR

- VkRenderingInfoKHR

- Extending VkCommandBufferInheritanceInfo:

  - VkCommandBufferInheritanceRenderingInfoKHR

- Extending VkGraphicsPipelineCreateInfo:

  - VkPipelineRenderingCreateInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDynamicRenderingFeaturesKHR

If VK_AMD_mixed_attachment_samples is supported:

- Extending VkCommandBufferInheritanceInfo, VkGraphicsPipelineCreateInfo:

  - VkAttachmentSampleCountInfoAMD

If VK_EXT_fragment_density_map is supported:

- Extending VkRenderingInfo:

  - VkRenderingFragmentDensityMapAttachmentInfoEXT

If VK_KHR_fragment_shading_rate is supported:

- Extending VkRenderingInfo:

  - VkRenderingFragmentShadingRateAttachmentInfoKHR

If VK_NV_framebuffer_mixed_samples is supported:

- Extending VkCommandBufferInheritanceInfo, VkGraphicsPipelineCreateInfo:

  - VkAttachmentSampleCountInfoNV

If VK_NVX_multiview_per_view_attributes is supported:

- Extending VkCommandBufferInheritanceInfo, VkGraphicsPipelineCreateInfo, VkRenderingInfo:

  - VkMultiviewPerViewAttributesInfoNVX

#### New Enums

- VkRenderingFlagBitsKHR

#### New Bitmasks

- VkRenderingFlagsKHR

#### New Enum Constants

- `VK_KHR_DYNAMIC_RENDERING_EXTENSION_NAME`

- `VK_KHR_DYNAMIC_RENDERING_SPEC_VERSION`

- Extending VkAttachmentStoreOp:

  - `VK_ATTACHMENT_STORE_OP_NONE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_RENDERING_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DYNAMIC_RENDERING_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_RENDERING_ATTACHMENT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_RENDERING_INFO_KHR`

If VK_AMD_mixed_attachment_samples is supported:

- 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`

If VK_NV_framebuffer_mixed_samples is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ATTACHMENT_SAMPLE_COUNT_INFO_NV`

If VK_NVX_multiview_per_view_attributes is supported:

- 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_fence_capabilities` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2017-05-08

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Cass Everitt, Oculus

  - Contributors to `VK_KHR_external_semaphore`

#### Description

An application using external memory may wish to synchronize access to that memory using fences. This extension enables an application to create fences from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkFenceCreateInfo:

  - VkExportFenceCreateInfoKHR

#### New Enums

- VkFenceImportFlagBitsKHR

#### New Bitmasks

- VkFenceImportFlagsKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_FENCE_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_FENCE_SPEC_VERSION`

- Extending VkFenceImportFlagBits:

  - `VK_FENCE_IMPORT_TEMPORARY_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR`

#### Issues

This extension borrows concepts, semantics, and language from `VK_KHR_external_semaphore`. That extension’s issues apply equally to this extension.

#### Version History

- Revision 1, 2017-05-08 (Jesse Hall)

  - Initial revision

#### VK_KHR_external_fence_capabilities

Name String

  `VK_KHR_external_fence_capabilities`

Extension Type

  Instance extension

Registered Extension Number

  113

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2017-05-08

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Cass Everitt, Oculus

  - Contributors to `VK_KHR_external_semaphore_capabilities`

#### Description

An application may wish to reference device fences in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” fence handles an implementation supports for a given set of use cases.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkGetPhysicalDeviceExternalFencePropertiesKHR

#### New Structures

- VkExternalFencePropertiesKHR

- VkPhysicalDeviceExternalFenceInfoKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceIDPropertiesKHR

#### New Enums

- VkExternalFenceFeatureFlagBitsKHR

- VkExternalFenceHandleTypeFlagBitsKHR

#### New Bitmasks

- VkExternalFenceFeatureFlagsKHR

- VkExternalFenceHandleTypeFlagsKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_FENCE_CAPABILITIES_SPEC_VERSION`

- `VK_LUID_SIZE_KHR`

- Extending VkExternalFenceFeatureFlagBits:

  - `VK_EXTERNAL_FENCE_FEATURE_EXPORTABLE_BIT_KHR`

  - `VK_EXTERNAL_FENCE_FEATURE_IMPORTABLE_BIT_KHR`

- Extending VkExternalFenceHandleTypeFlagBits:

  - `VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR`

  - `VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR`

  - `VK_EXTERNAL_FENCE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR`

  - `VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR`

#### Version History

- Revision 1, 2017-05-08 (Jesse Hall)

  - Initial version

#### VK_KHR_external_memory

Name String

  `VK_KHR_external_memory`

Extension Type

  Device extension

Registered Extension Number

  73

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_memory_capabilities` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-20

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with `VK_KHR_dedicated_allocation`.

  - Interacts with `VK_NV_dedicated_allocation`.

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jason Ekstrand, Intel

  - Ian Elliot, 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

  - Chad Versace, Google

#### Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension enables an application to export non-Vulkan handles from Vulkan memory objects such that the underlying resources can be referenced outside the scope of the Vulkan logical device that created them.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkBufferCreateInfo:

  - VkExternalMemoryBufferCreateInfoKHR

- Extending VkImageCreateInfo:

  - VkExternalMemoryImageCreateInfoKHR

- Extending VkMemoryAllocateInfo:

  - VkExportMemoryAllocateInfoKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_MEMORY_SPEC_VERSION`

- `VK_QUEUE_FAMILY_EXTERNAL_KHR`

- Extending VkResult:

  - `VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_BUFFER_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_KHR`

#### Issues

1) How do applications correlate two physical devices across process or Vulkan instance boundaries?

RESOLVED: New device ID fields have been introduced by `VK_KHR_external_memory_capabilities`. These fields, combined with the existing VkPhysicalDeviceProperties::`driverVersion` field can be used to identify compatible devices across processes, drivers, and APIs. VkPhysicalDeviceProperties::`pipelineCacheUUID` is not sufficient for this purpose because despite its description in the specification, it need only identify a unique pipeline cache format in practice. Multiple devices may be able to use the same pipeline cache data, and hence it would be desirable for all of them to have the same pipeline cache UUID. However, only the same concrete physical device can be used when sharing memory, so an actual unique device ID was introduced. Further, the pipeline cache UUID was specific to Vulkan, but correlation with other, non-extensible APIs is required to enable interoperation with those APIs.

2) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes. Applications must take care to obey all restrictions imposed on aliased resources when using memory across multiple Vulkan instances or other APIs.

3) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan- compatible, and those that are Vulkan-incompatible. Vulkan-incompatible APIs will require the image to be in the GENERAL layout whenever they are accessing them.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

4) Is a new barrier flag or operation of some type needed to prepare external memory for handoff to another Vulkan instance or API and/or receive it from another instance or API?

RESOLVED: Yes. Some implementations need to perform additional cache management when transitioning memory between address spaces and other APIs, instances, or processes which may operate in a separate address space. Options for defining this transition include:

- A new structure that can be added to the `pNext` list in VkMemoryBarrier, VkBufferMemoryBarrier, and VkImageMemoryBarrier.

- A new bit in VkAccessFlags that can be set to indicate an “external” access.

- A new bit in VkDependencyFlags

- A new special queue family that represents an “external” queue.

A new structure has the advantage that the type of external transition can be described in as much detail as necessary. However, there is not currently a known need for anything beyond differentiating between external and internal accesses, so this is likely an over-engineered solution. The access flag bit has the advantage that it can be applied at buffer, image, or global granularity, and semantically it maps pretty well to the operation being described. Additionally, the API already includes `VK_ACCESS_MEMORY_READ_BIT` and `VK_ACCESS_MEMORY_WRITE_BIT` which appear to be intended for this purpose. However, there is no obvious pipeline stage that would correspond to an external access, and therefore no clear way to use `VK_ACCESS_MEMORY_READ_BIT` or `VK_ACCESS_MEMORY_WRITE_BIT`. VkDependencyFlags and VkPipelineStageFlags operate at command granularity rather than image or buffer granularity, which would make an entire pipeline barrier an internal→external or external→internal barrier. This may not be a problem in practice, but seems like the wrong scope. Another downside of VkDependencyFlags is that it lacks inherent directionality: there are no `src` and `dst` variants of it in the barrier or dependency description semantics, so two bits might need to be added to describe both internal→external and external→internal transitions. Transitioning a resource to a special queue family corresponds well with the operation of transitioning to a separate Vulkan instance, in that both operations ideally include scheduling a barrier on both sides of the transition: Both the releasing and the acquiring queue or process. Using a special queue family requires adding an additional reserved queue family index. 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-17

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with `VK_KHR_dedicated_allocation`.

  - Interacts with `VK_NV_dedicated_allocation`.

  - Promoted to Vulkan 1.1 Core

Contributors

  - Ian Elliot, Google

  - Jesse Hall, Google

  - James Jones, NVIDIA

#### Description

An application may wish to reference device memory in multiple Vulkan logical devices or instances, in multiple processes, and/or in multiple APIs. This extension provides a set of capability queries and handle definitions that allow an application to determine what types of “external” memory handles an implementation supports for a given set of use cases.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkGetPhysicalDeviceExternalBufferPropertiesKHR

#### New Structures

- VkExternalBufferPropertiesKHR

- VkExternalMemoryPropertiesKHR

- VkPhysicalDeviceExternalBufferInfoKHR

- Extending VkImageFormatProperties2:

  - VkExternalImageFormatPropertiesKHR

- Extending VkPhysicalDeviceImageFormatInfo2:

  - VkPhysicalDeviceExternalImageFormatInfoKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceIDPropertiesKHR

#### New Enums

- VkExternalMemoryFeatureFlagBitsKHR

- VkExternalMemoryHandleTypeFlagBitsKHR

#### New Bitmasks

- VkExternalMemoryFeatureFlagsKHR

- VkExternalMemoryHandleTypeFlagsKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION`

- `VK_LUID_SIZE_KHR`

- Extending VkExternalMemoryFeatureFlagBits:

  - `VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_KHR`

- Extending VkExternalMemoryHandleTypeFlagBits:

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_KMT_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_HEAP_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D12_RESOURCE_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR`

  - `VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXTERNAL_BUFFER_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_EXTERNAL_IMAGE_FORMAT_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_BUFFER_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_IMAGE_FORMAT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR`

#### Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_external_semaphore_capabilities` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-21

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jason Ekstrand, Intel

  - Jesse Hall, Google

  - Tobias Hector, Imagination Technologies

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Matthew Netsch, Qualcomm Technologies, Inc.

  - Ray Smith, ARM

  - Chad Versace, Google

#### Description

An application using external memory may wish to synchronize access to that memory using semaphores. This extension enables an application to create semaphores from which non-Vulkan handles that reference the underlying synchronization primitive can be exported.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkSemaphoreCreateInfo:

  - VkExportSemaphoreCreateInfoKHR

#### New Enums

- VkSemaphoreImportFlagBitsKHR

#### New Bitmasks

- VkSemaphoreImportFlagsKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_SEMAPHORE_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_SEMAPHORE_SPEC_VERSION`

- Extending VkSemaphoreImportFlagBits:

  - `VK_SEMAPHORE_IMPORT_TEMPORARY_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR`

#### Issues

1) Should there be restrictions on what side effects can occur when waiting on imported semaphores that are in an invalid state?

RESOLVED: Yes. Normally, validating such state would be the responsibility of the application, and the implementation would be free to enter an undefined state if valid usage rules were violated. However, this could cause security concerns when using imported semaphores, as it would require the importing application to trust the exporting application to ensure the state is valid. Requiring this level of trust is undesirable for many potential use cases.

2) Must implementations validate external handles the application provides as input to semaphore state import operations?

RESOLVED: Implementations must return an error to the application if the provided semaphore state handle cannot be used to complete the requested import operation. However, implementations need not validate handles are of the exact type specified by the application.

#### Version History

- Revision 1, 2016-10-21 (James Jones)

  - Initial revision

#### VK_KHR_external_semaphore_capabilities

Name String

  `VK_KHR_external_semaphore_capabilities`

Extension Type

  Instance extension

Registered Extension Number

  77

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-10-20

IP Status

  No known IP claims.

Interactions and External Dependencies

  - 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 Commands

- vkGetPhysicalDeviceExternalSemaphorePropertiesKHR

#### New Structures

- VkExternalSemaphorePropertiesKHR

- VkPhysicalDeviceExternalSemaphoreInfoKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceIDPropertiesKHR

#### New Enums

- VkExternalSemaphoreFeatureFlagBitsKHR

- VkExternalSemaphoreHandleTypeFlagBitsKHR

#### New Bitmasks

- VkExternalSemaphoreFeatureFlagsKHR

- VkExternalSemaphoreHandleTypeFlagsKHR

#### New Enum Constants

- `VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME`

- `VK_KHR_EXTERNAL_SEMAPHORE_CAPABILITIES_SPEC_VERSION`

- `VK_LUID_SIZE_KHR`

- Extending VkExternalSemaphoreFeatureFlagBits:

  - `VK_EXTERNAL_SEMAPHORE_FEATURE_EXPORTABLE_BIT_KHR`

  - `VK_EXTERNAL_SEMAPHORE_FEATURE_IMPORTABLE_BIT_KHR`

- Extending VkExternalSemaphoreHandleTypeFlagBits:

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT_KHR`

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT_KHR`

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_BIT_KHR`

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_WIN32_KMT_BIT_KHR`

  - `VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_SEMAPHORE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHR`

#### Version History

- Revision 1, 2016-10-20 (James Jones)

  - Initial revision

#### VK_KHR_format_feature_flags2

Name String

  `VK_KHR_format_feature_flags2`

Extension Type

  Device extension

Registered Extension Number

  361

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Lionel Landwerlin llandwerlin

#### 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

  - Jason 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 implementations may not report `VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR` and `VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR` in VkFormatProperties3KHR::`bufferFeatures`. Despite this, buffer reads/writes are supported as intended by the original features.

#### New Structures

- Extending VkFormatProperties2:

  - VkFormatProperties3KHR

#### New Enums

- VkFormatFeatureFlagBits2KHR

#### New Bitmasks

- VkFormatFeatureFlags2KHR

#### New Enum Constants

- `VK_KHR_FORMAT_FEATURE_FLAGS_2_EXTENSION_NAME`

- `VK_KHR_FORMAT_FEATURE_FLAGS_2_SPEC_VERSION`

- Extending 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jason Ekstrand jekstrand

#### 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

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Jesse Hall, Google

#### Description

This extension provides new entry points to query memory requirements of images and buffers in a way 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 Commands

- vkGetBufferMemoryRequirements2KHR

- vkGetImageMemoryRequirements2KHR

- vkGetImageSparseMemoryRequirements2KHR

#### New Structures

- VkBufferMemoryRequirementsInfo2KHR

- VkImageMemoryRequirementsInfo2KHR

- VkImageSparseMemoryRequirementsInfo2KHR

- VkMemoryRequirements2KHR

- VkSparseImageMemoryRequirements2KHR

#### New Enum Constants

- `VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME`

- `VK_KHR_GET_MEMORY_REQUIREMENTS_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BUFFER_MEMORY_REQUIREMENTS_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_MEMORY_REQUIREMENTS_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_SPARSE_MEMORY_REQUIREMENTS_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_MEMORY_REQUIREMENTS_2_KHR`

  - `VK_STRUCTURE_TYPE_SPARSE_IMAGE_MEMORY_REQUIREMENTS_2_KHR`

#### Version History

- Revision 1, 2017-03-23 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

Contributors

  - Jeff Bolz, NVIDIA

  - Ian Elliott, Google

#### Description

This extension provides new entry points to query device features, device properties, and format properties in a way that can be easily extended by other extensions, without introducing any further entry points. The Vulkan 1.0 feature/limit/formatproperty structures do not include `sType`/`pNext` members. This extension wraps them in new structures with `sType`/`pNext` members, so an application can query a chain of feature/limit/formatproperty structures by constructing the chain and letting the implementation fill them in. A new command is added for each `vkGetPhysicalDevice*` command in core Vulkan 1.0. The new feature structure (and a `pNext` chain of extending structures) can also be passed in to device creation to enable features.

This extension also allows applications to use the physical-device components of device extensions before vkCreateDevice is called.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkGetPhysicalDeviceFeatures2KHR

- vkGetPhysicalDeviceFormatProperties2KHR

- vkGetPhysicalDeviceImageFormatProperties2KHR

- vkGetPhysicalDeviceMemoryProperties2KHR

- vkGetPhysicalDeviceProperties2KHR

- vkGetPhysicalDeviceQueueFamilyProperties2KHR

- vkGetPhysicalDeviceSparseImageFormatProperties2KHR

#### New Structures

- VkFormatProperties2KHR

- VkImageFormatProperties2KHR

- VkPhysicalDeviceImageFormatInfo2KHR

- VkPhysicalDeviceMemoryProperties2KHR

- VkPhysicalDeviceProperties2KHR

- VkPhysicalDeviceSparseImageFormatInfo2KHR

- VkQueueFamilyProperties2KHR

- VkSparseImageFormatProperties2KHR

- Extending VkDeviceCreateInfo:

  - VkPhysicalDeviceFeatures2KHR

#### New Enum Constants

- `VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME`

- `VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SPARSE_IMAGE_FORMAT_INFO_2_KHR`

  - `VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2_KHR`

  - `VK_STRUCTURE_TYPE_SPARSE_IMAGE_FORMAT_PROPERTIES_2_KHR`

#### Examples

        // Get features with a hypothetical future extension.
        VkHypotheticalExtensionFeaturesKHR hypotheticalFeatures =
        {
            VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,                // sType
            NULL,                                                       // pNext
        };

        VkPhysicalDeviceFeatures2KHR features =
        {
            VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,           // sType
            &hypotheticalFeatures,                                      // pNext
        };

        // 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 =
        {
            VK_STRUCTURE_TYPE_HYPOTHETICAL_FEATURES_KHR,                // sType
            NULL,                                                       // pNext
        };

        VkPhysicalDeviceFeatures2KHR enabledFeatures =
        {
            VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FEATURES_2_KHR,           // sType
            &enabledHypotheticalFeatures,                               // pNext
        };

        enabledFeatures.features.xyz = VK_TRUE;
        enabledHypotheticalFeatures.abc = VK_TRUE;

        VkDeviceCreateInfo deviceCreateInfo =
        {
            VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,                       // sType
            &enabledFeatures,                                           // pNext
            ...
            NULL,                                                       // pEnabledFeatures
        };

        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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jason Ekstrand jekstrand

#### 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

  - Jason Ekstrand, Intel

  - Jan-Harald Fredriksen, ARM

  - Jeff Bolz, NVIDIA

  - Jeff Leger, Qualcomm

  - Neil Henning, Codeplay

#### Description

On some implementations, setting the `VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT` on image creation can cause access to that image to perform worse than an equivalent image created without `VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT` because the implementation does not know what view formats will be paired with the image.

This extension allows an application to provide the list of all formats that can be used with an image when it is created. The implementation may then be able to create a more efficient image that supports the subset of formats required by the application without having to support all formats in the format compatibility class of the image format.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkImageCreateInfo, VkSwapchainCreateInfoKHR, VkPhysicalDeviceImageFormatInfo2:

  - VkImageFormatListCreateInfoKHR

#### New Enum Constants

- `VK_KHR_IMAGE_FORMAT_LIST_EXTENSION_NAME`

- `VK_KHR_IMAGE_FORMAT_LIST_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_FORMAT_LIST_CREATE_INFO_KHR`

#### Version History

- Revision 1, 2017-03-20 (Jason Ekstrand)

  - Initial revision

#### VK_KHR_imageless_framebuffer

Name String

  `VK_KHR_imageless_framebuffer`

Extension Type

  Device extension

Registered Extension Number

  109

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_maintenance2` to be enabled for any device-level functionality

  - Requires `VK_KHR_image_format_list` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Tobias Hector tobias

#### 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 Structures

- VkFramebufferAttachmentImageInfoKHR

- Extending VkFramebufferCreateInfo:

  - VkFramebufferAttachmentsCreateInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImagelessFramebufferFeaturesKHR

- Extending VkRenderPassBeginInfo:

  - VkRenderPassAttachmentBeginInfoKHR

#### New Enum Constants

- `VK_KHR_IMAGELESS_FRAMEBUFFER_EXTENSION_NAME`

- `VK_KHR_IMAGELESS_FRAMEBUFFER_SPEC_VERSION`

- Extending VkFramebufferCreateFlagBits:

  - `VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENTS_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_FRAMEBUFFER_ATTACHMENT_IMAGE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGELESS_FRAMEBUFFER_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_ATTACHMENT_BEGIN_INFO_KHR`

#### Version History

- Revision 1, 2018-12-14 (Tobias Hector)

  - Internal revisions

#### VK_KHR_maintenance1

Name String

  `VK_KHR_maintenance1`

Extension Type

  Device extension

Registered Extension Number

  70

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Piers Daniell pdaniell-nv

#### 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

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Jesse Hall, Google

  - John Kessenich, Google

  - Michael Worcester, Imagination Technologies

  - Neil Henning, Codeplay Software Ltd.

  - Piers Daniell, NVIDIA

  - Slawomir Grajewski, Intel

  - Tobias Hector, Imagination Technologies

  - Tom Olson, ARM

#### Description

`VK_KHR_maintenance1` adds a collection of minor features that were intentionally left out or overlooked from the original Vulkan 1.0 release.

The new features are as follows:

- Allow 2D and 2D array image views to be created from 3D images, which can then be used as color framebuffer attachments. This allows applications to render to slices of a 3D image.

- Support vkCmdCopyImage between 2D array layers and 3D slices. This extension allows copying from layers of a 2D array image to slices of a 3D image and vice versa.

- Allow negative height to be specified in the VkViewport::`height` field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to use `gl_Position.y = -gl_Position.y` in shaders also targeting other APIs.

- Allow implementations to express support for doing just transfers and clears of image formats that they otherwise support no other format features for. This is done by adding new format feature flags `VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR` and `VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR`.

- Support vkCmdFillBuffer on transfer-only queues. Previously vkCmdFillBuffer was defined to only work on command buffers allocated from command pools which support graphics or compute queues. It is now allowed on queues that just support transfer operations.

- Fix the inconsistency of how error conditions are returned between the vkCreateGraphicsPipelines and vkCreateComputePipelines functions and the vkAllocateDescriptorSets and vkAllocateCommandBuffers functions.

- Add new `VK_ERROR_OUT_OF_POOL_MEMORY_KHR` error so implementations can give a more precise reason for vkAllocateDescriptorSets failures.

- Add a new command vkTrimCommandPoolKHR which gives the implementation an opportunity to release any unused command pool memory back to the system.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkTrimCommandPoolKHR

#### New Bitmasks

- VkCommandPoolTrimFlagsKHR

#### New Enum Constants

- `VK_KHR_MAINTENANCE1_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE1_SPEC_VERSION`

- `VK_KHR_MAINTENANCE_1_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE_1_SPEC_VERSION`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR`

  - `VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT_KHR`

- Extending VkResult:

  - `VK_ERROR_OUT_OF_POOL_MEMORY_KHR`

#### Issues

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Michael Worcester michaelworcester

#### 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 combined depth stencil format) will be accessed via a `subpassLoad` operation.

On some implementations there may be a performance penalty if the implementation does not know (at vkCreateRenderPass time) which aspect(s) of multi-aspect images can be accessed as input attachments.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- VkInputAttachmentAspectReferenceKHR

- Extending VkImageViewCreateInfo:

  - VkImageViewUsageCreateInfoKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDevicePointClippingPropertiesKHR

- Extending VkPipelineTessellationStateCreateInfo:

  - VkPipelineTessellationDomainOriginStateCreateInfoKHR

- Extending VkRenderPassCreateInfo:

  - VkRenderPassInputAttachmentAspectCreateInfoKHR

#### New Enums

- VkPointClippingBehaviorKHR

- VkTessellationDomainOriginKHR

#### New Enum Constants

- `VK_KHR_MAINTENANCE2_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE2_SPEC_VERSION`

- `VK_KHR_MAINTENANCE_2_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE_2_SPEC_VERSION`

- Extending VkImageCreateFlagBits:

  - `VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT_KHR`

  - `VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL_KHR`

  - `VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL_KHR`

- Extending VkPointClippingBehavior:

  - `VK_POINT_CLIPPING_BEHAVIOR_ALL_CLIP_PLANES_KHR`

  - `VK_POINT_CLIPPING_BEHAVIOR_USER_CLIP_PLANES_ONLY_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_POINT_CLIPPING_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_PIPELINE_TESSELLATION_DOMAIN_ORIGIN_STATE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR`

- Extending VkTessellationDomainOrigin:

  - `VK_TESSELLATION_DOMAIN_ORIGIN_LOWER_LEFT_KHR`

  - `VK_TESSELLATION_DOMAIN_ORIGIN_UPPER_LEFT_KHR`

#### Input Attachment Specification Example

Consider the case where a render pass has two subpasses and two attachments.

Attachment 0 has the format `VK_FORMAT_D24_UNORM_S8_UINT`, attachment 1 has some color format.

Subpass 0 writes to attachment 0, subpass 1 reads only the depth information from attachment 0 (using inputAttachmentRead) and writes to attachment 1.

        VkInputAttachmentAspectReferenceKHR references[] = {
            {
                .subpass = 1,
                .inputAttachmentIndex = 0,
                .aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT
            }
        };

        VkRenderPassInputAttachmentAspectCreateInfoKHR specifyAspects = {
            .sType = VK_STRUCTURE_TYPE_RENDER_PASS_INPUT_ATTACHMENT_ASPECT_CREATE_INFO_KHR,
            .pNext = NULL,
            .aspectReferenceCount = 1,
            .pAspectReferences = references
        };

        VkRenderPassCreateInfo createInfo = {
            ...
            .pNext = &specifyAspects,
            ...
        };

        vkCreateRenderPass(...);

#### Issues

1) What is the default tessellation domain origin?

RESOLVED: Vulkan 1.0 originally inadvertently documented a lower-left origin, but the conformance tests and all implementations implemented an upper-left origin. This extension adds a control to select between lower-left (for compatibility with OpenGL) and upper-left, and we retroactively fix unextended Vulkan to have a default of an upper-left origin.

#### Version History

- Revision 1, 2017-04-28

#### VK_KHR_maintenance3

Name String

  `VK_KHR_maintenance3`

Extension Type

  Device extension

Registered Extension Number

  169

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### 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 Commands

- vkGetDescriptorSetLayoutSupportKHR

#### New Structures

- VkDescriptorSetLayoutSupportKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMaintenance3PropertiesKHR

#### New Enum Constants

- `VK_KHR_MAINTENANCE3_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE3_SPEC_VERSION`

- `VK_KHR_MAINTENANCE_3_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE_3_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_SUPPORT_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_3_PROPERTIES_KHR`

#### Version History

- Revision 1, 2017-08-22

#### VK_KHR_maintenance4

Name String

  `VK_KHR_maintenance4`

Extension Type

  Device extension

Registered Extension Number

  414

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2021-10-25

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

  - Requires SPIR-V 1.2 for `LocalSizeId`

Contributors

  - Lionel Duc, NVIDIA

  - Jason Ekstrand, Intel

  - Spencer Fricke, Samsung

  - Tobias Hector, AMD

  - Lionel Landwerlin, Intel

  - Graeme Leese, Broadcom

  - Tom Olson, Arm

  - Stu Smith, AMD

  - Yiwei Zhang, Google

#### Description

`VK_KHR_maintenance4` adds a collection of minor features, none of which would warrant an entire extension of their own.

The new features are as follows:

- Allow the application to destroy their VkPipelineLayout object immediately after it was used to create another object. It is no longer necessary to keep its handle valid while the created object is in use.

- Add a new `maxBufferSize` implementation-defined limit for the maximum size `VkBuffer` that can be created.

- Add support for the SPIR-V 1.2 `LocalSizeId` execution mode, which can be used as an alternative to `LocalSize` to specify the local workgroup size with specialization constants.

- Add a guarantee that images created with identical creation parameters will always have the same alignment requirements.

- Add new vkGetDeviceBufferMemoryRequirementsKHR, vkGetDeviceImageMemoryRequirementsKHR, and vkGetDeviceImageSparseMemoryRequirementsKHR to allow the application to query the image memory requirements without having to create an image object and query it.

- Relax the requirement that push constants must be initialized before they are dynamically accessed.

- Relax the interface matching rules to allow a larger output vector to match with a smaller input vector, with additional values being discarded.

- Add a guarantee for buffer memory requirement that the size memory requirement is never greater than the result of aligning create size with the alignment memory requirement.

#### New Commands

- vkGetDeviceBufferMemoryRequirementsKHR

- vkGetDeviceImageMemoryRequirementsKHR

- vkGetDeviceImageSparseMemoryRequirementsKHR

#### New Structures

- VkDeviceBufferMemoryRequirementsKHR

- VkDeviceImageMemoryRequirementsKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMaintenance4FeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMaintenance4PropertiesKHR

#### New Enum Constants

- `VK_KHR_MAINTENANCE_4_EXTENSION_NAME`

- `VK_KHR_MAINTENANCE_4_SPEC_VERSION`

- Extending VkImageAspectFlagBits:

  - `VK_IMAGE_ASPECT_NONE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_BUFFER_MEMORY_REQUIREMENTS_KHR`

  - `VK_STRUCTURE_TYPE_DEVICE_IMAGE_MEMORY_REQUIREMENTS_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MAINTENANCE_4_PROPERTIES_KHR`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2016-10-28

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.1 Core

  - This extension requires `SPV_KHR_multiview`

  - This extension provides API support for `GL_EXT_multiview`

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension has the same goal as the OpenGL ES `GL_OVR_multiview` extension. Multiview is a rendering technique originally designed for VR where it is more efficient to record a single set of commands to be executed with slightly different behavior for each “view”.

It includes a concise way to declare a render pass with multiple views, and gives implementations freedom to render the views in the most efficient way possible. This is done with a multiview configuration specified during render pass creation with the VkRenderPassMultiviewCreateInfo passed into VkRenderPassCreateInfo::`pNext`.

This extension enables the use of the `SPV_KHR_multiview` shader extension, which adds a new `ViewIndex` built-in type that allows shaders to control what to do for each view. If using GLSL there is also the `GL_EXT_multiview` extension that introduces a `highp int gl_ViewIndex;` built-in variable for vertex, tessellation, geometry, and fragment shaders.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceMultiviewFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceMultiviewPropertiesKHR

- Extending VkRenderPassCreateInfo:

  - VkRenderPassMultiviewCreateInfoKHR

#### New Enum Constants

- `VK_KHR_MULTIVIEW_EXTENSION_NAME`

- `VK_KHR_MULTIVIEW_SPEC_VERSION`

- Extending VkDependencyFlagBits:

  - `VK_DEPENDENCY_VIEW_LOCAL_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR`

#### New Built-In Variables

- `ViewIndex`

#### New SPIR-V Capabilities

- `MultiView`

#### Version History

- Revision 1, 2016-10-28 (Jeff Bolz)

  - Internal revisions

#### VK_KHR_relaxed_block_layout

Name String

  `VK_KHR_relaxed_block_layout`

Extension Type

  Device extension

Registered Extension Number

  145

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - John Kessenich johnkslang

#### Other Extension Metadata

Last Modified Date

  2017-03-26

IP Status

  No known IP claims.

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Tobias Hector tobski

#### 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 =
        {
            VK_STRUCTURE_TYPE_SAMPLER_CREATE_INFO // sType
            // 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_maintenance1` to be enabled for any device-level functionality

  - Requires `VK_KHR_bind_memory2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_memory_requirements2` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Andrew Garrard fluppeteer

#### Other Extension Metadata

Last Modified Date

  2017-08-11

IP Status

  No known IP claims.

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

- VkSamplerYcbcrConversionKHR

#### New Commands

- vkCreateSamplerYcbcrConversionKHR

- vkDestroySamplerYcbcrConversionKHR

#### New Structures

- VkSamplerYcbcrConversionCreateInfoKHR

- Extending VkBindImageMemoryInfo:

  - VkBindImagePlaneMemoryInfoKHR

- Extending VkImageFormatProperties2:

  - VkSamplerYcbcrConversionImageFormatPropertiesKHR

- Extending VkImageMemoryRequirementsInfo2:

  - VkImagePlaneMemoryRequirementsInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR

- Extending VkSamplerCreateInfo, VkImageViewCreateInfo:

  - VkSamplerYcbcrConversionInfoKHR

#### New Enums

- VkChromaLocationKHR

- VkSamplerYcbcrModelConversionKHR

- VkSamplerYcbcrRangeKHR

#### New Enum Constants

- `VK_KHR_SAMPLER_YCBCR_CONVERSION_EXTENSION_NAME`

- `VK_KHR_SAMPLER_YCBCR_CONVERSION_SPEC_VERSION`

- Extending VkChromaLocation:

  - `VK_CHROMA_LOCATION_COSITED_EVEN_KHR`

  - `VK_CHROMA_LOCATION_MIDPOINT_KHR`

- Extending VkDebugReportObjectTypeEXT:

  - `VK_DEBUG_REPORT_OBJECT_TYPE_SAMPLER_YCBCR_CONVERSION_KHR_EXT`

- 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`

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_create_renderpass2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Piers Daniell pdaniell-nv

#### 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 Structures

- Extending VkAttachmentDescription2:

  - VkAttachmentDescriptionStencilLayoutKHR

- Extending VkAttachmentReference2:

  - VkAttachmentReferenceStencilLayoutKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSeparateDepthStencilLayoutsFeaturesKHR

#### New Enum Constants

- `VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_EXTENSION_NAME`

- `VK_KHR_SEPARATE_DEPTH_STENCIL_LAYOUTS_SPEC_VERSION`

- Extending VkImageLayout:

  - `VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL_KHR`

  - `VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR`

  - `VK_IMAGE_LAYOUT_STENCIL_ATTACHMENT_OPTIMAL_KHR`

  - `VK_IMAGE_LAYOUT_STENCIL_READ_ONLY_OPTIMAL_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_ATTACHMENT_DESCRIPTION_STENCIL_LAYOUT_KHR`

  - `VK_STRUCTURE_TYPE_ATTACHMENT_REFERENCE_STENCIL_LAYOUT_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SEPARATE_DEPTH_STENCIL_LAYOUTS_FEATURES_KHR`

#### Version History

- Revision 1, 2019-06-25 (Piers Daniell)

  - Internal revisions

#### VK_KHR_shader_atomic_int64

Name String

  `VK_KHR_shader_atomic_int64`

Extension Type

  Device extension

Registered Extension Number

  181

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Aaron Hagan ahagan

#### Other Extension Metadata

Last Modified Date

  2018-07-05

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension provides API support for `GL_ARB_gpu_shader_int64` and `GL_EXT_shader_atomic_int64`

Contributors

  - Aaron Hagan, AMD

  - Daniel Rakos, AMD

  - Jeff Bolz, NVIDIA

  - Neil Henning, Codeplay

#### Description

This extension advertises the SPIR-V Int64Atomics capability for Vulkan, which allows a shader to contain 64-bit atomic operations on signed and unsigned integers. The supported operations include OpAtomicMin, OpAtomicMax, OpAtomicAnd, OpAtomicOr, OpAtomicXor, OpAtomicAdd, OpAtomicExchange, and OpAtomicCompareExchange.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, the `shaderBufferInt64Atomics` capability is optional. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderAtomicInt64FeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_ATOMIC_INT64_EXTENSION_NAME`

- `VK_KHR_SHADER_ATOMIC_INT64_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_ATOMIC_INT64_FEATURES_KHR`

#### New SPIR-V Capabilities

- `Int64Atomics`

#### Version History

- Revision 1, 2018-07-05 (Aaron Hagan)

  - Internal revisions

#### VK_KHR_shader_draw_parameters

Name String

  `VK_KHR_shader_draw_parameters`

Extension Type

  Device extension

Registered Extension Number

  64

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_shader_draw_parameters`

  - This extension provides API support for `GL_ARB_shader_draw_parameters`

  - Promoted to Vulkan 1.1 Core

Contributors

  - Daniel Koch, NVIDIA Corporation

  - Jeff Bolz, NVIDIA

  - Daniel Rakos, AMD

  - Jan-Harald Fredriksen, ARM

  - John Kessenich, Google

  - Stuart Smith, IMG

#### Description

This extension adds support for the following SPIR-V extension in Vulkan:

- `SPV_KHR_shader_draw_parameters`

The extension provides access to three additional built-in shader variables in Vulkan:

- `BaseInstance`, containing the `firstInstance` parameter passed to drawing commands,

- `BaseVertex`, containing the `firstVertex` or `vertexOffset` parameter passed to drawing commands, and

- `DrawIndex`, containing the index of the draw call currently being processed from an indirect drawing call.

When using GLSL source-based shader languages, the following variables from `GL_ARB_shader_draw_parameters` can map to these SPIR-V built-in decorations:

- `in int gl_BaseInstanceARB;` → `BaseInstance`,

- `in int gl_BaseVertexARB;` → `BaseVertex`, and

- `in int gl_DrawIDARB;` → `DrawIndex`.

#### Promotion to Vulkan 1.1

All functionality in this extension is included in core Vulkan 1.1. However, the `shaderDrawParameters` feature bit was added to distinguish whether it is actually available or not.

#### New Enum Constants

- `VK_KHR_SHADER_DRAW_PARAMETERS_EXTENSION_NAME`

- `VK_KHR_SHADER_DRAW_PARAMETERS_SPEC_VERSION`

#### New Built-In Variables

- `BaseInstance`

- `BaseVertex`

- `DrawIndex`

#### New SPIR-V Capabilities

- `DrawParameters`

#### Issues

1) Is this the same functionality as `GL_ARB_shader_draw_parameters`?

RESOLVED: It is actually a superset, as it also adds in support for arrayed drawing commands.

In GL for `GL_ARB_shader_draw_parameters`, `gl_BaseVertexARB` holds the integer value passed to the parameter to the command that resulted in the current shader invocation. In the case where the command has no `baseVertex` parameter, the value of `gl_BaseVertexARB` is zero. This means that `gl_BaseVertexARB` = `baseVertex` (for `glDrawElements` commands with `baseVertex`) or 0. In particular there are no `glDrawArrays` commands that take a `baseVertex` parameter.

Now in Vulkan, we have `BaseVertex` = `vertexOffset` (for indexed drawing commands) or `firstVertex` (for arrayed drawing commands), and so Vulkan’s version is really a superset of GL functionality.

#### Version History

- Revision 1, 2016-10-05 (Daniel Koch)

  - Internal revisions

#### VK_KHR_shader_float16_int8

Name String

  `VK_KHR_shader_float16_int8`

Extension Type

  Device extension

Registered Extension Number

  83

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Alexander Galazin alegal-arm

#### Other Extension Metadata

Last Modified Date

  2018-03-07

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension interacts with `VK_KHR_8bit_storage`

  - This extension interacts with `VK_KHR_16bit_storage`

  - This extension interacts with `VK_KHR_shader_float_controls`

  - This extension provides API support for `GL_EXT_shader_explicit_arithmetic_types`

IP Status

  No known IP claims.

Contributors

  - Alexander Galazin, Arm

  - Jan-Harald Fredriksen, Arm

  - Jeff Bolz, NVIDIA

  - Graeme Leese, Broadcom

  - Daniel Rakos, AMD

#### Description

The `VK_KHR_shader_float16_int8` extension allows use of 16-bit floating-point types and 8-bit integer types in shaders for arithmetic operations.

It introduces two new optional features `shaderFloat16` and `shaderInt8` which directly map to the `Float16` and the `Int8` SPIR-V capabilities. The `VK_KHR_shader_float16_int8` extension also specifies precision requirements for half-precision floating-point SPIR-V operations. This extension does not enable use of 8-bit integer types or 16-bit floating-point types in any shader input and output interfaces and therefore does not supersede the `VK_KHR_8bit_storage` or `VK_KHR_16bit_storage` extensions.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. However, if Vulkan 1.2 is supported and this extension is not, both the `shaderFloat16` and `shaderInt8` capabilities are optional. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFloat16Int8FeaturesKHR

  - VkPhysicalDeviceShaderFloat16Int8FeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_FLOAT16_INT8_EXTENSION_NAME`

- `VK_KHR_SHADER_FLOAT16_INT8_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_FLOAT16_INT8_FEATURES_KHR`

#### Version History

- Revision 1, 2018-03-07 (Alexander Galazin)

  - Initial draft

#### VK_KHR_shader_float_controls

Name String

  `VK_KHR_shader_float_controls`

Extension Type

  Device extension

Registered Extension Number

  198

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Alexander Galazin alegal-arm

#### Other Extension Metadata

Last Modified Date

  2018-09-11

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_KHR_float_controls`

IP Status

  No known IP claims.

Contributors

  - Alexander Galazin, Arm

  - Jan-Harald Fredriksen, Arm

  - Jeff Bolz, NVIDIA

  - Graeme Leese, Broadcom

  - Daniel Rakos, AMD

#### Description

The `VK_KHR_shader_float_controls` extension enables efficient use of floating-point computations through the ability to query and override the implementation’s default behavior for rounding modes, denormals, signed zero, and infinity.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceFloatControlsPropertiesKHR

#### New Enums

- VkShaderFloatControlsIndependenceKHR

#### New Enum Constants

- `VK_KHR_SHADER_FLOAT_CONTROLS_EXTENSION_NAME`

- `VK_KHR_SHADER_FLOAT_CONTROLS_SPEC_VERSION`

- Extending VkShaderFloatControlsIndependence:

  - `VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_32_BIT_ONLY_KHR`

  - `VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_ALL_KHR`

  - `VK_SHADER_FLOAT_CONTROLS_INDEPENDENCE_NONE_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR`

#### New SPIR-V Capabilities

- `DenormPreserve`

- `DenormFlushToZero`

- `SignedZeroInfNanPreserve`

- `RoundingModeRTE`

- `RoundingModeRTZ`

#### Issues

1) Which instructions must flush denorms?

RESOLVED: Only floating-point conversion, floating-point arithmetic, floating-point relational (except `OpIsNaN`, `OpIsInf`), and floating-point GLSL.std.450 extended instructions must flush denormals.

2) What is the denorm behavior for intermediate results?

RESOLVED: When a SPIR-V instruction is implemented as a sequence of other instructions:

- in the `DenormFlushToZero` execution mode, the intermediate instructions may flush denormals, the final result of the sequence must not be denormal.

- in the `DenormPreserve` execution mode, denormals must be preserved throughout the whole sequence.

3) Do denorm and rounding mode controls apply to `OpSpecConstantOp`?

RESOLVED: Yes, except when the opcode is `OpQuantizeToF16`.

4) The SPIR-V specification says that `OpConvertFToU` and `OpConvertFToS` unconditionally round towards zero. Do the rounding mode controls specified through the execution modes apply to them?

RESOLVED: No, these instructions unconditionally round towards zero.

5) Do any of the “Pack” GLSL.std.450 instructions count as conversion instructions and have the rounding mode applied?

RESOLVED: No, only instructions listed in “section 3.32.11. Conversion Instructions” of the SPIR-V specification count as conversion instructions.

6) When using inf/nan-ignore mode, what is expected of `OpIsNan` and `OpIsInf`?

RESOLVED: These instructions must always accurately detect inf/nan if it is passed to them.

#### Version 4 API incompatibility

The original versions of `VK_KHR_shader_float_controls` shipped with booleans named “separateDenormSettings” and “separateRoundingModeSettings”, which at first glance could have indicated “they can all be set independently, or not”. However the spec language as written indicated that the 32-bit value could always be set independently, and only the 16- and 64-bit controls needed to be the same if these values were `VK_FALSE`.

As a result of this slight disparity, and lack of test coverage for this facet of the extension, we ended up with two different behaviors in the wild, where some implementations worked as written, and others worked based on the naming. As these are hard limits in hardware with reasons for exposure as written, it was not possible to 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)

  - Modified settings restrictions, see Version 4 API incompatibility

- Revision 3, 2018-09-11 (Alexander Galazin)

  - Minor restructuring

- Revision 2, 2018-04-17 (Alexander Galazin)

  - Added issues and resolutions

- Revision 1, 2018-04-11 (Alexander Galazin)

  - Initial draft

#### VK_KHR_shader_integer_dot_product

Name String

  `VK_KHR_shader_integer_dot_product`

Extension Type

  Device extension

Registered Extension Number

  281

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Kevin Petit kevinpetit

Extension Proposal

  VK_KHR_shader_integer_dot_product

#### Other Extension Metadata

Last Modified Date

  2021-06-16

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

  - This extension requires `SPV_KHR_integer_dot_product`.

  - This extension interacts with `VK_KHR_shader_float16_int8`.

IP Status

  No known IP claims.

Contributors

  - Kévin Petit, Arm Ltd.

  - Jeff Bolz, NVidia

  - Spencer Fricke, Samsung

  - Jesse Hall, Google

  - John Kessenich, Google

  - Graeme Leese, Broadcom

  - Einar Hov, Arm Ltd.

  - Stuart Brady, Arm Ltd.

  - Pablo Cascon, Arm Ltd.

  - Tobias Hector, AMD

  - Jeff Leger, Qualcomm

  - Ruihao Zhang, Qualcomm

  - Pierre Boudier, NVidia

  - Jon Leech, The Khronos Group

  - Tom Olson, Arm Ltd.

#### Description

This extension adds support for the integer dot product SPIR-V instructions defined in SPV_KHR_integer_dot_product. These instructions are particularly useful for neural network inference and training but find uses in other general purpose compute applications as well.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderIntegerDotProductFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceShaderIntegerDotProductPropertiesKHR

#### New Enum Constants

- `VK_KHR_SHADER_INTEGER_DOT_PRODUCT_EXTENSION_NAME`

- `VK_KHR_SHADER_INTEGER_DOT_PRODUCT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_INTEGER_DOT_PRODUCT_PROPERTIES_KHR`

#### Promotion to Vulkan 1.3

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.

#### New SPIR-V Capabilities

- `DotProductInputAllKHR`

- `DotProductInput4x8BitKHR`

- `DotProductInput4x8BitPackedKHR`

- `DotProductKHR`

#### Version History

- Revision 1, 2021-06-16 (Kévin Petit)

  - Initial revision

#### VK_KHR_shader_non_semantic_info

Name String

  `VK_KHR_shader_non_semantic_info`

Extension Type

  Device extension

Registered Extension Number

  294

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Baldur Karlsson baldurk

#### Other Extension Metadata

Last Modified Date

  2019-10-16

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

  - This extension requires `SPV_KHR_non_semantic_info`

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Neil Henning sheredom

#### Other Extension Metadata

Last Modified Date

  2019-01-08

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension provides API support for `GLSL_EXT_shader_subgroup_extended_types`

Contributors

  - Jeff Bolz, NVIDIA

  - Jan-Harald Fredriksen, Arm

  - Neil Henning, AMD

  - Daniel Koch, NVIDIA

  - Jeff Leger, Qualcomm

  - Graeme Leese, Broadcom

  - David Neto, Google

  - Daniel Rakos, AMD

#### Description

This extension enables the Non Uniform Group Operations in SPIR-V to support 8-bit integer, 16-bit integer, 64-bit integer, 16-bit floating-point, and vectors of these types.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderSubgroupExtendedTypesFeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_EXTENSION_NAME`

- `VK_KHR_SHADER_SUBGROUP_EXTENDED_TYPES_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_SUBGROUP_EXTENDED_TYPES_FEATURES_KHR`

#### Version History

- Revision 1, 2019-01-08 (Neil Henning)

  - Initial draft

#### VK_KHR_shader_terminate_invocation

Name String

  `VK_KHR_shader_terminate_invocation`

Extension Type

  Device extension

Registered Extension Number

  216

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2020-08-11

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

  - Requires the `SPV_KHR_terminate_invocation` SPIR-V extension.

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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderTerminateInvocationFeaturesKHR

#### New Enum Constants

- `VK_KHR_SHADER_TERMINATE_INVOCATION_EXTENSION_NAME`

- `VK_KHR_SHADER_TERMINATE_INVOCATION_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_TERMINATE_INVOCATION_FEATURES_KHR`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

  - Requires `VK_KHR_shader_float_controls` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2019-04-01

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Requires SPIR-V 1.4.

  - 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Alexander Galazin alegal-arm

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_storage_buffer_storage_class`

  - Promoted to Vulkan 1.1 Core

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Tobias Hector tobski

#### Other Extension Metadata

Last Modified Date

  2020-12-03

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

  - Interacts with `VK_KHR_create_renderpass2`

Contributors

  - Tobias Hector

#### Description

This extension modifies the original core synchronization APIs to simplify the interface and improve usability of these APIs. It also adds new pipeline stage and access flag types that extend into the 64-bit range, as we have run out within the 32-bit range. The new flags are identical to the old values within the 32-bit range, with new stages and bits beyond that.

Pipeline stages and access flags are now specified together in memory barrier structures, making the connection between the two more obvious. Additionally, scoping the pipeline stages into the barrier structs allows the use of the `MEMORY_READ` and `MEMORY_WRITE` flags without sacrificing precision. The per-stage access flags should be used to disambiguate specific accesses in a given stage or set of stages - for instance, between uniform reads and sampling operations.

Layout transitions have been simplified as well; rather than requiring a different set of layouts for depth/stencil/color attachments, there are generic `VK_IMAGE_LAYOUT_ATTACHMENT_OPTIMAL_KHR` and `VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR` layouts which are contextually applied based on the image format. For example, for a depth format image, `VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR` is equivalent to `VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL_KHR`. `VK_IMAGE_LAYOUT_READ_ONLY_OPTIMAL_KHR` also functionally replaces `VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL`.

Events are now more efficient, because they include memory dependency information when you set them on the device. Previously, this information was only known when waiting on an event, so the dependencies could not be satisfied until the wait occurred. That sometimes meant stalling the pipeline when the wait occurred. The new API provides enough information for implementations to satisfy these dependencies in parallel with other tasks.

Queue submission has been changed to wrap command buffers and semaphores in extensible structures, which incorporate changes from Vulkan 1.1, `VK_KHR_device_group`, and `VK_KHR_timeline_semaphore`. This also adds a pipeline stage to the semaphore signal operation, mirroring the existing pipeline stage specification for wait operations.

Other miscellaneous changes include:

- Events can now be specified as interacting only with the device, allowing more efficient access to the underlying object.

- Image memory barriers that do not perform an image layout transition can be specified by setting `oldLayout` equal to `newLayout`.

  - E.g. the old and new layout can both be set to `VK_IMAGE_LAYOUT_UNDEFINED`, without discarding data in the image.

- Queue family ownership transfer parameters are simplified in some cases.

- 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

- `VkFlags64`

#### New Commands

- vkCmdPipelineBarrier2KHR

- vkCmdResetEvent2KHR

- vkCmdSetEvent2KHR

- vkCmdWaitEvents2KHR

- vkCmdWriteTimestamp2KHR

- vkQueueSubmit2KHR

If VK_AMD_buffer_marker is supported:

- vkCmdWriteBufferMarker2AMD

If VK_NV_device_diagnostic_checkpoints is supported:

- vkGetQueueCheckpointData2NV

#### New Structures

- VkBufferMemoryBarrier2KHR

- VkCommandBufferSubmitInfoKHR

- VkDependencyInfoKHR

- VkImageMemoryBarrier2KHR

- VkSemaphoreSubmitInfoKHR

- VkSubmitInfo2KHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSynchronization2FeaturesKHR

- Extending VkSubpassDependency2:

  - VkMemoryBarrier2KHR

If VK_NV_device_diagnostic_checkpoints is supported:

- VkCheckpointData2NV

- Extending VkQueueFamilyProperties2:

  - VkQueueFamilyCheckpointProperties2NV

#### New Enums

- VkAccessFlagBits2KHR

- VkPipelineStageFlagBits2KHR

- VkSubmitFlagBitsKHR

#### New Bitmasks

- VkAccessFlags2KHR

- VkPipelineStageFlags2KHR

- VkSubmitFlagsKHR

#### New Enum Constants

- `VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME`

- `VK_KHR_SYNCHRONIZATION_2_SPEC_VERSION`

- Extending VkAccessFlagBits:

  - `VK_ACCESS_NONE_KHR`

- Extending 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_blend_operation_advanced is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_COLOR_ATTACHMENT_READ_NONCOHERENT_BIT_EXT`

If VK_EXT_conditional_rendering is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_CONDITIONAL_RENDERING_READ_BIT_EXT`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_CONDITIONAL_RENDERING_BIT_EXT`

If VK_EXT_fragment_density_map is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_FRAGMENT_DENSITY_MAP_READ_BIT_EXT`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_FRAGMENT_DENSITY_PROCESS_BIT_EXT`

If VK_EXT_mesh_shader is supported:

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_MESH_SHADER_BIT_EXT`

  - `VK_PIPELINE_STAGE_2_TASK_SHADER_BIT_EXT`

If VK_EXT_transform_feedback is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT`

  - `VK_ACCESS_2_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT`

  - `VK_ACCESS_2_TRANSFORM_FEEDBACK_WRITE_BIT_EXT`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_TRANSFORM_FEEDBACK_BIT_EXT`

If VK_KHR_acceleration_structure is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_KHR`

  - `VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_KHR`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_KHR`

If VK_KHR_fragment_shading_rate is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR`

If VK_KHR_ray_tracing_pipeline is supported:

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_KHR`

If VK_NV_device_diagnostic_checkpoints is supported:

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_CHECKPOINT_DATA_2_NV`

  - `VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_2_NV`

If VK_NV_device_generated_commands is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_COMMAND_PREPROCESS_READ_BIT_NV`

  - `VK_ACCESS_2_COMMAND_PREPROCESS_WRITE_BIT_NV`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_COMMAND_PREPROCESS_BIT_NV`

If VK_NV_mesh_shader is supported:

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_MESH_SHADER_BIT_NV`

  - `VK_PIPELINE_STAGE_2_TASK_SHADER_BIT_NV`

If VK_NV_ray_tracing is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_ACCELERATION_STRUCTURE_READ_BIT_NV`

  - `VK_ACCESS_2_ACCELERATION_STRUCTURE_WRITE_BIT_NV`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_ACCELERATION_STRUCTURE_BUILD_BIT_NV`

  - `VK_PIPELINE_STAGE_2_RAY_TRACING_SHADER_BIT_NV`

If VK_NV_shading_rate_image is supported:

- Extending VkAccessFlagBits2:

  - `VK_ACCESS_2_SHADING_RATE_IMAGE_READ_BIT_NV`

- Extending VkPipelineStageFlagBits2:

  - `VK_PIPELINE_STAGE_2_SHADING_RATE_IMAGE_BIT_NV`

#### Promotion to Vulkan 1.3

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.

#### Examples

See https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jason Ekstrand jekstrand

#### Other Extension Metadata

Last Modified Date

  2019-06-12

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension interacts with `VK_KHR_external_semaphore_capabilities`

  - This extension interacts with `VK_KHR_external_semaphore`

  - This extension interacts with `VK_KHR_external_semaphore_win32`

  - Promoted to Vulkan 1.2 Core

Contributors

  - Jeff Bolz, NVIDIA

  - Yuriy O’Donnell, Epic Games

  - Jason Ekstrand, Intel

  - Jesse Hall, Google

  - James Jones, NVIDIA

  - Jeff Juliano, NVIDIA

  - Daniel Rakos, AMD

  - Ray Smith, Arm

#### Description

This extension introduces a new type of semaphore that has an integer payload identifying a point in a timeline. Such timeline semaphores support the following operations:

- Host query - A host operation that allows querying the payload of the timeline semaphore.

- Host wait - A host operation that allows a blocking wait for a timeline semaphore to reach a specified value.

- Host signal - A host operation that allows advancing the timeline semaphore to a specified value.

- Device wait - A device operation that allows waiting for a timeline semaphore to reach a specified value.

- Device signal - A device operation that allows advancing the timeline semaphore to a specified value.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the KHR suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkGetSemaphoreCounterValueKHR

- vkSignalSemaphoreKHR

- vkWaitSemaphoresKHR

#### New Structures

- VkSemaphoreSignalInfoKHR

- VkSemaphoreWaitInfoKHR

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTimelineSemaphoreFeaturesKHR

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceTimelineSemaphorePropertiesKHR

- Extending VkSemaphoreCreateInfo, VkPhysicalDeviceExternalSemaphoreInfo:

  - VkSemaphoreTypeCreateInfoKHR

- Extending VkSubmitInfo, VkBindSparseInfo:

  - VkTimelineSemaphoreSubmitInfoKHR

#### New Enums

- VkSemaphoreTypeKHR

- VkSemaphoreWaitFlagBitsKHR

#### New Bitmasks

- VkSemaphoreWaitFlagsKHR

#### New Enum Constants

- `VK_KHR_TIMELINE_SEMAPHORE_EXTENSION_NAME`

- `VK_KHR_TIMELINE_SEMAPHORE_SPEC_VERSION`

- Extending VkSemaphoreType:

  - `VK_SEMAPHORE_TYPE_BINARY_KHR`

  - `VK_SEMAPHORE_TYPE_TIMELINE_KHR`

- Extending VkSemaphoreWaitFlagBits:

  - `VK_SEMAPHORE_WAIT_ANY_BIT_KHR`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_PROPERTIES_KHR`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_SIGNAL_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO_KHR`

  - `VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO_KHR`

  - `VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO_KHR`

#### Issues

1) Do we need a new object type for this?

RESOLVED: No, we just introduce a new type of semaphore object, as `VK_KHR_external_semaphore_win32` already uses semaphores as the destination for importing D3D12 fence objects, which are semantically close/identical to the proposed synchronization primitive.

2) What type of payload the new synchronization primitive has?

RESOLVED: A 64-bit unsigned integer that can only be set to strictly increasing values by signal operations and is not changed by wait operations.

3) Does the new synchronization primitive have the same signal-before-wait requirement as the existing semaphores do?

RESOLVED: No. Timeline semaphores support signaling and waiting entirely asynchronously. It is the responsibility of the 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 (Jason Ekstrand)

  - Initial version

- Revision 2, 2019-06-12 (Jason 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Graeme Leese gnl21

#### 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

  - Jason 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceUniformBufferStandardLayoutFeaturesKHR

#### New Enum Constants

- `VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_EXTENSION_NAME`

- `VK_KHR_UNIFORM_BUFFER_STANDARD_LAYOUT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_UNIFORM_BUFFER_STANDARD_LAYOUT_FEATURES_KHR`

#### Version History

- Revision 1, 2019-01-25 (Graeme Leese)

  - Initial draft

#### VK_KHR_variable_pointers

Name String

  `VK_KHR_variable_pointers`

Extension Type

  Device extension

Registered Extension Number

  121

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_storage_buffer_storage_class` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.1

Contact

  - Jesse Hall critsec

#### Other Extension Metadata

Last Modified Date

  2017-09-05

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_variable_pointers`

  - Promoted to Vulkan 1.1 Core

Contributors

  - John Kessenich, Google

  - Neil Henning, Codeplay

  - David Neto, Google

  - Daniel Koch, Nvidia

  - Graeme Leese, Broadcom

  - Weifeng Zhang, Qualcomm

  - Stephen Clarke, Imagination Technologies

  - Jason 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceVariablePointerFeaturesKHR

  - VkPhysicalDeviceVariablePointersFeaturesKHR

#### New Enum Constants

- `VK_KHR_VARIABLE_POINTERS_EXTENSION_NAME`

- `VK_KHR_VARIABLE_POINTERS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTERS_FEATURES_KHR`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VARIABLE_POINTER_FEATURES_KHR`

#### New SPIR-V Capabilities

- `VariablePointers`

- `VariablePointersStorageBuffer`

#### Issues

1) Do we need an optional property for the SPIR-V `VariablePointersStorageBuffer` capability or should it be mandatory when this extension is advertised?

RESOLVED: Add it as a distinct feature, but make support mandatory. Adding it as a feature makes the extension easier to include in a future core API version. In the extension, the feature is mandatory, so that presence of the extension guarantees some functionality. When included in a core API version, the feature would be optional.

2) Can support for these capabilities vary between shader stages?

RESOLVED: No, if the capability is supported in any stage it must be supported in all stages.

3) Should the capabilities be features or limits?

RESOLVED: Features, primarily for consistency with other similar extensions.

#### Version History

- Revision 1, 2017-03-14 (Jesse Hall and John Kessenich)

  - Internal revisions

#### VK_KHR_vulkan_memory_model

Name String

  `VK_KHR_vulkan_memory_model`

Extension Type

  Device extension

Registered Extension Number

  212

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2018-12-10

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_KHR_vulkan_memory_model`

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 Vulkan Memory Model, which 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceVulkanMemoryModelFeaturesKHR

#### New Enum Constants

- `VK_KHR_VULKAN_MEMORY_MODEL_EXTENSION_NAME`

- `VK_KHR_VULKAN_MEMORY_MODEL_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR`

#### New SPIR-V Capabilities

- `VulkanMemoryModelKHR`

#### Version History

- Revision 1, 2018-06-24 (Jeff Bolz)

  - Initial draft

- Revision 3, 2018-12-10 (Jeff Bolz)

  - Add vulkanMemoryModelAvailabilityVisibilityChains member to the VkPhysicalDeviceVulkanMemoryModelFeaturesKHR structure.

#### VK_KHR_zero_initialize_workgroup_memory

Name String

  `VK_KHR_zero_initialize_workgroup_memory`

Extension Type

  Device extension

Registered Extension Number

  326

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Alan Baker alan-baker

#### 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

  - Jason Ekstrand, Intel

#### Description

This extension allows the use of a null constant initializer on shader Workgroup memory variables, allowing implementations to expose any special hardware or instructions they may have. Zero initialization is commonly used by applications running untrusted content (e.g. web browsers) as way of defeating memory-scraping attacks.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceZeroInitializeWorkgroupMemoryFeaturesKHR

#### New Enum Constants

- `VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_EXTENSION_NAME`

- `VK_KHR_ZERO_INITIALIZE_WORKGROUP_MEMORY_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ZERO_INITIALIZE_WORKGROUP_MEMORY_FEATURES_KHR`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Joshua Ashton Joshua-Ashton

#### 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

  - Jason Ekstrand, Intel

#### Description

This extension defines the `VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT` and `VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT` formats which are defined in other current graphics APIs.

This extension may be useful for building translation layers for those APIs or for porting applications that use these formats without having to resort to swizzles.

When VK_EXT_custom_border_color is used, these formats are not subject to the same restrictions for border color without format as with VK_FORMAT_B4G4R4A4_UNORM_PACK16.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevice4444FormatsFeaturesEXT

#### New Enum Constants

- `VK_EXT_4444_FORMATS_EXTENSION_NAME`

- `VK_EXT_4444_FORMATS_SPEC_VERSION`

- Extending VkFormat:

  - `VK_FORMAT_A4B4G4R4_UNORM_PACK16_EXT`

  - `VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_4444_FORMATS_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Deprecated by `VK_KHR_buffer_device_address` extension

    - Which in turn was promoted to Vulkan 1.2

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2019-01-06

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_EXT_physical_storage_buffer`

  - This extension provides API support for `GLSL_EXT_buffer_reference` and `GLSL_EXT_buffer_reference_uvec2`

Contributors

  - Jeff Bolz, NVIDIA

  - Neil Henning, AMD

  - Tobias Hector, AMD

  - Jason Ekstrand, Intel

  - Baldur Karlsson, Valve

#### Description

This extension allows the application to query a 64-bit buffer device address value for a buffer, which can be used to access the buffer memory via the `PhysicalStorageBufferEXT` storage class in the `GL_EXT_buffer_reference` GLSL extension and `SPV_EXT_physical_storage_buffer` SPIR-V extension.

It also allows buffer device addresses to be provided by a trace replay tool, so that it matches the address used when the trace was captured.

#### New Commands

- vkGetBufferDeviceAddressEXT

#### New Structures

- VkBufferDeviceAddressInfoEXT

- Extending VkBufferCreateInfo:

  - VkBufferDeviceAddressCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceBufferAddressFeaturesEXT

  - VkPhysicalDeviceBufferDeviceAddressFeaturesEXT

#### New Enum Constants

- `VK_EXT_BUFFER_DEVICE_ADDRESS_EXTENSION_NAME`

- `VK_EXT_BUFFER_DEVICE_ADDRESS_SPEC_VERSION`

- Extending VkBufferCreateFlagBits:

  - `VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT_EXT`

- Extending VkBufferUsageFlagBits:

  - `VK_BUFFER_USAGE_SHADER_DEVICE_ADDRESS_BIT_EXT`

- Extending VkResult:

  - `VK_ERROR_INVALID_DEVICE_ADDRESS_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_BUFFER_DEVICE_ADDRESS_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT`

#### New SPIR-V Capabilities

- `PhysicalStorageBufferAddressesEXT`

#### Issues

1) Where is VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_ADDRESS_FEATURES_EXT and VkPhysicalDeviceBufferAddressFeaturesEXT?

RESOLVED: They were renamed as `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_BUFFER_DEVICE_ADDRESS_FEATURES_EXT` and VkPhysicalDeviceBufferDeviceAddressFeaturesEXT accordingly for consistency. Even though, the old names can still be found in the generated header files for compatibility.

#### Version History

- Revision 1, 2018-11-01 (Jeff Bolz)

  - Internal revisions

- Revision 2, 2019-01-06 (Jon Leech)

  - Minor updates to appendix for publication

#### VK_EXT_debug_marker

Name String

  `VK_EXT_debug_marker`

Extension Type

  Device extension

Registered Extension Number

  23

Revision

  4

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_debug_report` to be enabled for any device-level functionality

Deprecation state

  - Promoted to `VK_EXT_debug_utils` extension

Special Use

  - Debugging tools

Contact

  - Baldur Karlsson baldurk

#### Other Extension Metadata

Last Modified Date

  2017-01-31

IP Status

  No known IP claims.

Contributors

  - Baldur Karlsson

  - Dan Ginsburg, Valve

  - Jon Ashburn, LunarG

  - Kyle Spagnoli, NVIDIA

#### Description

The `VK_EXT_debug_marker` extension is a device extension. It introduces concepts of object naming and tagging, for better tracking of Vulkan objects, as well as additional commands for recording annotations of named sections of a workload to aid organization and offline analysis in external tools.

#### New Commands

- vkCmdDebugMarkerBeginEXT

- vkCmdDebugMarkerEndEXT

- vkCmdDebugMarkerInsertEXT

- vkDebugMarkerSetObjectNameEXT

- vkDebugMarkerSetObjectTagEXT

#### New Structures

- VkDebugMarkerMarkerInfoEXT

- VkDebugMarkerObjectNameInfoEXT

- VkDebugMarkerObjectTagInfoEXT

#### New Enums

- VkDebugReportObjectTypeEXT

#### New Enum Constants

- `VK_EXT_DEBUG_MARKER_EXTENSION_NAME`

- `VK_EXT_DEBUG_MARKER_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_TAG_INFO_EXT`

#### Examples

Example 1

Associate a name with an image, for easier debugging in external tools or with validation layers that can print a friendly name when referring to objects in error messages.

        extern VkDevice device;
        extern VkImage image;

        // Must call extension functions through a function pointer:
        PFN_vkDebugMarkerSetObjectNameEXT pfnDebugMarkerSetObjectNameEXT = (PFN_vkDebugMarkerSetObjectNameEXT)vkGetDeviceProcAddr(device, "vkDebugMarkerSetObjectNameEXT");

        // Set a name on the image
        const VkDebugMarkerObjectNameInfoEXT imageNameInfo =
        {
            VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT, // sType
            NULL,                                           // pNext
            VK_DEBUG_REPORT_OBJECT_TYPE_IMAGE_EXT,          // objectType
            (uint64_t)image,                                // object
            "Brick Diffuse Texture",                        // pObjectName
        };

        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 =
        {
            VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT, // sType
            NULL,                                           // pNext
            "Brick House",                                  // pMarkerName
            { 1.0f, 0.0f, 0.0f, 1.0f },                     // color
        };

        // Start an annotated group of calls under the 'Brick House' name
        pfnCmdDebugMarkerBeginEXT(commandBuffer, &houseMarker);
        {
            // A mutable structure for each part being rendered
            VkDebugMarkerMarkerInfoEXT housePartMarker =
            {
                VK_STRUCTURE_TYPE_DEBUG_MARKER_MARKER_INFO_EXT, // sType
                NULL,                                           // pNext
                NULL,                                           // pMarkerName
                { 0.0f, 0.0f, 0.0f, 0.0f },                     // color
            };

            // 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_EXT_debug_utils` extension

Special Use

  - Debugging tools

Contact

  - Courtney Goeltzenleuchter courtney-g

#### Other Extension Metadata

Last Modified Date

  2020-12-14

IP Status

  No known IP claims.

Contributors

  - Courtney Goeltzenleuchter, LunarG

  - Dan Ginsburg, Valve

  - Jon Ashburn, LunarG

  - Mark Lobodzinski, LunarG

#### Description

Due to the nature of the Vulkan interface, there is very little error information available to the developer and application. By enabling optional validation layers and using the `VK_EXT_debug_report` extension, developers can obtain much more detailed feedback on the application’s use of Vulkan. This extension defines a way for layers and the implementation to call back to the application for events of interest to the application.

#### New Object Types

- VkDebugReportCallbackEXT

#### New Commands

- vkCreateDebugReportCallbackEXT

- vkDebugReportMessageEXT

- vkDestroyDebugReportCallbackEXT

#### New Structures

- Extending VkInstanceCreateInfo:

  - VkDebugReportCallbackCreateInfoEXT

#### New Function Pointers

- PFN_vkDebugReportCallbackEXT

#### New Enums

- VkDebugReportFlagBitsEXT

- VkDebugReportObjectTypeEXT

#### New Bitmasks

- VkDebugReportFlagsEXT

#### New Enum Constants

- `VK_EXT_DEBUG_REPORT_EXTENSION_NAME`

- `VK_EXT_DEBUG_REPORT_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_DEBUG_REPORT_CALLBACK_EXT`

- Extending VkResult:

  - `VK_ERROR_VALIDATION_FAILED_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT`

If 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 = {
                VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,    // sType
                NULL,                                                       // pNext
                VK_DEBUG_REPORT_ERROR_BIT_EXT |                             // flags
                VK_DEBUG_REPORT_WARNING_BIT_EXT,
                myOutputDebugString,                                        // pfnCallback
                NULL                                                        // pUserData
        };
        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 = {
                VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,    // sType
                NULL,                                                       // pNext
                VK_DEBUG_REPORT_WARNING_BIT_EXT,                            // flags
                mystdOutLogger,                                             // pfnCallback
                NULL                                                        // pUserData
        };
        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)

  - Moved definition of VkDebugReportObjectTypeEXT from debug marker chapter

- Revision 6, 2017-01-31 (Baldur Karlsson)

  - Added VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT

- Revision 7, 2017-04-20 (Courtney Goeltzenleuchter)

  - Clarify wording and address questions from developers.

- Revision 8, 2017-04-21 (Courtney Goeltzenleuchter)

  - Remove unused enum VkDebugReportErrorEXT

- Revision 9, 2017-09-12 (Tobias Hector)

  - Added interactions with Vulkan 1.1

- Revision 10, 2020-12-14 (Courtney Goetzenleuchter)

  - Add issue 4 discussing matching handles returned by the extension, based on suggestion in public issue 368.

#### VK_EXT_descriptor_indexing

Name String

  `VK_EXT_descriptor_indexing`

Extension Type

  Device extension

Registered Extension Number

  162

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_maintenance3` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2017-10-02

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_EXT_descriptor_indexing`

  - This extension provides API support for `GL_EXT_nonuniform_qualifier`

Contributors

  - Jeff Bolz, NVIDIA

  - Daniel Rakos, AMD

  - Slawomir Grajewski, Intel

  - Tobias Hector, Imagination Technologies

#### Description

This extension adds several small features which together enable applications to create large descriptor sets containing substantially all of their resources, and selecting amongst those resources with dynamic (non-uniform) indexes in the shader. There are feature enables and SPIR-V capabilities for non-uniform descriptor indexing in the shader, and non-uniform indexing in the shader requires use of a new `NonUniformEXT` decoration defined in the `SPV_EXT_descriptor_indexing` SPIR-V extension. There are descriptor set layout binding creation flags enabling several features:

- Descriptors can be updated after they are bound to a command buffer, such that the execution of the command buffer reflects the most recent update to the descriptors.

- Descriptors that are not used by any pending command buffers can be updated, which enables writing new descriptors for frame N+1 while frame N is executing.

- Relax the requirement that all descriptors in a binding that is “statically used” must be valid, such that descriptors that are not accessed by a submission need not be valid and can be updated while that submission is executing.

- The final binding in a descriptor set layout can have a variable size (and unsized arrays of resources are allowed in the `GL_EXT_nonuniform_qualifier` and `SPV_EXT_descriptor_indexing` extensions).

Note that it is valid for multiple descriptor arrays in a shader to use the same set and binding number, as long as they are all compatible with the descriptor type in the pipeline layout. This means a single array binding in the descriptor set can serve multiple texture dimensionalities, or an array of buffer descriptors can be used with multiple different block layouts.

There are new descriptor set layout and descriptor pool creation flags that are required to opt in to the update-after-bind functionality, and there are separate `maxPerStage`* and `maxDescriptorSet`* limits that apply to these descriptor set layouts which may be much higher than the pre-existing limits. The old limits only count descriptors in non-updateAfterBind descriptor set layouts, and the new limits count descriptors in all descriptor set layouts in the pipeline layout.

#### New Structures

- Extending VkDescriptorSetAllocateInfo:

  - VkDescriptorSetVariableDescriptorCountAllocateInfoEXT

- Extending VkDescriptorSetLayoutCreateInfo:

  - VkDescriptorSetLayoutBindingFlagsCreateInfoEXT

- Extending VkDescriptorSetLayoutSupport:

  - VkDescriptorSetVariableDescriptorCountLayoutSupportEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceDescriptorIndexingFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceDescriptorIndexingPropertiesEXT

#### New Enums

- VkDescriptorBindingFlagBitsEXT

#### New Bitmasks

- VkDescriptorBindingFlagsEXT

#### New Enum Constants

- `VK_EXT_DESCRIPTOR_INDEXING_EXTENSION_NAME`

- `VK_EXT_DESCRIPTOR_INDEXING_SPEC_VERSION`

- Extending VkDescriptorBindingFlagBits:

  - `VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT_EXT`

  - `VK_DESCRIPTOR_BINDING_UPDATE_AFTER_BIND_BIT_EXT`

  - `VK_DESCRIPTOR_BINDING_UPDATE_UNUSED_WHILE_PENDING_BIT_EXT`

  - `VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT`

- Extending VkDescriptorPoolCreateFlagBits:

  - `VK_DESCRIPTOR_POOL_CREATE_UPDATE_AFTER_BIND_BIT_EXT`

- Extending VkDescriptorSetLayoutCreateFlagBits:

  - `VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT`

- Extending VkResult:

  - `VK_ERROR_FRAGMENTATION_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_ALLOCATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_SET_VARIABLE_DESCRIPTOR_COUNT_LAYOUT_SUPPORT_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DESCRIPTOR_INDEXING_PROPERTIES_EXT`

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Piers Daniell pdaniell-nv

#### 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

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Jesse Hall, Google

  - Philip Rebohle, Valve Corporation

  - Stuart Smith, Imagination Technologies

  - Tobias Hector, AMD

#### Description

This extension adds some more dynamic state to support applications that need to reduce the number of pipeline state objects they compile and bind.

#### New Commands

- vkCmdBindVertexBuffers2EXT

- vkCmdSetCullModeEXT

- vkCmdSetDepthBoundsTestEnableEXT

- vkCmdSetDepthCompareOpEXT

- vkCmdSetDepthTestEnableEXT

- vkCmdSetDepthWriteEnableEXT

- vkCmdSetFrontFaceEXT

- vkCmdSetPrimitiveTopologyEXT

- vkCmdSetScissorWithCountEXT

- vkCmdSetStencilOpEXT

- vkCmdSetStencilTestEnableEXT

- vkCmdSetViewportWithCountEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceExtendedDynamicStateFeaturesEXT

#### New Enum Constants

- `VK_EXT_EXTENDED_DYNAMIC_STATE_EXTENSION_NAME`

- `VK_EXT_EXTENDED_DYNAMIC_STATE_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_CULL_MODE_EXT`

  - `VK_DYNAMIC_STATE_DEPTH_BOUNDS_TEST_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_DEPTH_COMPARE_OP_EXT`

  - `VK_DYNAMIC_STATE_DEPTH_TEST_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_DEPTH_WRITE_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_FRONT_FACE_EXT`

  - `VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY_EXT`

  - `VK_DYNAMIC_STATE_SCISSOR_WITH_COUNT_EXT`

  - `VK_DYNAMIC_STATE_STENCIL_OP_EXT`

  - `VK_DYNAMIC_STATE_STENCIL_TEST_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE_EXT`

  - `VK_DYNAMIC_STATE_VIEWPORT_WITH_COUNT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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.

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Vikram Kushwaha vkushwaha-nv

#### 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 Commands

- vkCmdSetDepthBiasEnableEXT

- vkCmdSetLogicOpEXT

- vkCmdSetPatchControlPointsEXT

- vkCmdSetPrimitiveRestartEnableEXT

- vkCmdSetRasterizerDiscardEnableEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceExtendedDynamicState2FeaturesEXT

#### New Enum Constants

- `VK_EXT_EXTENDED_DYNAMIC_STATE_2_EXTENSION_NAME`

- `VK_EXT_EXTENDED_DYNAMIC_STATE_2_SPEC_VERSION`

- Extending VkDynamicState:

  - `VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_LOGIC_OP_EXT`

  - `VK_DYNAMIC_STATE_PATCH_CONTROL_POINTS_EXT`

  - `VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT`

  - `VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTENDED_DYNAMIC_STATE_2_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to `VK_KHR_global_priority` extension

Contact

  - Andres Rodriguez lostgoat

#### Other Extension Metadata

Last Modified Date

  2017-10-06

IP Status

  No known IP claims.

Contributors

  - Andres Rodriguez, Valve

  - Pierre-Loup Griffais, Valve

  - Dan Ginsburg, Valve

  - Mitch Singer, AMD

#### Description

In Vulkan, users can specify device-scope queue priorities. In some cases it may be useful to extend this concept to a system-wide scope. This extension provides a mechanism for callers to set their system-wide priority. The default queue priority is `VK_QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT`.

The driver implementation will attempt to skew hardware resource allocation in 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 Structures

- Extending VkDeviceQueueCreateInfo:

  - VkDeviceQueueGlobalPriorityCreateInfoEXT

#### New Enums

- VkQueueGlobalPriorityEXT

#### 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_EXT_global_priority` to be enabled for any device-level functionality

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to `VK_KHR_global_priority` extension

Contact

  - Yiwei Zhang zhangyiwei

#### Other Extension Metadata

Last Modified Date

  2021-03-29

IP Status

  No known IP claims.

Contributors

  - Yiwei Zhang, Google

#### Description

This device extension allows applications to query the global queue priorities supported by a queue family. It allows implementations to report which global priority levels are treated differently by the implementation, instead of silently mapping multiple requested global priority levels to the same internal priority, or using device creation failure to signal that a requested priority is not supported. It is intended primarily for use by system integration along with certain platform-specific priority enforcement rules.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceGlobalPriorityQueryFeaturesEXT

- Extending VkQueueFamilyProperties2:

  - VkQueueFamilyGlobalPriorityPropertiesEXT

#### New Enum Constants

- `VK_EXT_GLOBAL_PRIORITY_QUERY_EXTENSION_NAME`

- `VK_EXT_GLOBAL_PRIORITY_QUERY_SPEC_VERSION`

- `VK_MAX_GLOBAL_PRIORITY_SIZE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GLOBAL_PRIORITY_QUERY_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_QUEUE_FAMILY_GLOBAL_PRIORITY_PROPERTIES_EXT`

#### Issues

1) Can we additionally query whether a caller is permitted to acquire a specific global queue priority in this extension?

RESOLVED: No. Whether a caller has enough privilege goes with the OS, and the Vulkan driver cannot really guarantee that the privilege will not change in between this query and the actual queue creation call.

2) If more than 1 queue using global priority is requested, is there a good way to know which queue is failing the device creation?

RESOLVED: No. There is not a good way at this moment, and it is also not quite actionable for the applications to know that because the information may not be accurate. Queue creation can fail because of runtime constraints like insufficient privilege or lack of resource, and the failure is not necessarily tied to that particular queue configuration requested.

#### Version History

- Revision 1, 2021-03-29 (Yiwei Zhang)

#### VK_EXT_host_query_reset

Name String

  `VK_EXT_host_query_reset`

Extension Type

  Device extension

Registered Extension Number

  262

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Bas Nieuwenhuizen BNieuwenhuizen

#### Other Extension Metadata

Last Modified Date

  2019-03-06

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

Contributors

  - Bas Nieuwenhuizen, Google

  - Jason Ekstrand, Intel

  - Jeff Bolz, NVIDIA

  - Piers Daniell, NVIDIA

#### Description

This extension adds a new function to reset queries from the host.

#### Promotion to Vulkan 1.2

All functionality in this extension is included in core Vulkan 1.2, with the EXT suffix omitted. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkResetQueryPoolEXT

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceHostQueryResetFeaturesEXT

#### New Enum Constants

- `VK_EXT_HOST_QUERY_RESET_EXTENSION_NAME`

- `VK_EXT_HOST_QUERY_RESET_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_HOST_QUERY_RESET_FEATURES_EXT`

#### Version History

- Revision 1, 2019-03-12 (Bas Nieuwenhuizen)

  - Initial draft

#### VK_EXT_image_robustness

Name String

  `VK_EXT_image_robustness`

Extension Type

  Device extension

Registered Extension Number

  336

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Graeme Leese gnl21

#### 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceImageRobustnessFeaturesEXT

#### New Enum Constants

- `VK_EXT_IMAGE_ROBUSTNESS_EXTENSION_NAME`

- `VK_EXT_IMAGE_ROBUSTNESS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_ROBUSTNESS_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

  - Requires `VK_KHR_maintenance1` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Daniel Rakos aqnuep

#### 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 Structures

- Extending VkDescriptorPoolCreateInfo:

  - VkDescriptorPoolInlineUniformBlockCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceInlineUniformBlockFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceInlineUniformBlockPropertiesEXT

- Extending VkWriteDescriptorSet:

  - VkWriteDescriptorSetInlineUniformBlockEXT

#### New Enum Constants

- `VK_EXT_INLINE_UNIFORM_BLOCK_EXTENSION_NAME`

- `VK_EXT_INLINE_UNIFORM_BLOCK_SPEC_VERSION`

- Extending VkDescriptorType:

  - `VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT`

#### Promotion to Vulkan 1.3

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.

Vulkan 1.3 adds additional functionality related to this extension in the form of the `maxInlineUniformTotalSize` limit.

#### Issues

1) Do we need a new storage class for inline uniform blocks vs uniform blocks?

RESOLVED: No. The `Uniform` storage class is used to allow the same syntax used for both uniform buffers and inline uniform blocks.

2) Is the descriptor array index and array size expressed in terms of bytes or dwords for inline uniform block descriptors?

RESOLVED: In bytes, but both must be a multiple of 4, similar to how push constant ranges are specified. The `descriptorCount` of `VkDescriptorSetLayoutBinding` thus provides the total number of bytes a particular binding with an inline uniform block descriptor type can hold, while the `srcArrayElement`, `dstArrayElement`, and `descriptorCount` members of `VkWriteDescriptorSet`, `VkCopyDescriptorSet`, and `VkDescriptorUpdateTemplateEntry` (where applicable) specify the byte offset and number of bytes to write/copy to the binding’s backing store. Additionally, the `stride` member of `VkDescriptorUpdateTemplateEntry` is ignored for inline uniform blocks and a default value of one is used, meaning that the data to update inline uniform block bindings with must be contiguous in memory.

3) What layout rules apply for uniform blocks corresponding to inline constants?

RESOLVED: They use the same layout rules as uniform buffers.

4) Do we need to add non-uniform indexing features/properties as introduced by `VK_EXT_descriptor_indexing` for inline uniform blocks?

RESOLVED: No, because inline uniform blocks are not allowed to be “arrayed”. A single binding with an inline uniform block descriptor type corresponds to a single uniform block instance and the array indices inside that binding refer to individual offsets within the uniform block (see issue #2). However, this extension does introduce new features/properties about the level of support for update-after-bind inline uniform blocks.

5) Is the `descriptorBindingVariableDescriptorCount` feature introduced by `VK_EXT_descriptor_indexing` supported for inline uniform blocks?

RESOLVED: Yes, as long as other inline uniform block specific limits are respected.

6) Do the robustness guarantees of `robustBufferAccess` apply to inline uniform block accesses?

RESOLVED: No, similarly to push constants, as they are not backed by buffer memory like uniform buffers.

#### Version History

- Revision 1, 2018-08-01 (Daniel Rakos)

  - Internal revisions

#### VK_EXT_pipeline_creation_cache_control

Name String

  `VK_EXT_pipeline_creation_cache_control`

Extension Type

  Device extension

Registered Extension Number

  298

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Gregory Grebe grgrebe_amd

#### 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. The ICD will return the result `VK_PIPELINE_COMPILE_REQUIRED_EXT`. An ICD may still return a valid `VkPipeline` object by either re-using existing pre-compiled objects such as those from a pipeline cache, or derivative pipelines.

By default `vkCreate*Pipelines` calls must attempt to create all pipelines before returning. Setting `VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT` on `Vk*PipelineCreateInfo`::`flags` can be used as an escape hatch for batched pipeline creates.

Hidden locks also add to the unpredictability of the cost of pipeline creation. The most common case of locks inside the `vkCreate*Pipelines` is internal synchronization of the VkPipelineCache object. `VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT` can be set when calling vkCreatePipelineCache to state the cache is externally synchronized.

The hope is that armed with this information application and engine developers can leverage existing asset streaming systems to recover from "just-in-time" pipeline creation stalls.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePipelineCreationCacheControlFeaturesEXT

#### New Enums

- VkPipelineCacheCreateFlagBits

#### New Enum Constants

- `VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_EXTENSION_NAME`

- `VK_EXT_PIPELINE_CREATION_CACHE_CONTROL_SPEC_VERSION`

- Extending VkPipelineCacheCreateFlagBits:

  - `VK_PIPELINE_CACHE_CREATE_EXTERNALLY_SYNCHRONIZED_BIT_EXT`

- Extending VkPipelineCreateFlagBits:

  - `VK_PIPELINE_CREATE_EARLY_RETURN_ON_FAILURE_BIT_EXT`

  - `VK_PIPELINE_CREATE_FAIL_ON_PIPELINE_COMPILE_REQUIRED_BIT_EXT`

- Extending VkResult:

  - `VK_ERROR_PIPELINE_COMPILE_REQUIRED_EXT`

  - `VK_PIPELINE_COMPILE_REQUIRED_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PIPELINE_CREATION_CACHE_CONTROL_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Special Use

  - Developer tools

Contact

  - Jean-Francois Roy jfroy

#### Other Extension Metadata

Last Modified Date

  2019-03-12

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 Structures

- VkPipelineCreationFeedbackEXT

- Extending VkGraphicsPipelineCreateInfo, VkComputePipelineCreateInfo, VkRayTracingPipelineCreateInfoNV, VkRayTracingPipelineCreateInfoKHR:

  - VkPipelineCreationFeedbackCreateInfoEXT

#### New Enums

- VkPipelineCreationFeedbackFlagBitsEXT

#### New Bitmasks

- VkPipelineCreationFeedbackFlagsEXT

#### New Enum Constants

- `VK_EXT_PIPELINE_CREATION_FEEDBACK_EXTENSION_NAME`

- `VK_EXT_PIPELINE_CREATION_FEEDBACK_SPEC_VERSION`

- Extending 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Matthew Rusch mattruschnv

#### 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

- VkPrivateDataSlotEXT

#### New Commands

- vkCreatePrivateDataSlotEXT

- vkDestroyPrivateDataSlotEXT

- vkGetPrivateDataEXT

- vkSetPrivateDataEXT

#### New Structures

- VkPrivateDataSlotCreateInfoEXT

- Extending VkDeviceCreateInfo:

  - VkDevicePrivateDataCreateInfoEXT

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDevicePrivateDataFeaturesEXT

#### New Bitmasks

- VkPrivateDataSlotCreateFlagsEXT

#### New Enum Constants

- `VK_EXT_PRIVATE_DATA_EXTENSION_NAME`

- `VK_EXT_PRIVATE_DATA_SPEC_VERSION`

- Extending VkObjectType:

  - `VK_OBJECT_TYPE_PRIVATE_DATA_SLOT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEVICE_PRIVATE_DATA_CREATE_INFO_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PRIVATE_DATA_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PRIVATE_DATA_SLOT_CREATE_INFO_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Jeff Bolz jeffbolznv

#### 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 Structures

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT

- Extending VkSamplerCreateInfo:

  - VkSamplerReductionModeCreateInfoEXT

#### New Enums

- VkSamplerReductionModeEXT

#### New Enum Constants

- `VK_EXT_SAMPLER_FILTER_MINMAX_EXTENSION_NAME`

- `VK_EXT_SAMPLER_FILTER_MINMAX_SPEC_VERSION`

- Extending VkFormatFeatureFlagBits:

  - `VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT`

- Extending VkSamplerReductionMode:

  - `VK_SAMPLER_REDUCTION_MODE_MAX_EXT`

  - `VK_SAMPLER_REDUCTION_MODE_MIN_EXT`

  - `VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT`

#### Version History

- Revision 2, 2017-05-19 (Piers Daniell)

  - Renamed to EXT

- Revision 1, 2017-03-25 (Jeff Bolz)

  - Internal revisions

#### VK_EXT_scalar_block_layout

Name String

  `VK_EXT_scalar_block_layout`

Extension Type

  Device extension

Registered Extension Number

  222

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Tobias Hector tobski

#### 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

  - Jason 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceScalarBlockLayoutFeaturesEXT

#### New Enum Constants

- `VK_EXT_SCALAR_BLOCK_LAYOUT_EXTENSION_NAME`

- `VK_EXT_SCALAR_BLOCK_LAYOUT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SCALAR_BLOCK_LAYOUT_FEATURES_EXT`

#### Version History

- Revision 1, 2018-11-14 (Tobias Hector)

  - Initial draft

#### VK_EXT_separate_stencil_usage

Name String

  `VK_EXT_separate_stencil_usage`

Extension Type

  Device extension

Registered Extension Number

  247

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Daniel Rakos drakos-amd

#### 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 Structures

- Extending VkImageCreateInfo, VkPhysicalDeviceImageFormatInfo2:

  - VkImageStencilUsageCreateInfoEXT

#### New Enum Constants

- `VK_EXT_SEPARATE_STENCIL_USAGE_EXTENSION_NAME`

- `VK_EXT_SEPARATE_STENCIL_USAGE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IMAGE_STENCIL_USAGE_CREATE_INFO_EXT`

#### Version History

- Revision 1, 2018-11-08 (Daniel Rakos)

  - Internal revisions.

#### VK_EXT_shader_demote_to_helper_invocation

Name String

  `VK_EXT_shader_demote_to_helper_invocation`

Extension Type

  Device extension

Registered Extension Number

  277

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Jeff Bolz jeffbolznv

#### 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

  - This extension requires `SPV_EXT_demote_to_helper_invocation`

  - This extension provides API support for `GL_EXT_demote_to_helper_invocation`

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension adds Vulkan support for the `SPV_EXT_demote_to_helper_invocation` SPIR-V extension. That SPIR-V extension provides a new instruction `OpDemoteToHelperInvocationEXT` allowing shaders to “demote” a fragment shader invocation to behave like a helper invocation for its duration. The demoted invocation will have no further side effects and will not output to the framebuffer, but remains active and can participate in computing derivatives and in group operations. This is a better match for the “discard” instruction in HLSL.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceShaderDemoteToHelperInvocationFeaturesEXT

#### New Enum Constants

- `VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_EXTENSION_NAME`

- `VK_EXT_SHADER_DEMOTE_TO_HELPER_INVOCATION_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_DEMOTE_TO_HELPER_INVOCATION_FEATURES_EXT`

#### New SPIR-V Capability

- `DemoteToHelperInvocationEXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by Vulkan 1.2

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2016-11-28

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_shader_ballot`

  - This extension provides API support for `GL_ARB_shader_ballot`

Contributors

  - Jeff Bolz, NVIDIA

  - Neil Henning, Codeplay

  - Daniel Koch, NVIDIA Corporation

#### Description

This extension adds support for the following SPIR-V extension in Vulkan:

- `SPV_KHR_shader_ballot`

This extension provides the ability for a group of invocations, which execute in parallel, to do limited forms of cross-invocation communication via a group broadcast of 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 Built-In Variables

- `SubgroupEqMaskKHR`

- `SubgroupGeMaskKHR`

- `SubgroupGtMaskKHR`

- `SubgroupLeMaskKHR`

- `SubgroupLtMaskKHR`

- `SubgroupLocalInvocationId`

- `SubgroupSize`

#### New SPIR-V Capabilities

- `SubgroupBallotKHR`

#### Version History

- Revision 1, 2016-11-28 (Daniel Koch)

  - Initial draft

#### VK_EXT_shader_subgroup_vote

Name String

  `VK_EXT_shader_subgroup_vote`

Extension Type

  Device extension

Registered Extension Number

  66

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by Vulkan 1.1

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2016-11-28

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_KHR_subgroup_vote`

  - This extension provides API support for `GL_ARB_shader_group_vote`

Contributors

  - Neil Henning, Codeplay

  - Daniel Koch, NVIDIA Corporation

#### Description

This extension adds support for the following SPIR-V extension in Vulkan:

- `SPV_KHR_subgroup_vote`

This extension provides new SPIR-V instructions:

- `OpSubgroupAllKHR`,

- `OpSubgroupAnyKHR`, and

- `OpSubgroupAllEqualKHR`.

to compute the composite of a set of boolean conditions across a group of shader invocations that are running concurrently (a subgroup). These composite results may be used to execute shaders more efficiently on a VkPhysicalDevice.

When using GLSL source-based shader languages, the following shader functions from GL_ARB_shader_group_vote can map to these SPIR-V instructions:

- `anyInvocationARB`() → `OpSubgroupAnyKHR`,

- `allInvocationsARB`() → `OpSubgroupAllKHR`, and

- `allInvocationsEqualARB`() → `OpSubgroupAllEqualKHR`.

The subgroup across which the boolean conditions are evaluated is implementation-dependent, and this extension provides no guarantee over how individual shader invocations are assigned to subgroups. In particular, a subgroup has no necessary relationship with the compute shader local workgroup— any pair of shader invocations in a compute local workgroup may execute in different subgroups as used by these instructions.

Compute shaders operate on an explicitly specified group of threads (a local workgroup), but many implementations will also group non-compute shader invocations and execute them concurrently. When executing code like

    if (condition) {
      result = do_fast_path();
    } else {
      result = do_general_path();
    }

where `condition` diverges between invocations, an implementation might first execute `do_fast_path`() for the invocations where `condition` is true and leave the other invocations dormant. Once `do_fast_path`() returns, it might call `do_general_path`() for invocations where `condition` is `false` and leave the other invocations dormant. In this case, the shader executes both the fast and the general path and might be better off just using the general path for all invocations.

This extension provides the ability to avoid divergent execution by evaluating a condition across an entire subgroup using code like:

    if (allInvocationsARB(condition)) {
      result = do_fast_path();
    } else {
      result = do_general_path();
    }

The built-in function `allInvocationsARB`() will return the same value for all invocations in the group, so the group will either execute `do_fast_path`() or `do_general_path`(), but never both. For example, shader code might want to evaluate a complex function iteratively by starting with an approximation of the result and then refining the approximation. Some input values may require a small number of iterations to generate an accurate result (`do_fast_path`) while others require a larger number (`do_general_path`). In another example, shader code might want to evaluate a complex function (`do_general_path`) that can be greatly simplified when assuming a specific value for one of its inputs (`do_fast_path`).

#### Deprecated by Vulkan 1.1

All functionality in this extension is superseded by the core Vulkan 1.1 subgroup operations.

#### New Enum Constants

- `VK_EXT_SHADER_SUBGROUP_VOTE_EXTENSION_NAME`

- `VK_EXT_SHADER_SUBGROUP_VOTE_SPEC_VERSION`

#### New SPIR-V Capabilities

- `SubgroupVoteKHR`

#### Version History

- Revision 1, 2016-11-28 (Daniel Koch)

  - Initial draft

#### VK_EXT_shader_viewport_index_layer

Name String

  `VK_EXT_shader_viewport_index_layer`

Extension Type

  Device extension

Registered Extension Number

  163

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.2

Contact

  - Daniel Koch dgkoch

#### Other Extension Metadata

Last Modified Date

  2017-08-08

Interactions and External Dependencies

  - Promoted to Vulkan 1.2 Core

  - This extension requires `SPV_EXT_shader_viewport_index_layer`

  - This extension provides API support for `GL_ARB_shader_viewport_layer_array`, `GL_AMD_vertex_shader_layer`, `GL_AMD_vertex_shader_viewport_index`, and `GL_NV_viewport_array2`

  - This extension requires the `multiViewport` feature.

  - This extension interacts with the `tessellationShader` feature.

Contributors

  - Piers Daniell, NVIDIA

  - Jeff Bolz, NVIDIA

  - Jan-Harald Fredriksen, ARM

  - Daniel Rakos, AMD

  - Slawomir Grajeswki, Intel

#### Description

This extension adds support for the `ShaderViewportIndexLayerEXT` capability from the `SPV_EXT_shader_viewport_index_layer` extension in Vulkan.

This extension allows variables decorated with the `Layer` and `ViewportIndex` built-ins to be exported from vertex or tessellation shaders, using the `ShaderViewportIndexLayerEXT` capability.

When using GLSL source-based shading languages, the `gl_ViewportIndex` and `gl_Layer` built-in variables map to the SPIR-V `ViewportIndex` and `Layer` built-in decorations, respectively. 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

- (modified) `Layer`

- (modified) `ViewportIndex`

#### New SPIR-V Capabilities

- `ShaderViewportIndexLayerEXT`

#### Version History

- Revision 1, 2017-08-08 (Daniel Koch)

  - Internal drafts

#### VK_EXT_subgroup_size_control

Name String

  `VK_EXT_subgroup_size_control`

Extension Type

  Device extension

Registered Extension Number

  226

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.1

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Neil Henning sheredom

#### Other Extension Metadata

Last Modified Date

  2019-03-05

Interactions and External Dependencies

  - Promoted to Vulkan 1.3 Core

Contributors

  - Jeff Bolz, NVIDIA

  - Jason 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:

s=W o r k G r oup S i z e.x×W o r k G r oup S i z e. y×W o r k g r oup S i z e. z≤S ub g r oup S i z e×max C ompute W o r k g r oup S ub g r oups

Developers can also specify a new pipeline shader stage create flag that requires the implementation to have fully populated subgroups within local workgroups. This requires the workgroup size in the X dimension to be a multiple of the subgroup size.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceSubgroupSizeControlFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceSubgroupSizeControlPropertiesEXT

- Extending VkPipelineShaderStageCreateInfo:

  - VkPipelineShaderStageRequiredSubgroupSizeCreateInfoEXT

#### New Enum Constants

- `VK_EXT_SUBGROUP_SIZE_CONTROL_EXTENSION_NAME`

- `VK_EXT_SUBGROUP_SIZE_CONTROL_SPEC_VERSION`

- Extending VkPipelineShaderStageCreateFlagBits:

  - `VK_PIPELINE_SHADER_STAGE_CREATE_ALLOW_VARYING_SUBGROUP_SIZE_BIT_EXT`

  - `VK_PIPELINE_SHADER_STAGE_CREATE_REQUIRE_FULL_SUBGROUPS_BIT_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_SIZE_CONTROL_PROPERTIES_EXT`

  - `VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_REQUIRED_SUBGROUP_SIZE_CREATE_INFO_EXT`

#### Promotion to Vulkan 1.3

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-05 (Neil Henning)

  - Initial draft

- Revision 2, 2019-07-26 (Jason Ekstrand)

  - Add the missing VkPhysicalDeviceSubgroupSizeControlFeaturesEXT for querying subgroup size control features.

#### VK_EXT_texel_buffer_alignment

Name String

  `VK_EXT_texel_buffer_alignment`

Extension Type

  Device extension

Registered Extension Number

  282

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Jeff Bolz jeffbolznv

#### 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTexelBufferAlignmentFeaturesEXT

- Extending VkPhysicalDeviceProperties2:

  - VkPhysicalDeviceTexelBufferAlignmentPropertiesEXT

#### New Enum Constants

- `VK_EXT_TEXEL_BUFFER_ALIGNMENT_EXTENSION_NAME`

- `VK_EXT_TEXEL_BUFFER_ALIGNMENT_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_FEATURES_EXT`

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXEL_BUFFER_ALIGNMENT_PROPERTIES_EXT`

#### Promotion to Vulkan 1.3

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. 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceTextureCompressionASTCHDRFeaturesEXT

#### New Enum Constants

- `VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_EXTENSION_NAME`

- `VK_EXT_TEXTURE_COMPRESSION_ASTC_HDR_SPEC_VERSION`

- Extending VkFormat:

  - `VK_FORMAT_ASTC_10x10_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_10x5_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_10x6_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_10x8_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_12x10_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_12x12_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_4x4_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_5x4_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_5x5_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_6x5_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_6x6_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_8x5_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_8x6_SFLOAT_BLOCK_EXT`

  - `VK_FORMAT_ASTC_8x8_SFLOAT_BLOCK_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TEXTURE_COMPRESSION_ASTC_HDR_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Tobias Hector tobski

#### 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 Commands

- vkGetPhysicalDeviceToolPropertiesEXT

#### New Structures

- VkPhysicalDeviceToolPropertiesEXT

#### New Enums

- VkToolPurposeFlagBitsEXT

#### New Bitmasks

- VkToolPurposeFlagsEXT

#### New Enum Constants

- `VK_EXT_TOOLING_INFO_EXTENSION_NAME`

- `VK_EXT_TOOLING_INFO_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TOOL_PROPERTIES_EXT`

If VK_EXT_debug_marker is supported:

- Extending VkToolPurposeFlagBits:

  - `VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT`

If VK_EXT_debug_report is supported:

- Extending VkToolPurposeFlagBits:

  - `VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT`

If VK_EXT_debug_utils is supported:

- Extending VkToolPurposeFlagBits:

  - `VK_TOOL_PURPOSE_DEBUG_MARKERS_BIT_EXT`

  - `VK_TOOL_PURPOSE_DEBUG_REPORTING_BIT_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_EXT_validation_features` extension

Special Use

  - Debugging tools

Contact

  - Tobin Ehlis tobine

#### Other Extension Metadata

Last Modified Date

  2019-08-19

IP Status

  No known IP claims.

Contributors

  - Tobin Ehlis, Google

  - Courtney Goeltzenleuchter, Google

#### Description

This extension provides the VkValidationFlagsEXT 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

- Extending VkInstanceCreateInfo:

  - VkValidationFlagsEXT

#### New Enums

- VkValidationCheckEXT

#### New Enum Constants

- `VK_EXT_VALIDATION_FLAGS_EXTENSION_NAME`

- `VK_EXT_VALIDATION_FLAGS_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT`

#### Version History

- Revision 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_sampler_ycbcr_conversion` to be enabled for any device-level functionality

Deprecation state

  - Promoted to Vulkan 1.3

Contact

  - Tony Zlatinski tzlatinski

#### 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 Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceYcbcr2Plane444FormatsFeaturesEXT

#### New Enum Constants

- `VK_EXT_YCBCR_2PLANE_444_FORMATS_EXTENSION_NAME`

- `VK_EXT_YCBCR_2PLANE_444_FORMATS_SPEC_VERSION`

- Extending VkFormat:

  - `VK_FORMAT_G10X6_B10X6R10X6_2PLANE_444_UNORM_3PACK16_EXT`

  - `VK_FORMAT_G12X4_B12X4R12X4_2PLANE_444_UNORM_3PACK16_EXT`

  - `VK_FORMAT_G16_B16R16_2PLANE_444_UNORM_EXT`

  - `VK_FORMAT_G8_B8R8_2PLANE_444_UNORM_EXT`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_2_PLANE_444_FORMATS_FEATURES_EXT`

#### Promotion to Vulkan 1.3

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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Promoted to `VK_KHR_draw_indirect_count` extension

    - Which in turn was promoted to Vulkan 1.2

Contact

  - Daniel Rakos drakos-amd

#### Other Extension Metadata

Last Modified Date

  2016-08-23

Interactions and External Dependencies

  - Promoted to `VK_KHR_draw_indirect_count`

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Derrick Owens, AMD

  - Graham Sellers, AMD

  - Daniel Rakos, AMD

  - Dominik Witczak, AMD

#### Description

This extension allows an application to source the number of draws for indirect drawing commands from a buffer. This enables applications to generate an arbitrary number of drawing commands and execute them without host intervention.

#### Promotion to `VK_KHR_draw_indirect_count`

All functionality in this extension is included in `VK_KHR_draw_indirect_count`, with the suffix changed to KHR. The original type, enum and command names are still available as aliases of the core functionality.

#### New Commands

- vkCmdDrawIndexedIndirectCountAMD

- vkCmdDrawIndirectCountAMD

#### New Enum Constants

- `VK_AMD_DRAW_INDIRECT_COUNT_EXTENSION_NAME`

- `VK_AMD_DRAW_INDIRECT_COUNT_SPEC_VERSION`

#### Version History

- Revision 2, 2016-08-23 (Dominik Witczak)

  - Minor fixes

- Revision 1, 2016-07-21 (Matthaeus Chajdas)

  - Initial draft

#### VK_AMD_gpu_shader_half_float

Name String

  `VK_AMD_gpu_shader_half_float`

Extension Type

  Device extension

Registered Extension Number

  37

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_KHR_shader_float16_int8` extension

    - Which in turn was promoted to Vulkan 1.2

Contact

  - Dominik Witczak dominikwitczakamd

#### Other Extension Metadata

Last Modified Date

  2019-04-11

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_gpu_shader_half_float`

  - This extension provides API support for `GL_AMD_gpu_shader_half_float`

Contributors

  - Daniel Rakos, AMD

  - Dominik Witczak, AMD

  - Donglin Wei, AMD

  - Graham Sellers, AMD

  - Qun Lin, AMD

  - Rex Xu, AMD

#### Description

This extension adds support for using half float variables in shaders.

#### Deprecation by `VK_KHR_shader_float16_int8`

Functionality in this extension 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_KHR_shader_float16_int8` extension

    - Which in turn was promoted to Vulkan 1.2

Contact

  - Qun Lin linqun

#### Other Extension Metadata

Last Modified Date

  2019-04-11

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_AMD_gpu_shader_int16`

  - This extension provides API support for `GL_AMD_gpu_shader_int16`

Contributors

  - Daniel Rakos, AMD

  - Dominik Witczak, AMD

  - Matthaeus G. Chajdas, AMD

  - Rex Xu, AMD

  - Timothy Lottes, AMD

  - Zhi Cai, AMD

#### Description

This extension adds support for using 16-bit integer variables in shaders.

#### Deprecation by `VK_KHR_shader_float16_int8`

Functionality in this extension 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Obsoleted by `VK_KHR_maintenance1` extension

    - Which in turn was promoted to Vulkan 1.1

Contact

  - Matthaeus G. Chajdas anteru

#### Other Extension Metadata

Last Modified Date

  2016-09-02

IP Status

  No known IP claims.

Contributors

  - Matthaeus G. Chajdas, AMD

  - Graham Sellers, AMD

  - Baldur Karlsson

#### Description

This extension allows an application to specify a negative viewport height. The result is that the viewport transformation will flip along the y-axis.

- Allow negative height to be specified in the VkViewport::`height` field to perform y-inversion of the clip-space to framebuffer-space transform. This allows apps to avoid having to use `gl_Position.y = -gl_Position.y` in shaders also targeting other APIs.

#### Obsoletion by `VK_KHR_maintenance1` and Vulkan 1.1

Functionality in this extension is included in `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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to `VK_EXT_rasterization_order_attachment_access` extension

Contact

  - Jan-Harald Fredriksen janharaldfredriksen-arm

#### Other Extension Metadata

Last Modified Date

  2021-11-12

IP Status

  No known IP claims.

Contributors

  - Tobias Hector, AMD

  - Jan-Harald Fredriksen, Arm

#### Description

Renderpasses, and specifically subpass self-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.

See renderpass feedback loops for more information.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceRasterizationOrderAttachmentAccessFeaturesARM

#### New Enum Constants

- `VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_EXTENSION_NAME`

- `VK_ARM_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_SPEC_VERSION`

- Extending VkPipelineColorBlendStateCreateFlagBits:

  - `VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_ARM`

- Extending VkPipelineDepthStencilStateCreateFlagBits:

  - `VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM`

  - `VK_PIPELINE_DEPTH_STENCIL_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_FEATURES_ARM`

- Extending VkSubpassDescriptionFlagBits:

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_COLOR_ACCESS_BIT_ARM`

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_DEPTH_ACCESS_BIT_ARM`

  - `VK_SUBPASS_DESCRIPTION_RASTERIZATION_ORDER_ATTACHMENT_STENCIL_ACCESS_BIT_ARM`

#### Issues

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_MVK_ios_surface

Name String

  `VK_MVK_ios_surface`

Extension Type

  Instance extension

Registered Extension Number

  123

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Deprecation state

  - Deprecated by `VK_EXT_metal_surface` extension

Contact

  - Bill Hollings billhollings

#### Other Extension Metadata

Last Modified Date

  2020-07-31

IP Status

  No known IP claims.

Contributors

  - Bill Hollings, The Brenwill Workshop Ltd.

#### Description

The `VK_MVK_ios_surface` extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the `VK_KHR_surface` extension) based on a `UIView`, the native surface type of iOS, which is underpinned by a `CAMetalLayer`, to support rendering to the surface using Apple’s Metal framework.

#### Deprecation by `VK_EXT_metal_surface`

The `VK_MVK_ios_surface` extension is considered deprecated and has been superseded by the `VK_EXT_metal_surface` extension.

#### New Commands

- vkCreateIOSSurfaceMVK

#### New Structures

- VkIOSSurfaceCreateInfoMVK

#### New Bitmasks

- VkIOSSurfaceCreateFlagsMVK

#### New Enum Constants

- `VK_MVK_IOS_SURFACE_EXTENSION_NAME`

- `VK_MVK_IOS_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_IOS_SURFACE_CREATE_INFO_MVK`

#### Version History

- Revision 1, 2017-02-15 (Bill Hollings)

  - Initial draft.

- Revision 2, 2017-02-24 (Bill Hollings)

  - Minor syntax fix to emphasize firm requirement for `UIView` to be backed by a `CAMetalLayer`.

- Revision 3, 2020-07-31 (Bill Hollings)

  - Update documentation on requirements for `UIView`.

  - Mark as deprecated by `VK_EXT_metal_surface`.

#### VK_MVK_macos_surface

Name String

  `VK_MVK_macos_surface`

Extension Type

  Instance extension

Registered Extension Number

  124

Revision

  3

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_surface` to be enabled

Deprecation state

  - Deprecated by `VK_EXT_metal_surface` extension

Contact

  - Bill Hollings billhollings

#### Other Extension Metadata

Last Modified Date

  2020-07-31

IP Status

  No known IP claims.

Contributors

  - Bill Hollings, The Brenwill Workshop Ltd.

#### Description

The `VK_MVK_macos_surface` extension is an instance extension. It provides a mechanism to create a VkSurfaceKHR object (defined by the `VK_KHR_surface` extension) based on an `NSView`, the native surface type of macOS, which is underpinned by a `CAMetalLayer`, to support rendering to the surface using Apple’s Metal framework.

#### Deprecation by `VK_EXT_metal_surface`

The `VK_MVK_macos_surface` extension is considered deprecated and has been superseded by the `VK_EXT_metal_surface` extension.

#### New Commands

- vkCreateMacOSSurfaceMVK

#### New Structures

- VkMacOSSurfaceCreateInfoMVK

#### New Bitmasks

- VkMacOSSurfaceCreateFlagsMVK

#### New Enum Constants

- `VK_MVK_MACOS_SURFACE_EXTENSION_NAME`

- `VK_MVK_MACOS_SURFACE_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_MACOS_SURFACE_CREATE_INFO_MVK`

#### Version History

- Revision 1, 2017-02-15 (Bill Hollings)

  - Initial draft.

- Revision 2, 2017-02-24 (Bill Hollings)

  - Minor syntax fix to emphasize firm requirement for `NSView` to be backed by a `CAMetalLayer`.

- Revision 3, 2020-07-31 (Bill Hollings)

  - Update documentation on requirements for `NSView`.

  - Mark as deprecated by `VK_EXT_metal_surface`.

#### VK_NV_dedicated_allocation

Name String

  `VK_NV_dedicated_allocation`

Extension Type

  Device extension

Registered Extension Number

  27

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_KHR_dedicated_allocation` extension

    - Which in turn was promoted to Vulkan 1.1

Contact

  - Jeff Bolz jeffbolznv

#### Other Extension Metadata

Last Modified Date

  2016-05-31

IP Status

  No known IP claims.

Contributors

  - Jeff Bolz, NVIDIA

#### Description

This extension allows device memory to be allocated for a particular buffer or image resource, which on some devices can significantly improve the performance of that resource. Normal device memory allocations must support memory aliasing and sparse binding, which could interfere with optimizations like framebuffer compression or efficient page table usage. This is important for render targets and very large resources, but need not (and probably should not) be used for smaller resources that can benefit from suballocation.

This extension adds a few small structures to resource creation and memory allocation: a new structure that flags whether am image/buffer will have a dedicated allocation, and a structure indicating the image or buffer that an allocation will be bound to.

#### New Structures

- Extending VkBufferCreateInfo:

  - VkDedicatedAllocationBufferCreateInfoNV

- Extending VkImageCreateInfo:

  - VkDedicatedAllocationImageCreateInfoNV

- Extending VkMemoryAllocateInfo:

  - VkDedicatedAllocationMemoryAllocateInfoNV

#### New Enum Constants

- `VK_NV_DEDICATED_ALLOCATION_EXTENSION_NAME`

- `VK_NV_DEDICATED_ALLOCATION_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_BUFFER_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV`

#### Examples

        // Create an image with
        // VkDedicatedAllocationImageCreateInfoNV::dedicatedAllocation
        // set to VK_TRUE

        VkDedicatedAllocationImageCreateInfoNV dedicatedImageInfo =
        {
            VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV,            // sType
            NULL,                                                                   // pNext
            VK_TRUE,                                                                // dedicatedAllocation
        };

        VkImageCreateInfo imageCreateInfo =
        {
            VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,    // sType
            &dedicatedImageInfo                     // pNext
            // 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 =
        {
            VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV,             // sType
            NULL,                                                                       // pNext
            image,                                                                      // image
            VK_NULL_HANDLE,                                                             // buffer
        };

        VkMemoryAllocateInfo memoryAllocateInfo =
        {
            VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,                 // sType
            &dedicatedInfo,                                         // pNext
            memoryRequirements.size,                                // allocationSize
            FindMemoryTypeIndex(memoryRequirements.memoryTypeBits), // memoryTypeIndex
        };

        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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_NV_external_memory_capabilities` to be enabled for any device-level functionality

Deprecation state

  - Deprecated by `VK_KHR_external_memory` extension

    - Which in turn was promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-08-19

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

Applications may wish to export memory to other Vulkan instances or other APIs, or import memory from other Vulkan instances or other APIs to enable Vulkan workloads to be split up across application module, process, or API boundaries. This extension enables applications to create exportable Vulkan memory objects such that the underlying resources can be referenced outside the Vulkan instance that created them.

#### New Structures

- Extending VkImageCreateInfo:

  - VkExternalMemoryImageCreateInfoNV

- Extending VkMemoryAllocateInfo:

  - VkExportMemoryAllocateInfoNV

#### New Enum Constants

- `VK_NV_EXTERNAL_MEMORY_EXTENSION_NAME`

- `VK_NV_EXTERNAL_MEMORY_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV`

  - `VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV`

#### Issues

1) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes, but strict exceptions to the rules are added to allow some forms of aliasing in these cases. Further, other extensions may build upon these new aliasing rules to define specific support usage within Vulkan for imported native memory objects, or memory objects from other APIs.

2) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: No. Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan compatible (a term to be defined by subsequent interopability extensions), or Vulkan incompatible. When sharing images with Vulkan incompatible APIs, the Vulkan image must be transitioned to the `VK_IMAGE_LAYOUT_GENERAL` layout before handing it off to the external API.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

#### Examples

        // TODO: Write some sample code here.

#### Version History

- Revision 1, 2016-08-19 (James Jones)

  - Initial draft

#### VK_NV_external_memory_capabilities

Name String

  `VK_NV_external_memory_capabilities`

Extension Type

  Instance extension

Registered Extension Number

  56

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated by `VK_KHR_external_memory_capabilities` extension

    - Which in turn was promoted to Vulkan 1.1

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-08-19

IP Status

  No known IP claims.

Interactions and External Dependencies

  - Interacts with Vulkan 1.1.

  - Interacts with `VK_KHR_dedicated_allocation`.

  - Interacts with `VK_NV_dedicated_allocation`.

Contributors

  - James Jones, NVIDIA

#### Description

Applications may wish to import memory from the Direct 3D API, or export memory to other Vulkan instances. This extension provides a set of capability queries that allow applications determine what types of win32 memory handles an implementation supports for a given set of use cases.

#### New Commands

- vkGetPhysicalDeviceExternalImageFormatPropertiesNV

#### New Structures

- VkExternalImageFormatPropertiesNV

#### New Enums

- VkExternalMemoryFeatureFlagBitsNV

- VkExternalMemoryHandleTypeFlagBitsNV

#### New Bitmasks

- VkExternalMemoryFeatureFlagsNV

- VkExternalMemoryHandleTypeFlagsNV

#### New Enum Constants

- `VK_NV_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME`

- `VK_NV_EXTERNAL_MEMORY_CAPABILITIES_SPEC_VERSION`

#### Issues

1) Why do so many external memory capabilities need to be queried on a per-memory-handle-type basis?

RESOLVED: This is because some handle types are based on OS-native objects that have far more limited capabilities than the very generic Vulkan memory objects. Not all memory handle types can name memory objects that support 3D images, for example. Some handle types cannot even support the deferred image and memory binding behavior of Vulkan and require specifying the image when allocating or importing the memory object.

2) Does the VkExternalImageFormatPropertiesNV 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

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_NV_external_memory` to be enabled for any device-level functionality

Deprecation state

  - Deprecated by `VK_KHR_external_memory_win32` extension

Contact

  - James Jones cubanismo

#### Other Extension Metadata

Last Modified Date

  2016-08-19

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

Applications may wish to export memory to other Vulkan instances or other APIs, or import memory from other Vulkan instances or other APIs to enable Vulkan workloads to be split up across application module, process, or API boundaries. This extension enables win32 applications to export win32 handles from Vulkan memory objects such that the underlying resources can be referenced outside the Vulkan instance that created them, and import win32 handles created in the Direct3D API to Vulkan memory objects.

#### New Commands

- vkGetMemoryWin32HandleNV

#### New Structures

- Extending VkMemoryAllocateInfo:

  - VkExportMemoryWin32HandleInfoNV

  - VkImportMemoryWin32HandleInfoNV

#### New Enum Constants

- `VK_NV_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME`

- `VK_NV_EXTERNAL_MEMORY_WIN32_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV`

  - `VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_NV`

#### Issues

1) If memory objects are shared between processes and APIs, is this considered aliasing according to the rules outlined in the Memory Aliasing section?

RESOLVED: Yes, but strict exceptions to the rules are added to allow some forms of aliasing in these cases. Further, other extensions may build upon these new aliasing rules to define specific support usage within Vulkan for imported native memory objects, or memory objects from other APIs.

2) Are new image layouts or metadata required to specify image layouts and layout transitions compatible with non-Vulkan APIs, or with other instances of the same Vulkan driver?

RESOLVED: No. Separate instances of the same Vulkan driver running on the same GPU should have identical internal layout semantics, so applications have the tools they need to ensure views of images are consistent between the two instances. Other APIs will fall into two categories: Those that are Vulkan compatible (a term to be defined by subsequent interopability extensions), or Vulkan incompatible. When sharing images with Vulkan incompatible APIs, the Vulkan image must be transitioned to the `VK_IMAGE_LAYOUT_GENERAL` layout before handing it off to the external API.

Note this does not attempt to address cross-device transitions, nor transitions to engines on the same device which are not visible within the Vulkan API. Both of these are beyond the scope of this extension.

3) Do applications need to call `CloseHandle`() on the values returned from vkGetMemoryWin32HandleNV when `handleType` is `VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV`?

RESOLVED: Yes, unless it is passed back in to another driver instance to import the object. A successful get call transfers ownership of the handle to the application, while an import transfers ownership to the associated driver. Destroying the memory object will not destroy the handle or the handle’s reference to the underlying memory resource.

#### Examples

        //
        // Create an exportable memory object and export an external
        // handle from it.
        //

        // Pick an external format and handle type.
        static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
        static const VkExternalMemoryHandleTypeFlagsNV handleType =
            VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_BIT_NV;

        extern VkPhysicalDevice physicalDevice;
        extern VkDevice device;

        VkPhysicalDeviceMemoryProperties memoryProperties;
        VkExternalImageFormatPropertiesNV properties;
        VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
        VkDedicatedAllocationImageCreateInfoNV dedicatedImageCreateInfo;
        VkImageCreateInfo imageCreateInfo;
        VkImage image;
        VkMemoryRequirements imageMemoryRequirements;
        uint32_t numMemoryTypes;
        uint32_t memoryType;
        VkExportMemoryAllocateInfoNV exportMemoryAllocateInfo;
        VkDedicatedAllocationMemoryAllocateInfoNV dedicatedAllocationInfo;
        VkMemoryAllocateInfo memoryAllocateInfo;
        VkDeviceMemory memory;
        VkResult result;
        HANDLE memoryHnd;

        // Figure out how many memory types the device supports
        vkGetPhysicalDeviceMemoryProperties(physicalDevice,
                                            &memoryProperties);
        numMemoryTypes = memoryProperties.memoryTypeCount;

        // Check the external handle type capabilities for the chosen format
        // Exportable 2D image support with at least 1 mip level, 1 array
        // layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
        // texturing and color rendering is required.
        result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
            physicalDevice,
            format,
            VK_IMAGE_TYPE_2D,
            VK_IMAGE_TILING_OPTIMAL,
            VK_IMAGE_USAGE_SAMPLED_BIT |
            VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
            0,
            handleType,
            &properties);

        if ((result != VK_SUCCESS) ||
            !(properties.externalMemoryFeatures &
              VK_EXTERNAL_MEMORY_FEATURE_EXPORTABLE_BIT_NV)) {
            abort();
        }

        // Set up the external memory image creation info
        memset(&externalMemoryImageCreateInfo,
               0, sizeof(externalMemoryImageCreateInfo));
        externalMemoryImageCreateInfo.sType =
            VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
        externalMemoryImageCreateInfo.handleTypes = handleType;
        if (properties.externalMemoryFeatures &
            VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
            memset(&dedicatedImageCreateInfo, 0, sizeof(dedicatedImageCreateInfo));
            dedicatedImageCreateInfo.sType =
                VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_IMAGE_CREATE_INFO_NV;
            dedicatedImageCreateInfo.dedicatedAllocation = VK_TRUE;
            externalMemoryImageCreateInfo.pNext = &dedicatedImageCreateInfo;
        }
        // Set up the  core image creation info
        memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
        imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
        imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
        imageCreateInfo.format = format;
        imageCreateInfo.extent.width = 64;
        imageCreateInfo.extent.height = 64;
        imageCreateInfo.extent.depth = 1;
        imageCreateInfo.mipLevels = 1;
        imageCreateInfo.arrayLayers = 1;
        imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
        imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
        imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
            VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
        imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
        imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

        vkCreateImage(device, &imageCreateInfo, NULL, &image);

        vkGetImageMemoryRequirements(device,
                                     image,
                                     &imageMemoryRequirements);

        // For simplicity, just pick the first compatible memory type.
        for (memoryType = 0; memoryType < numMemoryTypes; memoryType++) {
            if ((1 << memoryType) & imageMemoryRequirements.memoryTypeBits) {
                break;
            }
        }

        // At least one memory type must be supported given the prior external
        // handle capability check.
        assert(memoryType < numMemoryTypes);

        // Allocate the external memory object.
        memset(&exportMemoryAllocateInfo, 0, sizeof(exportMemoryAllocateInfo));
        exportMemoryAllocateInfo.sType =
            VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV;
        exportMemoryAllocateInfo.handleTypes = handleType;
        if (properties.externalMemoryFeatures &
            VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV) {
            memset(&dedicatedAllocationInfo, 0, sizeof(dedicatedAllocationInfo));
            dedicatedAllocationInfo.sType =
                VK_STRUCTURE_TYPE_DEDICATED_ALLOCATION_MEMORY_ALLOCATE_INFO_NV;
            dedicatedAllocationInfo.image = image;
            exportMemoryAllocateInfo.pNext = &dedicatedAllocationInfo;
        }
        memset(&memoryAllocateInfo, 0, sizeof(memoryAllocateInfo));
        memoryAllocateInfo.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO;
        memoryAllocateInfo.pNext = &exportMemoryAllocateInfo;
        memoryAllocateInfo.allocationSize = imageMemoryRequirements.size;
        memoryAllocateInfo.memoryTypeIndex = memoryType;

        vkAllocateMemory(device, &memoryAllocateInfo, NULL, &memory);

        if (!(properties.externalMemoryFeatures &
              VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT_NV)) {
            vkBindImageMemory(device, image, memory, 0);
        }

        // Get the external memory opaque FD handle
        vkGetMemoryWin32HandleNV(device, memory, &memoryHnd);

#### Version History

- Revision 1, 2016-08-11 (James Jones)

  - Initial draft

#### VK_NV_fragment_shader_barycentric

Name String

  `VK_NV_fragment_shader_barycentric`

Extension Type

  Device extension

Registered Extension Number

  204

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_KHR_get_physical_device_properties2` to be enabled for any device-level functionality

Deprecation state

  - Promoted to `VK_KHR_fragment_shader_barycentric` extension

Contact

  - Pat Brown nvpbrown

#### Other Extension Metadata

Last Modified Date

  2018-08-03

IP Status

  No known IP claims.

Interactions and External Dependencies

  - This extension requires `SPV_NV_fragment_shader_barycentric`

  - This extension provides API support for `GL_NV_fragment_shader_barycentric`

Contributors

  - Pat Brown, NVIDIA

  - Daniel Koch, NVIDIA

#### Description

This extension adds support for the following SPIR-V extension in Vulkan:

- `SPV_NV_fragment_shader_barycentric`

The extension provides access to three additional fragment shader variable decorations in SPIR-V:

- `PerVertexNV`, which indicates that a fragment shader input will not have interpolated values, but instead must be accessed with an extra array index that identifies one of the vertices of the primitive producing the fragment

- `BaryCoordNV`, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using perspective interpolation

- `BaryCoordNoPerspNV`, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using linear interpolation

When using GLSL source-based shader languages, the following variables from `GL_NV_fragment_shader_barycentric` maps to these SPIR-V built-in decorations:

- `in vec3 gl_BaryCoordNV;` → `BaryCoordNV`

- `in vec3 gl_BaryCoordNoPerspNV;` → `BaryCoordNoPerspNV`

GLSL variables declared using the `__pervertexNV` GLSL qualifier are expected to be decorated with `PerVertexNV` in SPIR-V.

#### Promotion to `VK_KHR_fragment_shader_barycentric`

All functionality in this extension is included in `VK_KHR_fragment_shader_barycentric`, with the suffix changed to KHR.

#### New Structures

- Extending VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShaderBarycentricFeaturesNV

#### New Enum Constants

- `VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME`

- `VK_NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV`

#### New Built-In Variables

- `BaryCoordNV`

- `BaryCoordNoPerspNV`

#### New SPIR-V Decorations

- `PerVertexNV`

#### New SPIR-V Capabilities

- `FragmentBarycentricNV`

#### Issues

(1) The AMD_shader_explicit_vertex_parameter extension provides similar functionality. Why write a new extension, and how is this extension different?

RESOLVED: For the purposes of Vulkan/SPIR-V, we chose to implement a separate extension due to several functional differences.

First, the hardware supporting this extension can provide a three-component barycentric weight vector for variables decorated with `BaryCoordNV`, while variables decorated with `BaryCoordSmoothAMD` provide only two components. In some cases, it may be more efficient to explicitly interpolate an attribute via:

    float value = (baryCoordNV.x * v[0].attrib +
                   baryCoordNV.y * v[1].attrib +
                   baryCoordNV.z * v[2].attrib);

instead of

    float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
                   baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
                   v[2].attrib);

Additionally, the semantics of the decoration `BaryCoordPullModelAMD` do not appear to map to anything supported by the initial hardware implementation of this extension.

This extension provides a smaller number of decorations than the AMD extension, as we expect that shaders could derive variables decorated with things like `BaryCoordNoPerspCentroidAMD` with explicit attribute interpolation instructions. One other relevant difference is that explicit per-vertex attribute access using this extension does not require a constant vertex number.

(2) Why do the built-in SPIR-V decorations for this extension include two separate built-ins `BaryCoordNV` and `BaryCoordNoPerspNV` when a “no perspective” variable could be decorated with `BaryCoordNV` and `NoPerspective`?

RESOLVED: The SPIR-V extension for this feature chose to mirror the behavior of the GLSL extension, which provides two built-in variables. Additionally, it is not clear that its a good idea (or even legal) to have two variables using the “same attribute”, but with different interpolation modifiers.

#### Version History

- Revision 1, 2018-08-03 (Pat Brown)

  - Internal revisions

#### VK_NV_glsl_shader

Name String

  `VK_NV_glsl_shader`

Extension Type

  Device extension

Registered Extension Number

  13

Revision

  1

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

Deprecation state

  - Deprecated without replacement

Contact

  - Piers Daniell pdaniell-nv

#### Other Extension Metadata

Last Modified Date

  2016-02-14

IP Status

  No known IP claims.

Contributors

  - Piers Daniell, NVIDIA

#### Description

This extension allows GLSL shaders written to the `GL_KHR_vulkan_glsl` extension specification to be used instead of SPIR-V. The implementation will automatically detect whether the shader is SPIR-V or GLSL, and compile it appropriately.

#### Deprecation

Functionality in this extension is outside of the scope of Vulkan and is better served by a compiler library such as glslang. No new implementations will support this extension, so applications should not use it.

#### New Enum Constants

- `VK_NV_GLSL_SHADER_EXTENSION_NAME`

- `VK_NV_GLSL_SHADER_SPEC_VERSION`

- Extending VkResult:

  - `VK_ERROR_INVALID_SHADER_NV`

#### Examples

Example 1

Passing in GLSL code

        char const vss[] =
            "#version 450 core\n"
            "layout(location = 0) in vec2 aVertex;\n"
            "layout(location = 1) in vec4 aColor;\n"
            "out vec4 vColor;\n"
            "void main()\n"
            "{\n"
            "    vColor = aColor;\n"
            "    gl_Position = vec4(aVertex, 0, 1);\n"
            "}\n"
        ;
        VkShaderModuleCreateInfo vertexShaderInfo = { VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO };
        vertexShaderInfo.codeSize = sizeof vss;
        vertexShaderInfo.pCode = vss;
        VkShaderModule vertexShader;
        vkCreateShaderModule(device, &vertexShaderInfo, 0, &vertexShader);

#### Version History

- Revision 1, 2016-02-14 (Piers Daniell)

  - Initial draft

#### VK_NV_win32_keyed_mutex

Name String

  `VK_NV_win32_keyed_mutex`

Extension Type

  Device extension

Registered Extension Number

  59

Revision

  2

Extension and Version Dependencies

  - Requires support for Vulkan 1.0

  - Requires `VK_NV_external_memory_win32` to be enabled for any device-level functionality

Deprecation state

  - Promoted to `VK_KHR_win32_keyed_mutex` extension

Contact

  - Carsten Rohde crohde

#### Other Extension Metadata

Last Modified Date

  2016-08-19

IP Status

  No known IP claims.

Contributors

  - James Jones, NVIDIA

  - Carsten Rohde, NVIDIA

#### Description

Applications that wish to import Direct3D 11 memory objects into the Vulkan API may wish to use the native keyed mutex mechanism to synchronize access to the memory between Vulkan and Direct3D. This extension provides a way for an application to access the keyed mutex associated with an imported Vulkan memory object when submitting command buffers to a queue.

#### New Structures

- Extending VkSubmitInfo, VkSubmitInfo2:

  - VkWin32KeyedMutexAcquireReleaseInfoNV

#### New Enum Constants

- `VK_NV_WIN32_KEYED_MUTEX_EXTENSION_NAME`

- `VK_NV_WIN32_KEYED_MUTEX_SPEC_VERSION`

- Extending VkStructureType:

  - `VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV`

#### Examples

        //
        // Import a memory object from Direct3D 11, and synchronize
        // access to it in Vulkan using keyed mutex objects.
        //

        extern VkPhysicalDevice physicalDevice;
        extern VkDevice device;
        extern HANDLE sharedNtHandle;

        static const VkFormat format = VK_FORMAT_R8G8B8A8_UNORM;
        static const VkExternalMemoryHandleTypeFlagsNV handleType =
            VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_IMAGE_BIT_NV;

        VkPhysicalDeviceMemoryProperties memoryProperties;
        VkExternalImageFormatPropertiesNV properties;
        VkExternalMemoryImageCreateInfoNV externalMemoryImageCreateInfo;
        VkImageCreateInfo imageCreateInfo;
        VkImage image;
        VkMemoryRequirements imageMemoryRequirements;
        uint32_t numMemoryTypes;
        uint32_t memoryType;
        VkImportMemoryWin32HandleInfoNV importMemoryInfo;
        VkMemoryAllocateInfo memoryAllocateInfo;
        VkDeviceMemory mem;
        VkResult result;

        // Figure out how many memory types the device supports
        vkGetPhysicalDeviceMemoryProperties(physicalDevice,
                                            &memoryProperties);
        numMemoryTypes = memoryProperties.memoryTypeCount;

        // Check the external handle type capabilities for the chosen format
        // Importable 2D image support with at least 1 mip level, 1 array
        // layer, and VK_SAMPLE_COUNT_1_BIT using optimal tiling and supporting
        // texturing and color rendering is required.
        result = vkGetPhysicalDeviceExternalImageFormatPropertiesNV(
            physicalDevice,
            format,
            VK_IMAGE_TYPE_2D,
            VK_IMAGE_TILING_OPTIMAL,
            VK_IMAGE_USAGE_SAMPLED_BIT |
            VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT,
            0,
            handleType,
            &properties);

        if ((result != VK_SUCCESS) ||
            !(properties.externalMemoryFeatures &
              VK_EXTERNAL_MEMORY_FEATURE_IMPORTABLE_BIT_NV)) {
            abort();
        }

        // Set up the external memory image creation info
        memset(&externalMemoryImageCreateInfo,
               0, sizeof(externalMemoryImageCreateInfo));
        externalMemoryImageCreateInfo.sType =
            VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV;
        externalMemoryImageCreateInfo.handleTypes = handleType;
        // Set up the  core image creation info
        memset(&imageCreateInfo, 0, sizeof(imageCreateInfo));
        imageCreateInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
        imageCreateInfo.pNext = &externalMemoryImageCreateInfo;
        imageCreateInfo.format = format;
        imageCreateInfo.extent.width = 64;
        imageCreateInfo.extent.height = 64;
        imageCreateInfo.extent.depth = 1;
        imageCreateInfo.mipLevels = 1;
        imageCreateInfo.arrayLayers = 1;
        imageCreateInfo.samples = VK_SAMPLE_COUNT_1_BIT;
        imageCreateInfo.tiling = VK_IMAGE_TILING_OPTIMAL;
        imageCreateInfo.usage = VK_IMAGE_USAGE_SAMPLED_BIT |
            VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT;
        imageCreateInfo.sharingMode = VK_SHARING_MODE_EXCLUSIVE;
        imageCreateInfo.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;

        vkCreateImage(device, &imageCreateInfo, NULL, &image);
        vkGetImageMemoryRequirements(device,
                                     image,
                                     &imageMemoryRequirements);

        // 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.