// Copyright (c) 2016-2020 Advanced Micro Devices, Inc.
//
// SPDX-License-Identifier: CC-BY-4.0

include::{generated}/meta/{refprefix}VK_AMD_rasterization_order.txt[]

=== Other Extension Metadata

*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

=== Description

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.

include::{generated}/interfaces/VK_AMD_rasterization_order.txt[]

=== 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.