Safe Haskell | Safe-Inferred |
---|---|
Language | Haskell2010 |
Name
VK_AMD_rasterization_order - device extension
VK_AMD_rasterization_order
- Name String
VK_AMD_rasterization_order
- Extension Type
- Device extension
- Registered Extension Number
- 19
- Revision
- 1
- Ratification Status
- Not ratified
- Extension and Version Dependencies; Contact
Other Extension Metadata
- Last Modified Date
- 2016-04-25
- IP Status
- No known IP claims.
- Contributors
- Matthaeus G. Chajdas, AMD
- Jaakko Konttinen, AMD
- Daniel Rakos, AMD
- Graham Sellers, AMD
- Dominik Witczak, AMD
Description
This extension introduces the possibility for the application to control the order of primitive rasterization. In unextended Vulkan, the following stages are guaranteed to execute in API order:
- depth bounds test
- stencil test, stencil op, and stencil write
- depth test and depth write
- occlusion queries
- blending, logic op, and color write
This extension enables applications to opt into a relaxed, implementation defined primitive rasterization order that may allow better parallel processing of primitives and thus enabling higher primitive throughput. It is applicable in cases where the primitive rasterization order is known to not affect the output of the rendering or any differences caused by a different rasterization order are not a concern from the point of view of the application’s purpose.
A few examples of cases when using the relaxed primitive rasterization order would not have an effect on the final rendering:
- If the primitives rendered are known to not overlap in framebuffer space.
- If depth testing is used with a comparison operator of
COMPARE_OP_LESS
,COMPARE_OP_LESS_OR_EQUAL
,COMPARE_OP_GREATER
, orCOMPARE_OP_GREATER_OR_EQUAL
, and the primitives rendered are known to not overlap in clip space. - If depth testing is not used and blending is enabled for all attachments with a commutative blend operator.
New Structures
New Enums
New Enum Constants
Issues
1) How is this extension useful to application developers?
RESOLVED: Allows them to increase primitive throughput for cases when strict API order rasterization is not important due to the nature of the content, the configuration used, or the requirements towards the output of the rendering.
2) How does this extension interact with content optimizations aiming to reduce overdraw by appropriately ordering the input primitives?
RESOLVED: While the relaxed rasterization order might somewhat limit the effectiveness of such content optimizations, most of the benefits of it are expected to be retained even when the relaxed rasterization order is used, so applications should still apply these optimizations even if they intend to use the extension.
3) Are there any guarantees about the primitive rasterization order when using the new relaxed mode?
RESOLVED: No. In this case the rasterization order is completely implementation-dependent, but in practice it is expected to partially still follow the order of incoming primitives.
4) Does the new relaxed rasterization order have any adverse effect on repeatability and other invariance rules of the API?
RESOLVED: Yes, in the sense that it extends the list of exceptions when the repeatability requirement does not apply.
Examples
None
Issues
None
Version History
Revision 1, 2016-04-25 (Daniel Rakos)
- Initial draft.
See Also
PipelineRasterizationStateRasterizationOrderAMD
,
RasterizationOrderAMD
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 PipelineRasterizationStateRasterizationOrderAMD = PipelineRasterizationStateRasterizationOrderAMD {}
- newtype RasterizationOrderAMD where
- type AMD_RASTERIZATION_ORDER_SPEC_VERSION = 1
- pattern AMD_RASTERIZATION_ORDER_SPEC_VERSION :: forall a. Integral a => a
- type AMD_RASTERIZATION_ORDER_EXTENSION_NAME = "VK_AMD_rasterization_order"
- pattern AMD_RASTERIZATION_ORDER_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
Documentation
data PipelineRasterizationStateRasterizationOrderAMD Source #
VkPipelineRasterizationStateRasterizationOrderAMD - Structure defining rasterization order for a graphics pipeline
Valid Usage (Implicit)
If the VK_AMD_rasterization_order
device extension is not enabled or
the application does not request a particular rasterization order
through specifying a PipelineRasterizationStateRasterizationOrderAMD
structure then the rasterization order used by the graphics pipeline
defaults to RASTERIZATION_ORDER_STRICT_AMD
.
See Also
VK_AMD_rasterization_order,
RasterizationOrderAMD
,
StructureType
PipelineRasterizationStateRasterizationOrderAMD | |
|
Instances
newtype RasterizationOrderAMD Source #
VkRasterizationOrderAMD - Specify rasterization order for a graphics pipeline
See Also
VK_AMD_rasterization_order,
PipelineRasterizationStateRasterizationOrderAMD
pattern RASTERIZATION_ORDER_STRICT_AMD :: RasterizationOrderAMD |
|
pattern RASTERIZATION_ORDER_RELAXED_AMD :: RasterizationOrderAMD |
|
Instances
type AMD_RASTERIZATION_ORDER_SPEC_VERSION = 1 Source #
pattern AMD_RASTERIZATION_ORDER_SPEC_VERSION :: forall a. Integral a => a Source #
type AMD_RASTERIZATION_ORDER_EXTENSION_NAME = "VK_AMD_rasterization_order" Source #
pattern AMD_RASTERIZATION_ORDER_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #