Misc content fixes

Author: spencer-lunarg

chapters/access_chains.md

@@ -260,7 +260,7 @@ layout(set = 0, binding = 1) buffer OutputBuffer {
 } out_v;
 
 void main() {
-    in_v.output_values = out_v.input_values;
+    out_v.output_values = in_v.input_values;
 }
 ```
 

chapters/entry_execution.md

@@ -45,7 +45,7 @@ The `OpExecutionMode` and `OpExecutionModeId` instructions reference an `Entry P
 
 > A notable update in the SPIR-V 1.2 spec is that `OpExecutionModeId` was added.
 
-> Also worth noting that as of now, there are no possible uses of `OpExecutionModeId` for Shader capability-based client APIs such as Vulkan.
+> Also worth noting that in Vulkan, `OpExecutionModeId` (e.g. `LocalSizeId`) can only be used with Vulkan 1.3 or `VK_KHR_maintenance4` (and the `maintenance4` feature enabled).
 
 The only difference between the two instructions is how it handles possible `Extra Operands`.
 

chapters/extended_instruction_sets.md

@@ -51,7 +51,7 @@ Breaking this down:
 
 - Need to import the name of the extended instruction set being added with `OpExtInstImport`
 - Use `OpExtInst`
-    - Set the `Set` field to the imported non-semantic extension
-    - Set the `Instruction` to the non-semantic extension specific instruction being added
+    - Set the `Set` field to the imported extended instruction set
+    - Set the `Instruction` to the extended instruction set specific instruction being added
         - For `GLSL.std.450` it is listed as being instruction `13` in the [extended instruction set spec](https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html)
         - ![extended_instruction_sets_sin.png](../images/extended_instruction_sets_sin.png)

chapters/extension_by_version.md

@@ -21,3 +21,8 @@ With some minor versions of SPIR-V some extensions are added into the [unified s
     - [SPV_EXT_physical_storage_buffer](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/EXT/SPV_EXT_physical_storage_buffer.asciidoc)
     - [SPV_KHR_physical_storage_buffer](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_physical_storage_buffer.asciidoc)
     - [SPV_KHR_vulkan_memory_model](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_vulkan_memory_model.asciidoc)
+- SPIR-V 1.6
+    - [SPV_KHR_non_semantic_info](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_non_semantic_info.asciidoc)
+    - [SPV_KHR_integer_dot_product](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_integer_dot_product.asciidoc)
+    - [SPV_KHR_terminate_invocation](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_terminate_invocation.asciidoc)
+    - [SPV_EXT_demote_to_helper_invocation](https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/EXT/SPV_EXT_demote_to_helper_invocation.asciidoc)

chapters/image_accesses.md

@@ -55,7 +55,7 @@ When using a sampler, you must have an `OpTypeSampledImage` object, this will be
 
 ## Combined Image Samplers
 
-The `Input` `OpVariable` can sometimes contain both the Sampler and Image (Vulkan calls these `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`).
+The `UniformConstant` `OpVariable` can sometimes contain both the Sampler and Image (Vulkan calls these `VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER`).
 
 When these variables are loaded, they will be of type `OpTypeSampledImage`.
 

chapters/nonsemantic.md

@@ -32,12 +32,12 @@ the output SPIR-V disassembly roughly looks like
 %10  = OpString "Here are two float values %f, %f"
        OpSourceExtension "GL_EXT_debug_printf"
 
-%14  = %2 OpExtInst %13 %1 %10 %11 %12
+%14  = OpExtInst %2 %13 1 %10 %11 %12
 ```
 
 Breaking this down:
 
-- First need to make sure the `SPV_KHR_non_semantic_info` is enabled
+- First need to make sure the `SPV_KHR_non_semantic_info` is enabled (not needed starting with SPIR-V 1.6, where it was incorporated into core)
 - Need to import the name of the non-semantic extension being added with `OpExtInstImport`
 - Use `OpExtInst`
     - Set the `Set` field to the imported non-semantic extension

chapters/parsing_instructions.md

@@ -55,7 +55,7 @@ Taking a look at a few lines of disassembled SPIR-V
 ```swift
 %2 = OpTypeVoid
 %3 = OpTypeFunction %2
-%6 = TypeInt 32 0
+%6 = OpTypeInt 32 0
 ```
 
 The assembled binary representation is as follows

chapters/untyped_pointers.md

@@ -10,9 +10,9 @@ This idea can also be found in the LLVM community, which has moved to `Opaque Po
 
 This extension adds various `Untyped` instructions, such as:
 
-- Op**Untyped**VariableKHR`
-- Op**Untyped**AccessChainKHR`
-- OpType**Untyped**PointerKHR`
+- Op**Untyped**VariableKHR
+- Op**Untyped**AccessChainKHR
+- OpType**Untyped**PointerKHR
 
 > `OpTypeUntypedPointerKHR` may seem strange, but it follows the `OpType*` convention and is just unfortunate the "type" and "untyped" are both in the name