mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-19 17:48:23 +00:00
f1a7c4b4f3
* Update release number to 98.
Public Issues:
* Fix missing markup in flink:vkDestroyPipelineLayout valid usage
statement (pull request 882).
* Add missing contributors for `<<VK_EXT_buffer_device_address>>` (public
pull request 891).
Internal Issues:
* Detect nested bullet points in valid usage blocks and warn about them
during VUID assignment (internal issue 1382).
* Update the style guide to document the process for reserving new bits in
bitmask types (internal issue 1411).
* Clarify for slink:VkApplicationInfo::pname:apiVersion and in the
<<fundamentals-validusage-versions, Valid Usage for Newer Core
Versions>> section when it is valid for an application to use a certain
version of Vulkan API functionality (for an instance and for a
device/physical device); and when the validation layers must generate an
error (internal issue 1412).
* Add optional <<memory-model-availability-visibility, transitive
availability/visibility operations to the memory model, including a new
pname:vulkanMemoryModelAvailabilityVisibilityChains feature for
slink:VkPhysicalDeviceVulkanMemoryModelFeaturesKHR (internal issue
1460).
* Add the code:StorageBuffer storage class to those in the
<<interfaces-resources-descset, Descriptor Set Interface>> (internal
issue 1480).
* Add missing `returnedonly` tags for a number of returned extension
structures that can be passed in pname:pNext chains (internal issue
1515).
* Clean up and rearrange some spec language for
slink:VkRenderPassCreateInfo and slink:VkAttachmentReference.txt
(internal issue 1522).
* Correctly round the code:OpVectorTimesScalar and
code:OpMatrixTimesScalar SPIR-V operations in the <<Precision of core
SPIR-V Instructions>> table (internal merge request 2996).
* Work around cases in flink:vkCmdBeginTransformFeedbackEXT,
flink:vkCmdEndTransformFeedbackEXT, and
slink:VkPipelineCoverageModulationStateCreateInfoNV where an array
parameter is `optional` but the length is not in `vk.xml`. This is an
interim fix using `noautovalidity` + handcoded VU replacing those that
should be autogenerated (internal issue 2944 and
https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/480).
* Remove redundant capability validation of the code:float16 and code:int8
SPIR-V capabilities from the <<spirvenv-capabilities, Capabilities>>
section, since they are already covered in the preceding table.
* Update check_spec_links script, including validation for reference page
open blocks. Fix errors identified by the script.
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
|