Change log for November 25, 2016 Vulkan 1.0.35 spec update:

* Bump API patch number and header version number to 35 for this update.

Github Issues:

  * Document in the <<memory-device-hostaccess,Host Access>> section that
    mapping and unmapping does not invalidate or flush the mapped memory
    (public issues 27, 126).
  * Redefine the entire <<synchronization>> chapter in terms of consistent
    and well defined terminology, that's called out at the start of the
    chapter. This terminology is applied equally to all synchronization
    types, including subpass dependencies, submissions, and much of the
    implicit ordering stuff dotted around the spec. Key terms are laid out
    in the <<synchronization-dependencies,Execution and Memory
    Dependencies>> section at the top of the rewritten chapter (public
    issues 128, 131, 132, 217, 299, 300, 302, 306, 322, 346, 347, 371, 407).
  * Specify order of submission for batches in the
    <<vkQueueSubmit,vkQueueSubmit>> and
    <<vkQueueBindSparse,vkQueueBindSparse>> commands (public issue 371).
  * Add valid usage statements to each of the WSI extension sections
    indicating that the WSI-specific structure parameters must be valid, and
    remove automatically generated valid usage statements now covered by the
    manual sections (public issue 383).
  * Clarify render pass compatibility for flink:vkCmdExecuteCommands (public
    issue 390).

Internal Issues:

  * Update +vk.xml+ to make previously explicit valid usage statements for
    <<vkDebugReportMessageEXT,vkDebugReportMessageEXT>> implicit instead
    (internal issue 553).
  * Add valid usage statement for slink:VkCreateImageInfo preventing
    creation of 1D sparse images (internal issue 573).
  * Fix Python scripts to always read/write files in utf-8 encoding, and a
    logic error in reflib.py which could cause a fatal error for
    malstructured asciidoc (internal issues 578, 586).

ChangeLog.txt

@@ -1621,3 +1621,43 @@ Internal Issues:
     when needed (internal issue 462).
   * Shorten the table of contents in the single-page ref page HTML output.
     Still working on the PDF (internal issue 536).
+
+-----------------------------------------------------
+
+Change log for November 25, 2016 Vulkan 1.0.35 spec update:
+
+  * Bump API patch number and header version number to 35 for this update.
+
+Github Issues:
+
+  * Document in the <<memory-device-hostaccess,Host Access>> section that
+    mapping and unmapping does not invalidate or flush the mapped memory
+    (public issues 27, 126).
+  * Redefine the entire <<synchronization>> chapter in terms of consistent
+    and well defined terminology, that's called out at the start of the
+    chapter. This terminology is applied equally to all synchronization
+    types, including subpass dependencies, submissions, and much of the
+    implicit ordering stuff dotted around the spec. Key terms are laid out
+    in the <<synchronization-dependencies,Execution and Memory
+    Dependencies>> section at the top of the rewritten chapter (public
+    issues 128, 131, 132, 217, 299, 300, 302, 306, 322, 346, 347, 371, 407).
+  * Specify order of submission for batches in the
+    <<vkQueueSubmit,vkQueueSubmit>> and
+    <<vkQueueBindSparse,vkQueueBindSparse>> commands (public issue 371).
+  * Add valid usage statements to each of the WSI extension sections
+    indicating that the WSI-specific structure parameters must be valid, and
+    remove automatically generated valid usage statements now covered by the
+    manual sections (public issue 383).
+  * Clarify render pass compatibility for flink:vkCmdExecuteCommands (public
+    issue 390).
+
+Internal Issues:
+
+  * Update +vk.xml+ to make previously explicit valid usage statements for
+    <<vkDebugReportMessageEXT,vkDebugReportMessageEXT>> implicit instead
+    (internal issue 553).
+  * Add valid usage statement for slink:VkCreateImageInfo preventing
+    creation of 1D sparse images (internal issue 573).
+  * Fix Python scripts to always read/write files in utf-8 encoding, and a
+    logic error in reflib.py which could cause a fatal error for
+    malstructured asciidoc (internal issues 578, 586).

doc/specs/vulkan/Makefile

@@ -160,7 +160,7 @@ GENDEPENDS = api/timeMarker validity/timeMarker hostsynctable/timeMarker
 COMMONDOCS = $(CHAPTERS) $(GENINCLUDE) $(GENDEPENDS)
 # A generated included file containing the spec version, date, and git commit
 SPECVERSION = specversion.txt
-SPECREVISION = 1.0.34
+SPECREVISION = 1.0.35
 SPECREMARK =
 
 # Spec targets

doc/specs/vulkan/appendices/VK_NVX_device_generated_commands.txt

@@ -0,0 +1,378 @@
+[[VK_NVX_device_generated_commands]]
+== VK_NVX_device_generated_commands
+
+*Name String*::
+    +VK_NVX_device_generated_commands+
+*Extension Type*::
+    Device extension
+*Registered Extension Number*::
+    87
+*Last Modified Date*::
+    2016-10-31
+*Revision*::
+    1
+*Dependencies*::
+    - This extension is written against version 1.0 of the Vulkan API.
+*Contributors*::
+    - Pierre Boudier, NVIDIA
+    - Christoph Kubisch, NVIDIA
+    - Mathias Schott, NVIDIA
+    - Jeff Bolz, NVIDIA
+    - Eric Werness, NVIDIA
+    - Detlef Roettger, NVIDIA
+    - Daniel Koch, NVIDIA
+    
+*Contacts*::
+    - Pierre Boudier, NVIDIA (pboudier@nvidia.com)
+    - Christoph Kubisch, NVIDIA (ckubisch@nvidia.com)
+
+
+This extension allows the device to generate a number of critical commands
+for command buffers.
+
+When rendering a large number of objects, the device can be leveraged to
+implement a number of critical functions, like updating matrices, or
+implementing occlusion culling, frustum culling, front to back sorting...
+Implementing those on the device does not require any special extension,
+since an application is free to define its own data structure, and just
+process them using shaders.
+
+However, if the application desires to quickly kick off the rendering of the
+final stream of objects, then unextended Vulkan forces the application to
+read back the processed stream and issue graphics command from the host.
+For very large scenes, the synchronization overhead, and cost to generate
+the command buffer can become the bottleneck.
+This extension allows an application to generate a device side stream of
+state changes and commands, and convert it efficiently into a command buffer
+without having to read it back on the host.
+
+Furthermore, it allows incremental changes to such command buffers, by
+manipulating only partial sections of a command stream, for example pipeline
+bindings.
+Unextended Vulkan requires re-creation of entire command buffers in such
+scenario, or updates synchronized on the host.
+
+The intended usage for this extension is for the application to:
+
+  * create its objects as in unextended Vulkan
+  * create a VkObjectTableNVX, and register the various Vulkan objects that
+    are needed to evaluate the input parameters.
+  * create a VkIndirectCommandsLayoutNVX, which lists the
+    VkIndirectCommandsTokenTypes it wants to dynamically change as atomic
+    command sequence.
+    This step likely involves some internal device code compilation, since
+    the intent is for the GPU to generate the command buffer in the
+    pipeline.
+  * fill the input buffers with the data for each of the inputs it needs.
+    Each input is an array that will be filled with an index in the object
+    table, instead of using CPU pointers.
+  * set up a target secondary command buffer
+  * reserve command buffer space via vkCmdReserveSpaceForCommandsNVX in a
+    target command buffer at the position you want the generated commands to
+    be executed.
+  * call vkCmdProcessCommandsNVX to create the actual device commands for
+    all sequences based on the array contents into a provided target command
+    buffer.
+  * execute the target command buffer like a regular secondary command
+    buffer
+
+For each draw/dispatch, the following can be specified:
+
+  * a different pipeline state object
+  * a number of descriptor sets, with dynamic offsets
+  * a number of vertex buffer bindings, with an optional dynamic offset
+  * a different index buffer, with an optional dynamic offset
+
+It is recommended to register a small number of objects and to use dynamic
+offsets whenever possible.
+
+While the GPU can be faster than a CPU to generate the commands, it may not
+happen asynchronously, therefore the primary use-case is generating "less"
+total work (occlusion culling, classification to use specialized
+shaders...).
+
+=== New Object Types
+
+  * sname:VkObjectTableNVX
+  * sname:VkIndirectCommandsLayoutNVX
+  
+== New Flag Types
+
+  * sname:VkIndirectCommandsLayoutUsageFlagsNVX
+  * sname:VkObjectEntryUsageFlagsNVX
+
+=== New Enum Constants
+
+Extending elink:VkStructureType:
+
+  ** ename:VK_STRUCTURE_TYPE_OBJECT_TABLE_CREATE_INFO_NVX
+  ** ename:VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NVX
+  ** ename:VK_STRUCTURE_TYPE_CMD_PROCESS_COMMANDS_INFO_NVX
+  ** ename:VK_STRUCTURE_TYPE_CMD_RESERVE_SPACE_FOR_COMMANDS_INFO_NVX
+  ** ename:VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_LIMITS_NVX
+  ** ename:VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_FEATURES_NVX
+
+Extending elink:VkPipelineStageFlagBits:
+
+  ** ename:VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX
+
+=== New Enums
+
+  * elink:VkIndirectCommandsLayoutUsageFlagBitsNVX
+  * elink:VkIndirectCommandsTokenTypeNVX
+  * elink:VkObjectEntryUsageFlagBitsNVX
+  * elink:VkObjectEntryTypeNVX
+
+=== New Structures
+
+  * slink:VkDeviceGeneratedCommandsFeaturesNVX
+  * slink:VkDeviceGeneratedCommandsLimitsNVX
+  * slink:VkIndirectCommandsTokenNVX
+  * slink:VkIndirectCommandsLayoutTokenNVX
+  * slink:VkIndirectCommandsLayoutCreateInfoNVX
+  * slink:VkCmdProcessCommandsInfoNVX
+  * slink:VkCmdReserveSpaceForCommandsInfoNVX
+  * slink:VkObjectTableCreateInfoNVX
+  * slink:VkObjectTableEntryNVX
+  * slink:VkObjectTablePipelineEntryNVX
+  * slink:VkObjectTableDescriptorSetEntryNVX
+  * slink:VkObjectTableVertexBufferEntryNVX
+  * slink:VkObjectTableIndexBufferEntryNVX
+  * slink:VkObjectTablePushConstantEntryNVX
+  
+=== New Functions
+
+  * flink:vkCmdProcessCommandsNVX
+  * flink:vkCmdReserveSpaceForCommandsNVX
+  * flink:vkCreateIndirectCommandsLayoutNVX
+  * flink:vkDestroyIndirectCommandsLayoutNVX
+  * flink:vkCreateObjectTableNVX
+  * flink:vkDestroyObjectTableNVX
+  * flink:vkRegisterObjectsNVX
+  * flink:vkUnregisterObjectsNVX
+  * flink:vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX
+
+=== Issues
+
+1) How to name this extension ?
+
+  As usual one of the hardest issues ;)
+
+  VK_gpu_commands VK_execute_commands VK_device_commands
+  VK_device_execute_commands VK_device_execute VK_device_created_commands
+  VK_device_recorded_commands VK_device_generated_commands
+
+2) Should we use serial tokens or redundant sequence description?
+
+  Similar to VkPipeline, signatures have the most likeliness to be
+  cross-vendor adoptable.
+  They also benefit from being processable in parallel.
+
+3) How to name sequence description
+
+  ExecuteCommandSignature a bit long, just ExecuteSignature or actually more
+  Vulkan nomenclature IndirectCommandsLayout
+
+4) Do we want to provide indirectCommands inputs with layout or at
+indirectCommands time?
+
+  Separate layout from data as Vulkan does.
+  Provide full flexibilty for indirectCommands.
+
+5) Should the input be provided as SoA or AoS?
+
+  It is desired by application to reuse the list of objects and render them
+  with some kind override.
+  This can be done by just selecting a different input for a push constant
+  or a descriptor set, if they are defined as independent arrays.
+  If the data was interleaved, this would not be as easily possible.
+
+  Allowing input divisors can also reduce the conservative command buffer
+  allocation.
+
+6) how do we know the size of the GPU command buffer generated by
+vkCmdProcessCommandsNVX ?
+
+  maxSequenceCount can give an upper estimate, even if the actual count is
+  sourced from the gpu buffer at (buffer, countOffset).
+  As such maxSequenceCount must always be set correctly.
+
+  Developers are encouraged to make well use the IndirectCommandsLayout's
+  pTokens->divisor, as they allow less conservative storage costs.
+  Especially pipeline changes on a per-draw basis can be costly memory wise.
+
+7) How to deal with dynamic offsets in DescriptorSets?
+
+  Maybe additional token VK_EXECUTE_DESCRIPTOR_SET_OFFSET_COMMAND_NVX that
+  works for a "single dynamic buffer" descriptor set and then use (32 bit
+  tableEntry + 32bit offset)
+
+added dynamicCount field, variable sized input
+
+8) Should we allow updates to the object table, similar to DescriptorSet?
+
+  Desired yes, people may change "material" shaders and not want to recreate
+  the entire register table.
+  However the developer must ensure to not overwrite a registered
+  objectindex while it is still being used.
+
+9) Should we allow dynamic state changes?
+
+  Seems a bit excessive for "per-draw" type of scenario, but GPU could
+  partition work itself with viewport/scissor...
+
+10) How do we allow re-using already "filled" indirectCommands buffers?
+
+  just use a VkCommandBuffer for the output, and it can be reused easily.
+
+11) How portable should such re-use be?
+
+  Same as secondary command buffer
+
+12) Should sequenceOrdered be part of IndirectCommandsLayout or
+vkCmdProcessCommandsNVX?
+
+  Seems better for IndirectCommandsLayout, as that is when most heavy
+  lifting in terms of internal device code generation is done.
+
+13) Under which conditions is vkCmdProcessCommandsNVX legal?
+
+  Options: a) on the host command buffer like a regular draw call b)
+     vkCmdProcessCommandsNVX makes use VkCommandBufferBeginInfo and serves
+     as vkBeginCommandBuffer/vkEndCommandBuffer implicitly.
+  c) The targetCommandbuffer must be inside the "begin" state already at the
+     moment of being passed.
+     This very likely suggests a new VkCommandBufferUsageFlags
+     VK_COMMAND_BUFFER_USAGE_DEVICE_GENERATED_BIT.
+  d) The targetCommandbuffer must reserve space via a new function.
+  
+  used a & d.
+
+14) What if different pipelines have different DescriptorSetLayouts at a
+certain set unit that mismatches in "token.dynamicCount"?
+
+  Considered legal, as long as the maximum dynamic count of all used
+  DescriptorSetLayouts is provided.
+
+15) Should we add "strides" to input arrays, so that "Array of Structures"
+type setups can be support more easily?
+
+  Maybe provide a usage flag for packed tokens stream (all inputs from same
+  buffer, implicit stride).
+  
+  No, given performance test was worse.
+
+16) Should we allow re-using the target command buffer directly, without
+need to reset command buffer?
+
+  YES: new api vkCmdReserveSpaceForCommandsNVX.
+
+17) Is vkCmdProcessCommandsNVX copying the input data or referencing it ?
+
+  There are multiple implementations possible:
+  
+  * one could have some emulation code that parse the inputs, and generates
+    an output command buffer, therefore copying the inputs.
+  * one could just reference the inputs, and have the processing done in
+    pipe at execution time.
+
+  If the data is mandated to be copied, then it puts a penalty on
+  implementation that could process the inputs directly in pipe.
+  If the data is "referenced", then it allows both types of implementation
+
+  The inputs are "referenced", and should not be modified after the call to
+  vkCmdProcessCommands and until after the rendering of the target command
+  buffer is finished.
+
+18) Why is this NVX and not NV?
+
+  To allow early experimentation and feedback.
+  We expect that a version with a refined design as multi-vendor variant
+  will follow up.
+  
+19) Should we make the availability for each token type a device limit?
+  
+  Only distinguish between graphics/compute for now, further splitting up
+  may lead to too much fractioning.
+  
+20) When can the objectTable be modified?
+  
+  Similar to the other inputs for vkCmdProcessCommandsNVX, only when all
+  device access via vkCmdProcessCommandsNVX or execution of target command
+  buffer has completed can an object at a given objectIndex be unregistered
+  or re-registered again.
+  
+21) Which buffer usage flags are required for the buffers referenced by
+vkCmdProcessCommandsNVX
+  
+  reuse existing VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT
+  
+  * VkCmdProcessCommandsInfoNVX::sequencesCountBuffer
+  * VkCmdProcessCommandsInfoNVX::sequencesIndexBuffer
+  * VkIndirectCommandsTokenNVX::buffer
+    
+22) In which pipeline stage do the device generated command expansion
+happen?
+  
+  This is required in order to allow applications to properly syncronize
+  access (e.g. via memory barriers) when writing to the buffers referenced
+  by vkCmdProcessCommandsNVX
+     
+  added VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT
+  
+23) What if most token data is "static", but we frequently want to render a
+subsection?
+  
+  added "sequencesIndexBuffer".
+  This allows to easier sort and filter what should actually be processed.
+
+=== Example Code
+
+TODO links to gameworks & designworks samples
+
+[source,c]
+---------------------------------------------------
+    
+  // setup secondary command buffer
+    vkBeginCommandBuffer(generatedCmdBuffer, &beginInfo);
+    ... setup its state as usual
+  
+  // insert the reservation (there can only be one per command buffer)
+  // where the generated calls should be filled into
+    VkCmdReserveSpaceForCommandsInfoNVX reserveInfo = { VK_STRUCTURE_TYPE_CMD_RESERVE_SPACE_FOR_COMMANDS_INFO_NVX };
+    reserveInfo.objectTable = objectTable;
+    reserveInfo.indirectCommandsLayout = deviceGeneratedLayout;
+    reserveInfo.maxSequencesCount = myCount;
+    vkCmdReserveSpaceForCommandsNVX(generatedCmdBuffer, &reserveInfo);
+
+    vkEndCommandBuffer(generatedCmdBuffer);
+    
+  // trigger the generation at some point in another primary command buffer
+    VkCmdProcessCommandsInfoNVX processInfo = { VK_STRUCTURE_TYPE_CMD_PROCESS_COMMANDS_INFO_NVX };
+    processInfo.objectTable = objectTable;
+    processInfo.indirectCommandsLayout = deviceGeneratedLayout;
+    processInfo.maxSequencesCount = myCount;
+    // set the target of the generation (if null we would directly execute with mainCmd)
+    processInfo.targetCommandBuffer = generatedCmdBuffer;
+    // provide input data
+    processInfo.indirectCommandsTokenCount = 3;
+    processInfo.pIndirectCommandsTokens = myTokens;
+    
+  // If you modify the input buffer data referenced by VkCmdProcessCommandsInfoNVX, 
+  // ensure you have added the appropriate barriers prior generation process.
+  // When regenerating the content of the same reserved space, ensure prior operations have completed
+    vkCmdPipelineBarrier   (mainCmd, VK_PIPELINE_STAGE_ALL_COMMANDS_BIT, VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX, ...);
+    
+    vkCmdProcessCommandsNVX(mainCmd, &processInfo);
+    ...
+  // execute the secondary command buffer and ensure the processing that modifies command-buffer content
+  // has completed
+    vkCmdPipelineBarrier(mainCmd, VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, ...)
+    vkCmdExecuteCommands(mainCmd, 1, &generatedCmdBuffer);
+
+---------------------------------------------------
+
+=== Version History
+
+ * Revision 1, 2016-10-31 (Christoph Kubisch)
+   - Initial draft

doc/specs/vulkan/appendices/boilerplate.txt

@@ -62,10 +62,16 @@ include::../api/flags/VkImageAspectFlags.txt[]
 include::../api/flags/VkImageCreateFlags.txt[]
 include::../api/flags/VkImageUsageFlags.txt[]
 include::../api/flags/VkImageViewCreateFlags.txt[]
+ifdef::VK_NVX_device_generated_commands[]
+include::../api/flags/VkIndirectCommandsLayoutUsageFlagsNVX.txt[]
+endif::VK_NVX_device_generated_commands[]
 include::../api/flags/VkInstanceCreateFlags.txt[]
 include::../api/flags/VkMemoryHeapFlags.txt[]
 include::../api/flags/VkMemoryMapFlags.txt[]
 include::../api/flags/VkMemoryPropertyFlags.txt[]
+ifdef::VK_NVX_device_generated_commands[]
+include::../api/flags/VkObjectEntryUsageFlagsNVX.txt[]
+endif::VK_NVX_device_generated_commands[]
 include::../api/flags/VkPipelineCacheCreateFlags.txt[]
 include::../api/flags/VkPipelineColorBlendStateCreateFlags.txt[]
 include::../api/flags/VkPipelineCreateFlags.txt[]

doc/specs/vulkan/appendices/extensions.txt

@@ -156,3 +156,14 @@ include::VK_NV_win32_keyed_mutex.txt[]
 endif::VK_NV_win32_keyed_mutex[]
 
 // :leveloffset: 1
+
+
+// == NVIDIA +NVX+ Vendor Extensions
+//
+// :leveloffset: 2
+
+ifdef::VK_NVX_device_generated_commands[]
+include::VK_NVX_device_generated_commands.txt[]
+endif::VK_NVX_device_generated_commands[]
+
+// :leveloffset: 1

doc/specs/vulkan/appendices/glossary.txt

@@ -17,6 +17,10 @@ Accessible (Descriptor Binding)::
     Descriptors using that binding can: only be used by stages in which they
     are accessible.
 
+Acquire Operation (Resource)::
+    An operation that acquires ownership of an image subresource or buffer
+    range.
+
 Adjacent Vertex::
     A vertex in an adjacency primitive topology that is not part of a given
     primitive, but is accessible in geometry shaders.
@@ -53,8 +57,12 @@ Attachment (Render Pass)::
     information about the properties of the image view that will later be
     attached.
 
+Availability Operation::
+    An operation that causes the values generated by specified memory write
+    accesses to become available for future access.
+    
 Available::
-    See Memory Dependency.
+    A state of values written to memory that allows them to be made visible.
 
 Back-Facing::
     See Facingness.
@@ -303,7 +311,7 @@ Execution Dependency::
     events, or implicit ordering operations.
 
 Execution Dependency Chain::
-    A sequence of execution dependencies that transitively act as an
+    A sequence of execution dependencies that transitively act as a single
     execution dependency.
 
 Extension Scope::
@@ -354,6 +362,23 @@ Framebuffer Coordinates::
     x and/or y, with [eq]#(0,0)# in the upper left corner and pixel centers
     at half-integers.
 
+Framebuffer-Space::
+    Operating with respect to framebuffer coordinates.
+
+Framebuffer-Local::
+    A framebuffer-local dependency guarantees that only for a single
+    framebuffer region, the first set of operations happens-before the
+    second set of operations.
+
+Framebuffer-Global::
+    A framebuffer-global dependency guarantees that for all framebuffer
+    regions, the first set of operations happens-before the second set of
+    operations.
+
+Framebuffer Region::
+    A framebuffer region is a set of sample (x, y, layer, sample)
+    coordinates that is a subset of the entire framebuffer.
+
 Front-Facing::
     See Facingness.
 
@@ -366,18 +391,18 @@ Handle::
     Each object type has a unique handle type.
 
 Happen-after::
-    A command happens-after a dependency if they are separated by an
-    execution dependency chain, with the command included in the destination
-    of the last dependency of the chain.
-    A memory barrier makes visible memory writes to commands that
-    happen-after it.
+    A transitive, irreflexive and antisymmetric ordering relation between
+    operations.
+    An execution dependency with a source of *A* and a destination of *B*
+    enforces that *B* happens-after *A*.
+    The inverse relation of happens-before.
 
 Happen-before::
-    A command happens-before a dependency if they are separated by an
-    execution dependency chain, with the command included in the source of
-    the first dependency of the chain.
-    A memory barrier makes available memory writes of commands that
-    happen-before it.
+    A transitive, irreflexive and antisymmetric ordering relation between
+    operations.
+    An execution dependency with a source of *A* and a destination of *B*
+    enforces that *A* happens-before *B*.
+    The inverse relation of happens-after.
 
 Helper Invocation::
     A fragment shader invocation that is created solely for the purposes of
@@ -444,6 +469,16 @@ Indirect Commands::
     from structures in buffer memory.
     Includes flink:vkCmdDrawIndirect, flink:vkCmdDrawIndexedIndirect, and
     flink:vkCmdDispatchIndirect.
+    
+ifdef::VK_NVX_device_generated_commands[]
+Indirect Commands Layout::
+    A definition of a sequence of commands, that are generated on the device
+    via flink:vkCmdProcessCommandsNVX.
+    Each sequence is comprised of multiple
+    sname:VkIndirectCommandsTokenTypeNVX, which represent asubset of
+    traditional command buffer commands.
+    Represented as sname:VkIndirectCommandsLayoutNVX.
+endif::VK_NVX_device_generated_commands[]
 
 Initial State (Command Buffer)::
     A command buffer that has not begun recording commands.
@@ -503,12 +538,12 @@ Mappable::
     See Host-Visible Memory.
 
 Memory Dependency::
-    A sequence of operations that makes writes available, performs an
-    execution dependency between the writes and subsequent accesses, and
-    makes available writes visible to later accesses.
-    In order for the effects of a write to be coherent with later accesses,
-    it must: be made available from the old access type and then made
-    visible to the new access type.
+    A memory dependency is an execution dependency which includes
+    availability and visibility operations such that:
+
+  * The first set of operations happens-before the availability operation
+  * The availability operation happens-before the visibility operation
+  * The visibility operation happens-before the second set of operations
 
 Memory Heap::
     A region of memory from which device memory allocations can: be made.
@@ -534,11 +569,24 @@ Normalized Device Coordinates::
     A coordinate space after perspective division is applied to clip
     coordinates, and before the viewport transformation converts to
     framebuffer coordinates.
+    
+ifdef::VK_NVX_device_generated_commands[]
+Object Table::
+    A binding table for various resources (sname:VkPipeline, sname:VkBuffer,
+    sname:VkDescriptorSet), so that they can be referenced in
+    device-generated command processing.
+    Represented as sname:VkObjectTableNVX.
+    Entries are registered or unregistered via ftext:uint32_t indices.
+endif::VK_NVX_device_generated_commands[]
 
 Overlapped Range (Aliased Range)::
     The aliased range of a device memory allocation that intersects a given
     image subresource of an image or range of a buffer.
 
+Ownership (Resource)::
+    If an entity (e.g. a queue family) has ownership of a resource, access
+    to that resource is well-defined for access by that entity.
+
 Packed Format::
     A format whose components are stored as a single data element in memory,
     with their relative locations defined within that element.
@@ -573,6 +621,10 @@ Pipeline Layout::
     setting push constant values.
     Represented by a sname:VkPipelineLayout object.
 
+Pipeline Stage::
+    A logically independent execution unit that performs some of the
+    operations defined by an action command.
+    
 Point Sampling (Rasterization)::
     A rule that determines whether a fragment sample location is covered by
     a polygon primitive by testing whether the sample location is in the
@@ -642,6 +694,10 @@ Recording State (Command Buffer)::
     A command buffer that is ready to record commands.
     See also Initial State and Executable State.
 
+Release Operation (Resource)::
+    An operation that releases ownership of an image subresource or buffer
+    range.
+    
 Render Pass::
     An object that represents a set of framebuffer attachments and phases of
     rendering using those attachments.
@@ -815,14 +871,19 @@ Viewport Transformation::
     A transformation from normalized device coordinates to framebuffer
     coordinates, based on a viewport rectangle and depth range.
 
+Visibility Operation::
+    An operation that causes available values to become visible to specified
+    memory accesses.
+    
 Visible::
-    See Memory Dependency.
+    A state of values written to memory that allows them to be accessed by a
+    set of operations.
 
 // To be added per issue 18:
 // Current State <<fundamentals-queueoperation>>
 // Barycentric Coordinates <<primsrast-polygons-basic>>
 // Internal Allocations <<memory-host-allocation-scope>>
-// Unavailable, Available <<queries-operation>>
+// Unavailable, Available <<queries-operation>> - NB: this clashes with available/visible in terms of memory
 // Signaled, Unsignaled <<synchronization-semaphores>> <<synchronization-fences>>
 // Interior Vertices <<tessellation-tessellator-spacing>>
 // Inner Vertices <<tessellation-triangle-tessellation>> <<tessellation-quad-tessellation>>

doc/specs/vulkan/chapters/VK_EXT_debug_report.txt

@@ -165,8 +165,6 @@ registered.
 .Valid Usage
 ****
   * pname:object may: be a Vulkan object
-  * pname:pLayerPrefix must: be a `NULL` terminated string
-  * pname:pMessage must: be a `NULL` terminated string
 ****
 
 include::../validity/protos/vkDebugReportMessageEXT.txt[]

doc/specs/vulkan/chapters/VK_KHR_android_surface/platformCreateSurface_android.txt

@@ -61,5 +61,10 @@ include::../../api/structs/VkAndroidSurfaceCreateInfoKHR.txt[]
   * pname:window is a pointer to the code:ANativeWindow to associate the
     surface with.
 
+.Valid Usage
+****
+  * pname:window must: point to a valid Android code:ANativeWindow.
+****
+
 include::../../validity/structs/VkAndroidSurfaceCreateInfoKHR.txt[]
 

doc/specs/vulkan/chapters/VK_KHR_mir_surface/platformCreateSurface_mir.txt

@@ -36,6 +36,12 @@ include::../../api/structs/VkMirSurfaceCreateInfoKHR.txt[]
     code:MirConnection and code:MirSurface for the window to associate the
     surface with.
 
+.Valid Usage
+****
+  * pname:connection must: point to a valid code:MirConnection.
+  * pname:surface must: point to a valid code:MirSurface.
+****
+
 include::../../validity/structs/VkMirSurfaceCreateInfoKHR.txt[]
 
 On Mir, when a swapchain's pname:imageExtent does not match the surface's

doc/specs/vulkan/chapters/VK_KHR_swapchain/wsi.txt

@@ -533,12 +533,10 @@ The fname:vkCmdWaitEvents or fname:vkCmdPipelineBarrier used to transition
 the image away from ename:VK_IMAGE_LAYOUT_PRESENT_SRC_KHR layout must: have
 pname:dstStageMask and pname:dstAccessMask parameters set based on the next
 use of the image.
-The application must: use
-<<synchronization-implicit-ordering-hostwrites,implicit ordering
-guarantees>> and
-<<synchronization-execution-and-memory-dependencies,execution dependencies>>
-to prevent the image transition from occurring before the semaphore passed
-to fname:vkAcquireNextImageKHR has signaled.
+The application must: use <<synchronization-submission-host-writes, implicit
+ordering guarantees>> and <<synchronization-dependencies,execution
+dependencies>> to prevent the image transition from occurring before the
+semaphore passed to fname:vkAcquireNextImageKHR has signaled.
 
 [NOTE]
 .Note

doc/specs/vulkan/chapters/VK_KHR_wayland_surface/platformCreateSurface_wayland.txt

@@ -35,6 +35,12 @@ include::../../api/structs/VkWaylandSurfaceCreateInfoKHR.txt[]
   * pname:display and pname:surface are pointers to the Wayland
     code:wl_display and code:wl_surface to associate the surface with.
 
+.Valid Usage
+****
+  * pname:display must: point to a valid Wayland code:wl_display.
+  * pname:surface must: point to a valid Wayland code:wl_surface.
+****
+
 include::../../validity/structs/VkWaylandSurfaceCreateInfoKHR.txt[]
 
 On Wayland, pname:currentExtent is undefined [eq]#(0,0)#.

doc/specs/vulkan/chapters/VK_KHR_win32_surface/platformCreateSurface_win32.txt

@@ -35,6 +35,12 @@ include::../../api/structs/VkWin32SurfaceCreateInfoKHR.txt[]
   * pname:hinstance and pname:hwnd are the Win32 code:HINSTANCE and
     code:HWND for the window to associate the surface with.
 
+.Valid Usage
+****
+  * pname:hinstance must: be a valid Win32 code:HINSTANCE.
+  * pname:hwnd must: be a valid Win32 code:HWND.
+****
+
 include::../../validity/structs/VkWin32SurfaceCreateInfoKHR.txt[]
 
 With Win32, pname:minImageExtent, pname:maxImageExtent, and

doc/specs/vulkan/chapters/VK_KHR_xcb_surface/platformCreateSurface_xcb.txt

@@ -38,6 +38,12 @@ include::../../api/structs/VkXcbSurfaceCreateInfoKHR.txt[]
   * pname:window is the code:xcb_window_t for the X11 window to associate
     the surface with.
 
+.Valid Usage
+****
+  * pname:connection must: point to a valid X11 code:xcb_connection_t.
+  * pname:window must: be a valid X11 code:xcb_window_t.
+****
+
 include::../../validity/structs/VkXcbSurfaceCreateInfoKHR.txt[]
 
 With Xcb, pname:minImageExtent, pname:maxImageExtent, and

doc/specs/vulkan/chapters/VK_KHR_xlib_surface/platformCreateSurface_xlib.txt

@@ -37,6 +37,12 @@ include::../../api/structs/VkXlibSurfaceCreateInfoKHR.txt[]
     server.
   * pname:window is an Xlib code:Window to associate the surface with.
 
+.Valid Usage
+****
+  * pname:dpy must: point to a valid Xlib code:Display.
+  * pname:window must: be a valid Xlib code:Window.
+****
+
 include::../../validity/structs/VkXlibSurfaceCreateInfoKHR.txt[]
 
 With Xlib, pname:minImageExtent, pname:maxImageExtent, and

doc/specs/vulkan/chapters/VK_NVX_device_generated_commands/generatedcommands.txt

@@ -0,0 +1,88 @@
+[[device-generated-commands]]
+= Device-Generated Commands
+
+This chapter discusses the generation of command buffer content on the
+device.
+These principle steps are to be taken to generate commands on the device:
+
+  * Make resource bindings accessible for the device via registering in an
+    sname:VkObjectTableNVX.
+  * Define via sname:VkIndirectCommandsLayoutNVX the sequence of commands
+    which should be generated.
+  * Fill one or more sname:VkBuffer with the appropriate content that gets
+    interpreted by sname:VkIndirectCommandsLayoutNVX.
+  * Reserve command space via flink:vkCmdReserveSpaceForCommandsNVX in a
+    secondary sname:VkCommandBuffer where the generated commands should be
+    recorded.
+  * Generate the actual commands via flink:vkCmdProcessCommandsNVX passing
+    all required data.
+
+Execution of such generated commands can either be triggered directly with
+the generation process, or by executing the secondary sname:VkCommandBuffer
+that was chosen as optional target.
+The latter allows re-using generated commands as well.
+Similar to sname:VkDescriptorSet special care must be taken for the lifetime
+of resources referenced in sname:VkObjectTableNVX, which may be accessed at
+either generation or execution time.
+
+== Features and Limitations
+
+// refBegin vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX Returns device-generated commands related properties of a physical device
+
+To query the support of related features and limitations, call:
+
+include::../../api/protos/vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX.txt[]
+
+  * pname:physicalDevice is the handle to the physical device whose
+    properties will be queried.
+  * pname:pFeatures points to an instance of the
+    slink:VkDeviceGeneratedCommandsFeaturesNVX structure, that will be
+    filled with returned information.
+  * pname:pLimits points to an instance of the
+    slink:VkDeviceGeneratedCommandsLimitsNVX structure, that will be filled
+    with returned information.
+
+include::../../validity/protos/vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX.txt[]
+
+// refBegin VkDeviceGeneratedCommandsFeaturesNVX Structure specifying physical device support
+
+The sname:VkDeviceGeneratedCommandsFeaturesNVX structure is defined as:
+
+include::../../api/structs/VkDeviceGeneratedCommandsFeaturesNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:computeBindingPointSupport indicates whether the
+    sname:VkObjectTableNVX supports entries with
+    ename:VK_OBJECT_ENTRY_USAGE_GRAPHICS_BIT_NVX bit set and
+    sname:VkIndirectCommandsLayoutNVX supports
+    ename:VK_PIPELINE_BIND_POINT_COMPUTE.
+
+include::../../validity/structs/VkDeviceGeneratedCommandsFeaturesNVX.txt[]
+
+// refBegin VkDeviceGeneratedCommandsLimitsNVX Structure specifying physical device limits
+
+The sname:VkDeviceGeneratedCommandsLimitsNVX structure is defined as:
+
+include::../../api/structs/VkDeviceGeneratedCommandsLimitsNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:maxIndirectCommandsLayoutTokenCount the maximum number of tokens
+    in sname:VkIndirectCommandsLayoutNVX.
+  * pname:maxObjectEntryCounts the maximum number of entries per resource
+    type in sname:VkObjectTableNVX.
+  * pname:minSequenceCountBufferOffsetAlignment the minimum alignment for
+    memory addresses optionally used in fname:vkCmdProcessCommandsNVX.
+  * pname:minSequenceIndexBufferOffsetAlignment the minimum alignment for
+    memory addresses optionally used in fname:vkCmdProcessCommandsNVX.
+  * pname:minCommandsTokenBufferOffsetAlignment the minimum alignment for
+    memory addresses optionally used in fname:vkCmdProcessCommandsNVX.
+
+include::../../validity/structs/VkDeviceGeneratedCommandsLimitsNVX.txt[]
+
+include::objecttable.txt[]
+
+include::indirectcommands.txt[]
+
+include::generation.txt[]

doc/specs/vulkan/chapters/VK_NVX_device_generated_commands/generation.txt

@@ -0,0 +1,173 @@
+== Indirect Commands Generation
+
+// refBegin vkCmdReserveSpaceForCommandsNVX Perform a reservation of command buffer space
+
+Command space for generated commands recorded into a secondary command
+buffer must: be reserved by calling:
+
+include::../../api/protos/vkCmdReserveSpaceForCommandsNVX.txt[]
+
+  * pname:commandBuffer is the secondary command buffer in which the space
+    for device-generated commands is reserved.
+  * pname:pProcessCommandsInfo is a pointer to an instance of the
+    slink:vkCmdReserveSpaceForCommandsNVX structure containing parameters
+    affecting the reservation of command buffer space.
+
+.Valid Usage
+****
+  * The provided pname:commandBuffer must: not have had a prior space
+    reservation since its creation or the last reset.
+  * The state of the pname:commandBuffer must: be legal to execute all
+    commands within the sequence provided by the
+    pname:indirectCommandsLayout member of pname:pProcessCommandsInfo.
+****
+
+include::../../validity/protos/vkCmdReserveSpaceForCommandsNVX.txt[]
+
+// refBegin VkCmdReserveSpaceForCommandsInfoNVX Structure specifying parameters for the reservation of command buffer space
+
+include::../../api/structs/VkCmdReserveSpaceForCommandsInfoNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:objectTable is the sname:VkObjectTableNVX to be used for the
+    generation process.
+    Only registered objects at the time
+    flink:vkCmdReserveSpaceForCommandsNVX is called, will be taken into
+    account for the reservation.
+  * pname:indirectCommandsLayout is the sname:VkIndirectCommandsLayoutNVX
+    that must: also be used at generation time.
+  * pname:maxSequencesCount is the maximum number of sequences for which
+    command buffer space will be reserved.
+
+include::../../validity/structs/VkCmdReserveSpaceForCommandsInfoNVX.txt[]
+
+The generated commands will behave as if they were recorded within the call
+to fname:vkCmdReserveSpaceForCommandsNVX, that means they can inherit state
+defined in the command buffer prior this call.
+However, given the stateless nature of the generated sequences, they will
+not affect commands after the reserved space.
+Treat the state that can: be affected by the provided
+sname:VkIndirectCommandsLayoutNVX as undefined.
+
+// refBegin vkCmdProcessCommandsNVX Performs the generation of commands on the device
+
+The actual generation on the device is handled with:
+
+include::../../api/protos/vkCmdProcessCommandsNVX.txt[]
+
+  * pname:commandBuffer is the primary command buffer in which the
+    generation process takes space.
+  * pname:pProcessCommandsInfo is a pointer to an instance of the
+    slink:VkCmdProcessCommandsInfoNVX structure containing parameters
+    affecting the processing of commands.
+
+include::../../validity/protos/vkCmdProcessCommandsNVX.txt[]
+
+// refBegin VkCmdProcessCommandsInfoNVX Structure specifying parameters for the generation of commands
+
+include::../../api/structs/VkCmdProcessCommandsInfoNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:objectTable is the sname:VkObjectTableNVX to be used for the
+    generation process.
+    Only registered objects at the time
+    flink:vkCmdReserveSpaceForCommandsNVX is called, will be taken into
+    account for the reservation.
+  * pname:indirectCommandsLayout is the sname:VkIndirectCommandsLayoutNVX
+    that provides the command sequence to generate.
+  * pname:indirectCommandsTokenCount defines the number of input tokens
+    used.
+  * pname:pIndirectCommandsTokens provides an array of
+    slink:VkIndirectCommandsTokenNVX that reference the input data for each
+    token command.
+  * pname:maxSequencesCount is the maximum number of sequences for which
+    command buffer space will be reserved.
+    If pname:sequencesCountBuffer is `NULL`, this is also the actual number
+    of sequences generated.
+  * pname:targetCommandBuffer can: be the secondary sname:VkCommandBuffer in
+    which the commands should be recorded.
+    If `NULL` an implicit reservation as well as execution takes place on
+    the processing sname:VkCommandBuffer.
+  * pname:sequencesCountBuffer can: be sname:VkBuffer from which the actual
+    amount of sequences is sourced from as ftext:uint32_t value.
+  * pname:sequencesCountOffset is the byte offset into
+    pname:sequencesCountBuffer where the count value is stored.
+  * pname:sequencesIndexBuffer must: be set if
+    pname:indirectCommandsLayout's
+    ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT is set and
+    provides the used sequence indices as ftext:uint32_t array.
+    Otherwise it must: be `NULL`.
+  * pname:sequencesIndexOffset is the byte offset into
+    pname:sequencesIndexBuffer where the index values start.
+
+
+.Valid Usage
+****
+  * The provided pname:objectTable must: include all objects referenced by
+    the generation process.
+  * pname:indirectCommandsTokenCount must match the
+    pname:indirectCommandsLayout's tokenCount.
+  * The pname:tokenType member of each entry in the
+    pname:pIndirectCommandsTokens array must match the values used at
+    creation time of pname:indirectCommandsLayout
+  * If pname:targetCommandBuffer is provided, it must have reserved command
+    space.
+  * If pname:targetCommandBuffer is provided, the pname:objectTable must:
+    match the reservation's objectTable and must: have had all referenced
+    objects registered at reservation time.
+  * If pname:targetCommandBuffer is provided, the
+    pname:indirectCommandsLayout must: match the reservation's
+    indirectCommandsLayout.
+  * If pname:targetCommandBuffer is provided, the pname:maxSequencesCount
+    must: not exceed the reservation's maxSequencesCount.
+  * If pname:sequencesCountBuffer is used, its usage flag must: have
+    ename:VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT bit set.
+  * If pname:sequencesCountBuffer is used, pname:sequencesCountOffset must
+    be aligned to
+    sname:VkDeviceGeneratedCommandsLimitsNVX::pname:minSequenceCountBufferOffsetAlignment.
+  * If pname:sequencesIndexBuffer is used, its usage flag must: have
+    ename:VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT bit set.
+  * If pname:sequencesIndexBuffer is used, pname:sequencesIndexOffset must
+    be aligned to
+    sname:VkDeviceGeneratedCommandsLimitsNVX::pname:minSequenceIndexBufferOffsetAlignment.
+****
+
+include::../../validity/structs/VkCmdProcessCommandsInfoNVX.txt[]
+
+Referencing the functions defined in <<indirectmdslayout>>,
+fname:vkCmdProcessCommandsNVX behaves as:
+
+[source,c]
+---------------------------------------------------
+// For targetCommandBuffers the existing reservedSpace is reset & overwritten.
+
+VkCommandBuffer cmd = targetCommandBuffer ?
+      targetCommandBuffer.reservedSpace :
+      commandBuffer;
+
+uint32_t sequencesCount = sequencesCountBuffer ?
+      min(maxSequencesCount, sequencesCountBuffer.load_uint32(sequencesCountOffset) :
+      maxSequencesCount;
+
+
+cmdProcessAllSequences(cmd, objectTable,
+                       indirectCommandsLayout, pIndirectCommandsTokens,
+                       sequencesCount,
+                       sequencesIndexBuffer, sequencesIndexOffset);
+
+// The stateful commands within indirectCommandsLayout will not
+// affect the state of subsequent commands in the target
+// command buffer (cmd)
+---------------------------------------------------
+
+[NOTE]
+.Note
+====
+It is important to note that the state that may be affected through
+generated commands must be considered undefined for the commands following
+them.
+It is not possible to setup generated state and provoking work that uses
+this state outside of the generated sequence.
+====

doc/specs/vulkan/chapters/VK_NVX_device_generated_commands/indirectcommands.txt

@@ -0,0 +1,329 @@
+[[indirectmdslayout]]
+== Indirect Commands Layout
+
+// refBegin VkIndirectCommandsLayoutNVX Opaque handle to an indirect commands layout object
+
+The device-side command generation happens through an iterative processing
+of an atomic sequence comprised of command tokens, which are represented by:
+
+include::../../api/handles/VkIndirectCommandsLayoutNVX.txt[]
+
+// refEnd VkIndirectCommandsLayoutNVX
+
+
+=== Tokenized Command Processing
+
+The processing is in principle illustrated below:
+
+[source,c]
+---------------------------------------------------
+void cmdProcessSequence(cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, s)
+{
+  for (c = 0; c < indirectCommandsLayout.tokenCount; c++)
+  {
+    indirectCommandsLayout.pTokens[c].command (cmd, objectTable, pIndirectCommandsTokens[c], s);
+  }
+}
+
+void cmdProcessAllSequences(cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, sequencesCount)
+{
+  for (s = 0; s < sequencesCount; s++)
+  {
+    cmdProcessSequence(cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, s);
+  }
+}
+---------------------------------------------------
+
+The processing of each sequence is considered stateless, therefore all state
+changes must occur prior work provoking commands within the sequence.
+A single sequence is either strictly targeting
+sname:VK_PIPELINE_BIND_POINT_GRAPHICS or
+ename:VK_PIPELINE_BIND_POINT_COMPUTE.
+
+The primary input data for each token is provided through sname:VkBuffer
+content at command generation time using flink:vkCmdProcessCommandsNVX,
+however some functional arguments, for example binding sets, are specified
+at layout creation time.
+The input size is different for each token.
+
+// refBegin VkIndirectCommandsTokenTypeNVX Enum specifying
+
+The following tokens exist:
+
+include::../../api/enums/VkIndirectCommandsTokenTypeNVX.txt[]
+
+.Supported indirect command tokens
+[width="80%",cols="67%,33%",options="header",align="center"]
+|====
+|Token type                                                 | Equivalent command
+|ename:VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX              | fname:vkCmdBindPipeline
+|ename:VK_INDIRECT_COMMANDS_TOKEN_DESCRIPTOR_SET_NVX        | fname:vkCmdBindDescriptorSets
+|ename:VK_INDIRECT_COMMANDS_TOKEN_INDEX_BUFFER_NVX          | fname:vkCmdBindIndexBuffer
+|ename:VK_INDIRECT_COMMANDS_TOKEN_VERTEX_BUFFER_NVX         | fname:vkCmdBindVertexBuffers
+|ename:VK_INDIRECT_COMMANDS_TOKEN_PUSH_CONSTANT_NVX         | fname:vkCmdPushConstants
+|ename:VK_INDIRECT_COMMANDS_TOKEN_DRAW_INDEXED_NVX          | fname:vkCmdDrawIndexedIndirect
+|ename:VK_INDIRECT_COMMANDS_TOKEN_DRAW_NVX                  | fname:vkCmdDrawIndirect
+|ename:VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX              | fname:vkCmdDispatchIndirect
+|====
+
+// refBegin VkIndirectCommandsLayoutTokenNVX Struct specifying the details of an indirect command layout token
+
+The sname:VkIndirectCommandsLayoutTokenNVX structure specifies details to
+the function arguments that need to be known at layout creation time:
+
+include::../../api/structs/VkIndirectCommandsLayoutTokenNVX.txt[]
+
+ * pname:type specifies the token command type.
+ * pname:bindingUnit has a different meaning depending on the type, please
+   refer pseudo code further down for details.
+ * pname:dynamicCount has a different meaning depending on the type, please
+   refer pseudo code further down for details.
+ * pname:divisor defines the rate at which the input data buffers are
+   accessed.
+
+.Valid Usage
+****
+  * pname:bindingUnit must stay within device supported limits for the
+    appropriate commands.
+  * pname:dynamicCount must stay within device supported limits for the
+    appropriate commands.
+  * pname:divisor must greater '0' and power of two.
+****
+
+include::../../validity/structs/VkIndirectCommandsLayoutTokenNVX.txt[]
+
+// refBegin VkIndirectCommandsTokenNVX Structure specifying parameters for the reservation of command buffer space
+
+The sname:VkIndirectCommandsTokenNVX structure specifies the input data for
+a token at processing time.
+
+include::../../api/structs/VkIndirectCommandsTokenNVX.txt[]
+
+  * pname:tokenType specifies the token command type.
+  * pname:buffer specifies the sname:VkBuffer storing the functional
+    arguments for each squence.
+    These argumetns can be written by the device.
+  * pname:offset specified an offset into pname:buffer where the arguments
+    start.
+
+.Valid Usage
+****
+  * The pname:buffer's usage flag must: have the
+    ename:VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT bit set.
+  * The pname:offset must: be aligned to
+    sname:VkDeviceGeneratedCommandsLimitsNVX::pname:minCommandsTokenBufferOffsetAlignment.
+****
+
+include::../../validity/structs/VkIndirectCommandsTokenNVX.txt[]
+
+
+The following code provides detailed information on how an individual
+sequence is processed:
+
+[source,c]
+---------------------------------------------------
+void cmdProcessSequence(cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, s)
+{
+  for (uint32_t c = 0; c < indirectCommandsLayout.tokenCount; c++){
+    input   = pIndirectCommandsTokens[c];
+    i       = s / indirectCommandsLayout.pTokens[c].divisor;
+
+    switch(input.type){
+      VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX:
+        size_t    stride  = sizeof(uint32_t);
+        uint32_t* data    = input.buffer.pointer( input.offset + stride * i );
+        uint32_t  object  = data[0];
+
+        vkCmdBindPipeline(cmd, indirectCommandsLayout.pipelineBindPoint,
+          objectTable.pipelines[ object ].pipeline);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_DESCRIPTOR_SET_NVX:
+        size_t    stride  = sizeof(uint32_t) + sizeof(uint32_t) * indirectCommandsLayout.pTokens[c].dynamicCount;
+        uint32_t* data    = input.buffer.pointer( input.offset + stride * i);
+        uint32_t  object  = data[0];
+
+        vkCmdBindDescriptorSets(cmd, indirectCommandsLayout.pipelineBindPoint,
+          objectTable.descriptorsets[ object ].layout,
+          indirectCommandsLayout.pTokens[ c ].bindingUnit,
+          1, &objectTable.descriptorsets[ object ].descriptorSet,
+          indirectCommandsLayout.pTokens[ c ].dynamicCount, data + 1);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_PUSH_CONSTANT_NVX:
+        size_t    stride  = sizeof(uint32_t) + sizeof(uint32_t) * indirectCommandsLayout.pTokens[c].dynamicCount;
+        uint32_t* data    = input.buffer.pointer( input.offset + stride * i );
+        uint32_t  object  = data[0];
+
+        vkCmdPushConstants(cmd,
+          objectTable.pushconstants[ object ].layout,
+          objectTable.pushconstants[ object ].stageFlags,
+          indirectCommandsLayout.pTokens[ c ].bindingUnit, indirectCommandsLayout.pTokens[c].dynamicCount, data + 1);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_INDEX_BUFFER_NVX:
+        size_t   s tride  = sizeof(uint32_t) + sizeof(uint32_t) * indirectCommandsLayout.pTokens[c].dynamicCount;
+        uint32_t* data    = input.buffer.pointer( input.offset + stride * i );
+        uint32_t  object  = data[0];
+
+        vkCmdBindIndexBuffer(cmd,
+          objectTable.vertexbuffers[ object ].buffer,
+          indirectCommandsLayout.pTokens[ c ].dynamicCount ? data[1] : 0,
+          objectTable.vertexbuffers[ object ].indexType);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_VERTEX_BUFFER_NVX:
+        size_t    stride  = sizeof(uint32_t) + sizeof(uint32_t) * indirectCommandsLayout.pTokens[c].dynamicCount;
+        uint32_t* data    = input.buffer.pointer( input.offset + stride * i );
+        uint32_t  object  = data[0];
+
+        vkCmdBindVertexBuffers(cmd,
+          indirectCommandsLayout.pTokens[ c ].bindingUnit, 1,
+          &objectTable.vertexbuffers[ object ].buffer,
+          indirectCommandsLayout.pTokens[ c ].dynamicCount ? data + 1 : {0}); // device size handled as uint32_t
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_DRAW_INDEXED_NVX:
+        vkCmdDrawIndexedIndirect(cmd,
+          input.buffer,
+          sizeof(VkDrawIndexedIndirectCommand) * i + input.offset, 1, 0);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_DRAW_NVX:
+        vkCmdDrawIndirect(cmd,
+          input.buffer,
+          sizeof(VkDrawIndirectCommand) * i  + input.offset, 1, 0);
+      break;
+
+      VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX:
+        vkCmdDispatchIndirect(cmd,
+          input.buffer,
+          sizeof(VkDispatchIndirectCommand) * i  + input.offset);
+      break;
+    }
+  }
+}
+---------------------------------------------------
+
+=== Creation and Deletion
+
+Indirect command layouts are created by:
+
+include::../../api/protos/vkCreateIndirectCommandsLayoutNVX.txt[]
+
+  * pname:device is the logical device that creates the object table.
+  * pname:pCreateInfo is a pointer to an instance of the
+    sname:VkObjectTableCreateInfoNVX structure containing parameters
+    affecting creation of the table.
+  * pname:pAllocator controls host memory allocation as described in the
+    <<memory-allocation, Memory Allocation>> chapter.
+  * pname:pIndirectCommandsLayout points to a sname:VkObjectTableNVX handle
+    in which the resulting object table is returned.
+
+include::../../validity/protos/vkCreateIndirectCommandsLayoutNVX.txt[]
+
+// refBegin VkIndirectCommandsLayoutCreateInfoNVX Structure specifying the parameters of a newly created indirect commands layout object
+
+The sname:VkIndirectCommandsLayoutCreateInfoNVX structure is defined as:
+
+include::../../api/structs/VkIndirectCommandsLayoutCreateInfoNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:pipelineBindPoint is the sname:VkPipelineBindPoint that this
+    layout targets.
+  * pname:flags is a bitmask providing usage hints of this layout.
+    See elink:VkIndirectCommandsLayoutUsageFlagBitsNVX below for a
+    description of the supported bits.
+  * pname:tokenCount is the length of the individual command sequnce.
+  * pname:pTokens is an array describing each command token in detail.
+    See elink:VkIndirectCommandsTokenTypeNVX and
+    slink:VkIndirectCommandsLayoutTokenNVX below for details.
+
+// refBegin VkIndirectCommandsLayoutUsageFlagBitsNVX Bitmask specifying allowed usage of a indirect commands layout
+
+Bits which can: be set in pname:flags are:
+
+include::../../api/enums/VkIndirectCommandsLayoutUsageFlagBitsNVX.txt[]
+
+  * ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NVX
+    indicates that the processing of sequences can: happen at an
+    implementation-dependent order, which is not guaranteed to be coherent
+    across multiple invocations.
+  * ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_SPARSE_SEQUENCES_BIT_NVX
+    indicates that there is likely a high difference between allocated
+    number of sequences and actually used.
+  * ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_EMPTY_EXECUTIONS_BIT_NVX
+    indicates that there is likely many draw or dispatch calls that are
+    zero-sized (zero grid dimension, no primitives to render).
+  * ename:VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NVX
+    indicates that the input data for the sequences is not implicitly
+    indexed from 0..sequencesUsed but a user provided sname:VkBuffer
+    encoding the index is provided.
+
+The following code illustrates some of the key flags:
+
+[source,c]
+---------------------------------------------------
+void cmdProcessAllSequences(cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, sequencesCount, indexbuffer, indexbufferoffset)
+{
+  for (s = 0; s < sequencesCount; s++)
+  {
+    sequence = s;
+
+    if (indirectCommandsLayout.flags & VK_INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NVX) {
+      sequence = incoherent_implementation_dependent_permutation[ sequence ];
+    }
+    if (indirectCommandsLayout.flags & VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NVX) {
+      sequence = indexbuffer.load_uint32( sequence * sizeof(uint32_t) + indexbufferoffset);
+    }
+
+    cmdProcessSequence( cmd, objectTable, indirectCommandsLayout, pIndirectCommandsTokens, sequence );
+  }
+}
+---------------------------------------------------
+
+.Valid Usage
+****
+  * pname:tokenCount must: be greater than `0` and below
+    sname:VkDeviceGeneratedCommandsLimitsNVX::pname:maxIndirectCommandsLayoutTokenCount
+  * If the
+    sname:VkDeviceGeneratedCommandsFeaturesNVX::pname:computeBindingPointSupport
+    feature is not enabled, then pname:pipelineBindPoint must: not be
+    ename:VK_PIPELINE_BIND_POINT_COMPUTE
+  * If pname:pTokens contains an entry of
+    ename:VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX it must: be the first
+    element of the array and there must: be only a single element of such
+    token type.
+  * All state binding tokens in pname:pTokens must: occur prior work
+    provoking tokens (ename:VK_INDIRECT_COMMANDS_TOKEN_DRAW_NVX,
+    ename:VK_INDIRECT_COMMANDS_TOKEN_DRAW_INDEXED_NVX,
+    ename:VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX).
+  * The content of pname:pTokens must: include at least one work provoking
+    token.
+****
+
+include::../../validity/structs/VkIndirectCommandsLayoutCreateInfoNVX.txt[]
+
+// refBegin vkDestroyIndirectCommandsLayoutNVX Destroy a object table
+
+Indirect command layouts are destroyed by:
+
+include::../../api/protos/vkDestroyIndirectCommandsLayoutNVX.txt[]
+
+  * pname:device is the logical device that destroys the layout.
+  * pname:indirectCommandsLayout is the table to destroy.
+  * pname:pAllocator controls host memory allocation as described in the
+    <<memory-allocation, Memory Allocation>> chapter.
+
+.Valid Usage
+****
+  * All submitted commands that refer to pname:indirectCommandsLayout must:
+    have completed execution
+  * If sname:VkAllocationCallbacks were provided when pname:objectTable was
+    created, a compatible set of callbacks must: be provided here
+  * If no sname:VkAllocationCallbacks were provided when pname:objectTable
+    was created, pname:pAllocator must: be `NULL`
+****
+
+include::../../validity/protos/vkDestroyIndirectCommandsLayoutNVX.txt[]

doc/specs/vulkan/chapters/VK_NVX_device_generated_commands/objecttable.txt

@@ -0,0 +1,299 @@
+== Binding Object Table
+
+// refBegin VkObjectTableNVX Opaque handle to an object table
+
+The device-side bindings are registered inside a table:
+
+include::../../api/handles/VkObjectTableNVX.txt[]
+
+// refEnd VkObjectTableNVX
+
+This is required as the CPU-side object pointers, for example when binding a
+sname:VkPipeline or sname:VkDescriptorSet, cannot be used by the device.
+The combination of sname:VkObjectTableNVX and ftext:uint32_t table indices
+stored inside a sname:VkBuffer serve that purpose during device command
+generation.
+
+At creation time the table is defined with a fixed amount of registration
+slots for the individual resource types.
+A detailed resource binding can then later be registered via
+flink:vkRegisterObjectsNVX at any ftext:uint32_t index below the allocated
+maximum.
+
+=== Table Creation
+
+To create object tables, call:
+
+include::../../api/protos/vkCreateObjectTableNVX.txt[]
+
+  * pname:device is the logical device that creates the object table.
+  * pname:pCreateInfo is a pointer to an instance of the
+    sname:VkObjectTableCreateInfoNVX structure containing parameters
+    affecting creation of the table.
+  * pname:pAllocator controls host memory allocation as described in the
+    <<memory-allocation, Memory Allocation>> chapter.
+  * pname:pObjectTable points to a sname:VkObjectTableNVX handle in which
+    the resulting object table is returned.
+
+include::../../validity/protos/vkCreateObjectTableNVX.txt[]
+
+// refBegin VkObjectTableCreateInfoNVX Structure specifying the parameters of a newly created object table
+
+The sname:VkObjectTableCreateInfoNVX structure is defined as:
+
+include::../../api/structs/VkObjectTableCreateInfoNVX.txt[]
+
+  * pname:sType is the type of this structure.
+  * pname:pNext is `NULL` or a pointer to an extension-specific structure.
+  * pname:objectCount is the number of entry configurations that the object
+    table supports.
+    The following array parameters must match the size provided here.
+  * pname:pObjectEntryTypes is an array of elink:VkObjectEntryTypeNVX
+    providing the entry type of a given configuration.
+  * pname:pObjectEntryCounts is an array of counts how many objects can be
+    registered in the table.
+  * pname:pObjectEntryUsageFlags is an array of bitmasks describing the
+    binding usage of the entry.
+    See elink:VkObjectEntryUsageFlagBitsNVX below for a description of the
+    supported bits.
+  * pname:maxUniformBuffersPerDescriptor is the maximum number of
+    ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER or
+    ename:VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC used by any single
+    registered sname:VkDescriptorSet in this table.
+  * pname:maxStorageBuffersPerDescriptor is the maximum number of
+    ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or
+    ename:VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC used by any single
+    registered sname:VkDescriptorSet in this table.
+  * pname:maxStorageImagesPerDescriptor is the maximum number of
+    ename:VK_DESCRIPTOR_TYPE_STORAGE_IMAGE or
+    ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER used by any single
+    registered sname:VkDescriptorSet in this table.
+  * pname:maxSampledImagesPerDescriptor is the maximum number of
+    ename:VK_DESCRIPTOR_TYPE_SAMPLER,
+    ename:VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER,
+    ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER or
+    ename:VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT used by any single registered
+    sname:VkDescriptorSet in this table.
+  * pname:maxPipelineLayouts is the maximum number of unique
+    sname:VkPipelineLayout used by any registered sname:VkDescriptorSet or
+    sname:VkPipeline in this table.
+
+// refBegin VkObjectEntryTypeNVX Enum specifying object table entry type
+
+Types which can: be set in pname:pObjectEntryTypes are:
+
+include::../../api/enums/VkObjectEntryTypeNVX.txt[]
+
+ * ename:VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX indicates a
+   sname:VkDescriptorSet resource entry that is registered via
+   sname:VkObjectTableDescriptorSetEntryNVX.
+ * ename:VK_OBJECT_ENTRY_PIPELINE_NVX indicates a sname:VkPipeline resource
+   entry that is registered via sname:VkObjectTablePipelineEntryNVX.
+ * ename:VK_OBJECT_ENTRY_INDEX_BUFFER_NVX indicates a sname:VkBuffer
+   resource entry that is registered via
+   sname:VkObjectTableIndexBufferEntryNVX.
+ * ename:VK_OBJECT_ENTRY_VERTEX_BUFFER_NVX indicates a sname:VkBuffer
+   resource entry that is registered via
+   sname:VkObjectTableVertexBufferEntryNVX.
+ * ename:VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX indicates the resource entry is
+   registered via sname:VkObjectTablePushConstantEntryNVX.
+
+// refBegin VkObjectEntryUsageFlagBitsNVX Bitmask specifying allowed usage of an object entry
+
+Bits which can: be set in pname:pObjectEntryUsageFlags are:
+
+include::../../api/enums/VkObjectEntryUsageFlagBitsNVX.txt[]
+
+  * ename:VK_OBJECT_ENTRY_USAGE_GRAPHICS_BIT_NVX indicates that the resource
+    is bound to ename:VK_PIPELINE_BIND_POINT_GRAPHICS
+  * ename:VK_OBJECT_ENTRY_USAGE_COMPUTE_BIT_NVX indicates that the resource
+    is bound to ename:VK_PIPELINE_BIND_POINT_COMPUTE
+
+.Valid Usage
+****
+  * pname:objectCount must: be greater than `0`
+  * If the
+    sname:VkDeviceGeneratedCommandsFeaturesNVX::pname:computeBindingPointSupport
+    feature is not enabled, pname:pObjectEntryUsageFlags must: not contain
+    ename:VK_OBJECT_ENTRY_USAGE_COMPUTE_BIT_NVX
+  * Any value within pname:pObjectEntryCounts must not exceed
+    sname:VkDeviceGeneratedCommandsLimitsNVX::pname:maxObjectEntryCounts
+  * pname:maxUniformBuffersPerDescriptor must be within the limits supported
+    by the device.
+  * pname:maxStorageBuffersPerDescriptor must be within the limits supported
+    by the device.
+  * pname:maxStorageImagesPerDescriptor must be within the limits supported
+    by the device.
+  * pname:maxSampledImagesPerDescriptor must be within the limits supported
+    by the device.
+****
+
+include::../../validity/structs/VkObjectTableCreateInfoNVX.txt[]
+
+// refBegin vkDestroyObjectTableNVX Destroy a object table
+
+To destroy an object table, call:
+
+include::../../api/protos/vkDestroyObjectTableNVX.txt[]
+
+  * pname:device is the logical device that destroys the table.
+  * pname:objectTable is the table to destroy.
+  * pname:pAllocator controls host memory allocation as described in the
+    <<memory-allocation, Memory Allocation>> chapter.
+
+.Valid Usage
+****
+  * All submitted commands that refer to pname:objectTable must: have
+    completed execution.
+  * If sname:VkAllocationCallbacks were provided when pname:objectTable was
+    created, a compatible set of callbacks must: be provided here.
+  * If no sname:VkAllocationCallbacks were provided when pname:objectTable
+    was created, pname:pAllocator must: be `NULL`.
+****
+
+include::../../validity/protos/vkDestroyObjectTableNVX.txt[]
+
+=== Registering Objects
+
+Resource bindings of Vulkan objects are registered at an arbitrary
+ftext:uint32_t index within an object table.
+As long as the object table references such objects, they must not be
+deleted.
+
+include::../../api/protos/vkRegisterObjectsNVX.txt[]
+
+  * pname:device is the logical device that creates the object table.
+  * pname:objectTable is the table for which the resources are registered.
+  * pname:objectCount is the number of resources to register.
+  * pname:ppObjectTableEntries provides an array for detailed binding
+    informations, each array element is a pointer to a struct of type
+    sname:VkObjectTablePipelineEntryNVX,
+    sname:VkObjectTableDescriptorSetEntryNVX,
+    sname:VkObjectTableVertexBufferEntryNVX,
+    sname:VkObjectTableIndexBufferEntryNVX or
+    sname:VkObjectTablePushConstantEntryNVX (see below for details).
+  * pname:pObjectIndices are the indices at which each resource is
+    registered.
+
+.Valid Usage
+****
+  * The contents of pname:pObjectTableEntry must yield plausible bindings
+    supported by the device.
+  * At any pname:pObjectIndices there must: not be a registered resource
+    already.
+  * Any value inside pname:pObjectIndices must: be below the appropriate
+    sname:VkObjectTableCreateInfoNVX::pname:pObjectEntryCounts limits
+    provided at pname:objectTable creation time.
+****
+
+include::../../validity/protos/vkRegisterObjectsNVX.txt[]
+
+Common to all resource entries are:
+
+include::../../api/structs/VkObjectTableEntryNVX.txt[]
+
+  * pname:type defines the entry type
+  * pname:flags defines which sname:VkPipelineBindPoint the resource can be
+    used with.
+    Some entry types allow only a single flag to be set.
+
+.Valid Usage
+****
+  * If the
+    sname:VkDeviceGeneratedCommandsFeaturesNVX::pname:computeBindingPointSupport
+    feature is not enabled, pname:flags must: not contain
+    ename:VK_OBJECT_ENTRY_USAGE_COMPUTE_BIT_NVX
+****
+
+include::../../validity/structs/VkObjectTableEntryNVX.txt[]
+
+include::../../api/structs/VkObjectTablePipelineEntryNVX.txt[]
+
+  * pname:pipeline specifies the sname:VkPipeline that this resource entry
+    references.
+
+.Valid Usage
+****
+  * pname:type must be ename:VK_OBJECT_ENTRY_PIPELINE_NVX
+****
+
+include::../../validity/structs/VkObjectTablePipelineEntryNVX.txt[]
+
+include::../../api/structs/VkObjectTableDescriptorSetEntryNVX.txt[]
+
+  * pname:layout specifies the sname:VkPipelineLayout that the
+    pname:descriptorSet is used with.
+  * pname:descriptorSet specifies the sname:VkDescriptorSet that can be
+    bound with this entry.
+
+.Valid Usage
+****
+  * pname:type must be ename:VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX
+****
+
+include::../../validity/structs/VkObjectTableDescriptorSetEntryNVX.txt[]
+
+include::../../api/structs/VkObjectTableVertexBufferEntryNVX.txt[]
+
+  * pname:buffer specifies the sname:VkBuffer that can be bound as vertex
+    bufer
+
+.Valid Usage
+****
+  * pname:type must be ename:VK_OBJECT_ENTRY_VERTEX_BUFFER_NVX
+****
+
+include::../../validity/structs/VkObjectTableVertexBufferEntryNVX.txt[]
+
+include::../../api/structs/VkObjectTableIndexBufferEntryNVX.txt[]
+
+  * pname:buffer specifies the sname:VkBuffer that can be bound as index
+    buffer
+  * pname:indexType specifies the sname:VkIndexType used with this index
+    buffer
+
+.Valid Usage
+****
+  * pname:type must be ename:VK_OBJECT_ENTRY_INDEX_BUFFER_NVX
+****
+
+include::../../validity/structs/VkObjectTableIndexBufferEntryNVX.txt[]
+
+include::../../api/structs/VkObjectTablePushConstantEntryNVX.txt[]
+
+  * pname:layout specifies the sname:VkPipelineLayout that pushconstants
+    using this pname:objectIndex are used with.
+  * pname:descriptorSet stageFlags the sname:VkShaderStageFlags that
+    pushconstants using this pname:objectIndex are used with.
+
+.Valid Usage
+****
+  * pname:type must be ename:VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX
+****
+
+include::../../validity/structs/VkObjectTablePushConstantEntryNVX.txt[]
+
+Using the following command to unregister resources from an object table:
+
+include::../../api/protos/vkUnregisterObjectsNVX.txt[]
+
+  * pname:device is the logical device that creates the object table.
+  * pname:objectTable is the table from which the resources are
+    unregistered.
+  * pname:objectCount is the number of resources being removed from the
+    object table.
+  * pname:pObjectEntryType provides an array of sname:VkObjectEntryTypeNVX
+    for the resources being removed.
+  * pname:pObjectIndices provides the array of object indices to be removed.
+
+.Valid Usage
+****
+  * At any pname:pObjectIndices there must: be a registered resource
+    already.
+  * The pname:pObjectEntryTypes of the resource at pname:pObjectIndices
+    must: match.
+  * All operations on the device using the registered resource must have
+    been completed.
+****
+
+include::../../validity/protos/vkUnregisterObjectsNVX.txt[]

doc/specs/vulkan/chapters/VK_NV_external_memory/allocate_memory.txt

@@ -3,7 +3,7 @@ instance, add a slink:VkExportMemoryAllocateInfoNV structure to the
 pname:pNext chain of the slink:VkMemoryAllocateInfo structure, specifying
 the handle types that may: be exported.
 
-The slink:VkMemoryAllocateInfo structure is defined as:
+The slink:VkExportMemoryAllocateInfoNV structure is defined as:
 
 include::../../api/structs/VkExportMemoryAllocateInfoNV.txt[]
 

doc/specs/vulkan/chapters/cmdbuffers.txt

@@ -523,6 +523,11 @@ Once recording starts, an application records a sequence of commands
 (ftext:vkCmd*) to set state in the command buffer, draw, dispatch, and other
 commands.
 
+ifdef::VK_NVX_device_generated_commands[]
+Several commands can also be recorded indirectly from sname:VkBuffer
+content, see <<device-generated-commands>>.
+endif::VK_NVX_device_generated_commands[]
+
 // refBegin vkEndCommandBuffer Finish recording a command buffer
 
 To complete recording of a command buffer, call:
@@ -581,6 +586,8 @@ possible.
 fname:vkQueueSubmit is a <<devsandqueues-submission,queue submission
 command>>, with each batch defined by an element of pname:pSubmits as an
 instance of the slink:VkSubmitInfo structure.
+Batches begin execution in the order they appear in pname:pSubmits, but may:
+complete out of order.
 
 Fence and semaphore operations submitted with flink:vkQueueSubmit have
 additional ordering constraints compared to other submission commands, with
@@ -600,6 +607,11 @@ operation>> section of <<synchronization, the synchronization chapter>>.
   * If pname:fence is not dlink:VK_NULL_HANDLE, pname:fence must: not be
     associated with any other queue command that has not yet completed
     execution on that queue
+  * Any calls to flink:vkCmdSetEvent, flink:vkCmdResetEvent or
+    flink:vkCmdWaitEvents that have been recorded into any of the command
+    buffer elements of the pname:pCommandBuffers member of any element of
+    pname:pSubmits, must: not reference any slink:VkEvent that is referenced
+    by any of those commands that is pending execution on another queue.
 ****
 
 include::../validity/protos/vkQueueSubmit.txt[]
@@ -764,8 +776,9 @@ ename:VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT.
     in
   * If fname:vkCmdExecuteCommands is being called within a render pass
     instance, any given element of pname:pCommandBuffers must: have been
-    recorded with a render pass that is compatible with the current render
-    pass - see <<renderpass-compatibility>>
+    recorded with slink:VkCommandBufferInheritanceInfo::pname:renderPass set
+    to a render pass that is <<renderpass-compatibility,compatible>> with
+    the current render pass.
   * If fname:vkCmdExecuteCommands is being called within a render pass
     instance, and any given element of pname:pCommandBuffers was recorded
     with sname:VkCommandBufferInheritanceInfo::pname:framebuffer not equal

doc/specs/vulkan/chapters/fundamentals.txt

@@ -159,12 +159,12 @@ individual batches can be expressed with
 Before a fence or semaphore is signaled, it is guaranteed that any
 previously submitted queue operations have completed execution, and that
 memory writes from those queue operations are
-<<synchronization-execution-and-memory-dependencies-available-and-visible,available>>
-to future queue operations.
+<<synchronization-dependencies-available-and-visible,available>> to future
+queue operations.
 Waiting on a signaled semaphore or fence guarantees that previous writes
 that are available are also
-<<synchronization-execution-and-memory-dependencies-available-and-visible,visible>>
-to subsequent commands.
+<<synchronization-dependencies-available-and-visible,visible>> to subsequent
+commands.
 
 Command buffer boundaries, both between primary command buffers of the same
 or different batches or submissions as well as between primary and secondary
@@ -211,13 +211,13 @@ In general, action commands are those commands that alter framebuffer
 attachments, read/write buffer or image memory, or write to query pools.
 
 Synchronization commands introduce explicit
-<<synchronization-execution-and-memory-dependencies,execution and memory
-dependencies>> between two sets of action commands, where the second set of
-commands depends on the first set of commands.
+<<synchronization-dependencies,execution and memory dependencies>> between
+two sets of action commands, where the second set of commands depends on the
+first set of commands.
 These dependencies enforce that both the execution of certain
-<<synchronization-pipeline-stage-flags,pipeline stages>> in the later set
-occur after the execution of certain stages in the source set, and that the
-effects of <<synchronization-global-memory-barrier,memory accesses>>
+<<synchronization-pipeline-stages, pipeline stages>> in the later set occur
+after the execution of certain stages in the source set, and that the
+effects of <<synchronization-global-memory-barriers,memory accesses>>
 performed by certain pipeline stages occur in order and are visible to each
 other.
 When not enforced by an explicit dependency or otherwise forbidden by the
@@ -347,6 +347,10 @@ buffers using the object are recording or pending execution:
   * sname:VkCommandPool
   * sname:VkDeviceMemory
   * sname:VkDescriptorSet
+ifdef::VK_NVX_device_generated_commands[]
+  * sname:VkObjectTableNVX
+  * sname:VkIndirectCommandsLayout
+endif::VK_NVX_device_generated_commands[]
 
 The following Vulkan objects must: not be destroyed while any queue is
 executing commands that use the object:

doc/specs/vulkan/chapters/memory.txt

@@ -876,8 +876,8 @@ The application must: guarantee that any previously submitted command that
 writes to this range has completed before the host reads from or writes to
 that range, and that any previously submitted command that reads from that
 range has completed before the host writes to that region (see
-<<synchronization-fences-devicewrites, here>> for details on fulfilling such
-a guarantee).
+<<synchronization-submission-host-writes, here>> for details on fulfilling
+such a guarantee).
 If the device memory was allocated without the
 ename:VK_MEMORY_PROPERTY_HOST_COHERENT_BIT set, these guarantees must: be
 made for an extended range: the application must: round down the start of
@@ -944,6 +944,14 @@ It must: be called after the host writes to non-coherent memory have
 completed and before command buffers that will read or write any of those
 memory locations are submitted to a queue.
 
+[NOTE]
+.Note
+====
+Unmapping non-coherent memory does not implicitly flush the mapped memory,
+and host writes that have not been flushed may: not ever be visible to the
+device.
+====
+
 include::../validity/protos/vkFlushMappedMemoryRanges.txt[]
 
 // refBegin vkInvalidateMappedMemoryRanges Invalidate ranges of mapped memory objects
@@ -966,6 +974,14 @@ write any of those locations.
 If a range of non-coherent memory is written by the host and then
 invalidated without first being flushed, its contents are undefined.
 
+[NOTE]
+.Note
+====
+Mapping non-coherent memory does not implicitly invalidate the mapped
+memory, and device writes that have not been invalidated must: be made
+visible before the host reads or overwrites them.
+====
+
 include::../validity/protos/vkInvalidateMappedMemoryRanges.txt[]
 
 // refBegin VkMappedMemoryRange Structure specifying a mapped memory range
@@ -1004,8 +1020,7 @@ ifdef::editing-notes[]
 .editing-note
 ====
 TODO (Tobias) - There's a circular section reference between this next
-section and the <<synchronization-fences-devicewrites,synchronization
-section>>.
+section and the <<synchronization-fences-waiting,synchronization section>>.
 The information is all covered by both places, but it seems a bit weird to
 have them reference each other.
 Not sure how to resolve it.
@@ -1020,15 +1035,15 @@ management operations to achieve coherency.
 For host writes to be seen by subsequent command buffer operations, a
 pipeline barrier from a source of ename:VK_ACCESS_HOST_WRITE_BIT and
 ename:VK_PIPELINE_STAGE_HOST_BIT to a destination of the relevant device
-pipeline stages and access types must: be performed.
+<<synchronization-pipeline-stages, pipeline stages>> and
+<<synchronization-access-types, access types>> must: be performed.
 Note that such a barrier is performed
-<<synchronization-implicit-ordering-hostwrites,implicitly>> upon each
-command buffer submission, so an explicit barrier is only rarely needed
-(e.g. if a command buffer waits upon an event signaled by the host, where
-the host wrote some data after submission).
-For device writes to be seen by subsequent host reads, a pipeline barrier is
-required: to <<synchronization-fences-devicewrites,make the writes
-visible>>.
+<<synchronization-submission-host-writes,implicitly>> upon each command
+buffer submission, so an explicit barrier is only rarely needed (e.g. if a
+command buffer waits upon an event signaled by the host, where the host
+wrote some data after submission).
+A pipeline barrier is required: to make writes visible to subsequent reads
+on the host.
 
 // refBegin vkUnmapMemory Unmap a previously mapped memory object
 

doc/specs/vulkan/chapters/primsrast.txt

@@ -172,23 +172,27 @@ that sample location:
   * occlusion queries
   * blending, logic op and color write
 
-ifndef::VK_AMD_rasterization_order[]
-Rasterization order must: follow <<fundamentals-queueoperation-apiorder,API
-order>>.
-endif::VK_AMD_rasterization_order[]
+Each of these operations is atomically executed for each primitive and
+sample location.
 
+Execution of these operations for each primitive in a subpass occurs in
+ifndef::VK_AMD_rasterization_order[]
+<<fundamentals-queueoperation-apiorder, API order>>.
+endif::VK_AMD_rasterization_order[]
 ifdef::VK_AMD_rasterization_order[]
+an order determined by the application.
+
 The application can: select a graphics pipeline to use one of the following
 primitive rasterization ordering rules:
 
 include::../api/enums/VkRasterizationOrderAMD.txt[]
 
-  * ename:VK_RASTERIZATION_ORDER_STRICT_AMD indicates that primitive
-    rasterization must: follow <<fundamentals-queueoperation-apiorder,API
-    order>>.
-  * ename:VK_RASTERIZATION_ORDER_RELAXED_AMD indicates that primitive
-    rasterization may: not follow <<fundamentals-queueoperation-apiorder,API
-    order>>.
+  * ename:VK_RASTERIZATION_ORDER_STRICT_AMD indicates that the order of
+    these operations for each primitive in a subpass must: occur in
+    <<fundamentals-queueoperation-apiorder, API order>>.
+  * ename:VK_RASTERIZATION_ORDER_RELAXED_AMD indicates that the order of
+    these operations for each primitive in a subpass may: not occur in
+    <<fundamentals-queueoperation-apiorder, API order>>.
 
 The rasterization order to use for a graphics pipeline is specified by
 chaining a sname:VkPipelineRasterizationStateRasterizationOrderAMD structure

doc/specs/vulkan/chapters/renderpass.txt

@@ -29,20 +29,23 @@ instance.
 A _subpass description_ describes the subset of attachments that is involved
 in the execution of a subpass.
 Each subpass can: read from some attachments as _input attachments_, write
-to some as _color attachments_ or _depth/stencil attachments_, and do
-resolve operations to others as _resolve attachments_.
+to some as _color attachments_ or _depth/stencil attachments_, and perform
+_multisample resolve operations_ to _resolve attachments_.
 A subpass description can: also include a set of _preserve attachments_,
 which are attachments that are not read or written by the subpass but whose
 contents must: be preserved throughout the subpass.
 
-A subpass _uses_ an attachment if the attachment is a color, depth/stencil,
-resolve, or input attachment for that subpass.
+A subpass _uses an attachment_ if the attachment is a color, depth/stencil,
+resolve, or input attachment for that subpass (as determined by the
+pname:pColorAttachments, pname:pDepthStencilAttachment,
+pname:pResolveAttachments, and pname:pInputAttachments members of
+slink:VkSubpassDescription, respectively).
 A subpass does not use an attachment if that attachment is preserved by the
 subpass.
-The first use of an attachment is in the lowest numbered subpass that uses
+The _first use of an attachment_ is in the lowest numbered subpass that uses
 that attachment.
-Similarly, the last use of an attachment is in the highest numbered subpass
-that uses that attachment.
+Similarly, the _last use of an attachment_ is in the highest numbered
+subpass that uses that attachment.
 
 The subpasses in a render pass all render to the same dimensions, and
 fragments for pixel (x,y,layer) in one subpass can: only read attachment
@@ -62,24 +65,16 @@ However, it is also quite common for a render pass to only contain a single
 subpass.
 ====
 
-_Subpass dependencies_ describe ordering restrictions between pairs of
-subpasses.
-If no dependencies are specified, implementations may: reorder or overlap
-portions (e.g., certain shader stages) of the execution of subpasses.
-Dependencies limit the extent of overlap or reordering, and are defined
-using masks of pipeline stages and memory access types.
-Each dependency acts as an
-<<synchronization-execution-and-memory-dependencies,execution and memory
-dependency>>, similarly to how <<synchronization-pipeline-barriers,pipeline
-barriers>> are defined.
-Dependencies are needed if two subpasses operate on attachments with
-overlapping ranges of the same sname:VkDeviceMemory object and at least one
-subpass writes to that range.
+_Subpass dependencies_ describe <<synchronization-dependencies, execution
+and memory dependencies>> between subpasses.
 
 A _subpass dependency chain_ is a sequence of subpass dependencies in a
 render pass, where the source subpass of each subpass dependency (after the
 first) equals the destination subpass of the previous dependency.
 
+Execution of subpasses may: overlap or execute out of order with regards to
+other subpasses, unless otherwise enforced by an execution dependency.
+
 A render pass describes the structure of subpasses and attachments
 independent of any specific image views for the attachments.
 The specific image views that will be used for the attachments, and their
@@ -173,6 +168,11 @@ include::../api/structs/VkRenderPassCreateInfo.txt[]
   * The value of any element of the pname:pPreserveAttachments member in any
     given element of pname:pSubpasses must: not be
     ename:VK_ATTACHMENT_UNUSED
+  * For any member of pname:pAttachments with a pname:loadOp equal to
+    ename:VK_ATTACHMENT_LOAD_OP_CLEAR, the first use of that attachment
+    must: not specify a pname:layout equal to
+    pname:VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL or
+    pname:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL.
 ****
 
 include::../validity/structs/VkRenderPassCreateInfo.txt[]
@@ -203,14 +203,26 @@ include::../api/enums/VkAttachmentDescriptionFlagBits.txt[]
 // refBegin VkAttachmentLoadOp Specify how contents of an attachment are treated at the beginning of a subpass
 include::../api/enums/VkAttachmentLoadOp.txt[]
 --
-  ** ename:VK_ATTACHMENT_LOAD_OP_LOAD means the contents within the render
-     area will be preserved.
+  ** ename:VK_ATTACHMENT_LOAD_OP_LOAD means the previous contents of the
+     image within the render area will be preserved.
+     For attachments with a depth/stencil format, this uses the access type
+     ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT.
+     For attachments with a color format, this uses the access type
+     ename:VK_ACCESS_COLOR_ATTACHMENT_READ_BIT.
   ** ename:VK_ATTACHMENT_LOAD_OP_CLEAR means the contents within the render
      area will be cleared to a uniform value, which is specified when a
      render pass instance is begun.
-  ** ename:VK_ATTACHMENT_LOAD_OP_DONT_CARE means the contents within the
-     area need not be preserved; the contents of the attachment will be
-     undefined inside the render area.
+     For attachments with a depth/stencil format, this uses the access type
+     ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
+     For attachments with a color format, this uses the access type
+     ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.
+  ** ename:VK_ATTACHMENT_LOAD_OP_DONT_CARE means the previous contents
+     within the area need not be preserved; the contents of the attachment
+     will be undefined inside the render area.
+     For attachments with a depth/stencil format, this uses the access type
+     ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
+     For attachments with a color format, this uses the access type
+     ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.
   * pname:storeOp specifies how the contents of color and depth components
     of the attachment are treated at the end of the subpass where it is last
     used:
@@ -219,15 +231,19 @@ include::../api/enums/VkAttachmentLoadOp.txt[]
 // refBegin VkAttachmentStoreOp Specify how contents of an attachment are treated at the end of a subpass
 include::../api/enums/VkAttachmentStoreOp.txt[]
 --
-  ** ename:VK_ATTACHMENT_STORE_OP_STORE means the contents within the render
-     area are written to memory and will be available for reading after the
-     render pass instance completes once the writes have been synchronized
-     with ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT (for color attachments)
-     or ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT (for
-     depth/stencil attachments).
+  ** ename:VK_ATTACHMENT_STORE_OP_STORE means the contents generated during
+     the render pass and within the render area are written to memory.
+     For attachments with a depth/stencil format, this uses the access type
+     ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
+     For attachments with a color format, this uses the access type
+     ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.
   ** ename:VK_ATTACHMENT_STORE_OP_DONT_CARE means the contents within the
      render area are not needed after rendering, and may: be discarded; the
      contents of the attachment will be undefined inside the render area.
+     For attachments with a depth/stencil format, this uses the access type
+     ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
+     For attachments with a color format, this uses the access type
+     ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT.
   * pname:stencilLoadOp specifies how the contents of stencil components of
     the attachment are treated at the beginning of the subpass where it is
     first used, and must: be one of the same values allowed for pname:loadOp
@@ -243,11 +259,35 @@ include::../api/enums/VkAttachmentStoreOp.txt[]
     During a render pass instance, an attachment can: use a different layout
     in each subpass, if desired.
 
+[[renderpass-load-store-ops]]
 If the attachment uses a color format, then pname:loadOp and pname:storeOp
 are used, and pname:stencilLoadOp and pname:stencilStoreOp are ignored.
 If the format has depth and/or stencil components, pname:loadOp and
 pname:storeOp apply only to the depth data, while pname:stencilLoadOp and
 pname:stencilStoreOp define how the stencil data is handled.
+pname:loadOp and pname:stencilLoadOp define the _load operations_ that
+execute as part of the first subpass that uses the attachment.
+pname:storeOp and pname:stencilStoreOp define the _store operations_ that
+execute as part of the last subpass that uses the attachment.
+
+The load operation for each value in an attachment used by a subpass
+happens-before any command recorded into that subpass reads from that value.
+Load operations for attachments with a depth/stencil format execute in the
+ename:VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT pipeline stage.
+Load operations for attachments with a color format execute in the
+ename:VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT pipeline stage.
+
+Store operations for each value in an attachment used by a subpass
+happen-after any command recorded into that subpass writes to that value.
+Store operations for attachments with a depth/stencil format execute in the
+ename:VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT pipeline stage.
+Store operations for attachments with a color format execute in the
+ename:VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT pipeline stage.
+
+If an attachment is not used by any subpass, then pname:loadOp,
+pname:storeOp, pname:stencilStoreOp, and pname:stencilLoadOp are ignored,
+and the attachment's memory contents will not be modified by execution of a
+render pass instance.
 
 [[renderpass-precision]]
 During a render pass instance, input/color attachments with color formats
@@ -259,7 +299,7 @@ attachment format, but must: be represented with the same range.
 When such a component is loaded via the pname:loadOp, it will be converted
 into an implementation-dependent format used by the render pass.
 Such components must: be converted from the render pass format, to the
-format of the attachment, before they are stored or resolved at the end of a
+format of the attachment, before they are resolved or stored at the end of a
 render pass instance via pname:storeOp.
 Conversions occur as described in <<fundamentals-numerics,Numeric
 Representation and Computation>> and <<fundamentals-fixedconv, Fixed-Point
@@ -303,16 +343,20 @@ Attachments aliasing the same memory occurs in multiple ways:
   * Attachments using distinct image views that correspond to the same image
     subresource of an image.
   * Attachments using views of distinct image subresources which are bound
-    to overlapping memory.
+    to overlapping memory ranges.
 
+.Note
+[NOTE]
+====
 Render passes must: include subpass dependencies (either directly or via a
 subpass dependency chain) between any two subpasses that operate on the same
 attachment or aliasing attachments and those subpass dependencies must:
 include execution and memory dependencies separating uses of the aliases, if
 at least one of those subpasses writes to one of the aliases.
-Those dependencies must: not include the ename:VK_DEPENDENCY_BY_REGION_BIT
+These dependencies must: not include the ename:VK_DEPENDENCY_BY_REGION_BIT
 if the aliases are views of distinct image subresources which overlap in
 memory.
+====
 
 Multiple attachments that alias the same memory must: not be used in a
 single subpass.
@@ -323,8 +367,8 @@ use is as a resolve or preserve attachment.
 In other words, the same view can: be used simultaneously as an input and
 color or depth/stencil attachment, but must: not be used as multiple color
 or depth/stencil attachments nor as resolve or preserve attachments.
-This valid scenario is described in more detail <<renderpass-feedbackloop,
-below>>.
+The precise set of valid scenarios is described in more detail
+<<renderpass-feedbackloop, below>>.
 
 If a set of attachments alias each other, then all except the first to be
 used in the render pass must: use an pname:initialLayout of
@@ -335,17 +379,14 @@ the first alias must: not be used in any later subpasses.
 However, an application can: assign the same image view to multiple aliasing
 attachment indices, which allows that image view to be used multiple times
 even if other aliases are used in between.
-Once an attachment needs the ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
-bit, there should: be no additional cost of introducing additional aliases,
-and using these additional aliases may: allow more efficient clearing of the
-attachments on multiple uses via ename:VK_ATTACHMENT_LOAD_OP_CLEAR.
 
 [NOTE]
 .Note
 ====
-The exact set of attachment indices that alias with each other is not known
-until a framebuffer is created using the render pass, so the above
-conditions cannot: be validated at render pass creation time.
+Once an attachment needs the ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT
+bit, there should: be no additional cost of introducing additional aliases,
+and using these additional aliases may: allow more efficient clearing of the
+attachments on multiple uses via ename:VK_ATTACHMENT_LOAD_OP_CLEAR.
 ====
 
 // refBegin VkSubpassDescription Structure specifying a subpass description
@@ -383,14 +424,15 @@ include::../api/structs/VkSubpassDescription.txt[]
     pname:colorAttachmentCount slink:VkAttachmentReference structures that
     lists which of the render pass's attachments are resolved to at the end
     of the subpass, and what layout each attachment will be in during the
-    resolve.
+    multisample resolve operation.
     If pname:pResolveAttachments is not `NULL`, each of its elements
     corresponds to a color attachment (the element in
-    pname:pColorAttachments at the same index).
-    At the end of each subpass, the subpass's color attachments are resolved
-    to corresponding resolve attachments, unless the resolve attachment
-    index is ename:VK_ATTACHMENT_UNUSED or pname:pResolveAttachments is
-    `NULL`.
+    pname:pColorAttachments at the same index), and a multisample resolve
+    operation is defined for each attachment.
+    At the end of each subpass, multisample resolve operations read the
+    subpass's color attachments, and resolve the samples for each pixel to
+    the same pixel location in the corresponding resolve attachments, unless
+    the resolve attachment index is ename:VK_ATTACHMENT_UNUSED.
     If the first use of an attachment in a render pass is as a resolve
     attachment, then the pname:loadOp is effectively ignored as the resolve
     is guaranteed to overwrite all pixels in the render area.
@@ -407,19 +449,20 @@ include::../api/structs/VkSubpassDescription.txt[]
     subpass.
 
 The contents of an attachment within the render area become undefined at the
-start of a subpass S if all of the following conditions are true:
+start of a subpass *S* if all of the following conditions are true:
 
   * The attachment is used as a color, depth/stencil, or resolve attachment
     in any subpass in the render pass.
-  * There is a subpass S1 that uses or preserves the attachment, and a
-    subpass dependency from S1 to S.
-  * The attachment is not used or preserved in subpass S.
+  * There is a subpass *S~1~* that uses or preserves the attachment, and a
+    subpass dependency from *S~1~* to *S*.
+  * The attachment is not used or preserved in subpass *S*.
 
-Once the contents of an attachment become undefined in subpass S, they
+Once the contents of an attachment become undefined in subpass *S*, they
 remain undefined for subpasses in subpass dependency chains starting with
-subpass S until they are written again.
+subpass *S* until they are written again.
 However, they remain valid for subpasses in other subpass dependency chains
-starting with subpass S1 if those subpasses use or preserve the attachment.
+starting with subpass *S~1~* if those subpasses use or preserve the
+attachment.
 
 .Valid Usage
 ****
@@ -470,8 +513,6 @@ include::../api/structs/VkAttachmentReference.txt[]
     ename:VK_ATTACHMENT_UNUSED, then no writes occur for those attachments.
   * pname:layout is a elink:VkImageLayout value specifying the layout the
     attachment uses during the subpass.
-    The implementation will automatically perform layout transitions as
-    needed between subpasses to make each subpass use the requested layouts.
 
 .Valid Usage
 ****
@@ -487,58 +528,70 @@ The sname:VkSubpassDependency structure is defined as:
 
 include::../api/structs/VkSubpassDependency.txt[]
 
-  * pname:srcSubpass and pname:dstSubpass are the subpass indices of the
-    producer and consumer subpasses, respectively.
-    pname:srcSubpass and pname:dstSubpass can: also have the special value
-    ename:VK_SUBPASS_EXTERNAL.
-    The source subpass must: always be a lower numbered subpass than the
-    destination subpass (excluding external subpasses and
-    <<synchronization-pipeline-barriers-subpass-self-dependencies,
-    self-dependencies>>), so that the order of subpass descriptions is a
-    valid execution ordering, avoiding cycles in the dependency graph.
-  * pname:srcStageMask, pname:dstStageMask, pname:srcAccessMask,
-    pname:dstAccessMask, and pname:dependencyFlags describe an
-    <<synchronization-execution-and-memory-dependencies,execution and memory
-    dependency>> between subpasses.
-    The bits that can: be included in pname:dependencyFlags are:
-+
---
-// refBegin VkDependencyFlagBits Bitmask specifying dependencies between subpasses
-include::../api/enums/VkDependencyFlagBits.txt[]
---
-  ** If pname:dependencyFlags contains ename:VK_DEPENDENCY_BY_REGION_BIT,
-     then the dependency is by-region as defined in
-     <<synchronization-execution-and-memory-dependencies,Execution And
-     Memory Dependencies>>.
+  * pname:srcSubpass is the subpass index of the first subpass in the
+    dependency, or ename:VK_SUBPASS_EXTERNAL.
+  * pname:dstSubpass is the subpass index of the second subpass in the
+    dependency, or ename:VK_SUBPASS_EXTERNAL.
+  * pname:srcStageMask defines a <<synchronization-pipeline-stages-masks,
+    source stage mask>>.
+  * pname:dstStageMask defines a <<synchronization-pipeline-stages-masks,
+    destination stage mask>>.
+  * pname:srcAccessMask defines a <<synchronization-access-masks, source
+    access mask>>.
+  * pname:dstAccessMask defines a <<synchronization-access-masks,
+    destination access mask>>.
+  * pname:dependencyFlags is a bitmask of elink:VkDependencyFlagBits.
 
-Each subpass dependency defines an execution and memory dependency between
-two sets of commands, with the second set depending on the first set.
-When pname:srcSubpass does not equal pname:dstSubpass then the first set of
-commands is:
+If pname:srcSubpass is equal to pname:dstSubpass then the
+slink:VkSubpassDependency describes a
+<<synchronization-pipeline-barriers-subpass-self-dependencies, subpass
+self-dependency>>, and only constrains the pipeline barriers allowed within
+a subpass instance.
+Otherwise, when a render pass instance which includes a subpass dependency
+is submitted to a queue, it defines a memory dependency between the
+subpasses identified by pname:srcSubpass and pname:dstSubpass.
 
-  * All commands in the subpass indicated by pname:srcSubpass, if
-    pname:srcSubpass is not ename:VK_SUBPASS_EXTERNAL.
-  * All commands before the render pass instance, if pname:srcSubpass is
-    ename:VK_SUBPASS_EXTERNAL.
+If pname:srcSubpass is equal to ename:VK_SUBPASS_EXTERNAL, the first
+<<synchronization-dependencies-scopes, synchronization scope>> includes
+commands submitted to the queue before the render pass instance began.
+Otherwise, the first set of commands includes all commands submitted as part
+of the subpass instance identified by pname:srcSubpass and any load, store
+or multisample resolve operations on attachments used in pname:srcSubpass.
+In either case, the first synchronization scope is limited to operations on
+the pipeline stages determined by the
+<<synchronization-pipeline-stages-masks, source stage mask>> specified by
+pname:srcStageMask.
 
-While the corresponding second set of commands is:
+If pname:dstSubpass is equal to ename:VK_SUBPASS_EXTERNAL, the second
+<<synchronization-dependencies-scopes, synchronization scope>> includes
+commands submitted after the render pass instance is ended.
+Otherwise, the second set of commands includes all commands submitted as
+part of the subpass instance identified by pname:dstSubpass and any load,
+store or multisample resolve operations on attachments used in
+pname:dstSubpass.
+In either case, the second synchronization scope is limited to operations on
+the pipeline stages determined by the
+<<synchronization-pipeline-stages-masks, destination stage mask>> specified
+by pname:dstStageMask.
 
-  * All commands in the subpass indicated by pname:dstSubpass, if
-    pname:dstSubpass is not ename:VK_SUBPASS_EXTERNAL.
-  * All commands after the render pass instance, if pname:dstSubpass is
-    ename:VK_SUBPASS_EXTERNAL.
+The first <<synchronization-dependencies-access-scopes, access scope>> is
+limited to access in the pipeline stages determined by the
+<<synchronization-pipeline-stages-masks, source stage mask>> specified by
+pname:srcStageMask.
+It is also limited to access types in the <<synchronization-access-masks,
+source access mask>> specified by pname:srcAccessMask.
 
-When pname:srcSubpass equals pname:dstSubpass then the first set consists of
-commands in the subpass before a call to flink:vkCmdPipelineBarrier and the
-second set consists of commands in the subpass following that same call as
-described in the
-<<synchronization-pipeline-barriers-subpass-self-dependencies, Subpass
-Self-dependency>> section.
+The second <<synchronization-dependencies-access-scopes, access scope>> is
+limited to access in the pipeline stages determined by the
+<<synchronization-pipeline-stages-masks, destination stage mask>> specified
+by pname:dstStageMask.
+It is also limited to access types in the <<synchronization-access-masks,
+destination access mask>> specified by pname:dstAccessMask.
 
-The pname:srcStageMask, pname:dstStageMask, pname:srcAccessMask,
-pname:dstAccessMask, and pname:dependencyFlags parameters of the dependency
-are interpreted the same way as for other dependencies, as described in
-<<synchronization, Synchronization and Cache Control>>.
+The <<synchronization-dependencies-available-and-visible, availability and
+visibility operations>> defined by a subpass dependency affect the execution
+of <<renderpass-layout-transitions, image layout transitions>> within the
+render pass.
 
 .Valid Usage
 ****
@@ -576,196 +629,178 @@ are interpreted the same way as for other dependencies, as described in
     ename:VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT,
     ename:VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, or
     ename:VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT
-  * If pname:srcSubpass is equal to pname:dstSubpass, the highest bit value
-    included in pname:srcStageMask must: be less than or equal to the lowest
-    bit value in pname:dstStageMask
+  * If pname:srcSubpass is equal to pname:dstSubpass, the
+    <<synchronization-pipeline-stages-order, logically latest>> pipeline
+    stage in pname:srcStageMask must: be
+    <<synchronization-pipeline-stages-order, logically earlier>> than or
+    equal to the <<synchronization-pipeline-stages-order, logically
+    earliest>> pipeline stage in pname:dstStageMask
 ****
 
 include::../validity/structs/VkSubpassDependency.txt[]
 
-Automatic image layout transitions between subpasses also interact with the
-subpass dependencies.
-If two subpasses are connected by a dependency and those two subpasses use
-the same attachment in a different layout, then the layout transition will
-occur after the memory accesses via pname:srcAccessMask have completed in
-all pipeline stages included in pname:srcStageMask in the source subpass,
-and before any memory accesses via pname:dstAccessMask occur in any pipeline
-stages included in pname:dstStageMask in the destination subpass.
-
-The automatic image layout transitions from pname:initialLayout to the first
-used layout (if it is different) are performed according to the following
-rules:
-
-  * If the attachment does not include the
-    ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT bit and there is no
-    subpass dependency from ename:VK_SUBPASS_EXTERNAL to the first subpass
-    that uses the attachment, then it is as if there were such a dependency
-    with pname:srcStageMask = pname:srcAccessMask = 0 and pname:dstStageMask
-    and pname:dstAccessMask including all relevant bits (all graphics
-    pipeline stages and all access types that use image resources), with the
-    transition executing as part of that dependency.
-    In other words, it may: overlap work before the render pass instance and
-    is complete before the subpass begins.
-  * If the attachment does not include the
-    ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT bit and there is a subpass
-    dependency from ename:VK_SUBPASS_EXTERNAL to the first subpass that uses
-    the attachment, then the transition executes as part of that dependency
-    and according to its stage and access masks.
-    It must: not overlap work that came before the render pass instance that
-    is included in the source masks, but it may: overlap work in previous
-    subpasses.
-  * If the attachment includes the
-    ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT bit, then the transition
-    executes according to all the subpass dependencies with pname:dstSubpass
-    equal to the first subpass index that the attachment is used in.
-    That is, it occurs after all memory accesses in the source stages and
-    masks from all the source subpasses have completed and are available,
-    and before the union of all the destination stages begin, and the new
-    layout is visible to the union of all the destination access types.
-    If there are no incoming subpass dependencies, then this case follows
-    the first rule.
-
-Similar rules apply for the transition to the pname:finalLayout, using
-dependencies with pname:dstSubpass equal to ename:VK_SUBPASS_EXTERNAL
-
-If an attachment specifies the ename:VK_ATTACHMENT_LOAD_OP_CLEAR load
-operation, then it will logically be cleared at the start of the first
-subpass where it is used.
-
+ifdef::editing-notes[]
 [NOTE]
-.Note
+.editing-note
 ====
-Implementations may: move clears earlier as long as it does not affect the
-operation of a render pass instance.
-For example, an implementation may: choose to clear all attachments at the
-start of the render pass instance.
-If an attachment has the ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT flag
-set, then the clear must: occur at the start of subpass where the attachment
-is first used, in order to preserve the operation of the render pass
-instance.
+The following two alleged implicit dependencies are practically no-ops, as
+the operations they describe are already guaranteed by semaphores and
+submission order (so they're almost entirely no-ops on their own).
+The *only* reason they exist is because it simplifies reasoning about where
+<<renderpass-layout-transitions, automatic layout transitions>> happen.
+Further rewrites of this chapter could potentially remove the need for
+these.
 ====
+endif::editing-notes[]
 
-The first use of an attachment must: not specify a layout equal to
-ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL or
-ename:VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL if the attachment specifies
-that the pname:loadOp is ename:VK_ATTACHMENT_LOAD_OP_CLEAR.
-If a subpass uses the same attachment as both an input attachment and either
-a color attachment or a depth/stencil attachment, then both uses must:
-observe the result of the clear.
+If there is no subpass dependency from ename:VK_SUBPASS_EXTERNAL to the
+first subpass that uses an attachment, then an implicit subpass dependency
+exists from ename:VK_SUBPASS_EXTERNAL to the first subpass it is used in.
+The subpass dependency operates as if defined with the following parameters:
 
-Similarly, if an attachment specifies that the pname:storeOp is
-ename:VK_ATTACHMENT_STORE_OP_STORE, then it will logically be stored at the
-end of the last subpass where it is used.
+[source,c]
+----
+VkSubpassDependency implicitDependency = {
+    .srcSubpass = VK_SUBPASS_EXTERNAL;
+    .dstSubpass = firstSubpass; // First subpass attachment is used in
+    .srcStageMask = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT;
+    .dstStageMask = VK_PIPELINE_STAGE_ALL_COMMANDS_BIT;
+    .srcAccessMask = 0;
+    .dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
+                     VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
+    .dependencyFlags = 0;
+};
+----
 
-[NOTE]
-.Note
-====
-Implementations may: move stores later as long as it does not affect the
-operation of a render pass instance.
-If an attachment has the ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT flag
-set, then the store must: occur at the end of the highest numbered subpass
-that uses the attachment.
-====
+Similarly, if there is no subpass dependency from the last subpass that uses
+an attachment to ename:VK_SUBPASS_EXTERNAL, then an implicit subpass
+dependency exists from the last subpass it is used in to
+ename:VK_SUBPASS_EXTERNAL.
+The subpass dependency operates as if defined with the following parameters:
 
-If an attachment is not used by any subpass, then the pname:loadOp and the
-pname:storeOp are ignored and the attachment's memory contents will not be
-modified by execution of a render pass instance.
+[source,c]
+----
+VkSubpassDependency implicitDependency = {
+    .srcSubpass = lastSubpass; // Last subpass attachment is used in
+    .dstSubpass = VK_SUBPASS_EXTERNAL;
+    .srcStageMask = VK_PIPELINE_STAGE_ALL_COMMANDS_BIT;
+    .dstStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT;
+    .srcAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
+                     VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT |
+                     VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
+    .dstAccessMask = 0;
+    .dependencyFlags = 0;
+};
+----
 
-It will be common for a render pass to consist of a simple linear graph of
-dependencies, where subpass N depends on subpass N-1 for all N, and the
-operation of the memory barriers and layout transitions is fairly
-straightforward to reason about for those simple cases.
-But for more complex graphs, there are some rules that govern when there
-must: be dependencies between subpasses.
+[[renderpass-layout-transitions]]
+As subpasses may: overlap or execute out of order with regards to other
+subpasses unless a subpass dependency chain describes otherwise, the layout
+transitions required between subpasses cannot: be known to an application.
+Instead, an application provides the layout that each attachment must: be in
+at the start and end of a renderpass, and the layout it must: be in during
+each subpass it is used in.
+The implementation then must: execute layout transitions between subpasses
+in order to guarantee that the images are in the layouts required by each
+subpass, and in the final layout at the end of the render pass.
 
-As stated earlier, render passes must: include subpass dependencies which
-(either directly or via a subpass dependency chain) separate any two
-subpasses that operate on the same attachment or aliasing attachments, if at
-least one of those subpasses writes to the attachment.
-If an image layout changes between those two subpasses, the implementation
-uses the stageMasks and accessMasks indicated by the subpass dependency as
-the masks that control when the layout transition must: occur.
-If there is not a layout change on the attachment, or if an implementation
-treats the two layouts identically, then it may: treat the dependency as a
-simple execution/memory barrier.
+Automatic layout transitions away from the layout used in a subpass
+happen-after the availability operations for all dependencies with that
+subpass as the pname:srcSubpass.
 
-If two subpasses use the same attachment in different layouts but both uses
-are read-only (i.e. input attachment, or read-only depth/stencil
-attachment), the application does not need to express a dependency between
-the two subpasses.
-Implementations that treat the two layouts differently may: deduce and
-insert a dependency between the subpasses, with the implementation choosing
-the appropriate stage masks and access masks based on whether the attachment
-is used as an input or depth/stencil attachment, and may: insert the
-appropriate layout transition along with the execution/memory barrier.
-Implementations that treat the two layouts identically need not insert a
-barrier, and the two subpasses may: execute simultaneously.
-The stage masks and access masks are chosen as follows:
+Automatic layout transitions into the layout used in a subpass happen-before
+the visibility operations for all dependencies with that subpass as the
+pname:dstSubpass.
 
-  * for input attachments, stage mask =
-    ename:VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, access mask =
-    ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT.
-  * for depth/stencil attachments, stage mask =
-    ename:VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT |
-    ename:VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT, access mask =
-    ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT
+Automatic layout transitions away from pname:initialLayout happens-after the
+availability operations for all dependencies with a pname:srcSubpass equal
+to ename:VK_SUBPASS_EXTERNAL, where pname:dstSubpass uses the attachment
+that will be transitioned.
+For attachments created with ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT,
+automatic layout transitions away from pname:initialLayout happen-after the
+availability operations for all dependencies with a pname:srcSubpass equal
+to ename:VK_SUBPASS_EXTERNAL, where pname:dstSubpass uses any aliased
+attachment.
 
-where pname:srcStageMask and pname:srcAccessMask are taken based on usage in
-the source subpass and pname:dstStageMask and pname:dstAccessMask are taken
-based on usage in the destination subpass.
+Automatic layout transitions into pname:finalLayout happens-before the
+visibility operations for all dependencies with a pname:dstSubpass equal to
+ename:VK_SUBPASS_EXTERNAL, where pname:srcSubpass uses the attachment that
+will be transitioned.
+For attachments created with ename:VK_ATTACHMENT_DESCRIPTION_MAY_ALIAS_BIT,
+automatic layout transitions into pname:finalLayout happen-before the
+visibility operations for all dependencies with a pname:dstSubpass equal to
+ename:VK_SUBPASS_EXTERNAL, where pname:srcSubpass uses any aliased
+attachment.
+
+If two subpasses use the same attachment in different layouts, and both
+layouts are read-only, no subpass dependency needs to be specified between
+those subpasses.
+If an implementation treats those layouts separately, it must: insert an
+implicit subpass dependency between those subpasses to separate the uses in
+each layout.
+The subpass dependency operates as if defined with the following parameters:
+
+[source,c]
+----
+// Used for input attachments
+VkPipelineStageFlags inputAttachmentStages = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
+VkAccessFlags inputAttachmentAccess = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT;
+
+// Used for depth stencil attachments
+VkPipelineStageFlags depthStencilAttachmentStages = VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT;
+VkAccessFlags depthStencilAttachmentAccess = VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT;
+
+VkSubpassDependency implicitDependency = {
+    .srcSubpass = firstSubpass;
+    .dstSubpass = secondSubpass;
+    .srcStageMask = inputAttachmentStages | depthStencilAttachmentStages;
+    .dstStageMask = inputAttachmentStages | depthStencilAttachmentStages;
+    .srcAccessMask = inputAttachmentAccess | depthStencilAttachmentAccess;
+    .dstAccessMask = inputAttachmentAccess | depthStencilAttachmentAccess;
+    .dependencyFlags = 0;
+};
+----
 
 [[renderpass-feedbackloop]]
 If a subpass uses the same attachment as both an input attachment and either
-a color attachment or a depth/stencil attachment, reads from the input
-attachment are not automatically coherent with writes through the color or
-depth/stencil attachment.
-In order to achieve well-defined results, one of two criteria must: be
-satisfied.
-First, if the color components or depth/stencil components read by the input
-attachment are mutually exclusive with the components written by the color
-or depth/stencil attachment then there is no _feedback loop_ and the reads
-and writes both function normally, with the reads observing values from the
-previous subpass(es) or from memory.
-This option requires the graphics pipelines used by the subpass to disable
-writes to color components that are read as inputs via the
-pname:colorWriteMask, and to disable writes to depth/stencil components that
-are read as inputs via pname:depthWriteEnable or pname:stencilTestEnable.
+a color attachment or a depth/stencil attachment, writes via the color or
+depth/stencil attachment are not automatically made visible to reads via the
+input attachment, causing a _feedback loop_, except in any of the following
+conditions:
 
-Second, if the input attachment reads components that are written by the
-color or depth/stencil attachment, then there is a feedback loop and a
-pipeline barrier must: be used between when the attachment is written and
-when it is subsequently read by later fragments.
-This pipeline barrier must: follow the rules of a self-dependency as
-described in
-<<synchronization-pipeline-barriers-subpass-self-dependencies,Subpass
-Self-dependency>>, where the barrier's flags include:
+  * If the color components or depth/stencil components read by the input
+    attachment are mutually exclusive with the components written by the
+    color or depth/stencil attachments, then there is no feedback loop.
+    This requires the graphics pipelines used by the subpass to disable
+    writes to color components that are read as inputs via the
+    pname:colorWriteMask, and to disable writes to depth/stencil components
+    that are read as inputs via pname:depthWriteEnable or
+    pname:stencilTestEnable.
+  * If the attachment is used as an input attachment and depth/stencil
+    attachment only, and the depth/stencil attachment is not written to.
+  * If a memory dependency is inserted between when the attachment is
+    written and when it is subsequently read by later fragments.
+    <<synchronization-pipeline-barriers, Pipeline barriers>> expressing a
+    <<synchronization-pipeline-barriers-subpass-self-dependencies, subpass
+    self-dependency>> are the only way to achieve this, and one 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 the since start of the
+    subpass if there have been no pipeline barriers since the start of the
+    subpass.
 
-  * pname:dstStageMask = ename:VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,
-  * pname:dstAccessMask = ename:VK_ACCESS_INPUT_ATTACHMENT_READ_BIT, and
-  * pname:srcAccessMask = ename:VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT (for
-    color attachments) or pname:srcAccessMask =
-    ename:VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT (for depth/stencil
-    attachments).
-  * pname:srcStageMask = ename:VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT
-    (for color attachments) or pname:srcStageMask =
-    ename:VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT |
-    ename:VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT (for depth/stencil
-    attachments).
-  * pname:dependencyFlags = ename:VK_DEPENDENCY_BY_REGION_BIT.
-
-A pipeline barrier is needed each time a fragment will read a particular
-(x,y,layer,sample) location if that location has been written since the most
-recent pipeline barrier, or since the start of the subpass if there have
-been no pipeline barriers since the start of the subpass.
-
-An attachment used as both an input attachment and color attachment must: be
-in the ename:VK_IMAGE_LAYOUT_GENERAL layout.
-An attachment used as both an input attachment and depth/stencil attachment
-must: be in either the ename:VK_IMAGE_LAYOUT_GENERAL or
-ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL layout.
-Since an attachment in the
-ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL layout is read-only,
-this situation is not a feedback loop.
+An attachment used as both an input attachment and a color attachment must:
+be in the ename:VK_IMAGE_LAYOUT_GENERAL layout.
+An attachment used as an input attachment and depth/stencil attachment must:
+be in either ename:VK_IMAGE_LAYOUT_GENERAL or
+ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL.
+An attachment must: not be used as both a depth/stencil attachment and a
+color attachment.
 
 // refBegin vkDestroyRenderPass Destroy a render pass object
 
@@ -1080,9 +1115,9 @@ include::../api/structs/VkRenderPassBeginInfo.txt[]
 
 pname:renderArea is the render area that is affected by the render pass
 instance.
-The effects of attachment load, store and resolve operations are restricted
-to the pixels whose x and y coordinates fall within the render area on all
-attachments.
+The effects of attachment load, store and multisample resolve operations are
+restricted to the pixels whose x and y coordinates fall within the render
+area on all attachments.
 The render area extends to all layers of pname:framebuffer.
 The application must: ensure (using scissor if necessary) that all rendering
 is contained within the render area, otherwise the pixels outside of the

doc/specs/vulkan/chapters/resources.txt

@@ -85,7 +85,8 @@ include::../api/enums/VkBufferUsageFlagBits.txt[]
 
   * ename:VK_BUFFER_USAGE_TRANSFER_SRC_BIT indicates that the buffer can: be
     used as the source of a _transfer command_ (see the definition of
-    <<synchronization-transfer,ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>).
+    <<synchronization-pipeline-stages-transfer,
+    ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>).
   * ename:VK_BUFFER_USAGE_TRANSFER_DST_BIT indicates that the buffer can: be
     used as the destination of a transfer command.
   * ename:VK_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER_BIT indicates that the buffer
@@ -116,6 +117,11 @@ include::../api/enums/VkBufferUsageFlagBits.txt[]
     suitable for passing as the pname:buffer parameter to
     fname:vkCmdDrawIndirect, fname:vkCmdDrawIndexedIndirect, or
     fname:vkCmdDispatchIndirect.
+ifdef::VK_NVX_device_generated_commands[]
+    It is also suitable for passing as the pname:buffer member of
+    sname:VkIndirectCommandsTokenNVX, or pname:sequencesCountBuffer or
+    pname:sequencesIndexBuffer member of sname:VkCmdProcessCommandsInfoNVX
+endif::VK_NVX_device_generated_commands[]
 
 Any combination of bits can: be specified for pname:usage, but at least one
 of the bits must: be set in order to create a valid buffer.
@@ -606,6 +612,8 @@ flink:vkGetPhysicalDeviceImageFormatProperties.
   * If the <<features-features-sparseBinding,sparse bindings>> feature is
     not enabled, pname:flags must: not contain
     ename:VK_IMAGE_CREATE_SPARSE_BINDING_BIT
+  * If pname:imageType is ename:VK_IMAGE_TYPE_1D, pname:flags must: not
+    contain ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT
   * If the <<features-features-sparseResidencyImage2D,sparse residency for
     2D images>> feature is not enabled, and pname:imageType is
     ename:VK_IMAGE_TYPE_2D, pname:flags must: not contain
@@ -1025,7 +1033,7 @@ Applications have control over which layout each image subresource uses, and
 can: transition an image subresource from one layout to another.
 Transitions can: happen with an image memory barrier, included as part of a
 fname:vkCmdPipelineBarrier or a fname:vkCmdWaitEvents command buffer command
-(see <<synchronization-image-memory-barrier>>), or as part of a subpass
+(see <<synchronization-image-memory-barriers>>), or as part of a subpass
 dependency within a render pass (see sname:VkSubpassDependency).
 The image layout state is per-image subresource, and separate image
 subresources of the same image can: be in different layouts at the same time
@@ -1127,7 +1135,8 @@ The type(s) of device access supported by each layout are:
     ename:VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT usage bit enabled.
   * ename:VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL: must: only be used as a
     source image of a transfer command (see the definition of
-    <<synchronization-transfer,ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>).
+    <<synchronization-pipeline-stages-transfer,
+    ename:VK_PIPELINE_STAGE_TRANSFER_BIT>>).
     This layout is valid only for image subresources of images created with
     the ename:VK_IMAGE_USAGE_TRANSFER_SRC_BIT usage bit enabled.
   * ename:VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL: must: only be used as a
@@ -1571,9 +1580,10 @@ attachment descriptors, and framebuffer attachments.
 .Valid Usage
 ****
   * If pname:levelCount is not ename:VK_REMAINING_MIP_LEVELS,
-    [eq]#pname:levelCount# must: be non-zero and [eq]#(pname:baseMipLevel +
-    pname:levelCount)# must: be less than or equal to the pname:mipLevels
-    specified in slink:VkImageCreateInfo when the image was created
+    [eq]#pname:levelCount# must: be non-zero and [eq]#(pname:baseMipLevel
+    {plus} pname:levelCount)# must: be less than or equal to the
+    pname:mipLevels specified in slink:VkImageCreateInfo when the image was
+    created
   * If pname:layerCount is not ename:VK_REMAINING_ARRAY_LAYERS,
     [eq]#pname:layerCount# must: be non-zero and [eq]#(pname:baseArrayLayer
     + pname:layerCount)# must: be less than or equal to the
@@ -2003,51 +2013,28 @@ Ranges of buffers and image subresources of image objects created using
 ename:VK_SHARING_MODE_EXCLUSIVE must: only be accessed by queues in the same
 queue family at any given time.
 In order for a different queue family to be able to interpret the memory
-contents of a range or image subresource, the application must: transfer
-exclusive ownership of the range or image subresource between the source and
-destination queue families with the following sequence of operations:
-
-  . Release exclusive ownership from the source queue family to the
-    destination queue family.
-  . Use semaphores to ensure proper execution control for the ownership
-    transfer.
-  . Acquire exclusive ownership for the destination queue family from the
-    source queue family.
-
-To release exclusive ownership of a range of a buffer or image subresource
-of an image object, the application must: execute a buffer or image memory
-barrier, respectively (see slink:VkBufferMemoryBarrier and
-slink:VkImageMemoryBarrier) on a queue from the source queue family.
-The pname:srcQueueFamilyIndex parameter of the barrier must: be set to the
-source queue family index, and the pname:dstQueueFamilyIndex parameter to
-the destination queue family index.
-
-To acquire exclusive ownership, the application must: execute the same
-buffer or image memory barrier (i.e. an identically defined instance of the
-slink:VkBufferMemoryBarrier or slink:VkImageMemoryBarrier structure that was
-used for the exclusive ownership release) on a queue from the destination
-queue family.
+contents of a range or image subresource, the application must: perform a
+<<synchronization-queue-transfers,queue family ownership transfer>>.
 
 Upon creation, resources using ename:VK_SHARING_MODE_EXCLUSIVE are not owned
 by any queue family.
-A buffer or image memory barrier is not required to acquire ownership when
+A buffer or image memory barrier is not required to acquire _ownership_ when
 no queue family owns the resource - it is implicitly acquired upon first use
 within a queue.
-However, images still require a <<resources-image-layouts,layout
-transition>> from ename:VK_IMAGE_LAYOUT_UNDEFINED or
-ename:VK_IMAGE_LAYOUT_PREINITIALIZED before being used on the first queue.
-This layout transition can: either be accomplished by an image memory
-barrier or by use in a render pass instance.
 
-Once a queue family has used a range or image subresource of an
-ename:VK_SHARING_MODE_EXCLUSIVE resource, its contents are undefined to
-other queue families unless ownership is transferred.
-The contents may: also become undefined for other reasons, e.g. as a result
-of writes to an image subresource that aliases the same memory.
-A queue family can: take ownership of a range or image subresource without
-an ownership transfer in the same way as for a resource that was just
-created, however doing so means any contents written by other queue families
-or via incompatible aliases are undefined.
+.Note
+[NOTE]
+====
+Images still require a <<resources-image-layouts, layout transition>> from
+ename:VK_IMAGE_LAYOUT_UNDEFINED or ename:VK_IMAGE_LAYOUT_PREINITIALIZED
+before being used on the first queue.
+====
+
+A queue family can: take ownership of an image subresource or buffer range
+of a resource created with ename:VK_SHARING_MODE_EXCLUSIVE, without an
+ownership transfer, in the same way as for a resource that was just created;
+however, taking ownership in this way has the effect that the contents of
+the image subresource or buffer range are undefined.
 
 Ranges of buffers and image subresources of image objects created using
 ename:VK_SHARING_MODE_CONCURRENT must: only be accessed by queues from the
@@ -2132,8 +2119,9 @@ If any sparse blocks of a sparse image have been made undefined, then only
 the image subresources containing them must: be transitioned.
 
 Use of an overlapping range by two aliases must: be separated by a memory
-dependency using the appropriate access types if at least one of those uses
-performs writes, whether the aliases interpret memory consistently or not.
+dependency using the appropriate <<synchronization-access-types, access
+types>> if at least one of those uses performs writes, whether the aliases
+interpret memory consistently or not.
 If buffer or image memory barriers are used, the scope of the barrier must:
 contain the entire range and/or set of image subresources that overlap.
 

doc/specs/vulkan/chapters/shaders.txt

@@ -212,8 +212,9 @@ writes in finite time.
 ====
 
 Stores issued to different memory locations within a single shader
-invocation may: not be visible to other invocations in the order they were
-performed.
+invocation may: not be visible to other invocations, or may: not become
+visible in the order they were performed.
+
 The code:OpMemoryBarrier instruction can: be used to provide stronger
 ordering of reads and writes performed by a single invocation.
 code:OpMemoryBarrier guarantees that any memory transactions issued by the
@@ -232,6 +233,25 @@ final write would also see the previous writes.
 Without the memory barrier, the final write may: be visible before the
 previous writes.
 
+Writes that are the result of shader stores through a variable decorated
+with code:Coherent automatically have available writes to the same buffer,
+buffer view, or image view made visible to them, and are themselves
+automatically made available to access by the same buffer, buffer view, or
+image view.
+Reads that are the result of shader loads through a variable decorated with
+code:Coherent automatically have available writes to the same buffer, buffer
+view, or image view made visible to them.
+The order that coherent writes to different locations become available is
+undefined, unless enforced by a memory barrier instruction or other memory
+dependency.
+
+.Note
+[NOTE]
+====
+Explicit memory dependencies must: still be used to guarantee availability
+and visibility for access via other buffers, buffer views, or image views.
+====
+
 The built-in atomic memory transaction instructions can: be used to read and
 write a given memory address atomically.
 While built-in atomic functions issued by multiple shader invocations are
@@ -239,6 +259,18 @@ executed in undefined order relative to each other, these functions perform
 both a read and a write of a memory address and guarantee that no other
 memory transaction will write to the underlying memory between the read and
 write.
+Atomic operations ensure automatic availability and visibility for writes
+and reads in the same way as those to code:Coherent variables.
+
+.Note
+[[NOTE]]
+====
+Memory accesses performed on different resource descriptors with the same
+memory backing may: not be well-defined even with the code:Coherent
+decoration or via atomics, due to things such as image layouts or ownership
+of the resource - as described in the <<synchronization, Synchronization and
+Cache Control>> chapter.
+====
 
 [NOTE]
 .Note

doc/specs/vulkan/chapters/sparsemem.txt

@@ -1351,6 +1351,8 @@ include::../api/protos/vkQueueBindSparse.txt[]
 fname:vkQueueBindSparse is a <<devsandqueues-submission,queue submission
 command>>, with each batch defined by an element of pname:pBindInfo as an
 instance of the slink:VkBindSparseInfo structure.
+Batches begin execution in the order they appear in pname:pBindInfo, but
+may: complete out of order.
 
 Within a batch, a given range of a resource must: not be bound more than
 once.

doc/specs/vulkan/checkLinks.py

@@ -178,7 +178,7 @@ def checkLinks(infile, follow = False, included = False):
         return
 
     inPath = os.path.dirname(curFile)
-    fp = open(curFile, 'r')
+    fp = open(curFile, 'r', encoding='utf-8')
 
     for line in fp:
         curLine = curLine + 1

doc/specs/vulkan/genRef.py

@@ -220,7 +220,7 @@ def refPageTail(pageName, seeAlso, fp, auto = False):
 #   file - list of strings making up the file, indexed by pi
 def emitPage(baseDir, specDir, pi, file):
     pageName = baseDir + '/' + pi.name + '.txt'
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
 
     # Add a dictionary entry for this page
     global genDict
@@ -269,7 +269,7 @@ def emitPage(baseDir, specDir, pi, file):
 #   file - list of strings making up the file, indexed by pi
 def autoGenEnumsPage(baseDir, pi, file):
     pageName = baseDir + '/' + pi.name + '.txt'
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
 
     # Add a dictionary entry for this page
     global genDict
@@ -313,7 +313,7 @@ flagNamePat = re.compile('(?P<name>\w+)Flags(?P<author>[A-Z]*)')
 #   flagName - Vk*Flags name
 def autoGenFlagsPage(baseDir, flagName):
     pageName = baseDir + '/' + flagName + '.txt'
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
 
     # Add a dictionary entry for this page
     global genDict
@@ -361,7 +361,7 @@ def autoGenFlagsPage(baseDir, flagName):
 # @@ interface in generator.py.
 def autoGenHandlePage(baseDir, handleName):
     pageName = baseDir + '/' + handleName + '.txt'
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
 
     # Add a dictionary entry for this page
     global genDict
@@ -509,7 +509,7 @@ def genSinglePageRef(baseDir):
 
     # Write head and body to the output file
     pageName = baseDir + '/apispec.txt'
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
 
     print(head.getvalue(), file=fp, end='')
     print(body.getvalue(), file=fp, end='')

doc/specs/vulkan/genspec.py

@@ -57,7 +57,8 @@ allExtensions = KHRextensions + [
     'VK_NV_external_memory_capabilities',
     'VK_NV_external_memory_win32',
     'VK_NV_win32_keyed_mutex',
-    'VK_NV_glsl_shader'
+    'VK_NV_glsl_shader',
+    'VK_NVX_device_generated_commands'
     ]
 
 # Return the Vulkan release number, used for tags

doc/specs/vulkan/insertTags.py

@@ -96,7 +96,7 @@ def insertTags(specFile, baseDir):
 
     pageName = baseDir + '/' + os.path.basename(specFile)
     logDiag('Creating output file', pageName)
-    fp = open(pageName, 'w')
+    fp = open(pageName, 'w', encoding='utf-8')
     fp.writelines(file)
     fp.close()
 

doc/specs/vulkan/makeAllExts

@@ -42,6 +42,7 @@ for ext in \
     VK_AMD_shader_trinary_minmax \
     VK_EXT_debug_marker \
     VK_EXT_debug_report \
+    VK_EXT_validation_flags \
     VK_IMG_filter_cubic \
     VK_NV_dedicated_allocation \
     VK_NV_external_memory \
@@ -49,7 +50,7 @@ for ext in \
     VK_NV_external_memory_win32 \
     VK_NV_win32_keyed_mutex \
     VK_NV_glsl_shader \
-    VK_EXT_validation_flags \
+    VK_NVX_device_generated_commands \
 ; do
     extensions="$extensions $ext"
 done

doc/specs/vulkan/reflib.py

@@ -41,7 +41,7 @@ def setLogFile(setDiag, setWarn, filename):
     elif filename == '-':
         fp = sys.stdout
     else:
-        fp = open(filename, 'w')
+        fp = open(filename, 'w', encoding='utf-8')
 
     if setDiag:
         diagFile = fp
@@ -306,7 +306,8 @@ def fixupRefs(pageMap, specFile, file):
                     printPageInfo(pi, file)
                     printPageInfo(embed, file)
                 # If an embed is found, change the error to a warning
-                elif pi.include >= embed.begin and pi.include <= embed.end:
+                elif (pi.include != None and pi.include >= embed.begin and
+                      pi.include <= embed.end):
                     logDiag('fixupRefs: Found embed for:', name,
                             'inside:', embedName,
                             'in', specFile, 'at line', pi.include )

doc/specs/vulkan/style/writing.txt

@@ -128,6 +128,10 @@ of a structure as a ``color space'' value.
 3+h| Exceptions
 | mipmap        | mip map        | Exception for historical reasons
 | swapchain     | swap chain     | Exception due to heavy use in WSI extensions
+| happen-before +
+  happen-after  | happen before +
+                  happen after   | As used in concurrent languages such as
+                                   C++11, Java and OpenCL C.
 |====
 
 ==== Words With "Pre-" Prefixes

doc/specs/vulkan/vkspec.txt

@@ -106,6 +106,11 @@ include::chapters/framebuffer.txt[]
 // Compute
 include::chapters/dispatch.txt[]
 
+// Device Generated Commands
+ifdef::VK_NVX_device_generated_commands[]
+include::chapters/VK_NVX_device_generated_commands/generatedcommands.txt[]
+endif::VK_NVX_device_generated_commands[]
+
 // Sparse
 include::chapters/sparsemem.txt[]
 

src/ext_loader/vulkan_ext.c

@@ -670,6 +670,133 @@ VkResult vkGetMemoryWin32HandleNV(
 
 #endif /* VK_USE_PLATFORM_WIN32_KHR */
 #endif /* VK_NV_external_memory_win32 */
+#ifdef VK_NVX_device_generated_commands
+static PFN_vkCmdProcessCommandsNVX pfn_vkCmdProcessCommandsNVX;
+void vkCmdProcessCommandsNVX(
+    VkCommandBuffer                             commandBuffer,
+    const VkCmdProcessCommandsInfoNVX*          pProcessCommandsInfo)
+{
+    pfn_vkCmdProcessCommandsNVX(
+        commandBuffer,
+        pProcessCommandsInfo
+    );
+}
+
+static PFN_vkCmdReserveSpaceForCommandsNVX pfn_vkCmdReserveSpaceForCommandsNVX;
+void vkCmdReserveSpaceForCommandsNVX(
+    VkCommandBuffer                             commandBuffer,
+    const VkCmdReserveSpaceForCommandsInfoNVX*  pReserveSpaceInfo)
+{
+    pfn_vkCmdReserveSpaceForCommandsNVX(
+        commandBuffer,
+        pReserveSpaceInfo
+    );
+}
+
+static PFN_vkCreateIndirectCommandsLayoutNVX pfn_vkCreateIndirectCommandsLayoutNVX;
+VkResult vkCreateIndirectCommandsLayoutNVX(
+    VkDevice                                    device,
+    const VkIndirectCommandsLayoutCreateInfoNVX* pCreateInfo,
+    const VkAllocationCallbacks*                pAllocator,
+    VkIndirectCommandsLayoutNVX*                pIndirectCommandsLayout)
+{
+    return pfn_vkCreateIndirectCommandsLayoutNVX(
+        device,
+        pCreateInfo,
+        pAllocator,
+        pIndirectCommandsLayout
+    );
+}
+
+static PFN_vkDestroyIndirectCommandsLayoutNVX pfn_vkDestroyIndirectCommandsLayoutNVX;
+void vkDestroyIndirectCommandsLayoutNVX(
+    VkDevice                                    device,
+    VkIndirectCommandsLayoutNVX                 indirectCommandsLayout,
+    const VkAllocationCallbacks*                pAllocator)
+{
+    pfn_vkDestroyIndirectCommandsLayoutNVX(
+        device,
+        indirectCommandsLayout,
+        pAllocator
+    );
+}
+
+static PFN_vkCreateObjectTableNVX pfn_vkCreateObjectTableNVX;
+VkResult vkCreateObjectTableNVX(
+    VkDevice                                    device,
+    const VkObjectTableCreateInfoNVX*           pCreateInfo,
+    const VkAllocationCallbacks*                pAllocator,
+    VkObjectTableNVX*                           pObjectTable)
+{
+    return pfn_vkCreateObjectTableNVX(
+        device,
+        pCreateInfo,
+        pAllocator,
+        pObjectTable
+    );
+}
+
+static PFN_vkDestroyObjectTableNVX pfn_vkDestroyObjectTableNVX;
+void vkDestroyObjectTableNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    const VkAllocationCallbacks*                pAllocator)
+{
+    pfn_vkDestroyObjectTableNVX(
+        device,
+        objectTable,
+        pAllocator
+    );
+}
+
+static PFN_vkRegisterObjectsNVX pfn_vkRegisterObjectsNVX;
+VkResult vkRegisterObjectsNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    uint32_t                                    objectCount,
+    const VkObjectTableEntryNVX* const*         ppObjectTableEntries,
+    const uint32_t*                             pObjectIndices)
+{
+    return pfn_vkRegisterObjectsNVX(
+        device,
+        objectTable,
+        objectCount,
+        ppObjectTableEntries,
+        pObjectIndices
+    );
+}
+
+static PFN_vkUnregisterObjectsNVX pfn_vkUnregisterObjectsNVX;
+VkResult vkUnregisterObjectsNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    uint32_t                                    objectCount,
+    const VkObjectEntryTypeNVX*                 pObjectEntryTypes,
+    const uint32_t*                             pObjectIndices)
+{
+    return pfn_vkUnregisterObjectsNVX(
+        device,
+        objectTable,
+        objectCount,
+        pObjectEntryTypes,
+        pObjectIndices
+    );
+}
+
+static PFN_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX pfn_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX;
+void vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX(
+    VkPhysicalDevice                            physicalDevice,
+    VkDeviceGeneratedCommandsFeaturesNVX*       pFeatures,
+    VkDeviceGeneratedCommandsLimitsNVX*         pLimits)
+{
+    pfn_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX(
+        physicalDevice,
+        pFeatures,
+        pLimits
+    );
+}
+
+#endif /* VK_NVX_device_generated_commands */
 
 void vkExtInitInstance(VkInstance instance)
 {
@@ -758,6 +885,17 @@ void vkExtInitInstance(VkInstance instance)
     pfn_vkGetMemoryWin32HandleNV = (PFN_vkGetMemoryWin32HandleNV)vkGetInstanceProcAddr(instance, "vkGetMemoryWin32HandleNV");
 #endif /* VK_USE_PLATFORM_WIN32_KHR */
 #endif /* VK_NV_external_memory_win32 */
+#ifdef VK_NVX_device_generated_commands
+    pfn_vkCmdProcessCommandsNVX = (PFN_vkCmdProcessCommandsNVX)vkGetInstanceProcAddr(instance, "vkCmdProcessCommandsNVX");
+    pfn_vkCmdReserveSpaceForCommandsNVX = (PFN_vkCmdReserveSpaceForCommandsNVX)vkGetInstanceProcAddr(instance, "vkCmdReserveSpaceForCommandsNVX");
+    pfn_vkCreateIndirectCommandsLayoutNVX = (PFN_vkCreateIndirectCommandsLayoutNVX)vkGetInstanceProcAddr(instance, "vkCreateIndirectCommandsLayoutNVX");
+    pfn_vkDestroyIndirectCommandsLayoutNVX = (PFN_vkDestroyIndirectCommandsLayoutNVX)vkGetInstanceProcAddr(instance, "vkDestroyIndirectCommandsLayoutNVX");
+    pfn_vkCreateObjectTableNVX = (PFN_vkCreateObjectTableNVX)vkGetInstanceProcAddr(instance, "vkCreateObjectTableNVX");
+    pfn_vkDestroyObjectTableNVX = (PFN_vkDestroyObjectTableNVX)vkGetInstanceProcAddr(instance, "vkDestroyObjectTableNVX");
+    pfn_vkRegisterObjectsNVX = (PFN_vkRegisterObjectsNVX)vkGetInstanceProcAddr(instance, "vkRegisterObjectsNVX");
+    pfn_vkUnregisterObjectsNVX = (PFN_vkUnregisterObjectsNVX)vkGetInstanceProcAddr(instance, "vkUnregisterObjectsNVX");
+    pfn_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX = (PFN_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX)vkGetInstanceProcAddr(instance, "vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX");
+#endif /* VK_NVX_device_generated_commands */
 }
 
 void vkExtInitDevice(VkDevice device)
@@ -847,5 +985,16 @@ void vkExtInitDevice(VkDevice device)
     pfn_vkGetMemoryWin32HandleNV = (PFN_vkGetMemoryWin32HandleNV)vkGetDeviceProcAddr(device, "vkGetMemoryWin32HandleNV");
 #endif /* VK_USE_PLATFORM_WIN32_KHR */
 #endif /* VK_NV_external_memory_win32 */
+#ifdef VK_NVX_device_generated_commands
+    pfn_vkCmdProcessCommandsNVX = (PFN_vkCmdProcessCommandsNVX)vkGetDeviceProcAddr(device, "vkCmdProcessCommandsNVX");
+    pfn_vkCmdReserveSpaceForCommandsNVX = (PFN_vkCmdReserveSpaceForCommandsNVX)vkGetDeviceProcAddr(device, "vkCmdReserveSpaceForCommandsNVX");
+    pfn_vkCreateIndirectCommandsLayoutNVX = (PFN_vkCreateIndirectCommandsLayoutNVX)vkGetDeviceProcAddr(device, "vkCreateIndirectCommandsLayoutNVX");
+    pfn_vkDestroyIndirectCommandsLayoutNVX = (PFN_vkDestroyIndirectCommandsLayoutNVX)vkGetDeviceProcAddr(device, "vkDestroyIndirectCommandsLayoutNVX");
+    pfn_vkCreateObjectTableNVX = (PFN_vkCreateObjectTableNVX)vkGetDeviceProcAddr(device, "vkCreateObjectTableNVX");
+    pfn_vkDestroyObjectTableNVX = (PFN_vkDestroyObjectTableNVX)vkGetDeviceProcAddr(device, "vkDestroyObjectTableNVX");
+    pfn_vkRegisterObjectsNVX = (PFN_vkRegisterObjectsNVX)vkGetDeviceProcAddr(device, "vkRegisterObjectsNVX");
+    pfn_vkUnregisterObjectsNVX = (PFN_vkUnregisterObjectsNVX)vkGetDeviceProcAddr(device, "vkUnregisterObjectsNVX");
+    pfn_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX = (PFN_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX)vkGetDeviceProcAddr(device, "vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX");
+#endif /* VK_NVX_device_generated_commands */
 }
 

src/spec/docgenerator.py

@@ -125,7 +125,7 @@ class DocOutputGenerator(OutputGenerator):
         # Create file
         filename = directory + '/' + basename + '.txt'
         self.logMsg('diag', '# Generating include file:', filename)
-        fp = open(filename, 'w')
+        fp = open(filename, 'w', encoding='utf-8')
 
         # Asciidoc anchor
         write('// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry', file=fp)

src/spec/extensionStubSource.py

@@ -109,14 +109,16 @@ class ExtensionStubSourceOutputGenerator(OutputGenerator):
         #
         # Multiple inclusion protection & C++ wrappers.
 
-        # Internal state - accumulators for function pointers and function pointer initializatoin
+        # Internal state - accumulators for function pointers and function
+        # pointer initializatoin
         self.pointers = [];
         self.pointerInitializersInstance = [];
         self.pointerInitializersDevice = [];
 
         #
         # Write header protection
-        self.outFileHeader = open(self.genOpts.directory + '/' + 'vulkan_ext.h', 'w')
+        filename = self.genOpts.directory + '/' + 'vulkan_ext.h'
+        self.outFileHeader = open(filename, 'w', encoding='utf-8')
 
         write('#ifndef VULKAN_EXT_H', file=self.outFileHeader)
         write('#define VULKAN_EXT_H', file=self.outFileHeader)

src/spec/generator.py

@@ -318,7 +318,8 @@ class OutputGenerator:
         # Open specified output file. Not done in constructor since a
         # Generator can be used without writing to a file.
         if (self.genOpts.filename != None):
-            self.outFile = open(self.genOpts.directory + '/' + self.genOpts.filename, 'w')
+            filename = self.genOpts.directory + '/' + self.genOpts.filename
+            self.outFile = open(filename, 'w', encoding='utf-8')
         else:
             self.outFile = sys.stdout
     def endFile(self):

src/spec/genvk.py

@@ -302,16 +302,16 @@ if __name__ == '__main__':
 
     if (args.dump):
         write('* Dumping registry to regdump.txt', file=sys.stderr)
-        reg.dumpReg(filehandle = open('regdump.txt','w'))
+        reg.dumpReg(filehandle = open('regdump.txt', 'w', encoding='utf-8'))
 
     # create error/warning & diagnostic files
     if (args.errfile):
-        errWarn = open(args.errfile, 'w')
+        errWarn = open(args.errfile, 'w', encoding='utf-8')
     else:
         errWarn = sys.stderr
 
     if (args.diagfile):
-        diag = open(args.diagfile, 'w')
+        diag = open(args.diagfile, 'w', encoding='utf-8')
     else:
         diag = None
 

src/spec/hostsyncgenerator.py

@@ -55,7 +55,7 @@ class HostSynchronizationOutputGenerator(OutputGenerator):
             # Create file
             filename = self.genOpts.directory + '/' + 'parameters.txt'
             self.logMsg('diag', '# Generating include file:', filename)
-            fp = open(filename, 'w')
+            fp = open(filename, 'w', encoding='utf-8')
 
             # Host Synchronization
             write('// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry', file=fp)
@@ -69,7 +69,7 @@ class HostSynchronizationOutputGenerator(OutputGenerator):
             # Create file
             filename = self.genOpts.directory + '/' + '/parameterlists.txt'
             self.logMsg('diag', '# Generating include file:', filename)
-            fp = open(filename, 'w')
+            fp = open(filename, 'w', encoding='utf-8')
 
             # Host Synchronization
             write('// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry', file=fp)
@@ -83,7 +83,7 @@ class HostSynchronizationOutputGenerator(OutputGenerator):
             # Create file
             filename = self.genOpts.directory + '/' + '/implicit.txt'
             self.logMsg('diag', '# Generating include file:', filename)
-            fp = open(filename, 'w')
+            fp = open(filename, 'w', encoding='utf-8')
 
             # Host Synchronization
             write('// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry', file=fp)

src/spec/realign.py

@@ -40,11 +40,11 @@ def realignXML(fp):
             match = regexp[i].match(line)
             if (match):
                 if (not emitted):
-                    #print("# While processing line: " + line, end='')
+                    #print('# While processing line: ' + line, end='')
                     emitted = True
-                #print("# matched expression: " + patterns[i][0])
-                #print("# clause 1 = " + match.group(1))
-                #print("# clause 2 = " + match.group(2))
+                #print('# matched expression: ' + patterns[i][0])
+                #print('# clause 1 = ' + match.group(1))
+                #print('# clause 2 = ' + match.group(2))
                 line = match.group(1).ljust(column[i]) + match.group(2)
         if (emitted):
             print(line)
@@ -53,6 +53,6 @@ def realignXML(fp):
 
 if __name__ == '__main__':
     if (len(sys.argv) > 1):
-        realignXML(open(sys.argv[1],"r"))
+        realignXML(open(sys.argv[1], 'r', encoding='utf-8'))
     else:
         realignXML(sys.stdin)

src/spec/validitygenerator.py

@@ -82,7 +82,7 @@ class ValidityOutputGenerator(OutputGenerator):
         filename = directory + '/' + basename + '.txt'
         self.logMsg('diag', '# Generating include file:', filename)
 
-        fp = open(filename, 'w')
+        fp = open(filename, 'w', encoding='utf-8')
         # Asciidoc anchor
         write('// WARNING: DO NOT MODIFY! This file is automatically generated from the vk.xml registry', file=fp)
 
@@ -861,7 +861,7 @@ class ValidityOutputGenerator(OutputGenerator):
     def makeThreadSafetyBlock(self, cmd, paramtext):
         """Generate C function pointer typedef for <command> Element"""
         paramdecl = ''
-        
+
         # Find and add any parameters that are thread unsafe
         explicitexternsyncparams = cmd.findall(paramtext + "[@externsync]")
         if (explicitexternsyncparams is not None):
@@ -888,7 +888,7 @@ class ValidityOutputGenerator(OutputGenerator):
             paramdecl += '* '
             paramdecl += 'Host access to the sname:VkCommandPool that pname:commandBuffer was allocated from must: be externally synchronized'
             paramdecl += '\n'
-        
+
         # Find and add any "implicit" parameters that are thread unsafe
         implicitexternsyncparams = cmd.find('implicitexternsyncparams')
         if (implicitexternsyncparams is not None):

src/spec/vk.xml

@@ -104,7 +104,7 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
         <type category="define">// Vulkan 1.0 version number
 #define <name>VK_API_VERSION_1_0</name> <type>VK_MAKE_VERSION</type>(1, 0, 0)</type>    <!-- The patch version here should never be set to anything other than 0 -->
         <type category="define">// Version of this file
-#define <name>VK_HEADER_VERSION</name> 34</type>
+#define <name>VK_HEADER_VERSION</name> 35</type>
 
         <type category="define">
 #define <name>VK_DEFINE_HANDLE</name>(object) typedef struct object##_T* object;</type>
@@ -195,6 +195,10 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
         <type requires="VkDescriptorPoolCreateFlagBits"   category="bitmask">typedef <type>VkFlags</type> <name>VkDescriptorPoolCreateFlags</name>;</type>        <!-- Descriptor pool creation flags -->
         <type                                             category="bitmask">typedef <type>VkFlags</type> <name>VkDescriptorPoolResetFlags</name>;</type>         <!-- Descriptor pool reset flags -->
         <type requires="VkDependencyFlagBits"             category="bitmask">typedef <type>VkFlags</type> <name>VkDependencyFlags</name>;</type>                  <!-- Pipeline barrier and subpass dependency flags -->
+
+        <type requires="VkIndirectCommandsLayoutUsageFlagBitsNVX"  category="bitmask">typedef <type>VkFlags</type> <name>VkIndirectCommandsLayoutUsageFlagsNVX</name>;</type>  <!-- Device generated commands usage flags -->
+        <type requires="VkObjectEntryUsageFlagBitsNVX"             category="bitmask">typedef <type>VkFlags</type> <name>VkObjectEntryUsageFlagsNVX</name>;</type>             <!-- Object usage flags -->
+
             <!-- WSI extensions -->
         <type requires="VkCompositeAlphaFlagBitsKHR"      category="bitmask">typedef <type>VkFlags</type> <name>VkCompositeAlphaFlagsKHR</name>;</type>
         <type requires="VkDisplayPlaneAlphaFlagBitsKHR"   category="bitmask">typedef <type>VkFlags</type> <name>VkDisplayPlaneAlphaFlagsKHR</name>;</type>
@@ -239,6 +243,8 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
         <type category="handle" parent="VkDevice"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkFramebuffer</name>)</type>
         <type category="handle" parent="VkDevice"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkRenderPass</name>)</type>
         <type category="handle" parent="VkDevice"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkPipelineCache</name>)</type>
+        <type category="handle" parent="VkDevice"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkObjectTableNVX</name>)</type>
+        <type category="handle" parent="VkDevice"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkIndirectCommandsLayoutNVX</name>)</type>
 
         <!-- WSI extensions -->
         <type category="handle"><type>VK_DEFINE_NON_DISPATCHABLE_HANDLE</type>(<name>VkDisplayKHR</name>)</type>
@@ -334,6 +340,10 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
         <type name="VkAttachmentDescriptionFlagBits" category="enum"/>
         <type name="VkDescriptorPoolCreateFlagBits" category="enum"/>
         <type name="VkDependencyFlagBits" category="enum"/>
+        <type name="VkIndirectCommandsLayoutUsageFlagBitsNVX" category="enum"/>
+        <type name="VkIndirectCommandsTokenTypeNVX" category="enum"/>
+        <type name="VkObjectEntryUsageFlagBitsNVX" category="enum"/>
+        <type name="VkObjectEntryTypeNVX" category="enum"/>
         <!-- WSI extensions -->
         <type name="VkColorSpaceKHR" category="enum"/>
         <type name="VkCompositeAlphaFlagBitsKHR" category="enum"/>
@@ -1444,21 +1454,21 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <member values="VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
             <member optional="true"><type>VkAndroidSurfaceCreateFlagsKHR</type>   <name>flags</name></member>    <!-- Reserved -->
-            <member><type>ANativeWindow</type>*                   <name>window</name></member>
+            <member noautovalidity="true"><type>ANativeWindow</type>*                   <name>window</name></member>
         </type>
         <type category="struct" name="VkMirSurfaceCreateInfoKHR">
             <member values="VK_STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
             <member optional="true"><type>VkMirSurfaceCreateFlagsKHR</type>   <name>flags</name></member>        <!-- Reserved -->
-            <member><type>MirConnection</type>*                   <name>connection</name></member>
-            <member><type>MirSurface</type>*                      <name>mirSurface</name></member>
+            <member noautovalidity="true"><type>MirConnection</type>*                   <name>connection</name></member>
+            <member noautovalidity="true"><type>MirSurface</type>*                      <name>mirSurface</name></member>
         </type>
         <type category="struct" name="VkWaylandSurfaceCreateInfoKHR">
             <member values="VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
             <member optional="true"><type>VkWaylandSurfaceCreateFlagsKHR</type>   <name>flags</name></member>    <!-- Reserved -->
-            <member>struct <type>wl_display</type>*               <name>display</name></member>
-            <member>struct <type>wl_surface</type>*               <name>surface</name></member>
+            <member noautovalidity="true">struct <type>wl_display</type>*               <name>display</name></member>
+            <member noautovalidity="true">struct <type>wl_surface</type>*               <name>surface</name></member>
         </type>
         <type category="struct" name="VkWin32SurfaceCreateInfoKHR">
             <member values="VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
@@ -1471,14 +1481,14 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <member values="VK_STRUCTURE_TYPE_XLIB_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
             <member optional="true"><type>VkXlibSurfaceCreateFlagsKHR</type>   <name>flags</name></member>       <!-- Reserved -->
-            <member><type>Display</type>*                         <name>dpy</name></member>
+            <member noautovalidity="true"><type>Display</type>*                         <name>dpy</name></member>
             <member><type>Window</type>                           <name>window</name></member>
         </type>
         <type category="struct" name="VkXcbSurfaceCreateInfoKHR">
             <member values="VK_STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>                    <!-- Pointer to next structure -->
             <member optional="true"><type>VkXcbSurfaceCreateFlagsKHR</type>   <name>flags</name></member>        <!-- Reserved -->
-            <member><type>xcb_connection_t</type>*                <name>connection</name></member>
+            <member noautovalidity="true"><type>xcb_connection_t</type>*                <name>connection</name></member>
             <member><type>xcb_window_t</type>                     <name>window</name></member>
         </type>
         <type category="struct" name="VkSurfaceFormatKHR" returnedonly="true">
@@ -1571,33 +1581,33 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <member optional="true"><type>VkImage</type>          <name>image</name></member>                    <!-- Image that this allocation will be bound to -->
             <member optional="true"><type>VkBuffer</type>         <name>buffer</name></member>                   <!-- Buffer that this allocation will be bound to -->
         </type>
-        <type category="struct" name="VkExternalImageFormatPropertiesNV">
+        <type category="struct" name="VkExternalImageFormatPropertiesNV" returnedonly="true">
             <member><type>VkImageFormatProperties</type>          <name>imageFormatProperties</name></member>
-            <member><type>VkExternalMemoryFeatureFlagsNV</type>   <name>externalMemoryFeatures</name></member>
-            <member><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>exportFromImportedHandleTypes</name></member>
-            <member><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>compatibleHandleTypes</name></member>
+            <member optional="true"><type>VkExternalMemoryFeatureFlagsNV</type>   <name>externalMemoryFeatures</name></member>
+            <member optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>exportFromImportedHandleTypes</name></member>
+            <member optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>compatibleHandleTypes</name></member>
         </type>
         <type category="struct" name="VkExternalMemoryImageCreateInfoNV">
             <member values="VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>
-            <member><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>handleTypes</name></member>
+            <member optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>handleTypes</name></member>
         </type>
         <type category="struct" name="VkExportMemoryAllocateInfoNV">
             <member values="VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>
-            <member><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>handleTypes</name></member>
+            <member optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>handleTypes</name></member>
         </type>
         <type category="struct" name="VkImportMemoryWin32HandleInfoNV">
             <member values="VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>
             <member optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>handleType</name></member>
-            <member><type>HANDLE</type>                           <name>handle</name></member>
+            <member optional="true"><type>HANDLE</type>                           <name>handle</name></member>
         </type>
         <type category="struct" name="VkExportMemoryWin32HandleInfoNV">
             <member values="VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
             <member>const <type>void</type>*                      <name>pNext</name></member>
-            <member>const <type>SECURITY_ATTRIBUTES</type>*       <name>pAttributes</name></member>
-            <member><type>DWORD</type>                            <name>dwAccess</name></member>
+            <member optional="true">const <type>SECURITY_ATTRIBUTES</type>*       <name>pAttributes</name></member>
+            <member optional="true"><type>DWORD</type>                            <name>dwAccess</name></member>
         </type>
         <type category="struct" name="VkWin32KeyedMutexAcquireReleaseInfoNV">
             <member values="VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV"><type>VkStructureType</type> <name>sType</name></member>
@@ -1610,6 +1620,106 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <member len="releaseCount">const <type>VkDeviceMemory</type>*            <name>pReleaseSyncs</name></member>
             <member len="releaseCount">const <type>uint64_t</type>*                  <name>pReleaseKeys</name></member>
         </type>
+
+        <type category="struct" name="VkDeviceGeneratedCommandsFeaturesNVX">
+            <member values="VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_FEATURES_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member><type>VkBool32</type>                         <name>computeBindingPointSupport</name></member>
+        </type>
+        <type category="struct" name="VkDeviceGeneratedCommandsLimitsNVX">
+            <member values="VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_LIMITS_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member><type>uint32_t</type>                         <name>maxIndirectCommandsLayoutTokenCount</name></member>
+            <member><type>uint32_t</type>                         <name>maxObjectEntryCounts</name></member>
+            <member><type>uint32_t</type>                         <name>minSequenceCountBufferOffsetAlignment</name></member>
+            <member><type>uint32_t</type>                         <name>minSequenceIndexBufferOffsetAlignment</name></member>
+            <member><type>uint32_t</type>                         <name>minCommandsTokenBufferOffsetAlignment</name></member>
+        </type>
+        <type category="struct" name="VkIndirectCommandsTokenNVX">
+            <member><type>VkIndirectCommandsTokenTypeNVX</type>      <name>tokenType</name></member>
+            <member><type>VkBuffer</type>                         <name>buffer</name></member>  <!-- buffer containing tableEntries and additional data for indirectCommands -->
+            <member><type>VkDeviceSize</type>                     <name>offset</name></member>  <!-- offset from the base address of the buffer -->
+        </type>
+        <type category="struct" name="VkIndirectCommandsLayoutTokenNVX">
+            <member><type>VkIndirectCommandsTokenTypeNVX</type>      <name>tokenType</name></member>
+            <member><type>uint32_t</type>                         <name>bindingUnit</name></member>  <!-- Binding unit for vertex attribute / descriptor set, offset for pushconstants -->
+            <member><type>uint32_t</type>                         <name>dynamicCount</name></member> <!-- Number of variable dynamic values for descriptor set / push constants -->
+            <member><type>uint32_t</type>                         <name>divisor</name></member>      <!-- Rate the which the array is advanced per element (must be power of 2, minimum 1) -->
+        </type>
+        <type category="struct" name="VkIndirectCommandsLayoutCreateInfoNVX">
+            <member values="VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member><type>VkPipelineBindPoint</type>                      <name>pipelineBindPoint</name></member>
+            <member><type>VkIndirectCommandsLayoutUsageFlagsNVX</type>    <name>flags</name></member>
+            <member><type>uint32_t</type>                                 <name>tokenCount</name></member>
+            <member len="tokenCount">const <type>VkIndirectCommandsLayoutTokenNVX</type>*  <name>pTokens</name></member>
+        </type>
+        <type category="struct" name="VkCmdProcessCommandsInfoNVX">
+            <member values="VK_STRUCTURE_TYPE_CMD_PROCESS_COMMANDS_INFO_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member externsync="true"><type>VkObjectTableNVX</type>                                         <name>objectTable</name></member>
+            <member><type>VkIndirectCommandsLayoutNVX</type>                              <name>indirectCommandsLayout</name></member>
+            <member><type>uint32_t</type>                                                 <name>indirectCommandsTokenCount</name></member>
+            <member len="tokenCount">const <type>VkIndirectCommandsTokenNVX</type>*       <name>pIndirectCommandsTokens</name></member>
+            <member><type>uint32_t</type>                                                 <name>maxSequencesCount</name></member>
+            <member optional="true" externsync="true"><type>VkCommandBuffer</type>                          <name>targetCommandBuffer</name></member>
+            <member optional="true"><type>VkBuffer</type>                                 <name>sequencesCountBuffer</name></member>
+            <member optional="true"><type>VkDeviceSize</type>                             <name>sequencesCountOffset</name></member>
+            <member optional="true"><type>VkBuffer</type>                                 <name>sequencesIndexBuffer</name></member>
+            <member optional="true"><type>VkDeviceSize</type>                             <name>sequencesIndexOffset</name></member>
+        </type>
+        <type category="struct" name="VkCmdReserveSpaceForCommandsInfoNVX">
+            <member values="VK_STRUCTURE_TYPE_CMD_RESERVE_SPACE_FOR_COMMANDS_INFO_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member externsync="true"><type>VkObjectTableNVX</type>                                         <name>objectTable</name></member>
+            <member><type>VkIndirectCommandsLayoutNVX</type>                              <name>indirectCommandsLayout</name></member>
+            <member><type>uint32_t</type>                                                 <name>maxSequencesCount</name></member>
+        </type>
+        <type category="struct" name="VkObjectTableCreateInfoNVX">
+            <member values="VK_STRUCTURE_TYPE_OBJECT_TABLE_CREATE_INFO_NVX"><type>VkStructureType</type> <name>sType</name></member>
+            <member>const <type>void</type>*                      <name>pNext</name></member>
+            <member><type>uint32_t</type>                                          <name>objectCount</name></member>
+            <member len="objectCount">const<type>VkObjectEntryTypeNVX</type>*       <name>pObjectEntryTypes</name></member>
+            <member len="objectCount">const<type>uint32_t</type>*                   <name>pObjectEntryCounts</name></member>
+            <member len="objectCount">const<type>VkObjectEntryUsageFlagsNVX</type>* <name>pObjectEntryUsageFlags</name></member>
+
+            <member><type>uint32_t</type> <name>maxUniformBuffersPerDescriptor</name></member>
+            <member><type>uint32_t</type> <name>maxStorageBuffersPerDescriptor</name></member>
+            <member><type>uint32_t</type> <name>maxStorageImagesPerDescriptor</name></member>
+            <member><type>uint32_t</type> <name>maxSampledImagesPerDescriptor</name></member>
+            <member><type>uint32_t</type> <name>maxPipelineLayouts</name></member>
+        </type>
+        <type category="struct" name="VkObjectTableEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+        </type>
+        <type category="struct" name="VkObjectTablePipelineEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+            <member><type>VkPipeline</type>                   <name>pipeline</name></member>
+        </type>
+        <type category="struct" name="VkObjectTableDescriptorSetEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+            <member><type>VkPipelineLayout</type>             <name>pipelineLayout</name></member>
+            <member><type>VkDescriptorSet</type>              <name>descriptorSet</name></member>
+        </type>
+        <type category="struct" name="VkObjectTableVertexBufferEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+            <member><type>VkBuffer</type>                     <name>buffer</name></member>
+        </type>
+        <type category="struct" name="VkObjectTableIndexBufferEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+            <member><type>VkBuffer</type>                     <name>buffer</name></member>
+        </type>
+        <type category="struct" name="VkObjectTablePushConstantEntryNVX">
+            <member><type>VkObjectEntryTypeNVX</type>         <name>type</name></member>
+            <member><type>VkObjectEntryUsageFlagsNVX</type>   <name>flags</name></member>
+            <member><type>VkPipelineLayout</type>             <name>pipelineLayout</name></member>
+            <member><type>VkShaderStageFlags</type>           <name>stageFlags</name></member>
+        </type>
     </types>
 
     <!-- SECTION: Vulkan enumerant (token) definitions. -->
@@ -2434,7 +2544,33 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
         <enum value="0" name="VK_VALIDATION_CHECK_ALL_EXT"/>
         <!-- Placeholder for validation enums to be defined for VK_EXT_Validation_flags extension -->
     </enums>
-
+    <enums name="VkIndirectCommandsLayoutUsageFlagBitsNVX" type="bitmask">
+        <enum bitpos="0" name="VK_INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NVX"/> <!-- sequences can be processed in implementation-dependent order -->
+        <enum bitpos="1" name="VK_INDIRECT_COMMANDS_LAYOUT_USAGE_SPARSE_SEQUENCES_BIT_NVX"/>    <!-- likely generated with a high difference in actual sequencesCount and maxSequencesCount -->
+        <enum bitpos="2" name="VK_INDIRECT_COMMANDS_LAYOUT_USAGE_EMPTY_EXECUTIONS_BIT_NVX"/>    <!-- likely to contain draw/dispatch calls that are zero-sized -->
+        <enum bitpos="3" name="VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NVX"/>   <!-- custom sequence index permutation (32-bit) is provided -->
+    </enums>
+    <enums name="VkObjectEntryUsageFlagBitsNVX" type="bitmask">
+        <enum bitpos="0" name="VK_OBJECT_ENTRY_USAGE_GRAPHICS_BIT_NVX"/>
+        <enum bitpos="1" name="VK_OBJECT_ENTRY_USAGE_COMPUTE_BIT_NVX"/>
+    </enums>
+    <enums name="VkIndirectCommandsTokenTypeNVX" type="enum">
+        <enum value="0" name="VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX"/>        <!-- array of 32bit tableEntry in the object table -->
+        <enum value="1" name="VK_INDIRECT_COMMANDS_TOKEN_DESCRIPTOR_SET_NVX"/>  <!-- array of (32 bit tableEntry + variable count 32bit offsets) -->
+        <enum value="2" name="VK_INDIRECT_COMMANDS_TOKEN_INDEX_BUFFER_NVX"/>    <!-- array of (32 bit tableEntry + optional 32bit offset) -->
+        <enum value="3" name="VK_INDIRECT_COMMANDS_TOKEN_VERTEX_BUFFER_NVX"/>   <!-- array of (32 bit tableEntry + optional 32bit offset) -->
+        <enum value="4" name="VK_INDIRECT_COMMANDS_TOKEN_PUSH_CONSTANT_NVX"/>   <!-- array of (32 bit tableEntry + variable count 32bit values ) -->
+        <enum value="5" name="VK_INDIRECT_COMMANDS_TOKEN_DRAW_INDEXED_NVX"/>    <!-- array of VkDrawIndexedIndirectCommand -->
+        <enum value="6" name="VK_INDIRECT_COMMANDS_TOKEN_DRAW_NVX"/>            <!-- array of VkDrawIndirectCommand -->
+        <enum value="7" name="VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX"/>        <!-- array of VkDispatchIndirectCommand -->
+    </enums>
+    <enums name="VkObjectEntryTypeNVX" type="enum">
+        <enum value="0" name="VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX"/>
+        <enum value="1" name="VK_OBJECT_ENTRY_PIPELINE_NVX"/>
+        <enum value="2" name="VK_OBJECT_ENTRY_INDEX_BUFFER_NVX"/>
+        <enum value="3" name="VK_OBJECT_ENTRY_VERTEX_BUFFER_NVX"/>
+        <enum value="4" name="VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX"/>
+    </enums>
     <!-- SECTION: Vulkan command definitions -->
     <commands>
         <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY,VK_ERROR_INITIALIZATION_FAILED,VK_ERROR_LAYER_NOT_PRESENT,VK_ERROR_EXTENSION_NOT_PRESENT,VK_ERROR_INCOMPATIBLE_DRIVER">
@@ -3600,8 +3736,8 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <param><type>uint64_t</type> <name>object</name></param>
             <param><type>size_t</type> <name>location</name></param>
             <param><type>int32_t</type> <name>messageCode</name></param>
-            <param>const <type>char</type>* <name>pLayerPrefix</name></param>
-            <param>const <type>char</type>* <name>pMessage</name></param>
+            <param len="null-terminated">const <type>char</type>* <name>pLayerPrefix</name></param>
+            <param len="null-terminated">const <type>char</type>* <name>pMessage</name></param>
         </command>
         <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
             <proto><type>VkResult</type> <name>vkDebugMarkerSetObjectNameEXT</name></proto>
@@ -3634,8 +3770,8 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <param><type>VkImageType</type> <name>type</name></param>
             <param><type>VkImageTiling</type> <name>tiling</name></param>
             <param><type>VkImageUsageFlags</type> <name>usage</name></param>
-            <param><type>VkImageCreateFlags</type> <name>flags</name></param>
-            <param><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>externalHandleType</name></param>
+            <param optional="true"><type>VkImageCreateFlags</type> <name>flags</name></param>
+            <param optional="true"><type>VkExternalMemoryHandleTypeFlagsNV</type> <name>externalHandleType</name></param>
             <param><type>VkExternalImageFormatPropertiesNV</type>* <name>pExternalImageFormatProperties</name></param>
         </command>
         <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_TOO_MANY_OBJECTS,VK_ERROR_OUT_OF_HOST_MEMORY">
@@ -3665,6 +3801,64 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
             <param><type>uint32_t</type> <name>maxDrawCount</name></param>
             <param><type>uint32_t</type> <name>stride</name></param>
         </command>
+        <command queues="graphics,compute" renderpass="inside" cmdbufferlevel="primary,secondary">
+            <proto><type>void</type> <name>vkCmdProcessCommandsNVX</name></proto>
+            <param externsync="true"><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
+            <param>const <type>VkCmdProcessCommandsInfoNVX</type>* <name>pProcessCommandsInfo</name></param>
+        </command>
+        <command queues="graphics,compute" renderpass="inside" cmdbufferlevel="secondary">
+            <proto><type>void</type> <name>vkCmdReserveSpaceForCommandsNVX</name></proto>
+            <param externsync="true"><type>VkCommandBuffer</type> <name>commandBuffer</name></param>
+            <param>const <type>VkCmdReserveSpaceForCommandsInfoNVX</type>* <name>pReserveSpaceInfo</name></param>
+        </command>
+        <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
+            <proto><type>VkResult</type> <name>vkCreateIndirectCommandsLayoutNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param>const <type>VkIndirectCommandsLayoutCreateInfoNVX</type>* <name>pCreateInfo</name></param>
+            <param optional="true">const <type>VkAllocationCallbacks</type>* <name>pAllocator</name></param>
+            <param><type>VkIndirectCommandsLayoutNVX</type>* <name>pIndirectCommandsLayout</name></param>
+        </command>
+        <command>
+            <proto><type>void</type> <name>vkDestroyIndirectCommandsLayoutNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param><type>VkIndirectCommandsLayoutNVX</type> <name>indirectCommandsLayout</name></param>
+            <param optional="true">const <type>VkAllocationCallbacks</type>* <name>pAllocator</name></param>
+        </command>
+        <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
+            <proto><type>VkResult</type> <name>vkCreateObjectTableNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param>const <type>VkObjectTableCreateInfoNVX</type>* <name>pCreateInfo</name></param>
+            <param optional="true">const <type>VkAllocationCallbacks</type>* <name>pAllocator</name></param>
+            <param><type>VkObjectTableNVX</type>* <name>pObjectTable</name></param>
+        </command>
+        <command>
+            <proto><type>void</type> <name>vkDestroyObjectTableNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param externsync="true"><type>VkObjectTableNVX</type> <name>objectTable</name></param>
+            <param optional="true">const <type>VkAllocationCallbacks</type>* <name>pAllocator</name></param>
+        </command>
+        <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
+            <proto><type>VkResult</type> <name>vkRegisterObjectsNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param externsync="true"><type>VkObjectTableNVX</type> <name>objectTable</name></param>
+            <param><type>uint32_t</type> <name>objectCount</name></param>
+            <param len="objectCount">const <type>VkObjectTableEntryNVX</type>* const*    <name>ppObjectTableEntries</name></param>
+            <param len="objectCount">const <type>uint32_t</type>* <name>pObjectIndices</name></param>
+        </command>
+        <command successcodes="VK_SUCCESS" errorcodes="VK_ERROR_OUT_OF_HOST_MEMORY,VK_ERROR_OUT_OF_DEVICE_MEMORY">
+            <proto><type>VkResult</type> <name>vkUnregisterObjectsNVX</name></proto>
+            <param><type>VkDevice</type> <name>device</name></param>
+            <param externsync="true"><type>VkObjectTableNVX</type> <name>objectTable</name></param>
+            <param><type>uint32_t</type> <name>objectCount</name></param>
+            <param len="objectCount">const <type>VkObjectEntryTypeNVX</type>* <name>pObjectEntryTypes</name></param>
+            <param len="objectCount">const <type>uint32_t</type>* <name>pObjectIndices</name></param>
+        </command>
+        <command>
+            <proto><type>void</type> <name>vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX</name></proto>
+            <param><type>VkPhysicalDevice</type> <name>physicalDevice</name></param>
+            <param><type>VkDeviceGeneratedCommandsFeaturesNVX</type>* <name>pFeatures</name></param>
+            <param><type>VkDeviceGeneratedCommandsLimitsNVX</type>* <name>pLimits</name></param>
+        </command>
     </commands>
 
     <!-- SECTION: Vulkan API interface definitions -->
@@ -4547,12 +4741,50 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
                  <enum value="&quot;VK_KHR_extension_86&quot;"           name="VK_KHR_EXTENSION_86_EXTENSION_NAME"/>
               </require>
          </extension>
-         <extension name="VK_NV_extension_87" number="87" author="NVIDIA" contact="Christoph Kubisch @pixeljetstream" supported="disabled">
-             <require>
-                 <enum value="0"                                         name="VK_NV_EXTENSION_87_SPEC_VERSION"/>
-                 <enum value="&quot;VK_NV_extension_87&quot;"            name="VK_NV_EXTENSION_87_EXTENSION_NAME"/>
-              </require>
-         </extension>
+        <extension name="VK_NVX_device_generated_commands" number="87" type="device" author="NVIDIA" contact="Christoph Kubisch @pixeljetstream" supported="vulkan">
+          <require>
+              <enum value="1"                                               name="VK_NVX_DEVICE_GENERATED_COMMANDS_SPEC_VERSION"/>
+              <enum value="&quot;VK_NVX_device_generated_commands&quot;"    name="VK_NVX_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME"/>
+              <enum offset="0" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_OBJECT_TABLE_CREATE_INFO_NVX"/>
+              <enum offset="1" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NVX"/>
+              <enum offset="2" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_CMD_PROCESS_COMMANDS_INFO_NVX"/>
+              <enum offset="3" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_CMD_RESERVE_SPACE_FOR_COMMANDS_INFO_NVX"/>
+              <enum offset="4" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_LIMITS_NVX"/>
+              <enum offset="5" extends="VkStructureType"                    name="VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_FEATURES_NVX"/>
+              <enum bitpos="17" extends="VkPipelineStageFlagBits"           name="VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX"/>
+              <type name="VkObjectTableNVX"/>
+              <type name="VkIndirectCommandsLayoutNVX"/>
+              <type name="VkIndirectCommandsLayoutUsageFlagsNVX"/>
+              <type name="VkObjectEntryUsageFlagsNVX"/>
+              <type name="VkIndirectCommandsLayoutUsageFlagBitsNVX"/>
+              <type name="VkIndirectCommandsTokenTypeNVX"/>
+              <type name="VkObjectEntryUsageFlagBitsNVX"/>
+              <type name="VkObjectEntryTypeNVX"/>
+              <type name="VkDeviceGeneratedCommandsFeaturesNVX"/>
+              <type name="VkDeviceGeneratedCommandsLimitsNVX"/>
+              <type name="VkIndirectCommandsTokenNVX"/>
+              <type name="VkIndirectCommandsLayoutTokenNVX"/>
+              <type name="VkIndirectCommandsLayoutCreateInfoNVX"/>
+              <type name="VkCmdProcessCommandsInfoNVX"/>
+              <type name="VkCmdReserveSpaceForCommandsInfoNVX"/>
+              <type name="VkObjectTableCreateInfoNVX"/>
+              <type name="VkObjectTableEntryNVX"/>
+              <type name="VkObjectTablePipelineEntryNVX"/>
+              <type name="VkObjectTableDescriptorSetEntryNVX"/>
+              <type name="VkObjectTableVertexBufferEntryNVX"/>
+              <type name="VkObjectTableIndexBufferEntryNVX"/>
+              <type name="VkObjectTablePushConstantEntryNVX"/>
+              <command name="vkCmdProcessCommandsNVX"/>
+              <command name="vkCmdReserveSpaceForCommandsNVX"/>
+              <command name="vkCreateIndirectCommandsLayoutNVX"/>
+              <command name="vkDestroyIndirectCommandsLayoutNVX"/>
+              <command name="vkCreateObjectTableNVX"/>
+              <command name="vkDestroyObjectTableNVX"/>
+              <command name="vkRegisterObjectsNVX"/>
+              <command name="vkUnregisterObjectsNVX"/>
+              <command name="vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX"/>
+          </require>
+        </extension>
          <extension name="VK_KHR_extension_88" number="88" author="NV" contact="Eric Werness @ewerness" supported="disabled">
              <require>
                  <enum value="0"                                         name="VK_KHR_EXTENSION_88_SPEC_VERSION"/>
@@ -4577,5 +4809,11 @@ maintained in the master branch of the Khronos Vulkan GitHub project.
                  <enum value="&quot;VK_EXT_extension_91&quot;"           name="VK_EXT_EXTENSION_91_EXTENSION_NAME"/>
               </require>
          </extension>
+         <extension name="VK_EXT_extension_92" number="92" author="NV" contact="James Jones @cubanismo" supported="disabled">
+             <require>
+                 <enum value="0"                                         name="VK_EXT_EXTENSION_92_SPEC_VERSION"/>
+                 <enum value="&quot;VK_EXT_extension_92&quot;"           name="VK_EXT_EXTENSION_92_EXTENSION_NAME"/>
+              </require>
+         </extension>
     </extensions>
 </registry>

src/vulkan/vulkan.h

@@ -43,7 +43,7 @@ extern "C" {
 #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
 #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
 // Version of this file
-#define VK_HEADER_VERSION 34
+#define VK_HEADER_VERSION 35
 
 
 #define VK_NULL_HANDLE 0
@@ -226,6 +226,12 @@ typedef enum VkStructureType {
     VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_NV = 1000057001,
     VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV = 1000058000,
     VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT = 1000061000,
+    VK_STRUCTURE_TYPE_OBJECT_TABLE_CREATE_INFO_NVX = 1000086000,
+    VK_STRUCTURE_TYPE_INDIRECT_COMMANDS_LAYOUT_CREATE_INFO_NVX = 1000086001,
+    VK_STRUCTURE_TYPE_CMD_PROCESS_COMMANDS_INFO_NVX = 1000086002,
+    VK_STRUCTURE_TYPE_CMD_RESERVE_SPACE_FOR_COMMANDS_INFO_NVX = 1000086003,
+    VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_LIMITS_NVX = 1000086004,
+    VK_STRUCTURE_TYPE_DEVICE_GENERATED_COMMANDS_FEATURES_NVX = 1000086005,
     VK_STRUCTURE_TYPE_BEGIN_RANGE = VK_STRUCTURE_TYPE_APPLICATION_INFO,
     VK_STRUCTURE_TYPE_END_RANGE = VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO,
     VK_STRUCTURE_TYPE_RANGE_SIZE = (VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO - VK_STRUCTURE_TYPE_APPLICATION_INFO + 1),
@@ -918,6 +924,7 @@ typedef enum VkPipelineStageFlagBits {
     VK_PIPELINE_STAGE_HOST_BIT = 0x00004000,
     VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT = 0x00008000,
     VK_PIPELINE_STAGE_ALL_COMMANDS_BIT = 0x00010000,
+    VK_PIPELINE_STAGE_COMMAND_PROCESS_BIT_NVX = 0x00020000,
     VK_PIPELINE_STAGE_FLAG_BITS_MAX_ENUM = 0x7FFFFFFF
 } VkPipelineStageFlagBits;
 typedef VkFlags VkPipelineStageFlags;
@@ -4154,6 +4161,232 @@ typedef struct VkValidationFlagsEXT {
 
 
 
+#define VK_NVX_device_generated_commands 1
+VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkObjectTableNVX)
+VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkIndirectCommandsLayoutNVX)
+
+#define VK_NVX_DEVICE_GENERATED_COMMANDS_SPEC_VERSION 1
+#define VK_NVX_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME "VK_NVX_device_generated_commands"
+
+
+typedef enum VkIndirectCommandsTokenTypeNVX {
+    VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX = 0,
+    VK_INDIRECT_COMMANDS_TOKEN_DESCRIPTOR_SET_NVX = 1,
+    VK_INDIRECT_COMMANDS_TOKEN_INDEX_BUFFER_NVX = 2,
+    VK_INDIRECT_COMMANDS_TOKEN_VERTEX_BUFFER_NVX = 3,
+    VK_INDIRECT_COMMANDS_TOKEN_PUSH_CONSTANT_NVX = 4,
+    VK_INDIRECT_COMMANDS_TOKEN_DRAW_INDEXED_NVX = 5,
+    VK_INDIRECT_COMMANDS_TOKEN_DRAW_NVX = 6,
+    VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX = 7,
+    VK_INDIRECT_COMMANDS_TOKEN_TYPE_BEGIN_RANGE_NVX = VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX,
+    VK_INDIRECT_COMMANDS_TOKEN_TYPE_END_RANGE_NVX = VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX,
+    VK_INDIRECT_COMMANDS_TOKEN_TYPE_RANGE_SIZE_NVX = (VK_INDIRECT_COMMANDS_TOKEN_DISPATCH_NVX - VK_INDIRECT_COMMANDS_TOKEN_PIPELINE_NVX + 1),
+    VK_INDIRECT_COMMANDS_TOKEN_TYPE_MAX_ENUM_NVX = 0x7FFFFFFF
+} VkIndirectCommandsTokenTypeNVX;
+
+typedef enum VkObjectEntryTypeNVX {
+    VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX = 0,
+    VK_OBJECT_ENTRY_PIPELINE_NVX = 1,
+    VK_OBJECT_ENTRY_INDEX_BUFFER_NVX = 2,
+    VK_OBJECT_ENTRY_VERTEX_BUFFER_NVX = 3,
+    VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX = 4,
+    VK_OBJECT_ENTRY_TYPE_BEGIN_RANGE_NVX = VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX,
+    VK_OBJECT_ENTRY_TYPE_END_RANGE_NVX = VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX,
+    VK_OBJECT_ENTRY_TYPE_RANGE_SIZE_NVX = (VK_OBJECT_ENTRY_PUSH_CONSTANT_NVX - VK_OBJECT_ENTRY_DESCRIPTOR_SET_NVX + 1),
+    VK_OBJECT_ENTRY_TYPE_MAX_ENUM_NVX = 0x7FFFFFFF
+} VkObjectEntryTypeNVX;
+
+
+typedef enum VkIndirectCommandsLayoutUsageFlagBitsNVX {
+    VK_INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NVX = 0x00000001,
+    VK_INDIRECT_COMMANDS_LAYOUT_USAGE_SPARSE_SEQUENCES_BIT_NVX = 0x00000002,
+    VK_INDIRECT_COMMANDS_LAYOUT_USAGE_EMPTY_EXECUTIONS_BIT_NVX = 0x00000004,
+    VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NVX = 0x00000008,
+    VK_INDIRECT_COMMANDS_LAYOUT_USAGE_FLAG_BITS_MAX_ENUM_NVX = 0x7FFFFFFF
+} VkIndirectCommandsLayoutUsageFlagBitsNVX;
+typedef VkFlags VkIndirectCommandsLayoutUsageFlagsNVX;
+
+typedef enum VkObjectEntryUsageFlagBitsNVX {
+    VK_OBJECT_ENTRY_USAGE_GRAPHICS_BIT_NVX = 0x00000001,
+    VK_OBJECT_ENTRY_USAGE_COMPUTE_BIT_NVX = 0x00000002,
+    VK_OBJECT_ENTRY_USAGE_FLAG_BITS_MAX_ENUM_NVX = 0x7FFFFFFF
+} VkObjectEntryUsageFlagBitsNVX;
+typedef VkFlags VkObjectEntryUsageFlagsNVX;
+
+typedef struct VkDeviceGeneratedCommandsFeaturesNVX {
+    VkStructureType    sType;
+    const void*        pNext;
+    VkBool32           computeBindingPointSupport;
+} VkDeviceGeneratedCommandsFeaturesNVX;
+
+typedef struct VkDeviceGeneratedCommandsLimitsNVX {
+    VkStructureType    sType;
+    const void*        pNext;
+    uint32_t           maxIndirectCommandsLayoutTokenCount;
+    uint32_t           maxObjectEntryCounts;
+    uint32_t           minSequenceCountBufferOffsetAlignment;
+    uint32_t           minSequenceIndexBufferOffsetAlignment;
+    uint32_t           minCommandsTokenBufferOffsetAlignment;
+} VkDeviceGeneratedCommandsLimitsNVX;
+
+typedef struct VkIndirectCommandsTokenNVX {
+    VkIndirectCommandsTokenTypeNVX    tokenType;
+    VkBuffer                          buffer;
+    VkDeviceSize                      offset;
+} VkIndirectCommandsTokenNVX;
+
+typedef struct VkIndirectCommandsLayoutTokenNVX {
+    VkIndirectCommandsTokenTypeNVX    tokenType;
+    uint32_t                          bindingUnit;
+    uint32_t                          dynamicCount;
+    uint32_t                          divisor;
+} VkIndirectCommandsLayoutTokenNVX;
+
+typedef struct VkIndirectCommandsLayoutCreateInfoNVX {
+    VkStructureType                            sType;
+    const void*                                pNext;
+    VkPipelineBindPoint                        pipelineBindPoint;
+    VkIndirectCommandsLayoutUsageFlagsNVX      flags;
+    uint32_t                                   tokenCount;
+    const VkIndirectCommandsLayoutTokenNVX*    pTokens;
+} VkIndirectCommandsLayoutCreateInfoNVX;
+
+typedef struct VkCmdProcessCommandsInfoNVX {
+    VkStructureType                      sType;
+    const void*                          pNext;
+    VkObjectTableNVX                     objectTable;
+    VkIndirectCommandsLayoutNVX          indirectCommandsLayout;
+    uint32_t                             indirectCommandsTokenCount;
+    const VkIndirectCommandsTokenNVX*    pIndirectCommandsTokens;
+    uint32_t                             maxSequencesCount;
+    VkCommandBuffer                      targetCommandBuffer;
+    VkBuffer                             sequencesCountBuffer;
+    VkDeviceSize                         sequencesCountOffset;
+    VkBuffer                             sequencesIndexBuffer;
+    VkDeviceSize                         sequencesIndexOffset;
+} VkCmdProcessCommandsInfoNVX;
+
+typedef struct VkCmdReserveSpaceForCommandsInfoNVX {
+    VkStructureType                sType;
+    const void*                    pNext;
+    VkObjectTableNVX               objectTable;
+    VkIndirectCommandsLayoutNVX    indirectCommandsLayout;
+    uint32_t                       maxSequencesCount;
+} VkCmdReserveSpaceForCommandsInfoNVX;
+
+typedef struct VkObjectTableCreateInfoNVX {
+    VkStructureType                     sType;
+    const void*                         pNext;
+    uint32_t                            objectCount;
+    constVkObjectEntryTypeNVX*          pObjectEntryTypes;
+    constuint32_t*                      pObjectEntryCounts;
+    constVkObjectEntryUsageFlagsNVX*    pObjectEntryUsageFlags;
+    uint32_t                            maxUniformBuffersPerDescriptor;
+    uint32_t                            maxStorageBuffersPerDescriptor;
+    uint32_t                            maxStorageImagesPerDescriptor;
+    uint32_t                            maxSampledImagesPerDescriptor;
+    uint32_t                            maxPipelineLayouts;
+} VkObjectTableCreateInfoNVX;
+
+typedef struct VkObjectTableEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+} VkObjectTableEntryNVX;
+
+typedef struct VkObjectTablePipelineEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+    VkPipeline                    pipeline;
+} VkObjectTablePipelineEntryNVX;
+
+typedef struct VkObjectTableDescriptorSetEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+    VkPipelineLayout              pipelineLayout;
+    VkDescriptorSet               descriptorSet;
+} VkObjectTableDescriptorSetEntryNVX;
+
+typedef struct VkObjectTableVertexBufferEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+    VkBuffer                      buffer;
+} VkObjectTableVertexBufferEntryNVX;
+
+typedef struct VkObjectTableIndexBufferEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+    VkBuffer                      buffer;
+} VkObjectTableIndexBufferEntryNVX;
+
+typedef struct VkObjectTablePushConstantEntryNVX {
+    VkObjectEntryTypeNVX          type;
+    VkObjectEntryUsageFlagsNVX    flags;
+    VkPipelineLayout              pipelineLayout;
+    VkShaderStageFlags            stageFlags;
+} VkObjectTablePushConstantEntryNVX;
+
+
+typedef void (VKAPI_PTR *PFN_vkCmdProcessCommandsNVX)(VkCommandBuffer commandBuffer, const VkCmdProcessCommandsInfoNVX* pProcessCommandsInfo);
+typedef void (VKAPI_PTR *PFN_vkCmdReserveSpaceForCommandsNVX)(VkCommandBuffer commandBuffer, const VkCmdReserveSpaceForCommandsInfoNVX* pReserveSpaceInfo);
+typedef VkResult (VKAPI_PTR *PFN_vkCreateIndirectCommandsLayoutNVX)(VkDevice device, const VkIndirectCommandsLayoutCreateInfoNVX* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkIndirectCommandsLayoutNVX* pIndirectCommandsLayout);
+typedef void (VKAPI_PTR *PFN_vkDestroyIndirectCommandsLayoutNVX)(VkDevice device, VkIndirectCommandsLayoutNVX indirectCommandsLayout, const VkAllocationCallbacks* pAllocator);
+typedef VkResult (VKAPI_PTR *PFN_vkCreateObjectTableNVX)(VkDevice device, const VkObjectTableCreateInfoNVX* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkObjectTableNVX* pObjectTable);
+typedef void (VKAPI_PTR *PFN_vkDestroyObjectTableNVX)(VkDevice device, VkObjectTableNVX objectTable, const VkAllocationCallbacks* pAllocator);
+typedef VkResult (VKAPI_PTR *PFN_vkRegisterObjectsNVX)(VkDevice device, VkObjectTableNVX objectTable, uint32_t objectCount, const VkObjectTableEntryNVX* const*    ppObjectTableEntries, const uint32_t* pObjectIndices);
+typedef VkResult (VKAPI_PTR *PFN_vkUnregisterObjectsNVX)(VkDevice device, VkObjectTableNVX objectTable, uint32_t objectCount, const VkObjectEntryTypeNVX* pObjectEntryTypes, const uint32_t* pObjectIndices);
+typedef void (VKAPI_PTR *PFN_vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX)(VkPhysicalDevice physicalDevice, VkDeviceGeneratedCommandsFeaturesNVX* pFeatures, VkDeviceGeneratedCommandsLimitsNVX* pLimits);
+
+#ifndef VK_NO_PROTOTYPES
+VKAPI_ATTR void VKAPI_CALL vkCmdProcessCommandsNVX(
+    VkCommandBuffer                             commandBuffer,
+    const VkCmdProcessCommandsInfoNVX*          pProcessCommandsInfo);
+
+VKAPI_ATTR void VKAPI_CALL vkCmdReserveSpaceForCommandsNVX(
+    VkCommandBuffer                             commandBuffer,
+    const VkCmdReserveSpaceForCommandsInfoNVX*  pReserveSpaceInfo);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkCreateIndirectCommandsLayoutNVX(
+    VkDevice                                    device,
+    const VkIndirectCommandsLayoutCreateInfoNVX* pCreateInfo,
+    const VkAllocationCallbacks*                pAllocator,
+    VkIndirectCommandsLayoutNVX*                pIndirectCommandsLayout);
+
+VKAPI_ATTR void VKAPI_CALL vkDestroyIndirectCommandsLayoutNVX(
+    VkDevice                                    device,
+    VkIndirectCommandsLayoutNVX                 indirectCommandsLayout,
+    const VkAllocationCallbacks*                pAllocator);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkCreateObjectTableNVX(
+    VkDevice                                    device,
+    const VkObjectTableCreateInfoNVX*           pCreateInfo,
+    const VkAllocationCallbacks*                pAllocator,
+    VkObjectTableNVX*                           pObjectTable);
+
+VKAPI_ATTR void VKAPI_CALL vkDestroyObjectTableNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    const VkAllocationCallbacks*                pAllocator);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkRegisterObjectsNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    uint32_t                                    objectCount,
+    const VkObjectTableEntryNVX* const*         ppObjectTableEntries,
+    const uint32_t*                             pObjectIndices);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkUnregisterObjectsNVX(
+    VkDevice                                    device,
+    VkObjectTableNVX                            objectTable,
+    uint32_t                                    objectCount,
+    const VkObjectEntryTypeNVX*                 pObjectEntryTypes,
+    const uint32_t*                             pObjectIndices);
+
+VKAPI_ATTR void VKAPI_CALL vkGetPhysicalDeviceGeneratedCommandsPropertiesNVX(
+    VkPhysicalDevice                            physicalDevice,
+    VkDeviceGeneratedCommandsFeaturesNVX*       pFeatures,
+    VkDeviceGeneratedCommandsLimitsNVX*         pLimits);
+#endif
+
 #ifdef __cplusplus
 }
 #endif