mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-18 17:28:16 +00:00
* Bump API patch number and header version number to 29 for this update. Github Issues: * Remove redundant constraint on slink:VkCommandBufferInheritanceInfo::pname:queryFlags (public issue 224). * Fix typo and remove link in Note in the <<extended-functionality-instance-extensions-and-devices, Instance Extensions and Device Extensions>> section (public issue 359). * Fix erroneous validation statement for the pname:layout member of slink:VkComputePipelineCreateInfo (public issue 362). Internal Issues: * Restore long figure captions using asciidoc sidebar blocks, due to restrictions of asciidoc syntax (internal issue 101). * Replace most latexmath equations with comparable markup in straight asciidoc, which significantly improves time required to fully load and process the HTML forms of the Specification. There are known minor font and alignment inconsistencies with MathJax and PDF rendering of latexmath equations. Please do not file github issues about these. We are aware of the inconsistencies and will make refinements over time, while the performance improvements are compelling in at least some major browsers (internal issue 313). * Move handcoded validity statements from +vk.xml+ into the Specification body, easing work in the single-branch model. Specify the distinction between these explicit statements, and the implicit validity statements inferred from vk.xml. Validity statements now appear in two blocks for each command and structure - handcoded "Valid Usage" and the implicit "Valid Usage (Implicit)" (internal issue 392). * Add the +returnedonly="false"+ attribute to WSI output structures, removing incorrectly generated implicit validity statements for slink:VkDisplayPropertiesKHR, slink:VkDisplayPlanePropertiesKHR, slink:VkDisplayModePropertiesKHR, slink:VkDisplayPlaneCapabilitiesKHR, slink:VkSurfaceCapabilitiesKHR, and slink:VkSurfaceFormatKHR structures (internal issue 486). * Update slink:VkImageLayout to require the ename:VK_IMAGE_USAGE_SAMPLED_BIT be set for sampled depth/stencil images (internal issue 487). * Use an explicit format specifier string for the date command invocation in the +Makefile+ instead of the shorthand -R option, which doesn't work on BSD and MaxOS X date commands (internal issue 500). Other Issues: * Use the terms ``allocation scope'' and ``extension scope'' instead of just ``scope'', and add them to the glossary.
163 lines
7.0 KiB
Plaintext
163 lines
7.0 KiB
Plaintext
// Copyright (c) 2015-2016 The Khronos Group Inc.
|
|
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
|
|
|
|
[[geometry]]
|
|
= Geometry Shading
|
|
|
|
The geometry shader operates on a group of vertices and their associated
|
|
data assembled from a single input primitive, and emits zero or more output
|
|
primitives and the group of vertices and their associated data required for
|
|
each output primitive.
|
|
Geometry shading is enabled when a geometry shader is included in the
|
|
pipeline.
|
|
|
|
|
|
[[geometry-input]]
|
|
== Geometry Shader Input Primitives
|
|
|
|
Each geometry shader invocation has access to all vertices in the primitive
|
|
(and their associated data), which are presented to the shader as an array
|
|
of inputs.
|
|
The input primitive type expected by the geometry shader is specified with
|
|
an code:OpExecutionMode instruction in the geometry shader, and must: be
|
|
compatible with the primitive topology used by primitive assembly (if
|
|
tessellation is not in use) or must: match the type of primitive generated
|
|
by the tessellation primitive generator (if tessellation is in use).
|
|
Compatibility is defined below, with each input primitive type.
|
|
The input primitive types accepted by a geometry shader are:
|
|
|
|
Points::
|
|
|
|
Geometry shaders that operate on points use an code:OpExecutionMode
|
|
instruction specifying the code:InputPoints input mode.
|
|
Such a shader is valid only when the pipeline primitive topology is
|
|
code:VK_PRIMITIVE_TOPOLOGY_POINT_LIST (if tessellation is not in use) or if
|
|
tessellation is in use and the tessellation evaluation shader uses
|
|
code:PointMode.
|
|
There is only a single input vertex available for each geometry shader
|
|
invocation.
|
|
However, inputs to the geometry shader are still presented as an array, but
|
|
this array has a length of one.
|
|
|
|
Lines::
|
|
|
|
Geometry shaders that operate on line segments are generated by including an
|
|
code:OpExecutionMode instruction with the code:InputLines mode.
|
|
Such a shader is valid only for the code:VK_PRIMITIVE_TOPOLOGY_LINE_LIST,
|
|
and code:VK_PRIMITIVE_TOPOLOGY_LINE_STRIP primitive topologies (if
|
|
tessellation is not in use) or if tessellation is in use and the
|
|
tessellation mode is code:Isolines.
|
|
There are two input vertices available for each geometry shader invocation.
|
|
The first vertex refers to the vertex at the beginning of the line segment
|
|
and the second vertex refers to the vertex at the end of the line segment.
|
|
|
|
Lines with Adjacency::
|
|
|
|
Geometry shaders that operate on line segments with adjacent vertices are
|
|
generated by including an code:OpExecutionMode instruction with the
|
|
code:InputLinesAdjacency mode.
|
|
Such a shader is valid only for the
|
|
code:VK_PRIMITIVE_TOPOLOGY_LINES_WITH_ADJACENCY and
|
|
code:VK_PRIMITIVE_TOPOLOGY_LINE_STRIP_WITH_ADJACENCY primitive topologies
|
|
and must: not be used when tessellation is in use.
|
|
+
|
|
In this mode, there are four vertices available for each geometry shader
|
|
invocation.
|
|
The second vertex refers to attributes of the vertex at the beginning of the
|
|
line segment and the third vertex refers to the vertex at the end of the
|
|
line segment.
|
|
The first and fourth vertices refer to the vertices adjacent to the
|
|
beginning and end of the line segment, respectively.
|
|
|
|
Triangles::
|
|
|
|
Geometry shaders that operate on triangles are created by including an
|
|
code:OpExecutionMode instruction with the code:Triangles mode.
|
|
Such a shader is valid when the pipeline topology is
|
|
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST,
|
|
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP, or
|
|
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLE_FAN (if tessellation is not in use) or
|
|
when tessellation is in use and the tessellation mode is code:Triangles or
|
|
code:Quads.
|
|
+
|
|
In this mode, there are three vertices available for each geometry shader
|
|
invocation.
|
|
The first, second, and third vertices refer to attributes of the first,
|
|
second, and third vertex of the triangle, respectively.
|
|
|
|
Triangles with Adjacency::
|
|
|
|
Geometry shaders that operate on triangles with adjacent vertices are
|
|
created by including an code:OpExecutionMode instruction with the
|
|
code:InputTrianglesAdjacency mode.
|
|
Such a shader is valid when the pipeline topology is
|
|
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLES_WITH_ADJACENCY or
|
|
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY, and must: not be
|
|
used when tessellation is in use.
|
|
+
|
|
In this mode, there are six vertices available for each geometry shader
|
|
invocation.
|
|
The first, third and fifth vertices refer to attributes of the first, second
|
|
and third vertex of the triangle, respectively.
|
|
The second, fourth and sixth vertices refer to attributes of the vertices
|
|
adjacent to the edges from the first to the second vertex, from the second
|
|
to the third vertex, and from the third to the first vertex, respectively.
|
|
|
|
|
|
[[geometry-output]]
|
|
== Geometry Shader Output Primitives
|
|
|
|
A geometry shader generates primitives in one of three output modes: points,
|
|
line strips, or triangle strips.
|
|
The primitive mode is specified in the shader using an code:OpExecutionMode
|
|
instruction with the code:OutputPoints, code:OutputLineStrip or
|
|
code:OutputTriangleStrip modes, respectively.
|
|
Each geometry shader must: include exactly one output primitive mode.
|
|
|
|
The vertices output by the geometry shader are assembled into points, lines,
|
|
or triangles based on the output primitive type and the resulting primitives
|
|
are then further processed as described in <<primsrast>>.
|
|
If the number of vertices emitted by the geometry shader is not sufficient
|
|
to produce a single primitive, vertices corresponding to incomplete
|
|
primitives are not processed by subsequent pipeline stages.
|
|
The number of vertices output by the geometry shader is limited to a maximum
|
|
count specified in the shader.
|
|
|
|
The maximum output vertex count is specified in the shader using an
|
|
code:OpExecutionMode instruction with the mode set to code:OutputVertices
|
|
and the maximum number of vertices that will be produced by the geometry
|
|
shader specified as a literal.
|
|
Each geometry shader must: specify a maximum output vertex count.
|
|
|
|
|
|
[[geometry-invocations]]
|
|
== Multiple Invocations of Geometry Shaders
|
|
|
|
Geometry shaders can: be invoked more than one time for each input
|
|
primitive.
|
|
This is known as _geometry shader instancing_ and is requested by including
|
|
an code:OpExecutionMode instruction with code:mode specified as
|
|
code:Invocations and the number of invocations specified as an integer
|
|
literal.
|
|
|
|
In this mode, the geometry shader will execute [eq]#n# times for each input
|
|
primitive, where [eq]#n# is the number of invocations specified in the
|
|
code:OpExecutionMode instruction.
|
|
The instance number is available to each invocation as a built-in input
|
|
using code:InvocationId.
|
|
|
|
|
|
[[geometry-ordering]]
|
|
== Geometry Shader Primitive Ordering
|
|
|
|
Limited guarantees are provided for the relative ordering of primitives
|
|
produced by a geometry shader.
|
|
|
|
* For instanced geometry shaders, the output primitives generated from
|
|
each input primitive are passed to subsequent pipeline stages using the
|
|
invocation number to order the primitives, from least to greatest.
|
|
* All output primitives generated from a given input primitive are passed
|
|
to subsequent pipeline stages before any output primitives generated
|
|
from subsequent input primitives.
|
|
|