Requires Vulkan 1.0
Pat Brown nvpbrown
This extension adds support for the following SPIR-V extension in Vulkan:
The extension provides access to three additional fragment shader variable decorations in SPIR-V:
PerVertexNV, which indicates that a fragment shader input will not have interpolated values, but instead must be accessed with an extra array index that identifies one of the vertices of the primitive producing the fragment
BaryCoordNV, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using perspective interpolation
BaryCoordNoPerspNV, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using linear interpolation
When using GLSL source-based shader languages, the following variables from
GL_NV_fragment_shader_barycentric maps to these SPIR-V built-in
in vec3 gl_BaryCoordNV;→
in vec3 gl_BaryCoordNoPerspNV;→
GLSL variables declared using the
__pervertexNV GLSL qualifier are
expected to be decorated with
PerVertexNV in SPIR-V.
(1) The AMD_shader_explicit_vertex_parameter extension provides similar functionality. Why write a new extension, and how is this extension different?
RESOLVED: For the purposes of Vulkan/SPIR-V, we chose to implement a separate extension due to several functional differences.
First, the hardware supporting this extension can provide a three-component
barycentric weight vector for variables decorated with
while variables decorated with
BaryCoordSmoothAMD provide only two
In some cases, it may be more efficient to explicitly interpolate an
float value = (baryCoordNV.x * v.attrib + baryCoordNV.y * v.attrib + baryCoordNV.z * v.attrib);
float value = (baryCoordSmoothAMD.x * (v.attrib - v.attrib) + baryCoordSmoothAMD.y * (v.attrib - v.attrib) + v.attrib);
Additionally, the semantics of the decoration
not appear to map to anything supported by the initial hardware
implementation of this extension.
This extension provides a smaller number of decorations than the AMD
extension, as we expect that shaders could derive variables decorated with
BaryCoordNoPerspCentroidAMD with explicit attribute
One other relevant difference is that explicit per-vertex attribute access
using this extension does not require a constant vertex number.
(2) Why do the built-in SPIR-V decorations for this extension include two
BaryCoordNoPerspNV when a “no
perspective” variable could be decorated with
RESOLVED: The SPIR-V extension for this feature chose to mirror the behavior of the GLSL extension, which provides two built-in variables. Additionally, it is not clear that its a good idea (or even legal) to have two variables using the “same attribute”, but with different interpolation modifiers.
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.