VK_EXT_mesh_shader

Mesh shaders are a new compute-like shader stage that has a primary aim of generating a set of primitives to the rasterizer, which are passed via its new output interface. For the most part, these map well to compute shaders - they are dispatched in workgroups and have access to shared memory, workgroup barriers, and local IDs, allowing for a lot of flexibility in how they are executed.

Unlike vertex shaders, they do not use the vertex input interface, and geometry and indices must be generated by the shader or read from buffers with no requirement for applications to provide the data in a particular way. As such, this allows applications to read or generate data however they need to, removing the need to prepare data before launching the graphics pipeline. This allows items such as decompression or decryption of data to be performed within the graphics pipeline directly, avoiding the bandwidth cost typically associated with compute shaders.

Another key part of mesh shaders is that the number of primitives that a given workgroup can emit is dynamic - there are limits to how much can be emitted, which is advertised by the implementation, but applications can freely emit fewer primitives than the maximum. This allows things like modifying the level of detail at a fine granularity without the use of tessellation. Vertex outputs are written via the Output storage class and using standard built-ins like Position and PointSize, but are written as arrays in the same way as a tessellation control shader’s outputs. Additionally, the mesh shader outputs indices per primitive according to the output primitive type (points, lines, or triangles). Indices are emitted as a separate array in a similar fashion to vertex outputs. Mesh shader output topologies are lists only - there is no support for triangle or line strips or triangle fans; data in these formats must be unpacked by the shader. Other user data can be emitted at per-vertex or per-primitive rates alongside these built-ins. Mesh shaders must specify the actual number of primitives and vertices being emitted before writing them, via the OpSetMeshOutputsEXT instruction. Subsequent fragment shaders can retrieve input data at both rates, tied to the vertices and primitive being rasterized.

Mesh shaders can be dispatched from the API like a compute shader would be, or launched via Task Shaders.

Task shaders are an optional shader stage that executes ahead of mesh shaders. A task shader is dispatched like a compute shader, and indirectly dispatches mesh shader workgroups. This shader is another compute-like stage that is executed in workgroups and has all the other features of compute shaders as well, with the addition of access to a dedicated instruction to launch mesh shaders.

The primary function of task shaders is to dispatch mesh shaders via OpEmitMeshTasksEXT, which takes as input a number of mesh shader groups to emit, and a payload variable that will be visible to all mesh shader invocations launched by this instruction. This instruction is executed once per workgroup rather than per-invocation, and the payload itself is in a workgroup-wide storage class, similar to shared memory. Once this instruction is called, the workgroup is terminated immediately, and the mesh shaders are launched.

Task shaders can be used for functionality like coarse culling of entire meshlets or dynamically generating more or less geometry depending on the level of detail required. This is notionally similar to the purpose of tessellation shaders, but without the constraint of fixed functionality, and with greater flexibility in how primitives are executed. Applications can use task shaders to determine the number of launched mesh shader workgroups at whatever input granularity they want, and however they see fit.

As task and mesh shaders change how primitives are dispatched, a subsequent modification of rasterization order is made. Within a mesh shader workgroup, primitives are rasterized in the order in which they are defined in the output. A group of mesh shaders either launched directly by the API, indirectly by the API, or indirectly from a single task shader workgroup will rasterize their outputs in sequential order based on their flattened global invocation index, equal to , where x, y, and z refer to the components of the GlobalInvocationId built-in. width and height are equal to NumWorkgroups times WorkgroupSize for their respective dimensions. When using task shaders, there is no rasterization order guarantee between mesh shaders launched by separate task shader workgroups, even within the same draw command.

Graphics pipelines can now be created using mesh and task shaders in place of vertex, tessellation, and geometry shaders. This can be achieved by omitting existing pre-rasterization shaders and including a mesh shader stage, and optionally a task shader stage. When present, a graphics pipeline is complete without the inclusion of the vertex input state subset, as this state does not participate in mesh pipelines. No other modifications to graphics pipelines are necessary. Two new shader stages are added to the API to describe the new shader stages:

Note that VK_SHADER_STAGE_ALL_GRAPHICS_BIT was defined as a mask of existing bits during Vulkan 1.0 development, and thus cannot include these new bits; modifying it would break compatibility.

New pipeline stages are added for synchronization of these new stages:

These new pipeline stages interact similarly to compute shaders, with all the same access types and operations. They are also logically ordered before fragment shading, but have no logical ordering compared to existing pre-rasterization shader stages. The VK_PIPELINE_STAGE_2_PRE_RASTERIZATION_SHADERS_BIT stage added by VK_KHR_synchronization2 includes these new shader stages, and can be used identically.

Pipeline statistics queries are updated with new bits to count mesh and task shader invocations, in a similar manner to how other shader invocations are counted:

An additional standalone query counting the number of mesh primitives generated is added:

An active query of this type will generate a count of every individual primitive emitted from any mesh shader workgroup that is not culled by fixed function culling.

Three new draw calls are added to the API to dispatch mesh pipelines:

vkCmdDrawMeshTasksEXT is the simplest as it functions the same as vkCmdDispatch, but dispatches the mesh or task shader in a graphics pipeline with the specified workgroup counts, rather than a compute shader.

vkCmdDrawMeshTasksIndirectEXT functions similarly to vkCmdDispatchIndirect, but with the draw count functionality from other draw commands. Multiple draws are dispatched according to the drawCount parameter, with data in buffer being consumed as a strided array of VkDrawMeshTasksIndirectCommandEXT structures, with stride equal to stride. Each element of this array defines a separate draw call’s workgroup counts in each dimension, and dispatches mesh or task shaders for the current pipeline accordingly.

vkCmdDrawMeshTasksIndirectCountEXT functions as vkCmdDrawMeshTasksIndirectEXT, but takes its draw count from the device as well. The draw count is read from countBuffer at an offset of countBufferOffset, and must be lower than maxDrawCount.

Several new properties are added to the API - some dictating hard limits, and others indicating performance considerations:

The following limits affect task shader execution:

Similar limits affect task shader execution:

When considering the above properties, the number of mesh shader outputs a shader uses are rounded up to implementation-defined numbers defined by the following properties:

The following properties are implementation preferences. Violating these limits will not result in validation errors, but it is strongly recommended that applications adhere to them in order to maximize performance on each implementation.

Note that even if some of the above values are false, the implementation can still perform just as well whether or not the corresponding preferences are followed. It is recommended to follow these preferences unless the performance cost of doing so outweighs the gains of hitting the optimal paths in the implementation.

A few new features are introduced by this extension: