mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-10 13:26:32 +00:00
ef053e7c82
* Bump API patch number and header version number to 27 for this update.
Github Issues:
* Weaken flink:vkGetPipelineCacheData invariance conditions; previous
conditions were stronger than agreed and can't be guaranteed (public
issue 280).
* Add link to "Vulkan Loader Specification and Architecture Overview"
document to Normative References section (public issue 359).
Internal Issues:
* Be more clear in the <<interfaces-resources-layout-std140, uniform
buffer layout>> section that block offsets can be out of order
(internal issue 396).
* Document that extension authors should add support for their extensions
to the validation layers (internal issue 398).
* Clarify that the valid range of depth clear values should be limited
to the 0..1 range and that copies to depth aspect must also be in this
range (internal issue 412).
* Specify ``a'' vs. ``an'' use in the style guide (internal issue 432).
* Increase the maximum pname:nonCoherentAtomSize value in the
<<features-limits-required,Required Limits>> section from 128 to 256
(internal issue 435).
* Fix vk_platform.h for compiler errors on some Android platforms
(internal issue 441).
* Clarify that slink:VkPhysicalDeviceFeatures::pname:pEnabledFeatures ==
`NULL` disables all features, including the "required" feature
pname:robustBufferAccess (internal issue 479).
Other Issues:
* Expand style guide and make it more self-consistent.
* Use ISO 8601 date format everywhere.
* Emphasise the correct way of using
slink:VkSurfaceCapabilitiesKHR::pname:maxImageCount.
* Added +VK_EXT_validation_flags+ extension for validation flag mechanism.
* Fix an <<credits,author credit>> to include their current employer.
119 lines
3.7 KiB
Plaintext
119 lines
3.7 KiB
Plaintext
[[VK_AMD_rasterization_order]]
|
|
== VK_AMD_rasterization_order
|
|
|
|
*Name String*::
|
|
VK_AMD_rasterization_order
|
|
*Extension Type*::
|
|
Device extension
|
|
*Registered Extension Number*::
|
|
19
|
|
*Last Modified Date*::
|
|
2016-04-25
|
|
*Revision*::
|
|
1
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Dependencies*::
|
|
- This extension is written against version 1.0.11 of the Vulkan API.
|
|
*Contributors*::
|
|
- Matthaeus G. Chajdas, AMD
|
|
- Jaakko Konttinen, AMD
|
|
- Daniel Rakos, AMD
|
|
- Graham Sellers, AMD
|
|
- Dominik Witczak, AMD
|
|
*Contacts*::
|
|
- Daniel Rakos, AMD
|
|
|
|
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
|
|
ename:VK_COMPARE_OP_LESS, ename:VK_COMPARE_OP_LESS_OR_EQUAL,
|
|
ename:VK_COMPARE_OP_GREATER, or ename:VK_COMPARE_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 Object Types
|
|
|
|
None
|
|
|
|
=== New Enum Constants
|
|
|
|
* Extending elink:VkStructureType:
|
|
** ename:VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD
|
|
|
|
=== New Enums
|
|
|
|
* elink:VkRasterizationOrderAMD
|
|
|
|
=== New Structures
|
|
|
|
* slink:VkPipelineRasterizationStateRasterizationOrderAMD
|
|
|
|
=== New Functions
|
|
|
|
None
|
|
|
|
=== 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 are still recommended to 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. The rasterization order is completely implementation
|
|
dependent in this case 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.
|