Change log for June 23, 2023 Vulkan 1.3.255 spec update:

Github Issues

  * Fix XML `<format>` metadata for ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32
    and ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16 (public pull requests 2145,
    2147).

Internal Issues

  * Only extract VU statements for the currently built specification,
    allowing placing conditional markup inside VU statements and the
    simplification or elimination of many VUs that previously had to be
    replicated for extension-dependent behavior (internal issue 3387).
  * Add missing Description section to the
    apiext:VK_EXT_swapchain_colorspace extension appendix (internal issue
    3463).
  * Add VU to disable ftext:vkCmdBeginQuery* with micromap queries (internal
    issue 3511).
  * Add apiext:VK_EXT_calibrated_timestamps proposal document, and update
    some of the specification language and notes for
    flink:vkCmdWriteTimestamp2KHR and flink:vkCmdWriteTimestamp (internal
    issue 3521).

New Extensions

  * apiext:VK_KHR_cooperative_matrix

ChangeLog.adoc

@@ -14,6 +14,36 @@ appears frequently in the change log.
 
 -----------------------------------------------------
 
+Change log for June 23, 2023 Vulkan 1.3.255 spec update:
+
+Github Issues
+
+  * Fix XML `<format>` metadata for ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32
+    and ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16 (public pull requests 2145,
+    2147).
+
+Internal Issues
+
+  * Only extract VU statements for the currently built specification,
+    allowing placing conditional markup inside VU statements and the
+    simplification or elimination of many VUs that previously had to be
+    replicated for extension-dependent behavior (internal issue 3387).
+  * Add missing Description section to the
+    apiext:VK_EXT_swapchain_colorspace extension appendix (internal issue
+    3463).
+  * Add VU to disable ftext:vkCmdBeginQuery* with micromap queries (internal
+    issue 3511).
+  * Add apiext:VK_EXT_calibrated_timestamps proposal document, and update
+    some of the specification language and notes for
+    flink:vkCmdWriteTimestamp2KHR and flink:vkCmdWriteTimestamp (internal
+    issue 3521).
+
+New Extensions
+
+  * apiext:VK_KHR_cooperative_matrix
+
+-----------------------------------------------------
+
 Change log for June 16, 2023 Vulkan 1.3.254 spec update:
 
 Github Issues

Makefile

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

appendices/VK_EXT_calibrated_timestamps.adoc

@@ -25,85 +25,6 @@ quasi simultaneously from two time domains.
 
 include::{generated}/interfaces/VK_EXT_calibrated_timestamps.adoc[]
 
-=== Issues
-
-1) Is the device timestamp value returned in the same time domain as the
-timestamp values written by flink:vkCmdWriteTimestamp?
-
-*RESOLVED*: Yes.
-
-2) What time domain is the host timestamp returned in?
-
-*RESOLVED*: A query is provided to determine the calibrateable time domains.
-The expected host time domain used on Windows is that of
-QueryPerformanceCounter, and on Linux that of CLOCK_MONOTONIC.
-
-3) Should we support other time domain combinations than just one host and
-the device time domain?
-
-*RESOLVED*: Supporting that would need the application to query the set of
-supported time domains, while supporting only one host and the device time
-domain would only need a query for the host time domain type.
-The proposed API chooses the general approach for the sake of extensibility.
-
-4) Should we use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC?
-
-*RESOLVED*: CLOCK_MONOTONIC is usable in a wider set of situations, however,
-it is subject to NTP adjustments so some use cases may prefer
-CLOCK_MONOTONIC_RAW.
-Thus this extension allows both to be exposed.
-
-5) How can the application extrapolate future device timestamp values from
-the calibrated timestamp value?
-
-*RESOLVED*: slink:VkPhysicalDeviceLimits::pname:timestampPeriod makes it
-possible to calculate future device timestamps as follows:
-
-[source,c]
-----
-futureTimestamp = calibratedTimestamp + deltaNanoseconds / timestampPeriod
-----
-
-6) In what queue are timestamp values in time domain
-ename:VK_TIME_DOMAIN_DEVICE_EXT captured by
-flink:vkGetCalibratedTimestampsEXT?
-
-*RESOLVED*: An implementation supporting this extension will have all its
-VkQueue share the same time domain.
-
-6) Can the host and device timestamp values drift apart over longer periods
-of time?
-
-*RESOLVED*: Yes, especially as some time domains by definition allow for
-that to happen (e.g. CLOCK_MONOTONIC is subject to NTP adjustments).
-Thus it is recommended that applications re-calibrate from time to time.
-
-7) Should we add a query for reporting the maximum deviation of the
-timestamp values returned by calibrated timestamp queries?
-
-*RESOLVED*: A global query seems inappropriate and difficult to enforce.
-However, it is possible to return the maximum deviation any single
-calibrated timestamp query can have by sampling one of the time domains
-twice as follows:
-
-[source,c]
-----
-timestampX = timestampX_before = SampleTimeDomain(X)
-for each time domain Y != X
-    timestampY = SampleTimeDomain(Y)
-timestampX_after = SampleTimeDomain(X)
-maxDeviation = timestampX_after - timestampX_before
-----
-
-8) Can the maximum deviation reported ever be zero?
-
-*RESOLVED*: Unless the tick of each clock corresponding to the set of time
-domains coincides and all clocks can literally be sampled simultaneously,
-there is not really a possibility for the maximum deviation to be zero, so
-by convention the maximum deviation is always at least the maximum of the
-length of the ticks of the set of time domains calibrated and thus can never
-be zero.
-
 === Version History
 
   * Revision 2, 2021-03-16 (Lionel Landwerlin)

appendices/VK_EXT_swapchain_colorspace.adoc

@@ -15,7 +15,11 @@ include::{generated}/meta/{refprefix}VK_EXT_swapchain_colorspace.adoc[]
 
 === Description
 
-To be done.
+This extension expands elink:VkColorSpaceKHR to add support for most
+standard color spaces beyond ename:VK_COLOR_SPACE_SRGB_NONLINEAR_KHR.
+This extension also adds support for ename:VK_COLOR_SPACE_PASS_THROUGH_EXT
+which allows applications to use color spaces not explicitly enumerated in
+elink:VkColorSpaceKHR.
 
 include::{generated}/interfaces/VK_EXT_swapchain_colorspace.adoc[]
 

appendices/VK_KHR_cooperative_matrix.adoc

@@ -0,0 +1,53 @@
+// Copyright (c) 2021-2023 The Khronos Group, Inc.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_KHR_cooperative_matrix.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2023-05-03
+*Interactions and External Dependencies*::
+  - This extension requires
+    {spirv}/KHR/SPV_KHR_cooperative_matrix.html[`SPV_KHR_cooperative_matrix`]
+  - This extension provides API support for
+    {GLSLregistry}/khr/GL_KHR_cooperative_matrix.txt[`GL_KHR_cooperative_matrix`]
+*Contributors*::
+  - Jeff Bolz, NVIDIA
+  - Markus Tavenrath, NVIDIA
+  - Daniel Koch, NVIDIA
+  - Kevin Petit, Arm Ltd.
+  - Boris Zanin, AMD
+
+=== Description
+
+This extension adds support for using cooperative matrix types in SPIR-V.
+Cooperative matrix types are medium-sized matrices that are primarily
+supported in compute shaders, where the storage for the matrix is spread
+across all invocations in some scope (usually a subgroup) and those
+invocations cooperate to efficiently perform matrix multiplies.
+
+Cooperative matrix types are defined by the
+{spirv}/KHR/SPV_KHR_cooperative_matrix.html[`SPV_KHR_cooperative_matrix`]
+SPIR-V extension and can be used with the
+{GLSLregistry}/khr/GL_KHR_cooperative_matrix.txt[`GL_KHR_cooperative_matrix`]
+GLSL extension.
+
+This extension includes support for enumerating the matrix types and
+dimensions that are supported by the implementation.
+
+include::{generated}/interfaces/VK_KHR_cooperative_matrix.adoc[]
+
+=== New SPIR-V Capabilities
+
+  * <<spirvenv-capabilities-table-CooperativeMatrixKHR,CooperativeMatrixKHR>>
+
+=== Issues
+
+=== Version History
+
+  * Revision 2, 2023-05-03 (Kevin Petit)
+  ** First KHR revision
+  * Revision 1, 2019-02-05 (Jeff Bolz)
+  ** NVIDIA vendor extension

appendices/glossary.adoc

@@ -289,11 +289,11 @@ Constant Integral Expressions::
     See _Constant Instruction_ in section 2.2.1 "`Instructions`" of the
     <<spirv-spec,Khronos SPIR-V Specification>>.
 
-ifdef::VK_NV_cooperative_matrix[]
+ifdef::VK_NV_cooperative_matrix,VK_KHR_cooperative_matrix[]
 Cooperative Matrix::
     A SPIR-V type where the storage for and computations performed on the
     matrix are spread across a set of invocations such as a subgroup.
-endif::VK_NV_cooperative_matrix[]
+endif::VK_NV_cooperative_matrix,VK_KHR_cooperative_matrix[]
 
 ifdef::VK_NV_corner_sampled_image[]
 Corner-Sampled Image::

appendices/spirvenv.adoc

@@ -686,6 +686,11 @@ or knowledge of runtime information, such as enabled features.
   * [[VUID-{refpage}-None-08724]]
     The code:TileImageEXT {StorageClass} must: only be used for declaring
     tile image variables.
+  * [[VUID-{refpage}-Pointer-08973]]
+    The {StorageClass} of the code:Pointer operand to
+    code:OpCooperativeMatrixLoadKHR or code:OpCooperativeMatrixStoreKHR
+    must: be limited to code:Workgroup, code:CrossWorkgroup,
+    code:StorageBuffer, or code:PhysicalStorageBuffer.
 ****
 --
 
@@ -759,15 +764,15 @@ ifdef::VK_KHR_format_feature_flags2[]
   * [[VUID-{refpage}-apiVersion-07954]]
     If slink:VkPhysicalDeviceProperties::pname:apiVersion is less than
     Vulkan 1.3, the apiext:VK_KHR_format_feature_flags2 extension is not
-    enabled, and <<features-shaderStorageImageWriteWithoutFormat,
+    supported, and <<features-shaderStorageImageWriteWithoutFormat,
     pname:shaderStorageImageWriteWithoutFormat>> is not enabled, any
     variable created with a "`Type`" of code:OpTypeImage that has a
     "`Sampled`" operand of 2 and an "`Image Format`" operand of code:Unknown
     must: be decorated with code:NonWritable
   * [[VUID-{refpage}-apiVersion-07955]]
     If slink:VkPhysicalDeviceProperties::pname:apiVersion is less than
     Vulkan 1.3, the apiext:VK_KHR_format_feature_flags2 extension is not
-    enabled, and <<features-shaderStorageImageReadWithoutFormat,
+    supported, and <<features-shaderStorageImageReadWithoutFormat,
     pname:shaderStorageImageReadWithoutFormat>> is not enabled, any variable
     created with a "`Type`" of code:OpTypeImage that has a "`Sampled`"
     operand of 2 and an "`Image Format`" operand of code:Unknown must: be
@@ -1121,6 +1126,65 @@ ifdef::VK_NV_cooperative_matrix[]
     instructions must: not be used in shader stages not included in
     slink:VkPhysicalDeviceCooperativeMatrixPropertiesNV::pname:cooperativeMatrixSupportedStages
 endif::VK_NV_cooperative_matrix[]
+ifdef::VK_KHR_cooperative_matrix[]
+  * [[VUID-{refpage}-OpTypeCooperativeMatrixKHR-]]
+    For code:OpTypeCooperativeMatrixKHR, the component type, scope, number
+    of rows, and number of columns must: match one of the matrices in any of
+    the supported slink:VkCooperativeMatrixPropertiesKHR.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the type of code:A must: have
+    slink:VkCooperativeMatrixPropertiesKHR::pname:MSize rows and
+    slink:VkCooperativeMatrixPropertiesKHR::pname:KSize columns and have a
+    component type that matches
+    slink:VkCooperativeMatrixPropertiesKHR::pname:AType.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, when the component type of code:A
+    is a signed integer type, the code:MatrixASignedComponents cooperative
+    matrix operand must: be present.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the type of code:B must: have
+    slink:VkCooperativeMatrixPropertiesKHR::pname:KSize rows and
+    slink:VkCooperativeMatrixPropertiesKHR::pname:NSize columns and have a
+    component type that matches
+    slink:VkCooperativeMatrixPropertiesKHR::pname:BType.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, when the component type of code:B
+    is a signed integer type, the code:MatrixBSignedComponents cooperative
+    matrix operand must: be present.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the type of code:C must: have
+    slink:VkCooperativeMatrixPropertiesKHR::pname:MSize rows and
+    slink:VkCooperativeMatrixPropertiesKHR::pname:NSize columns and have a
+    component type that matches
+    slink:VkCooperativeMatrixPropertiesKHR::pname:CType.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, when the component type of code:C
+    is a signed integer type, the code:MatrixCSignedComponents cooperative
+    matrix operand must: be present.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the type of code:Result must:
+    have slink:VkCooperativeMatrixPropertiesKHR::pname:MSize rows and
+    slink:VkCooperativeMatrixPropertiesKHR::pname:NSize columns and have a
+    component type that matches
+    slink:VkCooperativeMatrixPropertiesKHR::pname:ResultType.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, when the component type of
+    code:Result is a signed integer type, the
+    code:MatrixResultSignedComponents cooperative matrix operand must: be
+    present.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the code:SaturatingAccumulation
+    cooperative matrix operand must: be present if and only if
+    slink:VkCooperativeMatrixPropertiesKHR::pname:saturatingAccumulation is
+    ename:VK_TRUE.
+  * [[VUID-{refpage}-OpCooperativeMatrixMulAddKHR-]]
+    For code:OpCooperativeMatrixMulAddKHR, the type of code:A, code:B,
+    code:C, and code:Result must: all have a scope of pname:scope.
+  * [[VUID-{refpage}-OpTypeCooperativeMatrixKHR-]]
+    code:OpTypeCooperativeMatrixKHR and code:OpCooperativeMatrix*
+    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
@@ -1269,6 +1333,15 @@ ifdef::VK_EXT_mesh_shader[]
     or equal to <<limits-maxTaskPayloadAndSharedMemorySize,
     pname:maxTaskPayloadAndSharedMemorySize>>
 endif::VK_EXT_mesh_shader[]
+ifdef::VK_KHR_cooperative_matrix[]
+  * [[VUID-{refpage}-OpCooperativeMatrixLoadKHR-]]
+    For code:OpCooperativeMatrixLoadKHR and code:OpCooperativeMatrixStoreKHR
+    instructions, the code:Pointer and code:Stride operands must: be aligned
+    to at least the lesser of 16 bytes or the natural alignment of a row or
+    column (depending on code:ColumnMajor) of the matrix (where the natural
+    alignment is the number of columns/rows multiplied by the component
+    size).
+endif::VK_KHR_cooperative_matrix[]
 ifdef::VK_KHR_portability_subset[]
   * [[VUID-{refpage}-shaderSampleRateInterpolationFunctions-06325]]
     If the `apiext:VK_KHR_portability_subset` extension is enabled, and
@@ -2319,6 +2392,10 @@ code:OpCooperativeMatrixMulAddNV performs its operations in an
 implementation-dependent order and internal precision.
 endif::VK_NV_cooperative_matrix[]
 
+ifdef::VK_KHR_cooperative_matrix[]
+code:OpCooperativeMatrixMulAddKHR performs its operations in an
+implementation-dependent order and internal precision.
+endif::VK_KHR_cooperative_matrix[]
 
 [[spirvenv-image-signedness]]
 == Signedness of SPIR-V Image Accesses

chapters/VK_KHR_swapchain/wsi.adoc

@@ -1351,11 +1351,13 @@ endif::VK_KHR_display_swapchain[]
     by the elements of the pname:pWaitSemaphores member of
     pname:pPresentInfo executes on pname:queue, there must: be no other
     queues waiting on the same semaphore
+ifndef::VK_VERSION_1_2,VK_KHR_timeline_semaphore[]
   * [[VUID-vkQueuePresentKHR-pWaitSemaphores-01295]]
     All elements of the pname:pWaitSemaphores member of pname:pPresentInfo
     must: be semaphores that are signaled, or have
     <<synchronization-semaphores-signaling, semaphore signal operations>>
     previously submitted for execution
+endif::VK_VERSION_1_2,VK_KHR_timeline_semaphore[]
 ifdef::VK_VERSION_1_2,VK_KHR_timeline_semaphore[]
   * [[VUID-vkQueuePresentKHR-pWaitSemaphores-03267]]
     All elements of the pname:pWaitSemaphores member of pname:pPresentInfo
@@ -1364,8 +1366,9 @@ ifdef::VK_VERSION_1_2,VK_KHR_timeline_semaphore[]
   * [[VUID-vkQueuePresentKHR-pWaitSemaphores-03268]]
     All elements of the pname:pWaitSemaphores member of pname:pPresentInfo
     must: reference a semaphore signal operation that has been submitted for
-    execution and any semaphore signal operations on which it depends (if
-    any) must: have also been submitted for execution
+    execution and any <<synchronization-semaphores-signaling, semaphore
+    signal operations>> on which it depends (if any) must: have also been
+    submitted for execution
 endif::VK_VERSION_1_2,VK_KHR_timeline_semaphore[]
 ****