mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-02-28 14:00:27 +00:00
95dd2f34c5
* Bump API patch number and header version number to 28 for this update.
Github Issues:
* Minor spelling and typography cleanup, add definitions of
ename:VK_FALSE and ename:VK_TRUE as just what their names say
(public issues 220, 318, 325, 365; internal issues 451, 496)
* Clarify that the pname:maxDescriptorSet limits in the
<<features-limits-required,Required Limits>> table are n *
maxPerStage limit (where n=number of supported stages) (public issue
254).
* Minor cleanup to <<boilerplate-platform-macros,Platform-Specific
Macro Definitions>> appendix (public issue 314).
* Add valid usage statement to slink:VkPipelineLayoutCreateInfo
disallowing multiple push constant ranges for the same shader stage
(public issue 340).
* Clarify the elink:VkSharingMode description of what executing the
"same" barriers means in case of ownership transfer (public issue
347).
* Rename copyright.txt and add COPYING.md to try and reduce confusion
about applicable copyrights (public issue 350).
* Extend the table in the <<boilerplate-wsi-header, Window System-Specific
Header Control>> section to describe the external headers included when
each etext:VK_USE_PLATFORM_* macro is defined (public issue 376).
Internal Issues:
* Add "Revision History" to the PDF outputs following the table of
contents, to match HTML outputs (internal issue 43).
* Clarified that flink:vkMapMemory may fail due to virtual address
space limitations (internal issue 346).
* Add +refBody+ comment markup for ref page autoextraction when required
(internal issue 400).
* Document proper use of "mipmap" and "mip" in the style guide API
naming rules, matching the spelling rules (internal issue 471).
* Tweak the <<extensions,Layers and Extensions>> appendix to note that
the Specification may be built with arbitrary combinations of
extensions (internal issue 483).
* Remove incorrect statement allowing
slink:VkClearAttachment::pname:colorAttachment to be >=
slink:VkSubpassDescription::pname:colorAttachmentCount (internal
issue 488).
* The <<features-limits-viewportboundsrange,viewportBoundsRange>> is
expressed in terms of the pname:maxViewportDimensions but this is
actually two values. Clarify that it's based on the larger of the two
(if they differ) (internal issue 499).
Other Issues:
* Reflowed text of the entire spec using the 'reflow' Makefile gater,
to (hopefully) reduce future internal git churn as edits are made
and extensions added in return for one-time pain. This has no
perceptible change on the spec outputs but considerable changes on
the asciidoc source (internal issue 367).
124 lines
3.7 KiB
Plaintext
124 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.
|