1  include::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  
 14  This extension introduces the possibility for the application to control the
 15  order of primitive rasterization.
 16  In unextended Vulkan, the following stages are guaranteed to execute in _API
 17  order_:
 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  
 25  This extension enables applications to opt into a relaxed, implementation
 26  defined primitive rasterization order that may allow better parallel
 27  processing of primitives and thus enabling higher primitive throughput.
 28  It is applicable in cases where the primitive rasterization order is known
 29  to not affect the output of the rendering or any differences caused by a
 30  different rasterization order are not a concern from the point of view of
 31  the application's purpose.
 32  
 33  A few examples of cases when using the relaxed primitive rasterization order
 34  would 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  
 47  None
 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  
 64  None
 65  
 66  === Issues
 67  
 68  1) How is this extension useful to application developers?
 69  
 70  *RESOLVED*: Allows them to increase primitive throughput for cases when
 71  strict API order rasterization is not important due to the nature of the
 72  content, the configuration used, or the requirements towards the output of
 73  the rendering.
 74  
 75  2) How does this extension interact with content optimizations aiming to
 76  reduce overdraw by appropriately ordering the input primitives?
 77  
 78  *RESOLVED*: While the relaxed rasterization order might somewhat limit the
 79  effectiveness of such content optimizations, most of the benefits of it are
 80  expected to be retained even when the relaxed rasterization order is used,
 81  so applications should: still apply these optimizations even if they intend
 82  to use the extension.
 83  
 84  3) Are there any guarantees about the primitive rasterization order when
 85  using the new relaxed mode?
 86  
 87  *RESOLVED*: No.
 88  In this case the rasterization order is completely implementation dependent,
 89  but in practice it is expected to partially still follow the order of
 90  incoming primitives.
 91  
 92  4) Does the new relaxed rasterization order have any adverse effect on
 93  repeatability and other invariance rules of the API?
 94  
 95  *RESOLVED*: Yes, in the sense that it extends the list of exceptions when
 96  the repeatability requirement does not apply.
 97  
 98  === Examples
 99  
100  None
101  
102  === Issues
103  
104  None
105  
106  === Version History
107  
108    * Revision 1, 2016-04-25 (Daniel Rakos)
109      - Initial draft.