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 requires 15 {spirv}/NV/SPV_NV_fragment_shader_barycentric.html[`SPV_NV_fragment_shader_barycentric`] 16 - This extension provides API support for 17 {GLSLregistry}/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 52=== Promotion to `VK_KHR_fragment_shader_barycentric` 53 54All functionality in this extension is included in 55`apiext:VK_KHR_fragment_shader_barycentric`, with the suffix changed to KHR. 56 57include::{generated}/interfaces/VK_NV_fragment_shader_barycentric.adoc[] 58 59=== New Built-In Variables 60 61 * <<interfaces-builtin-variables-barycoordkhr,code:BaryCoordNV>> 62 * <<interfaces-builtin-variables-barycoordnoperspkhr,code:BaryCoordNoPerspNV>> 63 64=== New SPIR-V Decorations 65 66 * <<shaders-interpolation-decorations-pervertexkhr,code:PerVertexNV>> 67 68=== New SPIR-V Capabilities 69 70 * <<spirvenv-capabilities-table-FragmentBarycentricKHR, 71 code:FragmentBarycentricNV>> 72 73=== Issues 74 75(1) The AMD_shader_explicit_vertex_parameter extension provides similar 76 functionality. 77 Why write a new extension, and how is this extension different? 78 79*RESOLVED*: For the purposes of Vulkan/SPIR-V, we chose to implement a 80separate extension due to several functional differences. 81 82First, the hardware supporting this extension can provide a three-component 83barycentric weight vector for variables decorated with code:BaryCoordNV, 84while variables decorated with code:BaryCoordSmoothAMD provide only two 85components. 86In some cases, it may be more efficient to explicitly interpolate an 87attribute via: 88 89 float value = (baryCoordNV.x * v[0].attrib + 90 baryCoordNV.y * v[1].attrib + 91 baryCoordNV.z * v[2].attrib); 92 93instead of 94 95 float value = (baryCoordSmoothAMD.x * (v[0].attrib - v[2].attrib) + 96 baryCoordSmoothAMD.y * (v[1].attrib - v[2].attrib) + 97 v[2].attrib); 98 99Additionally, the semantics of the decoration code:BaryCoordPullModelAMD do 100not appear to map to anything supported by the initial hardware 101implementation of this extension. 102 103This extension provides a smaller number of decorations than the AMD 104extension, as we expect that shaders could derive variables decorated with 105things like code:BaryCoordNoPerspCentroidAMD with explicit attribute 106interpolation instructions. 107One other relevant difference is that explicit per-vertex attribute access 108using this extension does not require a constant vertex number. 109 110(2) Why do the built-in SPIR-V decorations for this extension include two 111separate built-ins code:BaryCoordNV and code:BaryCoordNoPerspNV when a "`no 112perspective`" variable could be decorated with code:BaryCoordNV and 113code:NoPerspective? 114 115*RESOLVED*: The SPIR-V extension for this feature chose to mirror the 116behavior of the GLSL extension, which provides two built-in variables. 117Additionally, it is not clear that its a good idea (or even legal) to have 118two variables using the "`same attribute`", but with different interpolation 119modifiers. 120 121=== Version History 122 123 * Revision 1, 2018-08-03 (Pat Brown) 124 ** Internal revisions 125