Change log for March 13, 2026 Vulkan 1.4.346 spec update:

Github Issues

  * Clarify winding order for micromap triangle 3 (public issue 2686).
  * Clarify VkStructureType naming derivation in the <<fundamentals>>
    chapter to avoid double underscores (public PR 2698).

Internal Issues

  * Add <<glossary>> definitions of "`Undefined Values`" and "`Poison`". Use
    the latter throughout the spec where relevant in place of the current
    "`undefined values`" terminology (internal issue 4442).
  * Clarify interactions between
    VK_EXT_rasterization_order_attachment_access and dynamic rendering for
    VkSubpassDescriptionFlagBits and in the extension appendix (internal
    issue 4627).
  * Clarify binding reports on sparse objects in the
    VK_EXT_device_address_binding_report appendix (internal issue 4674).
  * Require that two SPIR-V variables placed in the same Location have the
    same numeric type, not the same "`underlying type`" (internal issue
    4722).
  * Move LongVector VUs 12295 and 12297 from runtime SPIR-V to standalone
    SPIR-V (internal MR 8106).
  * Pass `supersededby` XML attribute into VulkanObject (internal MR 8107).
  * Add `returnedonly` to VkDeviceFaultAddressInfoEXT and
    VkDeviceFaultVendorInfoEXT XML definitions (internal MR 8121).
  * Add VkPipeline*FlagBits types unconditionally in Vulkan 1.0 to work
    around modular headers problems (internal MR 8122).
  * Move VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE to
    VK_COMPUTE_VERSION_1_2 XML feature from VK_BASE_VERSION_1_0 (internal MR
    8123).
 * Remove duplicate VUs from vkCmdCopyAccelerationStructureKHR (internal MR
   8125).

New Extensions

  * VK_KHR_device_address_commands

Author: oddhack

.gitlab-ci.yml

@@ -56,7 +56,7 @@ proposed-check:
 spec_extension_branch_check:
   stage: build
   script:
-    - python3 scripts/testSpecVersion.py -branch "$CI_COMMIT_BRANCH" -test -build
+    - python3 scripts/testSpecVersion.py -branch "$CI_COMMIT_BRANCH" -test -build -build_log
   allow_failure: false
 
 # Build a test spec and check against expectation, to make sure the spec toolchain works as expected

ChangeLog.adoc

@@ -14,6 +14,47 @@ appears frequently in the change log.
 
 '''
 
+Change log for March 13, 2026 Vulkan 1.4.346 spec update:
+
+Github Issues
+
+  * Clarify winding order for micromap triangle 3 (public issue 2686).
+  * Clarify VkStructureType naming derivation in the <<fundamentals>>
+    chapter to avoid double underscores (public PR 2698).
+
+Internal Issues
+
+  * Add <<glossary>> definitions of "`Undefined Values`" and "`Poison`". Use
+    the latter throughout the spec where relevant in place of the current
+    "`undefined values`" terminology (internal issue 4442).
+  * Clarify interactions between
+    VK_EXT_rasterization_order_attachment_access and dynamic rendering for
+    VkSubpassDescriptionFlagBits and in the extension appendix (internal
+    issue 4627).
+  * Clarify binding reports on sparse objects in the
+    VK_EXT_device_address_binding_report appendix (internal issue 4674).
+  * Require that two SPIR-V variables placed in the same Location have the
+    same numeric type, not the same "`underlying type`" (internal issue
+    4722).
+  * Move LongVector VUs 12295 and 12297 from runtime SPIR-V to standalone
+    SPIR-V (internal MR 8106).
+  * Pass `supersededby` XML attribute into VulkanObject (internal MR 8107).
+  * Add `returnedonly` to VkDeviceFaultAddressInfoEXT and
+    VkDeviceFaultVendorInfoEXT XML definitions (internal MR 8121).
+  * Add VkPipeline*FlagBits types unconditionally in Vulkan 1.0 to work
+    around modular headers problems (internal MR 8122).
+  * Move VK_SAMPLER_ADDRESS_MODE_MIRROR_CLAMP_TO_EDGE to
+    VK_COMPUTE_VERSION_1_2 XML feature from VK_BASE_VERSION_1_0 (internal MR
+    8123).
+ * Remove duplicate VUs from vkCmdCopyAccelerationStructureKHR (internal MR
+   8125).
+
+New Extensions
+
+  * VK_KHR_device_address_commands
+
+'''
+
 Change log for March 6, 2026 Vulkan 1.4.345 spec update:
 
 Github Issues

Makefile

@@ -151,7 +151,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 345
+PATCHVERSION = 346
 BASEOPTS     =
 
 ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS)))

appendices/VK_ARM_rasterization_order_attachment_access.adoc

@@ -7,7 +7,7 @@ include::{generated}/meta/{refprefix}VK_ARM_rasterization_order_attachment_acces
 === Other Extension Metadata
 
 *Last Modified Date*::
-    2021-11-12
+    2026-01-16
 *IP Status*::
     No known IP claims.
 *Contributors*::
@@ -33,14 +33,7 @@ include::{generated}/interfaces/VK_ARM_rasterization_order_attachment_access.ado
 
 === Issues
 
-1) Is there any interaction with the `apiext:VK_KHR_dynamic_rendering`
-extension?
-
-No.
-This extension only affects reads from input attachments.
-Render pass instances begun with flink:vkCmdBeginRenderingKHR do not have
-input attachments and a different mechanism will be needed to provide
-similar functionality in this case.
+See the Issues for `apiext:VK_EXT_rasterization_order_attachment_access`.
 
 === Examples
 
@@ -50,3 +43,4 @@ None.
 
   * Revision 1, 2021-11-12 (Jan-Harald Fredriksen)
   ** Initial draft
+  ** Updated Issues section 2026-01-16

appendices/VK_EXT_device_address_binding_report.adoc

@@ -125,6 +125,12 @@ If the device memory is subsequently bound to a buffer or image via
 vkBind*Memory, the callbacks should be triggered a second time, reporting
 the association between virtual address range and the buffer/image.
 
+12.) Should binding reports be emitted for vkQueueBindSparse() operations?
+
+*RESOLVED*: binding reports for sparse objects are best effort, some
+implementations might report events on vkQueueBindSparse() other
+implementations might report events on sparse object creation/destruction.
+
 === Version History
 
   * Revision 1, 2020-09-23 (Ralph Potter)

appendices/VK_EXT_opacity_micromap.adoc

@@ -50,6 +50,7 @@ This extension provides:
 
 include::{generated}/interfaces/VK_EXT_opacity_micromap.adoc[]
 
+[[opacity-micromap-reference-code]]
 === Reference Code
 
 [source,c++]

appendices/VK_EXT_rasterization_order_attachment_access.adoc

@@ -7,7 +7,7 @@ include::{generated}/meta/{refprefix}VK_EXT_rasterization_order_attachment_acces
 === Other Extension Metadata
 
 *Last Modified Date*::
-    2022-07-04
+    2026-01-16
 *IP Status*::
     No known IP claims.
 *Contributors*::
@@ -23,6 +23,44 @@ order, without explicit synchronization.
 
 include::{generated}/interfaces/VK_EXT_rasterization_order_attachment_access.adoc[]
 
+=== Issues
+
+1) What are the interactions with the `apiext:VK_KHR_dynamic_rendering` or
+`apiext:VK_KHR_dynamic_rendering_local_read` extensions?
+
+*RESOLVED*
+
+Render pass instances begun with flink:vkCmdBeginRenderingKHR do not have
+input attachments and thus a different mechanism was needed to provide
+similar functionality in this case.
+This was provided by `apiext:VK_KHR_dynamic_rendering_local_read`, which
+enables reads from attachments and resources written by previous fragment
+shaders within a dynamic render pass.
+
+Render pass instances begun with flink:vkCmdBeginRenderingKHR do not have
+subpasses, and there is no equivalent to the following flag bits for these
+instances:
+
+  * 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
+
+Instead, the behavior is controlled only by the corresponding pipeline flag
+bits, i.e.:
+
+  * VK_PIPELINE_COLOR_BLEND_STATE_CREATE_RASTERIZATION_ORDER_ATTACHMENT_ACCESS_BIT_EXT
+  * 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
+
+2) What is the interaction with the `apiext:VK_EXT_shader_object` extension?
+
+*RESOLVED*
+
+This functionality is not available for draw calls using shader objects
+because the `apiext:VK_EXT_shader_object` extension depends on
+`apiext:VK_KHR_dynamic_rendering`, and thus neither the subpass flags nor
+the pipeline flags defined in this extension can be specified.
+
 === Examples
 
 None.
@@ -31,3 +69,4 @@ None.
 
   * Revision 1, 2022-07-04 (Jan-Harald Fredriksen)
   ** Initial draft
+  ** Updated Issues section 2026-01-16

appendices/VK_KHR_device_address_commands.adoc

@@ -0,0 +1,54 @@
+// Copyright 2025-2026 The Khronos Group Inc.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_KHR_device_address_commands.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2026-03-10
+*Contributors*::
+  - Tobias Hector, AMD
+  - Matthew Netsch, Qualcomm Technologies, Inc
+  - Jan-Harald Fredriksen, Arm
+  - Mike Blumenkrantz, Valve
+  - Allan MacKinnon, Google
+  - Daniel Koch, NVIDIA
+  - Autumn Ashton, Valve
+  - Piers Daniell, NVIDIA
+  - Stuart Smith, AMD
+  - Caterina Shablia, Collabora
+  - Piotr Byszewski, Cognizant
+  - James Fitzpatrick, Imagination
+  - Daniel Story, Nintendo
+  - Baldur Karlsson, Valve
+  - Jon Leech, Khronos
+  - Samuel Pitoiset, Valve
+  - Lionel Landwerlin, Intel
+  - Hans-Kristian Arntzen, Valve
+  - Žiga Markuš, LunarG
+  - Spencer Fricke, Lunarg
+  - Per Inge Mathisen, Arm
+  - Vikram Kushwaha, NVIDIA
+  - Ralph Potter, Samsung
+  - Marijn Suijten, Traverse Research
+  - Ricard Garcia, Igalia
+  - Mengyang Liu, AMD
+  - Artem Kharytoniuk, LunarG
+  - Marty Johnson, Khronos
+  - Alyssa Rosenzweig, Valve
+
+
+=== Description
+
+This extension enables applications to use device addresses in place of
+buffer objects for most functionality.
+
+include::{generated}/interfaces/VK_KHR_device_address_commands.adoc[]
+
+
+=== Version History
+
+  * Revision 1, 2026-03-10 (Tobias Hector)
+  ** Initial revision

appendices/VK_NV_shader_image_footprint.adoc

@@ -70,7 +70,7 @@ This extension has a number of limitations.
 The code: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.
+poison 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.
 

appendices/glossary.adoc

@@ -1600,6 +1600,15 @@ Point Sampling (Rasterization)::
     polygon according to the tie-breaking rules.
 endif::VK_GRAPHICS_VERSION_1_0[]
 
+ifdef::VK_COMPUTE_VERSION_1_0[]
+Poison::
+    Equivalent to poison in the <<spirv-spec,SPIR-V specification>>.
+    Can only be generated by shader operations.
+    Poison values made available to the host or read by device operations
+    outside of a SPIR-V instruction behave as undefined: values for all such
+    accesses.
+endif::VK_COMPUTE_VERSION_1_0[]
+
 Potential Format Features::
     The union of all elink:VkFormatFeatureFlagBits that the implementation
     supports for a specified elink:VkFormat, over all supported image
@@ -2146,6 +2155,14 @@ Timeline Semaphore::
     of ename:VK_SEMAPHORE_TYPE_TIMELINE.
 endif::VK_BASE_VERSION_1_2,VK_KHR_timeline_semaphore[]
 
+Undefined Value::
+    A value that does not have a specific defined bit pattern.
+    Undefined values are not
+    <<fundamentals-commandsyntax-results-lifetime,invariant>>.
+ifdef::VK_COMPUTE_VERSION_1_0[]
+    When read by a shader operation, undefined: values are read as _poison_.
+endif::VK_COMPUTE_VERSION_1_0[]
+
 ifdef::VK_COMPUTE_VERSION_1_0[]
 Uniform Texel Buffer::
     A descriptor type that represents a buffer view, and supports