Vulkan-Docs/doc/specs/vulkan/appendices/VK_NV_geometry_shader_passthrough.txt
Jon Leech 0cc6bba634 Change log for September 15, 2017 Vulkan 1.0.61 spec update:
* Bump API patch number and header version number to 61 for this update.

Github Issues:

  * Provide alternate length attributes (altlen=) in the XML schema, for
    those using length attributes to generate code instead of documentation
    (public issue 555).
  * Fix erroneous references to `latex:` being used for asciidoc math
    markup, rather than `latexmath:` (public pull request 556).
  * Add author ID to XML for Kazan software renderer (public pull request
    557).

Internal Issues:

  * Add the <<fundamentals-abi,Application Binary Interface>> section
    describing platform ABI requirements and recommendations, add examples
    of function and function pointer declarations to the
    <<boilerplate-platform-specific-calling-conventions, Platform-Specific
    Calling Conventions>> section, and remove related language that existed
    elsewhere in the specification (internal issue 64).
  * Describe where to document valid usage interactions of chained
    structures in the style guide, and fix one case now appearing in
    slink:VkBufferCreateInfo instead of the child
    slink:VkDedicatedAllocationBufferCreateInfoNV structure (internal issue
    715).
  * Add example to the style guide of describing enumerated types which are
    empty when the spec is built without relevant extensions enabled, and
    apply it to existing examples for
    elink:VkDescriptorSetLayoutCreateFlagBits and
    elink:VkSubpassDescriptionFlagBits (internal issue 864).
  * Add a note to the <<fundamentals-validusage-enums, Valid Usage for
    Enumerated Types>> section that the special values suffixed with
    etext:_BEGIN_RANGE, etext:_END_RANGE, etext:_RANGE_SIZE and
    etext:_MAX_ENUM are not part of the API and should: not be used by
    applications (internal issue 872).
  * Added note to flink:vkCmdUpdateBuffers explaining the performance
    penalty for copies done in this way, and why the upper copy limit is
    what it is (internal issue 952).
  * Update `VK_KHX_device_group` to split some functionality into the new
    `VK_KHR_bind_memory2` extension, and rename that functionality (internal
    issue 969).
  * Remove *Status* fields from extension appendices, since they are by
    definition published and complete by the time they reach the public
    github repository (internal issue 973).

Other Issues:

  * Update Data Format specification dependency to version 1.2 and change
    references to DF sections accordingly.
  * Update XML to make the pname:pAllocator parameter of
    flink:vkRegisterDeviceEventEXT and flink:vkRegisterDisplayEventEXT in
    the `VK_EXT_display_control` extension as optional.

New Extensions:

  * `VK_KHR_bind_memory2`
  * `VK_KHR_image_format_list`
  * `VK_KHR_maintenance2`
  * `VK_KHR_sampler_ycbcr_conversion`
2017-09-14 22:41:33 -07:00

185 lines
5.5 KiB
Plaintext

include::meta/VK_NV_geometry_shader_passthrough.txt[]
*Last Modified Date*::
2017-02-15
*Interactions and External Dependencies*::
- This extension requires the
https://www.khronos.org/registry/spir-v/extensions/NV/SPV_NV_geometry_shader_passthrough.html[+SPV_NV_geometry_shader_passthrough+]
SPIR-V extension.
- This extension requires the
https://www.khronos.org/registry/OpenGL/extensions/NV/NV_geometry_shader_passthrough.txt[+GL_NV_geometry_shader_passthrough+]
extension for GLSL source languages.
- This extension requires the pname:geometryShader feature.
*Contributors*::
- Piers Daniell, NVIDIA
- Jeff Bolz, NVIDIA
This extension adds support for the following SPIR-V extension in Vulkan:
* +SPV_NV_geometry_shader_passthrough+
Geometry shaders provide the ability for applications to process each
primitive sent through the graphics pipeline using a programmable shader.
However, one common use case treats them largely as a "passthrough".
In this use case, the bulk of the geometry shader code simply copies inputs
from each vertex of the input primitive to corresponding outputs in the
vertices of the output primitive.
Such shaders might also compute values for additional built-in or
user-defined per-primitive attributes (e.g., code:Layer) to be assigned to
all the vertices of the output primitive.
This extension provides access to the code:PassthroughNV decoration under
the code:GeometryShaderPassthroughNV capability.
Adding this to a geometry shader input variable indicates that the values of
this input are copied to the corresponding vertex of the output primitive.
When using GLSL source-based shading languages, the code:passthrough layout
qualifier from +GL_NV_geometry_shader_passthrough+ maps to the
code:PassthroughNV decoration.
To use the code:passthrough layout, in GLSL the
+GL_NV_geometry_shader_passthrough+ extension must be enabled.
Behaviour is described in the +GL_NV_geometry_shader_passthrough+ extension
specification.
=== New Object Types
None.
=== New Enum Constants
None.
=== New Enums
None.
=== New Structures
None.
=== New Functions
None.
=== New Built-In Variables
None.
=== New Variable Decoration
* <<geometry-passthrough-passthrough,code:PassthroughNV>> in
<<geometry-passthrough,Geometry Shader Passthrough>>
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-table-geometryshaderpassthrough,GeometryShaderPassthroughNV>>
=== Issues
1) Should we require or allow a passthrough geometry shader to specify the
output layout qualifiers for the output primitive type and maximum vertex
count in the SPIR-V?
*RESOLVED*: Yes they should be required in the SPIR-V.
Per GL_NV_geometry_shader_passthrough they are not permitted in the GLSL
source shader, but SPIR-V is lower-level.
It is straight forward for the GLSL compiler to infer them from the input
primitive type and to explicitly emit them in the SPIR-V according to the
following table.
[options="header"]
|====
| Input Layout | Implied Output Layout
| points | layout(points, max_vertices=1)
| lines | layout(line_stripo, max_vertices=2)
| triangles | layout(triangle_strip, max_vertices=3)
|====
2) How does interface matching work with passthrough geometry shaders?
*RESOLVED*: This is described in <<geometry-passthrough-interface,
Passthrough Interface Matching>>.
In GL when using passthough geometry shaders in separable mode, all inputs
must also be explicitly assigned location layout qualifiers.
In Vulkan all SPIR-V shader inputs (except built-ins) must also have
location decorations specified.
Redeclarations of built-in varables that add the passthrough layout
qualifier are exempted from the rule requiring location assignment because
built-in variables are do not have locations and are matched by builtin
decoration.
=== Sample Code
Consider the following simple geometry shader in unextended GLSL:
[source,c]
---------------------------------------------------
layout(triangles) in;
layout(triangle_strip) out;
layout(max_vertices=3) out;
in Inputs {
vec2 texcoord;
vec4 baseColor;
} v_in[];
out Outputs {
vec2 texcoord;
vec4 baseColor;
};
void main()
{
int layer = compute_layer();
for (int i = 0; i < 3; i++) {
gl_Position = gl_in[i].gl_Position;
texcoord = v_in[i].texcoord;
baseColor = v_in[i].baseColor;
gl_Layer = layer;
EmitVertex();
}
}
---------------------------------------------------
In this shader, the inputs "gl_Position", "Inputs.texcoord", and
"Inputs.baseColor" are simply copied from the input vertex to the
corresponding output vertex.
The only "interesting" work done by the geometry shader is computing and
emitting a gl_Layer value for the primitive.
The following geometry shader, using this extension, is equivalent:
[source,c]
---------------------------------------------------
#extension GL_NV_geometry_shader_passthrough : require
layout(triangles) in;
// No output primitive layout qualifiers required.
// Redeclare gl_PerVertex to pass through "gl_Position".
layout(passthrough) in gl_PerVertex {
vec4 gl_Position;
} gl_in[];
// Declare "Inputs" with "passthrough" to automatically copy members.
layout(passthrough) in Inputs {
vec2 texcoord;
vec4 baseColor;
} v_in[];
// No output block declaration required.
void main()
{
// The shader simply computes and writes gl_Layer. We don't
// loop over three vertices or call EmitVertex().
gl_Layer = compute_layer();
}
---------------------------------------------------
=== Version History
* Revision 1, 2017-02-15 (Daniel Koch)
- Internal revisions