Vulkan-Docs/doc/specs/vulkan/chapters/geometry.txt

150 lines
7.0 KiB
Plaintext
Raw Normal View History

2016-02-16 09:53:44 +00:00
// 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
Change log for September 6, 2016 Vulkan 1.0.26 spec update: * Bump API patch number and header version number to 26 for this update. Github Issues: * Bring sample code in the +VK_KHR_surface+ and +VK_KHR_swapchain+ extension summary appendices up to date, and note they will be replaced with pointers to the LunarG SDK examples in the future (public issue 279). * Add a new <<fundamentals-commandsyntax-results-lifetime,Lifetime of Retrieved Results>> section specifying that ftext:vkGet* and ftext:VkEnumerate* results are invariant unless otherwise specified, and specify behavior for individual commands which are not invariant (public issue 280). * Remove conflicting definition of slink:VkDisplayPlaneCapabilitiesKHR::pname:maxSrcPosition and clean up language of the remaining definition (public issue 351). * Fix many minor spelling errors and add rules to the style guide to prevent recurrences (public issue 352). Internal Issues: * Remove redundant descriptions of the etext:VK_USE_PLATFORM_* macros from the <<wsi,Window System Integration>> chapter in favor of the description in the <<boilerplate-wsi-header,Window System-Specific Header Control>> appendix (internal issue 6). * Replace misleading 'can: be destroyed when not X' with more correct 'must: not be destroyed while X' in the <<fundamentals-objectmodel-lifetime,Object Lifetime>> section. Disallow destroying a pipeline layout while a command buffer using it is recording (internal issue 241). * Clarify that ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT is valid for all images used as attachments in elink:VkImageUsageFlagBits and the slink:VkImageLayout validity language (internal issue 320). * Note that <<extended-functionality-layers,Layers>> may wrap object handles, but that this is a generally discouraged. A link to additional information in the documentation for layer authors is provided (issue 398) * Replace the mustnot: and shouldnot: macros with equivalent must: not and should: not to get rid of non-English words while still highlighting normative language (internal issue 407). * Disallow creating multisampled images with ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT in the slink:VkImageLayout validity language and the <<features-supported-sample-counts,Supported Sample Counts>> section (internal issue 445). * Fix typo so that flink:vkCmdDrawIndexedIndirect is defined in terms of flink:vkCmdDrawIndexed rather than flink:vkCmdDrawIndirect (internal issue 446). * Reorganize the per-extension information sections to all be in the <<extensions,Layers & Extensions>> appendix. Also fix a typo in +VK_IMG_filter_cubic+ which incorrectly identified it as a +KHR+ extension (internal issue 461). Other Issues: * Use asciidoc markup instead of latexmath to simplify diagrams in the <<features-formats-non-packed,byte mapping tables>> for color formats. * Fix a markup problem with the wildcarded enumerant names in a NOTE in the <<textures-texel-replacement,Texel Replacement>> section. * Fix missing attributes in the XML interface for elink:VkExternalMemoryHandleTypeFlagBitsNV and elink:VkExternalMemoryFeatureFlagBitsNV (KhronosGroup/Vulkan-Hpp issue #25) * Cleanup reference page builds so only core pages are built for releases.
2016-09-06 13:17:27 +00:00
instruction specifying the code:InputPoints input mode. Such a shader is
2016-02-16 09:53:44 +00:00
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
Change log for September 6, 2016 Vulkan 1.0.26 spec update: * Bump API patch number and header version number to 26 for this update. Github Issues: * Bring sample code in the +VK_KHR_surface+ and +VK_KHR_swapchain+ extension summary appendices up to date, and note they will be replaced with pointers to the LunarG SDK examples in the future (public issue 279). * Add a new <<fundamentals-commandsyntax-results-lifetime,Lifetime of Retrieved Results>> section specifying that ftext:vkGet* and ftext:VkEnumerate* results are invariant unless otherwise specified, and specify behavior for individual commands which are not invariant (public issue 280). * Remove conflicting definition of slink:VkDisplayPlaneCapabilitiesKHR::pname:maxSrcPosition and clean up language of the remaining definition (public issue 351). * Fix many minor spelling errors and add rules to the style guide to prevent recurrences (public issue 352). Internal Issues: * Remove redundant descriptions of the etext:VK_USE_PLATFORM_* macros from the <<wsi,Window System Integration>> chapter in favor of the description in the <<boilerplate-wsi-header,Window System-Specific Header Control>> appendix (internal issue 6). * Replace misleading 'can: be destroyed when not X' with more correct 'must: not be destroyed while X' in the <<fundamentals-objectmodel-lifetime,Object Lifetime>> section. Disallow destroying a pipeline layout while a command buffer using it is recording (internal issue 241). * Clarify that ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT is valid for all images used as attachments in elink:VkImageUsageFlagBits and the slink:VkImageLayout validity language (internal issue 320). * Note that <<extended-functionality-layers,Layers>> may wrap object handles, but that this is a generally discouraged. A link to additional information in the documentation for layer authors is provided (issue 398) * Replace the mustnot: and shouldnot: macros with equivalent must: not and should: not to get rid of non-English words while still highlighting normative language (internal issue 407). * Disallow creating multisampled images with ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT in the slink:VkImageLayout validity language and the <<features-supported-sample-counts,Supported Sample Counts>> section (internal issue 445). * Fix typo so that flink:vkCmdDrawIndexedIndirect is defined in terms of flink:vkCmdDrawIndexed rather than flink:vkCmdDrawIndirect (internal issue 446). * Reorganize the per-extension information sections to all be in the <<extensions,Layers & Extensions>> appendix. Also fix a typo in +VK_IMG_filter_cubic+ which incorrectly identified it as a +KHR+ extension (internal issue 461). Other Issues: * Use asciidoc markup instead of latexmath to simplify diagrams in the <<features-formats-non-packed,byte mapping tables>> for color formats. * Fix a markup problem with the wildcarded enumerant names in a NOTE in the <<textures-texel-replacement,Texel Replacement>> section. * Fix missing attributes in the XML interface for elink:VkExternalMemoryHandleTypeFlagBitsNV and elink:VkExternalMemoryFeatureFlagBitsNV (KhronosGroup/Vulkan-Hpp issue #25) * Cleanup reference page builds so only core pages are built for releases.
2016-09-06 13:17:27 +00:00
and must: not be used when tessellation is in use.
2016-02-16 09:53:44 +00:00
+
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
Change log for September 6, 2016 Vulkan 1.0.26 spec update: * Bump API patch number and header version number to 26 for this update. Github Issues: * Bring sample code in the +VK_KHR_surface+ and +VK_KHR_swapchain+ extension summary appendices up to date, and note they will be replaced with pointers to the LunarG SDK examples in the future (public issue 279). * Add a new <<fundamentals-commandsyntax-results-lifetime,Lifetime of Retrieved Results>> section specifying that ftext:vkGet* and ftext:VkEnumerate* results are invariant unless otherwise specified, and specify behavior for individual commands which are not invariant (public issue 280). * Remove conflicting definition of slink:VkDisplayPlaneCapabilitiesKHR::pname:maxSrcPosition and clean up language of the remaining definition (public issue 351). * Fix many minor spelling errors and add rules to the style guide to prevent recurrences (public issue 352). Internal Issues: * Remove redundant descriptions of the etext:VK_USE_PLATFORM_* macros from the <<wsi,Window System Integration>> chapter in favor of the description in the <<boilerplate-wsi-header,Window System-Specific Header Control>> appendix (internal issue 6). * Replace misleading 'can: be destroyed when not X' with more correct 'must: not be destroyed while X' in the <<fundamentals-objectmodel-lifetime,Object Lifetime>> section. Disallow destroying a pipeline layout while a command buffer using it is recording (internal issue 241). * Clarify that ename:VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT is valid for all images used as attachments in elink:VkImageUsageFlagBits and the slink:VkImageLayout validity language (internal issue 320). * Note that <<extended-functionality-layers,Layers>> may wrap object handles, but that this is a generally discouraged. A link to additional information in the documentation for layer authors is provided (issue 398) * Replace the mustnot: and shouldnot: macros with equivalent must: not and should: not to get rid of non-English words while still highlighting normative language (internal issue 407). * Disallow creating multisampled images with ename:VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT in the slink:VkImageLayout validity language and the <<features-supported-sample-counts,Supported Sample Counts>> section (internal issue 445). * Fix typo so that flink:vkCmdDrawIndexedIndirect is defined in terms of flink:vkCmdDrawIndexed rather than flink:vkCmdDrawIndirect (internal issue 446). * Reorganize the per-extension information sections to all be in the <<extensions,Layers & Extensions>> appendix. Also fix a typo in +VK_IMG_filter_cubic+ which incorrectly identified it as a +KHR+ extension (internal issue 461). Other Issues: * Use asciidoc markup instead of latexmath to simplify diagrams in the <<features-formats-non-packed,byte mapping tables>> for color formats. * Fix a markup problem with the wildcarded enumerant names in a NOTE in the <<textures-texel-replacement,Texel Replacement>> section. * Fix missing attributes in the XML interface for elink:VkExternalMemoryHandleTypeFlagBitsNV and elink:VkExternalMemoryFeatureFlagBitsNV (KhronosGroup/Vulkan-Hpp issue #25) * Cleanup reference page builds so only core pages are built for releases.
2016-09-06 13:17:27 +00:00
code:VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP_WITH_ADJACENCY, and must: not be
2016-02-16 09:53:44 +00:00
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 latexmath:[$n$] times for
each input primitive, where latexmath:[$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.
2016-02-16 09:53:44 +00:00
[[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.