Change log for January 24, 2025 Vulkan 1.4.306 spec update:

Github Issues * Refactor binary blob text to consistently specify how structures are written to the blob (based on public PR 2477). Internal Issues * Update common draw and draw vertex binding VUs to allow graphics pipelines to ignore tessellation / geometry dynamic state if not using that stage (internal issue 3982) * Clarify in vkUpdateDescriptorSets that descriptors are just a bag of bits until they are dereferenced (internal issue 4125) * Use correct xref for the term "`multi-planar`" (internal issue 4144) * Remove VU 06323 from runtime SPIR-V VUs (internal issue 4147) * Clarify that the <<sparsememory, initial state of sparse resources>> is unbound (internal MR 7123). * Move mesh shader VUs 08694 and 08695 from common draw validity to common draw mesh validity, so they only affect mesh-drawing commands (internal MR 7126). * Fix typo in VU 01708 (internal MR 7139). New Extensions * VK_EXT_external_memory_metal * VK_KHR_video_maintenance2
KhronosGroup · Jan 24, 2025 · faf3ba5 · faf3ba5
1 parent 25ec2b7
commit faf3ba5
Show file tree

Hide file tree

Showing 40 changed files with 1,189 additions and 319 deletions.
diff --git a/ChangeLog.adoc b/ChangeLog.adoc
@@ -14,6 +14,36 @@ appears frequently in the change log.
 
 '''
 
+Change log for January 24, 2025 Vulkan 1.4.306 spec update:
+
+Github Issues
+
+  * Refactor binary blob text to consistently specify how structures are
+    written to the blob (based on public PR 2477).
+
+Internal Issues
+
+  * Update common draw and draw vertex binding VUs to allow graphics
+    pipelines to ignore tessellation / geometry dynamic state if not using
+    that stage (internal issue 3982)
+  * Clarify in vkUpdateDescriptorSets that descriptors are just a bag of
+    bits until they are dereferenced (internal issue 4125)
+  * Use correct xref for the term "`multi-planar`" (internal issue 4144)
+  * Remove VU 06323 from runtime SPIR-V VUs (internal issue 4147)
+  * Clarify that the <<sparsememory, initial state of sparse resources>> is
+    unbound (internal MR 7123).
+  * Move mesh shader VUs 08694 and 08695 from common draw validity to common
+    draw mesh validity, so they only affect mesh-drawing commands (internal
+    MR 7126).
+  * Fix typo in VU 01708 (internal MR 7139).
+
+New Extensions
+
+  * VK_EXT_external_memory_metal
+  * VK_KHR_video_maintenance2
+
+'''
+
 Change log for January 17, 2025 Vulkan 1.4.305 spec update:
 
 Github Issues

diff --git a/Makefile b/Makefile
@@ -148,7 +148,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 305
+PATCHVERSION = 306
 BASEOPTS     =
 
 ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS)))

diff --git a/appendices/VK_EXT_external_memory_metal.adoc b/appendices/VK_EXT_external_memory_metal.adoc
@@ -1,4 +1,4 @@
-// Copyright 2024 The Khronos Group Inc.
+// Copyright 2024-2025 The Khronos Group Inc.
 //
 // SPDX-License-Identifier: CC-BY-4.0
 
@@ -15,9 +15,12 @@ include::{generated}/meta/{refprefix}VK_EXT_external_memory_metal.adoc[]
 
 === Description
 
-An application may wish to reference device memory in multiple Vulkan device instances, in multiple processes, and/or in Metal API.
-This extension enables an application to export and import Metal handles from Vulkan memory objects such that the underlying
-resources can be referenced outside the scope of the Vulkan device instance that created them.
+An application may wish to reference device memory in multiple Vulkan device
+instances, in multiple processes, and/or in Metal API.
+This extension enables an application to export and import Metal handles
+from Vulkan memory objects such that the underlying resources can be
+referenced outside the scope of the Vulkan device instance that created
+them.
 
 include::{generated}/interfaces/VK_EXT_external_memory_metal.adoc[]
 

diff --git a/appendices/VK_KHR_maintenance8.adoc b/appendices/VK_KHR_maintenance8.adoc
@@ -22,6 +22,10 @@ include::{generated}/meta/{refprefix}VK_KHR_maintenance8.adoc[]
   - Rick Hammerstone, Qualcomm
   - Daniel Story, Nintendo
   - Hans-Kristian Arntzen, Valve
+  - Caterina Shablia, Collabora
+  - Georg Lehmann, Valve
+  - Shahbaz Youssefi, Google
+  - Tobias Hector, AMD
 
 === Description
 

diff --git a/appendices/VK_KHR_video_maintenance2.adoc b/appendices/VK_KHR_video_maintenance2.adoc
@@ -0,0 +1,48 @@
+// Copyright 2023-2025 The Khronos Group Inc.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_KHR_video_maintenance2.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2024-10-14
+*IP Status*::
+    No known IP claims.
+*Contributors*::
+  - Ahmed Abdelkhalek, AMD
+  - Benjamin Cheng, AMD
+  - Aidan Fabius, Core Avionics & Industrial Inc.
+  - Ping Liu, Intel
+  - Lynne Iribarren, Independent
+  - Srinath Kumarapuram, NVIDIA
+  - Tony Zlatinski, NVIDIA
+  - Daniel Rakos, RasterGrid
+
+=== Description
+
+`VK_KHR_video_maintenance2` adds a collection of minor video coding
+features, none of which would warrant an entire extension of their own.
+
+The new features are as follows:
+
+  * Allow video coding control commands (such as video session reset) to be
+    issued without the need for a bound video session parameters object for
+    video decode operations that would otherwise require the use of video
+    session parameters objects.
+  * Allow applications to specify codec-specific parameter sets inline for
+    each decode operation instead of having to construct video session
+    parameters objects.
+  * Require support for
+    ename:VK_VIDEO_ENCODE_RATE_CONTROL_MODE_DISABLED_BIT_KHR in all
+    applicable video encode profiles.
+  * Provide additional guarantees on Video Std parameters that the encoder
+    implementation will not override.
+
+include::{generated}/interfaces/VK_KHR_video_maintenance2.adoc[]
+
+=== Version History
+
+  * Revision 1, 2024-10-14 (Daniel Rakos)
+  ** internal revisions
diff --git a/appendices/spirvenv.adoc b/appendices/spirvenv.adoc
@@ -1510,11 +1510,6 @@ endif::VK_NV_cooperative_matrix2[]
     instructions must: not be used in shader stages not included in
     slink:VkPhysicalDeviceCooperativeMatrixPropertiesKHR::pname:cooperativeMatrixSupportedStages
 endif::VK_KHR_cooperative_matrix[]
-  * [[VUID-{refpage}-DescriptorSet-06323]]
-    code:DescriptorSet and code:Binding decorations must: obey the
-    constraints on {StorageClass}, type, and descriptor type described in
-    <<interfaces-resources-setandbinding,DescriptorSet and Binding
-    Assignment>>
 ifdef::VK_NV_cooperative_matrix[]
   * [[VUID-{refpage}-OpCooperativeMatrixLoadNV-06324]]
     For code:OpCooperativeMatrixLoadNV and code:OpCooperativeMatrixStoreNV

diff --git a/chapters/VK_EXT_external_memory_metal/device_memory.adoc b/chapters/VK_EXT_external_memory_metal/device_memory.adoc
@@ -1,4 +1,4 @@
-// Copyright 2024 The Khronos Group Inc.
+// Copyright 2024-2025 The Khronos Group Inc.
 //
 // SPDX-License-Identifier: CC-BY-4.0
 
@@ -21,8 +21,8 @@ include::{generated}/api/structs/VkImportMemoryMetalHandleInfoEXT.adoc[]
     specifying the type of pname:handle or pname:name.
   * pname:handle is `NULL` or the external handle to import.
 
-Importing memory object payloads from Metal handles shares the
-ownership of the handle to the Vulkan implementation.
+Importing memory object payloads from Metal handles shares the ownership of
+the handle to the Vulkan implementation.
 
 Applications can: import the same payload into multiple instances of Vulkan,
 into the same instance from which it was exported, and multiple times into a
@@ -32,18 +32,23 @@ sname:VkDeviceMemory object.
 
 .Valid Usage
 ****
-  * If pname:handleType is not `0`, it must: be supported for import, as
+  * [[VUID-VkImportMemoryMetalHandleInfoEXT-handleType-10408]]
+    If pname:handleType is not `0`, it must: be supported for import, as
     reported by slink:VkExternalImageFormatProperties or
     slink:VkExternalBufferProperties
-  * The memory from which pname:handle was exported must: have been created
+  * [[VUID-VkImportMemoryMetalHandleInfoEXT-handle-10409]]
+    The memory from which pname:handle was exported must: have been created
     on the same underlying physical device as pname:device
-  * If pname:handleType is not `0`, it must: be
+  * [[VUID-VkImportMemoryMetalHandleInfoEXT-handleType-10410]]
+    If pname:handleType is not `0`, it must: be
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT,
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT or
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT
-  * If pname:handleType is not `0` , pname:handle must: be a valid non-NULL
+  * [[VUID-VkImportMemoryMetalHandleInfoEXT-handleType-10411]]
+    If pname:handleType is not `0` , pname:handle must: be a valid non-NULL
     handle of the type specified by pname:handleType
-  * pname:handle must: obey any requirements listed for pname:handleType in
+  * [[VUID-VkImportMemoryMetalHandleInfoEXT-handle-10412]]
+    pname:handle must: obey any requirements listed for pname:handleType in
     <<external-memory-handle-types-compatibility,external memory handle
     types compatibility>>
 ****
@@ -53,8 +58,8 @@ include::{generated}/validity/structs/VkImportMemoryMetalHandleInfoEXT.adoc[]
 
 [open,refpage='vkGetMemoryMetalHandleEXT',desc='Get a Metal handle for a memory object',type='protos']
 --
-To export a Metal handle representing the payload of a Vulkan device
-memory object, call:
+To export a Metal handle representing the payload of a Vulkan device memory
+object, call:
 
 include::{generated}/api/protos/vkGetMemoryMetalHandleEXT.adoc[]
 
@@ -66,8 +71,8 @@ include::{generated}/api/protos/vkGetMemoryMetalHandleEXT.adoc[]
   * pname:pHandle will return the Metal handle representing the payload of
     the device memory object.
 
-Unless the app retains the handle object returned by the call, the lifespan will be the same as
-the associated `VkDeviceMemory`.
+Unless the app retains the handle object returned by the call, the lifespan
+will be the same as the associated `VkDeviceMemory`.
 
 include::{generated}/validity/protos/vkGetMemoryMetalHandleEXT.adoc[]
 --
@@ -93,12 +98,15 @@ properties of the defined external memory handle types.
 
 .Valid Usage
 ****
-  * pname:memory must: have been created with a valid
+  * [[VUID-VkMemoryGetMetalHandleInfoEXT-memory-10413]]
+    pname:memory must: have been created with a valid
     slink:VkExportMemoryAllocateInfo
-  * pname:handleType must: have been included in
+  * [[VUID-VkMemoryGetMetalHandleInfoEXT-handleType-10414]]
+    pname:handleType must: have been included in
     slink:VkExportMemoryAllocateInfo::pname:handleTypes when pname:memory
     was created
-  * pname:handleType must: be
+  * [[VUID-VkMemoryGetMetalHandleInfoEXT-handleType-10415]]
+    pname:handleType must: be
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT,
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT or
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT
@@ -126,9 +134,11 @@ include::{generated}/api/protos/vkGetMemoryMetalHandlePropertiesEXT.adoc[]
 
 .Valid Usage
 ****
-  * pname:handle must: point to a valid id<MTLBuffer>, id<MTLTexture> or
+  * [[VUID-vkGetMemoryMetalHandlePropertiesEXT-handle-10416]]
+    pname:handle must: point to a valid id<MTLBuffer>, id<MTLTexture> or
     id<MTLDevice>
-  * pname:handleType must: be 
+  * [[VUID-vkGetMemoryMetalHandlePropertiesEXT-handleType-10417]]
+    pname:handleType must: be
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT,
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT or
     ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT
@@ -150,4 +160,4 @@ include::{generated}/api/structs/VkMemoryMetalHandlePropertiesEXT.adoc[]
     memory type which the specified Metal handle can: be imported as.
 
 include::{generated}/validity/structs/VkMemoryMetalHandlePropertiesEXT.adoc[]
---
+--
diff --git a/chapters/VK_EXT_metal_objects/device_memory.adoc b/chapters/VK_EXT_metal_objects/device_memory.adoc
@@ -173,23 +173,24 @@ include::{generated}/api/structs/VkExportMetalObjectsInfoEXT.adoc[]
   * [[VUID-VkExportMetalObjectsInfoEXT-pNext-06799]]
     If the pname:pNext chain includes a slink:VkExportMetalTextureInfoEXT
     structure, and if the slink:VkImage in its pname:image member does not
-    have a multi-planar format, then its pname:plane member must: be
-    ename:VK_IMAGE_ASPECT_PLANE_0_BIT
+    have a <<formats-multiplanar, multi-planar format>>, then its
+    pname:plane member must: be ename:VK_IMAGE_ASPECT_PLANE_0_BIT
   * [[VUID-VkExportMetalObjectsInfoEXT-pNext-06800]]
     If the pname:pNext chain includes a slink:VkExportMetalTextureInfoEXT
     structure, and if the slink:VkImage in its pname:image member has a
-    multi-planar format with only two planes, then its pname:plane member
-    must: not be ename:VK_IMAGE_ASPECT_PLANE_2_BIT
+    <<formats-multiplanar, multi-planar format>> with only two planes, then
+    its pname:plane member must: not be ename:VK_IMAGE_ASPECT_PLANE_2_BIT
   * [[VUID-VkExportMetalObjectsInfoEXT-pNext-06801]]
     If the pname:pNext chain includes a slink:VkExportMetalTextureInfoEXT
     structure, and if the slink:VkImageView in its pname:imageView member
-    does not have a multi-planar format, then its pname:plane member must:
-    be ename:VK_IMAGE_ASPECT_PLANE_0_BIT
+    does not have a <<formats-multiplanar, multi-planar format>>, then its
+    pname:plane member must: be ename:VK_IMAGE_ASPECT_PLANE_0_BIT
   * [[VUID-VkExportMetalObjectsInfoEXT-pNext-06802]]
     If the pname:pNext chain includes a slink:VkExportMetalTextureInfoEXT
     structure, and if the slink:VkImageView in its pname:imageView member
-    has a multi-planar format with only two planes, then its pname:plane
-    member must: not be ename:VK_IMAGE_ASPECT_PLANE_2_BIT
+    has a <<formats-multiplanar, multi-planar format>> with only two planes,
+    then its pname:plane member must: not be
+    ename:VK_IMAGE_ASPECT_PLANE_2_BIT
   * [[VUID-VkExportMetalObjectsInfoEXT-pNext-06803]]
     If the pname:pNext chain includes a slink:VkExportMetalIOSurfaceInfoEXT
     structure, the slink:VkImage in its pname:image member must: have been

diff --git a/chapters/capabilities.adoc b/chapters/capabilities.adoc
@@ -529,12 +529,12 @@ ifdef::VK_QNX_external_memory_screen_buffer[]
     details of this handle type.
 endif::VK_QNX_external_memory_screen_buffer[]
 ifdef::VK_EXT_external_memory_metal[]
-  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT is a handle to
-    a `MTLResource` holding a `MTLBuffer`.
-  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT is a handle to
-    a `MTLResource` holding a `MTLTexture`.
-  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT is a handle to
-    a `MTLResource` holding a `MTLHeap`.
+  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLBUFFER_BIT_EXT is a handle to a
+    `MTLResource` holding a `MTLBuffer`.
+  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLTEXTURE_BIT_EXT is a handle to a
+    `MTLResource` holding a `MTLTexture`.
+  * ename:VK_EXTERNAL_MEMORY_HANDLE_TYPE_MTLHEAP_BIT_EXT is a handle to a
+    `MTLResource` holding a `MTLHeap`.
 endif::VK_EXT_external_memory_metal[]
 
 <<<
@@ -824,9 +824,10 @@ ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
 [open,refpage='VkSamplerYcbcrConversionImageFormatProperties',desc='Structure specifying combined image sampler descriptor count for multi-planar images',type='structs']
 --
 To determine the number of combined image samplers required to support a
-multi-planar format, add slink:VkSamplerYcbcrConversionImageFormatProperties
-to the pname:pNext chain of the slink:VkImageFormatProperties2 structure in
-a call to fname:vkGetPhysicalDeviceImageFormatProperties2.
+<<formats-multiplanar, multi-planar format>>, add
+slink:VkSamplerYcbcrConversionImageFormatProperties to the pname:pNext chain
+of the slink:VkImageFormatProperties2 structure in a call to
+fname:vkGetPhysicalDeviceImageFormatProperties2.
 
 The sname:VkSamplerYcbcrConversionImageFormatProperties structure is defined
 as:
@@ -872,7 +873,8 @@ implementations to use a uniform stride for dynamic indexing of the
 descriptors in the binding.
 
 For example, consider a descriptor set layout binding with two descriptors
-and immutable samplers for multi-planar formats that have
+and immutable samplers for <<formats-multiplanar, multi-planar formats>>
+that have
 sname:VkSamplerYcbcrConversionImageFormatProperties::pname:combinedImageSamplerDescriptorCount
 values of `2` and `3` respectively.
 There are two descriptors in the binding and the maximum

diff --git a/chapters/commonvalidity/blit_image_common.adoc b/chapters/commonvalidity/blit_image_common.adoc
@@ -135,7 +135,7 @@ endif::VK_VERSION_1_4,VK_KHR_maintenance5[]
     slink:VkImageCreateInfo when pname:srcImage was created
   * [[VUID-{refpage}-dstSubresource-01708]]
 ifdef::VK_VERSION_1_4,VK_KHR_maintenance5[]
-    If pname:srcSubresource.layerCount is not
+    If pname:dstSubresource.layerCount is not
     ename:VK_REMAINING_ARRAY_LAYERS,
 endif::VK_VERSION_1_4,VK_KHR_maintenance5[]
     [eq]#pname:dstSubresource.baseArrayLayer {plus}

diff --git a/...ers/commonvalidity/copy_bufferimage_to_imagebuffer_buffer_alignment_common.adoc b/...ers/commonvalidity/copy_bufferimage_to_imagebuffer_buffer_alignment_common.adoc
@@ -12,18 +12,17 @@
   * [[VUID-{refpage}-{imageparam}-07975]]
     If pname:{imageparam} does not have either a depth/stencil format
 ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
-    or a <<formats-requiring-sampler-ycbcr-conversion,multi-planar format>>,
+    or a <<formats-multiplanar, multi-planar format>>,
 endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
     then for each element of pname:pRegions, pname:bufferOffset must: be a
     multiple of the <<formats-compatibility-classes,texel block size>>
 ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
   * [[VUID-{refpage}-{imageparam}-07976]]
-    If pname:{imageparam} has a
-    <<formats-requiring-sampler-ycbcr-conversion,multi-planar format>>, then
-    for each element of pname:pRegions, pname:bufferOffset must: be a
-    multiple of the element size of the compatible format for the format and
-    the pname:aspectMask of the pname:imageSubresource as defined in
-    <<formats-compatible-planes>>
+    If pname:{imageparam} has a <<formats-multiplanar, multi-planar
+    format>>, then for each element of pname:pRegions, pname:bufferOffset
+    must: be a multiple of the element size of the compatible format for the
+    format and the pname:aspectMask of the pname:imageSubresource as defined
+    in <<formats-compatible-planes>>
 endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
   * [[VUID-{refpage}-{imageparam}-07978]]
     If pname:{imageparam} has a depth/stencil format, the pname:bufferOffset

diff --git a/chapters/commonvalidity/copy_bufferimage_to_imagebuffer_common.adoc b/chapters/commonvalidity/copy_bufferimage_to_imagebuffer_common.adoc
@@ -156,11 +156,10 @@ endif::VK_QCOM_rotated_copy_commands[]
     must: specify aspects present in pname:{imageparam}
 ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
   * [[VUID-{refpage}-{imageparam}-07981]]
-    If pname:{imageparam} has a
-    <<formats-requiring-sampler-ycbcr-conversion, multi-planar image
+    If pname:{imageparam} has a <<formats-multiplanar, multi-planar
     format>>, then for each element of pname:pRegions,
     pname:{imagesubresource}.aspectMask must: be a single valid
-    <<formats-planes-image-aspect,multi-planar aspect mask>> bit
+    <<formats-multiplanar-image-aspect,multi-planar aspect mask>> bit
 endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
   * [[VUID-{refpage}-{imageparam}-07983]]
     If pname:{imageparam} is of type ename:VK_IMAGE_TYPE_3D, for each