Change log for June 9, 2022 Vulkan 1.3.217 spec update:

  * Update release number to 217 for this update.

Public Issues:

  * Clarify meaning of "`private data slot`" for apiext:VK_EXT_private_data
    (public issue 1675)
  * Minor markup fix in the <<spirvenv-module-validation-standalone>>
    section (public merge request 1864).

Internal Issues:

  * Clarify that <<primsrast-sampleshading, Sample Shading>> affects the
    number of times the fragment shader is evaluated, rather than dictating
    fragment data (internal issue 3003).
  * Clarify interaction of the
    slink:VkPhysicalDeviceLimits::pname:strictLines limit with
    apiext:VK_EXT_line_rasterization in
    slink:VkPhysicalDeviceLineRasterizationFeaturesEXT and the
    <<line_linear_interpolation>> section (internal issue 3042).
  * Clarify that code:EarlyFragmentTests allows for sample counting after
    fragment shading and multisample coverage in the introduction to the
    <<fragops, Fragment Operations>> chapter (internal issue 3085).
  * Update description of ray tracing <<features-requirements Feature
    Requirements>> for consistency and to remove redundancy. Add an issue to
    apiext:VK_KHR_ray_tracing_pipeline explaining why
    apiext:VK_KHR_pipeline_library is an interaction, rather than a required
    dependency. (internal issue 3103).
  * Define alignment requirements for matrices in terms of arrays.
    in the <<interfaces-alignment-requirements,
    Alignment Requirements>> section
    (internal issue 3105).
  * Add valid usage statements for code:StorageBuffer and code:Uniform
    code:PushConstant types to the <<spirvenv-module-validation-standalone,
    Standalone SPIR-V Validation>> section (internal merge request 5080).
  * Fix conditional markup interaction for
    apiext:VK_KHR_depth_stencil_resolve and apiext:VK_KHR_dynamic_rendering
    in slink:VkRenderingInfo and slink:VkRenderingAttachmentInfo valid usage
    statements, now that apiext:VK_KHR_dynamic_rendering requires
    apiext:VK_KHR_depth_stencil_resolve (internal merge request 5224).
  * Clarify dependencies and fix broken chapter links for
    apiext:VK_ARM_rasterization_order (internal merge request 5229).
  * Add a valid usage statement to flink:vkCmdEndRendering to disallow
    calling it when transform feedback is active (internal merge request
    5230).
  * Update reference to a style guide chapter (internal merge request 5231).
  * Clarify that slink:VkExportMemoryAllocateInfo::pname:handleTypes can be
    zero in spec description, matching XML and other pname:handleType
    members (internal merge request 5234).

New Extensions:

  * apiext:VK_EXT_metal_objects
  * apiext:VK_EXT_non_seamless_cube_map

ChangeLog.txt

@@ -11,6 +11,64 @@ public pull requests that have been accepted.
 
 -----------------------------------------------------
 
+Change log for June 9, 2022 Vulkan 1.3.217 spec update:
+
+  * Update release number to 217 for this update.
+
+Public Issues:
+
+  * Clarify meaning of "`private data slot`" for apiext:VK_EXT_private_data
+    (public issue 1675)
+  * Minor markup fix in the <<spirvenv-module-validation-standalone>>
+    section (public merge request 1864).
+
+Internal Issues:
+
+  * Clarify that <<primsrast-sampleshading, Sample Shading>> affects the
+    number of times the fragment shader is evaluated, rather than dictating
+    fragment data (internal issue 3003).
+  * Clarify interaction of the
+    slink:VkPhysicalDeviceLimits::pname:strictLines limit with
+    apiext:VK_EXT_line_rasterization in
+    slink:VkPhysicalDeviceLineRasterizationFeaturesEXT and the
+    <<line_linear_interpolation>> section (internal issue 3042).
+  * Clarify that code:EarlyFragmentTests allows for sample counting after
+    fragment shading and multisample coverage in the introduction to the
+    <<fragops, Fragment Operations>> chapter (internal issue 3085).
+  * Update description of ray tracing <<features-requirements Feature
+    Requirements>> for consistency and to remove redundancy. Add an issue to
+    apiext:VK_KHR_ray_tracing_pipeline explaining why
+    apiext:VK_KHR_pipeline_library is an interaction, rather than a required
+    dependency. (internal issue 3103).
+  * Define alignment requirements for matrices in terms of arrays.
+    in the <<interfaces-alignment-requirements,
+    Alignment Requirements>> section
+    (internal issue 3105).
+  * Add valid usage statements for code:StorageBuffer and code:Uniform
+    code:PushConstant types to the <<spirvenv-module-validation-standalone,
+    Standalone SPIR-V Validation>> section (internal merge request 5080).
+  * Fix conditional markup interaction for
+    apiext:VK_KHR_depth_stencil_resolve and apiext:VK_KHR_dynamic_rendering
+    in slink:VkRenderingInfo and slink:VkRenderingAttachmentInfo valid usage
+    statements, now that apiext:VK_KHR_dynamic_rendering requires
+    apiext:VK_KHR_depth_stencil_resolve (internal merge request 5224).
+  * Clarify dependencies and fix broken chapter links for
+    apiext:VK_ARM_rasterization_order (internal merge request 5229).
+  * Add a valid usage statement to flink:vkCmdEndRendering to disallow
+    calling it when transform feedback is active (internal merge request
+    5230).
+  * Update reference to a style guide chapter (internal merge request 5231).
+  * Clarify that slink:VkExportMemoryAllocateInfo::pname:handleTypes can be
+    zero in spec description, matching XML and other pname:handleType
+    members (internal merge request 5234).
+
+New Extensions:
+
+  * apiext:VK_EXT_metal_objects
+  * apiext:VK_EXT_non_seamless_cube_map
+
+-----------------------------------------------------
+
 Change log for June 2, 2022 Vulkan 1.3.216 spec update:
 
   * Update release number to 216 for this update.

Makefile

@@ -128,7 +128,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 216
+PATCHVERSION = 217
 
 ifneq (,$(findstring VK_VERSION_1_3,$(VERSIONS)))
 SPECMINOR = 3

appendices/VK_EXT_metal_objects.txt

@@ -0,0 +1,48 @@
+// Copyright (c) 2021-2022 The Brenwill Workshop Ltd.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_EXT_metal_objects.txt[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2022-05-28
+*IP Status*::
+    No known IP claims.
+*Contributors*::
+  - Bill Hollings, The Brenwill Workshop Ltd.
+  - Dzmitry Malyshau, Mozilla Corp.
+
+=== Description
+
+In a Vulkan implementation that is layered on top of Metal on Apple device
+platforms, this extension provides the ability to import and export the
+underlying Metal objects associated with specific Vulkan objects.
+
+As detailed in the
+https://github.com/KhronosGroup/Vulkan-Docs/tree/main/proposals/VK_EXT_metal_objects.asciidoc[extension
+proposal document], this extension adds one new Vulkan command,
+flink:vkExportMetalObjectsEXT, to export underlying Metal objects from
+Vulkan objects, and supports importing the appropriate existing Metal
+objects when creating Vulkan objects of types slink:VkDeviceMemory,
+slink:VkImage, slink:VkSemaphore, and slink:VkEvent,
+
+The intent is that this extension will be advertised and supported only on
+implementations that are layered on top of Metal on Apple device platforms.
+
+include::{generated}/interfaces/VK_EXT_metal_objects.txt[]
+
+=== Issues
+
+None.
+
+=== Version History
+
+ * Revision 1, 2022-05-28 (Bill Hollings)
+   - Initial draft.
+   - Incorported feedback from review by the Vulkan Working Group.
+     Renamed many structures, moved import/export of MTLBuffer to
+     VkDeviceMemory, added export of MTLSharedEvent, added import of
+     MTLSharedEvent for VkSemaphore and VkEvent, and changed used bit mask
+     fields to individual bit fields to simplify Valid Usage rules.

appendices/VK_EXT_non_seamless_cube_map.txt

@@ -15,8 +15,9 @@ include::{generated}/meta/{refprefix}VK_EXT_non_seamless_cube_map.txt[]
 
 === Description
 
-This extension provides functionality to disable <<textures-cubemapedge, cube map edge handling>>
-on a per sampler level which matches the behavior of other graphics APIs.
+This extension provides functionality to disable <<textures-cubemapedge,
+cube map edge handling>> on a per sampler level which matches the behavior
+of other graphics APIs.
 
 This extension may be useful for building translation layers for those APIs
 or for porting applications that rely on this cube map behavior.

appendices/VK_EXT_post_depth_coverage.txt

@@ -33,8 +33,7 @@ code:SampleMaskPostDepthCoverage capability.
 When this mode is specified along with code:EarlyFragmentTests, the value of
 an input variable decorated with the
 <<interfaces-builtin-variables-samplemask, code:SampleMask>> built-in
-reflects the coverage after the <<shaders-fragment-earlytest, early fragment
-tests>> are applied.
+reflects the coverage after the early fragment tests are applied.
 Otherwise, it reflects the coverage before the depth and stencil tests.
 
 When using GLSL source-based shading languages, the code:post_depth_coverage

appendices/VK_EXT_private_data.txt

@@ -43,6 +43,30 @@ the core functionality.
 
   * In progress
 
+=== Issues
+
+(1) If I have to create a slink:VkPrivateDataSlot to store and retrieve data
+on an object, how does this extension help me? Will I not need to store the
+slink:VkPrivateDataSlot mapping with each object, and if I am doing that, I
+might as well just store the original data!
+--
+**RESOLVED:** The slink:VkPrivateDataSlot can be thought of as an opaque
+index into storage that is reserved in each object.
+That is, you can use the same slink:VkPrivateDataSlot with each object for a
+specific piece of information.
+For example, if a layer wishes to track per-object information, the layer
+only needs to allocate one slink:VkPrivateDataSlot per device and it can use
+that private data slot for all of the device's child objects.
+This allows multiple layers to store private data without conflicting with
+each other's and/or the application's private data.
+--
+
+(2) What if I need to store more than 64-bits of information per object?
+--
+**RESOLVED:** The data that you store per object could be a pointer to
+another object or structure of your own allocation.
+--
+
 === Version History
 
  * Revision 1, 2020-01-15 (Matthew Rusch)

appendices/VK_KHR_ray_tracing_pipeline.txt

@@ -317,6 +317,19 @@ There are two main reasons for the difference here:
     it more obvious that this is zero-based.
 --
 
+(6) Why is `apiext:VK_KHR_pipeline_library` an interaction instead of a
+    required dependency, particularly when the "Feature Requirements"
+    section says it is required to be supported anyhow?
+--
+*RESOLVED*: If `apiext:VK_KHR_pipeline_library` were a required extension
+dependency, then every application would need to enable the 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.
+--
+
+
 === Sample Code
 
 Example ray generation GLSL shader

appendices/spirvenv.txt

@@ -214,6 +214,12 @@ endif::VK_VERSION_1_1[]
     Any variable in the code:UniformConstant storage class must: be typed as
     either code:OpTypeImage, code:OpTypeSampler, code:OpTypeSampledImage,
     code:OpTypeAccelerationStructureKHR, or an array of one of these types
+  * [[VUID-{refpage}-Uniform-06807]]
+    Any variable in the code:Uniform or code:StorageBuffer storage class
+    must: be typed as code:OpTypeStruct or an array of this type
+  * [[VUID-{refpage}-PushConstant-06808]]
+    Any variable in the code:PushConstant storage class must: be typed as
+    code:OpTypeStruct
   * [[VUID-{refpage}-OpTypeImage-04656]]
     code:OpTypeImage must: declare a scalar 32-bit float, 64-bit integer, or
     32-bit integer type for the "`Sampled Type`" (code:RelaxedPrecision can:
@@ -515,8 +521,9 @@ endif::VK_VERSION_1_1[]
     code:OpTypeForwardPointer must: have a storage class of
     code:PhysicalStorageBuffer
   * [[VUID-{refpage}-None-04745]]
-    All variables with a storage class of *PushConstant* declared as an
-    array must: only be accessed by dynamically uniform indices
+    All block members in a variable with a storage class of *PushConstant*
+    declared as an array must: only be accessed by dynamically uniform
+    indices
   * [[VUID-{refpage}-OpVariable-06673]]
     There must: not be more than one code:OpVariable in the
     code:PushConstant storage class listed in the code:Interface for each