209 lines
10 KiB
Plaintext
209 lines
10 KiB
Plaintext
// Copyright (c) 2015-2016 The Khronos Group Inc.
|
|
// Copyright notice at https://www.khronos.org/registry/speccopyright.html
|
|
|
|
[appendix]
|
|
= Invariance
|
|
|
|
The Vulkan specification is not pixel exact. It therefore does not
|
|
guarantee an exact match between images produced by different Vulkan
|
|
implementations. However, the specification does specify exact matches, in
|
|
some cases, for images produced by the same implementation. The purpose of
|
|
this appendix is to identify and provide justification for those cases that
|
|
require exact matches.
|
|
|
|
== Repeatability
|
|
|
|
The obvious and most fundamental case is repeated issuance of a series of
|
|
Vulkan commands. For any given Vulkan and framebuffer state vector,
|
|
and for any Vulkan command, the resulting Vulkan and framebuffer state
|
|
must: be identical whenever the command is executed on that initial
|
|
Vulkan and framebuffer state. This repeatability requirement does not
|
|
apply when using shaders containing side effects (image and buffer variable
|
|
stores and atomic operations), because these memory operations are not
|
|
guaranteed to be processed in a defined order.
|
|
|
|
One purpose of repeatability is avoidance of visual artifacts when a
|
|
doublebuffered scene is redrawn. If rendering is not repeatable, swapping
|
|
between two buffers rendered with the same command sequence may: result in
|
|
visible changes in the image. Such false motion is distracting to the
|
|
viewer. Another reason for repeatability is testability.
|
|
|
|
Repeatability, while important, is a weak requirement. Given only
|
|
repeatability as a requirement, two scenes rendered with one (small) polygon
|
|
changed in position might differ at every pixel. Such a difference, while
|
|
within the law of repeatability, is certainly not within its spirit.
|
|
Additional invariance rules are desirable to ensure useful operation.
|
|
|
|
|
|
== Multi-pass Algorithms
|
|
|
|
Invariance is necessary for a whole set of useful multi-pass algorithms.
|
|
Such algorithms render multiple times, each time with a different Vulkan
|
|
mode vector, to eventually produce a result in the framebuffer. Examples of
|
|
these algorithms include:
|
|
|
|
* ``Erasing'' a primitive from the framebuffer by redrawing it, either in
|
|
a different color or using the XOR logical operation.
|
|
* Using stencil operations to compute capping planes.
|
|
|
|
|
|
== Invariance Rules
|
|
|
|
For a given instantiation of an Vulkan rendering context:
|
|
|
|
*Rule 1* _For any given Vulkan and framebuffer state vector, and for any
|
|
given Vulkan command, the resulting Vulkan and framebuffer state must:
|
|
be identical each time the command is executed on that initial Vulkan and
|
|
framebuffer state._
|
|
|
|
*Rule 2* _Changes to the following state values have no side effects (the
|
|
use of any other state value is not affected by the change):_
|
|
|
|
*Required:*
|
|
|
|
* _Framebuffer contents (all bitplanes)_
|
|
* _The color buffers enabled for writing_
|
|
* _Scissor parameters (other than enable)_
|
|
* _Writemasks (color, depth, stencil)_
|
|
* _Clear values (color, depth, stencil)_
|
|
|
|
*Strongly suggested:*
|
|
|
|
* _Stencil Parameters (other than enable)_
|
|
* _Depth test parameters (other than enable)_
|
|
* _Blend parameters (other than enable)_
|
|
* _Logical operation parameters (other than enable)_
|
|
* _Pixel storage state_
|
|
|
|
*Corollary 1* _Fragment generation is invariant with respect to the state
|
|
values listed in Rule 2._
|
|
|
|
*Rule 3* _The arithmetic of each per-fragment operation is invariant except
|
|
with respect to parameters that directly control it._
|
|
|
|
*Corollary 2* _Images rendered into different color buffers sharing the same
|
|
framebuffer, either simultaneously or separately using the same command
|
|
sequence, are pixel identical._
|
|
|
|
*Rule 4* _The same vertex or fragment shader will produce the same result
|
|
when run multiple times with the same input. The wording ``the same shader''
|
|
means a program object that is populated with the same SPIR-V binary, which
|
|
is used to create pipelines, possibly multiple times, and which program
|
|
object is then executed using the same Vulkan state vector. Invariance is
|
|
relaxed for shaders with side effects, such as performing stores or
|
|
atomics._
|
|
|
|
*Rule 5* _All fragment shaders that either conditionally or unconditionally
|
|
assign_ code:FragCoord.z _to_ code:FragDepth _are depth-invariant with
|
|
respect to each other, for those fragments where the assignment to_
|
|
code:FragDepth _actually is done._
|
|
|
|
If a sequence of Vulkan commands specifies primitives to be rendered with
|
|
shaders containing side effects (image and buffer variable stores and atomic
|
|
operations), invariance rules are relaxed. In particular, rule 1, corollary
|
|
2, and rule 4 do not apply in the presence of shader side effects.
|
|
|
|
The following weaker versions of rules 1 and 4 apply to Vulkan commands
|
|
involving shader side effects:
|
|
|
|
*Rule 6* _For any given Vulkan and framebuffer state vector, and for any
|
|
given Vulkan command, the contents of any framebuffer state not directly
|
|
or indirectly affected by results of shader image or buffer variable stores
|
|
or atomic operations must: be identical each time the command is executed on
|
|
that initial Vulkan and framebuffer state._
|
|
|
|
*Rule 7* _The same vertex or fragment shader will produce the same result
|
|
when run multiple times with the same input as long as:_
|
|
|
|
* _shader invocations do not use image atomic operations;_
|
|
* _no framebuffer memory is written to more than once by image stores,
|
|
unless all such stores write the same value; and_
|
|
* _no shader invocation, or other operation performed to process the
|
|
sequence of commands, reads memory written to by an image store._
|
|
|
|
When any sequence of Vulkan commands triggers shader invocations that
|
|
perform image stores or atomic operations, and subsequent Vulkan commands
|
|
read the memory written by those shader invocations, these operations must:
|
|
be explicitly synchronized.
|
|
|
|
|
|
== Tessellation Invariance
|
|
|
|
When using a program containing tessellation evaluation shaders, the
|
|
fixed-function tessellation primitive generator consumes the input patch
|
|
specified by an application and emits a new set of primitives. The following
|
|
invariance rules are intended to provide repeatability guarantees.
|
|
Additionally, they are intended to allow an application with a carefully
|
|
crafted tessellation evaluation shader to ensure that the sets of triangles
|
|
generated for two adjacent patches have identical vertices along shared
|
|
patch edges, avoiding ``cracks'' caused by minor differences in the
|
|
positions of vertices along shared edges.
|
|
|
|
*Rule 1* _When processing two patches with identical outer and inner
|
|
tessellation levels, the tessellation primitive generator will emit an
|
|
identical set of point, line, or triangle primitives as long as the active
|
|
program used to process the patch primitives has tessellation evaluation
|
|
shaders specifying the same tessellation mode, spacing, vertex order, and
|
|
point mode decorations. Two sets of primitives are considered identical if
|
|
and only if they contain the same number and type of primitives and the
|
|
generated tessellation coordinates for the vertex numbered m of the
|
|
primitive numbered n are identical for all values of m and n._
|
|
|
|
*Rule 2* _The set of vertices generated along the outer edge of the
|
|
subdivided primitive in triangle and quad tessellation, and the tessellation
|
|
coordinates of each, depends only on the corresponding outer tessellation
|
|
level and the spacing decorations in the tessellation shaders of the
|
|
pipeline._
|
|
|
|
*Rule 3* _The set of vertices generated when subdividing any outer primitive
|
|
edge is always symmetric. For triangle tessellation, if the subdivision
|
|
generates a vertex with tessellation coordinates of the form (0, x, 1-x),
|
|
(x, 0, 1-x), or (x, 1-x, 0), it will also generate a vertex with coordinates
|
|
of exactly (0, 1-x, x), (1-x, 0, x), or (1-x, x, 0), respectively. For quad
|
|
tessellation, if the subdivision generates a vertex with coordinates of (x,
|
|
0) or (0, x), it will also generate a vertex with coordinates of exactly
|
|
(1-x, 0) or (0, 1-x), respectively. For isoline tessellation, if it
|
|
generates vertices at (0, x) and (1, x) where x is not zero, it will also
|
|
generate vertices at exactly (0, 1-x) and (1, 1-x), respectively._
|
|
|
|
*Rule 4* _The set of vertices generated when subdividing outer edges in
|
|
triangular and quad tessellation must: be independent of the specific edge
|
|
subdivided, given identical outer tessellation levels and spacing. For
|
|
example, if vertices at (x, 1 - x, 0) and (1-x, x, 0) are generated when
|
|
subdividing the w = 0 edge in triangular tessellation, vertices must: be
|
|
generated at (x, 0, 1-x) and (1-x, 0, x) when subdividing an otherwise
|
|
identical v = 0 edge. For quad tessellation, if vertices at (x, 0) and
|
|
(1-x, 0) are generated when subdividing the v = 0 edge, vertices must: be
|
|
generated at (0, x) and (0, 1-x) when subdividing an otherwise identical
|
|
u = 0 edge._
|
|
|
|
*Rule 5* _When processing two patches that are identical in all respects
|
|
enumerated in rule 1 except for vertex order, the set of triangles generated
|
|
for triangle and quad tessellation must: be identical except for vertex and
|
|
triangle order. For each triangle n1 produced by processing the first patch,
|
|
there must: be a triangle n2 produced when processing the second patch each
|
|
of whose vertices has the same tessellation coordinates as one of the
|
|
vertices in n1._
|
|
|
|
*Rule 6* _When processing two patches that are identical in all respects
|
|
enumerated in rule 1 other than matching outer tessellation levels and/or
|
|
vertex order, the set of interior triangles generated for triangle and quad
|
|
tessellation must: be identical in all respects except for vertex and
|
|
triangle order. For each interior triangle n1 produced by processing the
|
|
first patch, there must: be a triangle n2 produced when processing the
|
|
second patch each of whose vertices has the same tessellation coordinates as
|
|
one of the vertices in n1. A triangle produced by the tessellator is
|
|
considered an interior triangle if none of its vertices lie on an outer edge
|
|
of the subdivided primitive._
|
|
|
|
*Rule 7* _For quad and triangle tessellation, the set of triangles
|
|
connecting an inner and outer edge depends only on the inner and outer
|
|
tessellation levels corresponding to that edge and the spacing decorations._
|
|
|
|
*Rule 8* _The value of all defined components of_ code:TessCoord
|
|
_will be in the range [0, 1]. Additionally, for any defined component x of_
|
|
code:TessCoord, _the results of computing 1.0-x in a tessellation
|
|
evaluation shader will be exact. If any floating-point values in the range
|
|
[0, 1] fail to satisfy this property, such values mustnot: be used as
|
|
tessellation coordinate components._
|