vulkan-3.24.5: Bindings to the Vulkan graphics API.
Safe HaskellSafe-Inferred
LanguageHaskell2010

Vulkan.Extensions.VK_NV_device_generated_commands

Description

Name

VK_NV_device_generated_commands - device extension

VK_NV_device_generated_commands

Name String
VK_NV_device_generated_commands
Extension Type
Device extension
Registered Extension Number
278
Revision
3
Extension and Version Dependencies
  • Requires support for Vulkan 1.1
  • Requires VK_KHR_buffer_device_address to be enabled for any device-level functionality
Contact

Other Extension Metadata

Last Modified Date
2020-02-20
Interactions and External Dependencies
  • This extension requires Vulkan 1.1
  • This extension requires VK_EXT_buffer_device_address or VK_KHR_buffer_device_address or Vulkan 1.2 for the ability to bind vertex and index buffers on the device.
  • This extension interacts with VK_NV_mesh_shader. If the latter extension is not supported, remove the command token to initiate mesh tasks drawing in this extension.
Contributors
  • Christoph Kubisch, NVIDIA
  • Pierre Boudier, NVIDIA
  • Jeff Bolz, NVIDIA
  • Eric Werness, NVIDIA
  • Yuriy O’Donnell, Epic Games
  • Baldur Karlsson, Valve
  • Mathias Schott, NVIDIA
  • Tyson Smith, NVIDIA
  • Ingo Esser, NVIDIA

Description

This extension allows the device to generate a number of critical graphics 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, etc. Implementing those on the device does not require any special extension, since an application is free to define its own data structures, 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 to 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 a scenario, or updates synchronized on the host.

The intended usage for this extension is for the application to:

For each draw in a sequence, the following can be specified:

  • a different shader group
  • a number of vertex buffer bindings
  • a different index buffer, with an optional dynamic offset and index type
  • a number of different push constants
  • a flag that encodes the primitive winding

While the GPU can be faster than a CPU to generate the commands, it will not happen asynchronously to the device, therefore the primary use-case is generating “less” total work (occlusion culling, classification to use specialized shaders, etc.).

New Object Types

New Commands

New Structures

New Enums

New Bitmasks

New Enum Constants

Issues

1) How to name this extension ?

VK_NV_device_generated_commands

As usual, one of the hardest issues ;)

Alternatives: 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 VK_indirect_generated_commands

2) Should we use a serial stateful token stream or stateless sequence descriptions?

Similarly to Pipeline, fixed layouts have the most likelihood to be cross-vendor adoptable. They also benefit from being processable in parallel. This is a different design choice compared to the serial command stream generated through GL_NV_command_list.

3) How to name a sequence description?

VkIndirectCommandsLayout as in the NVX extension predecessor.

Alternative: VkGeneratedCommandsLayout

4) Do we want to provide indirectCommands inputs with layout or at indirectCommands time?

Separate layout from data as Vulkan does. Provide full flexibility for indirectCommands.

5) Should the input be provided as SoA or AoS?

Both ways are desirable. AoS can provide portability to other APIs and easier to setup, while SoA allows to update individual inputs in a cache-efficient manner, when others remain static.

6) How do we make developers aware of the memory requirements of implementation-dependent data used for the generated commands?

Make the API explicit and introduce a preprocess Buffer. Developers have to allocate it using getGeneratedCommandsMemoryRequirementsNV.

In the NVX version the requirements were hidden implicitly as part of the command buffer reservation process, however as the memory requirements can be substantial, we want to give developers the ability to budget the memory themselves. By lowering the maxSequencesCount the memory consumption can be reduced. Furthermore reuse of the memory is possible, for example for doing explicit preprocessing and execution in a ping-pong fashion.

The actual buffer size is implementation-dependent and may be zero, i.e. not always required.

When making use of Graphics Shader Groups, the programs should behave similar with regards to vertex inputs, clipping and culling outputs of the geometry stage, as well as sample shading behavior in fragment shaders, to reduce the amount of the worst-case memory approximation.

7) Should we allow additional per-sequence dynamic state changes?

Yes

Introduced a lightweight indirect state flag IndirectStateFlagBitsNV. So far only switching front face winding state is exposed. Especially in CAD/DCC mirrored transforms that require such changes are common, and similar flexibility is given in the ray tracing instance description.

The flag could be extended further, for example to switch between primitive-lists or -strips, or make other state modifications.

Furthermore, as new tokens can be added easily, future extension could add the ability to change any DynamicState.

8) How do we allow re-using already “generated” indirectCommands?

Expose a preprocessBuffer to reuse implementation-dependencyFlags data. Set the isPreprocessed to true in cmdExecuteGeneratedCommandsNV.

9) Under which conditions is cmdExecuteGeneratedCommandsNV legal?

It behaves like a regular draw call command.

10) Is cmdPreprocessGeneratedCommandsNV copying the input data or referencing it?

There are multiple implementations possible:

  • one could have some emulation code that parses 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 must not be modified after the call to cmdExecuteGeneratedCommandsNV has completed.

11) Which buffer usage flags are required for the buffers referenced by GeneratedCommandsInfoNV ?

Reuse existing BUFFER_USAGE_INDIRECT_BUFFER_BIT

12) In which pipeline stage does the device generated command expansion happen?

cmdPreprocessGeneratedCommandsNV is treated as if it occurs in a separate logical pipeline from either graphics or compute, and that pipeline only includes PIPELINE_STAGE_TOP_OF_PIPE_BIT, a new stage PIPELINE_STAGE_COMMAND_PREPROCESS_BIT_NV, and PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT. This new stage has two corresponding new access types, ACCESS_COMMAND_PREPROCESS_READ_BIT_NV and ACCESS_COMMAND_PREPROCESS_WRITE_BIT_NV, used to synchronize reading the buffer inputs and writing the preprocess memory output.

The generated output written in the preprocess buffer memory by cmdExecuteGeneratedCommandsNV is considered to be consumed by the PIPELINE_STAGE_DRAW_INDIRECT_BIT pipeline stage.

Thus, to synchronize from writing the input buffers to preprocessing via cmdPreprocessGeneratedCommandsNV, use:

To synchronize from cmdPreprocessGeneratedCommandsNV to executing the generated commands by cmdExecuteGeneratedCommandsNV, use:

When cmdExecuteGeneratedCommandsNV is used with a isPreprocessed of FALSE, the generated commands are implicitly preprocessed, therefore one only needs to synchronize the inputs via:

13) 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 executed.

14) What are the changes compared to the previous NVX extension?

  • Compute dispatch support was removed (was never implemented in drivers). There are different approaches how dispatching from the device should work, hence we defer this to a future extension.
  • The ObjectTableNVX was replaced by using physical buffer addresses and introducing Shader Groups for the graphics pipeline.
  • Less state changes are possible overall, but the important operations are still there (reduces complexity of implementation).
  • The API was redesigned so all inputs must be passed at both preprocessing and execution time (this was implicit in NVX, now it is explicit)
  • The reservation of intermediate command space is now mandatory and explicit through a preprocess buffer.
  • The IndirectStateFlagBitsNV were introduced

15) When porting from other APIs, their indirect buffers may use different enums, for example for index buffer types. How to solve this?

Added “pIndexTypeValues” to map custom uint32_t values to corresponding IndexType.

16) Do we need more shader group state overrides?

The NVX version allowed all PSO states to be different, however as the goal is not to replace all state setup, but focus on highly-frequent state changes for drawing lots of objects, we reduced the amount of state overrides. Especially VkPipelineLayout as well as VkRenderPass configuration should be left static, the rest is still open for discussion.

The current focus is just to allow VertexInput changes as well as shaders, while all shader groups use the same shader stages.

Too much flexibility will increase the test coverage requirement as well. However, further extensions could allow more dynamic state as well.

17) Do we need more detailed physical device feature queries/enables?

An EXT version would need detailed implementor feedback to come up with a good set of features. Please contact us if you are interested, we are happy to make more features optional, or add further restrictions to reduce the minimum feature set of an EXT.

18) Is there an interaction with VK_KHR_pipeline_library planned?

Yes, a future version of this extension will detail the interaction, once VK_KHR_pipeline_library is no longer provisional.

Example Code

Open-Source samples illustrating the usage of the extension can be found at the following location (may not yet exist at time of writing):

https://github.com/nvpro-samples/vk_device_generated_cmds

Version History

  • Revision 1, 2020-02-20 (Christoph Kubisch)

    • Initial version
  • Revision 2, 2020-03-09 (Christoph Kubisch)

    • Remove VK_EXT_debug_report interactions
  • Revision 3, 2020-03-09 (Christoph Kubisch)

    • Fix naming VkPhysicalDeviceGenerated to VkPhysicalDeviceDeviceGenerated

See Also

BindIndexBufferIndirectCommandNV, BindShaderGroupIndirectCommandNV, BindVertexBufferIndirectCommandNV, GeneratedCommandsInfoNV, GeneratedCommandsMemoryRequirementsInfoNV, GraphicsPipelineShaderGroupsCreateInfoNV, GraphicsShaderGroupCreateInfoNV, IndirectCommandsLayoutCreateInfoNV, IndirectCommandsLayoutNV, IndirectCommandsLayoutTokenNV, IndirectCommandsLayoutUsageFlagBitsNV, IndirectCommandsLayoutUsageFlagsNV, IndirectCommandsStreamNV, IndirectCommandsTokenTypeNV, IndirectStateFlagBitsNV, IndirectStateFlagsNV, PhysicalDeviceDeviceGeneratedCommandsFeaturesNV, PhysicalDeviceDeviceGeneratedCommandsPropertiesNV, SetStateFlagsIndirectCommandNV, cmdBindPipelineShaderGroupNV, cmdExecuteGeneratedCommandsNV, cmdPreprocessGeneratedCommandsNV, createIndirectCommandsLayoutNV, destroyIndirectCommandsLayoutNV, getGeneratedCommandsMemoryRequirementsNV

Document Notes

For more information, see the Vulkan Specification

This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.

Synopsis

Documentation

cmdExecuteGeneratedCommandsNV Source #

Arguments

:: forall io. MonadIO io 
=> CommandBuffer

commandBuffer is the command buffer into which the command is recorded.

-> ("isPreprocessed" ::: Bool)

isPreprocessed represents whether the input data has already been preprocessed on the device. If it is FALSE this command will implicitly trigger the preprocessing step, otherwise not.

-> GeneratedCommandsInfoNV

pGeneratedCommandsInfo is a pointer to a GeneratedCommandsInfoNV structure containing parameters affecting the generation of commands.

-> io () 

vkCmdExecuteGeneratedCommandsNV - Generate and execute commands on the device

Valid Usage

Valid Usage (Implicit)

  • pGeneratedCommandsInfo must be a valid pointer to a valid GeneratedCommandsInfoNV structure
  • commandBuffer must be in the recording state
  • The CommandPool that commandBuffer was allocated from must support graphics, or compute operations
  • This command must only be called inside of a render pass instance
  • This command must only be called outside of a video coding scope

Host Synchronization

  • Host access to commandBuffer must be externally synchronized
  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer LevelsRender Pass ScopeVideo Coding ScopeSupported Queue TypesCommand Type
Primary SecondaryInside Outside Graphics ComputeAction Indirection

See Also

VK_NV_device_generated_commands, Bool32, CommandBuffer, GeneratedCommandsInfoNV

cmdPreprocessGeneratedCommandsNV Source #

Arguments

:: forall io. MonadIO io 
=> CommandBuffer

commandBuffer is the command buffer which does the preprocessing.

-> GeneratedCommandsInfoNV

pGeneratedCommandsInfo is a pointer to a GeneratedCommandsInfoNV structure containing parameters affecting the preprocessing step.

-> io () 

vkCmdPreprocessGeneratedCommandsNV - Performs preprocessing for generated commands

Valid Usage

  • commandBuffer must not be a protected command buffer

Valid Usage (Implicit)

  • pGeneratedCommandsInfo must be a valid pointer to a valid GeneratedCommandsInfoNV structure
  • commandBuffer must be in the recording state
  • The CommandPool that commandBuffer was allocated from must support graphics, or compute operations
  • This command must only be called outside of a render pass instance
  • This command must only be called outside of a video coding scope

Host Synchronization

  • Host access to commandBuffer must be externally synchronized
  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer LevelsRender Pass ScopeVideo Coding ScopeSupported Queue TypesCommand Type
Primary SecondaryOutside Outside Graphics ComputeAction

See Also

VK_NV_device_generated_commands, CommandBuffer, GeneratedCommandsInfoNV

cmdBindPipelineShaderGroupNV Source #

Arguments

:: forall io. MonadIO io 
=> CommandBuffer

commandBuffer is the command buffer that the pipeline will be bound to.

-> PipelineBindPoint

pipelineBindPoint is a PipelineBindPoint value specifying the bind point to which the pipeline will be bound.

-> Pipeline

pipeline is the pipeline to be bound.

-> ("groupIndex" ::: Word32)

groupIndex is the shader group to be bound.

-> io () 

vkCmdBindPipelineShaderGroupNV - Bind a pipeline object

Valid Usage

Valid Usage (Implicit)

  • pipelineBindPoint must be a valid PipelineBindPoint value
  • pipeline must be a valid Pipeline handle
  • commandBuffer must be in the recording state
  • The CommandPool that commandBuffer was allocated from must support graphics, or compute operations
  • This command must only be called outside of a video coding scope
  • Both of commandBuffer, and pipeline must have been created, allocated, or retrieved from the same Device

Host Synchronization

  • Host access to commandBuffer must be externally synchronized
  • Host access to the CommandPool that commandBuffer was allocated from must be externally synchronized

Command Properties

'

Command Buffer LevelsRender Pass ScopeVideo Coding ScopeSupported Queue TypesCommand Type
Primary SecondaryBoth Outside Graphics ComputeState

See Also

VK_NV_device_generated_commands, CommandBuffer, Pipeline, PipelineBindPoint

getGeneratedCommandsMemoryRequirementsNV Source #

Arguments

:: forall a io. (Extendss MemoryRequirements2 a, PokeChain a, PeekChain a, MonadIO io) 
=> Device

device is the logical device that owns the buffer.

-> GeneratedCommandsMemoryRequirementsInfoNV

pInfo is a pointer to a GeneratedCommandsMemoryRequirementsInfoNV structure containing parameters required for the memory requirements query.

-> io (MemoryRequirements2 a) 

vkGetGeneratedCommandsMemoryRequirementsNV - Retrieve the buffer allocation requirements for generated commands

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

See Also

VK_NV_device_generated_commands, Device, GeneratedCommandsMemoryRequirementsInfoNV, MemoryRequirements2

createIndirectCommandsLayoutNV Source #

Arguments

:: forall io. MonadIO io 
=> Device

device is the logical device that creates the indirect command layout.

-> IndirectCommandsLayoutCreateInfoNV

pCreateInfo is a pointer to a IndirectCommandsLayoutCreateInfoNV structure containing parameters affecting creation of the indirect command layout.

-> ("allocator" ::: Maybe AllocationCallbacks)

pAllocator controls host memory allocation as described in the Memory Allocation chapter.

-> io IndirectCommandsLayoutNV 

vkCreateIndirectCommandsLayoutNV - Create an indirect command layout object

Valid Usage

Valid Usage (Implicit)

  • device must be a valid Device handle

Return Codes

Success
Failure

See Also

VK_NV_device_generated_commands, AllocationCallbacks, Device, IndirectCommandsLayoutCreateInfoNV, IndirectCommandsLayoutNV

withIndirectCommandsLayoutNV :: forall io r. MonadIO io => Device -> IndirectCommandsLayoutCreateInfoNV -> Maybe AllocationCallbacks -> (io IndirectCommandsLayoutNV -> (IndirectCommandsLayoutNV -> io ()) -> r) -> r Source #

A convenience wrapper to make a compatible pair of calls to createIndirectCommandsLayoutNV and destroyIndirectCommandsLayoutNV

To ensure that destroyIndirectCommandsLayoutNV is always called: pass bracket (or the allocate function from your favourite resource management library) as the last argument. To just extract the pair pass (,) as the last argument.

destroyIndirectCommandsLayoutNV Source #

Arguments

:: forall io. MonadIO io 
=> Device

device is the logical device that destroys the layout.

-> IndirectCommandsLayoutNV

indirectCommandsLayout is the layout to destroy.

-> ("allocator" ::: Maybe AllocationCallbacks)

pAllocator controls host memory allocation as described in the Memory Allocation chapter.

-> io () 

vkDestroyIndirectCommandsLayoutNV - Destroy an indirect commands layout

Valid Usage

  • All submitted commands that refer to indirectCommandsLayout must have completed execution

Valid Usage (Implicit)

  • device must be a valid Device handle
  • If indirectCommandsLayout is not NULL_HANDLE, indirectCommandsLayout must be a valid IndirectCommandsLayoutNV handle
  • If pAllocator is not NULL, pAllocator must be a valid pointer to a valid AllocationCallbacks structure
  • If indirectCommandsLayout is a valid handle, it must have been created, allocated, or retrieved from device

Host Synchronization

  • Host access to indirectCommandsLayout must be externally synchronized

See Also

VK_NV_device_generated_commands, AllocationCallbacks, Device, IndirectCommandsLayoutNV

data PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source #

VkPhysicalDeviceDeviceGeneratedCommandsFeaturesNV - Structure describing the device-generated commands features that can be supported by an implementation

Members

This structure describes the following feature:

Description

If the PhysicalDeviceDeviceGeneratedCommandsFeaturesNV structure is included in the pNext chain of the PhysicalDeviceFeatures2 structure passed to getPhysicalDeviceFeatures2, it is filled in to indicate whether each corresponding feature is supported. PhysicalDeviceDeviceGeneratedCommandsFeaturesNV can also be used in the pNext chain of DeviceCreateInfo to selectively enable these features.

Valid Usage (Implicit)

See Also

VK_NV_device_generated_commands, Bool32, StructureType

Constructors

PhysicalDeviceDeviceGeneratedCommandsFeaturesNV 

Fields

Instances

Instances details
Storable PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero PhysicalDeviceDeviceGeneratedCommandsFeaturesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source #

VkPhysicalDeviceDeviceGeneratedCommandsPropertiesNV - Structure describing push descriptor limits that can be supported by an implementation

Description

If the PhysicalDeviceDeviceGeneratedCommandsPropertiesNV structure is included in the pNext chain of the PhysicalDeviceProperties2 structure passed to getPhysicalDeviceProperties2, it is filled in with each corresponding implementation-dependent property.

Valid Usage (Implicit)

See Also

VK_NV_device_generated_commands, StructureType

Constructors

PhysicalDeviceDeviceGeneratedCommandsPropertiesNV 

Fields

Instances

Instances details
Storable PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero PhysicalDeviceDeviceGeneratedCommandsPropertiesNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data GraphicsShaderGroupCreateInfoNV Source #

VkGraphicsShaderGroupCreateInfoNV - Structure specifying override parameters for each shader group

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL
  • pStages must be a valid pointer to an array of stageCount valid PipelineShaderStageCreateInfo structures
  • stageCount must be greater than 0

See Also

VK_NV_device_generated_commands, GraphicsPipelineShaderGroupsCreateInfoNV, PipelineShaderStageCreateInfo, PipelineTessellationStateCreateInfo, PipelineVertexInputStateCreateInfo, StructureType

Constructors

GraphicsShaderGroupCreateInfoNV 

Fields

data GraphicsPipelineShaderGroupsCreateInfoNV Source #

VkGraphicsPipelineShaderGroupsCreateInfoNV - Structure specifying parameters of a newly created multi shader group pipeline

Description

When referencing shader groups by index, groups defined in the referenced pipelines are treated as if they were defined as additional entries in pGroups. They are appended in the order they appear in the pPipelines array and in the pGroups array when those pipelines were defined.

The application must maintain the lifetime of all such referenced pipelines based on the pipelines that make use of them.

Valid Usage

  • The sum of groupCount including those groups added from referenced pPipelines must also be as maximum PhysicalDeviceDeviceGeneratedCommandsPropertiesNV::maxGraphicsShaderGroupCount
  • The state of the first element of pGroups must match its equivalent within the parent’s GraphicsPipelineCreateInfo
  • Each element of pGroups must in combination with the rest of the pipeline state yield a valid state configuration
  • All elements of pGroups must use the same shader stage combinations unless any mesh shader stage is used, then either combination of task and mesh or just mesh shader is valid
  • Mesh and regular primitive shading stages cannot be mixed across pGroups
  • Each element of pPipelines must have been created with identical state to the pipeline currently created except the state that can be overridden by GraphicsShaderGroupCreateInfoNV
  • The deviceGeneratedCommands feature must be enabled

Valid Usage (Implicit)

  • If groupCount is not 0, pGroups must be a valid pointer to an array of groupCount valid GraphicsShaderGroupCreateInfoNV structures
  • If pipelineCount is not 0, pPipelines must be a valid pointer to an array of pipelineCount valid Pipeline handles

See Also

VK_NV_device_generated_commands, GraphicsShaderGroupCreateInfoNV, Pipeline, StructureType

Constructors

GraphicsPipelineShaderGroupsCreateInfoNV 

Fields

data BindShaderGroupIndirectCommandNV Source #

VkBindShaderGroupIndirectCommandNV - Structure specifying input data for a single shader group command token

Valid Usage

  • The index must be within range of the accessible shader groups of the current bound graphics pipeline. See cmdBindPipelineShaderGroupNV for further details

See Also

VK_NV_device_generated_commands

Instances

Instances details
Storable BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero BindShaderGroupIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data BindIndexBufferIndirectCommandNV Source #

VkBindIndexBufferIndirectCommandNV - Structure specifying input data for a single index buffer command token

Valid Usage

  • The bufferAddress must be aligned to the indexType used
  • Each element of the buffer from which the address was acquired and that is non-sparse must be bound completely and contiguously to a single DeviceMemory object

Valid Usage (Implicit)

See Also

VK_NV_device_generated_commands, DeviceAddress, IndexType

Constructors

BindIndexBufferIndirectCommandNV 

Fields

Instances

Instances details
Storable BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero BindIndexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data BindVertexBufferIndirectCommandNV Source #

VkBindVertexBufferIndirectCommandNV - Structure specifying input data for a single vertex buffer command token

Valid Usage

  • Each element of the buffer from which the address was acquired and that is non-sparse must be bound completely and contiguously to a single DeviceMemory object

See Also

VK_NV_device_generated_commands, DeviceAddress

Constructors

BindVertexBufferIndirectCommandNV 

Fields

Instances

Instances details
Storable BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero BindVertexBufferIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data SetStateFlagsIndirectCommandNV Source #

VkSetStateFlagsIndirectCommandNV - Structure specifying input data for a single state flag command token

See Also

VK_NV_device_generated_commands

Constructors

SetStateFlagsIndirectCommandNV 

Fields

Instances

Instances details
Storable SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero SetStateFlagsIndirectCommandNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data IndirectCommandsStreamNV Source #

VkIndirectCommandsStreamNV - Structure specifying input streams for generated command tokens

Valid Usage

Valid Usage (Implicit)

  • buffer must be a valid Buffer handle

See Also

VK_NV_device_generated_commands, Buffer, DeviceSize, GeneratedCommandsInfoNV

Constructors

IndirectCommandsStreamNV 

Fields

  • buffer :: Buffer

    buffer specifies the Buffer storing the functional arguments for each sequence. These arguments can be written by the device.

  • offset :: DeviceSize

    offset specified an offset into buffer where the arguments start.

Instances

Instances details
Storable IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero IndirectCommandsStreamNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

data IndirectCommandsLayoutTokenNV Source #

VkIndirectCommandsLayoutTokenNV - Struct specifying the details of an indirect command layout token

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL
  • tokenType must be a valid IndirectCommandsTokenTypeNV value
  • If pushconstantPipelineLayout is not NULL_HANDLE, pushconstantPipelineLayout must be a valid PipelineLayout handle
  • pushconstantShaderStageFlags must be a valid combination of ShaderStageFlagBits values
  • indirectStateFlags must be a valid combination of IndirectStateFlagBitsNV values
  • If indexTypeCount is not 0, pIndexTypes must be a valid pointer to an array of indexTypeCount valid IndexType values
  • If indexTypeCount is not 0, pIndexTypeValues must be a valid pointer to an array of indexTypeCount uint32_t values

See Also

VK_NV_device_generated_commands, Bool32, IndexType, IndirectCommandsLayoutCreateInfoNV, IndirectCommandsTokenTypeNV, IndirectStateFlagsNV, PipelineLayout, ShaderStageFlags, StructureType

Constructors

IndirectCommandsLayoutTokenNV 

Fields

data IndirectCommandsLayoutCreateInfoNV Source #

VkIndirectCommandsLayoutCreateInfoNV - Structure specifying the parameters of a newly created indirect commands layout object

Description

The following code illustrates some of the flags:

void cmdProcessAllSequences(cmd, pipeline, indirectCommandsLayout, pIndirectCommandsTokens, sequencesCount, indexbuffer, indexbufferOffset)
{
  for (s = 0; s < sequencesCount; s++)
  {
    sUsed = s;

    if (indirectCommandsLayout.flags & VK_INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NV) {
      sUsed = indexbuffer.load_uint32( sUsed * sizeof(uint32_t) + indexbufferOffset);
    }

    if (indirectCommandsLayout.flags & VK_INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NV) {
      sUsed = incoherent_implementation_dependent_permutation[ sUsed ];
    }

    cmdProcessSequence( cmd, pipeline, indirectCommandsLayout, pIndirectCommandsTokens, sUsed );
  }
}

When tokens are consumed, an offset is computed based on token offset and stream stride. The resulting offset is required to be aligned. The alignment for a specific token is equal to the scalar alignment of the data type as defined in Alignment Requirements, or PhysicalDeviceDeviceGeneratedCommandsPropertiesNV::minIndirectCommandsBufferOffsetAlignment, whichever is lower.

Note

A minIndirectCommandsBufferOffsetAlignment of 4 allows DeviceAddress to be packed as uvec2 with scalar layout instead of uint64_t with 8 byte alignment. This enables direct compatibility with D3D12 command signature layouts.

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL
  • flags must be a valid combination of IndirectCommandsLayoutUsageFlagBitsNV values
  • pipelineBindPoint must be a valid PipelineBindPoint value
  • pTokens must be a valid pointer to an array of tokenCount valid IndirectCommandsLayoutTokenNV structures
  • pStreamStrides must be a valid pointer to an array of streamCount uint32_t values
  • tokenCount must be greater than 0
  • streamCount must be greater than 0

See Also

VK_NV_device_generated_commands, IndirectCommandsLayoutTokenNV, IndirectCommandsLayoutUsageFlagsNV, PipelineBindPoint, StructureType, createIndirectCommandsLayoutNV

Constructors

IndirectCommandsLayoutCreateInfoNV 

Fields

data GeneratedCommandsInfoNV Source #

VkGeneratedCommandsInfoNV - Structure specifying parameters for the generation of commands

Valid Usage

  • The provided pipeline must match the pipeline bound at execution time

Valid Usage (Implicit)

  • pNext must be NULL
  • pipelineBindPoint must be a valid PipelineBindPoint value
  • pipeline must be a valid Pipeline handle
  • indirectCommandsLayout must be a valid IndirectCommandsLayoutNV handle
  • pStreams must be a valid pointer to an array of streamCount valid IndirectCommandsStreamNV structures
  • preprocessBuffer must be a valid Buffer handle
  • If sequencesCountBuffer is not NULL_HANDLE, sequencesCountBuffer must be a valid Buffer handle
  • If sequencesIndexBuffer is not NULL_HANDLE, sequencesIndexBuffer must be a valid Buffer handle
  • streamCount must be greater than 0
  • Each of indirectCommandsLayout, pipeline, preprocessBuffer, sequencesCountBuffer, and sequencesIndexBuffer that are valid handles of non-ignored parameters must have been created, allocated, or retrieved from the same Device

See Also

VK_NV_device_generated_commands, Buffer, DeviceSize, IndirectCommandsLayoutNV, IndirectCommandsStreamNV, Pipeline, PipelineBindPoint, StructureType, cmdExecuteGeneratedCommandsNV, cmdPreprocessGeneratedCommandsNV

Constructors

GeneratedCommandsInfoNV 

Fields

data GeneratedCommandsMemoryRequirementsInfoNV Source #

VkGeneratedCommandsMemoryRequirementsInfoNV - Structure specifying parameters for the reservation of preprocess buffer space

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL
  • pipelineBindPoint must be a valid PipelineBindPoint value
  • pipeline must be a valid Pipeline handle
  • indirectCommandsLayout must be a valid IndirectCommandsLayoutNV handle
  • Both of indirectCommandsLayout, and pipeline must have been created, allocated, or retrieved from the same Device

See Also

VK_NV_device_generated_commands, IndirectCommandsLayoutNV, Pipeline, PipelineBindPoint, StructureType, getGeneratedCommandsMemoryRequirementsNV

Constructors

GeneratedCommandsMemoryRequirementsInfoNV 

Fields

Instances

Instances details
Storable GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FromCStruct GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

ToCStruct GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero GeneratedCommandsMemoryRequirementsInfoNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

newtype IndirectCommandsLayoutUsageFlagBitsNV Source #

VkIndirectCommandsLayoutUsageFlagBitsNV - Bitmask specifying allowed usage of an indirect commands layout

See Also

VK_NV_device_generated_commands, IndirectCommandsLayoutUsageFlagsNV

Bundled Patterns

pattern INDIRECT_COMMANDS_LAYOUT_USAGE_EXPLICIT_PREPROCESS_BIT_NV :: IndirectCommandsLayoutUsageFlagBitsNV

INDIRECT_COMMANDS_LAYOUT_USAGE_EXPLICIT_PREPROCESS_BIT_NV specifies that the layout is always used with the manual preprocessing step through calling cmdPreprocessGeneratedCommandsNV and executed by cmdExecuteGeneratedCommandsNV with isPreprocessed set to TRUE.

pattern INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NV :: IndirectCommandsLayoutUsageFlagBitsNV

INDIRECT_COMMANDS_LAYOUT_USAGE_INDEXED_SEQUENCES_BIT_NV specifies that the input data for the sequences is not implicitly indexed from 0..sequencesUsed but a user provided Buffer encoding the index is provided.

pattern INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NV :: IndirectCommandsLayoutUsageFlagBitsNV

INDIRECT_COMMANDS_LAYOUT_USAGE_UNORDERED_SEQUENCES_BIT_NV specifies that the processing of sequences can happen at an implementation-dependent order, which is not: guaranteed to be coherent using the same input data.

Instances

Instances details
Storable IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Bits IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Methods

(.&.) :: IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV #

(.|.) :: IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV #

xor :: IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV #

complement :: IndirectCommandsLayoutUsageFlagBitsNV -> IndirectCommandsLayoutUsageFlagBitsNV #

shift :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

rotate :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

zeroBits :: IndirectCommandsLayoutUsageFlagBitsNV #

bit :: Int -> IndirectCommandsLayoutUsageFlagBitsNV #

setBit :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

clearBit :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

complementBit :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

testBit :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> Bool #

bitSizeMaybe :: IndirectCommandsLayoutUsageFlagBitsNV -> Maybe Int #

bitSize :: IndirectCommandsLayoutUsageFlagBitsNV -> Int #

isSigned :: IndirectCommandsLayoutUsageFlagBitsNV -> Bool #

shiftL :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

unsafeShiftL :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

shiftR :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

unsafeShiftR :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

rotateL :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

rotateR :: IndirectCommandsLayoutUsageFlagBitsNV -> Int -> IndirectCommandsLayoutUsageFlagBitsNV #

popCount :: IndirectCommandsLayoutUsageFlagBitsNV -> Int #

FiniteBits IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Read IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Ord IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero IndirectCommandsLayoutUsageFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

newtype IndirectStateFlagBitsNV Source #

VkIndirectStateFlagBitsNV - Bitmask specifying state that can be altered on the device

See Also

VK_NV_device_generated_commands, IndirectStateFlagsNV

Bundled Patterns

pattern INDIRECT_STATE_FLAG_FRONTFACE_BIT_NV :: IndirectStateFlagBitsNV

INDIRECT_STATE_FLAG_FRONTFACE_BIT_NV allows to toggle the FrontFace rasterization state for subsequent draw operations.

Instances

Instances details
Storable IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Bits IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

FiniteBits IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Read IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Ord IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero IndirectStateFlagBitsNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

newtype IndirectCommandsTokenTypeNV Source #

Instances

Instances details
Storable IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Read IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Show IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Eq IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Ord IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

Zero IndirectCommandsTokenTypeNV Source # 
Instance details

Defined in Vulkan.Extensions.VK_NV_device_generated_commands

type NV_DEVICE_GENERATED_COMMANDS_EXTENSION_NAME = "VK_NV_device_generated_commands" Source #

newtype IndirectCommandsLayoutNV Source #

Instances

Instances details
Storable IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

Show IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

Eq IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

Ord IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

HasObjectType IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

IsHandle IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles

Zero IndirectCommandsLayoutNV Source # 
Instance details

Defined in Vulkan.Extensions.Handles