// 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 doesn't 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._