1  include::meta/VK_NV_fragment_shader_barycentric.txt[]
  2  
  3  *Last Modified Date*::
  4      2018-08-03
  5  *IP Status*::
  6      No known IP claims.
  7  *Interactions and External Dependencies*::
  8    - Requires the SPV_NV_fragment_shader_barycentric SPIR-V extension.
  9    - Requires the GL_NV_fragment_shader_barycentric extension for GLSL source
 10      languages.
 11  *Contributors*::
 12    - Pat Brown, NVIDIA
 13    - Daniel Koch, NVIDIA
 14  
 15  This extension adds support for the following SPIR-V extension in Vulkan:
 16  
 17    * `SPV_NV_fragment_shader_barycentric`
 18  
 19  The extension provides access to three additional fragment shader variable
 20  decorations in SPIR-V:
 21  
 22    * code:PerVertexNV, which indicates that a fragment shader input will not
 23      have interpolated values, but instead must be accessed with an extra
 24      array index that identifies one of the vertices of the primitive
 25      producing the fragment
 26    * code:BaryCoordNV, which indicates that the variable is a three-component
 27      floating-point vector holding barycentric weights for the fragment
 28      produced using perspective interpolation
 29    * code:BaryCoordNoPerspNV, which indicates that the variable is a
 30      three-component floating-point vector holding barycentric weights for
 31      the fragment produced using linear interpolation
 32  
 33  When using GLSL source-based shader languages, the following variables from
 34  `GL_NV_fragment_shader_barycentric` maps to these SPIR-V built-in
 35  decorations:
 36  
 37    * `in vec3 gl_BaryCoordNV;` -> code:BaryCoordNV
 38    * `in vec3 gl_BaryCoordNoPerspNV;` -> code:BaryCoordNoPerspNV
 39  
 40  GLSL variables declared using the code:__pervertexNV GLSL qualifier are
 41  expected to be decorated with code:PerVertexNV in SPIR-V.
 42  
 43  === New Object Types
 44  
 45  None.
 46  
 47  === New Enum Constants
 48  
 49    * Extending elink:VkStructureType
 50    ** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV
 51  
 52  === New Enums
 53  
 54  None.
 55  
 56  === New Structures
 57  
 58  None.
 59  
 60  === New Functions
 61  
 62  None.
 63  
 64  === New Built-In Variables
 65  
 66    * <<interfaces-builtin-variables-barycoordnv,code:BaryCoordNV>>
 67    * <<interfaces-builtin-variables-barycoordnoperspnv,code:BaryCoordNoPerspNV>>
 68  
 69  === New SPIR-V Decorations
 70  
 71    * <<shaders-interpolation-decorations-pervertexnv,code:PerVertexNV>>
 72  
 73  === New SPIR-V Capabilities
 74  
 75    * <<spirvenv-capabilities-fragment-barycentric,code:FragmentBarycentricNV>>
 76  
 77  === Issues
 78  
 79  (1) The AMD_shader_explicit_vertex_parameter extension provides similar
 80      functionality.
 81      Why write a new extension, and how is this extension different?
 82  
 83  *RESOLVED*: For the purposes of Vulkan/SPIR-V, we chose to implement a
 84  separate extension due to several functional differences.
 85  
 86  First, the hardware supporting this extension can provide a three-component
 87  barycentric weight vector for variables decorated with code:BaryCoordNV,
 88  while variables decorated with code:BaryCoordSmoothAMD provide only two
 89  components.
 90  In some cases, it may be more efficient to explicitly interpolate an
 91  attribute via:
 92  
 93          float value = (baryCoordNV.x * v[0].attrib +
 94                         baryCoordNV.y * v[1].attrib +
 95                         baryCoordNV.z * v[2].attrib);
 96  
 97  instead of
 98  
 99         float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) +
100                        baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) +
101                        v[2].attrib);
102  
103  Additionally, the semantics of the decoration code:BaryCoordPullModelAMD do
104  not appear to map to anything supported by the initial hardware
105  implementation of this extension.
106  
107  This extension provides a smaller number of decorations than the AMD
108  extension, as we expect that shaders could derive variables decorated with
109  things like code:BaryCoordNoPerspCentroidAMD with explicit attribute
110  interpolation instructions.
111  One other relevant difference is that explicit per-vertex attribute access
112  using this extension does not require a constant vertex number.
113  
114  (2) Why do the built-in SPIR-V decorations for this extension include two
115      separate built-ins code:BaryCoordNV and code:BaryCoordNoPerspNV when a
116      "`no perspective`" variable could be decorated with code:BaryCoordNV and
117      code:NoPerspective?
118  
119  *RESOLVED*: The SPIR-V extension for this feature chose to mirror the
120  behavior of the GLSL extension, which provides two built-in variables.
121  Additionally, it's not clear that its a good idea (or even legal) to have
122  two variables using the "`same attribute`", but with different interpolation
123  modifiers.
124  
125  === Version History
126  
127    * Revision 1, 2018-08-03 (Pat Brown)
128      - Internal revisions