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