Vulkan-Docs/appendices/VK_NV_fragment_shader_baryc...

128 lines
4.2 KiB
Plaintext
Raw Normal View History

Change log for September 19, 2018 Vulkan 1.1.85 spec update: * Update release number to 85. Public Issues: * Add self-dependency ename:VK_DEPENDENCY_BY_REGION_BIT valid usage statements for slink:VkSubpassDependency(public pull request 778). * Apply fix from pull request 742 to slink:VkSubpassDependency and slink:VkSubpassDependency2 (public pull request 779). * Specify the units of slink:VkBufferImageCopy::pname:bufferRowLength and pname:bufferImageHeight as texels (public pull request 781). * Better specify promoted parameter mapping in the `<<VK_KHR_create_renderpass2>>` appendix (public pull request 782). Internal Issues: * Only include the <<fundamentals-validusage-versions, Valid Usage for Newer Core Versions>> section in Vulkan 1.1 or later (internal issue 1381). Other Issues: * Clean up redundant valid usage language for the `VK_ANDROID_external_memory_android_hardware_buffer` extension interaction with slink:VkImageCreateInfo. * Fix error in a flag name within valid usage statements for slink:VkMemoryAllocateInfo. * Clarify that memory types are not totally ordered in slink:VkPhysicalDeviceMemoryProperties. * For slink:VkWriteDescriptorSetInlineUniformBlockEXT, set structextends="VkWriteDescriptorSet" in `vk.xml`, and make slink:VkDescriptorSetLayoutBindingFlagsCreateInfoEXT::pname:pBindingFlags optional. * Add documentation of 'provisional' XML attribute to registry.txt. New Extensions: * `VK_NV_compute_shader_derivatives` * `VK_NV_corner_sampled_image` * `VK_NV_fragment_shader_barycentric` * `VK_NV_mesh_shader` * `VK_NV_representative_fragment_test` * `VK_NV_scissor_exclusive` * `VK_NV_shader_image_footprint` * `VK_NV_shading_rate_image` * `VK_NVX_raytracing`
2018-09-16 01:35:16 +00:00
include::meta/VK_NV_fragment_shader_barycentric.txt[]
*Last Modified Date*::
2018-08-03
*IP Status*::
No known IP claims.
*Interactions and External Dependencies*::
- Requires the SPV_NV_fragment_shader_barycentric SPIR-V extension.
- Requires the GL_NV_fragment_shader_barycentric extension for GLSL source
languages.
*Contributors*::
- Pat Brown, NVIDIA
- Daniel Koch, NVIDIA
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:
* code: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
* code:BaryCoordNV, which indicates that the variable is a three-component
floating-point vector holding barycentric weights for the fragment
produced using perspective interpolation
* code: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;` -> code:BaryCoordNV
* `in vec3 gl_BaryCoordNoPerspNV;` -> code:BaryCoordNoPerspNV
GLSL variables declared using the code:__pervertexNV GLSL qualifier are
expected to be decorated with code:PerVertexNV in SPIR-V.
=== New Object Types
None.
=== New Enum Constants
None.
=== New Enums
None.
=== New Structures
None.
=== New Functions
None.
=== New Built-In Variables
* <<interfaces-builtin-variables-barycoordnv,code:BaryCoordNV>>
* <<interfaces-builtin-variables-barycoordnoperspnv,code:BaryCoordNoPerspNV>>
=== New SPIR-V Decorations
* <<shaders-interpolation-decorations-pervertexnv,code:PerVertexNV>>
=== New SPIR-V Capabilities
* <<spirvenv-capabilities-fragment-barycentric,code: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 code:BaryCoordNV,
while variables decorated with code: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 code: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 code: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 code:BaryCoordNV and code:BaryCoordNoPerspNV when a
"no perspective" variable could be decorated with code:BaryCoordNV and
code: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's 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