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