Google Git
Sign in
skia / external / github.com / KhronosGroup / OpenGL-Registry / 4de5113836d5cf7be76df40034d9137364e5fb1a / . / extensions / EXT / EXT_tessellation_shader.txt
blob: fb2487638b26e2c2eb8c2174954aa2e267f9fd8a [file] [log] [blame]
Name
EXT_tessellation_shader
Name Strings
GL_EXT_tessellation_shader
GL_EXT_tessellation_point_size
Contact
Jon Leech (oddhack 'at' sonic.net)
Daniel Koch, NVIDIA (dkoch 'at' nvidia.com)
Contributors
Daniel Koch, NVIDIA (dkoch 'at' nvidia.com)
Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
Bill Licea-Kane, Qualcomm (billl 'at' qti.qualcomm.com)
Jesse Hall, Google (jessehall 'at' google.com)
Dominik Witczak, Mobica
Jan-Harald Fredriksen, ARM
Maurice Ribble, Qualcomm
Vineet Goel, Qualcomm
Alex Chalfin, ARM
Graham Connor, Imagination
Ben Bowman, Imagination
Jonathan Putsman, Imagination
Slawomir Grajewski, Intel
Contributors to ARB_tessellation_shader
Notice
Copyright (c) 2010-2016 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Portions Copyright (c) 2013-2014 NVIDIA Corporation.
Status
Complete.
Version
Last Modified Date: December 10, 2018
Revision: 25
Number
OpenGL ES Extension #181
Dependencies
OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required.
This specification is written against the OpenGL ES 3.1 (March 17, 2014)
and OpenGL ES 3.10 Shading Language (March 17, 2014) Specifications.
EXT_geometry_shader is required in order to share language modifying the
OpenGL ES 3.1 specifications, which would otherwise have to be repeated
here.
EXT_shader_io_blocks is required.
EXT_gpu_shader5 is required.
This extension interacts with OES_shader_multisample_interpolation.
Overview
This extension introduces new tessellation stages and two new shader types
to the OpenGL ES primitive processing pipeline. These pipeline stages
operate on a new basic primitive type, called a patch. A patch consists
of a fixed-size collection of vertices, each with per-vertex attributes,
plus a number of associated per-patch attributes. Tessellation control
shaders transform an input patch specified by the application, computing
per-vertex and per-patch attributes for a new output patch. A
fixed-function tessellation primitive generator subdivides the patch, and
tessellation evaluation shaders are used to compute the position and
attributes of each vertex produced by the tessellator.
When tessellation is active, it begins by running the optional
tessellation control shader. This shader consumes an input patch and
produces a new fixed-size output patch. The output patch consists of an
array of vertices, and a set of per-patch attributes. The per-patch
attributes include tessellation levels that control how finely the patch
will be tessellated. For each patch processed, multiple tessellation
control shader invocations are performed -- one per output patch vertex.
Each tessellation control shader invocation writes all the attributes of
its corresponding output patch vertex. A tessellation control shader may
also read the per-vertex outputs of other tessellation control shader
invocations, as well as read and write shared per-patch outputs. The
tessellation control shader invocations for a single patch effectively run
as a group. A built-in barrier() function is provided to allow
synchronization points where no shader invocation will continue until all
shader invocations have reached the barrier.
The tessellation primitive generator then decomposes a patch into a new
set of primitives using the tessellation levels to determine how finely
tessellated the output should be. The primitive generator begins with
either a triangle or a quad, and splits each outer edge of the primitive
into a number of segments approximately equal to the corresponding element
of the outer tessellation level array. The interior of the primitive is
tessellated according to elements of the inner tessellation level array.
The primitive generator has three modes: "triangles" and "quads" split a
triangular or quad-shaped patch into a set of triangles that cover the
original patch; "isolines" splits a quad-shaped patch into a set of line
strips running across the patch horizontally. Each vertex generated by
the tessellation primitive generator is assigned a (u,v) or (u,v,w)
coordinate indicating its relative location in the subdivided triangle or
quad.
For each vertex produced by the tessellation primitive generator, the
tessellation evaluation shader is run to compute its position and other
attributes of the vertex, using its (u,v) or (u,v,w) coordinate. When
computing final vertex attributes, the tessellation evaluation shader can
also read the attributes of any of the vertices of the patch written by
the tessellation control shader. Tessellation evaluation shader
invocations are completely independent, although all invocations for a
single patch share the same collection of input vertices and per-patch
attributes.
The tessellator operates on vertices after they have been transformed by a
vertex shader. The primitives generated by the tessellator are passed
further down the OpenGL ES pipeline, where they can be used as inputs to
geometry shaders, transform feedback, and the rasterizer.
The tessellation control and evaluation shaders are both optional. If
neither shader type is present, the tessellation stage has no effect.
However, if either a tessellation control or a tessellation evaluation
shader is present, the other must also be present.
Not all tessellation shader implementations have the ability to write the
point size from a tessellation shader. Thus a second extension string and
shading language enable are provided for implementations which do
support tessellation shader point size.
This extension relies on the EXT_shader_io_blocks extension to provide
the required functionality for declaring input and output blocks and
interfacing between shaders.
This extension relies on the EXT_gpu_shader5 extension to provide the
'precise' and 'fma' functionality which are necessary to ensure crack-free
tessellation.
IP Status
No known IP claims.
New Procedures and Functions
void PatchParameteriEXT(enum pname, int value);
New Tokens
Accepted by the <mode> parameter of DrawArrays, DrawElements,
and other commands which draw primitives:
PATCHES_EXT 0xE
Accepted by the <pname> parameter of PatchParameteriEXT, GetBooleanv,
GetFloatv, GetIntegerv, and GetInteger64v:
PATCH_VERTICES_EXT 0x8E72
Accepted by the <pname> parameter of GetProgramiv:
TESS_CONTROL_OUTPUT_VERTICES_EXT 0x8E75
TESS_GEN_MODE_EXT 0x8E76
TESS_GEN_SPACING_EXT 0x8E77
TESS_GEN_VERTEX_ORDER_EXT 0x8E78
TESS_GEN_POINT_MODE_EXT 0x8E79
Returned by GetProgramiv when <pname> is TESS_GEN_MODE_EXT:
TRIANGLES
ISOLINES_EXT 0x8E7A
QUADS_EXT 0x0007
Returned by GetProgramiv when <pname> is TESS_GEN_SPACING_EXT:
EQUAL
FRACTIONAL_ODD_EXT 0x8E7B
FRACTIONAL_EVEN_EXT 0x8E7C
Returned by GetProgramiv when <pname> is TESS_GEN_VERTEX_ORDER_EXT:
CCW
CW
Returned by GetProgramiv when <pname> is TESS_GEN_POINT_MODE_EXT:
FALSE
TRUE
Accepted by the <pname> parameter of GetBooleanv, GetFloatv,
GetIntegerv, and GetInteger64v:
MAX_PATCH_VERTICES_EXT 0x8E7D
MAX_TESS_GEN_LEVEL_EXT 0x8E7E
MAX_TESS_CONTROL_UNIFORM_COMPONENTS_EXT 0x8E7F
MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT 0x8E80
MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_EXT 0x8E81
MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_EXT 0x8E82
MAX_TESS_CONTROL_OUTPUT_COMPONENTS_EXT 0x8E83
MAX_TESS_PATCH_COMPONENTS_EXT 0x8E84
MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_EXT 0x8E85
MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_EXT 0x8E86
MAX_TESS_CONTROL_UNIFORM_BLOCKS_EXT 0x8E89
MAX_TESS_EVALUATION_UNIFORM_BLOCKS_EXT 0x8E8A
MAX_TESS_CONTROL_INPUT_COMPONENTS_EXT 0x886C
MAX_TESS_EVALUATION_INPUT_COMPONENTS_EXT 0x886D
MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_EXT 0x8E1E
MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT 0x8E1F
MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_EXT 0x92CD
MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_EXT 0x92CE
MAX_TESS_CONTROL_ATOMIC_COUNTERS_EXT 0x92D3
MAX_TESS_EVALUATION_ATOMIC_COUNTERS_EXT 0x92D4
MAX_TESS_CONTROL_IMAGE_UNIFORMS_EXT 0x90CB
MAX_TESS_EVALUATION_IMAGE_UNIFORMS_EXT 0x90CC
MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_EXT 0x90D8
MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_EXT 0x90D9
PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED 0x8221
Accepted by the <props> parameter of
GetProgramResourceiv:
IS_PER_PATCH_EXT 0x92E7
REFERENCED_BY_TESS_CONTROL_SHADER_EXT 0x9307
REFERENCED_BY_TESS_EVALUATION_SHADER_EXT 0x9308
Accepted by the <type> parameter of CreateShader, by the <pname>
parameter of GetProgramPipelineiv, and returned by the
<params> parameter of GetShaderiv:
TESS_EVALUATION_SHADER_EXT 0x8E87
TESS_CONTROL_SHADER_EXT 0x8E88
Accepted by the <stages> parameter of UseProgramStages:
TESS_CONTROL_SHADER_BIT_EXT 0x00000008
TESS_EVALUATION_SHADER_BIT_EXT 0x00000010
Additions to the OpenGL ES 3.1 Specification
Modify chapter 3 "Dataflow Model"
Change the second paragraph, on p. 28:
... In the next stage vertices may be transformed, followed by assembly
into geometric primitives. Tessellation and geometry shaders may then
optionally generate multiple new primitives from single input
primitives. Optionally, the results ...
Modify figure 3.1 "Block diagram of the OpenGL ES pipeline" as modified
by EXT_geometry_shader to insert new boxes "Tessellation Control
Shader", "Tessellation Primitive Generation", and "Tessellation
Evaluation Shader" in sequence following "Vertex Shader" and preceding
"Geometry Shader". Extend the arrows from the boxes "Image Load/Store"
.. "Uniform Block" to the right of "Vertex Shader" to connect to the new
"Control" and "Evaluation" boxes.
Replace the two paragraphs of chapter 7, "Programs and Shaders" on p. 64
starting "Shader stages including ..." with:
Shader stages including vertex, tessellation control, tessellation
evaluation, geometry, fragment, and compute shaders can be created,
compiled, and linked into program objects.
Vertex shaders describe the operations that occur on vertex attributes.
Tessellation control and evaluation shaders are used to control
the operation of the tessellator (see section 11.1ts). Geometry shaders
affect the processing of primitives assembled from vertices (see section
11.1gs). Fragment shaders affect the processing of fragments during
rasterization (see chapter 14). A single program object can contain all
of these shaders, or any subset thereof.
Compute shaders ...
Add to table 7.1 "CreateShader <type> values" on p. 65:
<type> Shader Stage
-------------------------- ------------------------------
TESS_CONTROL_SHADER_EXT Tessellation control shader
TESS_EVALUATION_SHADER_EXT Tessellation evaluation shader
Add to the bullet list describing reasons for link failure below the
LinkProgram command on p. 70, as modified by EXT_geometry_shader:
* The program object contains an object to form a tessellation control
shader (see section 11.1ts.1), and
- the program is not separable and contains no object to form a
vertex shader; or
- the program is not separable and contains no object to form a
tessellation evaluation shader; or
- the output patch vertex count is not specified in the compiled
tessellation control shader object.
* The program object contains an object to form a tessellation
evaluation shader (see section 11.1ts.3), and
- the program is not separable and contains no object to form a
vertex shader; or
- the program is not separable and contains no object to form a
tessellation control shader; or
- the tessellation primitive mode is not specified in the compiled
tessellation evaluation shader object.
Modify section 7.3, "Program Objects", as modified by
EXT_geometry_shader:
Add to the second paragraph after UseProgram on p. 71:
The executable code ... the results of vertex and/or fragment processing
will be undefined. However, this is not an error. If there is no active
program for the tessellation control, tessellation evaluation, or
geometry shader stages, those stages are ignored. If there is no active
program for the compute shader stage ...
Modify section 7.3.1, Program Interfaces:
Modify table 7.2 "GetProgramResourceiv properties and supported
interfaces" on p. 81 to add "REFERENCED_BY_TESS_CONTROL_SHADER_EXT" and
"REFERENCED_BY_TESS_EVALUATION_SHADER_EXT" to the "Property" cell
already containing REFERENCED_BY_<stage>_SHADER for VERTEX, GEOMETRY,
FRAGMENT, and COMPUTE stages, with the same supported interfaces.
Add to table 7.2:
Property Supported Interfaces
---------------------------------------- -----------------------------
IS_PER_PATCH_EXT PROGRAM_INPUT, PROGRAM_OUTPUT
Add a new paragraph preceding the paragraph "For property IS_ROW_MAJOR"
on p. 83:
For the property IS_PER_PATCH_EXT, a single integer identifying whether
the input or output is a per-patch attribute is written to <params>. If
the active variable is a per-patch attribute (declared with the "patch"
qualifier), the value one is written to <params>; otherwise the value
zero is written to <params>.
Add tessellation shaders to the paragraph describing the REFERENCED_BY
properties, on p. 83:
For the properties REFERENCED_BY_VERTEX_SHADER,
REFERENCED_BY_TESS_CONTROL_SHADER_EXT,
REFERENCED_BY_TESS_EVALUATION_SHADER_EXT,
REFERENCED_BY_GEOMETRY_SHADER_EXT, REFERENCED_BY_FRAGMENT_SHADER, and
REFERENCED_BY_COMPUTE_SHADER, a single integer is written to <params>,
identifying whether the active resource is referenced by the vertex,
tessellation control, tessellation evaluation, geometry, fragment, or
compute shaders, respectively, in the program object. ...
Modify section 7.4, "Program Pipeline Objects" in the first
paragraph after UseProgramStages on p. 89:
... These stages may include vertex, tessellation control, tessellation
evaluation, geometry, fragment, or compute, indicated respectively by
VERTEX_SHADER_BIT, TESS_CONTROL_SHADER_BIT_EXT, TESS_EVALUATION_BIT_EXT,
GEOMETRY_SHADER_BIT_EXT, FRAGMENT_SHADER_BIT, or COMPUTE_SHADER_BIT. ...
Modify section 7.4.1, "Shader Interface Matching" on p. 91, changing the
new paragraph starting "Geometry shader per-vertex ...":
Tessellation control shader per-vertex output variables and blocks and
tessellation control, tessellation evaluation, and geometry shader
per-vertex input variables are required to be declared as arrays...
Modify section 7.4.2 "Program Pipeline Object State" on p. 92,
replacing the first bullet point:
* Unsigned integers are required to hold the names of the active program
and each of the current vertex, tessellation control, tessellation
evaluation, geometry, fragment, and compute stage programs. Each
integer is initially zero.
Modify section 7.6, "Uniform Variables"
Add to table 7.4 "Query targets for default uniform block storage ..."
on p. 96:
Shader Stage <pname> for querying default uniform block
storage, in components
---------------------------------- -------------------------------------------
Tess. control (see sec. 11.1ts.1.1) MAX_TESS_CONTROL_UNIFORM_COMPONENTS_EXT
Tess. eval (see sec. 11.1ts.3.1) MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT
Add to table 7.5 "Query targets for combined uniform block storage ..."
on p. 96:
Shader Stage <pname> for querying combined uniform block
storage, in components
---------------------------------- ---------------------------------------------------
Tess. control MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_EXT
Tess. eval MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT
Modify section 7.6.2, "Uniform Blocks" on p. 104, changing the second
paragraph of the section:
There is a set of implementation-dependent maximums for the number of
active uniform blocks used by each shader. If the number of uniform
blocks used by any shader in the program exceeds its corresponding
limit, the program will fail to link. The limits for vertex,
tessellation control, tessellation evaluation, geometry, fragment, and
compute shaders can be obtained by calling GetIntegerv with <pname>
values of MAX_VERTEX_UNIFORM_BLOCKS,
MAX_TESS_CONTROL_UNIFORM_BLOCKS_EXT,
MAX_TESS_EVALUATION_UNIFORM_BLOCKS_EXT, MAX_GEOMETRY_UNIFORM_BLOCKS_EXT,
MAX_FRAGMENT_UNIFORM_BLOCKS, and MAX_COMPUTE_UNIFORM_BLOCKS,
respectively.
Modify section 7.7, "Atomic Counter Buffers" on p. 108, changing the
second paragraph of the section:
There is a set of implementation-dependent maximums for the number of
active atomic counter buffers referenced by each shader. If the number
of atomic counter buffers referenced by any shader in the program
exceeds its corresponding limit, the program will fail to link. The
limits for vertex, tessellation control, tessellation evaluation,
geometry, fragment, and compute shaders can be obtained by calling
GetIntegerv with <pname> values of MAX_VERTEX_ATOMIC_COUNTER_BUFFERS,
MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_EXT,
MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_EXT,
MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS_EXT,
MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS, or
MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS, respectively.
Modify section 7.8, "Shader Buffer Variables and Shader Storage Blocks"
on p. 110, changing the fourth paragraph:
If the number of active shader storage blocks referenced by the shaders
in a program exceeds implementation-dependent limits, the program will
fail to link. The limits for vertex, tessellation control, tessellation
evaluation, geometry, fragment, and compute shaders can be obtained by
calling GetIntegerv with pname values of
MAX_VERTEX_SHADER_STORAGE_BLOCKS,
MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_EXT,
MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_EXT,
MAX_GEOMETRY_SHADER_STORAGE_BLOCKS_EXT,
MAX_FRAGMENT_SHADER_STORAGE_BLOCKS, and
MAX_COMPUTE_SHADER_STORAGE_BLOCKS, respectively. ...
Modify Section 7.11.1, "Shader Memory Access Ordering":
The order in which texture or buffer object memory is read or written by
shaders is largely undefined. For some shader types (vertex,
tessellation evaluation, and in some cases, fragment), even the number
of shader invocations that might perform loads and stores is undefined.
In particular, the following rules apply:
* While a vertex or tessellation evaluation shader will be executed at
least once for each unique vertex specified by the application (vertex
shaders) or generated by the tessellation primitive genertor
(tessellation evaluation shaders), it may be executed more than once
for implementation-dependent reasons. Additionally, ...
Modify section 7.12, "Shader, Program, and Program Pipeline Queries"
to add to the list of valid <pname>s for GetProgramiv on p. 120:
If <pname> is TESS_CONTROL_OUTPUT_VERTICES_EXT, the number of vertices
in the tessellation control shader output patch is returned.
If <pname> is TESS_GEN_MODE_EXT, QUADS_EXT, TRIANGLES, or ISOLINES_EXT
is returned, depending on the primitive mode declaration in the
tessellation evaluation shader. If <pname> is TESS_GEN_SPACING_EXT,
EQUAL, FRACTIONAL_EVEN_EXT, or FRACTIONAL_ODD_EXT is returned, depending
on the spacing declaration in the tessellation evaluation shader. If
<pname> is TESS_GEN_VERTEX_ORDER_EXT, CCW or CW is returned, depending
on the vertex order declaration in the tessellation evaluation shader.
If <pname> is TESS_GEN_POINT_MODE_EXT, TRUE is returned if point mode is
enabled in a tessellation evaluation shader declaration; FALSE is
returned otherwise.
Add to the Errors for GetProgramiv on p. 121:
An INVALID_OPERATION error is generated if TESS_CONTROL_OUTPUT_VERTICES
is queried for a program which has not been linked successfully, or
which does not contain objects to form a tessellation control shader.
An INVALID_OPERATION error is generated if TESS_GEN_MODE,
TESS_GEN_SPACING, TESS_GEN_VERTEX_ORDER, or TESS_GEN_POINT_MODE are
queried for a program which has not been linked successfully, or which
does not contain objects to form a tessellation evaluation shader,
Add new section 10.1.7sp following section 10.1.7, "Separate Triangles",
on p. 234:
Section 10.1.7sp, Separate Patches
Separate patches are specified with mode PATCHES_EXT. A patch is an
ordered collection of vertices used for primitive tessellation (see
section 11.1ts). The vertices comprising a patch have no implied
geometric ordering. The vertices of a patch are used by tessellation
shaders and the fixed-function tessellator to generate new point, line,
or triangle primitives.
Each patch in the series has a fixed number of vertices, which is
specified by calling
void PatchParameteriEXT(enum pname, int value);
with <pname> set to PATCH_VERTICES_EXT.
Errors
An INVALID_ENUM error is generated if <pname> is not PATCH_VERTICES_EXT.
An INVALID_VALUE error is generated if <value> is less than or equal to
zero, or is greater than the implementation-dependent maximum patch size
(the value of MAX_PATCH_VERTICES_EXT). The patch size is initially three
vertices.
If the number of vertices in a patch is given by <v>, the <v>*<i>+1st
through <v>*<i>+<v>th vertices (in that order) determine a patch for
each i = 0, 1, ..., n-1, where there are <v>*<n>+<k> vertices. <k> is in
the range [0,<v>-1]; if <k> is not zero, the final <k> vertices are
ignored.
Add to the end of section 10.3.4, "Primitive Restart" on p. 243:
Implementations are not required to support primitive restart for
separate patch primitives (primitive type PATCHES_EXT). Support can be
queried by calling GetBooleanv with the symbolic constant
PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED_EXT. A value of FALSE indicates
that primitive restart is treated as disabled when drawing patches, no
matter the value of the enable. A value of TRUE indicates that primitive
restart behaves normally for patches.
Modify section 11.1.2.1, "Output Variables" on p. 262, starting with the
second paragraph of the section:
... These output variables are used to communicate values to the next
active stage in the vertex processing pipeline; either the tessellation
control or geometry shader, or the fixed-function vertex processing
stages leading to rasterization.
...
The number of components (individual scalar numeric values) of output
variables that can be written by the vertex shader, whether or not a
tessellation control or geometry shader is active, is given by the value
of the implementation-dependent constant MAX_VERTEX_OUTPUT_COMPONENTS.
For the purposes of counting ...
...
Each program object can specify a set of output variables from one
shader to be recorded in transform feedback mode (see section 2.14). The
variables that can be recorded are those emitted by the first active
shader, in order, from the following list:
* geometry shader
* tessellation evaluation shader
* vertex shader
The set of variables to record is specified with the command
void TransformFeedbackVaryings ...
Modify the bullet point starting "the <count> specified" in the list of
TransformFeedbackVaryings link failures on p. 263:
* the <count> specified by TransformFeedbackVaryings is non-zero, but
the program object has no vertex, tessellation evaluation, or geometry
shader; ...
Modify Section 11.1.3, Shader Execution
Change the first paragraph and bullet list on p. 264:
If there is an active program object present for the vertex,
tessellation control, tessellation evaluation, or geometry shader
stages, the executable code for those active programs is used to process
incoming vertex values. The following sequence of operations is
performed:
* Vertices are processed by the vertex shader (see section 11.1) and
assembled into primitives as described in sections 10.1 through 10.3.
* If the current program contains a tessellation control shader, each
individual patch primitive is processed by the tessellation control
shader (section 11.1ts.1). Otherwise, primitives are passed through
unmodified. If active, the tessellation control shader consumes its
input patch and produces a new patch primitive, which is passed to
subsequent pipeline stages.
* If the current program contains a tessellation evaluation shader, each
individual patch primitive is processed by the tessellation primitive
generator (section 11.1ts.2) and tessellation evaluation shader (see
section 11.1ts.3). Otherwise, primitives are passed through unmodified.
When a tessellation evaluation shader is active, the tessellation
primitive generator produces a new collection of point, line, or
triangle primitives to be passed to subsequent pipeline stages. The
vertices of these primitives are processed by the tessellation
evaluation shader. The patch primitive passed to the tessellation
primitive generator is consumed by this process.
* If the current program contains a geometry shader, ...
Modify the bullet list in section 11.1.3.5 "Texture Access" on p. 266 to
add limits for tessellation shaders:
* MAX_VERTEX_TEXTURE_IMAGE_UNITS (for vertex shaders),
* MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_EXT (for tessellation control
shaders),
* MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_EXT (for tessellation
evaluation shaders),
* MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_EXT (for geometry shaders), and
* MAX_TEXTURE_IMAGE_UNITS (for fragment shaders).
Modify the bullet list in section 11.1.3.6 "Atomic Counter Access" on p.
268 to add a limit for geometry shaders:
* MAX_TESS_CONTROL_ATOMIC_COUNTERS_EXT (for tessellation control
shaders),
* MAX_TESS_EVALUATION_ATOMIC_COUNTERS_EXT (for tessellation evaluation
shaders),
Modify the bullet list in section 11.1.3.7 "Image Access" on p. 268 to
add a limit for geometry shaders:
* MAX_TESS_CONTROL_IMAGE_UNIFORMS_EXT (for tessellation control
shaders),
* MAX_TESS_EVALUATION_IMAGE_UNIFORMS_EXT (for tessellation evaluation
shaders),
Modify the bullet list in section 11.1.3.8 "Shader Storage Buffer
Access" on p. 268 to add a limit for geometry shaders:
* MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_EXT (for tessellation control
shaders),
* MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_EXT (for tessellation
evaluation shaders),
Modify section 11.1.3.11, "Validation" to replace the bullet point
starting "There is an active program for the geometry stage ..." on p.
270:
* There is an active program for tessellation control, tessellation
evaluation, or geometry stages with corresponding executable shader,
but there is no active program with an executable vertex shader.
Add a new bullet point in the same section:
* One but not both of the tessellation control and tessellation
evaluation stages have an active program with corresponding executable
shader.
Insert new section 11.1ts, "Tessellation", between section 11.1 "Vertex
Shaders" and section 11.1gs "Geometry Shaders":
Tessellation is a process that reads a patch primitive and generates new
primitives used by subsequent pipeline stages. The generated primitives
are formed by subdividing a single triangle or quad primitive according
to fixed or shader-computed levels of detail and transforming each of
the vertices produced during this subdivision.
Tessellation functionality is controlled by two types of tessellation
shaders: tessellation control shaders and tessellation evaluation
shaders. Tessellation is considered active if and only if the active
program object or program pipeline object includes both a tessellation
control shader and a tessellation evaluation shader.
The tessellation control shader is used to read an input patch provided
by the application, and emit an output patch. The tessellation control
shader is run once for each vertex in the output patch and computes the
attributes of that vertex. Additionally, the tessellation control shader
may compute additional per-patch attributes of the output patch. The
most important per-patch outputs are the tessellation levels, which are
used to control the number of subdivisions performed by the tessellation
primitive generator. The tessellation control shader may also write
additional per-patch attributes for use by the tessellation evaluation
shader. If no tessellation control shader is active, patch primitives
may not be provided by the application.
If a tessellation evaluation shader is active, the tessellation
primitive generator subdivides a triangle or quad primitive into a
collection of points, lines, or triangles according to the tessellation
levels of the patch and the set of layout declarations specified in the
tessellation evaluation shader text.
When a tessellation evaluation shader is active, it is run on each
vertex generated by the tessellation primitive generator to compute the
final position and other attributes of the vertex. The tessellation
evaluation shader can read the relative location of the vertex in the
subdivided output primitive, given by an (u,v) or (u,v,w) coordinate, as
well as the position and attributes of any or all of the vertices in the
input patch.
Tessellation operates only on patch primitives.
Patch primitives are not supported by pipeline stages below the
tessellation evaluation shader.
A non-separable program object or program pipeline object that includes
a tessellation shader of any kind must also include a vertex shader.
Errors
An INVALID_OPERATION error is generated by any command that transfers
vertices to the GL if the current program state has one but not both of
a tessellation control shader and tessellation evaluation shader.
An INVALID_OPERATION error is generated by any command that transfers
vertices to the GL if tessellation is active and the primitive mode is
not PATCHES_EXT.
An INVALID_OPERATION error is generated by any command that transfers
vertices to the GL if tessellation is not active and the primitive mode
is PATCHES_EXT.
An INVALID_OPERATION error is generated by any command that transfers
vertices to the GL if the current program state has a tessellation
shader but no vertex shader.
Section 11.1ts.1, Tessellation Control Shaders
The tessellation control shader consumes an input patch provided by the
application and emits a new output patch. The input patch is an array of
vertices with attributes corresponding to output variables written by
the vertex shader. The output patch consists of an array of vertices
with attributes corresponding to per-vertex output variables written by
the tessellation control shader and a set of per-patch attributes
corresponding to per-patch output variables written by the tessellation
control shader. Tessellation control output variables are per-vertex by
default, but may be declared as per-patch using the "patch" qualifier.
The number of vertices in the output patch is fixed when the program is
linked, and is specified in tessellation control shader source code
using the output layout qualifier "vertices", as described in the OpenGL
ES Shading Language Specification. A program will fail to link if the
output patch vertex count is not specified by the tessellation control
shader object attached to the program, if it is less than or equal to
zero, or if it is greater than the implementation-dependent maximum
patch size. The output patch vertex count may be queried by calling
GetProgramiv with the symbolic constant
TESS_CONTROL_OUTPUT_VERTICES_EXT.
Tessellation control shaders are created as described in section 7.1,
using a <type> of TESS_CONTROL_SHADER_EXT. When a new input patch is
received, the tessellation control shader is run once for each vertex in
the output patch. The tessellation control shader invocations
collectively specify the per-vertex and per-patch attributes of the
output patch. The per-vertex attributes are obtained from the per-vertex
output variables written by each invocation. Each tessellation control
shader invocation may only write to per-vertex output variables
corresponding to its own output patch vertex. The output patch vertex
number corresponding to a given tessellation control point shader
invocation is given by the built-in variable gl_InvocationID. Per-patch
attributes are taken from the per-patch output variables, which may be
written by any tessellation control shader invocation. While
tessellation control shader invocations may read any per-vertex and
per-patch output variable and write any per-patch output variable,
reading or writing output variables also written by other invocations
has ordering hazards discussed below.
Section 11.1ts.1.1, Tessellation Control Shader Variables
Tessellation control shaders can access uniforms belonging to the
current program object. Limits on uniform storage and methods for
manipulating uniforms are described in section 7.6.
Tessellation control shaders also have access to samplers to perform
texturing operations, as described in section 7.9.
Tessellation control shaders can access the transformed attributes of
all vertices for their input primitive using input variables. A vertex
shader writing to output variables generates the values of these input
variables. Values for any inputs that are not written by a vertex shader
are undefined.
Additionally, tessellation control shaders can write to one or more
output variables, including per-vertex attributes for the vertices of
the output patch and per-patch attributes of the patch. Tessellation
control shaders can also write to a set of built-in per-vertex and
per-patch outputs defined in the OpenGL ES Shading Language. The
per-vertex and per-patch attributes of the output patch are used by the
tessellation primitive generator (section 11.1ts.2) and may be read by
tessellation evaluation shader (section 11.1ts.3).
Section 11.1ts.1.2, Tessellation Control Shader Execution Environment
If there is an active program for the tessellation control stage, the
executable version of the program's tessellation control shader is used
to process patches resulting from the primitive assembly stage. When
tessellation control shader execution completes, the input patch is
consumed. A new patch is assembled from the per-vertex and per-patch
output variables written by the shader and is passed to subsequent
pipeline stages.
There are several special considerations for tessellation control shader
execution described in the following sections.
Section 11.1ts.1.2.1, Texture Access
Section 11.1.3.1 describes texture lookup functionality accessible to a
vertex shader. The texel fetch and texture size query functionality
described there also applies to tessellation control shaders.
Section 11.1ts.1.2.2, Tessellation Control Shader Inputs
Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language
Specification describes the built-in variable array gl_in[] available as
input to a tessellation control shader. gl_in[] receives values from
equivalent built-in output variables written by the vertex shader. Each
array element of gl_in[] is a structure holding values for a specific
vertex of the input patch. The length of gl_in[] is equal to the
implementation-dependent maximum patch size (gl_MaxPatchVertices).
Behavior is undefined if gl_in[] is indexed with a vertex index greater
than or equal to the current patch size. The members of each element of
the gl_in[] array are gl_Position
[[ If EXT_tessellation_point_size is supported: ]]
and gl_PointSize.
Tessellation control shaders have available several other special input
variables not replicated per-vertex and not contained in gl_in[],
including:
* The variable gl_PatchVerticesIn holds the number of vertices in the
input patch being processed by the tessellation control shader.
* The variable gl_PrimitiveID is filled with the number of primitives
processed by the drawing command which generated the input vertices.
The first primitive generated by a drawing command is numbered zero,
and the primitive ID counter is incremented after every individual
point, line, or triangle primitive is processed. The counter is
reset to zero between each instance drawn. Restarting a primitive
topology using the primitive restart index has no effect on the
primitive ID counter.
* The variable gl_InvocationID holds an invocation number for the
current tessellation control shader invocation. Tessellation control
shaders are invoked once per output patch vertex, and invocations
are numbered beginning with zero.
Similarly to the built-in inputs, each user-defined input variable has a
value for each vertex and thus needs to be declared as arrays or inside
input blocks declared as arrays. Declaring an array size is optional. If
no size is specified, it will be taken from the implementation-dependent
maximum patch size (gl_MaxPatchVertices). If a size is specified, it must
match the maximum patch size; otherwise, a compile or link error will
occur. Since the array size may be larger than the number of vertices
found in the input patch, behavior is undefined if a per-vertex input
variable is accessed using an index greater than or equal to the number of
vertices in the input patch. The OpenGL ES Shading Language doesn't
support multi-dimensional arrays as shader inputs or outputs; therefore,
user-defined tessellation control shader inputs corresponding to vertex
shader outputs declared as arrays must be declared as array members of
an input block that is itself declared as an array.
Similarly to the limit on vertex shader output components (see section
11.1.2.1), there is a limit on the number of components of input
variables that can be read by the tessellation control shader, given by
the value of the implementation-dependent constant
MAX_TESS_CONTROL_INPUT_COMPONENTS_EXT.
When a program is linked, all components of any input read by a
tessellation control shader will count against this limit. A program
whose tessellation control shader exceeds this limit may fail to link,
unless device-dependent optimizations are able to make the program fit
within available hardware resources.
Component counting rules for different variable types and variable
declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see
section 11.1.2.1).
Section 11.1ts.1.2.3, Tessellation Control Shader Outputs
Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language
Specification describes the built-in variable array gl_out[] available
as an output for a tessellation control shader. gl_out[] passes values
to equivalent built-in input variables read by subsequent shader stages
or to subsequent fixed functionality vertex processing pipeline stages.
Each array element of gl_out[] is a structure holding values for a
specific vertex of the output patch. The length of gl_out[] is equal to
the output patch size specified in the tessellation control shader
output layout declaration. The members of each element of the gl_out[]
array are gl_Position
[[ If EXT_tessellation_point_size is supported: ]]
and gl_PointSize.
They behave identically to equivalently named vertex shader outputs
(see section 11.1.2.1).
Tessellation shaders additionally have two built-in per-patch output
arrays, gl_TessLevelOuter[] and gl_TessLevelInner[]. These arrays are not
replicated for each output patch vertices and are not members of gl_out[].
gl_TessLevelOuter[] is an array of four floating-point values specifying
the approximate number of segments that the tessellation primitive
generator should use when subdividing each outer edge of the primitive it
subdivides. gl_TessLevelInner[] is an array of two floating-point values
specifying the approximate number of segments used to produce a
regularly-subdivided primitive interior. The values written to
gl_TessLevelOuter and gl_TessLevelInner need not be integers, and their
interpretation depends on the type of primitive the tessellation
primitive generator will subdivide and other tessellation parameters, as
discussed in the following section.
A tessellation control shader may also declare user-defined per-vertex
output variables. User-defined per-vertex output variables are declared
with the qualifier "out" and have a value for each vertex in the output
patch. Such variables must be declared as arrays or inside output blocks
declared as arrays. Declaring an array size is optional. If no size is
specified, it will be taken from output patch size declared in the
shader. If a size is specified, it must match the maximum patch size;
otherwise, a compile or link error will occur. The OpenGL ES Shading
Language doesn't support multi-dimensional arrays as shader inputs or
outputs; therefore, user-defined per-vertex tessellation control shader
outputs with multiple elements per vertex must be declared as array members
of an output block that is itself declared as an array.
While per-vertex output variables are declared as arrays indexed by
vertex number, each tessellation control shader invocation may write
only to those outputs corresponding to its output patch vertex.
Tessellation control shaders must use the special variable
gl_InvocationID as the vertex number index when writing to per-vertex
output variables.
Additionally, a tessellation control shader may declare per-patch output
variables using the qualifier "patch out". Unlike per-vertex outputs,
per-patch outputs do not correspond to any specific vertex in the patch,
and are not indexed by vertex number. Per-patch outputs declared as
arrays have multiple values for the output patch; similarly declared
per-vertex outputs would indicate a single value for each vertex in the
output patch. User-defined per-patch outputs are not used by the
tessellation primitive generator, but may be read by tessellation
evaluation shaders.
There are several limits on the number of components of built-in and
user-defined output variables that can be written by the tessellation
control shader. The number of components of active per-vertex output
variables may not exceed the value of
MAX_TESS_CONTROL_OUTPUT_COMPONENTS_EXT. The number of components of
active per-patch output variables may not exceed the value of
MAX_TESS_PATCH_COMPONENTS_EXT. The built-in outputs gl_TessLevelOuter[]
and gl_TessLevelInner[] are not counted against the per-patch limit. The
total number of components of active per-vertex and per-patch outputs is
derived by multiplying the per-vertex output component count by the output
patch size and then adding the per-patch output component count. The total
component count may not exceed
MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_EXT.
When a program is linked, all components of any output variable written
by a tessellation control shader will count against this limit. A
program exceeding any of these limits may fail to link, unless
device-dependent optimizations are able to make the program fit within
available hardware resources.
Component counting rules for different variable types and variable
declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see
section 11.1.2.1).
Section 11.1ts.1.2.4, Tessellation Control Shader Execution Order
For tessellation control shaders with a declared output patch size
greater than one, the shader is invoked more than once for each input
patch. The order of execution of one tessellation control shader
invocation relative to the other invocations for the same input patch is
largely undefined. The built-in function barrier() provides some control
over relative execution order. When a tessellation control shader calls
the barrier() function, its execution pauses until all other invocations
have also called the same function. Output variable assignments
performed by any invocation executed prior to calling barrier() will be
visible to any other invocation after the call to barrier() returns.
Shader output values read in one invocation but written by another may
be undefined without proper use of barrier(); full rules are found in
the OpenGL ES Shading Language Specification.
The barrier() function may only be called inside the main entry point of
the tessellation control shader and may not be called in potentially
divergent flow control. In particular, barrier() may not be called
inside a switch statement, in either sub-statement of an if statement,
inside a do, for, or while loop, or at any point after a return
statement in the function main().
Section 11.1ts.2, Tessellation Primitive Generation
The tessellation primitive generator consumes the input patch and
produces a new set of basic primitives (points, lines, or triangles).
These primitives are produced by subdividing a geometric primitive
(rectangle or triangle) according to the per-patch tessellation levels
written by the tessellation control shader. This subdivision is
performed in an implementation- dependent manner.
The type of subdivision performed by the tessellation primitive
generator is specified by an input layout declaration in the
tessellation evaluation shader using one of the identifiers "triangles",
"quads", and "isolines". For "triangles", the primitive generator
subdivides a triangle primitive into smaller triangles. For "quads", the
primitive generator subdivides a rectangle primitive into smaller
triangles. For "isolines", the primitive generator subdivides a
rectangle primitive into a collection of line segments arranged in
strips stretching horizontally across the rectangle. Each vertex
produced by the primitive generator has an associated (u,v,w) or (u,v)
position in a normalized parameter space, with parameter values in the
range [0,1], as illustrated in Figure 11.X1. For "triangles", the vertex
position is a barycentric coordinate (u,v,w), where u+v+w==1, and
indicates the relative influence of the three vertices of the triangle
on the position of the vertex. For "quads" and "isolines", the position
is a (u,v) coordinate indicating the relative horizontal and vertical
position of the vertex relative to the subdivided rectangle. The
subdivision process is explained in more detail in subsequent sections.
(0,1) OL3 (1,1) (0,1,0) (0,1) (1,1)
+--------------+ + ^ + <no edge> +
| | / \ |
| +--------+ | / \ | +--------------+
| | IL0 | | OL0 / + \ OL2 |
OL0| |IL1 | |OL2 / / \ \ | +--------------+
| | | | / /IL0\ \ OL0
| +--------+ | / +-----+ \ | +--------------+
| | / \ |
+--------------+ +---------------+ v +--------------+
(0,0) OL1 (1,0) (0,0,1) OL1 (1,0,0) (0,0) OL1 (1,0)
quads triangles isolines
Figure 11.X1: Domain parameterization for tessellation generator
primitive modes (triangles, quads, or isolines). The coordinates
illustrate the value of gl_TessCoord at the corners of the domain. The
labels on the edges indicate the inner (IL0 and IL1) and outer (OL0
through OL3) tessellation level values used to control the number of
subdivisions along each edge of the domain.
A patch is discarded by the tessellation primitive generator if any
relevant outer tessellation level is less than or equal to zero. Patches
will also be discarded if any relevant outer tessellation level
corresponds to a floating-point NaN (not a number) in implementations
supporting NaN. When patches are discarded, no new primitives will be
generated and the tessellation evaluation program will not be run. For
"quads", all four outer levels are relevant. For "triangles" and
"isolines", only the first three or two outer levels, respectively, are
relevant. Negative inner levels will not cause a patch to be discarded;
they will be clamped as described below.
Each of the tessellation levels is used to determine the number and
spacing of segments used to subdivide a corresponding edge. The method
used to derive the number and spacing of segments is specified by an
input layout declaration in the tessellation evaluation shader using one
of the identifiers "equal_spacing", "fractional_even_spacing", or
"fractional_odd_spacing". If no spacing is specified in the tessellation
evaluation shader, "equal_spacing" will be used.
If "equal_spacing" is used, the floating-point tessellation level is
first clamped to the range [1,<max>], where <max> is the
implementation-dependent maximum tessellation level (the value of
MAX_TESS_GEN_LEVEL_EXT). The result is rounded up to the nearest integer
<n>, and the corresponding edge is divided into <n> segments of equal
length in (u,v) space.
If "fractional_even_spacing" is used, the tessellation level is first
clamped to the range [2,<max>] and then rounded up to the nearest even
integer <n>. If "fractional_odd_spacing" is used, the tessellation level
is clamped to the range [1,<max>-1] and then rounded up to the nearest
odd integer <n>. If <n> is one, the edge will not be subdivided.
Otherwise, the corresponding edge will be divided into <n>-2 segments of
equal length, and two additional segments of equal length that are
typically shorter than the other segments. The length of the two
additional segments relative to the others will decrease monotonically
with the value of <n>-<f>, where <f> is the clamped floating-point
tessellation level. When <n>-<f> is zero, the additional segments will
have equal length to the other segments. As <n>-<f> approaches 2.0, the
relative length of the additional segments approaches zero. The two
additional segments should be placed symmetrically on opposite sides of
the subdivided edge. The relative location of these two segments is
undefined, but must be identical for any pair of subdivided edges with
identical values of <f>.
When the tessellation primitive generator produces triangles (in the
"triangles" or "quads" modes), the orientation of all triangles can be
specified by an input layout declaration in the tessellation evaluation
shader using the identifiers "cw" and "ccw". If the order is "cw", the
vertices of all generated triangles will have a clockwise ordering in
(u,v) or (u,v,w) space, as illustrated in Figure 11.X1. If the order is
"ccw", the vertices will be specified in counter-clockwise order. If no
layout is specified, "ccw" will be used.
For all primitive modes, the tessellation primitive generator is capable
of generating points instead of lines or triangles. If an input layout
declaration in the tessellation evaluation shader specifies the identifier
"point_mode", the primitive generator will generate one point for each
distinct vertex produced by tessellation. Otherwise, the primitive
generator will produce a collection of line segments or triangles
according to the primitive mode. When tessellating triangles or quads in
point mode with fractional odd spacing, the tessellation primitive
generator may produce "interior" vertices that are positioned on the edge
of the patch if an inner tessellation level is less than or equal to one.
Such vertices are considered distinct from vertices produced by
subdividing the outer edge of the patch, even if there are pairs of
vertices with identical coordinates.
The points, lines, or triangles produced by the tessellation primitive
generator are passed to subsequent pipeline stages in an
implementation-dependent order.
Section 11.1ts.2.1, Triangle Tessellation
If the tessellation primitive mode is "triangles", an equilateral
triangle is subdivided into a collection of triangles covering the area
of the original triangle. First, the original triangle is subdivided
into a collection of concentric equilateral triangles. The edges of each
of these triangles are subdivided, and the area between each triangle
pair is filled by triangles produced by joining the vertices on the
subdivided edges. The number of concentric triangles and the number of
subdivisions along each triangle except the outermost is derived from
the first inner tessellation level. The edges of the outermost triangle
are subdivided independently, using the first, second, and third outer
tessellation levels to control the number of subdivisions of the u==0
(left), v==0 (bottom), and w==0 (right) edges, respectively. The second
inner tessellation level and the fourth outer tessellation level have no
effect in this mode.
If the first inner tessellation level and all three outer tessellation
levels are exactly one after clamping and rounding, only a single
triangle with (u,v,w) coordinates of (0,0,1), (1,0,0), and (0,1,0) is
generated. If the inner tessellation level is one and any of the outer
tessellation levels is greater than one, the inner tessellation level is
treated as though it were originally specified as 1+epsilon and will be
rounded up to result in a two- or three-segment subdivision according to
the tessellation spacing.
If any tessellation level is greater than one, tessellation begins by
producing a set of concentric inner triangles and subdividing their
edges. First, the three outer edges are temporarily subdivided using the
clamped and rounded first inner tessellation level and the specified
tessellation spacing, generating <n> segments. For the outermost inner
triangle, the inner triangle is degenerate -- a single point at the
center of the triangle -- if <n> is two. Otherwise, for each corner of
the outer triangle, an inner triangle corner is produced at the
intersection of two lines extended perpendicular to the corner's two
adjacent edges running through the vertex of the subdivided outer edge
nearest that corner. If <n> is three, the edges of the inner triangle
are not subdivided and is the final triangle in the set of concentric
triangles. Otherwise, each edge of the inner triangle is divided into
<n>-2 segments, with the <n>-1 vertices of this subdivision produced by
intersecting the inner edge with lines perpendicular to the edge running
through the <n>-1 innermost vertices of the subdivision of the outer
edge. Once the outermost inner triangle is subdivided, the previous
subdivision process repeats itself, using the generated triangle as an
outer triangle. This subdivision process is illustrated in Figure 11.X2.
(0,1,0)
+
/ \
(0,1,0) O. .O
+ / + \
/ \ O. / \ .O
O. .O / O. .O \
/ + \ / / + \ \
O. / \ .O / / / \ \ \
/ O. .O \ O. / / \ \ .O
/ / O \ \ / O. / \ .O \
O. / . \ .O / / O-------O \ \
/ O----O----O \ O. / . . \ .O
/ . . . \ / O----O-------O----O \
O----O----O----O----O / . . . . \
(0,0,1) (1,0,0) O----O----O-------O----O----O
(0,0,1) (1,0,0)
Figure 11.X2, Inner Triangle Tessellation with inner tessellation
levels of four and five (not to scale). This figure depicts the
vertices along the bottom edge of the concentric triangles. The edges
of inner triangles are subdivided by intersecting the edge with
segments perpendicular to the edge passing through each inner vertex
of the subdivided outer edge.
Once all the concentric triangles are produced and their edges are
subdivided, the area between each pair of adjacent inner triangles is
filled completely with a set of non-overlapping triangles. In this
subdivision, two of the three vertices of each triangle are taken from
adjacent vertices on a subdivided edge of one triangle; the third is one
of the vertices on the corresponding edge of the other triangle. If the
innermost triangle is degenerate (i.e., a point), the triangle
containing it is subdivided into six triangles by connecting each of the
six vertices on that triangle with the center point. If the innermost
triangle is not degenerate, that triangle is added to the set of
generated triangles as-is.
After the area corresponding to any inner triangles is filled, the
primitive generator generates triangles to cover area between the
outermost triangle and the outermost inner triangle. To do this, the
temporary subdivision of the outer triangle edge above is discarded.
Instead, the u==0, v==0, and w==0 edges are subdivided according to the
first, second, and third outer tessellation levels, respectively, and
the tessellation spacing. The original subdivision of the first inner
triangle is retained. The area between the outer and first inner
triangles is completely filled by non-overlapping triangles as described
above. If the first (and only) inner triangle is degenerate, a set of
triangles is produced by connecting each vertex on the outer triangle
edges with the center point.
After all triangles are generated, each vertex in the subdivided
triangle is assigned a barycentric (u,v,w) coordinate based on its
location relative to the three vertices of the outer triangle.
The algorithm used to subdivide the triangular domain in (u,v,w) space
into individual triangles is implementation-dependent. However, the set
of triangles produced will completely cover the domain, and no portion
of the domain will be covered by multiple triangles. The order in which
the generated triangles passed to subsequent pipeline stages and the
order of the vertices in those triangles are both
implementation-dependent. However, when depicted in a manner similar to
Figure 11.X2, the order of the vertices in the generated triangles will
be either all clockwise or all counter-clockwise, according to the
vertex order layout declaration.
Section 11.1ts.2.2, Quad Tessellation
If the tessellation primitive mode is "quads", a rectangle is subdivided
into a collection of triangles covering the area of the original
rectangle. First, the original rectangle is subdivided into a regular
mesh of rectangles, where the number of rectangles along the u==0 and
u==1 (vertical) and v==0 and v==1 (horizontal) edges are derived from
the first and second inner tessellation levels, respectively. All
rectangles, except those adjacent to one of the outer rectangle edges,
are decomposed into triangle pairs. The outermost rectangle edges are
subdivided independently, using the first, second, third, and fourth
outer tessellation levels to control the number of subdivisions of the
u==0 (left), v==0 (bottom), u==1 (right), and v==1 (top) edges,
respectively. The area between the inner rectangles of the mesh and the
outer rectangle edges are filled by triangles produced by joining the
vertices on the subdivided outer edges to the vertices on the edge of
the inner rectangle mesh.
If both clamped inner tessellation levels and all four clamped outer
tessellation levels are exactly one, only a single triangle pair covering
the outer rectangle is generated. Otherwise, if either clamped inner
tessellation level is one, that tessellation level is treated as though it
were originally specified as 1+epsilon and will result in a two- or
three-segment subdivision depending on the tessellation spacing. When
used with fractional odd spacing, the three-segment subdivision may
produce "inner" vertices positioned on the edge of the rectangle.
If any tessellation level is greater than one, tessellation begins by
subdividing the u==0 and u==1 edges of the outer rectangle into <m>
segments using the clamped and rounded first inner tessellation level
and the tessellation spacing. The v==0 and v==1 edges are subdivided
into <n> segments using using the second inner tessellation level. Each
vertex on the u==0 and v==0 edges are joined with the corresponding
vertex on the u==1 and v==1 edges to produce a set of vertical and
horizontal lines that divide the rectangle into a grid of smaller
rectangles. The primitive generator emits a pair of non-overlapping
triangles covering each such rectangle not adjacent to an edge of the
outer rectangle. The boundary of the region covered by these triangles
forms an inner rectangle, the edges of which are subdivided by the grid
vertices that lie on the edge. If either <m> or <n> is two, the inner
rectangle is degenerate, and one or both of the rectangle's "edges"
consist of a single point. This subdivision is illustrated in Figure
11.X3.
(0,1) (1,1)
+--+--+--+--+--+--+--+
| . . . . . . |
(0,1) (1,1) | . . . . . . |
+--+--+--+--+ +..O--O--O--O--O--O..+
| . . . | | |**|**|**|**|**| |
| . . . | | |**|**|**|**|**| |
+..O--O--O..+ +..O--+--+--+--+--O..+
| . . . | | |**|**|**|**|**| |
| . . . | | |**|**|**|**|**| |
+--+--+--+--+ +..O--O--O--O--O--O..+
(0,0) (1,0) | . . . . . . |
| . . . . . . |
+--+--+--+--+--+--+--+
(0,0) (1,0)
Figure 11.X3, Inner Quad Tessellation with inner tessellation levels
of (4,2) and (7,4). The areas labeled with "*" on the right depict the
10 inner rectangles, each of which will be subdivided into two
triangles. The points labeled "O" depict vertices on the boundary of
the inner rectangle, where the inner rectangle on the left side is
degenerate (a single line segment). The dotted lines (".") depict the
horizontal and vertical edges connecting corresponding points on the
outer rectangle edge.
After the area corresponding to the inner rectangle is filled, the
primitive generator must produce triangles to cover area between the
inner and outer rectangles. To do this, the subdivision of the outer
rectangle edge above is discarded. Instead, the u==0, v==0, u==1, and
v==1 edges are subdivided according to the first, second, third, and
fourth outer tessellation levels, respectively, and the tessellation
spacing. The original subdivision of the inner rectangle is retained.
The area between the outer and inner rectangles is completely filled by
non-overlapping triangles. Two of the three vertices of each triangle
are adjacent vertices on a subdivided edge of one rectangle; the third
is one of the vertices on the corresponding edge of the other triangle.
If either edge of the innermost rectangle is degenerate, the area near
the corresponding outer edges is filled by connecting each vertex on the
outer edge with the single vertex making up the inner "edge".
The algorithm used to subdivide the rectangular domain in (u,v) space
into individual triangles is implementation-dependent. However, the set
of triangles produced will completely cover the domain, and no portion
of the domain will be covered by multiple triangles. The order in which
the generated triangles passed to subsequent pipeline stages and the
order of the vertices in those triangles are both
implementation-dependent. However, when depicted in a manner similar to
Figure 11.X3, the order of the vertices in the generated triangles will
be either all clockwise or all counter-clockwise, according to the
vertex order layout declaration.
Isoline Tessellation
If the tessellation primitive mode is "isolines", a set of independent
horizontal line segments is drawn. The segments are arranged into
connected strips called "isolines", where the vertices of each isoline
have a constant v coordinate and u coordinates covering the full range
[0,1]. The number of isolines generated is derived from the first outer
tessellation level; the number of segments in each isoline is derived
from the second outer tessellation level. Both inner tessellation levels
and the third and fourth outer tessellation levels have no effect in
this mode.
As with quad tessellation above, isoline tessellation begins with a
rectangle. The u==0 and u==1 edges of the rectangle are subdivided
according to the first outer tessellation level. For the purposes of
this subdivision, the tessellation spacing mode is ignored and treated
as "equal_spacing". A line is drawn connecting each vertex on the u==0
rectangle edge to the corresponding vertex on the u==1 rectangle edge,
except that no line is drawn between (0,1) and (1,1). If the number of
segments on the subdivided u==0 and u==1 edges is <n>, this process will
result in <n> equally spaced lines with constant v coordinates of 0,
1/<n>, 2/<n>, ..., (<n>-1)/<n>.
Each of the <n> lines is then subdivided according to the second outer
tessellation level and the tessellation spacing, resulting in <m> line
segments. Each segment of each line is emitted by the tessellation
primitive generator, as illustrated in Figure 11.X4.
(0,1) (1,1)
+ + (0,1) (1,1)
+ +
O---O---O---O---O---O---O
O---O---O---O---O---O---O
O---O---O---O---O---O---O
O-----O-----O-----O
O---O---O---O---O---O---O (0,0) (1,0)
(0,0) (1,0)
Figure 11.X4, Isoline Tessellation with the first two outer
tessellation levels of (4,6) and (1,3), respectively. The lines
connecting the vertices labeled "O" are emitted by the primitive
generator. The vertices labeled "+" correspond to (u,v) coordinates of
(0,1) and (1,1), where no line segments are generated.
The order in which the generated line segments are passed to subsequent
pipeline stages and the order of the vertices in each generated line
segment are both implementation-dependent.
Section 11.1ts.3, Tessellation Evaluation Shaders
If active, the tessellation evaluation shader takes the (u,v) or (u,v,w)
location of each vertex in the primitive subdivided by the tessellation
primitive generator, and generates a vertex with a position and
associated attributes. The tessellation evaluation shader can read any
of the vertices of its input patch, which is the output patch produced
by the tessellation control shader. Tessellation evaluation shaders are
created as described in section 7.1, using a <type> of
TESS_EVALUATION_SHADER_EXT.
Each invocation of the tessellation evaluation shader writes the
attributes of exactly one vertex. The number of vertices evaluated per
patch depends on the tessellation level values computed by the
tessellation control shaders. Tessellation evaluation shader invocations
run independently, and no invocation can access the variables belonging
to another invocation. All invocations are capable of accessing all the
vertices of their corresponding input patch.
The number of the vertices in the input patch is fixed and is equal to
the tessellation control shader output patch size parameter in effect
when the program was last linked.
Section 11.1ts.3.1, Tessellation Evaluation Shader Variables
Tessellation evaluation shaders can access uniforms belonging to the
current program object. The amount of storage available for uniform
variables, except for atomic counters, in the default uniform block
accessed by a tessellation evaluation shader is specified by the value
of the implementation-dependent constant
MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT. The total amount of combined
storage available for uniform variables in all uniform blocks accessed
by a tessellation evaluation shader (including the default uniform
block) is specified by the value of the implementation-dependent
constant MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT. These
values represent the numbers of individual floating-point, integer, or
boolean values that can be held in uniform variable storage for a
tessellation evaluation shader. A uniform matrix in the default uniform
block with single-precision components will consume no more than 4 x
min(r,c) uniform components. A link error is generated if an attempt is
made to utilize more than the space available for tessellation
evaluation shader uniform variables. Uniforms are manipulated as
described in section 2.11.6. Tessellation evaluation shaders also have
access to samplers to perform texturing operations, as described in
section 2.11.7.
Tessellation evaluation shaders can access the transformed attributes of
all vertices for their input primitive using input variables. A
tessellation control shader writing to output variables generates the
values of these input varying variables, including values for built-in
as well as user- defined varying variables. Values for any varying
variables that are not written by a tessellation control shader are
undefined.
Additionally, tessellation evaluation shaders can write to one or more
output variables that will be passed to subsequent programmable shader
stages or fixed functionality vertex pipeline stages.
Section 11.1ts.3.2, Tessellation Evaluation Shader Execution Environment
If there is an active program for the tessellation evaluation stage, the
executable version of the program's tessellation evaluation shader is
used to process vertices produced by the tessellation primitive
generator. During this processing, the shader may access the input patch
processed by the primitive generator. When tessellation evaluation
shader execution completes, a new vertex is assembled from the output
variables written by the shader and is passed to subsequent pipeline
stages.
There are several special considerations for tessellation evaluation
shader execution described in the following sections.
Section 11.1ts.3.2.1, Texture Access
Section 11.1.3.1 describes texture lookup functionality accessible to a
vertex shader. The texel fetch and texture size query functionality
described there also applies to tessellation evaluation shaders.
Section 11.1ts.3.3, Tessellation Evaluation Shader Inputs
Section 7.1 ("Built-In Variables") of the OpenGL ES Shading Language
Specification describes the built-in variable array gl_in[] available as
input to a tessellation evaluation shader. gl_in[] receives values from
equivalent built-in output variables written by a previous shader
(section 11.1.3). Each array element of gl_in[] is a structure holding
values for a specific vertex of the input patch. The length of gl_in[]
is equal to the implementation- dependent maximum patch size
(gl_MaxPatchVertices). Behavior is undefined if gl_in[] is indexed with
a vertex index greater than or equal to the current patch size. The
members of each element of the gl_in[] array are gl_Position
[[ If EXT_tessellation_point_size is supported: ]]
and gl_PointSize.
Tessellation evaluation shaders have available several other special
input variables not replicated per-vertex and not contained in gl_in[],
including:
* The variables gl_PatchVerticesIn and gl_PrimitiveID are filled with
the number of the vertices in the input patch and a primitive
number, respectively. They behave exactly as the identically named
inputs for tessellation control shaders.
* The variable gl_TessCoord is a three-component floating-point vector
consisting of the (u,v,w) coordinate of the vertex being processed
by the tessellation evaluation shader. The values of u, v, and w are
in the range [0,1], and vary linearly across the primitive being
subdivided. For tessellation primitive modes of "quads" or
"isolines", the w value is always zero. The (u,v,w) coordinates are
generated by the tessellation primitive generator in a manner
dependent on the primitive mode, as described in section 11.1ts.2.
gl_TessCoord is not an array; it specifies the location of the
vertex being processed by the tessellation evaluation shader, not of
any vertex in the input patch.
* The variables gl_TessLevelOuter[] and gl_TessLevelInner[] are arrays
holding outer and inner tessellation levels of the patch, as used by
the tessellation primitive generator. Tessellation level values
loaded in these variables will be prior to the clamping and rounding
operations performed by the primitive generator as described in
Section 11.1ts.2. For triangular tessellation, gl_TessLevelOuter[3]
and gl_TessLevelInner[1] will be undefined. For isoline
tessellation, gl_TessLevelOuter[2], gl_TessLevelOuter[3], and both
values in gl_TessLevelInner[] are undefined.
A tessellation evaluation shader may also declare user-defined
per-vertex input variables. User-defined per-vertex input variables are
declared with the qualifier "in" and have a value for each vertex in the
input patch. User-defined per-vertex input varying variables have a
value for each vertex and thus need to be declared as arrays or inside
input blocks declared as arrays. Declaring an array size is optional. If
no size is specified, it will be taken from the implementation-dependent
maximum patch size (gl_MaxPatchVertices). If a size is specified, it must
match the maximum patch size; otherwise, a compile or link error will
occur. Since the array size may be larger than the number of vertices
found in the input patch, behavior is undefined if a per-vertex input
variable is accessed using an index greater than or equal to the number of
vertices in the input patch. The OpenGL ES Shading Language doesn't
support multi-dimensional arrays as shader inputs or outputs; therefore,
user-defined tessellation evaluation shader inputs corresponding to
shader outputs declared as arrays must be declared as array members of
an input block that is itself declared as an array.
Additionally, a tessellation evaluation shader may declare per-patch
input variables using the qualifier "patch in". Unlike per-vertex
inputs, per-patch inputs do not correspond to any specific vertex in the
patch, and are not indexed by vertex number. Per-patch inputs declared
as arrays have multiple values for the input patch; similarly declared
per-vertex inputs would indicate a single value for each vertex in the
output patch. User-defined per-patch input variables are filled with
corresponding per-patch output values written by the tessellation
control shader.
Similarly to the limit on vertex shader output components (see section
11.1.2.1), there is a limit on the number of components of per-vertex
and per-patch input variables that can be read by the tessellation
evaluation shader, given by the values of the implementation-dependent
constants MAX_TESS_EVALUATION_INPUT_COMPONENTS_EXT and
MAX_TESS_PATCH_COMPONENTS_EXT, respectively. The built-in inputs
gl_TessLevelOuter[] and gl_TessLevelInner[] are not counted against the
per-patch limit.
When a program is linked, all components of any input variable read by a
tessellation evaluation shader will count against this limit. A program
whose tessellation evaluation shader exceeds this limit may fail to
link, unless device-dependent optimizations are able to make the program
fit within available hardware resources.
Component counting rules for different variable types and variable
declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see
section 11.1.2.1).
Section 11.1ts.3.4, Tessellation Evaluation Shader Outputs
Tessellation evaluation shaders have a number of built-in output
variables used to pass values to equivalent built-in input variables
read by subsequent shader stages or to subsequent fixed functionality
vertex processing pipeline stages. These variables are gl_Position
[[ If EXT_tessellation_point_size is supported: ]]
and gl_PointSize,
and behave identically to equivalently named vertex shader outputs (see
section 11.1.3). A tessellation evaluation shader may also declare
user-defined per-vertex output variables.
Similarly to the limit on vertex shader output components (see section
11.1.2.1), there is a limit on the number of components of built-in and
user-defined output variables that can be written by the tessellation
evaluation shader, given by the values of the implementation-dependent
constant MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_EXT.
When a program is linked, all components of any output variable written
by a tessellation evaluation shader will count against this limit. A
program whose tessellation evaluation shader exceeds this limit may fail
to link, unless device-dependent optimizations are able to make the
program fit within available hardware resources.
Component counting rules for different variable types and variable
declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS. (see
section 11.1.2.1).
Modify section 12.1, "Transform Feedback"
Replace the second paragraph of the section on p. 274 (as modified
by EXT_geometry_shader):
The data captured in transform feedback mode depends on the active
programs on each of the shader stages. If a program is active for the
geometry shader stage, transform feedback captures the vertices of each
primitive emitted by the geometry shader. Otherwise, if a program is
active for the tessellation evaluation shader stage, transform feedback
captures each primitive produced by the tessellation primitive generator,
whose vertices are processed by the tessellation evaluation shader.
Otherwise, transform feedback captures each primitive processed by the
vertex shader.
Modify the second paragraph following ResumeTransformFeedback on p. 277
(as modified by EXT_geometry_shader):
When transform feedback is active and not paused ... If a tessellation
evaluation or geometry shader is active, the type of primitive emitted
by that shader is used instead of the <mode> parameter passed to drawing
commands for the purposes of this error check. If tessellation
evaluation and geometry shaders are both active, the output primitive
type of the geometry shader will be used for the purposes of this error.
Any primitive type may be used while transform feedback is paused.
Modify the second paragraph of section 12.2, "Primitive Queries" on p.
281:
When BeginQuery is called with a target of PRIMITIVES_GENERATED_EXT, ...
This counter counts the number of primitives emitted by a geometry
shader, if active, possibly further tessellated into separate primitives
during the transform feedback stage, if active.
Modify section 13.3, "Points"
Replace the text starting "The point size is determined ..." on p. 290:
The point size is determined by the last active stage before the
rasterizer:
* the geometry shader, if active; or
* the tessellation evaluation shader, if active and no geometry shader
is active;
* the vertex shader, otherwise.
If the last active stage is not a vertex shader and does not statically
assign a value to gl_PointSize, the point size is 1.0. Otherwise, the
point size is taken from the shader built-in gl_PointSize written by
that stage.
[[ Note that it is impossible to assign a value to gl_PointSize
if EXT_geometry_point_size or EXT_tessellation_point_size is not
supported and enabled in the relevant shader stages. ]]
If the last active stage is a vertex shader, the point size is taken
from the shader built-in gl_PointSize written by the vertex shader.
In all cases, the point size is clamped to the implementation-dependent
point size range. If the value written to gl_PointSize is less than or
equal to zero, or if no value is written to gl_PointSize (except as
noted above) the point size is undefined. The supported range ...
Add new section A.3ts in Appendix A before section A.4, "Atomic Counter
Invariance" on p. 405:
Section A.3ts, 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 input layout qualifiers. 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 input layout qualifier in the
tessellation evaluation shader of the active program.
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 input
layout qualifier.
Rule 8: The value of all defined components of gl_TessCoord will be in
the range [0,1]. Additionally, for any defined component <x> of
gl_TessCoord, the results of computing (1.0-<x>) in a tessellation
evaluation shader will be exact. Some floating-point values in the range
[0,1] may fail to satisfy this property, but such values may never be
used as tessellation coordinate components.
Dependencies on OES_shader_multisample_interpolation
If OES_shader_multisample_interpolation is not supported ignore all
references to the "sample in" and "sample out" qualifiers.
New State
Add new table 20.1ts "Current Values and Associated Data" preceding table
20.2 on p. 354:
Default
Get Value Type Get Command Value Description Sec.
------------------------ ---- -------------- --------- ------------------------ ------------
PATCH_VERTICES_EXT Z+ GetIntegerv 3 Number of vertices in 10.1.7sp
input patch
Add to table 20.19, "Program Pipeline Object State":
Initial
Get Value Type Get Command Value Description Sec
-------------------------- ---- -------------------- ------- -------------------------------- ---
TESS_CONTROL_SHADER_EXT Z+ GetProgramPipelineiv 0 Name of current tess. control 7.4
shader program object
TESS_EVALUATION_SHADER_EXT Z+ GetProgramPipelineiv 0 Name of current tess. evaluation 7.4
shader program object
Add new table 20.25ts, "Program Object State (cont.)":
Default
Get Value Type Get Command Value Description Sec.
-------------------------------- ---- ------------ --------- ------------------------ --------
TESS_CONTROL_OUTPUT_VERTICES_EXT Z+ GetProgramiv 0 Output patch size 11.1ts.1
for tess. control shader
TESS_GEN_MODE_EXT E GetProgramiv QUADS_EXT Base primitive type for 11.1ts.2
tess. prim. generator
TESS_GEN_SPACING_EXT E GetProgramiv EQUAL Spacing of tess. prim. 11.1ts.2
generator edge subdivision
TESS_GEN_VERTEX_ORDER_EXT E GetProgramiv CCW Order of vertices in 11.1ts.2
primitives generated by
tess. prim generator
TESS_GEN_POINT_MODE_EXT B GetProgramiv FALSE Tess prim. generator 11.1ts.2
emits points?
Add to table 20.28, "Program Object Resource State (cont.)":
Initial
Get Value Type Get Command Value Description Sec.
---------------------------------------- ---- -------------------- ------- ----------------------- -----
REFERENCED_BY_TESS_CONTROL_SHADER_EXT Z+ GetProgramResourceiv - Active resource used by 7.3.1
tess. control shader?
REFERENCED_BY_TESS_EVALUATION_SHADER_EXT Z+ GetProgramResourceiv - Active resource used by 7.3.1
tess. eval. shader?
New Implementation Dependent State
Add to table 20.39 "Implementation Dependent Values":
Minimum
Get Value Type Get Command Value Description Sec.
------------------------------------------- ---- ----------- ------- ---------------------------- ------
PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED_EXT B GetBooleanv - True if primitive restart is 10.3.4
supported for patches
Add new table 20.43ts "Implementation Dependent Tessellation Shader Limits"
following table 6.31 "Implementation Dependent Vertex Shader Limits":
Minimum
Get Value Type Get Command Value Description Sec.
------------------------- ---- ----------- ------- ------------------------------- ------
MAX_TESS_GEN_LEVEL_EXT Z+ GetIntegerv 64 Max. level supported by 11.1ts.2
tess. primitive generator
MAX_PATCH_VERTICES_EXT Z+ GetIntegerv 32 Maximum patch size 10.1
MAX_TESS_CONTROL_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv 1024 No. of words for TCS uniforms 11.1ts.1.1
MAX_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv 1024 No. of words for TES uniforms 11.1ts.3.1
MAX_TESS_CONTROL_TEXTURE_IMAGE_UNITS_EXT Z+ GetIntegerv 16 No. of tex. image units for TCS 11.1.3.5
MAX_TESS_EVALUATION_TEXTURE_IMAGE_UNITS_EXT Z+ GetIntegerv 16 No. of tex. image units for TES 11.1.3.5
MAX_TESS_CONTROL_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 64 No. components for per-patch 11.1ts.1.2
vertex outputs in TCS
MAX_TESS_PATCH_COMPONENTS_EXT Z+ GetIntegerv 120 No. components for per-patch 11.1ts.1.2
output varyings for TCS
MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 2048 Total no. components for TCS 11.1ts.1.2
outputs
MAX_TESS_EVALUATION_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.3.2
outputs in TES
MAX_TESS_CONTROL_INPUT_COMPONENTS_EXT Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.1.2
inputs in TCS
MAX_TESS_EVALUATION_INPUT_COMPONENTS_EXT Z+ GetIntegerv 64 No. components for per-vertex 11.1ts.3.2
inputs in TES
MAX_TESS_CONTROL_UNIFORM_BLOCKS_EXT Z+ GetIntegerv 12 No. of supported uniform 7.6.2
blocks for TCS
MAX_TESS_EVALUATION_UNIFORM_BLOCKS_EXT Z+ GetIntegerv 12 No. of supported uniform 7.6.2
blocks for TES
MAX_TESS_CONTROL_ATOMIC_COUNTER_BUFFERS_EXT Z+ GetIntegerv 0 No. of AC (atomic counter) 7.7
buffers accessed by a TCS
MAX_TESS_EVALUATION_ATOMIC_COUNTER_BUFFERS_EXT Z+ GetIntegerv 0 No. of AC (atomic counter) 7.7
buffers accessed by a TES
MAX_TESS_CONTROL_ATOMIC_COUNTERS_EXT Z+ GetIntegerv 0 Number of ACs accessed by a TCS 11.1.3.6
MAX_TESS_EVALUATION_ATOMIC_COUNTERS_EXT Z+ GetIntegerv 0 Number of ACs accessed by a TES 11.1.3.6
MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS_EXT Z+ GetIntegerv 0 No. of shader storage blocks 7.8
accessed by a TCS
MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS_EXT Z+ GetIntegerv 0 No. of shader storage blocks 7.8
accessed by a TES
Add to table 20.46 "Implementation Dependent Aggregate Shader Limits"
([fn] is a dagger mark referring to existing text in the table caption):
Minimum
Get Value Type Get Command Value Description Sec.
--------------------------------------------------- ---- ----------- ------- ----------------------------- ----------
MAX_TESS_CONTROL_IMAGE_UNIFORMS_EXT Z+ GetIntegerv 0 No. of image variables in TCS 11.1.3.7
in TCS
MAX_TESS_EVALUATION_IMAGE_UNIFORMS_EXT Z+ GetIntegerv 0 No. of image variables in TES 11.1.3.7
MAX_COMBINED_TESS_CONTROL_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv [fn] No. of words for TCS uniform 11.1ts.1.1
variables in all uniform
blocks (including default)
MAX_COMBINED_TESS_EVALUATION_UNIFORM_COMPONENTS_EXT Z+ GetIntegerv [fn] No. of words for TES uniform 11.1ts.3.1
variables in all uniform
blocks (including default)
Modify existing entries in table 20.46:
Minimum
Get Value Type Get Command Value Description Sec.
-------------------------------------------- ---- ----------- ------- -------------------------- -------
MAX_UNIFORM_BUFFER_BINDINGS Z+ GetIntegerv 72 Max. no. of uniform buffer 7.6.2
binding points
MAX_COMBINED_UNIFORM_BLOCKS Z+ GetIntegerv 60 Max. no. of uniform 7.6.2
buffers per program
MAX_COMBINED_TEXTURE_IMAGE_UNITS Z+ GetIntegerv 96 Total no. of tex. units 11.1.3.5
accessible by the GL
Additions to the OpenGL ES Shading Language 3.10 Specification
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_tessellation_shader : <behavior>
#extension GL_EXT_tessellation_point_size : <behavior>
where <behavior> is as specified in section 3.4.
A new preprocessor #define is added to the OpenGL ES Shading Language:
#define GL_EXT_tessellation_shader 1
#define GL_EXT_tessellation_point_size 1
If the EXT_tessellation_shader extension is enabled, the
EXT_shader_io_blocks extension is also implicitly enabled.
Change the introduction to Chapter 2 "Overview of OpenGL ES Shading" as
follows:
The OpenGL ES Shading Language is actually several closely related
languages. These languages are used to create shaders for each of the
programmable processors contained in the OpenGL ES processing pipeline.
Currently, these processors are the compute, vertex, tessellation
control, tessellation evaluation, geometry, and fragment processors.
Unless otherwise noted in this Specification, a language feature applies
to all languages, and common usage will refer to these languages as a
single language. The specific languages will be referred to by the name
of the processor they target: compute, vertex, tessellation control,
tessellation evalution, geometry, or fragment.
Add new subsections 2.ts1 and 2.ts2 preceding subsection 2.gs "Geometry
Processor":
Section 2.ts1, Tessellation Control Processor
The <tessellation control processor> is a programmable unit that
operates on a patch of incoming vertices and their associated data,
emitting a new output patch. Compilation units written in the OpenGL ES
Shading Language to run on this processor are called tessellation
control shaders. When a tessellation control shader is compiled and
linked, it results in a tessellation control shader executable that runs
on the tessellation control processor.
The tessellation control processor is invoked for each each vertex of
the output patch. Each invocation can read the attributes of any vertex
in the input or output patches, but can only write per-vertex attributes
for the corresponding output patch vertex. The shader invocations
collectively produce a set of per-patch attributes for the output patch.
After all tessellation control shader invocations have completed, the
output vertices and per-patch attributes are assembled to form a patch
to be used by subsequent pipeline stages.
Tessellation control shader invocations run mostly independently, with
undefined relative execution order. However, the built-in function
barrier() can be used to control execution order by synchronizing
invocations, effectively dividing tessellation control shader execution
into a set of phases. Tessellation control shaders will get undefined
results if one invocation reads a per-vertex or per-patch attribute
written by another invocation at any point during the same phase, or if
two invocations attempt to write different values to the same per-patch
output in a single phase.
Section 2.ts2, Tessellation Evaluation Processor
The <tessellation evaluation processor> is a programmable unit that
evaluates the position and other attributes of a vertex generated by the
tessellation primitive generator, using a patch of incoming vertices and
their associated data. Compilation units written in the OpenGL ES
Shading Language to run on this processor are called tessellation
evaluation shaders. When a tessellation evaluation shader is compiled
and linked, it results in a tessellation evaluation shader executable
that runs on the tessellation evaluation processor.
Each invocation of the tessellation evaluation executable computes the
position and attributes of a single vertex generated by the tessellation
primitive generator. The executable can read the attributes of any
vertex in the input patch, plus the tessellation coordinate, which is
the relative location of the vertex in the primitive being tessellated.
The executable writes the position and other attributes of the vertex.
Modifications to Section 3.7 (Keywords)
Remove "patch" from the list of reserved keywords and add it to the list
of keywords.
Modify Section 4.3, Storage Qualifiers
Add two new qualifiers to the storage qualifier table on p. 38:
Qualifier Meaning
--------- -------------------------------------------------------------
patch in linkage of per-patch attributes into a shader from a previous
stage (tessellation evaluation shaders only)
patch out linkage out of a shader to a subsequent stage (tessellation
control shaders only)
Modify section 4.3.4, Input Variables
Replace the paragraphs starting with "Geometry shader input variables
get ..." and ending with "Fragment shader inputs get ..." on p. 40:
Tessellation control, evaluation, and geometry shader input variables
get the per-vertex values written out by output variables of the same
names in the previous active (vertex) shader stage. For these inputs,
"centroid in", "sample in", and interpolation qualifiers are allowed,
but are equivalent to "in". Since these shader stages operate on a set
of vertices, each input variable or input block (see section 4.3.9
"Interface Blocks") needs to be declared as an array. For example,
in float foo[]; // geometry shader input for vertex "out float foo"
Each element of such an array corresponds to one vertex of the primitive
being processed. Each array can optionally have a size declared. The
array size will be set by (or if provided must be consistent with) the
input layout declaration(s) establishing the type of input primitive, as
described later in section 4.4.1 "Input Layout Qualifiers".
Some inputs and outputs are <arrayed>, meaning that for an interface
between two shader stages either the input or output declaration
requires an extra level of array indexing for the declarations to match.
For example, with the interface between a vertex shader and a geometry
shader, vertex shader output variables and geometry shader input
variables of the same name must match in type and qualification (other
than precision and "out" matching to "in"), except that the geometry
shader will have one more array dimension than the vertex shader, to
allow for vertex indexing. If such an arrayed interface variable is not
declared with the necessary additional input or output array dimension,
a link-time error will result.
For non-arrayed interfaces (meaning array dimensionally stays the same
between stages), it is a link-time error if the input variable is not
declared with the same type, including array dimensionality, and
qualification (other than precision and "out" matching to "in") as the
matching output variable.
Additionally, tessellation evaluation shaders support per-patch input
variables declared with the "patch in" qualifier. Per-patch input
variables are filled with the values of per-patch output variables
written by the tessellation control shader. Per-patch inputs may be
declared as one-dimensional arrays, but are not indexed by vertex
number. Applying the "patch in" qualifier to inputs can only be done in
tessellation evaluation shaders. As with other input variables,
per-patch inputs must be declared using the same type and qualification
(other than precision and "out" matching to "in") as per-patch outputs
from the previous (tessellation control) shader stage.
It is a compile-time error to use the "patch in" qualifier with inputs
in any type of shader other than tessellation evaluation.
Fragment shader inputs get ...
Modify section 4.3.6 "Output Variables" starting with the third
paragraph of the section, on p. 42:
Vertex, tessellation evaluation, and geometry output variables output
per-vertex data and are declared using the "out", "centroid out", or
"sample out" storage qualifiers. Applying the "patch out" qualifier to
an output can only be done in tessellation control shaders. Output
variables can only be floating-point scalars, floating-point vectors,
matrices, signed or unsigned integers or integer vectors, or arrays or
structures of any of these.
It is a compile-time error to use the "patch out" qualifier with outputs
in any other type of shader other than tessellation control.
Individual vertex, tessellation control, tessellation evaluation, and
geometry outputs are declared as in the following examples: ...
Following this modified language and leading into the last paragraph of
section 4.3.6 on p. 37 (starting "Fragment outputs output
per-fragment"), add:
Tessellation control shader output variables are used to output
per-vertex and per-patch data. Per-vertex output variables are arrayed
(see "arrayed" in section 4.3.4, "Inputs") and declared using the "out",
"centroid out", or "sample out" qualifiers; the "patch out" qualifier is
not allowed. Per-patch output variables must be declared using the
"patch out" qualifier. Per-vertex and per-patch output variables can
only be floating-point scalars, vectors, or matrices, signed or unsigned
integers or integer vectors, or arrays or structures of these. Since
tessellation control shaders produce an arrayed primitive comprising
multiple vertices, each per-vertex output variable (or output block, see
interface blocks below) needs to be declared as an array. For example,
out float foo[]; // feeds next stage input "in float foo[]"
Each element of such an array corresponds to one vertex of the primitive
being produced. Each array can optionally have a size declared. The
array size will be set by (or if provided must be consistent with) the
output layout declaration(s) establishing the number of vertices in the
output patch, as described later in section 4.4.2.ts "Tessellation
Control Outputs".
Each tessellation control shader invocation has a corresponding output
patch vertex, and may assign values to per-vertex outputs only if they
belong to that corresponding vertex. If a per-vertex output variable is
used as an l-value, it is a compile- or link-time error if the expression
indicating the vertex index is not the identifier gl_InvocationID.
The order of execution of a tessellation control shader invocation
relative to the other invocations for the same input patch is undefined
unless the built-in function barrier() is used. This provides some
control over relative execution order. When a shader invocation calls
barrier(), its execution pauses until all other invocations have reached
the same point of execution. Output variable assignments performed by
any invocation executed prior to calling barrier() will be visible to
any other invocation after the call to barrier() returns.
Because tessellation control shader invocations execute in undefined
order between barriers, the values of per-vertex or per-patch output
variables will sometimes be undefined. Consider the beginning and end of
shader execution and each call to barrier() as synchronization points.
The value of an output variable will be undefined in any of the three
following cases:
1. At the beginning of execution.
2. At each synchronization point, unless
* the value was well-defined after the previous synchronization point
and was not written by any invocation since, or
* the value was written by exactly one shader invocation since the
previous synchronization point, or
* the value was written by multiple shader invocations since the
previous synchronization point, and the last write performed by all
such invocations wrote the same value.
3. When read by a shader invocation, if
* the value was undefined at the previous synchronization point and
has not been writen by the same shader invocation since, or
* the output variable is written to by any other shader invocation
between the previous and next synchronization points, even if that
assignment occurs in code following the read.
Fragment outputs output per-fragment data and are declared ...
Modify section 4.4.1 "Input Layout Qualifiers" to add new subsections
4.4.1.ts and 4.4.2.ts, preceding the new subsection 4.4.1.gs "Geometry
Shader Inputs":
Section 4.4.1.ts, Tessellation Evaluation Inputs
Additional input layout qualifier identifiers allowed for tessellation
evaluation shaders are:
<layout-qualifier-id>
triangles
quads
isolines
equal_spacing
fractional_even_spacing
fractional_odd_spacing
cw
ccw
point_mode
One group of these identifiers, <primitive mode>, is used to specify a
tessellation primitive mode to be used by the tessellation primitive
generator. To specify a primitive mode, the identifier must be one of
"triangles", "quads", or "isolines", which specify that the tessellation
primitive generator should subdivide a triangle into smaller triangles,
a quad into triangles, or a quad into a collection of lines,
respectively.
A second group of these identifiers, <vertex spacing>, is used to
specify the spacing used by the tessellation primitive generator when
subdividing an edge. To specify vertex spacing, the identifier must be
one of:
* "equal_spacing", signifying that edges should be divided into a
collection of <N> equal-sized segments;
* "fractional_even_spacing", signifying that edges should be divided
into an even number of equal-length segments plus two additional
shorter "fractional" segments; or
* "fractional_odd_spacing", signifying that edges should be divided
into an odd number of equal-length segments plus two additional
shorter "fractional" segments.
A third subset of these identifiers, <ordering>, specifies whether the
tessellation primitive generator produces triangles in clockwise or
counter-clockwise order, according to the coordinate system depicted in
the OpenGL ES Specification. The identifiers "cw" and "ccw" indicate
clockwise and counter-clockwise triangles, respectively. If the
tessellation primitive generator does not produce triangles, the order
is ignored.
Finally, <point mode> is specified with the identifier "point_mode"
indicating that the tessellation primitive generator should produce one
point for each distinct vertex in the subdivided primitive, rather than
generating lines or triangles.
Any or all of these identifiers may be specified one or more times in a
single input layout declaration.
The tessellation evaluation shader object in a program must declare a
primitive mode in its input layout. Declaring vertex spacing, ordering,
or point mode identifiers is optional. If spacing or vertex order
declarations are omitted, the tessellation primitive generator will use
equal spacing or counter-clockwise vertex ordering, respectively. If a
point mode declaration is omitted, the tessellation primitive generator
will produce lines or triangles according to the primitive mode.
Section 4.4.2.ts, Tessellation Control Outputs
Other than for the transform feedback layout qualifiers, tessellation
control shaders allow output layout qualifiers only on the interface
qualifier "out", not on an output block, block member, or variable
declaration. The output layout qualifier identifiers allowed for
tessellation control shaders are:
layout-qualifier-id
vertices = integer-constant
The identifier "vertices" specifies the number of vertices in the output
patch produced by the tessellation control shader, which also specifies
the number of times the tessellation control shader is invoked. It is a
compile- or link-time error for the output vertex count to be less than
or equal to zero, or greater than the implementation-dependent maximum
patch size.
The intrinsically declared tessellation control output array gl_out[]
will also be sized by any output layout declaration. Hence, the
expression
gl_out.length()
will return the output patch vertex count specified in a previous output
layout qualifier. For outputs declared without an array size, including
intrinsically declared outputs (i.e., gl_out), a layout must be declared
before any use of the method length() or other array use that requires
its size to be known.
It is a compile-time error if the output patch vertex count specified in
an output layout qualifier does not match the array size specified in
any output variable declaration in the same shader.
All tessellation control shader layout declarations in a program must
specify the same output patch vertex count. There must be at least one
layout qualifier specifying an output patch vertex count in any program
containing a tessellation control shader.
Modify section 7 to add new subsections 7.1ts1 and 7.1ts2 following
section 7.1.1 "Vertex Shader Special Variables":
Section 7.1ts1, Tessellation Control Special Variables
In the tessellation control language, built-in variables are
intrinsically declared as:
[[ If EXT_tessellation_point_size is supported and enabled: ]]
in gl_PerVertex {
highp vec4 gl_Position;
hihgp float gl_PointSize;
} gl_in[gl_MaxPatchVertices];
[[ Otherwise: ]]
in gl_PerVertex {
highp vec4 gl_Position;
} gl_in[gl_MaxPatchVertices];
in highp int gl_PatchVerticesIn;
in highp int gl_PrimitiveID;
in highp int gl_InvocationID;
[[ If EXT_tessellation_point_size is supported and enabled: ]]
out gl_PerVertex {
highp vec4 gl_Position;
highp float gl_PointSize;
} gl_out[];
[[ Otherwise: ]]
out gl_PerVertex {
highp vec4 gl_Position;
} gl_out[];
patch out highp float gl_TessLevelOuter[4];
patch out highp float gl_TessLevelInner[2];
Section 7.1ts1.1, Tessellation Control Input Variables
gl_Position contains the output written in the previous shader stage to
gl_Position.
[[ If EXT_tessellation_point_size is supported: ]]
gl_PointSize contains the output written in the previous shader stage to
gl_PointSize.
gl_PatchVerticesIn contains the number of vertices in the input patch
being processed by the shader. A single shader can read patches of
differing sizes, so the value of gl_PatchVerticesIn may differ between
patches.
gl_PrimitiveID contains the number of primitives processed by the
shader since the current set of rendering primitives was started.
gl_InvocationID contains the number of the output patch vertex assigned
to the tessellation control shader invocation. It is assigned integer
values in the range [0, N-1], where N is the number of output patch
vertices per primitive.
Section 7.1ts1.2, Tessellation Control Output Variables
gl_Position is used in the same fashion as the
corresponding output variable in the vertex shader.
[[ If EXT_tessellation_point_size is supported: ]]
gl_PointSize is used in the same fashion as the corresponding output
variable in the vertex shader.
The values written to gl_TessLevelOuter and gl_TessLevelInner are
assigned to the corresponding outer and inner tessellation levels of the
output patch. They are used by the tessellation primitive generator to
control primitive tessellation, and may be read by tessellation
evaluation shaders.
Section 7.1ts2, Tessellation Evaluation Special Variables
In the tessellation evaluation language, built-in variables are
intrinsically declared as:
[[ If EXT_tessellation_point_size is supported and enabled: ]]
in gl_PerVertex {
highp vec4 gl_Position;
highp float gl_PointSize;
} gl_in[gl_MaxPatchVertices];
[[ Otherwise: ]]
in gl_PerVertex {
highp vec4 gl_Position;
} gl_in[gl_MaxPatchVertices];
in highp int gl_PatchVerticesIn;
in highp int gl_PrimitiveID;
in highp vec3 gl_TessCoord;
patch in highp float gl_TessLevelOuter[4];
patch in highp float gl_TessLevelInner[2];
[[ If EXT_tessellation_point_size is supported and enabled: ]]
out gl_PerVertex {
highp vec4 gl_Position;
hihgp float gl_PointSize;
};
[[ Otherwise: ]]
out gl_PerVertex {
highp vec4 gl_Position;
};
Section 7.1ts2.1, Tessellation Evaluation Input Variables
gl_Position contains the output written in the previous shader stage to
gl_Position.
[[ If EXT_tessellation_point_size is supported: ]]
gl_PointSize contains the output written in the previous shader stage to
gl_PointSize.
gl_PatchVerticesIn and gl_PrimitiveID are defined in the same fashion as
the corresponding input variables in the tessellation control shader.
gl_TessCoord specifies a three-component (u,v,w) vector identifying the
position of the vertex being processed by the shader relative to the
primitive being tessellated. Its values will obey the properties
gl_TessCoord.x == 1.0 - (1.0 - gl_TessCoord.x) // two operations performed
gl_TessCoord.y == 1.0 - (1.0 - gl_TessCoord.y) // two operations performed
gl_TessCoord.z == 1.0 - (1.0 - gl_TessCoord.z) // two operations performed
gl_TessLevelOuter and gl_TessLevelInner are filled with the corresponding
output variables written by the active tessellation control shader.
Section 7.1ts2.2, Tessellation Evaluation Output Variables
gl_Position is used in the same fashion as the
corresponding output variable in the vertex shader.
[[ If EXT_tessellation_point_size is supported: ]]
gl_PointSize is used in the same fashion as the corresponding output
variable in the vertex shader.
Add to Section 7.2 "Built-In Constants", matching the
corresponding API implementation-dependent limits:
const mediump int gl_MaxTessControlInputComponents = 64;
const mediump int gl_MaxTessControlOutputComponents = 64;
const mediump int gl_MaxTessControlTextureImageUnits = 16;
const mediump int gl_MaxTessControlUniformComponents = 1024;
const mediump int gl_MaxTessControlTotalOutputComponents = 2048;
const mediump int gl_MaxTessEvaluationInputComponents = 64;
const mediump int gl_MaxTessEvaluationOutputComponents = 64;
const mediump int gl_MaxTessEvaluationTextureImageUnits = 16;
const mediump int gl_MaxTessEvaluationUniformComponents = 1024;
const mediump int gl_MaxTessPatchComponents = 120;
const mediump int gl_MaxPatchVertices = 32;
const mediump int gl_MaxTessGenLevel = 64;
Modify gl_MaxCombinedTextureImageUnits to match the API:
const mediump int gl_MaxCombinedTextureImageUnits = 96;
Modify section 8.15 "Shader Invocation Control Functions":
The shader invocation control function is only available in tessellation
control and compute shaders. It is used to control the relative
execution order of multiple shader invocations used to process a patch
(in the case of tessellation control shaders) or a workgroup (in
the case of compute shaders), which are otherwise executed with an
undefined order.
+------------------+---------------------------------------------------------------+
| Syntax | Description |
+------------------+---------------------------------------------------------------+
| void | For any given static instance of barrier(), all |
| barrier(void) | tessellation control shader invocations for a single input |
| | patch, or all compute shader invocations for a single work |
| | group must enter it before any will continue beyond it. |
+------------------+---------------------------------------------------------------+
The function barrier() provides a partially defined order of execution
between shader invocations. This ensures that values written by one
invocation prior to a given static instance of barrier() can be safely
read by other invocations after their call to the same static instance
barrier(). Because invocations may execute in an undefined order between
these barrier calls, the values of a per-vertex or per-patch output
variable for tessellation control shaders, or the values of shared
variables for compute shaders will be undefined in a number of cases
enumerated in section 4.3.6 "Output Variables" (for tessellation control
shaders) and section 4.3.7 "Shared Variables" (for compute shaders).
For tessellation control shaders, the barrier() function may only be
placed inside the function main() of the shader and may not be called
within any control flow. Barriers are also disallowed after a return
statement in the function main(). Any such misplaced barriers result in
a compile-time error.
For compute shaders, the barrier() function ...
Issues
Note: These issues apply specifically to the definition of the
EXT_tessellation_shader specification, which is based on the OpenGL
extension ARB_tessellation_shader as updated in OpenGL 4.x. Resolved
issues from ARB_tessellation_shader have been removed, but remain
largely applicable to this extension. ARB_tessellation_shader can be
found in the OpenGL Registry.
(1) What functionality was removed from ARB_tessellation_shader?
Very little. Tessellation shaders are largely self-contained
functionality and the only removed interactions with features not
supported by the underlying OpenGL ES 3.1 API and Shading Language
were:
* Fixed-function inputs and outputs present only in the GL
compatibility profile.
* gl_ClipDistance shader inputs and outputs.
* While multi-dimensional arrays are supported by GLSL-ES 3.10,
they are explicitly not supported as shader inputs and outputs,
and that decision is respected here.
* Using a tessellation evaluation shader without a tessellation
control shader is not allowed. See issue 13.
* PATCH_DEFAULT_*_LEVEL parameters (issue 13).
(2) What functionality was changed and added relative to
ARB_tessellation_shader?
- EXT_tessellation_shader closely matches OpenGL 4.4 tessellation
shader language, rather than ARB_tessellation_shader language.
- Spec language is now based off of changes introduced by
EXT_geometry_shader, especially with regard to input and output
blocks.
- Note that although this spec mentions quad primitives repeatedly,
this is not inconsistent with the lack of support for QUADS drawing
primitives in OpenGL ES. The quad primitives discussed here occur
only during patch tessellation and are emitted as triangles to later
stages of the pipeline.
- Writing point size from tessellation shaders is optional functionality.
If it's not supported or written, the point size of 1.0 is used.
- Added precision qualifiers to builtins.
- ARB_tessellation_shader required that the tessellation primitive
generator reject a patch when any outer tessellation level contained a
NaN, even if the outer tessellation level is irrelevant for the
primitive type. As that was likely unintended (see Khronos bug 11484),
EXT_tessellation_shader only rejects patches if relevant outer
tessellation levels contain NaN.
- Added program interface query properties relevant to tessellation
shaders.
(3) Are any grammar additions required in chapter 9?
Probably, but such changes are not included in the original
ARB_tessellation_shader extension, either. TBD.
(4) Should GetActiveUniformBlockiv
support queries for uniform blocks and atomic counter buffers
referenced by tessellation shaders?
RESOLVED: No. Use the new generic query interface supported by
OpenGL ES 3.1, following the resolution for other features such as compute
shaders, which also dropped these legacy tokens / queries.
(5) How are aggregate shader limits computed?
RESOLVED: Following the GL 4.4 model, but we restrict uniform
buffer bindings to 12/stage instead of 14, this results in
MAX_UNIFORM_BUFFER_BINDINGS = 72
This is 12 bindings/stage * 6 shader stages, allowing a static
partitioning of the bindings even though at most 5 stages can
appear in a program object).
MAX_COMBINED_UNIFORM_BLOCKS = 60
This is 12 blocks/stage * 5 stages, since compute shaders can't
be mixed with other stages.
MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96
This is 16 textures/stage * 6 stages.
Khronos internal bugs 5870, 8891, and 9424 cover the ARB's thinking on
these limits for GL 4.0 and beyond.
(6) Are arrays supported as shader inputs and outputs?
RESOLVED: No. In several places in the tessellation and geometry API
language based on GL 4.4, it says that "the OpenGL ES Shading Language
doesn't support multi-dimensional arrays" and restricts declarations of
inputs and outputs which are array members to blocks themselves declared
as arrays.
Strictly speaking this is no longer true. GLSL-ES 3.10 supports
multi-dimensional arrays, but also notes in issue 0 that "arrays of
arrays are not allowed as shader inputs or outputs."
Given this constraint, and since the same constraint is in OpenGL 4.4, I
propose we resolve this by continuing to limit array inputs and outputs
in this fashion, and change the language to "...doesn't support
multi-dimensional arrays as shader inputs or outputs".
(7) What component counting rules are used for inputs and outputs?
RESOLVED: In several places I've inserted language from OpenGL 4.4 to
the effect of
"Component counting rules for different variable types and variable
declarations are the same as for MAX_VERTEX_OUTPUT_COMPONENTS (see
section 11.1.2.1)."
I think this is essentially cleaning up an oversight in the earlier ARB
extension language but it is a bit orthogonal to the extension
functionality and I'm bringing it up in case this is a potential issue.
(8) What component counting rules are used for the default
uniform block?
RESOLVED: In several places I've inserted language from OpenGL 4.2 to
the effect of
"A uniform matrix in the default uniform block with single-precision
components will consume no more than 4 x min(r,c) uniform
components."
This is based on bug 5432 and is language that was later expanded in
OpenGL 4.4 and refactored into the generic "Uniform Variables" section,
which is something we should consider in the EXT extensions as well to
avoid duplication. I believe it is what we want but am noting it for the
same reason as the language in issue (8). I'm hoping to be able to
include this refactored language into the OpenGL ES 3.1 Specification,
so we can refer to it more easily here. Tracking bug 11192 has been
opened for this and this language was approved there.
(9) The edits on section 4.4.1.ts (Tessellation Evaluation Inputs)
says that "Any or all of these identifiers may be specified one or more
times in a single input layout declaration." Do we need to add in the
language from GLSL 4.40 Section 4.4 "Layout Qualifiers" that defines this?
RESOLVED: ES 3.1 will be picking up the relaxed qualifier ordering
and it is presumed that this language will be coming along with it.
In any case, the EXT_shader_io_blocks extension clarifies this.
(10) Due to HW limitations, some vendors may not be able
to support writing gl_PointSize from tessellation shaders, how should we
accomodate this?
RESOLVED: There are two extensions described in this document. The
base extension does not support writing to gl_PointSize from tessellation
shaders and the gl_PerVertex block does not include gl_PointSize.
Additionally there is a layered extension which provides the ability
to write to gl_PointSize from tessellation shaders. When this extension
is enabled, the gl_PerVertex block does include gl_PointSize and it
can be written from a tessellation control or evaluation shader as normal.
If the point-size extension is not supported, all points written
from a tessellation shader will have size of one. If the point-size
extension is supported but not enabled, or if it's enabled but
gl_PointSize is not written, it as if a point size of one was written.
Otherwise, if you statically assign gl_PointSize in the last stage
before the rasterizer, the (potentially clamped) value written will
determine the size of the point for rasterization.
(11) Do we need a separate point_size extension from the one included
in EXT_geometry_shader or can we use the some one?
RESOLVED. We will use a separate extension to allow for maximum
implementation flexibility.
(12) Can a tessellation evaluation shader be used without a tessellation
control shader?
RESULT: No. This isn't allowed in other graphics APIs, and some vendors
designed hardware based on those APIs. Attempts to draw with only one of the
two tessellation shaders active results in an INVALID_OPERATION error.
Vendors that designed hardware for ARB_tessellation_shader or versions of
OpenGL that included it may choose to relax this restriction via extension.
One implication of this is that the default tessellation levels are useless,
since an active tessellation control shader always overrides them, so they
are not included in this spec.
(13) What happens if you use "patch out" in a tessellation evaluation
shader or "patch in" in a tessellation control shader?
RESOLVED. GLSL 4.40 spec only says "Applying the patch qualifier to
inputs can only be done in tessellation evaluation shaders." and
"Applying patch to an output can only be done in a tessellation control
shader." There is also a statement that says "It is a compile-time error
to use patch in a fragment shader." In Bug 11527 the ARB decided this
should be a compile-time error as this can be determined by solely by
looking at variable declaration.
(14) Do we need to make accommodations for tile-based implementations?
RESOLVED. Yes, but it will be done as a separate extension as it is
applicable to more than just tessellation shaders.
(15) Can inputs and outputs from tessellation shaders be arrays of
structures?
RESOLVED. Yes they can. OpenGL ES 3.1 disallows passing arrays of
structures between stages. However, since vertex shader outputs
can be structures we need to add the extra level of
array-ness when these are accessed from a tessellation control shader.
Similarly this applies to outputs from a tessellation control shader
and inputs to a tessellation evaluation shader. However as in GL,
arrays of arrays are not supported.
(16) Tessellation using "point_mode" is supposed to emit each distinct
vertex produced by the tessellation primitive generator exactly once.
Are there cases where this can produce multiple vertices with the same
position?
RESOLVED: Yes. If fractional odd spacing is used, we have outer
tessellation levels that are greater than 1.0, and inner tessellation
levels less than or equal to 1.0, this can occur. If any outer level is
greater than 1.0, we will subdivide the outer edges of the patch, and
will need a subdivided patch interior to connect to. We handle this by
treating inner levels less than or equal to 1.0 as though they were
slightly greater than 1.0 ("1+epsilon").
With fractional odd spacing, inner levels between 1.0 and 3.0 will
produce a three-segment subdivision, with one full-size interior segment
and two smaller ones on the outside. The following figure illustrates
what happens to quad tessellation if the horizontal inner LOD (IL0) goes
from 3.0 toward 1.0 in fractional odd mode:
IL0==3 IL0==2 IL0=1.5 IL0=1.2
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
| +---+ | | +-----+ | | +-------+ | |+---------+|
| | | | | | | | | | | | || ||
| | | | | | | | | | | | || ||
| +---+ | | +-----+ | | +-------+ | |+---------+|
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
As the inner level approaches 1.0, the vertical inner edges in this
example get closer and closer to the outer edge. The distance between
the inner and outer vertical edges approaches zero for an inner level of
1+epsilon, and the positions of vertices produced by subdividing such
edges may be numerically indistinguishable.
(17) Why does this extension not support GLSL built-in constants for the
following limits?
- gl_MaxTessControlAtomicCounters
- gl_MaxTessEvaluationAtomicCounters
- gl_MaxTessControlAtomicCounterBuffers
- gl_MaxTessEvaluationAtomicCounterBuffers
- gl_MaxTessControlImageUniforms
- gl_MaxTessEvaluationImageUniforms
RESOLVED: These were accidentally left out when drafting the extension,
and cannot be added now because shipping implementations don't support
them. This was fixed when these extensions were promoted into OpenGL ES
Shading Language 3.20.
Revision History
Rev. Date Author Changes
---- -------- --------- -------------------------------------------------
25 12/10/18 Jon Leech Use 'workgroup' consistently throughout (Bug
11723, internal API issue 87).
24 02/03/17 Jon Leech Add issue 17 noting missing GLSL built-in constants
(public bug 1427).
23 05/31/16 Jon Leech Note that primitive ID counters are reset to zero
after each instance drawn (Bug 14024).
22 04/29/16 Jon Leech Fix GLSL-ES built-in constants to match API
limits (Bug 12823).
21 04/27/16 Jon Leech Reduce minimum value of
MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS_EXT Z+ GetIntegerv 2048 Total no. components for TCS 11.1ts.1.2
from 4096 to 2048 (Bug 12823)
20 07/23/15 Jon Leech Reduce minimum value of
MAX_TESS_{CONTROL,EVALUATION}_{IN,OUT}PUT_COMPONENTS
to 64 (Bug 12823)
19 05/05/15 dkoch Allow arrays for both per-patch and per-vertex
TCS outputs (Bug 13658).
Fix typo in issue 15 suggesting that VS outputs
could be an array of structures (Bug 13824).
18 04/20/15 Jon Leech Remove "per-patch" part of description of
MAX_TESS_CONTROL_TOTAL_OUTPUT_COMPONENTS
(Bug 13765).
17 04/29/14 dkoch Add missing edits to Section 12.1 for XFB
16 04/25/14 dkoch Allow compile-time error for improperly sized
per-vertex inputs/outputs (Bug 12185).
Allow link-time error for TCS per-vertex outputs
not indexed by gl_InvocationID (Bug 12112).
Add issue 15 clarifying arrays of structs.
Clarify that the tessellation primitive
generator may produce multiple vertices with
the same gl_TessCoord values in point mode when
fractional odd spacing is used with an inner
tessellation level less than or equal to 1.0
(bug 11979) (Issue 16).
15 04/01/14 dkoch Update contributors, removed duplicated line.
14 03/28/14 dkoch Fix typo in Isoline tessellation: lines are sub-
divided based on second outer tessellation level
not the first (from ARB_ts v.19 and GL 4.4)
13 03/26/14 Jon Leech Sync with released ES 3.1 specs. Reflow text.
12 03/21/14 dkoch Update contributors, remove bounding box.
11 03/10/14 Jon Leech Rebase on OpenGL ES 3.1 and change suffix to EXT.
10 02/27/14 dkoch Add API edits for bounding box. Issue 15, 16.
9 02/24/14 dkoch Add missing entry point augmentation.
8 02/20/14 dkoch
- resolved issue 14, added language to make it a compile-time error
7 02/12/14 dkoch
- Resolve issues 6, 7, and 12. Add issues 14 and 15.
- Add IS_PER_PATCH program interface query.
- require EXT_gpu_shader5 for 'precise' functionality.
- Add error condition for 'patch in' in fragment shader.
6 01/20/14 dkoch
- Edits to require both TCS and TES.
- Remove unnecessary PatchParameterfv and default tessellation levels params.
- Fix typo in enum name.
- Update link error for duplicate locations.
5 12/19/13 dkoch
- remove legacy NV_primitive_restart interaction
- add PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED from GL 4.4 (Bug 10364)
- require EXT_shader_io_blocks
- add optional EXT_tessellation_point_size extension
- various minor editorial changes
4 11/28/13 dkoch Minor updates
- Added missing TESS_*_BIT_EXT to overview.
- Explicitly mention INVALID_ENUM errors as in GL 4.4.
- clarify that a PO or PPO using Tess needs a vertex shader (per GL 4.4).
- Add uniform matrix counting rule for TCS to match TES (per Issue 9).
- remove dangling reference to gl_VerticesOut.
- fix a couple remaining references to multiple shaders.
- fix a few typos, grammar and formatting issues.
- added interaction with OES_shader_multisample_interpolation.
3 11/20/13 Jon Leech Minor updates
- Refer to ES 3.1 instead of ES 3plus.
2 11/06/13 Jon Leech Updates based on Daniel Koch's feedback.
- Remove references from desktop language allowing multiple shader
objects per stage.
- Disallow multi-dimensional arrays as shader inputs & outputs,
consistent with OpenGL ES 3.1 and issue 7.
- Modified sections 4.3.4 / 4.3.6 to treat "centroid in" and "sample
in" as storage qualifiers on par with "in", in keeping with ESSL
3.00 not having yet refactored storage qualifiers as GLSL 4.40 has
already done. Reverted input / output matching to require matches
in everything except in/out and precision, also based on ESSL
3.00. Add "sample in" / "sample out" from
OES_shader_multisample_interpolation.
1 11/03/13 Jon Leech Initial version based on ARB_tessellation_shader.