xref: /third_party/openGLES/extensions/NV/NV_tessellation_program5.txt

Name

    NV_tessellation_program5

Name Strings

    (none)

Contact

    Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)

Status

    Shipping.

Version

    Last Modified Date:         12/19/2011
    NVIDIA Revision:            3

Number

    391

Dependencies

    OpenGL 1.1 is required.

    This extension is written against the OpenGL 2.1 specification.

    NV_gpu_program5 is required.  This extension is supported if and only
    "GL_NV_gpu_program5" is found in the extension string.  This extension is
    written against the NV_gpu_program5 extension.

    This specification interacts with ARB_tessellation_shader.

    This specification interacts with NV_parameter_buffer_object.

Overview

    This extension, in conjunction with the ARB_tessellation_shader extension,
    introduces a new tessellation stage to the OpenGL primitive processing
    pipeline.  The ARB_tessellation_shader extension provides programmable
    shading functionality using the OpenGL Shading Language as its base; this
    extension provides assembly programmable shaders building on the family of
    assembly programmability extensions including ARB_vertex_program,
    ARB_fragment_program, NV_gpu_program4, and NV_geometry_program4.

    This extension adds a new basic primitive type, called a patch, which
    consists of an array of vertices plus some associated per-patch state.  It
    also adds two new assembly program types:  a tessellation control program
    that transforms a patch into a new patch and a tessellation evaluation
    program that computes the position and attributes of each vertex produced
    by the tesselator.

    When tessellation is active, it begins by running the optional
    tessellation control program, if enabled.  This program consumes a
    variable-size 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 program invocations are performed
    -- one per output patch vertex.  Each tessellation control program
    invocation writes all the attributes of its corresponding output patch
    vertex.  A tessellation control program may also read the per-vertex
    outputs of other tessellation control program invocations, as well as read
    and write shared per-patch outputs.  The tessellation control program
    invocations for a single patch effectively run as a group.  The GL
    automatically synchronizes threads to ensure that when executing a given
    instruction, all previous instructions have completed for all program
    invocations in the group.

    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_NV splits a quad-shaped patch into a set of line
    strips spanning the patch.  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 program is run to compute its position and other
    attributes of the vertex, using its (u,v) or (u,v,w) coordinate.  When
    computing the final vertex attributes, the tessellation evaluation program
    can also read the attributes of any of the vertices of the patch written
    by the tessellation control program.  Tessellation evaluation program
    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 program or fixed-function vertex processing.  The primitives
    generated by the tessellator are passed further down the OpenGL pipeline,
    where they can be used as inputs to geometry programs, transform feedback,
    and the rasterizer.

    The tessellation control and evaluation programs are both optional.  If
    neither program type is present, the tessellation stage has no effect.  If
    no tessellation control program is present, the input patch provided by
    the application is passed directly to the tessellation primitive
    generator, and a set of fixed tessellation level parameters (specified via
    the PatchParameterfv function) is used to control primitive generation.
    If no tessellation evaluation program is present, the output patch
    produced by the tessellation control program is passed as a patch to
    subsequent pipeline stages, where it can be consumed by geometry programs,
    transform feedback, or the rasterizer.


New Procedures and Functions

    None

    (Note:  The PatchParameteri and PatchParameterfv functions from
     ARB_tessellation_shader will also be used by this extension.)

New Tokens

    Accepted by the <cap> parameter of Disable, Enable, and IsEnabled, 
    by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 
    and GetDoublev, and by the <target> parameter of ProgramStringARB,
    BindProgramARB, ProgramEnvParameter4[df][v]ARB,
    ProgramLocalParameter4[df][v]ARB, GetProgramEnvParameter[df]vARB, 
    GetProgramLocalParameter[df]vARB, GetProgramivARB and
    GetProgramStringARB:

        TESS_CONTROL_PROGRAM_NV                         0x891E
        TESS_EVALUATION_PROGRAM_NV                      0x891F

    Accepted by the <target> parameter of ProgramBufferParametersfvNV,
    ProgramBufferParametersIivNV, and ProgramBufferParametersIuivNV,
    BindBufferRangeNV, BindBufferOffsetNV, BindBufferBaseNV, and BindBuffer
    and the <value> parameter of GetIntegerIndexedvEXT:

        TESS_CONTROL_PROGRAM_PARAMETER_BUFFER_NV        0x8C74
        TESS_EVALUATION_PROGRAM_PARAMETER_BUFFER_NV     0x8C75

    Accepted by the <pname> parameter of GetProgramivARB:

        MAX_PROGRAM_PATCH_ATTRIBS_NV                    0x86D8

    (Note:  Various enumerants from ARB_tessellation_shader will also be used
     by this extension.)


Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation)

    (Incorporate Section 2.X of the ARB_tessellation_shader specification,
     Tessellation in its entirety.)

    Insert a new section after Section 2.X.1 in ARB_tessellation_shader,
    Tessellation Control Shaders

    Tessellation Control Programs

    Each patch primitive may be optionally processed by a tessellation control
    program, which operates similarly to the tessellation control shader
    described above.  Tessellation control programs are enabled by calling
    Enable with the value TESS_CONTROL_PROGRAM_NV.  If a GLSL program is
    active, the tessellation control program enable is ignored and treated as
    disabled unless the program contains only fragment shaders.

    When enabled, each patch primitive received by the GL will be processed by
    the tessellation control program to produce a new patch.  The tessellation
    control program emits a patch with a fixed number of vertices, given by
    the value specified in the VERTICES_OUT declaration.  It computes the
    attributes of each vertex of the output patch in parallel, and assembles
    the emitted vertices into an output patch.  The program also computes
    per-patch tessellation level values that control the number of vertices
    produced by the tessellation primitive generator when that patch is
    processed.  The program may also compute additional generic per-patch
    attributes that may be accessed by invocations of the tessellation
    evaluation program or a subsequent geometry program when processing the
    patch.  When the tessellation control program completes, the input patch
    is discarded and the output patch is processed by the remainder of the GL
    pipeline.

    Each patch processed by the tessellation control program will result in
    multiple program invocations (threads), with one invocation per output
    patch vertex.  Each program invocation has a corresponding output patch
    vertex, and can write per-vertex attributes only for that vertex.  All
    program invocations may read and write per-patch attributes of the output
    patch, and may read per-vertex attributes of any vertex in the output
    patch.

    The tessellation control program threads are run as a group, and execute
    effectively in lock-step.  In this model, the execution of each
    instruction completes for all active threads before the execution of
    subsequent instruction is started.  All threads in the group are initially
    active, but the set of active threads change as flow-control instructions
    are encountered.  Full details on the execution model are specified in
    Section 2.X.5.

    Tessellation control programs execute using the instruction set documented
    in the GL_NV_gpu_program5 extension specification.  Tessellation control
    programs can read attributes from all vertices of the input patch, and
    each vertex attribute access must identify the vertex number being
    accessed.  For example, "vertex[1].position" and "vertex.in[1].position"
    identify the position of the second vertex (numbered "1") in the input
    patch.  Programs may also read attributes of all vertices of the output
    patch (e.g., "vertex.out[2].position") and per-patch attributes of the
    output patch (e.g., "primitive.out.attrib[3]").  In both cases, the output
    patch vertices or attributes accessed in this manner are undefined unless
    written by a previous instruction executed on one of the threads.
    Programs may also write attributes of their corresponding vertex in the
    output patch (e.g., "result.attrib[0]") and shared per-patch attributes
    (e.g., "result.patch.attrib[4]").  When writing output patch vertex
    attributes, a vertex number is not supplied.
    
    The only input primitives supported by tessellation control programs are
    patches.  The error INVALID_OPERATION is generated by Begin (or vertex
    array functions that implicitly call Begin) if a tessellation control
    program is active and <mode> is not PATCHES_NV.


    Modify section after Section 2.X.2 of ARB_tessellation_shader,
    Tessellation Primitive Generation

    (add to the end of the section describing the operation of the
     tessellation primitive generator when assembly tessellation evaluation
     programs are used)

    If no GLSL program object is active, or if the active program contains
    only a fragment shader, the tessellation primitive generator will be
    active if and only if an assembly tessellation evaluation program is
    enabled.  When a tessellation evaluation program is used, the tessellation
    primitive generator will operate in exactly the manner describe above,
    except that the parameters controlling tessellation will be taken from
    declaration statements in the tessellation evaluation program.  The
    declaration statements used to specify each tessellation parameter are as
    described in Table X.1.  

          GLSL Program Parameter        TEP Declaration
          ------------------------      -----------------
          TESS_GEN_MODE_NV              TESS_MODE
          TESS_GEN_SPACING_NV           TESS_SPACING
          TESS_GEN_VERTEX_ORDER_NV      TESS_VERTEX_ORDER
          TESS_GEN_POINT_MODE_NV        TESS_POINT_MODE

      Table X.1, Parameters used to control tessellation when a program object
      with a tessellation evaluation shader is active and their tessellation
      evaluation program equivalents.

    If no tessellation control program is enabled, the default tessellation
    levels specified by calling PatchParameterfvNV with a <pname> of
    PATCH_DEFAULT_OUTER_LEVEL_NV or PATCH_DEFAULT_INNER_LEVEL_NV.

    If a GLSL program containing only a fragment shader is active, any
    tessellation-related program parameters in effect when the program was
    linked have no effect on tessellation.


    Insert a new section after Section 2.X.3 in ARB_tessellation_shader,
    Tessellation Evaluation Shaders

    Tessellation Evaluation Programs

    If a tessellation evaluation program is active, the tessellation primitive
    generator will subdivide a basic primitive and run the tessellation
    evaluation program on each generated vertex.  Tessellation evaluation
    programs are enabled by calling Enable with the value
    TESS_EVALUATION_PROGRAM_NV.  If a GLSL program is active, the tessellation
    evaluation program enable is ignored and treated as disabled unless the
    program contains only fragment shaders.

    When tessellation evaluation programs are enabled, each patch primitive
    received by the GL will trigger the tessellation primitive generator to
    perform primitive subdivision and generate a new set of vertices.  For
    each generated vertex, the tessellation evaluation program is invoked.
    Each tessellation evaluation program invocation produces a single output
    vertex.  These vertices are assembled into primitives according to the
    subdivision produced by the tessellation primitive generator, and these
    primitives are processed by the remainder of the GL pipeline.  The input
    patch used by the tessellation evaluation program is discarded.

    Tessellation evaluation programs execute using the instruction set
    documented in the GL_NV_gpu_program5 extension specification and in a
    manner similar to vertex programs.  Tessellation control programs can read
    attributes from all vertices of the input patch, and each vertex attribute
    access must identify the vertex number being accessed.  For example,
    "vertex[1].position" identifies the transformed position of "vertex[1]",
    which is the second vertex in the input patch.  Additionally, the special
    attribute variable "vertex.tesscoord" is available to specify the location
    of the vertex within the subdivided primitive.  Per-patch attributes,
    including the tessellation levels, are also available.

    The only input primitives supported by tessellation evaluation programs
    are patches.  The error INVALID_OPERATION is generated by Begin (or vertex
    array functions that implicitly call Begin) if a tessellation evaluation
    program is active and <mode> is not PATCHES_NV.


    Modify Section 2.X.2 of NV_gpu_program4, Program Grammar

    (replace third paragraph)

    Tessellation control programs are required to begin with the header string
    "!!NVtcp5.0".  Tessellation evaluation programs are required to begin with
    the header string "!!NVtep5.0".  These header strings identify the
    subsequent program body as being a tessellation control or evaluation
    program, respectively, and indicate that they should be parsed according
    to the base NV_gpu_program5 grammar plus the additions below.  Program
    string parsing begins with the character immediately following the header
    string.

    (For tessellation control programs, add the following grammar rules to the
     NV_gpu_program5 base grammar)

    <declSequence>          ::= <declaration> <declSequence>

    <attribUseV>            ::= <attribColor> "." <faceType> <swizzleSuffix>
                              | <attribColor> "." <faceType> "." <colorType> 
                                <swizzleSuffix>

    <resultUseW>            ::= <resultVarName> <arrayMem> <optWriteMask>
                              | <resultColor> <optWriteMask>
                              | <resultColor> "." <colorType> <optWriteMask>
                              | <resultColor> "." <faceType> <optWriteMask>
                              | <resultColor> "." <faceType> "." <colorType> 
                                "." <optWriteMask>

    <resultUseD>            ::= <resultColor> <optFaceColorType>
                              | <resultMulti>

    <optFaceColorType>      ::= <optColorType>
                              | "." <faceType> <optColorType>

    <declaration>           ::= "VERTICES_OUT" <int>

    <attribBasic>           ::= <vtxPrefix> "position"
                              | <vtxPrefix> "fogcoord"
                              | <vtxPrefix> "pointsize"
                              | <vtxPrefix> "id"
                              | <attribTexCoord> <optArrayMemAbs>
                              | <attribClip> <arrayMemAbs>
                              | <attribGeneric> <arrayMemAbs>
                              | <primPrefix> "." "id"
                              | <primPrefix> "." "invocation"
                              | <primPrefix> "." "vertexcount"
                              | <attribTessOuter> <arrayMemAbs>
                              | <attribTessInner> <arrayMemAbs>
                              | <attribPatchGeneric> <arrayMemAbs>

    <attribColor>           ::= <vtxPrefix> "color"

    <attribMulti>           ::= <attribTexCoord> <arrayRange>
                              | <attribClip> <arrayRange>
                              | <attribGeneric> <arrayRange>
                              | <attribTessOuter> <arrayRange>
                              | <attribTessInner> <arrayRange>
                              | <attribPatchGeneric> <arrayRange>

    <attribTexCoord>        ::= <vtxPrefix> "texcoord"

    <attribClip>            ::= <vtxPrefix> "clip"

    <attribGeneric>         ::= <vtxPrefix> "attrib"

    <attribTessOuter>       ::= <primPrefix> "." "tessouter"

    <attribTessInner>       ::= <primPrefix> "." "tessinner"

    <attribPatchGeneric>    ::= <primPrefix> "." "patch" "." "attrib"

    <vtxPrefix>             ::= "vertex" "."
                              | "vertex" <arrayMemAbs> "."
                              | "vertex" "." "in" <optArrayMemAbs> "."
                              | "vertex" "." "out" <optArrayMemAbs> "."

    <primPrefix>            ::= "primitive" "."
                              | "primitive" "." "in" "."
                              | "primitive" "." "out" "."

    <resultBasic>           ::= <resPrefix> "position"
                              | <resPrefix> "fogcoord"
                              | <resPrefix> "pointsize"
                              | <resultTexCoord> <optArrayMemAbs>
                              | <resultClip> <arrayMemAbs>
                              | <resultGeneric> <arrayMemAbs>
                              | <resPrefix> "id"
                              | <resultTessOuter> <arrayMemAbs>
                              | <resultTessInner> <arrayMemAbs>
                              | <resultPatchGeneric> <arrayMemAbs>

    <resultColor>           ::= <resPrefix> "color"

    <resultMulti>           ::= <resultTexCoord> <arrayRange>
                              | <resultClip> <arrayRange>
                              | <resultGeneric> <arrayRange>
                              | <resultTessOuter> <arrayRange>
                              | <resultTessInner> <arrayRange>
                              | <resultPatchGeneric> <arrayRange>

    <resultTexCoord>        ::= <resPrefix> "texcoord"

    <resultClip>            ::= <resPrefix> "clip"

    <resultGeneric>         ::= <resPrefix> "attrib"

    <resultTessOuter>       ::= <resPrefix> "." "patch" "." "tessouter"

    <resultTessInner>       ::= <resPrefix> "." "patch" "." "tessinner"

    <resultPatchGeneric>    ::= <resPrefix> "." "patch" "." "attrib"

    <resPrefix>             ::= "result" "."


    (For tessellation evaluation programs, add the following grammar rules to
     the NV_gpu_program5 base grammar)

    <declSequence>          ::= <declaration> <declSequence>

    <attribUseV>            ::= <attribColor> "." <faceType> <swizzleSuffix>
                              | <attribColor> "." <faceType> "." <colorType> 
                                <swizzleSuffix>

    <resultUseW>            ::= <resultVarName> <arrayMem> <optWriteMask>
                              | <resultColor> <optWriteMask>
                              | <resultColor> "." <colorType> <optWriteMask>
                              | <resultColor> "." <faceType> <optWriteMask>
                              | <resultColor> "." <faceType> "." <colorType> 
                                "." <optWriteMask>

    <resultUseD>            ::= <resultColor> <optFaceColorType>
                              | <resultMulti>

    <optFaceColorType>      ::= <optColorType>
                              | "." <faceType> <optColorType>

    <declaration>           ::= "TESS_MODE" <declTessMode>
                              | "TESS_SPACING" <declTessSpacing>
                              | "TESS_VERTEX_ORDER" <declTessVtxOrder>
                              | "TESS_POINT_MODE"

    <declTessMode>          ::= "TRIANGLES"
                              | "QUADS"
                              | "ISOLINES"

    <declTessSpacing>       ::= "EQUAL"
                              | "FRACTIONAL_ODD"
                              | "FRACTIONAL_EVEN"

    <declTessVtxOrder>      ::= "CW"
                              | "CCW"

    <attribBasic>           ::= <vtxPrefix> "position"
                              | <vtxPrefix> "fogcoord"
                              | <vtxPrefix> "pointsize"
                              | <vtxPrefix> "id"
                              | <attribTexCoord> <optArrayMemAbs>
                              | <attribClip> <arrayMemAbs>
                              | <attribGeneric> <arrayMemAbs>
                              | "vertex" "." "tesscoord"
                              | <primPrefix> "id"
                              | <primPrefix> "vertexcount"
                              | <attribTessOuter> <optArrayMemAbs>
                              | <attribTessInner> <optArrayMemAbs>
                              | <attribPatchGeneric> <optArrayMemAbs>

    <attribColor>           ::= <vtxPrefix> "color"

    <attribMulti>           ::= <attribTexCoord> <arrayRange>
                              | <attribClip> <arrayRange>
                              | <attribGeneric> <arrayRange>
                              | <attribTessOuter> <arrayRange>
                              | <attribTessInner> <arrayRange>
                              | <attribPatchGeneric> <arrayRange>

    <attribTexCoord>        ::= <vtxPrefix> "texcoord"

    <attribClip>            ::= <vtxPrefix> "clip"

    <attribGeneric>         ::= <vtxPrefix> "attrib"

    <attribTessOuter>       ::= <primPrefix> "." "tessouter"

    <attribTessInner>       ::= <primPrefix> "." "tessinner"

    <attribPatchGeneric>    ::= <primPrefix> "." "patch" "." "attrib"

    <vtxPrefix>             ::= "vertex" "."
                              | "vertex" <arrayMemAbs> "."
                              | "vertex" "." "in" <optArrayMemAbs> "."
                              | "vertex" "." "out" <optArrayMemAbs> "."

    <primPrefix>            ::= "primitive" "."
                              | "primitive" "." "in" "."

    <resultBasic>           ::= <resPrefix> "position"
                              | <resPrefix> "fogcoord"
                              | <resPrefix> "pointsize"
                              | <resultTexCoord> <optArrayMemAbs>
                              | <resultClip> <arrayMemAbs>
                              | <resultGeneric> <arrayMemAbs>
                              | <resPrefix> "id"

    <resultColor>           ::= <resPrefix> "color"

    <resultMulti>           ::= <resultTexCoord> <arrayRange>
                              | <resultClip> <arrayRange>
                              | <resultGeneric> <arrayRange>

    <resultTexCoord>        ::= <resPrefix> "texcoord"

    <resultClip>            ::= <resPrefix> "clip"

    <resultGeneric>         ::= <resPrefix> "attrib"

    <resPrefix>             ::= "result" "."
   

    (add the following subsection to section 2.X.3.2 of NV_gpu_program4, 
     Program Attribute Variables)

    Tessellation control and evaluation program attribute variables describe
    inputs accessible to the program.  There are several different classes of
    attribute bindings available, identified by the binding prefix.  The set
    of attribute binding classes and their corresponding prefixes are
    described in Table X.2.  The specific attributes for each class are
    identified by a binding suffix.

      Attribute Binding Prefix   Description
      ------------------------   ------------------------------------------
      vertex[m]                  Vertex <m> of the input patch
      vertex.in[m]               Vertex <m> of the input patch
      vertex                     Array spanning vertices of the input patch
                                   or the specific vertex being evaluated
      vertex.in                  Array spanning vertices of the input patch
                                   or the specific vertex being evaluated
      primitive                  Per-patch value of the input patch
      primitive.in               Per-patch value of the input patch
      vertex.out[m]              Vertex <m> of the output patch
      vertex.out                 Array spanning vertices of the output patch
      primitive.out              Per-patch value of the output patch

      Table X.2, Tessellation Control and Evaluation Program Attribute Binding
      Prefixes.  <m> refers to a constant integer vertex number in the input
      or output patch.

    If an attribute binding prefix matches "vertex[m]" or "vertex.in[m]", the
    attribute binding refers to an attribute of the vertex numbered <m> in the
    input patch.  If <m> is greater than or equal to the number of vertices in
    the input patch, the values corresponding to the binding are undefined.

    If an attribute binding prefix matches "vertex" or "vertex.in" and the
    suffix identifies an attribute of the vertex being processed by a
    tessellation evaluation program (e.g., "tesscoord"), the attribute binding
    refers to that attribute.

    If an attribute binding prefix matches "vertex" or "vertex.in" and the
    suffix identifies any other vertex attribute, the attribute binding refers
    to that specific attribute for each of the vertices of the input patch.
    Bindings of this form may only be used in explicit variable declarations.
    If the variable declaration identifies an array, the program will fail to
    load unless each binding in the binding list uses an attribute prefix of
    this form.  When such variables are used in instructions, they must be
    accessed as an array, with the first array index identifying the vertex
    number.  If such variables are declared as an array, a second array index
    must be provided to identify the specific per-vertex attribute to select.
    If the first array index is negative or greater than or equal to the
    number of vertices in the input patch, the value obtained is undefined.

    If an attribute binding prefix matches "primitive" or "primitive.in", the
    attribute binding refers to an attribute of the input patch.

    If a tessellation control program attribute binding prefix matches
    "vertex.out[m]", the attribute binding refers to an attribute of the
    vertex numbered <m> in the output patch.  These attributes correspond to
    per-vertex output values written by the tessellation control program
    thread numbered <m>.  A program will fail to load if the vertex number <m>
    is greater than or equal to the number of vertices in the output patch.
    Tessellation evaluation programs do not have an output patch and do not
    support this attribute binding prefix.

    If a tessellation control program attribute binding prefix matches
    "vertex.out", the attribute binding identifies a specific attribute for
    each of the vertices of the output patch.  Bindings of this form may only
    be used in explicit variable declarations, and all the usage rules
    described above for bindings using the prefix "vertex.in" apply.  If the
    vertex number identified when accessing such variables is negative or
    greater than or equal to the number of vertices in the output patch, the
    resulting values are undefined.  Tessellation evaluation programs do not
    have an output patch and do not support this attribute binding suffix.

    If an attribute binding prefix matches "primitive.out", the attribute
    binding refers to a per-patch attribute of the output patch.  These
    attributes correspond to per-patch result values written by one of the
    tessellation control program threads.  Tessellation evaluation programs do
    not have an output patch and do not support this attribute binding suffix.

    The following examples illustrate various legal and illegal program
    bindings and their meanings.

      ATTRIB pos = vertex.position;
      ATTRIB pos2 = vertex.in[2].position;
      ATTRIB outpos = vertex.out.position; 
      ATTRIB outpos2 = vertex.out[2].position; 
      ATTRIB texcoords[] = { vertex.texcoord[0..3] };
      ATTRIB tcoords1[4] = { vertex[1].texcoord[1..4] };
      ATTRIB outattr[2] = { vertex.out.attrib[0..1] };
      INT TEMP A0;
      ...
      MOV R0, pos[1];                   # position of input vertex 1
      MOV R0, vertex[1].position;       # position of input vertex 1
      MOV R0, pos2;                     # position of input vertex 2
      MOV R0, outpos;                   # ILLEGAL - needs a vertex number
      MOV R0, outpos[1];                # position of output vertex 1 (TCP)
      MOV R0, outpos2;                  # position of output vertex 2 (TCP)
      MOV R0, texcoords[A0.x][1];       # texcoord 1 of input vertex A0.x
      MOV R0, texcoords[A0.x][A0.y];    # texcoord A0.y of input vertex A0.x
      MOV R0, tcoords1[2];              # texcoord 3 of input vertex 1
      MOV R0, outattr[A0.x][1];         # generic attr 1 of output vertex 
                                        # A0.x (TCP)
      MOV R0, vertex[A0.x].texcoord[1]; # ILLEGAL -- vertex number must be 
                                        # constant or must use variables like
                                        # "texcoords" using bindings w/o
                                        # vertex numbers

    Attributes from input patch vertices will be obtained from the per-vertex
    outputs of the previous program used to generate the vertex in question.
    For tessellation evaluation programs, that previous program would be the
    tessellation control program, if enabled, or the vertex program otherwise.
    For tessellation control programs, the previous program is always the
    vertex program.  Tessellation control and evaluation program attributes
    should be read using the same component data type used to write the
    corresponding vertex program results.  If input patch vertices are
    specified to come from vertex program outputs but no vertex program is
    enabled, the values are instead produced from fixed-function vertex
    processing.  The value of any attribute corresponding to a vertex output
    not written by the previous program stage is undefined, as are the values
    of all generic attributes if the vertex was produced by fixed-function
    vertex processing.

    Attributes from output patch vertices are only available in tessellation
    control programs, and will be obtained from the per-vertex outputs of the
    same program.  When executing an instruction, the values of any output
    patch vertex attribute are undefined unless the corresponding program
    output was written by a previously executed instruction.

    Per-patch attributes of the input patch are only available in tessellation
    evaluation and geometry programs.  If a tessellation control program is
    enabled, they will be obtained from the corresponding per-patch outputs of
    the tessellation control program producing the patch, and any attributes
    not written by any thread of the control program are undefined.  If no
    tessellation control program is enabled, the inner and outer tessellation
    levels are taken from the default tessellation levels, and all other
    per-patch attributes are undefined.

    Per-patch attributes of the output patch are available only in
    tessellation control programs and will be obtained from the per-patch
    outputs of the same program.  When executing an instruction, the values of
    any output patch attribute are undefined unless the corresponding program
    output was written by a previously executed instruction.

    The attributes of the vertices of an input or output patch vertex are
    selected by an attribute binding suffix, as identified in Table X.3.  All
    such bindings correspond to one of multiple patch vertices and require a
    vertex number, either in the binding prefix used in the instruction or as
    the first array index when using an explicitly declared attribute variable
    whose bindings have no vertex number.

      Vertex Binding Suffix      Components   Description
      ------------------------   ----------   ----------------------------
      position                    (x,y,z,w)   clip coordinates
      color                       (r,g,b,a)   front primary color
      color.primary               (r,g,b,a)   front primary color
      color.secondary             (r,g,b,a)   front secondary color
      color.front                 (r,g,b,a)   front primary color
      color.front.primary         (r,g,b,a)   front primary color
      color.front.secondary       (r,g,b,a)   front secondary color
      color.back                  (r,g,b,a)   back primary color
      color.back.primary          (r,g,b,a)   back primary color
      color.back.secondary        (r,g,b,a)   back secondary color
      fogcoord                    (f,-,-,-)   fog coordinate
      pointsize                   (s,-,-,-)   point size
      texcoord                    (s,t,r,q)   texture coordinate, unit 0
      texcoord[n]                 (s,t,r,q)   texture coordinate, unit n
      attrib[n]                   (x,y,z,w)   generic interpolant n
      clip[n]                     (d,-,-,-)   clip plane distance
      texcoord[n..o]              (s,t,r,q)   array of texture coordinates
      attrib[n..o]                (x,y,z,w)   array of generic interpolants
      clip[n..o]                  (d,-,-,-)   array of clip distances
      id                          (id,-,-,-)  vertex id

      Table X.3, Tessellation Control and Evaluation Program Per-Patch Vertex
      Attribute Bindings.  <n> and <o> refer to integer constants.

    If an attribute binding suffix matches "position", the "x", "y", "z" and
    "w" components of the attribute variable are filled with the "x", "y",
    "z", and "w" components, respectively, of the transformed position of the
    specified vertex, in clip coordinates.

    If an attribute binding suffix matches any binding in Table X.3 beginning
    with "color", the "x", "y", "z", and "w" components of the attribute
    variable are filled with the "r", "g", "b", and "a" components,
    respectively, of the corresponding color of the specified vertex.
    Bindings containing "front" and "back" refer to the front and back colors,
    respectively.  Bindings containing "primary" and "secondary" refer to
    primary and secondary colors, respectively.  If face or color type is
    omitted in the binding, the binding is treated as though "front" and
    "primary", respectively, were specified.

    If an attribute binding suffix matches "fogcoord", the "x" component of
    the attribute variable is filled with the fog coordinate of the specified
    vertex.  The "y", "z", and "w" components are undefined.

    If an attribute binding suffix matches "pointsize", the "x" component of
    the attribute variable is filled with the point size of the specified
    vertex.  If the vertex was produced by fixed-function vertex processing,
    the point size attribute is undefined.  The "y", "z", and "w" components
    are always undefined.

    If an attribute binding suffix matches "texcoord" or "texcoord[n]", the
    "x", "y", "z", and "w" coordinates of the attribute variable are filled
    with the "s", "t", "r", and "q" coordinates of texture coordinate set <n>
    of the specified vertex.  If <n> is omitted, texture coordinate set zero
    is used.

    If an attribute binding suffix matches "attrib[n]", the "x", "y", "z", and
    "w" components of the attribute variable are filled with the "x", "y",
    "z", and "w" coordinates of generic interpolant <n> of the specified.  All
    generic interpolants will be undefined when the vertex is produced by
    fixed-function vertex processing.

    If an attribute binding suffix matches "clip[n]", the "x" component of the
    attribute variable is filled the clip distance of the specified vertex for
    clip plane <n>, as written by the vertex program.  If the vertex was
    produced by fixed-function vertex processing or a position-invariant
    vertex program, the clip distance is obtained by computing the per-clip
    plane dot product:

      (p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e),

    at the vertex location, as described in section 2.12.  The clip distance
    for clip plane <n> is undefined if clip plane <n> is disabled.  The "y",
    "z", and "w" components of the attribute are undefined.

    If an attribute binding suffix matches "texcoord[n..o]", "attrib[n..o]",
    or "clip[n..o]", a sequence of 1+<o>-<n> texture coordinate, generic
    attribute, or clip distance bindings is created.  For texture coordinate
    bindings, it is as though the sequence "vertex[m].texcoord[n],
    vertex[m].texcoord[n+1], ...  vertex[m].texcoord[o]" were specfied.  These
    bindings are available only in explicit declarations of array variables.
    A program will fail to load if <n> is greater than <o>.

    If an attribute binding suffix matches "id", the "x" component is filled
    with the vertex ID of the specified vertex.  If the vertex was generated
    by a previous program, the attribute variable is filled with the vertex ID
    result written by that program.  Otherwise, the vertex ID is undefined.
    The "y", "z", and "w" components of the attribute are undefined.

    Attribute bindings other than those corresponding to individual vertices
    in input and output patch are identified in Table X.4.  All of these items
    except for "vertex.tesscoord" are per-patch attributes, and require one of
    the prefixes beginning with "primitive".

      Primitive Binding Suffix   Components  Description
      ------------------------   ----------  ----------------------------
      id                         (id,-,-,-)  primitive number
      invocation                 (id,-,-,-)  tess. control invocation
      vertexcount                (c,-,-,-)   vertices in primitive
      tessouter[n]               (x,-,-,-)   outer tess. level n
      tessinner[n]               (x,-,-,-)   inner tess. level n
      patch.attrib[n]            (x,y,z,w)   generic patch attribute n
      tessouter[n..o]            (x,-,-,-)   outer tess. levels n to o
      tessinner[n..o]            (x,-,-,-)   inner tess. levels n to o
      patch.attrib[n..o]         (x,y,z,w)   generic patch attrib n to o
      vertex.tesscoord (*)       (u,v,w,-)   tess. coordinate in [0,1]

      Table X.4, Tessellation Control and Evaluation Miscellaneous Attribute
      Bindings.  <n> and <o> refer to integer constants.

    If an attribute binding suffix matches "id", the "x" component is filled
    with the number of primitives received by the GL since the last time Begin
    was called (directly or indirectly via vertex array functions).  The first
    primitive generated after a Begin is numbered zero, and the primitive ID
    counter is incremented after every individual point, line, or polygon
    primitive is processed.  Restarting a primitive topology using the
    primitive restart index has no effect on the primitive ID counter.  The
    "y", "z", and "w" components of the variable are always undefined.  This
    suffix may only be used with the prefixes "primitive", "primitive.in", or
    "primitive.out", and produces the same value in all cases.

    If a tessellation control program attribute binding suffix matches
    "invocation", the "x" component is filled with the thread number of the
    program invocation.  The invocation number identifies the number of the
    vertex in the output patch whose attributes are produced by this
    invocation, and is in the range [0..<n>-1], where <n> is given by the
    VERTICES_OUT declaration.  The "y", "z", and "w" components of the
    variable are always undefined.  This suffix is not available to
    tessellation evaluation programs and may only be used with the prefixes
    "primitive", "primitive.in", or "primitive.out", and produces the same
    value in all cases.

    If an attribute binding suffix matches "vertexcount", the "x" component is
    filled with the number of vertices in the input primitive being processed.
    The "y", "z", and "w" components of the variable are always undefined.
    This suffix is available only with the prefixes "primitive" and
    "primitive.in".

    If an attribute binding suffix matches "tessouter[n]", the "x" component
    is filled with the per-patch outer tessellation level numbered <n> of the
    identified input or output patch.  <n> must be less than four.  The "y",
    "z", and "w" components are always undefined.  This suffix is available
    only with the prefixes "primitive", "primitive.in", and "primitive.out".
    For tessellation control programs, this suffix is available only with
    "primitive.out".

    If an attribute binding suffix matches "tessinner[n]", the "x" component
    is filled with the per-patch inner tessellation level numbered <n> of the
    identified input or output patch.  <n> must be less than two.  The "y",
    "z", and "w" components are always undefined.  This suffix is available
    only with the prefixes "primitive", "primitive.in", and "primitive.out".
    For tessellation control programs, this suffix is available only with
    "primitive.out".

    If an attribute binding suffix matches "patch.attrib[n]", the "x", "y",
    "z", and "w" components are filled with the corresponding components of
    the per-patch generic attribute numbered <n> of the identified input or
    output patch.  This suffix is available only with the prefixes
    "primitive", "primitive.in", and "primitive.out".  For tessellation
    control programs, this suffix is available only with "primitive.out".

    If an attribute binding suffix matches "tessouter[n..o]",
    "tessinner[n..o]", or "patch.attrib[n..o]", a sequence of 1+<o>-<n> outer
    tessellation level, inner tessellation level, or per-patch generic
    attribute bindings is created.  For per-patch generic attribute bindings,
    it is as though the sequence "primitive.patch.attrib[n],
    primitive.patch.attrib[n+1], ...  primitive.patch.attrib[o]" were
    specfied.  These bindings are available only in explicit declarations of
    array variables.  A program will fail to load if <n> is greater than <o>.

    If a tessellation evaluation program attribute binding suffix matches
    "vertex.tesscoord", the "x", "y", and "z" components are filled with the
    floating-point (u,v,w) values, respectively, corresponding to the vertex
    being processed by the tessellation evaluation program.  For triangle
    tessellation, the (u,v,w) values are barycentric coordinates that specify
    the location of the vertex relative to the three corners of the subdivided
    triangle.  The (u,v,w) values are in the range [0,1] and sum to one.  For
    quad and isoline tessellation, the (u,v) values are in the range [0,1] and
    specify the relative horizontal and vertical position in the subdivided
    quad.  The third component of the (u,v,w) vector is undefined for quad and
    isoline tessellation.  The "w" component of the variable is always
    undefined.  This suffix is not available to tessellation control shaders
    and may only be used with the prefix "vertex".


    (add the following subsection to section 2.X.3.5 of NV_gpu_program4,
     Program Results.)

    The attributes of individual output vertices are written by tessellation
    control and evaluation programs.  For tessellation control programs, these
    attributes are those of the output patch vertex corresponding to the
    program invocation.  For tessellation evaluation programs, these
    attributes specify the attributes of the vertex in the tessellated patch
    corresponding to the program invocation.  The set of allowable per-vertex
    result variable bindings is the same for tessellation control and
    evaluation programs correspond to attributes of output vertices and is
    given in Table X.5.

      Binding                        Components  Description
      -----------------------------  ----------  ----------------------------
      result.position                (x,y,z,w)   position in clip coordinates
      result.color                   (r,g,b,a)   front-facing primary color
      result.color.primary           (r,g,b,a)   front-facing primary color
      result.color.secondary         (r,g,b,a)   front-facing secondary color
      result.color.front             (r,g,b,a)   front-facing primary color
      result.color.front.primary     (r,g,b,a)   front-facing primary color
      result.color.front.secondary   (r,g,b,a)   front-facing secondary color
      result.color.back              (r,g,b,a)   back-facing primary color
      result.color.back.primary      (r,g,b,a)   back-facing primary color
      result.color.back.secondary    (r,g,b,a)   back-facing secondary color
      result.fogcoord                (f,*,*,*)   fog coordinate
      result.pointsize               (s,*,*,*)   point size
      result.texcoord                (s,t,r,q)   texture coordinate, unit 0
      result.texcoord[n]             (s,t,r,q)   texture coordinate, unit n
      result.attrib[n]               (x,y,z,w)   generic interpolant n
      result.clip[n]                 (d,*,*,*)   clip plane distance
      result.texcoord[n..o]          (s,t,r,q)   texture coordinates n thru o
      result.attrib[n..o]            (x,y,z,w)   generic interpolants n thru o
      result.clip[n..o]              (d,*,*,*)   clip distances n thru o

      Table X.5:  Tessellation Control and Evaluation Program Per-Vertex 
      Result Variable Bindings.  Components labeled "*" are unused.

    If a result variable binding matches "result.position", updates to the
    "x", "y", "z", and "w" components of the result variable modify the "x",
    "y", "z", and "w" components, respectively, of the transformed vertex's
    clip coordinates.  Final window coordinates of vertices used for
    rasterization will be generated for the vertex as described in section
    2.14.4.4.

    If a result variable binding match begins with "result.color", updates to
    the "x", "y", "z", and "w" components of the result variable modify the
    "r", "g", "b", and "a" components, respectively, of the corresponding
    vertex color attribute in Table X.3.  Color bindings that do not specify
    "front" or "back" are consided to refer to front-facing colors.  Color
    bindings that do not specify "primary" or "secondary" are considered to
    refer to primary colors.

    If a result variable binding matches "result.fogcoord", updates to the "x"
    component of the result variable set the transformed vertex's fog
    coordinate.  Updates to the "y", "z", and "w" components of the result
    variable have no effect.

    If a result variable binding matches "result.pointsize", updates to the
    "x" component of the result variable set the transformed vertex's point
    size.  Updates to the "y", "z", and "w" components of the result variable
    have no effect.

    If a result variable binding matches "result.texcoord" or
    "result.texcoord[n]", updates to the "x", "y", "z", and "w" components of
    the result variable set the "s", "t", "r" and "q" components,
    respectively, of the transformed vertex's texture coordinates for texture
    unit <n>.  If "[n]" is omitted, texture unit zero is selected.

    If a result variable binding matches "result.attrib[n]", updates to the
    "x", "y", "z", and "w" components of the result variable set the "x", "y",
    "z", and "w" components of the generic interpolant <n>.

    If a result variable binding matches "result.clip[n]", updates to the "x"
    component of the result variable set the clip distance for clip plane <n>.

    If a result variable binding matches "result.texcoord[n..o]",
    "result.attrib[n..o]", or "result.clip[n..o]", a sequence of 1+<o>-<n>
    bindings is created.  For texture coordinates, it is as though the
    sequence "result.texcoord[n], result.texcoord[n+1],
    ... result.texcoord[o]" were specfied.  These bindings are available only
    in explicit declarations of array variables.  A program will fail to load
    if <n> is greater than <o>.

    In addition to per-vertex attribute bindings, a set of per-patch result
    bindings are available to tessellation control programs, as described in
    Table X.6.  These bindings are not available to tessellation evaluation
    programs.

      Binding                        Components  Description
      -----------------------------  ----------  ----------------------------
      result.patch.tessouter[n]      (x,*,*,*)   tessctl outer level n
      result.patch.tessinner[n]      (x,*,*,*)   tessctl inner level n
      result.patch.attrib[n]         (x,y,z,w)   per-patch generic attrib n
      result.patch.tessouter[n..o]   (x,*,*,*)   tessctl outer levels n thru o
      result.patch.tessinner[n..o]   (x,*,*,*)   tessctl inner levels n thru o
      result.patch.attrib[n..o]      (x,y,z,w)   per-patch attribs n thru o

      Table X.4:  Tessellation Control Per-Patch Result Variable Bindings.  
      Components labeled "*" are unused.

    If a result variable binding matches "result.patch.tessouter[n]", updates
    to the "x" component set the outer tessellation level numbered <n> for the
    output patch.  Updates to the "y", "z", and "w" components have no effect.

    If a result variable binding matches "result.patch.tessinner[n]", updates
    to the "x" component set the inner tessellation level numbered <n> for the
    output patch.  Updates to the "y", "z", and "w" components have no effect.

    If a result variable binding matches "result.patch.attrib[n]", updates to
    the "x", "y", "z", and "w" components of the result variable set the "x",
    "y", "z", and "w" components of the per-patch generic attribute numbered
    <n> for the output patch.

    If a result variable binding matches "result.patch.tessouter[n..o]",
    "result.patch.tessinner[n..o]", or "result.patch.attrib[n..o]", a sequence
    of 1+<o>-<n> bindings is created.  For per-patch generic attributes, it is
    as though the sequence "result.patch.attrib[n], result.patch.attrib[n+1],
    ...  result.patch.attrib[o]" were specfied.  These bindings are available
    only in explicit declarations of array variables.  A program will fail to
    load if <n> is greater than <o>.

    
    Modify Section 2.X.5 of NV_gpu_program4, Program Flow Control

    (modify spec language at the end of the section to account for the
     different flow control model for tessellation control programs)

    Tessellation Control Program Flow Control

    For tessellation control programs, there are multiple program invocations
    for each patch processed that run as a group.  Any given program
    invocation can read per-vertex or per-patch attributes of the output
    patch, which may be computed during the execution of the program and may
    be computed by a different program invocation.  To provide defined
    behavior for such accesses, we specify that all threads for each patch run
    as a group.  When executing any block of instructions, all active threads
    will complete the excecution of one instruction before starting the
    execution of the subsequent instruction.  Flow control instructions may
    cause the flow of threads in a group to diverge and will modify the set of
    active threads.  The handling of flow control instructions is described in
    more detail below.

    A tessellation control program is handled by executing all instructions in
    a block of instructions corresponding to the main subroutine, with all
    threads initially active.  This block consists of all instructions between
    the "main" label and the next subroutine label.  If no "main" label is
    present, the block starts with the first instruction in the program.  If
    there is no subroutine label following the beginning of the block, the
    block ends at the END instruction.  Instructions in the block are executed
    in order until all threads reach a termination condition.  A thread will
    terminate:

      * if it executes a RET anywhere within the main subroutine, unless the
        RET instruction is conditional and the condition code test fails; or

      * if it completes the execution of all instructions in the subroutine
        block.

    When an individual thread terminates processing of the main subroutine,
    the thread will become inactive and remain inactive for the remainder of
    program execution.  When all threads have terminated the main subroutine
    block, program execution is complete and the output patch is passed to
    subsequent pipeline stages.

    When a CAL instruction is executed, the current set of active threads will
    execute a block of instructions corresponding to the specified subroutine
    label.  This block consists of all instructions between the specified
    label and the next subroutine label.  If there is no subroutine label
    following the beginning of the block, the block ends at the END
    instruction.  Instructions in the block are executed in order until all
    active threads reach a termination condition.  A thread will complete
    execution of a subroutine block:

      * if the CAL instruction is conditional and the condition code test
        fails;

      * if it executes a RET anywhere within the subroutine block, unless the
        RET instruction is conditional and the condition code test fails; or

      * if it completes the execution of all instructions in the subroutine
        block.

    When an individual thread terminates processing of a called subroutine,
    the thread will become inactive and remain inactive until all threads have
    reached their termination condition.  When all threads have terminated the
    subroutine, execution continues at the instruction following the CAL
    instruction.  All threads active for initial CAL instruction become active
    again; all other threads will remain inactive.
    
    When a REP instruction is executed, the current set of active threads will
    repeatedly execute the instructions between the REP and corresponding
    ENDREP instruction in order.  Execution of this instruction loop will
    continue until all threads active when the REP instruction is executed
    reach a termination condition.  A thread will terminate the processing of
    a REP/ENDREP block:

      * if the REP instruction specifies a loop count, and the initial loop
        count is not positive;

      * if the REP instruction specifies a loop count, and the current value
        of the loop count for the thread reaches zero when decremented by an
        ENDREP instruction;

      * if a RET instruction is executed anywhere within the REP/ENDREP block,
        unless the RET instruction is conditional and the condition code test
        fails; or

      * if a BRK instruction is executed inside the REP/ENDREP block, unless
        the BRK instruction is contained inside a more-deeply nested
        REP/ENDREP block or the BRK instruction is conditional and the
        condition code test fails.

    When an individual thread terminates processing of a REP/ENDREP loop, the
    thread will become inactive and remain inactive until all threads have
    terminated the loop.  When all threads have terminated the loop, execution
    continues at the instruction following the ENDREP instruction.  All
    threads active for initial REP instruction become active again, unless
    they executed a RET instruction inside the REP/ENDREP block.  All other
    threads will be inactive.

    If a conditional CONT instruction is executed inside a REP/ENDREP block,
    all active threads passing the condition code test will become inactive
    and remain inactive until the next ENDREP instruction.  If all active
    threads become inactive following the completion of a CONT instruction,
    processing continues at the next ENDIF or ENDREP instruction.  An
    unconditional CONT instruction is treated identically to a conditional
    CONT instruction where all active threads pass the condition code test.

    When an IF instruction belonging to an IF/ELSE/ENDIF block is executed,
    the current set of active threads is split into two groups.  The first
    group consists of all active threads passing the condition code test, and
    will execute a block of instructions between the IF and ELSE.  The second
    group consists of all active threads failing the condition code test, and
    will execute a block of instructions between the ELSE and ENDIF.
    Instructions within each group are executed in lock-step order.  However,
    the order of execution of instructions for threads in the first group are
    undefined relative to those in the second group.

    When executing a block of instructions for either of the two groups in an
    IF/ELSE/ENDIF block, instructions within the block will be executed in
    order with only the threads in that group active.  The instructions of the
    block are executed until all threads in the group reach a block
    termination condition.  A thread will terminate the processing of its
    block:

      * if it executes a RET instruction, unless the RET instruction is
        conditional and the condition code test fails;

      * if it executes a BRK or CONT instruction inside the IF/ENDIF block,
        unless that instruction is contained in a more-deeply nested
        REP/ENDREP block or if the instruction is conditional and the
        condition code test fails; or

      * if it completes the execution of all instructions in the instruction
        block.

    When both groups have completed their instruction blocks, execution
    continues at the instruction following the ENDIF.  No instruction
    following the ENDIF will be executed until both groups have completed.  At
    that point, any thread active for the IF instruction will become active
    again unless the execution of its instruction block was terminated due to
    the execution of a RET, BRK, or CONT instruction.  All other threads will
    be inactive.

    An IF instruction belonging to an IF/ENDIF block (with no corresponding
    ELSE) is handled as above, except that only one thread group created.
    That group will consists of all active threads passing the condition code,
    and it executes a block of instructions between the IF and ENDIF.

    The order of execution imposed by this flow control model typically
    produces defined results when a tessellation control shader writes an
    output patch attribute, and then reads it (possibly on a different thread)
    for further computation.  There are two cases where undefined instruction
    execution order will lead to undefined attribute values.  When two or more
    threads access an attribute in a single executed instruction:

      * the value of the attribute after the instruction completes will be
        undefined if multiple threads write different values; and

      * the value of the attribute read by one thread will be undefined if the
        same attribute is written by another thread executing the same
        instruction.

    Also, when an IF/ELSE/ENDIF block is executed and a thread from each of
    the two thread groups access an attribute within its block:

      * the value of the attribute after the completion of the block will be
        undefined if both threads write different values;

      * the value of the attribute read by one thread will be undefined if the
        same attribute is written by another thread.

    If either thread group in an IF/ELSE/ENDIF block issue CAL instructions,
    these restrictions also apply to the instructions executed in the called
    subroutine.

    The additional complexities of this tessellation control program flow
    control model are not fundamentally incompatible with the simpler flow
    control rules above.  They are simply intended to provide a useful model
    allowing for multiple cooperating threads.  In particular, two models are
    completely equivalent if there is only number of tessellation control
    program threads per patch is one.


    (add the following subsections to section 2.X.6 of NV_gpu_program4,
     Program Options.)

    Section 2.X.6.Y, Tessellation Control Program Options

    No options are supported at present for tessellation control programs.


    Section 2.X.6.Y, Tessellation Evaluation Program Options

    No options are supported at present for tessellation evaluation programs.


    (add the following subsections to section 2.X.7 of NV_gpu_program4,
     Program Declarations.)

    Section 2.X.7.Y, Tessellation Control Program Declarations

    Tessellation control programs support one type of declaration statement,
    as described below.

    - Output Vertex Count (VERTICES_OUT)

    The VERTICES_OUT statement declares the number of vertices in the output
    patch produced by the tessellation control program, which also specifies
    the number of program invocations for each input patch.  The single
    argument must be a positive integer less than or equal to the value of the
    implementation-dependent limit MAX_PATCH_VERTICES_NV.  Each program
    invocation will have the same inputs except for the built-in input
    variable "primitive.invocation".  This variable will be an integer between
    0 and <n>-1, where <n> is the declared number of invocations.  A program
    will fail to load unless it contains exactly one VERTICES_OUT declaration.


    Section 2.X.7.Y, Tessellation Evaluation Program Declarations

    Tessellation evaluation programs support several declaration statements.
    Each of these may be included at most in a tessellation evaluation
    program.

    - Tessellation Primitive Generation Mode (TESS_MODE)

    The TESS_MODE statement declares the type of subdivision performed by the
    tessellation primitive generator when the tessellation evaluation program,
    as described for the TESS_GEN_MODE_NV parameter in Section 2.X.2.  The
    single argument must be "TRIANGLES", "QUADS", or "ISOLINES".  A
    tessellation evaluation program will fail to load if it has no primitive
    generation mode declaration.

    - Tessellation Primitive Spacing (TESS_SPACING)

    The TESS_SPACING statement declares the type of spacing the tessellation
    primitive generator applies when subdivides primitive edge, as described
    for the TESS_GEN_SPACING_NV parameter in Section 2.X.2.  The single
    argument must be "EQUAL", "FRACTIONAL_ODD", or "FRACTIONAL_EVEN".  If a
    program omits a spacing declaration, "EQUAL" will be used.

    - Tessellation Vertex Order (TESS_VERTEX_ORDER)

    The TESS_VERTEX_ORDER statement declares the order of the vertices in the
    triangles emitted by the tessellation primitive generator in TRIANGLES or
    QUADS mode, as described for the TESS_GEN_VERTEX_ORDER_NV parameter in
    Section 2.X.2.  The single argument must be "CW" or "CCW".  If a program
    omits a vertex order declaration, "CCW" will be used.

    - Tessellation Point Mode (TESS_POINT_MODE)

    The TESS_POINT_MODE statement declares that the tessellation primitive
    generator will emit points for each vertex in the subdivided primitive
    instead of lines or triangles, as described for the TESS_GEN_POINT_MODE_NV
    parameter in Section 2.X.2.  The declaration takes no arguments.  If a
    program omits a point mode declaration, the primitives emitted will be
    lines (for ISOLINES mode) or triangles (for TRIANGLES and QUADS mode).


Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)

    None.

Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
Operations and the Frame Buffer)

    None.

Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)

    None.

Additions to Chapter 6 of the OpenGL 1.5 Specification (State and
State Requests)

    None.

Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

GLX Protocol

    None.

Errors

    The error INVALID_OPERATION is generated if Begin, or any command that
    implicitly calls Begin, is called when tessellation control programs are
    enabled and the currently bound tessellation control program object does
    not contain a valid program.

    The error INVALID_OPERATION is generated if Begin, or any command that
    implicitly calls Begin, is called when tessellation evaluation programs
    are enabled and the currently bound tessellation evaluation program object
    does not contain a valid program.

    The error INVALID_OPERATION is generated if Begin, or any command that
    implicitly calls Begin, is called when tessellation control programs are
    enabled and <mode> is not PATCHES_NV.

    The error INVALID_OPERATION is generated if Begin, or any command that
    implicitly calls Begin, is called when tessellation evaluation programs
    are enabled and <mode> is not PATCHES_NV.

New State

    (Modify ARB_vertex_program, Table X.6 -- Program State)

                                                     Initial
    Get Value                  Type    Get Command    Value  Description              Sec.    Attribute
    -------------------------  ----    -----------   ------- ------------------------ ------  ---------
    TESS_CONTROL_PROGRAM_NV     B      IsEnabled      FALSE  Tessellation control     2.14.6  enable
                                                             program enable
    TESS_EVALUATION_PROGRAM_NV  B      IsEnabled      FALSE  Tess. evaluation         2.14.6  enable
                                                             program enable

    TESS_CONTROL_PROGRAM_       Z+     GetIntegerv      0    Active tess control      2.14.1  -
      PARAMETER_BUFFER_NV                                    program buffer object
                                                             binding
    TESS_CONTROL_PROGRAM_       nxZ+   GetInteger-      0    Buffer objects bound for 2.14.1  -
      PARAMETER_BUFFER_NV              IndexedvEXT           tess. control program use

    TESS_EVALUATION_PROGRAM_    Z+     GetIntegerv      0    Active tess evaluation   2.14.1  -
      PARAMETER_BUFFER_NV                                    program buffer object
                                                             binding
    TESS_EVALUATION_PROGRAM_    nxZ+   GetInteger-      0    Buffer objects bound for 2.14.1  -
      PARAMETER_BUFFER_NV              IndexedvEXT           tess. eval. program use


    Additionally, some tessellation-related state applicable to this extension
    is added by ARB_tessellation_shader.

New Implementation Dependent State

                                                             Minimum
    Get Value                         Type  Get Command       Value   Description             Sec.     Attrib
    --------------------------------  ----  ---------------  -------  ----------------------- -------- ------
    MAX_PROGRAM_PATCH_ATTRIBS_NV       Z+   GetProgramivARB     30    number of generic patch 2.X.3.2    -
                                                                      attribute vectors
                                                                      supported

    Additionally, some tessellation-related state applicable to this extension
    is added by ARB_tessellation_shader.


Dependencies on ARB_tessellation_shader

    This spec incorporates the text of ARB_tessellation_shader in its
    entirety.  If ARB_tessellation_shader is not supported, language
    documenting GLSL tessellation control and evaluation shaders should be
    removed; tessellation would be available only using the assembly
    interface.  Language describing the operation of patch primitives and the
    tessellation primitive generator would be retained.

Dependencies on NV_parameter_buffer_object

    The NV_parameter_buffer_object (PaBO) extension provides the ability to
    bind buffer objects to be read by vertex, geometry, and fragment programs.

    If NV_parameter_buffer_object is supported, this extension adds the
    ability to bind buffer objects to be accessed by tessellation control and
    evaluation programs.  The NV_parameter_buffer_object should be modified to
    accept the enums TESS_CONTROL_PROGRAM_PARAMETER_BUFFER_NV and
    TESS_EVALUATION_PROGRAM_PARAMETER_BUFFER_NV where the three previously
    defined enums (for vertex, geometry, and fragment programs) are accepted.

    If NV_parameter_buffer_object is not supported, references to the two new
    buffer object binding points should be removed.

Issues

    (1) How does tessellation fit into the existing GL pipeline?

      RESOLVED:  See issue (1) in the ARB_tessellation_shader specification,
      which contains beautifully crafted ASCII art depicting the pipeline.

    (2) What other considerations were involved in the design of the
        tessellation API?

      RESOLVED:  Go look at the detailed issues section of the GLSL-based
      ARB_tessellation_shader specification.  There are a good number of
      issues that apply equally to the assembly APIs that won't be duplicated
      here.

    (3) Should the tessellation-related parameters (e.g., the primitive
        decomposition, spacing, vertex orientation) be context state or
        provided with the program?  If the latter, how should they be
        provided.

      RESOLVED:  We are providing declaration statements to specify each of
      these parameters in the tessellation evaluation program.  Because they
      are part of the program text, they can't be changed independently of the
      program.  We don't think that limitation is serious, and the same
      limitation applies to GLSL shaders (you need to re-link when changing
      these parameters).  

      Putting these declarations in the shader means that it wasn't necessary
      to create a new "tessellation parameter" API to set this state.  Such an
      API would only apply to assembly programs and could be a source of
      confusion if developers thought it might apply to GLSL shaders as well.

    (4) The programming model for tessellation control programs supports
        multiple threads, each providing attributes for a single vertex.  But
        it also supports the ability to read the per-vertex outputs written by
        other threads and to read and write shared per-patch attribute
        outputs.  The latter capabilities require some sort of synchronization
        to ensure consistently ordered reads and writes whenever possible.
        How should this be handled?

      RESOLVED:  We will expose a programming model where we run groups of <N>
      parallel threads in lock-step.  In this model, all <N> threads
      effectively retire one instruction before starting the next.  This
      execution model provides a simple abstraction, and provides an obvious
      instruction order allowing an application to avoid most read-write and
      write-write hazards.

      There are three places where we have explicitly undefined behavior:

        * If flow control diverges in an IF/ELSE/ENDIF block, the relative
          order of writes in the "IF" side of the block and those in the
          "ELSE" side of the block is undefined.

        * If multiple threads write different values to the same per-patch
          attribute in the same instruction, the order in which the writes
          land is undefined.

        * If any single instruction has one thread reading a per-vertex output
          or a per-patch attribute and another thread writing the same output,
          the order in which the reads and writes land is undefined.

      Implementations need not actually run the threads in this manner, as
      long as the compiler properly synchronizes threads at the points where
      execution order dependencies do occur.  Since the NV_gpu_program4
      programming model uses structured branching (e.g., IF/ELSE/ENDIF
      blocks), the points at which threads may diverge and converge again are
      easily identified.  We expect that the number of such synchronization
      points will be low for most tessellation control programs.

      One other approach considered is to limit the flow control model and the
      capabilities of the system to result in a minimal number of required
      synchronization points.  For example, the tessellation control program
      might be split into phases where the capabilities of each thread to
      access outputs would be limited.  For example, one might have a
      three-phase model like the following:

                      Per-Vertex Outputs           Per-Patch Outputs
         Phase     can read?    can write?      can read?    can write?
         -----     ---------    ----------      ---------    ----------
           1          NO           YES             NO           NO
           2          YES          NO              NO           YES(a)
           3          YES          NO              YES(a)       YES(b)

     In this model, there would be two explicit synchronization points --
     between each pair of phases.  The limits on access prevent most cases
     where conficts could occur (e.g., you can't read any per-vertex outputs
     until you're completely done writing all).  To further limit conflicts,
     per-patch attributes might be divided into two sets -- set (a) can be
     written only in phase 2 and read only in phase (3), and set (b) can be
     written only in phase 3.

     We decided to expose a general model on the grounds that having the
     compiler automatically determine possible synchronization points was easy
     enough.  Optimizing compilers that reorder instructions already have to
     deal with this exact type of issue -- they can't move instructions that
     write a variable past subsequent instructions that read it.

     The programming model adopted for GLSL in ARB_tessellation_shader
     similarly has a set of parallel threads running one executable, but it
     provides a barrier() call that serves as a synchronization point and can
     be used to split shader execution into phases.

     Note that while all previous OpenGL programmability extensions exposed a
     model of completely independent threads (i.e., one thread can't read the
     outputs of another), threads weren't always completely independent!  In
     fragment programs/shaders, some texture and all partial derivative
     built-ins (dFdx, dFdy in GLSL) require screen-space derivatives.  If the
     quantity used for derivatives is computed by the shader, OpenGL
     implementations generally run threads in groups arranged by screen-space
     location and approximate derivatives by computing differences of the
     inputs between threads.  This approach requires the same sort of
     automatic synchronization between threads, since derivatives implicitly
     read values computed by other threads.


Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  -----------------------------------------
     3    12/19/11  pbrown    Clarify that "primitive.tessouter[n]",
                              "primitive.tessinner[n]", and "primitive.
                              patch.attrib[n]" are not available on the input
                              patch for tessellation control programs.  Remove
                              stray language referring to a non-existent
                              vector tessellation level.

     2    03/22/10  pbrown    Rename references to ARB_tessellation_shader
                              (formerly EXT).  Minor other cleanups, including
                              the issues section.

     1              pbrown    Internal revisions.