| ------------------------------------------------------------------------- |
| drawElements Quality Program Test Specification |
| ----------------------------------------------- |
| |
| Copyright 2014 The Android Open Source Project |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| ------------------------------------------------------------------------- |
| Basic tessellation tests |
| |
| Tests: |
| + dEQP-GLES31.functional.tessellation.* |
| |
| Includes: |
| + Tessellation UVW coordinate verification |
| - Coordinates read with transform feedback (with point_mode) |
| - Triangles, quads, isolines |
| - equal_spacing |
| - fractional_odd_spacing and fractional_even_spacing with tessellation |
| levels chosen so that results are not implementation-dependent |
| + Separate verification of fractional spacing modes |
| + Winding modes (cw, ccw) |
| + Built-in inputs and outputs and basic data transfer between TCS and TES |
| - Read gl_PrimitiveID, gl_PatchVerticesIn in both TCS and TES |
| - Read gl_TessLevelInner[] and gl_TessLevelOuter[] in TES |
| - Differing input and output patch sizes |
| - Pass data in (gl_in/gl_out []) .gl_Position between VS, TCS and TES |
| - Basic barrier usage |
| + Rendering result sanity verification |
| - Check for no obvious gaps or overlaps in tessellation triangulation for |
| quads and triangles modes |
| - Isolines rendering |
| + Test for absence of cracks at shared edges of primitives |
| - Use either the 'precise' qualifier or carefully chosen primitive |
| orientations |
| + Test that patches are discarded when appropriate |
| + Invariance rule testing |
| + Passing per-patch and per-vertex simple and aggregate user-defined data |
| from TCS to TES |
| - Arrays, structs and interface blocks |
| - Omit vertex IO array size expression, or use gl_MaxPatchVertices or |
| an integer literal (queried from GL_MAX_PATCH_VERTICES) |
| |
| Excludes: |
| + Complete checking of validity of the filling triangles in the triangles and |
| quads modes |
| + Negative testing |
| |
| Description: |
| |
| The tessellation test group contains various cases testing basic tessellation |
| shader functionality. |
| |
| The tessellation coordinate (gl_TessCoord) verification cases draw the vertices |
| of a tessellated "triangles", "quads" or "isolines" shape using the |
| "point_mode" input layout qualifier in the tessellation evaluation shader (TES). |
| The vertices are read with transform feedback, and the results are compared to a |
| point set generated by a reference tessellation vertex generator, verifying that |
| for each point in the reference set, there is an approximately equal point in |
| the GL-generated set, and vice versa. There is a small difference allowed in all |
| comparisons, and thus not all rules are exactly verified (such as |
| x + (1.0-x) == 1.0 for a given uvw coordinate x). The cases draw multiple times |
| with different tessellation levels. |
| |
| The tests for the fractional spacing modes (fractional_odd_spacing, |
| fractional_even_spacing) draw multiple simple isolines (with point_mode), each |
| resulting in a row of vertices. These vertices are read with transform feedback |
| and their x coordinates are inspected to see whether the edge is split into |
| valid segments. The conditions for the amount, length and location of the two |
| "additional segments", as laid out in the specification, are checked. The |
| segment sets produced by different isolines are also compared to each other to |
| determine whether the implementation fulfills the requirement of monotonic |
| segment length growth, and the requirement that two edges with identical clamped |
| tessellation levels have identically-located segments. |
| |
| The winding mode cases draw triangles or quads with a specific winding mode |
| ("cw" or "ccw") input layout qualifier in the TES. Back face culling is enabled. |
| Each case draws two times, with glFrontFace(GL_CCW) and glFrontFace(GL_CW), and |
| verifies that the primitive is drawn iff the glFrontFace value matches the |
| winding mode specified in the TES. The patterns drawn are simple and verified by |
| counting background-colored and non-background-colored pixels. |
| |
| The cases testing gl_PrimitiveID and gl_PatchVerticesIn read the variable in |
| either TCS or TES; the TCS cases pass the value as a "patch out" output to the |
| TES. For the gl_PrimitiveID cases, multiple primitives are drawn and one of |
| them, with gl_PrimitiveID matching a specific value, is drawn with a differing |
| color; for the gl_PatchVerticesIn cases, just one primitive is drawn and the |
| value of gl_PatchVerticesIn is verified. The "quads" mode is used. |
| |
| The gl_TessLevelInner[] and gl_TessLevelOuter[] cases simply verify that reading |
| the value of a tessellation level in the TES gives the value set in the TCS. The |
| arrays are indexed with literals. The "quads" mode is used. |
| |
| The cases testing differing input and output patch sizes draw a simple shape |
| using an output patch size either less or greater than the input patch size. The |
| "quads" mode is used. |
| |
| The barrier case uses both per-patch and per-vertex TCS output variables, |
| doing simple assignments and reads with them in different barrier()-separated |
| stages. The "quads" mode is used. |
| |
| For the above-mentioned cases, the gl_PrimitiveID cases, the barrier case, and |
| the cases with differing input and output patch sizes are verified with |
| comparisons to pre-computed reference images; the gl_PatchVerticesIn and |
| gl_TessLevel*[] cases draw simple all-white patterns and are verified as such. |
| |
| The basic rendering cases for the "triangles" and "quads" modes contain two |
| types of cases: cases testing that there are no obvious gaps in the |
| triangle-filled area, and cases testing that there are no overlaps between |
| triangles of differing inner layers of the tessellated primitive. The gap cases |
| draw a single primitive deformed so as to reveal possible errors in the |
| triangulation. The overlap cases draw a single primitive with different colors |
| for different concentric triangles (for the "triangles" mode) or concentric |
| rectangles (for the "quads" mode); the coloring is done so as to make it visible |
| if a fill-triangle spans between inappropriate inner triangles or rectangles. |
| Basic cases verifying the rendering results of isolines also exist; the cases |
| draw curly isolines with different colors for different vertices. |
| The above cases are repeated for different spacing modes. The results of the |
| rendering cases are compared to pre-computed reference images. |
| |
| The shared-edge cases draw multiple primitives (with the "triangles" or "quads" |
| mode) that have shared edges, and check that no cracks appear at the edges. For |
| each pair of primitives sharing an edge, that edge has the same tessellation |
| level for both primitives. The primitives are deformed in the TES so that |
| potential cracks are likely to become visible. The resulting image is verified |
| by checking that no pixel (inside a fixed rectangle) remains uncovered by a |
| primitive. Two variants exist, with different methods for avoiding cracks: |
| either the 'precise' qualifier is used in the tessellation shaders, or input |
| patches are generated in a way that causes each shared vertex to have the same |
| index in all the primitives it belongs to. |
| |
| The patch-discarding tests draw multiple patches in one draw call, with |
| different combinations for tessellation levels; some of these patches contain |
| relevant outer tessellation levels with a negative or zero value; they should |
| be discarded. Verification is done firstly by a sanity check that the number of |
| vertices returned by transform feedback is correct, and secondly by checking |
| that white primitives exist in the area where non-discarded primitives are |
| drawn, and only there. |
| |
| The invariance tests target the 8 invariance rules laid out in the |
| specification. They render one or more primitives with various tessellation |
| levels and/or programs with different configurations, read the primitives with |
| transform feedback, and do appropriate comparisons or other validation. |
| |
| The tessellation coordinate generation is somewhat implementation-dependent when |
| using a fractional spacing mode and a tessellation level that isn't already |
| properly rounded. In many of the cases using a spacing mode other than |
| equal_spacing, the tessellation levels are chosen in a way that makes the |
| results non-implementation-dependent. |
| |
| The exact manner in which a "triangles" or "quads" primitive is divided into |
| triangles is also implementation-dependent and is not thoroughly tested. |
| |
| More complete checking of final triangle generation are possible candidates for |
| future tests. |