1// Copyright (c) 2016-2020 Advanced Micro Devices, Inc. 2// 3// SPDX-License-Identifier: CC-BY-4.0 4 5include::{generated}/meta/{refprefix}VK_AMD_rasterization_order.adoc[] 6 7=== Other Extension Metadata 8 9*Last Modified Date*:: 10 2016-04-25 11*IP Status*:: 12 No known IP claims. 13*Contributors*:: 14 - Matthaeus G. Chajdas, AMD 15 - Jaakko Konttinen, AMD 16 - Daniel Rakos, AMD 17 - Graham Sellers, AMD 18 - Dominik Witczak, AMD 19 20=== Description 21 22This extension introduces the possibility for the application to control the 23order of primitive rasterization. 24In unextended Vulkan, the following stages are guaranteed to execute in _API 25order_: 26 27 * depth bounds test 28 * stencil test, stencil op, and stencil write 29 * depth test and depth write 30 * occlusion queries 31 * blending, logic op, and color write 32 33This extension enables applications to opt into a relaxed, implementation 34defined primitive rasterization order that may allow better parallel 35processing of primitives and thus enabling higher primitive throughput. 36It is applicable in cases where the primitive rasterization order is known 37to not affect the output of the rendering or any differences caused by a 38different rasterization order are not a concern from the point of view of 39the application's purpose. 40 41A few examples of cases when using the relaxed primitive rasterization order 42would not have an effect on the final rendering: 43 44 * If the primitives rendered are known to not overlap in framebuffer 45 space. 46 * If depth testing is used with a comparison operator of 47 ename:VK_COMPARE_OP_LESS, ename:VK_COMPARE_OP_LESS_OR_EQUAL, 48 ename:VK_COMPARE_OP_GREATER, or ename:VK_COMPARE_OP_GREATER_OR_EQUAL, 49 and the primitives rendered are known to not overlap in clip space. 50 * If depth testing is not used and blending is enabled for all attachments 51 with a commutative blend operator. 52 53include::{generated}/interfaces/VK_AMD_rasterization_order.adoc[] 54 55=== Issues 56 571) How is this extension useful to application developers? 58 59*RESOLVED*: Allows them to increase primitive throughput for cases when 60strict API order rasterization is not important due to the nature of the 61content, the configuration used, or the requirements towards the output of 62the rendering. 63 642) How does this extension interact with content optimizations aiming to 65reduce overdraw by appropriately ordering the input primitives? 66 67*RESOLVED*: While the relaxed rasterization order might somewhat limit the 68effectiveness of such content optimizations, most of the benefits of it are 69expected to be retained even when the relaxed rasterization order is used, 70so applications should: still apply these optimizations even if they intend 71to use the extension. 72 733) Are there any guarantees about the primitive rasterization order when 74using the new relaxed mode? 75 76*RESOLVED*: No. 77In this case the rasterization order is completely implementation-dependent, 78but in practice it is expected to partially still follow the order of 79incoming primitives. 80 814) Does the new relaxed rasterization order have any adverse effect on 82repeatability and other invariance rules of the API? 83 84*RESOLVED*: Yes, in the sense that it extends the list of exceptions when 85the repeatability requirement does not apply. 86 87=== Examples 88 89None 90 91=== Issues 92 93None 94 95=== Version History 96 97 * Revision 1, 2016-04-25 (Daniel Rakos) 98 ** Initial draft. 99