Change log for March 1, 2024 Vulkan 1.3.279 spec update:

Public Issues

  * Add a NOTE to the VK_IMG_format_pvrtc extension appendix specifying that
    PVRTC1 images must have power of two dimensions, and a corresponding VU
    to VkImageCreateInfo (public issue 1991).
  * Remove BETA ifdefs from video enums (public issue 2314).

Internal Issues

  * Clarify using multiple dynamic state to set vertex stride in the
    <<fxvertex-input-address-calculation, Vertex Input Address Calculation>>
    section (internal issue 3381).
  * Specify that reinterpreting images with unused format bits returns
    undefined values in the <<textures-operation-validation,
    Instruction/Sampler/Image View Validation>> and
    <<textures-output-format-conversion, Texel Output Format Conversion>>
    sections (internal issue 3591).
  * Remove redundant VkGraphicsPipelineCreateInfo multiView VUs (internal
    issue 3662).
  * Ensure that created descriptor set layouts are supported in
    vkCreateDescriptorSetLayout (internal issue 3676).
  * Clarify vkGetRenderingAreaGranularityKHR recommendations for optimal
    renderArea (internal issue 3702).
  * Fix link typo in vkRenderingFragmentDensityMapAttachmentInfoEXT
    multiview VU 07908 (internal issue 3714).
  * Tighten <<formats-without-shader-storage-format, Formats Without Shader
    Storage Format>> language regarding storage format support (internal
    issue 3777).
  * Clarify that VkPhysicalDeviceDriverProperties::conformanceVersion
    identifies the most recent version of CTS successfully passed (as
    opposed to requiring the driver to have passed a one-month review period
    and have been officially labelled conformant by the Vulkan working
    group) (internal issue 3780).
  * Provide more detailed description for VK_FORMAT_R16G16_S10_5_NV
    (internal issue 3788).
  * Fix swapped FeatureEnabled indices in the <<decode-av1-picture-info, Std
    Picture Information>> section (internal issue 3793).
  * Improve proposal template and style guide to clarify that the
    specification custom asciidoctor macros are not available in proposal
    documents (internal issue 3808).
  * Improvements and fixes for VK_NV_device_generated_commands_compute
    (internal MR 6410).
  * Fix parameter name typo in vkCmdControlVideoCodingKHR VU 08243 (internal
    MR 6426).
  * Clarify the default values of render pass mappings for
    vkCmdSetRenderingAttachmentLocationsKHR and
    VkRenderingInputAttachmentIndexInfoKHR (internal MR 6469).
  * Fix param name typo in VkRenderingFragmentDensityMapAttachmentInfoEXT VU
    06157 (internal MR 6483).
  * Fix VkMutableDescriptorTypeCreateInfoEXT ->
    VkMutableDescriptorTypeListEXT typo in the <<descriptorsets-mutable,
    Mutable>> introduction (internal MR 6484).
  * Fix VkGraphicsPipelineCreateInfo VU 08899 to refer to vertex input,
    rather than pre-rasterization state (internal MR 6501).
  * Add missing `type` attribute to some AV1 `<enum>` tags in `video.xml`
    (internal MR 6506).
  * Fix styleguide example markup that did not escape ifdef and endif macros
    (internal MR 6506).
  * Add a missing common pipeline barrier VU, and move the "`Explicit Render
    Pass Tile Image Access Synchronization`" section to the
    VK_EXT_shader_tile_image proposal document (internal MR 6510).

New Extensions

  * VK_NV_raw_access_chains

32 files changed, 438 insertions, 170 deletions

diff --git a/ChangeLog.adoc b/ChangeLog.adoc
index 61cbaac0..545b76e8 100644
--- a/ChangeLog.adoc
+++ b/ChangeLog.adoc
@@ -14,6 +14,76 @@ appears frequently in the change log.
 
 -----------------------------------------------------
 
+Change log for March 1, 2024 Vulkan 1.3.279 spec update:
+
+Public Issues
+
+  * Add a NOTE to the VK_IMG_format_pvrtc extension appendix specifying that
+    PVRTC1 images must have power of two dimensions, and a corresponding VU
+    to VkImageCreateInfo (public issue 1991).
+  * Remove BETA ifdefs from video enums (public issue 2314).
+
+Internal Issues
+
+  * Clarify using multiple dynamic state to set vertex stride in the
+    <<fxvertex-input-address-calculation, Vertex Input Address Calculation>>
+    section (internal issue 3381).
+  * Specify that reinterpreting images with unused format bits returns
+    undefined values in the <<textures-operation-validation,
+    Instruction/Sampler/Image View Validation>> and
+    <<textures-output-format-conversion, Texel Output Format Conversion>>
+    sections (internal issue 3591).
+  * Remove redundant VkGraphicsPipelineCreateInfo multiView VUs (internal
+    issue 3662).
+  * Ensure that created descriptor set layouts are supported in
+    vkCreateDescriptorSetLayout (internal issue 3676).
+  * Clarify vkGetRenderingAreaGranularityKHR recommendations for optimal
+    renderArea (internal issue 3702).
+  * Fix link typo in vkRenderingFragmentDensityMapAttachmentInfoEXT
+    multiview VU 07908 (internal issue 3714).
+  * Tighten <<formats-without-shader-storage-format, Formats Without Shader
+    Storage Format>> language regarding storage format support (internal
+    issue 3777).
+  * Clarify that VkPhysicalDeviceDriverProperties::conformanceVersion
+    identifies the most recent version of CTS successfully passed (as
+    opposed to requiring the driver to have passed a one-month review period
+    and have been officially labelled conformant by the Vulkan working
+    group) (internal issue 3780).
+  * Provide more detailed description for VK_FORMAT_R16G16_S10_5_NV
+    (internal issue 3788).
+  * Fix swapped FeatureEnabled indices in the <<decode-av1-picture-info, Std
+    Picture Information>> section (internal issue 3793).
+  * Improve proposal template and style guide to clarify that the
+    specification custom asciidoctor macros are not available in proposal
+    documents (internal issue 3808).
+  * Improvements and fixes for VK_NV_device_generated_commands_compute
+    (internal MR 6410).
+  * Fix parameter name typo in vkCmdControlVideoCodingKHR VU 08243 (internal
+    MR 6426).
+  * Clarify the default values of render pass mappings for
+    vkCmdSetRenderingAttachmentLocationsKHR and
+    VkRenderingInputAttachmentIndexInfoKHR (internal MR 6469).
+  * Fix param name typo in VkRenderingFragmentDensityMapAttachmentInfoEXT VU
+    06157 (internal MR 6483).
+  * Fix VkMutableDescriptorTypeCreateInfoEXT ->
+    VkMutableDescriptorTypeListEXT typo in the <<descriptorsets-mutable,
+    Mutable>> introduction (internal MR 6484).
+  * Fix VkGraphicsPipelineCreateInfo VU 08899 to refer to vertex input,
+    rather than pre-rasterization state (internal MR 6501).
+  * Add missing `type` attribute to some AV1 `<enum>` tags in `video.xml`
+    (internal MR 6506).
+  * Fix styleguide example markup that did not escape ifdef and endif macros
+    (internal MR 6506).
+  * Add a missing common pipeline barrier VU, and move the "`Explicit Render
+    Pass Tile Image Access Synchronization`" section to the
+    VK_EXT_shader_tile_image proposal document (internal MR 6510).
+
+New Extensions
+
+  * VK_NV_raw_access_chains
+
+-----------------------------------------------------
+
 Change log for February 16, 2024 Vulkan 1.3.278 spec update:
 
 Public Issues
diff --git a/Makefile b/Makefile
index 2bbd0b29..ffbbb42f 100644
--- a/Makefile
+++ b/Makefile
@@ -137,7 +137,7 @@ VERBOSE =
 # ADOCOPTS options for asciidoc->HTML5 output
 
 NOTEOPTS     = -a editing-notes -a implementation-guide
-PATCHVERSION = 278
+PATCHVERSION = 279
 BASEOPTS     =
 
 ifneq (,$(findstring VKSC_VERSION_1_0,$(VERSIONS)))
diff --git a/antora/Makefile b/antora/Makefile
index ce41744b..d922d153 100644
--- a/antora/Makefile
+++ b/antora/Makefile
@@ -61,7 +61,7 @@ setup_proposals: proposal_nav
 # Construct the proposals nav.adoc from the current list of
 # proposals, so it remains up to date.
 # This could be merged into antora-prep.py but is very specific
-# to the proposals so that's pointless.
+# to the proposals so that is pointless.
 proposal_nav:
 	scripts/antora-nav-proposals.py \
 	    -root . \
diff --git a/appendices/VK_IMG_format_pvrtc.adoc b/appendices/VK_IMG_format_pvrtc.adoc
index 13e579e2..a708abad 100644
--- a/appendices/VK_IMG_format_pvrtc.adoc
+++ b/appendices/VK_IMG_format_pvrtc.adoc
@@ -19,6 +19,13 @@ include::{generated}/meta/{refprefix}VK_IMG_format_pvrtc.adoc[]
 specific to Imagination Technologies PowerVR Texture compression format
 (called PVRTC).
 
+[NOTE]
+.Note
+====
+As also noted in the <<data-format, Khronos Data Format Specification>>,
+PVRTC1 images must have dimensions that are a power of two.
+====
+
 === Deprecation
 
 Both PVRTC1 and PVRTC2 are slower than standard image formats on PowerVR
diff --git a/appendices/VK_NV_raw_access_chains.adoc b/appendices/VK_NV_raw_access_chains.adoc
new file mode 100644
index 00000000..e31f0ac1
--- /dev/null
+++ b/appendices/VK_NV_raw_access_chains.adoc
@@ -0,0 +1,33 @@
+// Copyright 2024 The Khronos Group, Inc.
+//
+// SPDX-License-Identifier: CC-BY-4.0
+
+include::{generated}/meta/{refprefix}VK_NV_raw_access_chains.adoc[]
+
+=== Other Extension Metadata
+
+*Last Modified Date*::
+    2023-12-04
+*Interactions and External Dependencies*::
+  - This extension requires
+    {spirv}/NV/SPV_NV_raw_access_chains.html[`SPV_NV_raw_access_chains`]
+*Contributors*::
+  - Hans-Kristian Arntzen, Valve
+  - Rodrigo Locatti, NVIDIA
+
+=== Description
+
+This extension allows the use of the `SPV_NV_raw_access_chains` extension in
+SPIR-V shader modules.
+This enables SPIR-V producers to efficiently implement interfaces similar to
+Direct3D structured buffers and byte address buffers, allowing shaders
+compiled from an HLSL source to generate more efficient code.
+
+=== New SPIR-V Capabilities
+
+  * <<spirvenv-capabilities-table-RawAccessChainsNV,RawAccessChainsNV>>
+
+=== Version History
+
+  * Revision 1, 2023-12-04 (Rodrigo Locatti)
+  ** Initial revision
diff --git a/appendices/spirvenv.adoc b/appendices/spirvenv.adoc
index 4de00148..9be15096 100644
--- a/appendices/spirvenv.adoc
+++ b/appendices/spirvenv.adoc
@@ -1042,35 +1042,35 @@ ifdef::VK_KHR_shader_float_controls2[]
     If <<limits-shaderSignedZeroInfNanPreserveFloat16,
     pname:shaderSignedZeroInfNanPreserveFloat16>> is ename:VK_FALSE then any
     code:FPFastMathDefault execution mode with a type of 16-bit float must:
-    include the code:NSZ, code:NotInf, and code:NotNaN flags.
+    include the code:NSZ, code:NotInf, and code:NotNaN flags
   * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat16-09560]]
     If <<limits-shaderSignedZeroInfNanPreserveFloat16,
     pname:shaderSignedZeroInfNanPreserveFloat16>> is ename:VK_FALSE then any
-    code:FPFastMath decoration on an instruction with result type or any
+    code:FPFastMathMode decoration on an instruction with result type or any
     operand type that includes a 16-bit float must: include the code:NSZ,
-    code:NotInf, and code:NotNaN flags.
+    code:NotInf, and code:NotNaN flags
   * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat32-09561]]
     If <<limits-shaderSignedZeroInfNanPreserveFloat32,
     pname:shaderSignedZeroInfNanPreserveFloat32>> is ename:VK_FALSE then any
     code:FPFastMathDefault execution mode with a type of 32-bit float must:
-    include the code:NSZ, code:NotInf, and code:NotNaN flags.
+    include the code:NSZ, code:NotInf, and code:NotNaN flags
   * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat32-09562]]
     If <<limits-shaderSignedZeroInfNanPreserveFloat32,
     pname:shaderSignedZeroInfNanPreserveFloat32>> is ename:VK_FALSE then any
-    code:FPFastMath decoration on an instruction with result type or any
+    code:FPFastMathMode decoration on an instruction with result type or any
     operand type that includes a 32-bit float must: include the code:NSZ,
-    code:NotInf, and code:NotNaN flags.
+    code:NotInf, and code:NotNaN flags
   * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat64-09563]]
     If <<limits-shaderSignedZeroInfNanPreserveFloat64,
     pname:shaderSignedZeroInfNanPreserveFloat64>> is ename:VK_FALSE then any
     code:FPFastMathDefault execution mode with a type of 64-bit float must:
-    include the code:NSZ, code:NotInf, and code:NotNaN flags.
+    include the code:NSZ, code:NotInf, and code:NotNaN flags
   * [[VUID-{refpage}-shaderSignedZeroInfNanPreserveFloat64-09564]]
     If <<limits-shaderSignedZeroInfNanPreserveFloat64,
     pname:shaderSignedZeroInfNanPreserveFloat64>> is ename:VK_FALSE then any
-    code:FPFastMath decoration on an instruction with result type or any
+    code:FPFastMathMode decoration on an instruction with result type or any
     operand type that includes a 64-bit float must: include the code:NSZ,
-    code:NotInf, and code:NotNaN flags.
+    code:NotInf, and code:NotNaN flags
 endif::VK_KHR_shader_float_controls2[]
 ifdef::VK_EXT_transform_feedback[]
   * [[VUID-{refpage}-Offset-06308]]
diff --git a/chapters/VK_NV_device_generated_commands/generation.adoc b/chapters/VK_NV_device_generated_commands/generation.adoc
index ac5519e9..a4d17f16 100644
--- a/chapters/VK_NV_device_generated_commands/generation.adoc
+++ b/chapters/VK_NV_device_generated_commands/generation.adoc
@@ -14,7 +14,7 @@ include::{generated}/api/protos/vkGetGeneratedCommandsMemoryRequirementsNV.adoc[
 
   * pname:device is the logical device that owns the buffer.
   * pname:pInfo is a pointer to a
-    sname:VkGeneratedCommandsMemoryRequirementsInfoNV structure containing
+    slink:VkGeneratedCommandsMemoryRequirementsInfoNV structure containing
     parameters required for the memory requirements query.
   * pname:pMemoryRequirements is a pointer to a slink:VkMemoryRequirements2
     structure in which the memory requirements of the buffer object are
@@ -277,9 +277,11 @@ include::{generated}/api/structs/VkGeneratedCommandsInfoNV.adoc[]
     preprocessing the input data for execution.
     If this structure is used with flink:vkCmdExecuteGeneratedCommandsNV
     with its pname:isPreprocessed set to ename:VK_TRUE, then the
-    preprocessing step is skipped and data is only read from this buffer.
-    The contents and the layout of this buffer is opaque to applications and
-    must: not be modified or copied to another buffer for reuse.
+    preprocessing step is skipped and data in this buffer will not be
+    modified.
+    The contents and the layout of this buffer are opaque to applications
+    and must: not be modified outside functions related to device-generated
+    commands or copied to another buffer for reuse.
   * pname:preprocessOffset is the byte offset into pname:preprocessBuffer
     where the preprocessed data is stored.
   * pname:preprocessSize is the maximum byte size within the
@@ -312,7 +314,7 @@ include::{generated}/api/structs/VkGeneratedCommandsInfoNV.adoc[]
   * [[VUID-VkGeneratedCommandsInfoNV-indirectCommandsLayout-02915]]
     If the pname:indirectCommandsLayout uses a token of
     ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_PUSH_CONSTANT_NV, then the
-    pname:pipeline`s sname:VkPipelineLayout must: match the
+    pname:pipeline's sname:VkPipelineLayout must: match the
     slink:VkIndirectCommandsLayoutTokenNV::pname:pushconstantPipelineLayout
   * [[VUID-VkGeneratedCommandsInfoNV-streamCount-02916]]
     pname:streamCount must: match the pname:indirectCommandsLayout's
diff --git a/chapters/VK_NV_device_generated_commands/indirectcommands.adoc b/chapters/VK_NV_device_generated_commands/indirectcommands.adoc
index 59f53255..fdebffa5 100644
--- a/chapters/VK_NV_device_generated_commands/indirectcommands.adoc
+++ b/chapters/VK_NV_device_generated_commands/indirectcommands.adoc
@@ -11,6 +11,9 @@ The device-side command generation happens through an iterative processing
 of an atomic sequence comprised of command tokens, which are represented by:
 
 include::{generated}/api/handles/VkIndirectCommandsLayoutNV.adoc[]
+
+Each indirect command layout must: have exactly one action command token and
+it must: be the last token in the sequence.
 --
 
 
@@ -25,7 +28,7 @@ include::{generated}/api/protos/vkCreateIndirectCommandsLayoutNV.adoc[]
   * pname:device is the logical device that creates the indirect command
     layout.
   * pname:pCreateInfo is a pointer to a
-    sname:VkIndirectCommandsLayoutCreateInfoNV structure containing
+    slink:VkIndirectCommandsLayoutCreateInfoNV structure containing
     parameters affecting creation of the indirect command layout.
   * pname:pAllocator controls host memory allocation as described in the
     <<memory-allocation, Memory Allocation>> chapter.
@@ -124,12 +127,19 @@ endif::VK_NV_device_generated_commands_compute[]
     ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_SHADER_GROUP_NV it must: be the
     first element of the array and there must: be only a single element of
     such token type
+ifdef::VK_NV_device_generated_commands_compute[]
+  * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-pTokens-09585]]
+    If pname:pTokens contains an entry of
+    ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_PIPELINE_NV it must: be the first
+    element of the array and there must: be only a single element of such
+    token type
+endif::VK_NV_device_generated_commands_compute[]
   * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-pTokens-02933]]
     If pname:pTokens contains an entry of
     ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_STATE_FLAGS_NV there must: be only
     a single element of such token type
   * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-pTokens-02934]]
-    All state tokens in pname:pTokens must: occur before any work provoking
+    All state tokens in pname:pTokens must: occur before any action command
     tokens (ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_NV,
     ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_INDEXED_NV,
     ename:VK_INDIRECT_COMMANDS_TOKEN_TYPE_DRAW_TASKS_NV,
@@ -139,13 +149,13 @@ ifdef::VK_NV_device_generated_commands_compute[]
 endif::VK_NV_device_generated_commands_compute[]
     )
   * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-pTokens-02935]]
-    The content of pname:pTokens must: include one single work provoking
+    The content of pname:pTokens must: include one single action command
     token that is compatible with the pname:pipelineBindPoint
   * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-streamCount-02936]]
     pname:streamCount must: be greater than `0` and less or equal to
     sname:VkPhysicalDeviceDeviceGeneratedCommandsPropertiesNV::pname:maxIndirectCommandsStreamCount
   * [[VUID-VkIndirectCommandsLayoutCreateInfoNV-pStreamStrides-02937]]
-    each element of pname:pStreamStrides must: be greater than `0`and less
+    each element of pname:pStreamStrides must: be greater than `0` and less
     than or equal to
     sname:VkPhysicalDeviceDeviceGeneratedCommandsPropertiesNV::pname:maxIndirectCommandsStreamStride.
     Furthermore the alignment of each token input must: be ensured
@@ -482,7 +492,7 @@ void cmdProcessAllSequences(cmd, pipeline, indirectCommandsLayout, pIndirectComm
 ----
 
 The processing of each sequence is considered stateless, therefore all state
-changes must: occur prior work provoking commands within the sequence.
+changes must: occur before any action command tokens within the sequence.
 A single sequence is strictly targeting the elink:VkPipelineBindPoint it was
 created with.
 
@@ -535,7 +545,8 @@ include::{generated}/api/structs/VkIndirectCommandsLayoutTokenNV.adoc[]
   * pname:sType is a elink:VkStructureType value identifying this structure.
   * pname:pNext is `NULL` or a pointer to a structure extending this
     structure.
-  * pname:tokenType specifies the token command type.
+  * pname:tokenType is a elink:VkIndirectCommandsTokenTypeNV specifying the
+    token command type.
   * pname:stream is the index of the input stream containing the token
     argument data.
   * pname:offset is a relative starting offset within the input stream
@@ -551,13 +562,13 @@ include::{generated}/api/structs/VkIndirectCommandsLayoutTokenNV.adoc[]
   * pname:pushconstantOffset is the offset used for the push constant
     command.
   * pname:pushconstantSize is the size used for the push constant command.
-  * pname:indirectStateFlags are the active states for the state flag
-    command.
+  * pname:indirectStateFlags is a tlink:VkIndirectStateFlagsNV bitfield
+    indicating the active states for the state flag command.
   * pname:indexTypeCount is the optional size of the pname:pIndexTypes and
     pname:pIndexTypeValues array pairings.
     If not zero, it allows to register a custom `uint32_t` value to be
-    treated as specific ename:VkIndexType.
-  * pname:pIndexTypes is the used ename:VkIndexType for the corresponding
+    treated as specific elink:VkIndexType.
+  * pname:pIndexTypes is the used elink:VkIndexType for the corresponding
     `uint32_t` value entry in pname:pIndexTypeValues.
 
 .Valid Usage
diff --git a/chapters/commonvalidity/pipeline_barrier_common.adoc b/chapters/commonvalidity/pipeline_barrier_common.adoc
index 5ddb3ce0..fccbfab5 100644
--- a/chapters/commonvalidity/pipeline_barrier_common.adoc
+++ b/chapters/commonvalidity/pipeline_barrier_common.adoc
@@ -116,6 +116,19 @@ endif::VK_KHR_dynamic_rendering_local_read[]
     fname:{refpage} is called within a render pass instance started with
     flink:vkCmdBeginRendering, there must: be no buffer or image memory
     barriers specified by this command
+  * [[VUID-{refpage}-None-09586]]
+    If
+ifdef::VK_KHR_dynamic_rendering_local_read[]
+    the <<features-dynamicRenderingLocalRead,
+    pname:dynamicRenderingLocalRead>> feature is not enabled, and
+endif::VK_KHR_dynamic_rendering_local_read[]
+    fname:{refpage} is called within a render pass instance started with
+    flink:vkCmdBeginRendering, memory barriers specified by this command
+    must: only include ename:VK_ACCESS_2_COLOR_ATTACHMENT_READ_BIT,
+    ename:VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT,
+    ename:VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT, or
+    ename:VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT in their access
+    masks.
 ifdef::VK_KHR_dynamic_rendering_local_read[]
   * [[VUID-{refpage}-image-09555]]
     If fname:{refpage} is called within a render pass instance started with
diff --git a/chapters/descriptorsets.adoc b/chapters/descriptorsets.adoc
index 8910bbbb..9b6da794 100644
--- a/chapters/descriptorsets.adoc
+++ b/chapters/descriptorsets.adoc
@@ -455,9 +455,8 @@ ifdef::VK_EXT_mutable_descriptor_type,VK_VALVE_mutable_descriptor_type[]
 
 A descriptor of _mutable_ (ename:VK_DESCRIPTOR_TYPE_MUTABLE_EXT) type
 indicates that this descriptor can: mutate to any of the descriptor types
-given in the
-slink:VkMutableDescriptorTypeCreateInfoEXT::pname:pDescriptorTypes list of
-descriptor types in the pname:pNext chain of
+given in the slink:VkMutableDescriptorTypeListEXT::pname:pDescriptorTypes
+list of descriptor types in the pname:pNext chain of
 slink:VkDescriptorSetLayoutCreateInfo for this binding.
 At any point, each individual descriptor of mutable type has an active
 descriptor type.
@@ -561,9 +560,20 @@ include::{generated}/api/protos/vkCreateDescriptorSetLayout.adoc[]
 
 include::{chapters}/commonvalidity/no_dynamic_allocations_common.adoc[]
 
-ifdef::VKSC_VERSION_1_0[]
+ifdef::VK_VERSION_1_1,VK_KHR_maintenance3,VKSC_VERSION_1_0[]
 .Valid Usage
 ****
+ifdef::VK_VERSION_1_1,VK_KHR_maintenance3[]
+
+  * [[VUID-vkCreateDescriptorSetLayout-support-09582]]
+    If the descriptor layout does not meet the limits reported through the
+    <<limits,physical device limits>>, then
+    flink:vkGetDescriptorSetLayoutSupport must return
+    slink:VkDescriptorSetLayoutSupport with pname:support equal to
+    ename:VK_TRUE for pname:pCreateInfo
+
+endif::VK_VERSION_1_1,VK_KHR_maintenance3[]
+ifdef::VKSC_VERSION_1_0[]
 include::{chapters}/commonvalidity/memory_reservation_request_count_common.adoc[]
 
 :uniqifier: layoutbindings
@@ -572,8 +582,9 @@ include::{chapters}/commonvalidity/memory_reservation_request_count_common.adoc[
 :combinedobjectcount: pname:pCreateInfo->bindingCount
 :combinedobjectnamecamelcase: descriptorSetLayoutBinding
 include::{chapters}/commonvalidity/memory_reservation_request_count_combined_common.adoc[]
-****
 endif::VKSC_VERSION_1_0[]
+****
+endif::VK_VERSION_1_1,VK_KHR_maintenance3,VKSC_VERSION_1_0[]
 
 include::{generated}/validity/protos/vkCreateDescriptorSetLayout.adoc[]
 --
diff --git a/chapters/devsandqueues.adoc b/chapters/devsandqueues.adoc
index 3cd0fec9..0f4d9be6 100644
--- a/chapters/devsandqueues.adoc
+++ b/chapters/devsandqueues.adoc
@@ -723,8 +723,9 @@ ifndef::VK_VERSION_1_2[:anchor-prefix:]
   * pname:driverInfo is an array of ename:VK_MAX_DRIVER_INFO_SIZE code:char
     containing a null-terminated UTF-8 string with additional information
     about the driver.
-  * pname:conformanceVersion is the version of the Vulkan conformance test
-    this driver is conformant against (see slink:VkConformanceVersion).
+  * pname:conformanceVersion is the latest version of the Vulkan conformance
+    test that the implementor has successfully tested this driver against
+    prior to release (see slink:VkConformanceVersion).
 // end::VK_KHR_driver_properties-properties[]
 
 :refpage: VkPhysicalDeviceDriverProperties
diff --git a/chapters/features.adoc b/chapters/features.adoc
index 96da12f8..3a161e5b 100644
--- a/chapters/features.adoc
+++ b/chapters/features.adoc
@@ -7584,6 +7584,28 @@ include::{generated}/validity/structs/VkPhysicalDeviceShaderAtomicFloat16VectorF
 --
 endif::VK_NV_shader_atomic_float16_vector[]
 
+ifdef::VK_NV_raw_access_chains[]
+[open,refpage='VkPhysicalDeviceRawAccessChainsFeaturesNV', desc='Structure describing shader raw access chains features that can be supported by an implementation',type='structs']
+--
+The sname:VkPhysicalDeviceRawAccessChainsFeaturesNV structure is defined as:
+
+include::{generated}/api/structs/VkPhysicalDeviceRawAccessChainsFeaturesNV.adoc[]
+
+This structure describes the following feature:
+
+  * pname:sType is a elink:VkStructureType value identifying this structure.
+  * pname:pNext is `NULL` or a pointer to a structure extending this
+    structure.
+  * [[features-shaderRawAccessChains]] pname:shaderRawAccessChains specifies
+    whether shader modules can: declare the code:RawAccessChainsNV
+    capability.
+
+:refpage: VkPhysicalDeviceRawAccessChainsFeaturesNV
+include::{chapters}/features.adoc[tag=features]
+
+include::{generated}/validity/structs/VkPhysicalDeviceRawAccessChainsFeaturesNV.adoc[]
+--
+endif::VK_NV_raw_access_chains[]
 
 [[features-requirements]]
 == Feature Requirements
@@ -8503,6 +8525,10 @@ ifdef::VK_EXT_map_memory_placed[]
   * <<features-memoryMapPlaced, pname:memoryMapPlaced>> if the
     `apiext:VK_EXT_map_memory_placed` extension is supported.
 endif::VK_EXT_map_memory_placed[]
+ifdef::VK_NV_raw_access_chains[]
+  * <<features-shaderRawAccessChains, pname:shaderRawAccessChains>>, if the
+    `apiext:VK_NV_raw_access_chains` extension is supported.
+endif::VK_NV_raw_access_chains[]
 
 All other features defined in the Specification are optional:.
 
diff --git a/chapters/formats.adoc b/chapters/formats.adoc
index 798229c0..e5db2448 100644
--- a/chapters/formats.adoc
+++ b/chapters/formats.adoc
@@ -1289,13 +1289,13 @@ ifdef::VK_IMG_format_pvrtc[]
     nonlinear encoding applied to the RGB components.
 endif::VK_IMG_format_pvrtc[]
 ifdef::VK_NV_optical_flow[]
-  * ename:VK_FORMAT_R16G16_S10_5_NV specifies a two-component, 16-bit
-    signed fixed-point format with linear encoding. The components are
-    signed two's-complement integers where the most significant bit
-    specifies the sign bit, the next 10 bits specify the integer value, and
-    the last 5 bits represent the fractional value. The signed 16-bit values
-    can: be converted to floats in the range [eq]#[-1024,1023.96875]# by
-    dividing the value by 32 [eq]#(2^5^)#.
+  * ename:VK_FORMAT_R16G16_S10_5_NV specifies a two-component, 16-bit signed
+    fixed-point format with linear encoding.
+    The components are signed two's-complement integers where the most
+    significant bit specifies the sign bit, the next 10 bits specify the
+    integer value, and the last 5 bits represent the fractional value.
+    The signed 16-bit values can: be converted to floats in the range
+    [eq]#[-1024,1023.96875]# by dividing the value by 32 [eq]#(2^5^)#.
 endif::VK_NV_optical_flow[]
 --
 
@@ -3606,6 +3606,28 @@ pname:shaderStorageImageWriteWithoutFormat>> must: support
 ename:VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT for that same
 format if Vulkan 1.3 or the `apiext:VK_KHR_format_feature_flags2` extension
 is supported.
+
+An implementation that does not support either of
+ename:VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT or
+ename:VK_FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT for a format
+must: not report support for ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT or
+ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT for that format if it is
+not listed in the <<spirvenv-image-formats, SPIR-V and Vulkan Image Format
+Compatibility>> table.
+
+[NOTE]
+.Note
+====
+Some older implementations do not follow this restriction.
+They report support for formats as storage images even though they do not
+support access without the code:Format qualifier and there is no matching
+code:Format token.
+Such images cannot be either read from or written to.
+
+Drivers which pass Vulkan conformance test suite version 1.3.9.0, or any
+subsequent version will conform to the requirement above.
+====
+
 endif::VK_VERSION_1_3,VK_KHR_format_feature_flags2[]
 
 
diff --git a/chapters/fragops.adoc b/chapters/fragops.adoc
index 5207d5cd..c4f4bc5a 100644
--- a/chapters/fragops.adoc
+++ b/chapters/fragops.adoc
@@ -941,9 +941,8 @@ The samples which qualify for coherent tile image reads from an attachment
 A fragment shader can: declare code:NonCoherentColorAttachmentReadEXT,
 code:NonCoherentDepthAttachmentReadEXT, or
 code:NonCoherentStencilAttachmentReadEXT execution modes to enable
-non-coherent tile image reads which requires
-<<synchronization-pipeline-barriers-explicit-renderpass-tileimage, explicit
-tile image synchronization>> for the writes to an attachment to be made
+non-coherent tile image reads which require an explicit
+flink:vkCmdPipelineBarrier2 call for the writes to an attachment to be made
 visible via tile image reads.
 
 When
@@ -999,9 +998,9 @@ ifdef::VK_EXT_shader_stencil_export[]
 === Stencil Reference Replacement
 
 Writing to the
-<<interfaces-builtin-variables-fragdepth,code:FragStencilRefEXT>> built-in
-will replace the fragment's stencil reference value for each sample in the
-input code:SampleMask.
+<<interfaces-builtin-variables-fragstencilref,code:FragStencilRefEXT>>
+built-in will replace the fragment's stencil reference value for each sample
+in the input code:SampleMask.
 <<fragops-stencil, Stencil testing>> performed after the fragment shader for
 this fragment will use this new value as [eq]#s~r~#.
 endif::VK_EXT_shader_stencil_export[]
diff --git a/chapters/fxvertex.adoc b/chapters/fxvertex.adoc
index 82b91efa..0ee3b109 100644
--- a/chapters/fxvertex.adoc
+++ b/chapters/fxvertex.adoc
@@ -934,22 +934,33 @@ ifdef::VK_EXT_vertex_input_dynamic_state,VK_EXT_shader_object[]
     code:attribDesc.binding.
 endif::VK_EXT_vertex_input_dynamic_state,VK_EXT_shader_object[]
 endif::VK_EXT_vertex_attribute_divisor,VK_KHR_vertex_attribute_divisor[]
+  * Let code:stride be the member of
+    slink:VkPipelineVertexInputStateCreateInfo::pname:pVertexBindingDescriptions->stride
+    unless there is dynamic state causing the value to be ignored.
+    In this case the value is set from the last value from one of the
+    following
+ifdef::VK_EXT_vertex_input_dynamic_state,VK_EXT_shader_object[]
+  ** flink:vkCmdSetVertexInputEXT::pname:pVertexBindingDescriptions->stride
+endif::VK_EXT_vertex_input_dynamic_state,VK_EXT_shader_object[]
+ifdef::VK_VERSION_1_3,VK_EXT_extended_dynamic_state,VK_EXT_shader_object[]
+  ** flink:vkCmdBindVertexBuffers2EXT::pname:pStride, if not code:NULL
+endif::VK_VERSION_1_3,VK_EXT_extended_dynamic_state,VK_EXT_shader_object[]
 
 [source,c]
 ----
 bufferBindingAddress = buffer[binding].baseAddress + offset[binding];
 
 if (bindingDesc.inputRate == VK_VERTEX_INPUT_RATE_VERTEX)
-    effectiveVertexOffset = vertexIndex * bindingDesc.stride;
+    effectiveVertexOffset = vertexIndex * stride;
 else
 ifndef::VK_EXT_vertex_attribute_divisor,VK_KHR_vertex_attribute_divisor[]
-    effectiveVertexOffset = instanceIndex * bindingDesc.stride;
+    effectiveVertexOffset = instanceIndex * stride;
 endif::VK_EXT_vertex_attribute_divisor,VK_KHR_vertex_attribute_divisor[]
 ifdef::VK_EXT_vertex_attribute_divisor,VK_KHR_vertex_attribute_divisor[]
     if (divisor == 0)
-        effectiveVertexOffset = firstInstance * bindingDesc.stride;
+        effectiveVertexOffset = firstInstance * stride;
     else
-        effectiveVertexOffset = (firstInstance + ((instanceIndex - firstInstance) / divisor)) * bindingDesc.stride;
+        effectiveVertexOffset = (firstInstance + ((instanceIndex - firstInstance) / divisor)) * stride;
 endif::VK_EXT_vertex_attribute_divisor,VK_KHR_vertex_attribute_divisor[]
 
 attribAddress = bufferBindingAddress + effectiveVertexOffset + attribDesc.offset;
diff --git a/chapters/interfaces.adoc b/chapters/interfaces.adoc
index 5ace09d2..2fd5bfd6 100644
--- a/chapters/interfaces.adoc
+++ b/chapters/interfaces.adoc
@@ -479,23 +479,37 @@ Each element of pname:pColorAttachmentLocations set to any other value will
 map the specified location value to the color attachment specified in the
 render pass at the corresponding index in the
 pname:pColorAttachmentLocations array.
-If pname:pColorAttachmentLocations is `NULL`, it is equivalent to setting
-each element to its index within the array.
 Any writes to a fragment output location that is not mapped to an attachment
 must: be discarded.
 
+If pname:pColorAttachmentLocations is `NULL`, it is equivalent to setting
+each element to its index within the array.
+
 This structure can: be included in the pname:pNext chain of a
 slink:VkGraphicsPipelineCreateInfo structure to set this state for a
 pipeline.
+If this structure is not included in the pname:pNext chain of
+slink:VkGraphicsPipelineCreateInfo, it is equivalent to specifying this
+structure with the following properties:
+
+  * pname:colorAttachmentCount set to
+    slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount.
+  * pname:pColorAttachmentLocations set to `NULL`.
+
 This structure can: be included in the pname:pNext chain of a
 slink:VkCommandBufferInheritanceInfo structure to specify inherited state
 from the primary command buffer.
+If slink:VkCommandBufferInheritanceInfo::renderPass is not
+dlink:VK_NULL_HANDLE, or
+ename:VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT is not specified in
+slink:VkCommandBufferBeginInfo::flags, members of this structure are
+ignored.
 If this structure is not included in the pname:pNext chain of
-slink:VkGraphicsPipelineCreateInfo or slink:VkCommandBufferInheritanceInfo,
-it is equivalent to specifying this structure with the following properties:
+slink:VkCommandBufferInheritanceInfo, it is equivalent to specifying this
+structure with the following properties:
 
   * pname:colorAttachmentCount set to
-    slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount.
+    slink:VkCommandBufferInheritanceRenderingInfo::pname:colorAttachmentCount.
   * pname:pColorAttachmentLocations set to `NULL`.
 
 .Valid Usage
@@ -755,6 +769,7 @@ ename:VK_ATTACHMENT_UNUSED indicates that the corresponding attachment will
 not be used as an input attachment in this pipeline.
 Any other value in each of those elements will map the corresponding
 attachment to a code:InputAttachmentIndex value defined in shader code.
+
 If pname:pColorAttachmentInputIndices is `NULL`, it is equivalent to setting
 each element to its index within the array.
 
@@ -770,15 +785,25 @@ code:InputAttachmentIndex value defined in shader code.
 This structure can: be included in the pname:pNext chain of a
 slink:VkGraphicsPipelineCreateInfo structure to set this state for a
 pipeline.
+If this structure is not included in the pname:pNext chain of
+slink:VkGraphicsPipelineCreateInfo, it is equivalent to specifying this
+structure with the following properties:
+
+  * pname:colorAttachmentCount set to
+    slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount.
+  * pname:pColorAttachmentInputIndices set to `NULL`.
+  * pname:pDepthInputAttachmentIndex set to `NULL`.
+  * pname:pStencilInputAttachmentIndex set to `NULL`.
+
 This structure can: be included in the pname:pNext chain of a
 slink:VkCommandBufferInheritanceInfo structure to specify inherited state
 from the primary command buffer.
 If this structure is not included in the pname:pNext chain of
-slink:VkGraphicsPipelineCreateInfo or slink:VkCommandBufferInheritanceInfo,
-it is equivalent to specifying this structure with the following properties:
+slink:VkCommandBufferInheritanceInfo, it is equivalent to specifying this
+structure with the following properties:
 
   * pname:colorAttachmentCount set to
-    slink:VkPipelineRenderingCreateInfo::pname:colorAttachmentCount.
+    slink:VkCommandBufferInheritanceRenderingInfo::pname:colorAttachmentCount.
   * pname:pColorAttachmentInputIndices set to `NULL`.
   * pname:pDepthInputAttachmentIndex set to `NULL`.
   * pname:pStencilInputAttachmentIndex set to `NULL`.
diff --git a/chapters/pipelines.adoc b/chapters/pipelines.adoc
index 8d48e197..71cee19d 100755
--- a/chapters/pipelines.adoc
+++ b/chapters/pipelines.adoc
@@ -2323,12 +2323,6 @@ ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
     pre-rasterization shader state>>, pname:subpass viewMask is not `0`, and
     pname:multiviewGeometryShader is not enabled, then pname:pStages must:
     not include a geometry shader
-  * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-06049]]
-    If pname:renderPass is not dlink:VK_NULL_HANDLE, the pipeline is being
-    created with <<pipelines-graphics-subsets-pre-rasterization,
-    pre-rasterization shader state>>, and pname:subpass viewMask is not `0`,
-    all of the shaders in the pipeline must: not write to the code:Layer
-    built-in output
   * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-06050]]
     If pname:renderPass is not dlink:VK_NULL_HANDLE and the pipeline is
     being created with <<pipelines-graphics-subsets-pre-rasterization,
@@ -3204,13 +3198,6 @@ ifdef::VK_KHR_multiview,VK_VERSION_1_1[]
     slink:VkPipelineRenderingCreateInfo::pname:viewMask is not `0`, and the
     <<features-multiview-gs, pname:multiviewGeometryShader>> feature is not
     enabled, then pname:pStages must: not include a geometry shader
-  * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-07718]]
-    If pname:renderPass is dlink:VK_NULL_HANDLE, the pipeline is being
-    created with <<pipelines-graphics-subsets-pre-rasterization,
-    pre-rasterization shader state>>, and
-    slink:VkPipelineRenderingCreateInfo::pname:viewMask is not `0`, all of
-    the shaders in the pipeline must: not write to the code:Layer built-in
-    output
   * [[VUID-VkGraphicsPipelineCreateInfo-renderPass-06059]]
     If pname:renderPass is dlink:VK_NULL_HANDLE, the pipeline is being
     created with <<pipelines-graphics-subsets-pre-rasterization,
@@ -4267,9 +4254,8 @@ ifdef::VK_EXT_graphics_pipeline_library[]
     state>> is specified either in a library or by the inclusion of
     ename:VK_GRAPHICS_PIPELINE_LIBRARY_PRE_RASTERIZATION_SHADERS_BIT_EXT,
     and that state includes a vertex shader stage in pname:pStages, the
-    pipeline must: either define
-    <<pipelines-graphics-subsets-pre-rasterization, pre-rasterization shader
-    state>> or include that state in a linked pipeline library
+    pipeline must: either define <<pipelines-graphics-subsets-vertex-input,
+    vertex input state>> or include that state in a linked pipeline library
   * [[VUID-VkGraphicsPipelineCreateInfo-flags-08900]]
     If slink:VkGraphicsPipelineLibraryCreateInfoEXT::pname:flags includes
     ename:VK_GRAPHICS_PIPELINE_LIBRARY_PRE_RASTERIZATION_SHADERS_BIT_EXT the
diff --git a/chapters/renderpass.adoc b/chapters/renderpass.adoc
index 918286ed..85d78f15 100644
--- a/chapters/renderpass.adoc
+++ b/chapters/renderpass.adoc
@@ -1168,8 +1168,8 @@ is treated as dlink:VK_NULL_HANDLE.
 .Valid Usage
 ****
   * [[VUID-VkRenderingFragmentDensityMapAttachmentInfoEXT-imageView-06157]]
-    If pname:imageView is not dlink:VK_NULL_HANDLE, pname:layout must: be
-    ename:VK_IMAGE_LAYOUT_GENERAL or
+    If pname:imageView is not dlink:VK_NULL_HANDLE, pname:imageLayout must:
+    be ename:VK_IMAGE_LAYOUT_GENERAL or
     ename:VK_IMAGE_LAYOUT_FRAGMENT_DENSITY_MAP_OPTIMAL_EXT
   * [[VUID-VkRenderingFragmentDensityMapAttachmentInfoEXT-imageView-06158]]
     If pname:imageView is not dlink:VK_NULL_HANDLE, it must: have been
@@ -1181,7 +1181,7 @@ is treated as dlink:VK_NULL_HANDLE.
     If
 ifndef::VKSC_VERSION_1_0[]
 ifdef::VK_VERSION_1_1,VK_KHR_multiview[]
-    apiext:VK_KHR_multiview is not enabled,
+    the <<features-multiview, pname:multiview>> feature is not enabled,
     slink:VkPhysicalDeviceProperties::pname:apiVersion is less than Vulkan
     1.1, and
 endif::VK_VERSION_1_1,VK_KHR_multiview[]
@@ -1218,12 +1218,12 @@ The conditions leading to an optimal pname:renderArea are:
     granularity).
   * either the pname:extent.width member in pname:renderArea is a multiple
     of the horizontal granularity or pname:offset.x+pname:extent.width is
-    equal to the pname:width of the pname:framebuffer in the
-    slink:VkRenderPassBeginInfo.
+    equal to the pname:width of each attachment used in the render pass
+    instance.
   * either the pname:extent.height member in pname:renderArea is a multiple
     of the vertical granularity or pname:offset.y+pname:extent.height is
-    equal to the pname:height of the pname:framebuffer in the
-    slink:VkRenderPassBeginInfo.
+    equal to the pname:height of each attachment used in the render pass
+    instance.
 
 include::{generated}/validity/protos/vkGetRenderingAreaGranularityKHR.adoc[]
 --
diff --git a/chapters/resources.adoc b/chapters/resources.adoc
index cd0fd51f..cbfd6d5e 100644
--- a/chapters/resources.adoc
+++ b/chapters/resources.adoc
@@ -2052,11 +2052,19 @@ ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
     include ename:VK_IMAGE_CREATE_ALIAS_BIT, pname:flags must: not contain
     ename:VK_IMAGE_CREATE_DISJOINT_BIT
   * [[VUID-VkImageCreateInfo-format-04712]]
-    If pname:format has a code:_422 or code:_420 suffix, pname:width must:
-    be a multiple of 2
+    If pname:format has a code:_422 or code:_420 suffix, pname:extent.width
+    must: be a multiple of 2
   * [[VUID-VkImageCreateInfo-format-04713]]
-    If pname:format has a code:_420 suffix, pname:height must: be a multiple
-    of 2
+    If pname:format has a code:_420 suffix, pname:extent.height must: be a
+    multiple of 2
+ifdef::VK_IMG_format_pvrtc[]
+  * [[VUID-VkImageCreateInfo-format-09583]]
+    If pname:format is one of the etext:VK_FORMAT_PVTRC1_*_IMG formats,
+    pname:extent.width must: be a power of 2
+  * [[VUID-VkImageCreateInfo-format-09584]]
+    If pname:format is one of the etext:VK_FORMAT_PVTRC1_*_IMG formats,
+    pname:extent.height must: be a power of 2
+endif::VK_IMG_format_pvrtc[]
 endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
 ifdef::VK_EXT_image_drm_format_modifier[]
   * [[VUID-VkImageCreateInfo-tiling-02261]]
diff --git a/chapters/synchronization.adoc b/chapters/synchronization.adoc
index ba8782e9..6ffbe119 100644
--- a/chapters/synchronization.adoc
+++ b/chapters/synchronization.adoc
@@ -6281,14 +6281,8 @@ that occurred later in <<synchronization-submission-order,submission
 order>>.
 
 If fname:vkCmdPipelineBarrier2 is recorded within a render pass instance,
-the synchronization scopes are limited to operations within the same subpass
-ifdef::VK_EXT_shader_tile_image[]
-, or must: follow the restrictions for
-<<synchronization-pipeline-barriers-explicit-renderpass-tileimage, Tile
-Image Access Synchronization>> if the render pass instance was started with
-flink:vkCmdBeginRendering
-endif::VK_EXT_shader_tile_image[]
-.
+the synchronization scopes are limited to a subset of operations within the
+same subpass or render pass instance.
 
 .Valid Usage
 ****
@@ -6474,49 +6468,6 @@ tname:VkDependencyFlags is a bitmask type for setting a mask of zero or more
 elink:VkDependencyFlagBits.
 --
 
-
-ifdef::VK_EXT_shader_tile_image[]
-[[synchronization-pipeline-barriers-explicit-renderpass-tileimage]]
-=== Explicit Render Pass Tile Image Access Synchronization
-
-A fragment shader can: declare code:NonCoherentColorAttachmentReadEXT,
-code:NonCoherentDepthAttachmentReadEXT, or
-code:NonCoherentStencilAttachmentReadEXT execution modes to enable
-non-coherent tile image reads for color, depth, or stencil, respectively.
-When non-coherent tile image reads are enabled, writes via color, depth and
-stencil attachments are not automatically made visible to the corresponding
-attachment reads via tile images.
-For the writes to be made visible, an explicit memory dependency must: be
-inserted between when the attachment is written to and when it is read from
-by later fragments.
-Such memory dependencies must: be inserted every time a fragment will read
-values at a particular sample (x, y, layer, sample) coordinate, if those
-values have been written since the most recent pipeline barrier; or since
-the start of the render pass instance, if there have been no pipeline
-barriers since the start of the render pass instance.
-When such memory dependencies are used the values at all sample locations
-inside the fragment area are made visible, regardless of coverage.
-
-To insert a memory dependency for explicit render pass tile image
-synchronization, call flink:vkCmdPipelineBarrier2 inside a render pass
-instance started with flink:vkCmdBeginRendering.
-The following restrictions apply for such pipeline barriers:
-
-  * pname:dependencyFlags must: include ename:VK_DEPENDENCY_BY_REGION_BIT.
-  * The pipeline barriers can: only include memory barriers.
-    That is, buffer memory barriers and image memory barriers must: not be
-    used.
-  * The stages in slink:VkMemoryBarrier2::pname:srcStageMask and
-    slink:VkMemoryBarrier2::pname:dstStageMask are restricted to framebuffer
-    space stages.
-  * The access types in slink:VkMemoryBarrier2::pname:srcAccessMask and
-    slink:VkMemoryBarrier2::pname:dstAccessMask are restricted to the
-    following types: ename:VK_ACCESS_2_COLOR_ATTACHMENT_READ_BIT,
-    ename:VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT,
-    ename:VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT, and
-    ename:VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
-endif::VK_EXT_shader_tile_image[]
-
 [[synchronization-memory-barriers]]
 == Memory Barriers
 
diff --git a/chapters/textures.adoc b/chapters/textures.adoc
index eee9cfd7..7db22642 100644
--- a/chapters/textures.adoc
+++ b/chapters/textures.adoc
@@ -612,6 +612,21 @@ sampler or image view that enables <<samplers-YCbCr-conversion,sampler
 {YCbCr} conversion>>.
 endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
 
+If the underlying sname:VkImage format has an X component in its format
+description, undefined: values are read from those bits.
+
+[NOTE]
+.Note
+====
+If the sname:VkImage format and sname:VkImageView format are the same, these
+bits will be unused by format conversion and this will have no effect.
+However, if the sname:VkImageView format is different, then some bits of the
+result may be undefined:.
+For example, when a ename:VK_FORMAT_R10X6_UNORM_PACK16 sname:VkImage is
+sampled via a ename:VK_FORMAT_R16_UNORM sname:VkImageView, the low 6 bits of
+the value before format conversion are undefined: and format conversion may
+return a range of different values.
+====
 
 [[textures-integer-coordinate-validation]]
 ==== Integer Texel Coordinate Validation
@@ -1613,6 +1628,13 @@ Integer outputs are converted such that their value is preserved.
 The converted value of any integer that cannot be represented in the target
 format is undefined:.
 
+If the sname:VkImageView format has an X component in its format
+description, undefined: values are written to those bits.
+
+If the underlying sname:VkImage format has an X component in its format
+description, undefined: values are also written to those bits, even if
+result format conversion produces a valid value for those bits because the
+sname:VkImageView format is different.
 
 [[textures-normalized-operations]]
 == Normalized Texel Coordinate Operations
diff --git a/chapters/video/av1_decode.adoc b/chapters/video/av1_decode.adoc
index c3407f84..5224edad 100644
--- a/chapters/video/av1_decode.adoc
+++ b/chapters/video/av1_decode.adoc
@@ -378,7 +378,7 @@ pname:pStdPictureInfo are interpreted as follows:
     code:StdVideoAV1Segmentation structure pointed to by code:pSegmentation
     is interpreted as follows:
   ** the elements of code:FeatureEnabled are bitmasks where bit index
-     [eq]#i# of element [eq]#j# corresponds to `FeatureEnabled[i][j]` as
+     [eq]#j# of element [eq]#i# corresponds to `FeatureEnabled[i][j]` as
      defined in section 6.8.13 of the <<aomedia-av1,AV1 Specification>>;
   ** code:FeatureData is interpreted as defined in section 6.8.13 of the
      <<aomedia-av1,AV1 Specification>>;
diff --git a/chapters/videocoding.adoc b/chapters/videocoding.adoc
index bd64b83e..d6717d0c 100644
--- a/chapters/videocoding.adoc
+++ b/chapters/videocoding.adoc
@@ -3388,7 +3388,7 @@ endif::VK_KHR_video_encode_queue[]
 ifdef::VK_KHR_video_encode_queue[]
   * [[VUID-vkCmdControlVideoCodingKHR-pCodingControlInfo-08243]]
     If the bound video session was not created with an encode operation,
-    then pname:pCodingControlInfo->pNext must: not include
+    then pname:pCodingControlInfo->flags must: not include
     ename:VK_VIDEO_CODING_CONTROL_ENCODE_RATE_CONTROL_BIT_KHR or
     ename:VK_VIDEO_CODING_CONTROL_ENCODE_QUALITY_LEVEL_BIT_KHR
 endif::VK_KHR_video_encode_queue[]
diff --git a/proposals/VK_EXT_shader_tile_image.adoc b/proposals/VK_EXT_shader_tile_image.adoc
index 63fc482f..59b04821 100644
--- a/proposals/VK_EXT_shader_tile_image.adoc
+++ b/proposals/VK_EXT_shader_tile_image.adoc
@@ -93,13 +93,13 @@ Introduce the concept of a 'tile image'. When the extension is enabled, the fram
 
 Add a new feature struct `VkPhysicalDeviceShaderTileImageFeaturesEXT` containing:
 
- * shaderTileImageColorReadAccess
- * shaderTileImageDepthReadAccess
- * shaderTileImageStencilReadAccess
+ * `shaderTileImageColorReadAccess`
+ * `shaderTileImageDepthReadAccess`
+ * `shaderTileImageStencilReadAccess`
 
-shaderTileImageColorReadAccess is mandatory if this extension is supported.
+`shaderTileImageColorReadAccess` is mandatory if this extension is supported.
 
-shaderTileImageColorReadAccess provides the ability to access current (rasterization order) color values from tile memory via tile images.
+`shaderTileImageColorReadAccess` provides the ability to access current (rasterization order) color values from tile memory via tile images.
 There is no support for the storage format to be redefined as part of this feature.
 Output data is still written via Fragment Output variables.
 Since the framebuffer format is not re-declared, fixed-function blending works as normal.
@@ -109,13 +109,50 @@ Existing shaders do not to need to be modified to write to color attachments.
 Reading color values using the functionality in this extension guarantees that the access is in rasterization order.
 See the spec (Fragment Shader Tile Image Reads) for details on which samples reads qualify for coherent read access.
 
-shaderTileImageDepthReadAccess and shaderTileImageStencilReadAccess provide similar ability to read the depth and stencil values of any sample location covered by the fragment.
+`shaderTileImageDepthReadAccess` and `shaderTileImageStencilReadAccess` provide similar ability to read the depth and stencil values of any sample location covered by the fragment.
 Depth and stencil fetches use implicit tile images.
 If no depth / stencil attachment is present then the values returned by fetches are undefined.
 Early fragment tests are disallowed if depth or stencil fetch is used.
 
 Reading depth/stencil values have similar rasterization order and synchronization guarantees as color.
 
+
+==== Explicit Synchronization
+
+When non-coherent tile image reads are enabled, writes via color, depth and
+stencil attachments are not automatically made visible to the corresponding
+attachment reads via tile images.
+For the writes to be made visible, an explicit memory dependency must be
+inserted between when the attachment is written to and when it is read from
+by later fragments.
+Such memory dependencies must be inserted every time a fragment will read
+values at a particular sample (x, y, layer, sample) coordinate, if those
+values have been written since the most recent pipeline barrier; or since
+the start of the render pass instance, if there have been no pipeline
+barriers since the start of the render pass instance.
+When such memory dependencies are used the values at all sample locations
+inside the fragment area are made visible, regardless of coverage.
+
+To insert a memory dependency for explicit render pass tile image
+synchronization, link:{refpage}vkCmdPipelineBarrier.html[vkCmdPipelineBarrier]
+and link:{refpage}vkCmdPipelineBarrier2.html[vkCmdPipelineBarrier2]
+can now be called inside a render pass instance started with
+link:{refpage}vkCmdBeginRendering.html[vkCmdBeginRendering].
+The following restrictions apply for such pipeline barriers:
+
+  * `dependencyFlags` must include `VK_DEPENDENCY_BY_REGION_BIT`.
+  * The pipeline barriers can include only memory barriers.
+    That is, buffer memory barriers and image memory barriers must not be
+    used.
+  * The stages in the `srcStageMask` and `dstStageMask` members of link:{refpage}VkMemoryBarrier2.html[VkMemoryBarrier2] are restricted to framebuffer
+    space stages.
+  * The access types in the `srcAccessMask` and `dstAccessMask` members of link:{refpage}VkMemoryBarrier2.html[VkMemoryBarrier2] are restricted to the
+    following types: `VK_ACCESS_2_COLOR_ATTACHMENT_READ_BIT`,
+    `VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT`,
+    `VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT`, and
+    `VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT`.
+
+
 === SPIR-V changes
 
 This proposal leverages `OpTypeImage` and makes 'TileImageDataEXT' another `Dim` similar to `SubpassData`.
diff --git a/proposals/VK_KHR_dynamic_rendering_local_read.adoc b/proposals/VK_KHR_dynamic_rendering_local_read.adoc
index 951e9769..a25d0113 100644
--- a/proposals/VK_KHR_dynamic_rendering_local_read.adoc
+++ b/proposals/VK_KHR_dynamic_rendering_local_read.adoc
@@ -100,7 +100,7 @@ void vkCmdSetRenderingAttachmentLocationsKHR(
 As with render pass objects, this information must be provided both when creating a pipeline and during rendering, and must match between the two in order to be valid.
 
 This information can be provided during pipeline creation by chaining `VkRenderingAttachmentLocationInfoKHR` to link:{refpage}VkGraphicsPipelineCreateInfo.html[VkGraphicsPipelineCreateInfo] when the fragment output state subset is required.
-If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentLocations` to the value of its index within the array.
+If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentLocations` to the value of its index within the array, and `colorAttachmentCount` equal to the value of link:{refpage}VkPipelineRenderingCreateInfoKHR.html[VkPipelineRenderingCreateInfoKHR::colorAttachmentCount].
 
 `vkCmdSetRenderingAttachmentLocationsKHR` must only be called within a dynamic render pass instance.
 If this command is not called, the default state is that each element of `pColorAttachmentLocations` is equal to the value of its index within the array.
@@ -119,7 +119,7 @@ This means when porting from render pass objects, care must be taken to ensure t
 When issuing a draw call, the location mapping must match between the currently bound graphics pipeline and the command buffer state set by `vkCmdSetRenderingAttachmentLocationsKHR`.
 
 `VkRenderingAttachmentLocationInfoKHR` can also be chained to link:{refpage}VkCommandBufferInheritanceInfo.html[VkCommandBufferInheritanceInfo] when using secondary command buffers, to specify the color attachment location mapping in the primary command buffer when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called.
-If `VkRenderingAttachmentLocationInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentLocations` set to the value of its index within the array.
+If `VkRenderingAttachmentLocationInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentLocations` set to the value of its index within the array, with the color attachment count equal to that specified by link:{refpage}VkCommandBufferInheritanceRenderingInfo.html[VkCommandBufferInheritanceRenderingInfo::colorAttachmentCount].
 This information must match between the inheritance info and the state when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called if there is a currently active render pass instance.
 
 NOTE: This functionality is provided primarily for porting existing content to the new API; new applications should maintain a consistent location for all attachments in their shaders during a render pass; this functionality can be considered immediately deprecated.
@@ -156,7 +156,7 @@ void vkCmdSetRenderingInputAttachmentIndicesKHR(
 ----
 
 This information can be provided during pipeline creation by chaining `VkRenderingInputAttachmentIndexInfoKHR` to link:{refpage}VkGraphicsPipelineCreateInfo.html[VkGraphicsPipelineCreateInfo] when the fragment shader state subset is required.
-If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentInputIndices` to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` are set to `NULL`.
+If this structure is not provided for pipeline creation, it is equivalent to setting the value of each element of `pColorAttachmentInputIndices` to the value of its index within the array, `colorAttachmentCount` to the value of link:{refpage}VkPipelineRenderingCreateInfoKHR.html[VkPipelineRenderingCreateInfoKHR::colorAttachmentCount], and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` to `NULL`.
 
 `vkCmdSetRenderingInputAttachmentIndicesKHR` must only be called within a dynamic render pass instance.
 If this command is not called, the default state is that each element of `pColorAttachmentInputIndices` to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` are set to `NULL`.
@@ -171,7 +171,7 @@ If `pDepthInputAttachmentIndex`, `pStencilInputAttachmentIndex`, or any element
 When issuing a draw call, the input attachment index mapping must match between the currently bound graphics pipeline and the command buffer state set by `vkCmdSetRenderingInputAttachmentIndicesKHR`.
 
 `VkRenderingInputAttachmentIndexInfoKHR` can also be chained to link:{refpage}VkCommandBufferInheritanceInfo.html[VkCommandBufferInheritanceInfo] when using secondary command buffers, to specify the input attachment index mapping in the primary command buffer when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called.
-If `VkRenderingInputAttachmentIndexInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentInputIndices` set to the value of its index within the array, and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` set to `NULL`.
+If `VkRenderingInputAttachmentIndexInfoKHR` is not provided in the inheritance info, it is equivalent to providing it with the value of each element of `pColorAttachmentInputIndices` set to the value of its index within the array, `colorAttachmentCount` set to the value of link:{refpage}VkCommandBufferInheritanceRenderingInfo.html[VkCommandBufferInheritanceRenderingInfo::colorAttachmentCount], and `pDepthInputAttachmentIndex` and `pStencilInputAttachmentIndex` set to `NULL`.
 This information must match between the inheritance info and the state when link:{refpage}vkCmdExecuteCommands.html[vkCmdExecuteCommands] is called if there is a currently active render pass instance.
 
 NOTE: The remapping functionality is provided primarily for porting existing content to the new API; new applications should set their index attachment indices consistently for all attachments in their shaders during a render pass; this functionality can be considered immediately deprecated.
diff --git a/proposals/template.adoc b/proposals/template.adoc
index 8adf3622..a8242878 100644
--- a/proposals/template.adoc
+++ b/proposals/template.adoc
@@ -13,7 +13,10 @@
 This document outlines the expected flow of a proposal - text in the following sections is there as guidance for how to fill out each section.
 When creating a new proposal, text inside these sections (including this note!) should be removed and replaced with actual proposal text.
 
-Proposal documents are standalone and do not use the attributes and extensions associated with the specification - they should be independently buildable with Asciidoctor, which allows them to be previewed live on GitHub/GitLab.
+Proposal documents are standalone and do not use the attributes, extensions,
+and custom macros available to specification markup.
+They should only use pure Asciidoctor markup, so they can be viewed in the
+GitHub and GitLab asciidoctor renderers.
 
 When calling out existing API constructs or extensions, the `refpage` attribute should be used to link to the relevant Khronos reference page.
 For example - "...used to extend link:{refpage}VkGraphicsPipelineCreateInfo.html[VkGraphicsPipelineCreateInfo]..."
diff --git a/scripts/genvk.py b/scripts/genvk.py
index f2aeddfe..f497f4e5 100755
--- a/scripts/genvk.py
+++ b/scripts/genvk.py
@@ -416,7 +416,6 @@ def makeGenOpts(args):
     ]
 
     betaSuppressExtensions = [
-        'VK_KHR_video_queue',
         'VK_EXT_opacity_micromap',
         'VK_KHR_pipeline_library',
     ]
diff --git a/style/extensions.adoc b/style/extensions.adoc
index f113b8f2..c3fc78d2 100644
--- a/style/extensions.adoc
+++ b/style/extensions.adoc
@@ -1233,10 +1233,10 @@ feature of an extension.
 [source,asciidoc]
 .Example Markup
 ----
-ifdef::VK_EXT_image_robustness[]
+\ifdef::VK_EXT_image_robustness[]
   * <<features-robustImageAccess, pname:robustImageAccess>>, if the
     `apiext:VK_EXT_image_robustness` extension is supported.
-endif::VK_EXT_image_robustness[]
+\endif::VK_EXT_image_robustness[]
 ----
 
 For WSI extensions, it is often necessary to extend
diff --git a/style/introduction.adoc b/style/introduction.adoc
index 981201f9..28a46e7f 100644
--- a/style/introduction.adoc
+++ b/style/introduction.adoc
@@ -6,14 +6,22 @@
 = Introduction
 
 This document contains required procedures and conventions when writing
-specifications for new Vulkan APIs, extensions and layers, or related
-Khronos^{reg}^ documentation such as white papers and tutorials; or
-contributing to existing Vulkan specifications.
+documentation for new Vulkan APIs, extensions and layers, or related
+Khronos^{reg}^ documentation such as proposals.
 These are collectively referred to as _Vulkan Documentation_ or just
 _documentation_ below.
-The primary focus is the API Specification and API extensions, although all
-of the markup and most of the writing style is equally applicable to other
-documentation.
+The primary focus is the API Specification and API extensions, although most
+of this document is equally applicable to other documentation.
+
+[NOTE]
+.Note
+====
+The custom Asciidoctor macros described in the <<markup-macros, Markup
+Macros and Normative Terminology>> section are only available in the actual
+Vulkan Specification, not in proposals and other documents.
+For those documents only pure Asciidoctor markup may be used, in order that
+they be renderable in the web view provided by GitHub and Gitlab.
+====
 
 The primary purpose is to achieve consistency across the API, as well as
 across all of our source and output documents.
diff --git a/style/revisions.adoc b/style/revisions.adoc
index ad6d58bc..f3fcbcbb 100644
--- a/style/revisions.adoc
+++ b/style/revisions.adoc
@@ -5,6 +5,9 @@
 [[revisions]]
 = Revision History
 
+* 2024-02-27 - Add a NOTE to the introduction to clarify that the custom
+  asciidoctor macros are only available in the Specification, not related
+  documentation (internal issue 3808).
 * 2023-11-30 - Update introduction of the <<writing, Writing Style>> chapter
   to recommend following existing language and API design patterms when
   creating new specification language (internal issue 3707).
diff --git a/xml/video.xml b/xml/video.xml
index d570742c..7e52a1b6 100644
--- a/xml/video.xml
+++ b/xml/video.xml
@@ -1389,7 +1389,7 @@ The current public version of video.xml is maintained in the default branch
         <enum name="STD_VIDEO_AV1_FRAME_RESTORATION_TYPE_SWITCHABLE"        value="3"/>
         <enum name="STD_VIDEO_AV1_FRAME_RESTORATION_TYPE_INVALID"           value="0x7FFFFFFF"/>
     </enums>
-    <enums name="StdVideoAV1ColorPrimaries">
+    <enums name="StdVideoAV1ColorPrimaries" type="enum">
         <enum name="STD_VIDEO_AV1_COLOR_PRIMARIES_BT_709"                   value="1"/>
         <enum name="STD_VIDEO_AV1_COLOR_PRIMARIES_BT_UNSPECIFIED"           value="2"/>
         <enum name="STD_VIDEO_AV1_COLOR_PRIMARIES_BT_470_M"                 value="4"/>
@@ -1404,7 +1404,7 @@ The current public version of video.xml is maintained in the default branch
         <enum name="STD_VIDEO_AV1_COLOR_PRIMARIES_EBU_3213"                 value="22"/>
         <enum name="STD_VIDEO_AV1_COLOR_PRIMARIES_INVALID"                  value="0x7FFFFFFF"/>
     </enums>
-    <enums name="StdVideoAV1TransferCharacteristics">
+    <enums name="StdVideoAV1TransferCharacteristics" type="enum">
         <enum name="STD_VIDEO_AV1_TRANSFER_CHARACTERISTICS_RESERVED_0"      value="0"/>
         <enum name="STD_VIDEO_AV1_TRANSFER_CHARACTERISTICS_BT_709"          value="1"/>
         <enum name="STD_VIDEO_AV1_TRANSFER_CHARACTERISTICS_UNSPECIFIED"     value="2"/>
@@ -1426,7 +1426,7 @@ The current public version of video.xml is maintained in the default branch
         <enum name="STD_VIDEO_AV1_TRANSFER_CHARACTERISTICS_HLG"             value="18"/>
         <enum name="STD_VIDEO_AV1_TRANSFER_CHARACTERISTICS_INVALID"         value="0x7FFFFFFF"/>
     </enums>
-    <enums name="StdVideoAV1MatrixCoefficients">
+    <enums name="StdVideoAV1MatrixCoefficients" type="enum">
         <enum name="STD_VIDEO_AV1_MATRIX_COEFFICIENTS_IDENTITY"             value="0"/>
         <enum name="STD_VIDEO_AV1_MATRIX_COEFFICIENTS_BT_709"               value="1"/>
         <enum name="STD_VIDEO_AV1_MATRIX_COEFFICIENTS_UNSPECIFIED"          value="2"/>
@@ -1444,7 +1444,7 @@ The current public version of video.xml is maintained in the default branch
         <enum name="STD_VIDEO_AV1_MATRIX_COEFFICIENTS_ICTCP"                value="14"/>
         <enum name="STD_VIDEO_AV1_MATRIX_COEFFICIENTS_INVALID"              value="0x7FFFFFFF"/>
     </enums>
-    <enums name="StdVideoAV1ChromaSamplePosition">
+    <enums name="StdVideoAV1ChromaSamplePosition" type="enum">
         <enum name="STD_VIDEO_AV1_CHROMA_SAMPLE_POSITION_UNKNOWN"           value="0"/>
         <enum name="STD_VIDEO_AV1_CHROMA_SAMPLE_POSITION_VERTICAL"          value="1"/>
         <enum name="STD_VIDEO_AV1_CHROMA_SAMPLE_POSITION_COLOCATED"         value="2"/>
diff --git a/xml/vk.xml b/xml/vk.xml
index 53c4ff25..ee9221e9 100755
--- a/xml/vk.xml
+++ b/xml/vk.xml
@@ -175,7 +175,7 @@ branch of the member gitlab server.
 #define <name>VKSC_API_VERSION_1_0</name> <type>VK_MAKE_API_VERSION</type>(VKSC_API_VARIANT, 1, 0, 0)// Patch version should always be set to 0</type>
 
         <type api="vulkan" category="define">// Version of this file
-#define <name>VK_HEADER_VERSION</name> 278</type>
+#define <name>VK_HEADER_VERSION</name> 279</type>
         <type api="vulkan" category="define" requires="VK_HEADER_VERSION">// Complete version of this file
 #define <name>VK_HEADER_VERSION_COMPLETE</name> <type>VK_MAKE_API_VERSION</type>(0, 1, 3, VK_HEADER_VERSION)</type>
         <type api="vulkansc" category="define">// Version of this file
@@ -1467,7 +1467,7 @@ typedef void* <name>MTLSharedEvent_id</name>;
             <member noautovalidity="true" optional="true"><type>VkPipeline</type>      <name>basePipelineHandle</name><comment>If VK_PIPELINE_CREATE_DERIVATIVE_BIT is set and this value is nonzero, it specifies the handle of the base pipeline this is a derivative of</comment></member>
             <member><type>int32_t</type>                <name>basePipelineIndex</name><comment>If VK_PIPELINE_CREATE_DERIVATIVE_BIT is set and this value is not -1, it specifies an index into pCreateInfos of the base pipeline this is a derivative of</comment></member>
         </type>
-        <type category="struct" name="VkComputePipelineIndirectBufferInfoNV">
+        <type category="struct" name="VkComputePipelineIndirectBufferInfoNV" structextends="VkComputePipelineCreateInfo">
             <member values="VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_INDIRECT_BUFFER_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member optional="true">const <type>void</type>*   <name>pNext</name></member>
             <member><type>VkDeviceAddress</type>               <name>deviceAddress</name></member>
@@ -2488,7 +2488,7 @@ typedef void* <name>MTLSharedEvent_id</name>;
             <member values="VK_STRUCTURE_TYPE_GENERATED_COMMANDS_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member optional="true">const <type>void</type>*                        <name>pNext</name></member>
             <member><type>VkPipelineBindPoint</type>                <name>pipelineBindPoint</name></member>
-            <member><type>VkPipeline</type>                         <name>pipeline</name></member>
+            <member optional="true"><type>VkPipeline</type>         <name>pipeline</name></member>
             <member><type>VkIndirectCommandsLayoutNV</type>         <name>indirectCommandsLayout</name></member>
             <member><type>uint32_t</type>                           <name>streamCount</name></member>
             <member len="streamCount">const <type>VkIndirectCommandsStreamNV</type>*  <name>pStreams</name></member>
@@ -9103,6 +9103,11 @@ typedef void* <name>MTLSharedEvent_id</name>;
             <member optional="true">const <type>void</type>*  <name>pNext</name></member>
             <member noautovalidity="true"><type>void</type>*  <name>pPlacedAddress</name></member>
         </type>
+        <type category="struct" name="VkPhysicalDeviceRawAccessChainsFeaturesNV" structextends="VkPhysicalDeviceFeatures2,VkDeviceCreateInfo">
+            <member values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAW_ACCESS_CHAINS_FEATURES_NV"><type>VkStructureType</type> <name>sType</name></member>
+            <member optional="true"><type>void</type>*                           <name>pNext</name></member>
+            <member><type>VkBool32</type>                                        <name>shaderRawAccessChains</name></member>
+        </type>
     </types>
 
 
@@ -23312,8 +23317,8 @@ typedef void* <name>MTLSharedEvent_id</name>;
                 <enum bitpos="14" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_VIDEO_DECODE_DST_BIT_KHR"/>
             </require>
             <require depends="VK_KHR_video_encode_queue">
-                <enum bitpos="15" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_VIDEO_ENCODE_DST_BIT_KHR" protect="VK_ENABLE_BETA_EXTENSIONS"/>
-                <enum bitpos="16" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_VIDEO_ENCODE_SRC_BIT_KHR" protect="VK_ENABLE_BETA_EXTENSIONS"/>
+                <enum bitpos="15" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_VIDEO_ENCODE_DST_BIT_KHR"/>
+                <enum bitpos="16" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_VIDEO_ENCODE_SRC_BIT_KHR"/>
             </require>
             <require depends="VK_VERSION_1_2,VK_KHR_buffer_device_address,VK_EXT_buffer_device_address">
                 <enum bitpos="17" extends="VkBufferUsageFlagBits2KHR"    name="VK_BUFFER_USAGE_2_SHADER_DEVICE_ADDRESS_BIT_KHR"/>
@@ -24218,10 +24223,12 @@ typedef void* <name>MTLSharedEvent_id</name>;
                 <enum value="&quot;VK_IMG_extension_555&quot;"              name="VK_IMG_EXTENSION_555_EXTENSION_NAME"/>
             </require>
         </extension>
-        <extension name="VK_NV_extension_556" number="556" type="device" author="NV" contact="Rodrigo Locatti @rlocatti" supported="disabled">
+        <extension name="VK_NV_raw_access_chains" number="556" type="device" author="NV" contact="Rodrigo Locatti @rlocatti" supported="vulkan">
             <require>
-                <enum value="1"                                             name="VK_NV_EXTENSION_556_SPEC_VERSION"/>
-                <enum value="&quot;VK_NV_extension_556&quot;"               name="VK_NV_EXTENSION_556_EXTENSION_NAME"/>
+                <enum value="1"                                             name="VK_NV_RAW_ACCESS_CHAINS_SPEC_VERSION"/>
+                <enum value="&quot;VK_NV_raw_access_chains&quot;"           name="VK_NV_RAW_ACCESS_CHAINS_EXTENSION_NAME"/>
+                <enum offset="0" extends="VkStructureType"                  name="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_RAW_ACCESS_CHAINS_FEATURES_NV"/>
+                <type name="VkPhysicalDeviceRawAccessChainsFeaturesNV"/>
             </require>
         </extension>
         <extension name="VK_NV_extension_557" number="557" type="device" author="NV" contact="Chris Lentini @clentini" supported="disabled">
@@ -24264,6 +24271,7 @@ typedef void* <name>MTLSharedEvent_id</name>;
             <require>
                 <enum value="0"                                             name="VK_KHR_EXTENSION_563_SPEC_VERSION"/>
                 <enum value="&quot;VK_KHR_extension_563&quot;"              name="VK_KHR_EXTENSION_563_EXTENSION_NAME"/>
+                <enum bitpos="43" extends="VkFormatFeatureFlagBits2"        name="VK_FORMAT_FEATURE_2_RESERVED_43_BIT_KHR"/>
             </require>
         </extension>
         <extension name="VK_NV_shader_atomic_float16_vector" number="564" type="device" author="NV" contact="Jeff Bolz @jeffbolznv" supported="vulkan">
@@ -24329,6 +24337,12 @@ typedef void* <name>MTLSharedEvent_id</name>;
                 <enum bitpos="7" extends="VkShaderCreateFlagBitsEXT" name="VK_SHADER_CREATE_EXTENSION_573_BIT_EXT"/>
             </require>
         </extension>
+        <extension name="VK_KHR_extension_574" number="574" author="KHR" contact="Ralph Potter gitlab:@r_potter" supported="disabled">
+            <require>
+                <enum value="0"                                             name="VK_KHR_EXTENSION_574_SPEC_VERSION"/>
+                <enum value="&quot;VK_KHR_extension_574&quot;"              name="VK_KHR_EXTENSION_574_EXTENSION_NAME"/>
+            </require>
+        </extension>
     </extensions>
     <formats>
         <format name="VK_FORMAT_R4G4_UNORM_PACK8" class="8-bit" blockSize="1" texelsPerBlock="1" packed="8">
@@ -25975,6 +25989,9 @@ typedef void* <name>MTLSharedEvent_id</name>;
         <spirvextension name="SPV_KHR_quad_control">
             <enable extension="VK_KHR_shader_quad_control"/>
         </spirvextension>
+        <spirvextension name="SPV_NV_raw_access_chains">
+            <enable extension="VK_NV_raw_access_chains"/>
+        </spirvextension>
     </spirvextensions>
     <spirvcapabilities comment="SPIR-V Capabilities allowed in Vulkan and what is required to use it">
         <spirvcapability name="Matrix">
@@ -26488,6 +26505,9 @@ typedef void* <name>MTLSharedEvent_id</name>;
         <spirvcapability name="MaximallyReconvergesKHR">
             <enable struct="VkPhysicalDeviceShaderMaximalReconvergenceFeaturesKHR" feature="shaderMaximalReconvergence" requires="VK_KHR_shader_maximal_reconvergence"/>
         </spirvcapability>
+        <spirvcapability name="RawAccessChainsNV">
+            <enable struct="VkPhysicalDeviceRawAccessChainsFeaturesNV" feature="shaderRawAccessChains" requires="VK_NV_raw_access_chains"/>
+        </spirvcapability>
     </spirvcapabilities>
     <sync comment="Machine readable representation of the synchronization objects and their mappings">
         <syncstage name="VK_PIPELINE_STAGE_2_NONE" alias="VK_PIPELINE_STAGE_NONE">