VK_NV_fragment_shader_barycentric(3)

# VK_NV_fragment_shader_barycentric(3) Manual Page

## Name

VK_NV_fragment_shader_barycentric - device extension

Loading… please wait.

## Registered Extension Number

204

## Revision

1

## Ratification Status

Not ratified

## Extension and Version Dependencies

VK_KHR_get_physical_device_properties2
or
Vulkan Version 1.1

## SPIR-V Dependencies

- SPV_NV_fragment_shader_barycentric

## Deprecation State

- Promoted to VK_KHR_fragment_shader_barycentric extension

## Contact

- Pat Brown [GitHub]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:

- `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 VkPhysicalDeviceFeatures2, VkDeviceCreateInfo:

  - VkPhysicalDeviceFragmentShaderBarycentricFeaturesNV

## 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`

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

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

## Version History

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

  - Internal revisions

## See Also

No cross-references are available

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

## Copyright

Copyright 2014-2025 The Khronos Group Inc.

SPDX-License-Identifier: CC-BY-4.0