mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-26 04:55:12 +00:00
22a5a1459f
* Update release number to 124.
Github Issues:
* Fix Makefile SPECREMARK macro to work when not building in a git tree
(public issue 992).
* Ignore pname:aspectMask for unused attachments in
slink:VkSubpassDescription2KHR valid usage statements (public pull
request 1028).
* Minor markup / spelling fixes (public pull requests 1035, 1045).
Internal Issues:
* Fix markup in Valid Usage statement for slink:VkCreateFramebuffer
(internal issue 1823).
* Add a new <<synchronization-signal-operation-order, _signal operation
order_>> section to the synchronization chapter which describes in
detail the ordering guarantees provided by the API between fence and
semaphore signal operations (internal merge request 3368).
* Move generated `appendix/meta/` files into the Makefile GENERATED
directory (internal merge request 3381).
New Extensions
* `<<VK_KHR_shader_clock>>`
* `<<VK_KHR_timeline_semaphore>>`
129 lines
4.4 KiB
Plaintext
129 lines
4.4 KiB
Plaintext
include::{generated}/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:
|
|
|
|
* {spirv}/NV/SPV_NV_fragment_shader_barycentric.html[`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
|
|
|
|
* Extending elink:VkStructureType
|
|
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FRAGMENT_SHADER_BARYCENTRIC_FEATURES_NV
|
|
|
|
=== 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
|