Deprecation State
-
Promoted to VK_KHR_fragment_shader_barycentric extension
Contact
-
Pat Brown nvpbrown
Other Extension Metadata
- Last Modified Date
-
2018-08-03
- IP Status
-
No known IP claims.
- Interactions and External Dependencies
-
-
This extension provides API support for
GL_NV_fragment_shader_barycentric
-
- Contributors
-
-
Pat Brown, NVIDIA
-
Daniel Koch, NVIDIA
-
Description
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
decorations:
-
in vec3 gl_BaryCoordNV;→BaryCoordNV -
in vec3 gl_BaryCoordNoPerspNV;→BaryCoordNoPerspNV
GLSL variables declared using the __pervertexNV GLSL qualifier are
expected to be decorated with PerVertexNV in SPIR-V.
Promotion to VK_KHR_fragment_shader_barycentric
All functionality in this extension is included in
VK_KHR_fragment_shader_barycentric, with the suffix changed to KHR.
New Enum Constants
-
VK_NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME -
VK_NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION -
Extending VkStructureType:
-
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV
-
Issues
(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 BaryCoordNV,
while variables decorated with BaryCoordSmoothAMD provide only two
components.
In some cases, it may be more efficient to explicitly interpolate an
attribute via:
float value = (baryCoordNV.x * v[0].attrib +
baryCoordNV.y * v[1].attrib +
baryCoordNV.z * v[2].attrib);
instead of
float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
v[2].attrib);
Additionally, the semantics of the decoration BaryCoordPullModelAMD do
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
things like BaryCoordNoPerspCentroidAMD with explicit attribute
interpolation instructions.
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
separate built-ins BaryCoordNV and BaryCoordNoPerspNV when a “no
perspective” variable could be decorated with BaryCoordNV and
NoPerspective?
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.
Document Notes
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.