1------------------------------------------------------------------------- 2drawElements Quality Program Test Specification 3----------------------------------------------- 4 5Copyright 2014 The Android Open Source Project 6 7Licensed under the Apache License, Version 2.0 (the "License"); 8you may not use this file except in compliance with the License. 9You may obtain a copy of the License at 10 11 http://www.apache.org/licenses/LICENSE-2.0 12 13Unless required by applicable law or agreed to in writing, software 14distributed under the License is distributed on an "AS IS" BASIS, 15WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 16See the License for the specific language governing permissions and 17limitations under the License. 18------------------------------------------------------------------------- 19 Basic tessellation tests 20 21Tests: 22 + dEQP-GLES31.functional.tessellation.* 23 24Includes: 25 + Tessellation UVW coordinate verification 26 - Coordinates read with transform feedback (with point_mode) 27 - Triangles, quads, isolines 28 - equal_spacing 29 - fractional_odd_spacing and fractional_even_spacing with tessellation 30 levels chosen so that results are not implementation-dependent 31 + Separate verification of fractional spacing modes 32 + Winding modes (cw, ccw) 33 + Built-in inputs and outputs and basic data transfer between TCS and TES 34 - Read gl_PrimitiveID, gl_PatchVerticesIn in both TCS and TES 35 - Read gl_TessLevelInner[] and gl_TessLevelOuter[] in TES 36 - Differing input and output patch sizes 37 - Pass data in (gl_in/gl_out []) .gl_Position between VS, TCS and TES 38 - Basic barrier usage 39 + Rendering result sanity verification 40 - Check for no obvious gaps or overlaps in tessellation triangulation for 41 quads and triangles modes 42 - Isolines rendering 43 + Test for absence of cracks at shared edges of primitives 44 - Use either the 'precise' qualifier or carefully chosen primitive 45 orientations 46 + Test that patches are discarded when appropriate 47 + Invariance rule testing 48 + Passing per-patch and per-vertex simple and aggregate user-defined data 49 from TCS to TES 50 - Arrays, structs and interface blocks 51 - Omit vertex IO array size expression, or use gl_MaxPatchVertices or 52 an integer literal (queried from GL_MAX_PATCH_VERTICES) 53 54Excludes: 55 + Complete checking of validity of the filling triangles in the triangles and 56 quads modes 57 + Negative testing 58 59Description: 60 61The tessellation test group contains various cases testing basic tessellation 62shader functionality. 63 64The tessellation coordinate (gl_TessCoord) verification cases draw the vertices 65of a tessellated "triangles", "quads" or "isolines" shape using the 66"point_mode" input layout qualifier in the tessellation evaluation shader (TES). 67The vertices are read with transform feedback, and the results are compared to a 68point set generated by a reference tessellation vertex generator, verifying that 69for each point in the reference set, there is an approximately equal point in 70the GL-generated set, and vice versa. There is a small difference allowed in all 71comparisons, and thus not all rules are exactly verified (such as 72x + (1.0-x) == 1.0 for a given uvw coordinate x). The cases draw multiple times 73with different tessellation levels. 74 75The tests for the fractional spacing modes (fractional_odd_spacing, 76fractional_even_spacing) draw multiple simple isolines (with point_mode), each 77resulting in a row of vertices. These vertices are read with transform feedback 78and their x coordinates are inspected to see whether the edge is split into 79valid segments. The conditions for the amount, length and location of the two 80"additional segments", as laid out in the specification, are checked. The 81segment sets produced by different isolines are also compared to each other to 82determine whether the implementation fulfills the requirement of monotonic 83segment length growth, and the requirement that two edges with identical clamped 84tessellation levels have identically-located segments. 85 86The winding mode cases draw triangles or quads with a specific winding mode 87("cw" or "ccw") input layout qualifier in the TES. Back face culling is enabled. 88Each case draws two times, with glFrontFace(GL_CCW) and glFrontFace(GL_CW), and 89verifies that the primitive is drawn iff the glFrontFace value matches the 90winding mode specified in the TES. The patterns drawn are simple and verified by 91counting background-colored and non-background-colored pixels. 92 93The cases testing gl_PrimitiveID and gl_PatchVerticesIn read the variable in 94either TCS or TES; the TCS cases pass the value as a "patch out" output to the 95TES. For the gl_PrimitiveID cases, multiple primitives are drawn and one of 96them, with gl_PrimitiveID matching a specific value, is drawn with a differing 97color; for the gl_PatchVerticesIn cases, just one primitive is drawn and the 98value of gl_PatchVerticesIn is verified. The "quads" mode is used. 99 100The gl_TessLevelInner[] and gl_TessLevelOuter[] cases simply verify that reading 101the value of a tessellation level in the TES gives the value set in the TCS. The 102arrays are indexed with literals. The "quads" mode is used. 103 104The cases testing differing input and output patch sizes draw a simple shape 105using an output patch size either less or greater than the input patch size. The 106"quads" mode is used. 107 108The barrier case uses both per-patch and per-vertex TCS output variables, 109doing simple assignments and reads with them in different barrier()-separated 110stages. The "quads" mode is used. 111 112For the above-mentioned cases, the gl_PrimitiveID cases, the barrier case, and 113the cases with differing input and output patch sizes are verified with 114comparisons to pre-computed reference images; the gl_PatchVerticesIn and 115gl_TessLevel*[] cases draw simple all-white patterns and are verified as such. 116 117The basic rendering cases for the "triangles" and "quads" modes contain two 118types of cases: cases testing that there are no obvious gaps in the 119triangle-filled area, and cases testing that there are no overlaps between 120triangles of differing inner layers of the tessellated primitive. The gap cases 121draw a single primitive deformed so as to reveal possible errors in the 122triangulation. The overlap cases draw a single primitive with different colors 123for different concentric triangles (for the "triangles" mode) or concentric 124rectangles (for the "quads" mode); the coloring is done so as to make it visible 125if a fill-triangle spans between inappropriate inner triangles or rectangles. 126Basic cases verifying the rendering results of isolines also exist; the cases 127draw curly isolines with different colors for different vertices. 128The above cases are repeated for different spacing modes. The results of the 129rendering cases are compared to pre-computed reference images. 130 131The shared-edge cases draw multiple primitives (with the "triangles" or "quads" 132mode) that have shared edges, and check that no cracks appear at the edges. For 133each pair of primitives sharing an edge, that edge has the same tessellation 134level for both primitives. The primitives are deformed in the TES so that 135potential cracks are likely to become visible. The resulting image is verified 136by checking that no pixel (inside a fixed rectangle) remains uncovered by a 137primitive. Two variants exist, with different methods for avoiding cracks: 138either the 'precise' qualifier is used in the tessellation shaders, or input 139patches are generated in a way that causes each shared vertex to have the same 140index in all the primitives it belongs to. 141 142The patch-discarding tests draw multiple patches in one draw call, with 143different combinations for tessellation levels; some of these patches contain 144relevant outer tessellation levels with a negative or zero value; they should 145be discarded. Verification is done firstly by a sanity check that the number of 146vertices returned by transform feedback is correct, and secondly by checking 147that white primitives exist in the area where non-discarded primitives are 148drawn, and only there. 149 150The invariance tests target the 8 invariance rules laid out in the 151specification. They render one or more primitives with various tessellation 152levels and/or programs with different configurations, read the primitives with 153transform feedback, and do appropriate comparisons or other validation. 154 155The tessellation coordinate generation is somewhat implementation-dependent when 156using a fractional spacing mode and a tessellation level that isn't already 157properly rounded. In many of the cases using a spacing mode other than 158equal_spacing, the tessellation levels are chosen in a way that makes the 159results non-implementation-dependent. 160 161The exact manner in which a "triangles" or "quads" primitive is divided into 162triangles is also implementation-dependent and is not thoroughly tested. 163 164More complete checking of final triangle generation are possible candidates for 165future tests. 166