mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-20 18:18:06 +00:00
e24e42dcff
* Update release number to 91.
Public Issues:
* Update Ubuntu subsystem build instructions in `BUILD.adoc` (public pull
request 624).
* Delete the `VK_KHR_mir_surface` extension from the Specification and
XML, due to EOL of the only driver known to have supported it, and
near-EOL of Mir itself (public issue 814).
* Fix options for some figures that were using old ones (public pull
request 841).
* Fix various accidentally repeated words (public pull request 843).
* Use `time.process_time()`, introduced in Python 3.3, in the scripts
instead of `time.clock()`, which will be removed in Python 3.8 (public
pull request 844).
Internal Issues:
* Update valid usage statements for
`VK_ANDROID_external_memory_android_hardware_buffer` in
slink:VkMemoryAllocateInfo,
slink:VkImportAndroidHardwareBufferInfoANDROID, and
flink:vkGetAndroidHardwareBufferPropertiesANDROID to actually be
verifiable (internal issue 1419).
* Update valid usage statements for
`VK_ANDROID_external_memory_android_hardware_buffer` in
slink:VkMemoryAllocateInfo, slink:VkImageCreateInfo, and
slink:VkImageViewCreateInfo to move valid usage statements in
doubly-nested bullet points up one level, accomodating limitations of
the valid usage extraction script that creates `validusage.json`
(internal issue 1434).
* Fix typo etext:VK_ACCESS_SHADING_RATE_IMAGE_BIT_NV to the correct
ename:VK_ACCESS_SHADING_RATE_IMAGE_READ_BIT_NV.
* Add missing etext:VK_STRUCTURE_TYPE_* tokens to appendices for
extensions missing them.
New Extensions:
* `VK_AMD_memory_overallocation_behavior`
* `VK_NV_ray_tracing`, replacing `VK_NVX_raytracing`
129 lines
4.4 KiB
Plaintext
129 lines
4.4 KiB
Plaintext
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
|
|
|
|
* 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
|