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