Change log for November 14, 2025 Vulkan 1.4.333 spec update:

Github Issues

  * Fix `const` pNext in returnedonly="true" structs (public PR 2601).
  * Update description of queue objects to omit "`execution engines`"
    (public issue 2604).

Internal Issues

  * Add CI checks in xml_consistency.py for cases where pNext members must
    not be `const` (internal issue 2734).
  * Use "`for each element`" instead of "`for any element`" in VUs for ray
    tracing extensions, and document this pattern in the style guide
    (internal issue 4534).
  * Add acceleration structures to vkUpdateDescriptorSetWithTemplate VU
    01685 (internal issue 4536).
  * Add common query results VUs restricting
    VK_QUERY_RESULT_WITH_STATUS_BIT_KHR based on the query type (internal
    issue 4484).
  * Fix `const` pNext in VkPhysicalDeviceDataGraphModelFeaturesQCOM
    (internal MR 7804).
  * Merge INTEL, NN, NV, QCOM, and QNX extension markup in separate files
    into the chapters they are included from (internal issue 4516).
  * Update pipeline library dependency explanation in the
    VK_KHR_ray_tracing_pipeline extension appendix (internal MR 7828).

New Extensions

  * VK_EXT_custom_resolve
  * VK_EXT_ray_tracing_invocation_reorder

Author: oddhack

ChangeLog.adoc

@@ -14,6 +14,40 @@ appears frequently in the change log.
 
 '''
 
+Change log for November 14, 2025 Vulkan 1.4.333 spec update:
+
+Github Issues
+
+  * Fix `const` pNext in returnedonly="true" structs (public PR 2601).
+  * Update description of queue objects to omit "`execution engines`"
+    (public issue 2604).
+
+Internal Issues
+
+  * Add CI checks in xml_consistency.py for cases where pNext members must
+    not be `const` (internal issue 2734).
+  * Use "`for each element`" instead of "`for any element`" in VUs for ray
+    tracing extensions, and document this pattern in the style guide
+    (internal issue 4534).
+  * Add acceleration structures to vkUpdateDescriptorSetWithTemplate VU
+    01685 (internal issue 4536).
+  * Add common query results VUs restricting
+    VK_QUERY_RESULT_WITH_STATUS_BIT_KHR based on the query type (internal
+    issue 4484).
+  * Fix `const` pNext in VkPhysicalDeviceDataGraphModelFeaturesQCOM
+    (internal MR 7804).
+  * Merge INTEL, NN, NV, QCOM, and QNX extension markup in separate files
+    into the chapters they are included from (internal issue 4516).
+  * Update pipeline library dependency explanation in the
+    VK_KHR_ray_tracing_pipeline extension appendix (internal MR 7828).
+
+New Extensions
+
+  * VK_EXT_custom_resolve
+  * VK_EXT_ray_tracing_invocation_reorder
+
+'''
+
 Change log for November 7, 2025 Vulkan 1.4.332 spec update:
 
 Github Issues

ChangeLogSC.adoc

@@ -12,6 +12,27 @@ with any public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for November 10, 2025 Vulkan SC 1.0.20 spec update:
+
+  * update release number to 20 for this update and reflow spec language (#273/!417)
+
+Public issues:
+
+  * None
+
+Internal issues:
+
+  * Enable legacy appendix for Vulkan SC (#269/!415)
+  * Add VKSC_VERSION_1_0 listing to Core Versions appendix (!416)
+  * Merge VK 1.4.330 tag to sc_main (!414)
+  * Merge VK 1.4.329 tag to sc_main (!413)
+  * Merge VK 1.4.326 tag to sc_main (!412)
+  * Add description of API compatibility between Vulkan and Vulkan SC (#272/!411)
+  * Import reuse fix from github (!410)
+  * Fix limittype for supportsNonZeroFirstInstance (!409)
+
+-----------------------------------------------------
+
 Change log for August 1, 2025 Vulkan SC 1.0.19 spec update:
 
   * update release number to 19 for this update and reflow spec language (#258/!408)

Makefile

@@ -151,12 +151,12 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 332
+PATCHVERSION = 333
 BASEOPTS     =
 
 ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS)))
 VKSPECREVISION := 1.2.$(PATCHVERSION)
-SCPATCHVERSION = 19
+SCPATCHVERSION = 20
 SPECREVISION = 1.0.$(SCPATCHVERSION)
 BASEOPTS = -a baserevnumber="$(VKSPECREVISION)"
 else

appendices/VK_EXT_custom_resolve.adoc

@@ -0,0 +1,55 @@
+// Copyright 2025 The Khronos Group Inc.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_EXT_custom_resolve.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2025-05-13
+*IP Status*::
+    No known IP claims.
+*Interactions and External Dependencies*::
+  - This extension interacts with `apiext:VK_KHR_dynamic_rendering`
+  - This extension interacts with
+    `apiext:VK_EXT_dynamic_rendering_unused_attachments`
+  - This extension interacts with `apiext:VK_EXT_fragment_density_map`
+  - This extension interacts with `apiext:VK_EXT_graphics_pipeline_library`
+  - This extension interacts with `apiext:VK_EXT_shader_object`
+*Contributors*::
+  - Mike Blumenkrantz, Valve
+  - Connor Abbott, Valve
+  - Samuel Pitoiset, Valve
+  - Matthew Netsch, Qualcomm
+  - Jan-Harald Fredriksen, ARM
+  - Ting Wei, ARM
+  - Ricardo Garcia, Igalia
+  - Spencer Fricke, LunarG
+  - Piers Daniell, Nvidia
+
+=== Description
+
+This extension provides functionality for using shaders to resolve
+multisample rendering attachments.
+
+It builds upon mechanics introduced by VK_QCOM_render_pass_shader_resolve,
+additionally adding support for dynamic rendering.
+
+include::{generated}/interfaces/VK_EXT_custom_resolve.adoc[]
+
+=== Issues
+
+1) How will this work with shader objects?
+
+Some vendors emit an epilog at the end of the FS that stores each
+color/depth/stencil attachment to the appropriate tilebuffer location, and
+to do that they need to know the layout of the tilebuffer which depends on
+the attachment formats/sample counts.
+We agreed that for shader object the FS epilog is emitted dynamically when
+the draw happens.
+
+=== Version History
+
+  * Revision 1, 2025-05-13 (Mike Blumenkrantz)
+  ** Initial draft

appendices/VK_EXT_ray_tracing_invocation_reorder.adoc

@@ -0,0 +1,48 @@
+// Copyright (c) 2024-2025 Khronos Group
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_EXT_ray_tracing_invocation_reorder.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2025-11-12
+*Interactions and External Dependencies*::
+  - This extension provides API support for
+    {GLSLregistry}/ext/GLSL_EXT_shader_invocation_reorder.txt[`GL_EXT_shader_invocation_reorder`]
+*Contributors*::
+  - Eric Werness, NVIDIA
+  - Ashwin Lele, NVIDIA
+  - Daniel Koch, NVIDIA
+  - Vikram Kushwaha, NVIDIA
+  - Piers Daniell, NVIDIA
+  - Stu Smith, AMD
+  - Aaron Hagan, AMD
+  - Tyler Nowicki, AMD
+  - Sebastian Neubauer, AMD
+  - Radoslaw Drabinski, Intel
+  - Sven Woop, Intel
+  - Aleksandra Krstic, QUALCOMM
+  - Andrew Garrard, Imagination Technologies
+  - Mathieu Robart, Arm Limited
+  - Tom Olson, Khronos
+  - Ralph Potter, Samsung Electronics
+  - Antonio Caggiano, LunarG
+
+=== Description
+
+The ray tracing pipeline API provides some ability to reorder for locality,
+but it is useful to have more control over how the reordering happens and
+what information is included in the reordering.
+The shader API provides a hit object to contain result information from the
+hit which can be used as part of the explicit sorting plus options that
+contain an integer for hint bits to use to add more coherency.
+
+include::{generated}/interfaces/VK_EXT_ray_tracing_invocation_reorder.adoc[]
+
+
+=== Version History
+
+  * Revision 1, 2025-11-12 (Eric Werness)
+  ** Internal development - forked from NV

appendices/VK_KHR_ray_tracing_pipeline.adoc

@@ -317,7 +317,7 @@ There are two main reasons for the difference here:
 --
 
 (6) Why is `apiext:VK_KHR_pipeline_library` an interaction instead of a
-required dependency, particularly when the "`Feature Requirements`" section
+required dependency, particularly when the "`Device Extensions`" section
 says it is required to be supported anyhow?
 --
 *RESOLVED*: If the `apiext:VK_KHR_pipeline_library` extension were a
@@ -326,7 +326,7 @@ 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.
+it is listed as a requirement in device extensions section.
 --
 
 

appendices/glossary.adoc

@@ -1526,6 +1526,14 @@ ifdef::VK_NV_ray_tracing_motion_blur[]
   * code:OpHitObjectTraceRayMotionNV
 endif::VK_NV_ray_tracing_motion_blur[]
 endif::VK_NV_ray_tracing_invocation_reorder[]
+ifdef::VK_EXT_ray_tracing_invocation_reorder[]
+  * code:OpHitObjectTraceRayEXT
+  * code:OpHitObjectTraceReorderExecuteEXT
+ifdef::VK_NV_ray_tracing_motion_blur[]
+  * code:OpHitObjectTraceRayMotionEXT
+  * code:OpHitObjectTraceMotionReorderExecuteEXT
+endif::VK_NV_ray_tracing_motion_blur[]
+endif::VK_EXT_ray_tracing_invocation_reorder[]
 
 endif::VK_KHR_ray_tracing_pipeline,VK_NV_ray_tracing[]
 

appendices/legacy.adoc

@@ -54,10 +54,6 @@ the Extensions chapter>> for more information.
 When functionality is marked as legacy or if an extension supersedes it, an
 explanation will be added to the following sections.
 
-ifdef::VKSC_VERSION_1_0[]
-This section is currently empty for Vulkan SC.
-endif::VKSC_VERSION_1_0[]
-ifndef::VKSC_VERSION_1_0[]
 [NOTE]
 ====
 This list is a work in progress - we intend to add other items to this
@@ -84,6 +80,8 @@ provided in the pname:pNext chain of slink:VkDeviceCreateInfo instead of
 using slink:VkDeviceCreateInfo::pEnabledFeatures.
 endif::VK_BASE_VERSION_1_1[]
 
+ifndef::VKSC_VERSION_1_0[]
+// these were never included in VKSC 1.0
 [[legacy-version-macros]]
 === Version Macros: Superseded via replacements including API variant
 
@@ -94,6 +92,7 @@ that do, such as dlink:VK_MAKE_API_VERSION or dlink:VK_API_VERSION_MAJOR.
 Instead of dlink:VK_API_VERSION, specific version defines (e.g.
 dlink:VK_API_VERSION_1_0) or the dlink:VK_MAKE_API_VERSION macro should be
 used instead.
+endif::VKSC_VERSION_1_0[]
 
 [[legacy-devicelayers]]
 === Device Layers: Superseded via instance layers
@@ -170,4 +169,3 @@ Outside of vendor extensions, applications are advised to make use of
 flink:vkCmdBeginRendering and flink:vkCmdEndRendering to manage render
 passes from this API version onward.
 endif::VK_GRAPHICS_VERSION_1_4,VK_KHR_dynamic_rendering_local_read[]
-endif::VKSC_VERSION_1_0[]