| include::meta/VK_AMD_rasterization_order.txt[] |
| |
| *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 |
| |
| 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 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. |