Change log for November 28, 2025 Vulkan 1.4.335 spec update:

Github Issues

  * Apply -removeExtensions genvk.py flag to platform headers (public PR
    2616).

Internal Issues

  * Update tessellation VUs for shader objects to constrain patch size,
    subdivision, spacing / orientation, and point mode as to which shader
    stages they can appear in, and enforce matching rules across stages
    (internal issues 3458, 3747).
  * Evaluate complex dependencies in XML at syncgenerator runtime, instead
    of relying on asciidoc which cannot evaluate all such expressions
    properly. This restores several tokens in the generated tables related
    to VK_KHR_ray_tracing_pipelin (internal issue 4133).
  * Merge remaining FUCHSIA, GGP, and [GOOGLE] vendor extension markup in
    separate files into the chapters they are included from (internal issue
    4516).
  * Add missing VU for VK_KHR_copy_memory_indirect commands requiring source
    and destination memory be from ranges allocated from buffers and images
    with the correct USAGE flags set (internal issue 4546).
  * Mark vkCmdDebug*EXT in XML as state, not action commands (internal issue
    4558).
  * Clarify address mode parameters and type ranges for VkSamplerCreateInfo
    and VkSamplerAddressMode (internal issue 4560).
  * Require support for at least one queue family supporting graphics,
    compute, or video operations in VkQueueFlagBits (internal issue 4566).
  * Add USAGE flag VUs for vkGetDescriptorEXT (internal MR 7801).
  * Add standalone SPIR-V device Scope VU for OpTypeCooperativeMatrixKHR
    (internal MR 7827).
  * Merge orphaned VK_EXT_metal_surface include into WSI chapter (internal
    MR 7854).
  * Add VkDescriptorSetLayoutBinding VU restricting YCbCr samplers (internal
    MR 7858).
  * Fix / split VUs for
    VkClusterAccelerationStructureCommandsInfoNV::dstAddressesArray
    (internal MR 7861).

New Extensions

  * VK_EXT_present_timing

Author: oddhack

ChangeLog.adoc

@@ -14,6 +14,52 @@ appears frequently in the change log.
 
 '''
 
+Change log for November 28, 2025 Vulkan 1.4.335 spec update:
+
+Github Issues
+
+  * Apply -removeExtensions genvk.py flag to platform headers (public PR
+    2616).
+
+Internal Issues
+
+  * Update tessellation VUs for shader objects to constrain patch size,
+    subdivision, spacing / orientation, and point mode as to which shader
+    stages they can appear in, and enforce matching rules across stages
+    (internal issues 3458, 3747).
+  * Evaluate complex dependencies in XML at syncgenerator runtime, instead
+    of relying on asciidoc which cannot evaluate all such expressions
+    properly. This restores several tokens in the generated tables related
+    to VK_KHR_ray_tracing_pipelin (internal issue 4133).
+  * Merge remaining FUCHSIA, GGP, and [GOOGLE] vendor extension markup in
+    separate files into the chapters they are included from (internal issue
+    4516).
+  * Add missing VU for VK_KHR_copy_memory_indirect commands requiring source
+    and destination memory be from ranges allocated from buffers and images
+    with the correct USAGE flags set (internal issue 4546).
+  * Mark vkCmdDebug*EXT in XML as state, not action commands (internal issue
+    4558).
+  * Clarify address mode parameters and type ranges for VkSamplerCreateInfo
+    and VkSamplerAddressMode (internal issue 4560).
+  * Require support for at least one queue family supporting graphics,
+    compute, or video operations in VkQueueFlagBits (internal issue 4566).
+  * Add USAGE flag VUs for vkGetDescriptorEXT (internal MR 7801).
+  * Add standalone SPIR-V device Scope VU for OpTypeCooperativeMatrixKHR
+    (internal MR 7827).
+  * Merge orphaned VK_EXT_metal_surface include into WSI chapter (internal
+    MR 7854).
+  * Add VkDescriptorSetLayoutBinding VU restricting YCbCr samplers (internal
+    MR 7858).
+  * Fix / split VUs for
+    VkClusterAccelerationStructureCommandsInfoNV::dstAddressesArray
+    (internal MR 7861).
+
+New Extensions
+
+  * VK_EXT_present_timing
+
+'''
+
 Change log for November 21, 2025 Vulkan 1.4.334 spec update:
 
 Github Issues

Makefile

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

appendices/VK_EXT_present_timing.adoc

@@ -60,48 +60,47 @@ whether FRR vs. VRR, etc.
 *PROPOSED*: the query returns two values: 1) a refresh-cycle duration
 (pname:refreshDuration), and 2) an indication whether the timing is
 currently fixed (FRR) or variable (VRR).
-If pname:refreshDuration is zero, the platform cannot supply these
-values until after at least one flink:vkQueuePresentKHR has been done,
-from this time (e.g. if flink:vkQueuePresentKHR has been previously
-called for this swapchain, at least one additional call must be made).
+If pname:refreshDuration is zero, the platform cannot supply these values
+until after at least one flink:vkQueuePresentKHR has been done, from this
+time (e.g. if flink:vkQueuePresentKHR has been previously called for this
+swapchain, at least one additional call must be made).
 After calling flink:vkQueuePresentKHR, the query can be repeated until
-pname:refreshDuration is non-zero, at which point the FRR vs. VRR
-indication will also be valid.
+pname:refreshDuration is non-zero, at which point the FRR vs. VRR indication
+will also be valid.
 
-If the presentation engine's pname:refreshDuration is a fixed value,
-the application's image present duration (IPD) should be a multiple of
+If the presentation engine's pname:refreshDuration is a fixed value, the
+application's image present duration (IPD) should be a multiple of
 pname:refreshDuration.
 That is, the quanta for changing the IPD is pname:refreshDuration.
-For example, if pname:refreshDuration is 16.67ms, the IPD can be
-16.67ms, 33.33ms, 50.0ms, etc.
+For example, if pname:refreshDuration is 16.67ms, the IPD can be 16.67ms,
+33.33ms, 50.0ms, etc.
 
 If the presentation engine's pname:refreshDuration is variable,
-pname:refreshDuration is the minimum value of the application's IPD, and
-the IPD can be larger by any quanta that is meaningful to the application.
-For example, if the pname:refreshDuration is 10ms (i.e. the maximum
-refresh rate is 100Hz), the application can choose an IPD of 11ms,
-13.33ms, 13.5ms, or 66.0ms; any value greater than or equal to 10ms is
-valid.
-There may be negative consequences for choosing an IPD that is too
-high, as the presentation engine may actually have a practical maximum
-pname:refreshDuration, where it needs to display the previous image
-again, and during this time the presentation engine might delay
-displaying a newly-presented image.
-
-FRR displays on at least one platform (Wayland) are not necessarily
-fixed; but can change over time.
-For example, if a full-screen video player application is visible, the display
-may operate at a 24Hz refresh cycle; and then later switch to 60Hz when
-multiple windows are visible.
+pname:refreshDuration is the minimum value of the application's IPD, and the
+IPD can be larger by any quanta that is meaningful to the application.
+For example, if the pname:refreshDuration is 10ms (i.e. the maximum refresh
+rate is 100Hz), the application can choose an IPD of 11ms, 13.33ms, 13.5ms,
+or 66.0ms; any value greater than or equal to 10ms is valid.
+There may be negative consequences for choosing an IPD that is too high, as
+the presentation engine may actually have a practical maximum
+pname:refreshDuration, where it needs to display the previous image again,
+and during this time the presentation engine might delay displaying a
+newly-presented image.
+
+FRR displays on at least one platform (Wayland) are not necessarily fixed;
+but can change over time.
+For example, if a full-screen video player application is visible, the
+display may operate at a 24Hz refresh cycle; and then later switch to 60Hz
+when multiple windows are visible.
 
 VRR displays on some platforms can also be seen as having different
 characteristics over time.
-For example, if an application's window is full-screen-exclusive (i.e. no other
-window or window system component is visible), the display can look like a VRR
-display (however that is defined).
+For example, if an application's window is full-screen-exclusive (i.e. no
+other window or window system component is visible), the display can look
+like a VRR display (however that is defined).
 If the application's window is not full-screen-exclusive (e.g. a normal
-multi-window case), the display can look like an FRR display (i.e. because the
-compositor is trying to treat all windows in a consistent manner).
+multi-window case), the display can look like an FRR display (i.e. because
+the compositor is trying to treat all windows in a consistent manner).
 A different issue will deal with how the timing characteristics can change
 over time.
 
@@ -110,45 +109,45 @@ over time.
 
 *PROPOSED*: return only the minimum value of refreshDuration for a VRR.
 
-VRR displays have a minimum and maximum refresh rate, and therefore a minimum
-and maximum refreshDuration.
+VRR displays have a minimum and maximum refresh rate, and therefore a
+minimum and maximum refreshDuration.
 It has been asserted that the display effectively does not have a minimum
 refresh rate.
 That is because if an application does not present soon enough, the display
 hardware will automatically re-display the previous image.
-However, when the display does that, an application cannot present a new image
-for a certain period of time.
+However, when the display does that, an application cannot present a new
+image for a certain period of time.
 It is unclear about whether that period is large enough to cause visual
 artifacts.
 
 
 3) How to deal with changes in timing properties?
 
-*RESOLVED*: The slink:VkPastPresentationTimingPropertiesEXT structure
-that is returned by flink:vkGetPastPresentationTimingEXT contains
-pname:timeDomainsCounter, which is incremented if the time
-domain enabled for the swapchain is not currently available.
+*RESOLVED*: The slink:VkPastPresentationTimingPropertiesEXT structure that
+is returned by flink:vkGetPastPresentationTimingEXT contains
+pname:timeDomainsCounter, which is incremented if the time domain enabled
+for the swapchain is not currently available.
 
 An example of why display timing properties can change is if a surface
-changes from being a window that’s a subset of the display size, to
-becoming full-screen-exclusive.
-While the surface was a subset of the display, a compositor might
-enforce fixed timings on the surface (e.g. FRR of 60Hz), where the
-presentation engine might be free to allow VRR behavior of a
-full-screen-exclusive surface.
+changes from being a window that’s a subset of the display size, to becoming
+full-screen-exclusive.
+While the surface was a subset of the display, a compositor might enforce
+fixed timings on the surface (e.g. FRR of 60Hz), where the presentation
+engine might be free to allow VRR behavior of a full-screen-exclusive
+surface.
 
-It is possible that a full-screen-exclusive window can become
-temporarily obscured (e.g. when a short-term dialog pops up).
-In this case, the surface might use FRR timings while the dialog is
-visible and VRR otherwise.
+It is possible that a full-screen-exclusive window can become temporarily
+obscured (e.g. when a short-term dialog pops up).
+In this case, the surface might use FRR timings while the dialog is visible
+and VRR otherwise.
 
 
-4) One Query for all Timing info vs. an initial query to determine FRR vs. VRR,
-and then FRR-specific vs VRR-specific queries?
+4) One Query for all Timing info vs. an initial query to determine FRR vs.
+VRR, and then FRR-specific vs VRR-specific queries?
 
-*RESOLVED*: Have one query, as described in issue 1, that can be
-called whenever the application needs to obtain the timing properties
-of the surface.
+*RESOLVED*: Have one query, as described in issue 1, that can be called
+whenever the application needs to obtain the timing properties of the
+surface.
 
 
 5) Query to determine time domain?
@@ -164,51 +163,51 @@ Other extensions can add other platform-specific time domains.
 domain; and do allow the special value of zero for targetPresentTime,
 meaning that there is no target.
 
-On some platforms, there is no way to determine the current time, nor
-to determine surface timing properties until after at least one image
-has been presented.
+On some platforms, there is no way to determine the current time, nor to
+determine surface timing properties until after at least one image has been
+presented.
 
-In such cases, the special value of zero allows the application to
-indicate that timing feedback is desired, but that no
-targetPresentTime is requested.
+In such cases, the special value of zero allows the application to indicate
+that timing feedback is desired, but that no targetPresentTime is requested.
 Later, once the application has obtained feedback, it can specify
 targetPresentTime by using the result's actualPresentTime.
 
 
-7) How long before an application’s request for new image duration is honored?
+7) How long before an application’s request for new image duration is
+honored?
 
-*UNRESOLVED*: Apparently, changes to some vendors' display hardware settings do
-not take effect immediately.
-It is not clear what settings, and therefore, it is not clear how to
-address this issue.
+*UNRESOLVED*: Apparently, changes to some vendors' display hardware settings
+do not take effect immediately.
+It is not clear what settings, and therefore, it is not clear how to address
+this issue.
 
 
 8) Do we have a query for the anticipated latency from present to feedback?
 
 *RESOLVED*: Do not provide a query for the feedback latency.
 
 There is some amount of latency from when an application calls
-vkQueuePresentKHR to when the image is displayed to the user, to when feedback
-is available to the application on when the image was actually displayed to the
-user.
+vkQueuePresentKHR to when the image is displayed to the user, to when
+feedback is available to the application on when the image was actually
+displayed to the user.
 The first time (from the call till the image is presented) generally doesn’t
 matter, because the application will likely be providing a targetPresentTime
 (i.e. the application may have some indication for how long this will be).
-However, the latency between targetPresentTime until feedback is available may
-be much longer.
-For example, on Android on the 1st-generation Pixel phone (60Hz FRR display),
-the latency was approximately 5 refresh cycles (83.33ms).
-For higher-frequency displays, the latency may have a larger number of refresh
-cycles.
+However, the latency between targetPresentTime until feedback is available
+may be much longer.
+For example, on Android on the 1st-generation Pixel phone (60Hz FRR
+display), the latency was approximately 5 refresh cycles (83.33ms).
+For higher-frequency displays, the latency may have a larger number of
+refresh cycles.
 
 
 9) Do we have a query(s) about the number of VkPastPresentationTimingEXT
 structs to keep?
 
 *RESOLVED*: Do not provide a query for the number of results the swapchain
 is allowed to store before querying them with
-vkGetPastPresentationTimingEXT. Let the application specify that value with
-a dedicated API.
+vkGetPastPresentationTimingEXT.
+Let the application specify that value with a dedicated API.
 
 
 10) How is the SWAPCHAIN_LOCAL and STAGE_LOCAL time domain used with the

appendices/glossary.adoc

@@ -931,15 +931,16 @@ Image::
 
 ifdef::VK_EXT_present_timing,VK_GOOGLE_display_timing[]
 Image Present Duration::
-    The amount of time the application intends for each
-    newly-presented image to be visible to the user.
+    The amount of time the application intends for each newly-presented
+    image to be visible to the user.
     This value should: be a multiple of the refresh cycle duration.
 
 Image Present Rate::
     The number of newly-presented images the application intends to present
-    each second (a.k.a. frame rate).
-    On fixed refresh rate displays, this value should: be a multiple of
-    the refresh rate.
+    each second (a.k.a.
+    frame rate).
+    On fixed refresh rate displays, this value should: be a multiple of the
+    refresh rate.
 endif::VK_EXT_present_timing,VK_GOOGLE_display_timing[]
 
 Image Subresource::
@@ -1785,7 +1786,8 @@ endif::VK_KHR_video_queue[]
 
 ifdef::VK_EXT_present_timing,VK_GOOGLE_display_timing[]
 Refresh Cycle::
-    The periodic process for updating the contents of the Presentation Engine's display.
+    The periodic process for updating the contents of the Presentation
+    Engine's display.
 
 Refresh Cycle Duration::
     The amount of time from the start of one refresh cycle to the next.

appendices/spirvenv.adoc

@@ -188,6 +188,9 @@ or knowledge of runtime information, such as enabled features.
   * [[VUID-StandaloneSpirv-None-04636]]
     code:Scope for execution must: be limited to code:Workgroup or
     code:Subgroup
+  * [[VUID-{refpage}-Scope-12243]]
+    The code:Scope operand of code:OpTypeCooperativeMatrixKHR must: be
+    limited to code:Workgroup or code:Subgroup
   * [[VUID-StandaloneSpirv-None-04637]]
     If the code:Scope for execution is code:Workgroup, then it must: only be
     used in the task, mesh, tessellation control, or compute
@@ -758,7 +761,7 @@ or knowledge of runtime information, such as enabled features.
     code:OpSetMeshOutputsEXT must: be called before any outputs are written
   * [[VUID-StandaloneSpirv-MeshEXT-07107]]
     In mesh shaders using the code:MeshEXT {ExecutionModel} all variables
-    declared as output must: not be read from
+    declared in the code:Output {StorageClass} must: not be read
   * [[VUID-StandaloneSpirv-MeshEXT-07108]]
     In mesh shaders using the code:MeshEXT {ExecutionModel} for
     code:OpSetMeshOutputsEXT instructions, the "`Vertex Count`" and