doc/testspecs/GLES31/functional.tessellation.txt - third_party/vulkan-cts - Git at Google

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