Safe Haskell | None |
---|---|
Language | Haskell2010 |
Name
VK_NV_fragment_shader_barycentric - device extension
VK_NV_fragment_shader_barycentric
- Name String
VK_NV_fragment_shader_barycentric
- Extension Type
- Device extension
- Registered Extension Number
- 204
- Revision
- 1
- Extension and Version Dependencies
- Requires Vulkan 1.0
- Requires
VK_KHR_get_physical_device_properties2
- Contact
Other Extension Metadata
- Last Modified Date
- 2018-08-03
- IP Status
- No known IP claims.
- Interactions and External Dependencies
- This extension requires SPV_NV_fragment_shader_barycentric
- This extension provides API support for GL_NV_fragment_shader_barycentric
- Contributors
- Pat Brown, NVIDIA
- Daniel Koch, NVIDIA
Description
This extension adds support for the following SPIR-V extension in Vulkan:
The extension provides access to three additional fragment shader variable decorations in SPIR-V:
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 fragmentBaryCoordNV
, which indicates that the variable is a three-component floating-point vector holding barycentric weights for the fragment produced using perspective interpolationBaryCoordNoPerspNV
, 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;
→BaryCoordNV
in vec3 gl_BaryCoordNoPerspNV;
→BaryCoordNoPerspNV
GLSL variables declared using the __pervertexNV
GLSL qualifier are
expected to be decorated with PerVertexNV
in SPIR-V.
New Structures
Extending
PhysicalDeviceFeatures2
,DeviceCreateInfo
:
New Enum Constants
New Built-In Variables
New SPIR-V Decorations
New SPIR-V Capabilities
Issues
- 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
BaryCoordNV
, while variables decorated with 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 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 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.
- Why do the built-in SPIR-V decorations for this extension include
two separate built-ins
BaryCoordNV
andBaryCoordNoPerspNV
when a “no perspective” variable could be decorated withBaryCoordNV
andNoPerspective
?
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 is 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
See Also
PhysicalDeviceFragmentShaderBarycentricFeaturesNV
Document Notes
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.
Synopsis
- data PhysicalDeviceFragmentShaderBarycentricFeaturesNV = PhysicalDeviceFragmentShaderBarycentricFeaturesNV {}
- type NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION = 1
- pattern NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION :: forall a. Integral a => a
- type NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME = "VK_NV_fragment_shader_barycentric"
- pattern NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
Documentation
data PhysicalDeviceFragmentShaderBarycentricFeaturesNV Source #
VkPhysicalDeviceFragmentShaderBarycentricFeaturesNV - Structure describing barycentric support in fragment shaders that can be supported by an implementation
Members
This structure describes the following feature:
Description
See Barycentric Interpolation for more information.
If the PhysicalDeviceFragmentShaderBarycentricFeaturesNV
structure is
included in the pNext
chain of the
PhysicalDeviceFeatures2
structure passed to
getPhysicalDeviceFeatures2
,
it is filled in to indicate whether each corresponding feature is
supported. PhysicalDeviceFragmentShaderBarycentricFeaturesNV
can
also be used in the pNext
chain of
DeviceCreateInfo
to selectively enable these
features.
Valid Usage (Implicit)
See Also
Instances
pattern NV_FRAGMENT_SHADER_BARYCENTRIC_SPEC_VERSION :: forall a. Integral a => a Source #
type NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME = "VK_NV_fragment_shader_barycentric" Source #
pattern NV_FRAGMENT_SHADER_BARYCENTRIC_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #