KhronosGroup
diff --git a/‎ChangeLog.adoc‎
Lines changed: 80 additions & 0 deletions b/‎ChangeLog.adoc‎
Lines changed: 80 additions & 0 deletions
diff --git a/‎Makefile‎
Lines changed: 1 addition & 1 deletion b/‎Makefile‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎appendices/VK_NV_compute_occupancy_priority.adoc‎
Lines changed: 92 additions & 0 deletions b/‎appendices/VK_NV_compute_occupancy_priority.adoc‎
Lines changed: 92 additions & 0 deletions
diff --git a/‎appendices/spirvenv.adoc‎
Lines changed: 4 additions & 3 deletions b/‎appendices/spirvenv.adoc‎
Lines changed: 4 additions & 3 deletions
@@ -14,6 +14,86 @@ appears frequently in the change log.
 
 '''
 
+Change log for December 12, 2025 Vulkan 1.4.336 spec update:
+
+Github Issues
+
+  * Add a NOTE to the <<interfaces-resources-layout, Offset and Stride
+    (#2627) Assignment>> section linking to a different explanation of the
+    requirements in the Vulkan Guide (public issue 2621).
+  * Change XML `bitvalues` attribute to `requires' for a few 32-bit
+    Vk*FlagBits types (public PR 2624).
+  * Clarify that the VkDeviceDeviceMemoryReportCreateInfoEXT::pUserData
+    pointer passed through callbacks can be NULL in XML and the places in
+    the specification it is specified (Vulkan-ValidationLayers issue 11228).
+
+Internal Issues
+
+  * Make enumerant names in the single-file HTML specification and
+    independent refpage outputs into links to the enumerated type definition
+    they belong to (not done for Antora, yet) (internal issue 4283).
+  * Add Mesh and Task shaders to standalone SPIR-V LocalSize VU 10685
+    (internal issue 4432).
+  * Move VUs requiring image layouts match image usage from common image
+    memory barrier to common image layout section and include them with
+    VkHostImageLayoutTransitionInfo (internal issue 4467).
+  * Clarify the use of extended queues without the corresponding feature
+    enable for VkDeviceQueueCreateInfo (internal issue 4494).
+  * Add a NOTE to vkCmdEndRendering explaining multi-pass ordering
+    considerations (internal issue 4513).
+  * Add ShaderObject maxBoundDescriptorSets VU for VkShaderCreateInfoEXT
+    (internal issue 4518).
+  * Clarify unsized arrays of input attachments in the
+    <<interfaces-inputattachment, Fragment Input Attachment Interface>>
+    section (internal issue 4545).
+  * Add <<descriptorsets-inputattachment, allowed ImageLayout for
+    InputAttachment>> issue 4567).
+  * Restore missing validity include for
+    vkCmdDecompressMemoryIndirectCountNV (internal issue 4514).
+  * Relax phrasing of VK_KHR_suboptimal from "`is returned if an image
+    became available`" to "`may be returned...`" in the discussion of
+    vkAcquireNextImageKHR in the <<wsi-swapchain, WSI Swapchain>> chapter
+    (internal MR 7102).
+  * Add VUs to vkGetQueryPoolResults to check stride only when queryCount >
+    1 (internal MR 7476).
+  * Clarify when scratch data must be valid in VUs for
+    vkBuildAccelerationStructuresKHR, vkBuildMicromapsEXT,
+    VkBuildPartitionedAccelerationStructureInfoNV,
+    VkClusterAccelerationStructureCommandsInfoNV, vkCmdBuildMicromapsEXT,
+    and common build acceleration structure (internal MR 7628).
+  * Specify `optional` XML attributes for VkDeviceAddress members of
+    VkBuildPartitionedAccelerationStructureInfoNV
+    VkClusterAccelerationStructureCommandsInfoNV, allowing them to be zero
+    and update VkClusterAccelerationStructureCommandsInfoNV accordingly
+    (internal MR 7782).
+  * Use new consistent phrasing for buffer usage language consistently in
+    existing VUs (internal MR 7851).
+  * Typo fix to VkDescriptorGetInfoEXT VU 12216 (internal MR 7870).
+  * Fix copy-indirect and create-view interaction with disjoint planes for
+    common VU 07665 and VkImageViewCreateInfo VU 01020 (internal MR 7878).
+  * Remove "`Alternatively, to`" phrasing from vk*2 command descriptions so
+    the corresponding refpages read sensibly in isolation from the vk*non-2
+    command descriptions found immediately above in the full specification
+    (internal MR 7888).
+  * Add dynamic rendering VUs for VK_QCOM_multiview_per_view_viewports
+    equivalent to VkGraphicsPipelineCreateInfo VUs 07730 and 07731 (internal
+    MR 7892).
+  * Cleanup and unify markup style of proposal documents, and remove
+    RESOLVED: from issues since every published proposal should have
+    resolved all issues (internal MR 7899).
+  * Add VkRenderingAttachmentInfo VU to enforce resolveMode !=
+    VK_RESOLVE_MODE_NONE if multisampledRenderToSingleSampledEnable is true
+    (internal MR 7902).
+  * Evaluate complex dependencies in XML at format feature generator
+    runtime, instead of relying on asciidoc which cannot evaluate all such
+    expressions properly (internal MR 7908).
+
+New Extensions
+
+  * VK_NV_compute_occupancy_priority
+
+'''
+
 Change log for November 28, 2025 Vulkan 1.4.335 spec update:
 
 Github Issues
 
@@ -151,7 +151,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 335
+PATCHVERSION = 336
 BASEOPTS     =
 
 ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS)))
 
@@ -0,0 +1,92 @@
+// Copyright 2025 The Khronos Group Inc.
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_NV_compute_occupancy_priority.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2025-12-01
+*Contributors*::
+  - Chris Lentini, NVIDIA
+  - Eric Werness, NVIDIA
+  - Lionel Duc, NVIDIA
+  - Peter Deayton, NVIDIA
+
+=== Description
+
+This extension provides applications with control over how their compute
+workloads utilize GPU compute resources, specifically allowing
+prioritization relative to other simultaneously executing workloads.
+Applications can specify the priority with which compute workloads should
+occupy GPU compute resources, allowing for a fine-grained distinction
+between workloads that may want to execute at a background priority over a
+long period of time versus workloads with harder latency requirements.
+
+The extension introduces a new command
+flink:vkCmdSetComputeOccupancyPriorityNV that allows applications to set the
+occupancy priority for subsequent compute dispatches.
+The occupancy priority affects how compute workloads utilize GPU compute
+resources relative to other simultaneously executing workloads.
+
+The occupancy priority is stateful on a command buffer.
+All commands listed in the <<dispatch, Dispatching Commands>> chapter issued
+subsequent to a flink:vkCmdSetComputeOccupancyPriorityNV call will be
+executed with the specified priority parameters until another
+flink:vkCmdSetComputeOccupancyPriorityNV call is made.
+
+For convenience, three named occupancy priority values are defined:
+
+* **VK_COMPUTE_OCCUPANCY_PRIORITY_LOW_NV** - a constant value that can be
+    used for
+    slink:VkComputeOccupancyPriorityParametersNV::pname:occupancyPriority to
+    specify a low priority level.
+
+* **VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV** - a constant value that can be
+    used for
+    slink:VkComputeOccupancyPriorityParametersNV::pname:occupancyPriority to
+    specify a normal priority level.
+    This represents the default priority level.
+
+* **VK_COMPUTE_OCCUPANCY_PRIORITY_HIGH_NV** - a constant value that can be
+    used for
+    slink:VkComputeOccupancyPriorityParametersNV::pname:occupancyPriority to
+    specify a high priority level.
+
+All command buffers (primary and secondary) start with a priority level
+equal to the VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV value.
+The priority state is not inherited by secondary command buffers - each
+command buffer maintains its own independent priority state.
+
+include::{generated}/interfaces/VK_NV_compute_occupancy_priority.adoc[]
+
+[NOTE]
+====
+The extension only allows specification of occupancy priority for compute
+workloads, however, the priorities will also impact the prioritization of
+compute workloads relative to simultaneously executing graphics workloads.
+In such a scenario, the graphics workload may be thought of as executing at
+VK_COMPUTE_OCCUPANCY_PRIORITY_NORMAL_NV priority, and so a simultaneously
+executing compute workload with VK_COMPUTE_OCCUPANCY_PRIORITY_HIGH_NV
+occupancy priority will preferentially utilize available compute resources.
+====
+
+[NOTE]
+====
+Workloads specified with a higher priority may begin execution after
+workloads specified with a lower priority, at which point they may find GPU
+compute resources already occupied.
+So, while they will from that point forward preferentially occupy available
+compute resources, they may not ramp up to full occupancy until the already
+present lower priority work has reached a point where it can relinquish
+compute resources.
+====
+
+=== Issues
+
+None.
+
+=== Version History
+
+  * Revision 1, 2025-08-06 (Chris Lentini)
+  ** Initial revision
@@ -570,9 +570,10 @@ or knowledge of runtime information, such as enabled features.
     any-hit, closest hit, miss, fragment, vertex, tessellation evaluation,
     or geometry shaders, the execution Scope must: be code:Subgroup
   * [[VUID-StandaloneSpirv-None-10685]]
-    For each compute shader entry point, either a code:TileShadingRateQCOM,
-    code:LocalSize, or code:LocalSizeId {ExecutionMode}, or an object
-    decorated with the code:WorkgroupSize decoration must: be specified
+    Either a code:TileShadingRateQCOM, code:LocalSize, or code:LocalSizeId
+    {ExecutionMode}, or an object decorated with the code:WorkgroupSize
+    decoration must: be specified for each entry point with a task, mesh, or
+    compute {ExecutionModel}
   * [[VUID-StandaloneSpirv-DerivativeGroupQuadsNV-04684]]
     For compute shaders using the code:DerivativeGroupQuadsNV execution
     mode, the first two dimensions of the local workgroup size must: be a