Name

VK_NV_fragment_shader_barycentric - device extension

VK_NV_fragment_shader_barycentric

Name String

VK_NV_fragment_shader_barycentric

Extension Type

Device extension

Registered Extension Number

204

Revision

1

Ratification Status

Not ratified

Extension and Version Dependencies

VK_KHR_get_physical_device_properties2

Deprecation State

• Promoted to VK_KHR_fragment_shader_barycentric extension

Contact

• Pat Brown @nvpbrown%0A*Here describe the issue or question you have about the VK_NV_fragment_shader_barycentric extension*

Other Extension Metadata

Last Modified Date

2018-08-03

IP Status

No known IP claims.

Interactions and External Dependencies

• This extension requires SPV_NV_fragment_shader_barycentric
• 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:

• SPV_NV_fragment_shader_barycentric

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 Structures

• Extending PhysicalDeviceFeatures2, DeviceCreateInfo:

  • PhysicalDeviceFragmentShaderBarycentricFeaturesNV

New Enum Constants

• NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME

• NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION

• Extending StructureType:

  • STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV

New Built-In Variables

• BaryCoordNV

• BaryCoordNoPerspNV

New SPIR-V Decorations

• PerVertexNV

New SPIR-V Capabilities

• FragmentBarycentricNV

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.

1. 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.

Version History

• Revision 1, 2018-08-03 (Pat Brown)

  • Internal revisions

See Also

PhysicalDeviceFragmentShaderBarycentricFeaturesNV

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.