Name

    MESA_gpu_program3

Name Strings

    GL_MESA_vertex_program3
    GL_MESA_fragment_program3

Contact

    Ian Romanick, Intel Corporation (ian.d.romanick 'at' intel.com)

IP Status

    NVIDIA claims to own intellectual property related to
    ARB_vertex_program, and has signed an ARB Contributor License
    agreement licensing this intellectual property.

    Microsoft claims to own intellectual property related to
    ARB_vertex_program.

    Large portions of the text of this extension were extracted from the
    ARB_vertex_program, ARB_fragment_program, NV_vertex_program2_option,
    NV_gpu_program4, NV_vertex_program4, and NV_fragment_program4 extension
    specifications.

Status

    Incomplete.  DO NOT SHIP!

Version

    October 19, 2009 (version 2)

Number

    TBD

Dependencies

    This extension is written against the OpenGL 2.0 specification.

    OpenGL 2.0 is not required, but we expect all implementations of this
    extension will also support OpenGL 2.0.

    ARB_vertex_program and ARB_fragment_program are required.

    This extension interacts with ARB_fragment_program_shadow.

    This extension interacts with ARB_draw_buffers and ATI_draw_buffers.

    ARB_texture_rectangle trivially affects the definition of this extension.

    ARB_texture_cube_map trivially affects the definition of this extension.

Overview

    This specification documents the common instruction set and basic
    functionality provided by so-called Shader Model 3.0 GPUs.  Such
    GPUs provide a variety of capabilities beyond those exposed by
    ARB_vertex_program and ARB_fragment_program.  The instruction set
    document here builds on the basic framework provided by the
    ARB_vertex_program and ARB_fragment_program extensions.

    MESA_gpu_program3 provides a unified instruction set -- all instruction set
    features are available for all program types, except for a small number of
    features that make sense only for a specific program type.  It provides
    a variety of new instructions and conditional write masking.
    It also provides a uniform set of structured
    branching constructs (if tests, loops, and subroutines) that fully support
    run-time condition testing.
 
    This extension exposes the following capabilities:
 
      * structured branching support, including:
 
        - data-dependent if-statements
        - loops supporting a fixed number of iterations
        - a data-dependent loop exit instruction
 
      * subroutine calls
 
      * data-dependent conditional write masks
 
      * address registers with four components (instead of just one)
 
      * address register-relative addressing for attribute and result arrays
 
      * absolute value operator on scalar and swizzled operand loads
 
      * SIN and COS trigonometry instructions in vertex programs
 
      * optional texture fetching in vertex programs
 
      * fully orthogonal "set on" instructions
 
      * instructions to compute partial derivatives and perform texture
        lookups using specified partial derivatives in fragment programs 
 
      * result clamping to the range [0, 1] in vertex programs
 
      * centroid, constant, and non-perspective interpolation of fragment
        program attributes
 
    For the most part, vertex and fragment programs writing for
    ARB_vertex_program and ARB_fragment_program wishing to use this
    added functionality need only add:
 
        OPTION MESA_gpu_program3;
 
    to the beginning of their programs.

 
New Procedures and Functions

    None

New Tokens


    Accepted by the <pname> parameter of GetProgramivARB:

        MAX_PROGRAM_EXEC_INSTRUCTIONS_MESA              0x88F4
        MAX_PROGRAM_CALL_DEPTH_MESA                     0x88F5
        MAX_PROGRAM_IF_DEPTH_MESA                       0x88F6
        MAX_PROGRAM_LOOP_DEPTH_MESA                     0x88F7
        MAX_PROGRAM_LOOP_COUNT_MESA                     0x88F8

    (note: These tokens share values with tokens of the
     NV_fragment_program2 extension.)
 
        MAX_PROGRAM_PREDICATE_REGISTERS_MESA            0x????
 
    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
    GetFloatv, and GetDoublev:
 
        MAX_VERTEX_TEXTURE_IMAGE_UNITS                  0x8B4C

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

    Insert New Section 2.X between Sections 2.Y and 2.Z:

    Section 2.X, GPU Programs

    The GL provides a number of different program targets that allow an
    application to either replace certain fixed-function pipeline stages with
    a fully programmable model or use a program to control aspects of the GL
    pipeline that previously had only hard-wired behavior.

    A common base instruction set is available for all program types.
    Structured
    branching operations and subroutine calls are available.  Texture
    mapping (loading data from external images) is supported for all
    program types.  The main differences between the different program
    types are the set of available inputs and outputs, which are program type-
    specific, and a few instructions that are meaningful for only a subset
    of program types.

    Vertex Programs

    Vertex programs are used to compute the transformed attributes of a
    vertex, in lieu of the set of fixed-function operations described in
    sections 2.10 through 2.13.  Vertex programs are run on a single vertex at
    a time, and the state of neighboring vertices is not available.  The
    inputs available to a vertex program are the vertex attributes described
    in section 2.7.  The results of the program are the attributes of a
    transformed vertex, which include (among other things) a transformed
    position, colors, and texture coordinates.  The vertices transformed by a
    vertex program are then processed normally by the remainder of the GL
    pipeline.

    Fragment Programs

    Fragment programs are used to compute the transformed attributes of a
    fragment, in lieu of the set of fixed-function operations described in
    sections 3.8 through 3.10.  Fragment programs are run on a single fragment
    at a time, and the state of neighboring fragments is not explicitly
    available.  (In practice, fragment programs may be run on a block of
    fragments, and neighboring fragments' attributes may be used for texture
    LOD calculations or partial derivative approximation.)  The inputs
    available to a fragment program are the interpolated attributes of a
    fragment, which include (among other things) window-space position,
    primary and secondary colors, and texture coordinates.  The results of the
    program are one (or more) colors and possibly a new window Z coordinate.
    A fragment program can not modify the (X,Y) location of the fragment.


    Section 2.X.2, Program Grammar

    GPU program strings are specified as an array of ASCII characters
    containing the program text.  When a GPU program is loaded by a call to
    ProgramStringARB, the program string is parsed into a set of tokens
    possibly separated by whitespace.  Spaces, tabs, newlines, carriage
    returns, and comments are considered whitespace.  Comments begin with the
    character "#" and are terminated by a newline, a carriage return, or the
    end of the program array.

    The Backus-Naur Form (BNF) grammar below specifies the syntactically valid
    sequences for GPU programs.  The set of valid tokens can be inferred
    from the grammar.  A line containing "/* empty */" represents an empty
    string and is used to indicate optional rules.  A program is invalid if it
    contains any tokens or characters not defined in this specification.

    <program>               ::= <optionSequence> <statementSequence> "END"

    <optionSequence>        ::= <option> <optionSequence>
                              | /* empty */

    <option>                ::= "OPTION" <identifier> ";"

    <statementSequence>     ::= <statement> <statementSequence>
                              | /* empty */

    <statement>             ::= <instruction> ";"
                              | <namingStatement> ";"
                              | <instLabel> ":"

    <instruction>           ::= <ALUInstruction>
                              | <TexInstruction>
                              | <FlowInstruction>

    <ALUInstruction>        ::= <VECTORop_instruction>
                              | <SCALARop_instruction>
                              | <BINSCop_instruction>
                              | <BINop_instruction>
                              | <TRIop_instruction>
                              | <SWZop_instruction>

    <TexInstruction>        ::= <TEXop_instruction>
                              | <TXDop_instruction>

    <FlowInstruction>       ::= <BRAop_instruction>
                              | <FLOWCCop_instruction>
                              | <IFop_instruction>
                              | <LOOPop_instruction>
                              | <REPop_instruction>
                              | <ENDFLOWop_instruction>

    <VECTORop_instruction>  ::= <VECTORop> <instResult> "," 
                                <instOperandV>

    <VECTORop>              ::= "ABS"
                              | "FLR"
                              | "FRC"
                              | "LIT"
                              | "MOV"
                              | "NRM"
                              | "ROUND"
                              | "SSG"

    <SCALARop_instruction>  ::= <SCALARop> <instResult> "," 
                                <instOperandS>

    <SCALARop>              ::= "COS"
                              | "EX2"
                              | "EXP"
                              | "LG2"
                              | "LOG"
                              | "RCP"
                              | "RSQ"
                              | "SCS"
                              | "SIN"

    <BINSCop_instruction>   ::= <BINSCop> <instResult> "," 
                                <instOperandS> "," <instOperandS>

    <BINSCop>               ::= "POW"

    <BINop_instruction>     ::= <BINop> <instResult> "," 
                                <instOperandV> "," <instOperandV>

    <BINop>                 ::= "ADD"
                              | "DP3"
                              | "DP4"
                              | "DPH"
                              | "DST"
                              | "MAX"
                              | "MIN"
                              | "MUL"
                              | "SEQ"
                              | "SFL"
                              | "SGE"
                              | "SGT"
                              | "SLE"
                              | "SLT"
                              | "SNE"
                              | "STR"
                              | "SUB"
                              | "XPD"
                              | "DP2"

    <TRIop_instruction>     ::= <TRIop> <instResult> "," 
                                <instOperandV> "," <instOperandV> "," 
                                <instOperandV>

    <TRIop>                 ::= "CMP"
                              | "DP2A"
                              | "LRP"
                              | "MAD"

    <PREDop_instructions>   ::= <PREDop> <predicateName> "," 
                                <instOperandV> "," <instOperandV> 

    <PREDop>                ::= "PSEQ"
                              | "PSFL"
                              | "PSGE"
                              | "PSGT"
                              | "PSLE"
                              | "PSLT"
                              | "PSNE"
                              | "PSTR"

    <SWZop_instruction>     ::= <SWZop> <instResult> "," 
                                <instOperandVNS> "," <extendedSwizzle>

    <SWZop>                 ::= "SWZ"

    <TEXop_instruction>     ::= <TEXop> <instResult> "," 
                                <instOperandV> "," <texAccess>

    <TEXop>                 ::= "TEX"
                              | "TXB"
                              | "TXL"
                              | "TXP"

    <TXDop_instruction>     ::= <TXDop> <instResult> "," 
                                <instOperandV> "," <instOperandV> "," 
                                <instOperandV> "," <texAccess>

    <TXDop>                 ::= "TXD"

    <BRAop_instruction>     ::= <BRAop> <instTarget>
                                <optBranchCond>

    <BRAop>                 ::= "CAL"

    <FLOWCCop_instruction>  ::= <FLOWCCop> <optBranchCond>

    <FLOWCCop>              ::= "RET"
                              | "BRK"

    <IFop_instruction>      ::= <IFop> <predicate>

    <IFop>                  ::= "IF"

    <LOOPop_instruction>    ::= <LOOPop> <addrUseVNS> ',' <paramUseDB>

    <LOOPop>                ::= "LOOP"

    <REPop_instruction>     ::= <REPop> <paramUseDB>

    <REPop>                 ::= "REP"

    <ENDFLOWop_instruction> ::= <ENDFLOWop>

    <ENDFLOWop>             ::= "ELSE"
                              | "ENDIF"
                              | "ENDLOOP"
                              | "ENDREP"

    <texAccess>             ::= <texImageUnit> "," <texTarget>

    <texImageUnit>          ::= "texture" <optArrayMemAbs>

    <texTarget>             ::= "1D"
                              | "2D"
                              | "3D"
                              | "CUBE"
                              | "RECT"
                              | "SHADOW1D"
                              | "SHADOW2D"
                              | "SHADOWRECT"

    <optBranchCond>         ::= /* empty */
                              | <predicate>

    <instOperandV>          ::= <instOperandAbsV>
                              | <instOperandBaseV>

    <instOperandAbsV>       ::= <operandAbsNeg> "|" <instOperandBaseV> "|"

    <instOperandBaseV>      ::= <operandNeg> <attribUseV>
                              | <operandNeg> <tempUseV>
                              | <operandNeg> <paramUseV>

    <instOperandS>          ::= <instOperandAbsS>
                              | <instOperandBaseS>

    <instOperandAbsS>       ::= <operandAbsNeg> "|" <instOperandBaseS> "|"

    <instOperandBaseS>      ::= <operandNeg> <attribUseS>
                              | <operandNeg> <tempUseS>
                              | <operandNeg> <paramUseS>

    <instOperandVNS>        ::= <attribUseVNS>
                              | <tempUseVNS>
                              | <paramUseVNS>

    <operandAbsNeg>         ::= <optSign>

    <operandNeg>            ::= <optSign>

    <instResult>            ::= <instResultCC>
                              | <instResultBase>

    <instResultCC>          ::= <instResultBase> <predicate>

    <instResultBase>        ::= <tempUseW>
                              | <resultUseW>

    <namingStatement>       ::= <varMods> <ATTRIB_statement>
                              | <PARAM_statement>
                              | <TEMP_statement>
                              | <ADDRESS_statement>
                              | <OUTPUT_statement>
                              | <ALIAS_statement>

    <ATTRIB_statement>      ::= "ATTRIB" <establishName> "=" <attribUseD>

    <PARAM_statement>       ::= <PARAM_singleStmt>
                              | <PARAM_multipleStmt>

    <PARAM_singleStmt>      ::= "PARAM" <establishName> <paramSingleInit>

    <PARAM_multipleStmt>    ::= "PARAM" <establishName> <optArraySize> 
                                <paramMultipleInit>

    <paramSingleInit>       ::= "=" <paramUseDB>

    <paramMultipleInit>     ::= "=" "{" <paramMultInitList> "}"

    <paramMultInitList>     ::= <paramUseDM>
                              | <paramUseDM> "," <paramMultInitList>

    <TEMP_statement>        ::= "TEMP" <varNameList>

    <ADDRESS_statement>     ::= "ADDRESS" <varNameList>

    <OUTPUT_statement>      ::= "OUTPUT" <establishName> "=" <resultUseD>

    <varMods>               ::= /* empty */

    <ALIAS_statement>       ::= "ALIAS" <establishName> "=" <establishedName>

    <varNameList>           ::= <establishName>
                              | <establishName> "," <varNameList>

    <attribUseV>            ::= <attribBasic> <swizzleSuffix>
                              | <attribVarName> <swizzleSuffix>
                              | <attribVarName> <arrayMem> <swizzleSuffix>
                              | <attribColor> <swizzleSuffix>
                              | <attribColor> "." <colorType> <swizzleSuffix>

    <attribUseS>            ::= <attribBasic> <scalarSuffix>
                              | <attribVarName> <scalarSuffix>
                              | <attribVarName> <arrayMem> <scalarSuffix>
                              | <attribColor> <scalarSuffix>
                              | <attribColor> "." <colorType> <scalarSuffix>

    <attribUseVNS>          ::= <attribBasic>
                              | <attribVarName>
                              | <attribVarName> <arrayMem>
                              | <attribColor>
                              | <attribColor> "." <colorType>

    <attribUseD>            ::= <attribBasic>
                              | <attribColor>
                              | <attribColor> "." <colorType>
                              | <attribMulti>

    <paramUseV>             ::= <paramVarName> <optArrayMem> <swizzleSuffix>
                              | <stateSingleItem> <swizzleSuffix>
                              | <programSingleItem> <swizzleSuffix>
                              | <constantVector> <swizzleSuffix>
                              | <constantScalar>

    <paramUseS>             ::= <paramVarName> <optArrayMem> <scalarSuffix>
                              | <stateSingleItem> <scalarSuffix>
                              | <programSingleItem> <scalarSuffix>
                              | <constantVector> <scalarSuffix>
                              | <constantScalar>

    <paramUseVNS>           ::= <paramVarName> <optArrayMem>
                              | <stateSingleItem>
                              | <programSingleItem>
                              | <constantVector>
                              | <constantScalar>

    <paramUseDB>            ::= <stateSingleItem>
                              | <programSingleItem>
                              | <constantVector>
                              | <signedConstantScalar>

    <paramUseDM>            ::= <stateMultipleItem>
                              | <programMultipleItem>
                              | <constantVector>
                              | <signedConstantScalar>

    <stateMultipleItem>     ::= <stateSingleItem>
                              | "state" "." <stateMatrixRows>

    <stateSingleItem>       ::= "state" "." <stateMaterialItem>
                              | "state" "." <stateLightItem>
                              | "state" "." <stateLightModelItem>
                              | "state" "." <stateLightProdItem>
                              | "state" "." <stateFogItem>
                              | "state" "." <stateMatrixRow>
                              | "state" "." <stateTexGenItem>
                              | "state" "." <stateClipPlaneItem>
                              | "state" "." <statePointItem>
                              | "state" "." <stateTexEnvItem>
                              | "state" "." <stateDepthItem>

    <stateMaterialItem>     ::= "material" "." <stateMatProperty>
                              | "material" "." <faceType> "." 
                                <stateMatProperty>

    <stateMatProperty>      ::= "ambient"
                              | "diffuse"
                              | "specular"
                              | "emission"
                              | "shininess"

    <stateLightItem>        ::= "light" <arrayMemAbs> "." <stateLightProperty>

    <stateLightProperty>    ::= "ambient"
                              | "diffuse"
                              | "specular"
                              | "position"
                              | "attenuation"
                              | "spot" "." <stateSpotProperty>
                              | "half"

    <stateSpotProperty>     ::= "direction"

    <stateLightModelItem>   ::= "lightmodel" "." <stateLModProperty>

    <stateLModProperty>     ::= "ambient"
                              | "scenecolor"
                              | <faceType> "." "scenecolor"

    <stateLightProdItem>    ::= "lightprod" <arrayMemAbs> "." 
                                <stateLProdProperty>
                              | "lightprod" <arrayMemAbs> "." <faceType> "." 
                                <stateLProdProperty>

    <stateLProdProperty>    ::= "ambient"
                              | "diffuse"
                              | "specular"

    <stateFogItem>          ::= "fog" "." <stateFogProperty>

    <stateFogProperty>      ::= "color"
                              | "params"

    <stateMatrixRows>       ::= <stateMatrixItem>
                              | <stateMatrixItem> "." <stateMatModifier>
                              | <stateMatrixItem> "." "row" <arrayRange>
                              | <stateMatrixItem> "." <stateMatModifier> "." 
                                "row" <arrayRange>

    <stateMatrixRow>        ::= <stateMatrixItem> "." "row" <arrayMemAbs>
                              | <stateMatrixItem> "." <stateMatModifier> "." 
                                "row" <arrayMemAbs>

    <stateMatrixItem>       ::= "matrix" "." <stateMatrixName>

    <stateMatModifier>      ::= "inverse"
                              | "transpose"
                              | "invtrans"

    <stateMatrixName>       ::= "modelview" <optArrayMemAbs>
                              | "projection"
                              | "mvp"
                              | "texture" <optArrayMemAbs>
                              | "program" <arrayMemAbs>

    <stateTexGenItem>       ::= "texgen" <optArrayMemAbs> "." 
                                <stateTexGenType> "." <stateTexGenCoord>

    <stateTexGenType>       ::= "eye"
                              | "object"

    <stateTexGenCoord>      ::= "s"
                              | "t"
                              | "r"
                              | "q"

    <stateClipPlaneItem>    ::= "clip" <arrayMemAbs> "." "plane"

    <statePointItem>        ::= "point" "." <statePointProperty>

    <statePointProperty>    ::= "size"
                              | "attenuation"

    <stateTexEnvItem>       ::= "texenv" <optArrayMemAbs> "." 
                                <stateTexEnvProperty>

    <stateTexEnvProperty>   ::= "color"

    <stateDepthItem>        ::= "depth" "." <stateDepthProperty>

    <stateDepthProperty>    ::= "range"

    <programSingleItem>     ::= <progEnvParam>
                              | <progLocalParam>

    <programMultipleItem>   ::= <progEnvParams>
                              | <progLocalParams>

    <progEnvParams>         ::= "program" "." "env" <arrayMemAbs>
                              | "program" "." "env" <arrayRange>

    <progEnvParam>          ::= "program" "." "env" <arrayMemAbs>

    <progLocalParams>       ::= "program" "." "local" <arrayMemAbs>
                              | "program" "." "local" <arrayRange>

    <progLocalParam>        ::= "program" "." "local" <arrayMemAbs>

    <constantVector>        ::= "{" <constantVectorList> "}"

    <constantVectorList>    ::= <signedConstantScalar>
                              | <signedConstantScalar> "," 
                                <signedConstantScalar>
                              | <signedConstantScalar> "," 
                                <signedConstantScalar> "," 
                                <signedConstantScalar>
                              | <signedConstantScalar> "," 
                                <signedConstantScalar> "," 
                                <signedConstantScalar> "," 
                                <signedConstantScalar>

    <signedConstantScalar>  ::= <optSign> <constantScalar>

    <constantScalar>        ::= <floatConstant>
                              | <intConstant>

    <floatConstant>         ::= <float>

    <intConstant>           ::= <int>

    <tempUseV>              ::= <tempVarName> <swizzleSuffix>

    <tempUseS>              ::= <tempVarName> <scalarSuffix>

    <tempUseVNS>            ::= <tempVarName>

    <tempUseW>              ::= <tempVarName> <optWriteMask>

    <resultUseW>            ::= <resultBasic> <optWriteMask>
                              | <resultVarName> <optWriteMask>

    <resultUseD>            ::= <resultBasic>

    <optArraySize>          ::= "[" "]"
                              | "[" <int> "]"

    <optArrayMem>           ::= /* empty */
                              | <progParamArrayMem>

    <arrayMem>              ::= <arrayMemAbs>
                              | <arrayMemRel>

    <optArrayMemAbs>        ::= /* empty */
                              | <arrayMemAbs>

    <arrayMemAbs>           ::= "[" <int> "]"

    <arrayMemRel>           ::= "[" <arrayMemReg> <arrayMemOffset> "]"

    <arrayMemReg>           ::= <addrUseS>

    <arrayMemOffset>        ::= /* empty */
                              | "+" <int>

    <progParamArrayMem>     ::= <arrayMemAbs>
                              | <progParamArrayRel>

    <progParamArrayRel>     ::= "[" <arrayMemReg> <arrayMemRegRelOffset> "]"

    <arrayMemRegRelOffset>  ::= /* empty */
                              | "+" <int>
                              | "-" <addrRegNegOffset>

    <addrRegNegOffset>      ::= <integer> from 0 to 64

    <arrayRange>            ::= "[" <int> ".." <int> "]"

    <instResultAddr>        ::= <addrUseVNS> <predicate>

    <addrUseS>              ::= <addrVarName> <scalarSuffix>

    <addrUseVNS>            ::= <addrVarName>

    <predicate>             ::= "(" <predicateTest> ")"

    <predicateTest>         ::= <optInvert> <predicateName> <swizzleSuffix>

    <predicateName>         ::= "P"<predicateRegNum>

    <predicateRegNum>       ::= <int> from 0 to MAX_PROGRAM_PREDICATES_MESA - 1

    <optInvert>             ::= /* empty */
                              | "!"

    <optWriteMask>          ::= /* empty */
                              | <xyzwMask>
                              | <rgbaMask>

    <xyzwMask>              ::= "." "x"
                              | "." "y"
                              | "." "xy"
                              | "." "z"
                              | "." "xz"
                              | "." "yz"
                              | "." "xyz"
                              | "." "w"
                              | "." "xw"
                              | "." "yw"
                              | "." "xyw"
                              | "." "zw"
                              | "." "xzw"
                              | "." "yzw"
                              | "." "xyzw"

    <rgbaMask>              ::= "." "r"
                              | "." "g"
                              | "." "rg"
                              | "." "b"
                              | "." "rb"
                              | "." "gb"
                              | "." "rgb"
                              | "." "a"
                              | "." "ra"
                              | "." "ga"
                              | "." "rga"
                              | "." "ba"
                              | "." "rba"
                              | "." "gba"
                              | "." "rgba"

    <swizzleSuffix>         ::= /* empty */
                              | "." <component>
                              | "." <xyzwSwizzle>
                              | "." <rgbaSwizzle>

    <extendedSwizzle>       ::= <extSwizComp> "," <extSwizComp> "," 
                                <extSwizComp> "," <extSwizComp>

    <extSwizComp>           ::= <optSign> <xyzwExtSwizSel>
                              | <optSign> <rgbaExtSwizSel>

    <xyzwExtSwizSel>        ::= "0"
                              | "1"
                              | <xyzwComponent>

    <rgbaExtSwizSel>        ::= <rgbaComponent>

    <scalarSuffix>          ::= "." <component>

    <component>             ::= <xyzwComponent>
                              | <rgbaComponent>

    <xyzwComponent>         ::= "x"
                              | "y"
                              | "z"
                              | "w"

    <rgbaComponent>         ::= "r"
                              | "g"
                              | "b"
                              | "a"

    <optSign>               ::= /* empty */
                              | "-"
                              | "+"

    <faceType>              ::= "front"
                              | "back"

    <colorType>             ::= "primary"
                              | "secondary"

    <instLabel>             ::= <identifier>

    <instTarget>            ::= <identifier>

    <establishedName>       ::= <identifier>

    <establishName>         ::= <identifier>


    Vertex programs are required to begin with the header string "!!ARBvp1.0".
    This header string identifies the subsequent program body as being a
    vertex program and indicates that it should be parsed according to the
    base MESA_gpu_program3 grammar plus the additions below.  Program string
    parsing begins with the character immediately following the header string.

    <ALUInstruction>        ::= <ARL_instruction>

    <ARL_instruction>       ::= <ARLop> <instResultAddr> "," <scalarSrcReg>

    <ARLop>                 ::= "ARL"
                              | "ARR"

    <ARLop_src>             ::= <instOperandV>

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

    <resultUseD>            ::= <resultColor>
                              | <resultColor> "." <colorType>
                              | <resultColor> "." <faceType>
                              | <resultColor> "." <faceType> "." <colorType>
                              | <resultMulti>

    <attribBasic>           ::= <vtxPrefix> "position"
                              | <vtxPrefix> "weight" <optArrayMemAbs>
                              | <vtxPrefix> "normal"
                              | <vtxPrefix> "fogcoord"
                              | <attribTexCoord> <optArrayMemAbs>
                              | <attribGeneric> <arrayMemAbs>

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

    <attribMulti>           ::= <attribTexCoord> <arrayRange>
                              | <attribGeneric> <arrayRange>

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

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

    <vtxPrefix>             ::= "vertex" "."

    <resultBasic>           ::= <resPrefix> "position"
                              | <resPrefix> "fogcoord"
                              | <resPrefix> "pointsize"
                              | <resultTexCoord> <optArrayMemAbs>

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

    <resultMulti>           ::= <resultTexCoord> <arrayRange>

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

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

    Fragment programs are required to begin with the header string
    "!!ARBfp1.0".  This header string identifies the subsequent program body
    as being a fragment program and indicates that it should be parsed
    according to the base MESA_gpu_program3 grammar plus the additions below.
    Program string parsing begins with the character immediately following the
    header string.

    <instruction>           ::= <SpecialInstruction>

    <varMods>               ::= <varModifier> <varMods>

    <varModifier>           ::= <interpModifier>

    <SpecialInstruction>    ::= "KIL" <killCond>
                              | "DDX" <instResult> "," <instOperandV>
                              | "DDY" <instResult> "," <instOperandV>

    <killCond>              ::= <instOperandV>
                              | <predicate>

    <interpModifier>        ::= "FLAT"
                              | "CENTROID"
                              | "NOPERSPECTIVE"

    <attribBasic>           ::= <fragPrefix> "fogcoord"
                              | <fragPrefix> "position"
                              | <fragPrefix> "facing"
                              | <attribTexCoord> <optArrayMemAbs>

    <attribColor>           ::= <fragPrefix> "color"

    <attribMulti>           ::= <attribTexCoord> <arrayRange>

    <attribTexCoord>        ::= <fragPrefix> "texcoord"

    <fragPrefix>            ::= "fragment" "."

    <resultBasic>           ::= <resPrefix> "color" <resultOptColorNum>
                              | <resPrefix> "depth"

    <resultOptColorNum>     ::= /* empty */
                             | "[" <colorNum> "]"

    <colorNum>              ::= <int> from 0 to MAX_DRAW_BUFFERS - 1

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

    The <int> rule matches an integer constant.  The integer consists of a
    sequence of one or more digits ("0" through "9"), or a sequence in
    hexadecimal form beginning with "0x" or "0X" followed by a sequence of one or more
    hexadecimal digits ("0" through "9", "a" through "f", "A" through "F").

    The <float> rule matches a floating-point constant consisting of an
    integer part, a decimal point, a fraction part, an "e" or "E", and an
    optionally signed integer exponent.  The integer and fraction parts both
    consist of a sequence of one or more digits ("0" through "9").  Either the
    integer part or the fraction parts (not both) may be missing; either the
    decimal point or the "e" (or "E") and the exponent (not both) may be
    missing.  Most grammar rules that allow floating-point values also allow
    integers matching the <int> rule.

    The <identifier> rule matches a sequence of one or more letters ("A"
    through "Z", "a" through "z"), digits ("0" through "9), underscores ("_"),
    or dollar signs ("$"); the first character must not be a number.  Upper
    and lower case letters are considered different (names are
    case-sensitive).  The following strings are reserved keywords and may not
    be used as identifiers:

        ABS, ADD, ALIAS, ARL, ARR, ATTRIB, BRK, CAL, CMP, COS,
        CUBE, DP2, DP2A, DP3, DP4, DPH, DST, ELSE, ENDIF, ENDREP, EX2,
        EXP, FLR, FRC, IF, LG2, LIT, LOG, LOOP, LRP, MAD, MAX, MIN,
        MOV, MUL, NRM, OPTION, OUTPUT, PARAM, POW, RCP, RECT, REP,
        RET, ROUND, RSQ, SCS, SEQ, SFL, SGE, SGT, SHADOW1D, SHADOW2D,
        SHADOWRECT, SIN, SLE, SLT, SNE, SSG, STR, SUB, SWZ, TEMP, TEX,
        TXB, TXD, TXL, TXP, XPD, fragment (for fragment programs
        only), program, result, state, texture, and vertex (for vertex
        programs only).

    The <tempVarName>, <paramVarName>, <attribVarName>, and <resultVarName>
    rules match identifiers that have been previously established
    as names of temporary, program parameter, attribute, and result
    variables, respectively.

    The <xyzwSwizzle> and <rgbaSwizzle> rules match any 4-character strings
    consisting only of the characters "x", "y", "z", and "w" (<xyzwSwizzle>)
    or "r", "g", "b", "a" (<rgbaSwizzle>).

    The error INVALID_OPERATION is generated if a program fails to load
    because it is not syntactically correct or for one of the semantic
    restrictions described in the following sections.

    A successfully loaded program is parsed into a sequence of instructions.
    Each instruction is identified by its tokenized name.  The operation of
    these instructions when executed is defined in section 2.X.4.  A
    successfully loaded program string replaces the program string previously
    loaded into the specified program object.  If the OUT_OF_MEMORY error is
    generated by ProgramStringARB, no change is made to the previous contents
    of the current program object.


    Section 2.X.3, Program Variables

    Programs may operate on a number of different variables during their
    execution.  The following sections define the different classes of
    variables that can be declared and used by a program.  

    Some variable classes require variable bindings.  Variable classes with
    bindings refer to state that is either generated or consumed outside the
    program.  Examples of variable bindings include a vertex's normal, the
    position of a vertex computed by a vertex program, an interpolated texture
    coordinate, and the diffuse color of light 1.  Variables that are used
    only during program execution do not have bindings.

    Variables may be declared explicitly according to the <namingStatement>
    grammar rule.  Explicit variable declarations allow a program to establish
    a variable name that can be used to refer to a specified resource in
    subsequent instructions.  Variables may be declared anywhere in the
    program string, but must be declared prior to use.  A program will fail to
    load if it declares the same variable name more than once, or if it refers
    to a variable name that has not been previously declared in the program
    string.

    Variables may also be declared implicitly, simply by using a variable
    binding as an operand in a program instruction.  Such uses are considered
    to automatically create a nameless variable using the specified binding.
    Only variable from classes with bindings can be declared implicitly.


    Section 2.X.3.1, Program Variable Types

    Explicit variable declarations may include one or more modifiers that
    specify additional information about the variable, such as the size and
    data type of the components of the variable.  Variable modifiers are
    specified according to the <varModifier> grammar rule.

    Explicitly declared fragment program attribute variables may have one or
    more interpolation modifiers that control how per-fragment values are
    computed.
 
    An attribute variable declared as "FLAT" will be flat-shaded.  For such
    variables, the value of the attribute will be constant over an entire
    primitive and will taken from the provoking vertex of the primitive, as
    described in Section 2.14.7.  If "FLAT" is not specified, attributes will
    be interpolated as described in Chapter 3, with the exception that
    attribute variables bound to colors will still be flat-shaded if the shade
    model (section 2.14.7) is FLAT.  If an attribute variable declared as
    "FLAT" corresponds to a texture coordinate replaced by a point sprite
    (s,t) value (section 3.3.1), the value of the attribute is undefined.
 
    An attribute variable declared as "CENTROID" will be interpolated using a
    point on or inside the primitive, if possible, when doing multisample line
    or polygon rasterization (sections 3.4.4 and 3.5.6).  This method can
    avoid artifacts during multisample rasterization when some samples of a
    pixel are covered, but the sample location used is outside the primitive.
    Note that when centroid sampling, the sample points used to generate
    attribute values for adjacent pixels may not be evenly spaced, which can
    lead to artifacts when evaluating partial derivatives or performing
    texture LOD calculations needed for mipmapping.  If "CENTROID" is not
    specified, attributes may be sampled anywhere inside the pixel as
    permitted by the specification, including at points outside the primitive.
 
    An attribute variable declared as "NOPERSPECTIVE" will be interpolated
    using a method that is linear in screen space, as described in equation
    3.7 and the approximation that follows equation 3.8.  If "NOPERSPECTIVE" is
    not specified, attributes must be interpolated with perspective
    correction, as described in equations 3.6 and 3.8.  When clipping lines or
    polygons, an alternate method is used to compute the attributes of
    vertices introduced by clipping when they are specified as "NOPERSPECTIVE"
    (section 2.14.8).
 
    Implicitly declared attribute variables (bindings used directly in a
    program instruction) will inherit the interpolation modifiers of any
    explicitly declared attribute variable using the same binding.  If no such
    variable exists, default interpolation modes will be used.
 
    For fragments generated by point primitives, DrawPixels, and Bitmap,
    interpolation modifiers have no effect.
 
    There are several additional limitations on the use of interpolation
    modifiers.  A fragment program will fail to load:
 
      * if an interpolation modifier is specified when declaring a
        non-attribute variable,
 
      * if the same interpolation modifier is specified more than once in a
        single declaration (e.g., "CENTROID CENTROID ATTRIB"),
 
      * if the "FLAT" modifier is used together with either "CENTROID" or
        "NOPERSPECTIVE" in a single declaration,
 
      * if any interpolation modifier is specified when declaring a variable
        bound to a fragment's position, face direction, or fog coordinate,
 
      * if multiple attribute variables with different interpolation modifiers
        are bound to the same fragment attribute, or
 
      * if one variable is bound to the fragment's primary color and a second
        variable with different interpolation modifiers is bound the the
        fragment's secondary color.

    Explicitly declared variables of all types may be declared as arrays.  An
    array variable has one or more members, numbered 0 through <n>-1, where
    <n> is the number of entries in the array.  The total number of entries in
    the array can be declared using the <optArraySize> grammar rule.  For
    variable classes without bindings, an array size must be specified in the
    program, and must be a positive integer.  For variable classes with
    bindings, a declared size is optional, and is taken from the number of
    bindings assigned in the declaration if omitted.  A program will fail to
    load if the declared size of an array variable does not match the number
    of assigned bindings.

    When a variable is declared as an array, instructions that use the
    variable must specify an array member to access according to the
    <arrayMem> grammar rule.  A program will fail to load if it contains an
    instruction that accesses an array variable without specifying an array
    member or an instruction that specifies an array member for a non-array
    variable.


    Section 2.X.3.2, Program Attribute Variables

    Program attribute variables represent per-vertex or per-fragment inputs to
    the program.  All attribute variables have associated bindings, and are
    read-only during program execution.  Attribute variables may be declared
    explicitly via the <ATTRIB_statement> grammar rule, or implicitly by using
    an attribute binding in an instruction.

    The set of available attribute bindings depends on the program type, and
    is enumerated in subsections below.

    The set of bindings allowed for attribute array variables is limited to
    attribute state grouped in arrays (e.g., texture coordinates, generic
    vertex attributes).  Additionally, all bindings assigned to the array must
    be of the same binding type and must increase consecutively.  Examples of
    valid and invalid binding lists include:

      vertex.attrib[1], vertex.attrib[2]      # valid, 2-entry array
      vertex.texcoord[0..3]                   # valid, 4-entry array
      vertex.attrib[1], vertex.attrib[3]      # invalid, skipped attrib 2
      vertex.attrib[2], vertex.attrib[1]      # invalid, wrong order
      vertex.attrib[1], vertex.texcoord[2]    # invalid, different types

    Additionally, attribute bindings may be used in no more than one array
    variable accessed with relative addressing.


    Section 2.X.3.2.1, Vertex Program Attribute Variables

    Vertex program attribute variables describe the attributes of the vertex
    being transformed, as specified by the application.  The set of available
    bindings is enumerated in Table X.X.

      Vertex Attribute Binding  Components  Underlying State
      ------------------------  ----------  ------------------------------
      vertex.position           (x,y,z,w)   object coordinates
      vertex.normal             (x,y,z,1)   normal
      vertex.color              (r,g,b,a)   primary color
      vertex.color.primary      (r,g,b,a)   primary color
      vertex.color.secondary    (r,g,b,a)   secondary color
      vertex.fogcoord           (f,0,0,1)   fog coordinate
      vertex.texcoord           (s,t,r,q)   texture coordinate, unit 0
      vertex.texcoord[n]        (s,t,r,q)   texture coordinate, unit n
      vertex.attrib[n]          (x,y,z,w)   generic vertex attribute n
      vertex.weight             (w,w,w,w)   vertex weights 0-3
      vertex.weight[n]          (w,w,w,w)   vertex weights n-n+3
      vertex.texcoord[n..o]     (x,y,z,w)   array of texture coordinates
      vertex.attrib[n..o]       (x,y,z,w)   array of generic vertex attributes

      Table X.X, Vertex Program Attribute Bindings.  <n> and <o> refer to
      integer constants.  Only the "vertex.texcoord" and "vertex.attrib"
      bindings are available in arrays.  The "Components" column
      indicates the mapping of the state in the "Underlying State" column.
      Values of "0" or "1" in the "Components" column indicate the constants
      0.0 and 1.0, respectively.  Bindings containing "[n]" require an integer
      value of <n> to select an individual item.

    If a vertex attribute binding matches "vertex.position", the "x", "y", "z"
    and "w" components of the vertex attribute variable are filled with the
    "x", "y", "z", and "w" components, respectively, of the vertex position.

    If a vertex attribute binding matches "vertex.normal", the "x", "y", and
    "z" components of the vertex attribute variable are filled with the "x",
    "y", and "z" components, respectively, of the vertex normal.  The "w"
    component is filled with 1.

    If a vertex attribute binding matches "vertex.color" or
    "vertex.color.primary", the "x", "y", "z", and "w" components of the
    vertex attribute variable are filled with the "r", "g", "b", and "a"
    components, respectively, of the vertex color.

    If a vertex attribute binding matches "vertex.color.secondary", the "x",
    "y", "z", and "w" components of the vertex attribute variable are filled
    with the "r", "g", "b", and "a" components, respectively, of the vertex
    secondary color.

    If a vertex attribute binding matches "vertex.fogcoord", the "x" component
    of the vertex attribute variable is filled with the vertex fog coordinate.
    The "y", "z", and "w" coordinates are filled with 0, 0, and 1,
    respectively.

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

    If a vertex attribute binding matches "vertex.weight" or
    "vertex.weight[n]", the "x", "y", "z", and "w" components of the vertex
    attribute variable are filled with vertex weights <n> through <n>+3,
    respectively.  If "[n]" is omitted, weights zero through three are used.
    For the purposes of this binding, all weights supported by the
    implementation but not set by the application are set to zero, including
    the extra derived weight corresponding to the fixed-function
    WEIGHT_SUM_UNITY_ARB enable.  For components whose corresponding weight is
    not supported by the implementation (i.e., numbered MAX_VERTEX_UNITS_ARB
    or larger), "y" and "z" components are set to 0.0 and "w" components are
    set to 1.0.  A vertex program will fail to load if a vertex attribute
    binding specifies a weight number <n> that is greater than or equal to
    MAX_VERTEX_UNITS_ARB or is not divisible by four.

    If a vertex attribute binding matches "vertex.attrib[n]", the "x", "y",
    "z" and "w" components of the generic vertex attribute variable are filled
    with the "x", "y", "z", and "w" components, respectively, of generic
    vertex attribute <n>.  Note that "vertex.attrib[0]" and "vertex.position"
    are equivalent.

    As described in section 2.7, setting a generic vertex attribute may leave
    a corresponding conventional vertex attribute undefined, and vice versa.
    To prevent inadvertent use of attribute pairs with undefined attributes, a
    vertex program will fail to load if it binds both a conventional vertex
    attribute and a generic vertex attribute listed in the same row of Table
    X.X.

      Conventional Attribute Binding      Generic Attribute Binding
      ------------------------------      -------------------------
      vertex.position                     vertex.attrib[0]
      vertex.weight                       vertex.attrib[1]
      vertex.weight[0]                    vertex.attrib[1]
      vertex.normal                       vertex.attrib[2]
      vertex.color                        vertex.attrib[3]
      vertex.color.primary                vertex.attrib[3]
      vertex.color.secondary              vertex.attrib[4]        
      vertex.fogcoord                     vertex.attrib[5]
      vertex.texcoord                     vertex.attrib[8]
      vertex.texcoord[0]                  vertex.attrib[8]
      vertex.texcoord[1]                  vertex.attrib[9]
      vertex.texcoord[2]                  vertex.attrib[10]
      vertex.texcoord[3]                  vertex.attrib[11]
      vertex.texcoord[4]                  vertex.attrib[12]
      vertex.texcoord[5]                  vertex.attrib[13]
      vertex.texcoord[6]                  vertex.attrib[14]
      vertex.texcoord[7]                  vertex.attrib[15]
      vertex.texcoord[n]                  vertex.attrib[8+n]

      Table X.X:  Invalid Vertex Attribute Binding Pairs.  Vertex programs
      may not bind both attributes listed in any row.  The <n> in the last row
      matches the number of any valid texture unit.

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


    Section 2.X.3.2.2, Fragment Program Attribute Variables

    Fragment program attribute variables describe the attributes of a fragment
    produced during rasterization.  The set of available bindings is
    enumerated in Table X.X.

    Most attributes correspond to per-vertex attributes that are interpolated
    over a primitive; such attributes are subject to the interpolation
    modifiers described in section 2.X.3.1.  The fragment's position, facing,
    and primitive IDs are the exceptions, and are generated specially during
    rasterization.  Since two-sided color selection occurs prior to
    rasterization, there are no distinct "front" or "back" colors available to
    fragment programs.  A single set of colors is available, which corresponds
    to interpolated front or back vertex colors.

    If vertex programs are enabled, attributes will be obtained by
    interpolating per-vertex outputs written by the vertex program.  The value
    of any attribute corresponding to a vertex output not written by the
    vertex program is undefined.

    If vertex programs are not used, attributes will be obtained by
    interpolating per-vertex values computed by fixed-function vertex
    processing.

      Fragment Attribute Binding  Components  Underlying State
      --------------------------  ----------  ----------------------------
        fragment.color            (r,g,b,a)   primary color
        fragment.color.primary    (r,g,b,a)   primary color
        fragment.color.secondary  (r,g,b,a)   secondary color
        fragment.texcoord         (s,t,r,q)   texture coordinate, unit 0
        fragment.texcoord[n]      (s,t,r,q)   texture coordinate, unit n
        fragment.fogcoord         (f,0,0,1)   fog distance/coordinate
        fragment.texcoord[n..o]   (s,t,r,q)   texture coordinates n thru o
      * fragment.position         (x,y,z,1/w) window position
      * fragment.facing           (f,-,-,-)   fragment facing

      Table X.X:  Fragment Attribute Bindings.  The "Components" column
      indicates the mapping of the state in the "Underlying State" column.
      Bindings containing "[n]" require an integer value of <n> to select an
      individual item.  Interpolation modifiers are not supported on variables
      that use bindings labeled with "*".

    If a fragment attribute binding matches "fragment.color" or
    "fragment.color.primary", the "x", "y", "z", and "w" components of the
    fragment attribute variable are filled with the "r", "g", "b", and "a"
    components, respectively, of the fragment's primary color.  Each
    fixed-point color component undergoes an implied conversion to floating
    point.  This conversion must leave the values 0 and 1 invariant.

    If a fragment attribute binding matches "fragment.color.secondary", the
    "x", "y", "z", and "w" components of the fragment attribute variable are
    filled with the "r", "g", "b", and "a" components, respectively, of the
    fragment's secondary color.  Each fixed-point color component undergoes an
    implied conversion to floating point.  This conversion must leave the
    values 0 and 1 invariant.

    If a fragment attribute binding matches "fragment.texcoord" or
    "fragment.texcoord[n]", the "x", "y", "z", and "w" components of the
    fragment attribute variable are filled with the "s", "t", "r", and "q"
    components, respectively, of the fragment texture coordinates for texture
    unit <n>.  If "[n]" is omitted, texture unit zero is used.

    If a fragment attribute binding matches "fragment.fogcoord", the "x"
    component of the fragment attribute variable is filled with either the
    fragment eye distance or the fog coordinate, depending on whether the fog
    source is set to FRAGMENT_DEPTH_EXT or FOG_COORDINATE_EXT, respectively.
    The "y", "z", and "w" coordinates are filled with 0, 0, and 1,
    respectively.

    If a fragment attribute binding matches "fragment.texcoord[n..o]", a sequence of 1+<o>-<n>
    bindings is created.  For texture coordinate bindings, it is as though the
    sequence "fragment.texcoord[n], fragment.texcoord[n+1],
    ... fragment.texcoord[o]" were specified.  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 fragment attribute binding matches "fragment.position", the "x" and
    "y" components of the fragment attribute variable are filled with the
    floating-point (x,y) window coordinates of the fragment center, relative
    to the lower left corner of the window.  The "z" component is filled with
    the fragment's z window coordinate.  If z window coordinates are
    represented internally by the GL as fixed-point values, the z window
    coordinate undergoes an implied conversion to floating point.  This
    conversion must leave the values 0 and 1 invariant.  The "w" component is
    filled with the reciprocal of the fragment's clip w coordinate.

    On some implementations, the components of fragment.position may be
    generated by interpolating per-vertex position values.  This may produce x
    and y window coordinates that don't exactly match those of the fragment
    center and z window coordinates that do not exactly match those generated
    by fixed-function rasterization.  Therefore, there is no guaranteed
    invariance between the final z window coordinates of fragments processed
    by fragment programs that write depth values and fragments processed by
    any other means, even if the fragment programs in question simply copy the
    z value from the fragment.position binding.

    If a fragment attribute binding matches "fragment.facing", the "x"
    component of the fragment attribute variable is filled with +1.0 or -1.0,
    depending on the orientation of the primitive producing the fragment.  If
    the fragment is generated by a back-facing polygon (including point- and
    line-mode polygons), the facing is -1.0; otherwise, the facing is +1.0.
    The "y", "z", and "w" coordinates are undefined.


    Section 2.X.3.3, Program Parameters

    Program parameter variables are used as constants during program
    execution.  All program parameter variables have associated bindings and
    are read-only during program execution.  Program parameters retain their
    values across program invocations, although their values may change
    between invocations due to GL state changes.  Program parameter variables
    may be declared explicitly via the <PARAM_statement> grammar rule, or
    implicitly by using a parameter binding in an instruction.

    When declaring program parameter array variables, all bindings are
    supported and can be assigned to array members in any order.  The only
    restriction is that no parameter binding may be used more than once in
    array variables accessed using relative addressing.  A program will fail
    to load if any program parameter binding is used more than once in a
    single array accessed using relative addressing or used at least once in
    two or more arrays accessed using relative addressing.


    Constant Bindings

    If a program parameter binding matches the <constantScalar> or
    <signedConstantScalar> grammar rules, the corresponding program parameter
    variable is bound to the vector (X,X,X,X), where X is the value of the
    specified constant.

    If a program parameter binding matches <constantVector>, the corresponding
    program parameter variable is bound to the vector (X,Y,Z,W), where X, Y,
    Z, and W are the values corresponding to the first, second, third, and
    fourth match of <signedConstantScalar>.  If fewer than four constants are
    specified, Y, Z, and W assume the values 0.0, 0.0, and 1.0, if their respective
    constants are not specified.


    Program Environment/Local Parameter Bindings

      Binding                    Components  Underlying State
      -------------------------  ----------  -------------------------------
      program.env[a]             (x,y,z,w)   program environment parameter a
      program.local[a]           (x,y,z,w)   program local parameter a
      program.env[a..b]          (x,y,z,w)   program environment parameters 
                                             a through b
      program.local[a..b]        (x,y,z,w)   program local parameters 
                                             a through b

      Table X.1:  Program Environment/Local Parameter Bindings.  <a> and <b>
      indicate parameter numbers, where <a> must be less than or equal to <b>.

    If a program parameter binding matches "program.env[a]" or
    "program.local[a]", the four components of the program parameter variable
    are filled with the four components of program environment parameter <a>
    or program local parameter <a> respectively.

    Additionally, for program parameter array bindings, "program.env[a..b]"
    and "program.local[a..b]" are equivalent to specifying program environment
    or local parameters <a> through <b> in order, respectively.  A program
    using any of these bindings will fail to load if <a> is greater than <b>.


    Material Property Bindings

      Binding                        Components  Underlying State
      -----------------------------  ----------  ----------------------------
      state.material.ambient         (r,g,b,a)   front ambient material color
      state.material.diffuse         (r,g,b,a)   front diffuse material color
      state.material.specular        (r,g,b,a)   front specular material color
      state.material.emission        (r,g,b,a)   front emissive material color
      state.material.shininess       (s,0,0,1)   front material shininess
      state.material.front.ambient   (r,g,b,a)   front ambient material color
      state.material.front.diffuse   (r,g,b,a)   front diffuse material color
      state.material.front.specular  (r,g,b,a)   front specular material color
      state.material.front.emission  (r,g,b,a)   front emissive material color
      state.material.front.shininess (s,0,0,1)   front material shininess
      state.material.back.ambient    (r,g,b,a)   back ambient material color
      state.material.back.diffuse    (r,g,b,a)   back diffuse material color
      state.material.back.specular   (r,g,b,a)   back specular material color
      state.material.back.emission   (r,g,b,a)   back emissive material color
      state.material.back.shininess  (s,0,0,1)   back material shininess

      Table X.3:  Material Property Bindings.  If a material face is not
      specified in the binding, the front property is used.

    If a program parameter binding matches any of the material properties
    listed in Table X.3, the program parameter variable is filled according to
    the table.  For ambient, diffuse, specular, or emissive colors, the "x",
    "y", "z", and "w" components are filled with the "r", "g", "b", and "a"
    components, respectively, of the corresponding material color.  For
    material shininess, the "x" component is filled with the material's
    specular exponent, and the "y", "z", and "w" components are filled with
    the floating-point constants 0, 0, and 1, respectively.  Bindings
    containing ".back" refer to the back material; all other bindings refer to
    the front material.

    Material properties can be changed inside a Begin/End pair, either
    directly by calling Material, or indirectly through color material.
    However, such property changes are not guaranteed to update program
    parameter bindings until the following End command.  Program parameter
    variables bound to material properties changed inside a Begin/End pair are
    undefined until the following End command.


    Light Property Bindings

      Binding                        Components  Underlying State
      -----------------------------  ----------  ----------------------------
      state.light[n].ambient         (r,g,b,a)   light n ambient color
      state.light[n].diffuse         (r,g,b,a)   light n diffuse color
      state.light[n].specular        (r,g,b,a)   light n specular color
      state.light[n].position        (x,y,z,w)   light n position
      state.light[n].attenuation     (a,b,c,e)   light n attenuation constants
                                                 and spot light exponent
      state.light[n].spot.direction  (x,y,z,c)   light n spot direction and
                                                 cutoff angle cosine
      state.light[n].half            (x,y,z,1)   light n infinite half-angle
      state.lightmodel.ambient       (r,g,b,a)   light model ambient color
      state.lightmodel.scenecolor    (r,g,b,a)   light model front scene color
      state.lightmodel.              (r,g,b,a)   light model front scene color
               front.scenecolor
      state.lightmodel.              (r,g,b,a)   light model back scene color
               back.scenecolor
      state.lightprod[n].ambient     (r,g,b,a)   light n / front material
                                                 ambient color product
      state.lightprod[n].diffuse     (r,g,b,a)   light n / front material
                                                 diffuse color product
      state.lightprod[n].specular    (r,g,b,a)   light n / front material
                                                 specular color product
      state.lightprod[n].            (r,g,b,a)   light n / front material
              front.ambient                      ambient color product
      state.lightprod[n].            (r,g,b,a)   light n / front material
              front.diffuse                      diffuse color product
      state.lightprod[n].            (r,g,b,a)   light n / front material
              front.specular                     specular color product
      state.lightprod[n].            (r,g,b,a)   light n / back material
              back.ambient                       ambient color product
      state.lightprod[n].            (r,g,b,a)   light n / back material
              back.diffuse                       diffuse color product
      state.lightprod[n].            (r,g,b,a)   light n / back material
              back.specular                      specular color product

      Table X.4: Light Property Bindings.  <n> indicates a light number.

    If a program parameter binding matches "state.light[n].ambient",
    "state.light[n].diffuse", or "state.light[n].specular", the "x", "y", "z",
    and "w" components of the program parameter variable are filled with the
    "r", "g", "b", and "a" components, respectively, of the corresponding
    light color.

    If a program parameter binding matches "state.light[n].position", the "x",
    "y", "z", and "w" components of the program parameter variable are filled
    with the "x", "y", "z", and "w" components, respectively, of the light
    position.
    
    If a program parameter binding matches "state.light[n].attenuation", the
    "x", "y", and "z" components of the program parameter variable are filled
    with the constant, linear, and quadratic attenuation parameters of the
    specified light, respectively (section 2.13.1).  The "w" component of the
    program parameter variable is filled with the spot light exponent of the
    specified light.

    If a program parameter binding matches "state.light[n].spot.direction",
    the "x", "y", and "z" components of the program parameter variable are
    filled with the "x", "y", and "z" components of the spot light direction
    of the specified light, respectively (section 2.13.1).  The "w" component
    of the program parameter variable is filled with the cosine of the spot
    light cutoff angle of the specified light.

    If a program parameter binding matches "state.light[n].half", the "x",
    "y", and "z" components of the program parameter variable are filled with
    the x, y, and z components, respectively, of the normalized infinite
    half-angle vector

      h_inf = || P + (0, 0, 1) ||.

    The "w" component is filled with 1.0.  In the computation of h_inf, P
    consists of the x, y, and z coordinates of the normalized vector from the
    eye position P_e to the eye-space light position P_pli (section 2.13.1).
    h_inf is defined to correspond to the normalized half-angle vector when
    using an infinite light (w coordinate of the position is zero) and an
    infinite viewer (v_bs is FALSE).  For local lights or a local viewer,
    h_inf is well-defined but does not match the normalized half-angle vector,
    which will vary depending on the vertex position.

    If a program parameter binding matches "state.lightmodel.ambient", the
    "x", "y", "z", and "w" components of the program parameter variable are
    filled with the "r", "g", "b", and "a" components of the light model
    ambient color, respectively.

    If a program parameter binding matches "state.lightmodel.scenecolor" or
    "state.lightmodel.front.scenecolor", the "x", "y", and "z" components of
    the program parameter variable are filled with the "r", "g", and "b"
    components respectively of the "front scene color"

      c_scene = a_cs * a_cm + e_cm,

    where a_cs is the light model ambient color, a_cm is the front ambient
    material color, and e_cm is the front emissive material color.  The "w"
    component of the program parameter variable is filled with the alpha
    component of the front diffuse material color.  If a program parameter
    binding matches "state.lightmodel.back.scenecolor", a similar back scene
    color, computed using back-facing material properties, is used.  The front
    and back scene colors match the values that would be assigned to vertices
    using conventional lighting if all lights were disabled.

    If a program parameter binding matches anything beginning with
    "state.lightprod[n]", the "x", "y", and "z" components of the program
    parameter variable are filled with the "r", "g", and "b" components,
    respectively, of the corresponding light product.  The three light product
    components are the products of the corresponding color components of the
    specified material property and the light color of the specified light
    (see Table X.4).  The "w" component of the program parameter variable is
    filled with the alpha component of the specified material property.

    Light products depend on material properties, which can be changed inside
    a Begin/End pair.  Such property changes are not guaranteed to take effect
    until the following End command.  Program parameter variables bound to
    light products whose corresponding material property changes inside a
    Begin/End pair are undefined until the following End command.


    Texture Coordinate Generation Property Bindings

      Binding                    Components  Underlying State
      -------------------------  ----------  ----------------------------
      state.texgen[n].eye.s      (a,b,c,d)   TexGen eye linear plane
                                             coefficients, s coord, unit n
      state.texgen[n].eye.t      (a,b,c,d)   TexGen eye linear plane
                                             coefficients, t coord, unit n
      state.texgen[n].eye.r      (a,b,c,d)   TexGen eye linear plane
                                             coefficients, r coord, unit n
      state.texgen[n].eye.q      (a,b,c,d)   TexGen eye linear plane
                                             coefficients, q coord, unit n
      state.texgen[n].object.s   (a,b,c,d)   TexGen object linear plane
                                             coefficients, s coord, unit n
      state.texgen[n].object.t   (a,b,c,d)   TexGen object linear plane
                                             coefficients, t coord, unit n
      state.texgen[n].object.r   (a,b,c,d)   TexGen object linear plane
                                             coefficients, r coord, unit n
      state.texgen[n].object.q   (a,b,c,d)   TexGen object linear plane
                                             coefficients, q coord, unit n

      Table X.5:  Texture Coordinate Generation Property Bindings.  "[n]" is
      optional -- texture unit <n> is used if specified; texture unit 0 is
      used otherwise.

    If a program parameter binding matches a set of TexGen plane coefficients,
    the "x", "y", "z", and "w" components of the program parameter variable
    are filled with the coefficients p1, p2, p3, and p4, respectively, for
    object linear coefficients, and the coefficients p1', p2', p3', and p4',
    respectively, for eye linear coefficients (section 2.10.4).


    Fog Property Bindings

      Binding                        Components  Underlying State
      -----------------------------  ----------  ----------------------------
      state.fog.color                (r,g,b,a)   RGB fog color (section 3.10)
      state.fog.params               (d,s,e,r)   fog density, linear start
                                                 and end, and 1/(end-start)
                                                 (section 3.10) 

      Table X.6:  Fog Property Bindings

    If a program parameter binding matches "state.fog.color", the "x", "y",
    "z", and "w" components of the program parameter variable are filled with
    the "r", "g", "b", and "a" components, respectively, of the fog color
    (section 3.10).

    If a program parameter binding matches "state.fog.params", the "x", "y",
    and "z" components of the program parameter variable are filled with the
    fog density, linear fog start, and linear fog end parameters (section
    3.10), respectively.  The "w" component is filled with 1/(end-start),
    where end and start are the linear fog end and start parameters,
    respectively.


    Clip Plane Property Bindings

      Binding                        Components  Underlying State
      -----------------------------  ----------  ----------------------------
      state.clip[n].plane            (a,b,c,d)   clip plane n coefficients

      Table X.7:  Clip Plane Property Bindings.  <n> specifies the clip plane
      number, and is required.

    If a program parameter binding matches "state.clip[n].plane", the "x",
    "y", "z", and "w" components of the program parameter variable are filled
    with the coefficients p1', p2', p3', and p4', respectively, of clip plane
    <n> (section 2.11).


    Point Property Bindings

      Binding                        Components  Underlying State
      -----------------------------  ----------  ----------------------------
      state.point.size               (s,n,x,f)   point size, min and max size
                                                 clamps, and fade threshold
                                                 (section 3.3) 
      state.point.attenuation        (a,b,c,1)   point size attenuation consts

      Table X.8:  Point Property Bindings

    If a program parameter binding matches "state.point.size", the "x", "y",
    "z", and "w" components of the program parameter variable are filled with
    the point size, minimum point size, maximum point size, and fade
    threshold, respectively (section 3.3).

    If a program parameter binding matches "state.point.attenuation", the "x",
    "y", and "z" components of the program parameter variable are filled with
    the constant, linear, and quadratic point size attenuation parameters (a,
    b, and c), respectively (section 3.3).  The "w" component is filled with
    1.0.


    Texture Environment Property Bindings

      Binding                    Components  Underlying State
      -------------------------  ----------  ----------------------------
      state.texenv[n].color      (r,g,b,a)   texture environment n color

      Table X.9:  Texture Environment Property Bindings.  "[n]" is optional --
      texture unit <n> is used if specified; texture unit 0 is used otherwise.

    If a program parameter binding matches "state.texenv[n].color", the "x",
    "y", "z", and "w" components of the program parameter variable are filled
    with the "r", "g", "b", and "a" components, respectively, of the
    corresponding texture environment color.  Note that only "legacy" texture
    units, as queried by MAX_TEXTURE_UNITS, include texture environment state.
    Texture image units and texture coordinate sets do not have associated
    texture environment state.


    Depth Property Bindings

      Binding                      Components  Underlying State
      ---------------------------  ----------  ----------------------------
      state.depth.range            (n,f,d,1)   Depth range near, far, and
                                               (far-near) (section 2.10.1)

      Table X.10:  Depth Property Bindings

    If a program parameter binding matches "state.depth.range", the "x" and
    "y" components of the program parameter variable are filled with the
    mappings of near and far clipping planes to window coordinates,
    respectively.  The "z" component is filled with the difference of the
    mappings of near and far clipping planes, far minus near.  The "w"
    component is filled with 1.0.


    Matrix Property Bindings

      Binding                               Underlying State
      ------------------------------------  ---------------------------
      * state.matrix.modelview[n]           modelview matrix n
        state.matrix.projection             projection matrix
        state.matrix.mvp                    modelview-projection matrix
      * state.matrix.texture[n]             texture matrix n
        state.matrix.program[n]             program matrix n

      Table X.11:  Base Matrix Property Bindings.  The "[n]" syntax indicates
      a specific matrix number.  For modelview and texture matrices, a matrix
      number is optional, and matrix zero will be used if the matrix number is
      omitted.  These base bindings may further be modified by a
      inverse/transpose selector and a row selector.

    If the beginning of a program parameter binding matches any of the matrix
    binding names listed in Table X.11, the binding corresponds to a 4x4
    matrix.  If the parameter binding is followed by ".inverse", ".transpose",
    or ".invtrans" (<stateMatModifier> grammar rule), the inverse, transpose,
    or transpose of the inverse, respectively, of the matrix specified in
    Table X.11 is selected.  Otherwise, the matrix specified in Table X.11 is
    selected.  If the specified matrix is poorly-conditioned (singular or
    nearly so), its inverse matrix is undefined.  The binding name
    "state.matrix.mvp" refers to the product of modelview matrix zero and the
    projection matrix, defined as

       MVP = P * M0,

    where P is the projection matrix and M0 is modelview matrix zero.

    If the selected matrix is followed by ".row[<a>]" (matching the
    <stateMatrixRow> grammar rule), the "x", "y", "z", and "w" components of
    the program parameter variable are filled with the four entries of row <a>
    of the selected matrix.  In the example,

      PARAM m0 = state.matrix.modelview[1].row[0];
      PARAM m1 = state.matrix.projection.transpose.row[3];

    the variable "m0" is set to the first row (row 0) of modelview matrix 1
    and "m1" is set to the last row (row 3) of the transpose of the projection
    matrix.

    For program parameter array bindings, multiple rows of the selected matrix
    can be bound via the <stateMatrixRows> grammar rule.  If the selected
    matrix binding is followed by ".row[<a>..<b>]", the result is equivalent
    to specifying matrix rows <a> through <b>, in order.  A program will fail
    to load if <a> is greater than <b>.  If no row selection is specified
    (<optMatrixRows> matches ""), matrix rows 0 through 3 are bound in order.
    In the example,

      PARAM m2[] = { state.matrix.program[0].row[1..2] };
      PARAM m3[] = { state.matrix.program[0].transpose };

    the array "m2" has two entries, containing rows 1 and 2 of program matrix
    zero, and "m3" has four entries, containing all four rows of the transpose
    of program matrix zero.


    Section 2.X.3.4, Program Temporaries

    Program temporary variables are a set of four-component
    floating-point vectors used to hold temporary results during
    program execution.  Temporaries do not persist between program
    invocations, and are undefined at the beginning of each program
    invocation.

    Temporary variables are declared explicitly using the <TEMP_statement>
    grammar rule.  Each such statement can declare one or more temporaries.
    Temporaries cannot be declared implicitly.


    Section 2.X.3.5, Program Results

    Program result variables represent the per-vertex or per-fragment results
    of the program.  All result variables have associated bindings, are
    write-only during program execution, and are undefined at the beginning of
    each program invocation.  Any vertex or fragment attributes corresponding
    to unwritten result variables will be undefined in subsequent stages of
    the pipeline.  Result variables may be declared explicitly via the
    <OUTPUT_statement> grammar rule, or implicitly by using a result binding
    in an instruction.

    The set of available result bindings depends on the program type, and is
    enumerated in subsections below.

    Result variables may generally be declared as arrays, but the set of
    bindings allowed for arrays is limited to state grouped in arrays (e.g.,
    texture coordinates, colors).  Additionally, all bindings
    assigned to the array must be of the same binding type and must increase
    consecutively.  Examples of valid and invalid binding lists for vertex
    programs include:

      result.texcoord[1], result.texcoord[2]  # valid, 2-entry array
      result.texcoord[0..3]                   # valid, 4-entry array
      result.texcoord[1], result.texcoord[3]  # invalid, skipped texcoord 2
      result.texcoord[2], result.texcoord[1]  # invalid, wrong order

    Additionally, result bindings may be used in no more than one array
    addressed with relative addressing.

    Section 2.X.3.5.1, Vertex Program Results

    Vertex programs produce vertices, and the set of result variables
    available to such programs correspond to the attributes of a transformed
    vertex.  The set of allowable result variable bindings for vertex and
    fragment programs is given in Table X.4.

      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.texcoord[n..o]          (s,t,r,q)   texture coordinates n thru o

      Table X.4:  Vertex Program 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 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.4.  Color bindings that do not specify
    "front" or "back" are considered 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.texcoord[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 specified.  This binding is available only in
    explicit declarations of array variables.  A program will fail to load if
    <n> is greater than <o>.


    Section 2.X.3.5.2, Fragment Program Results

    Fragment programs produce final fragment values, and the set of result
    variables available to such programs correspond to the final attributes of
    a fragment.  Fragment program result variables may not be declared as
    arrays.

    The set of allowable result variable bindings is given in Table X.X.

      Binding                        Components  Description
      -----------------------------  ----------  ----------------------------
      result.color                   (r,g,b,a)   color
      result.color[n]                (r,g,b,a)   color output n
      result.depth                   (*,*,d,*)   depth coordinate

      Table X.X:  Fragment Result Variable Bindings.
      Components labeled "*" are unused.

    If a result variable binding matches "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 fragment's output color.  If
    "result.color" is not both bound by the fragment program and written by
    some instruction of the program, the output color of the fragment program
    is undefined.

    If a result variable binding matches "result.color[n]" , updates to the "x", "y",
    "z", and "w" components of the color result variable modify the "r", "g",
    "b", and "a" components, respectively, of the fragment output color
    numbered <n>.

    If a result variable binding matches "result.depth", updates to the "z"
    component of the result variable modify the fragment's output depth value.
    If the "result.depth" binding is not in used in a variable written to by
    any instruction in the fragment program, the interpolated depth value
    produced by rasterization is used as if fragment program mode is not
    enabled.  Otherwise, the value written by the fragment program is used,
    and the fragment's final depth value is undefined if the program did not
    end up writing a depth value due to flow control or write masks.  Writes
    to any component of depth other than the "z" component have no effect.


    Section 2.X.3.6,  Vertex Program Address Registers

    Vertex program address register variables are a set of four-component
    signed integer vectors.  Address registers are used as indices when
    performing relative addressing in program parameter arrays (section
    2.X.4.2).

    Vertex program address registers can be declared explicitly using the
    <ADDRESS_statement> grammar rule.  Each such statement can declare one or
    more address registers.  Vertex program address registers can not be
    declared implicitly.

    Vertex program address register variables are undefined at each vertex
    program invocation.  Address registers can be written by the ARL
    instruction (section 2.X.8.Y), and will be read when a program uses
    relative addressing in program parameter arrays.

    Vertex program address register variables are undefined at each vertex
    program invocation.  Address registers can be written by the ARL and ARR
    instructions (section 2.X.8), and will be read when a program uses
    relative addressing in program parameter arrays.


    Section 2.X.3.7,  Program Predication Registers

    FINISHME.


    Section 2.X.3.8, Program Aliases

    Programs can create aliases by matching the <ALIAS_statement> grammar
    rule.  Aliases allow programs to use multiple variable names to refer to a
    single underlying variable.  For example, the statement

      ALIAS var1 = var0

    establishes a variable name of "var1".  Subsequent references to "var1" in
    the program text are treated as references to "var0".  The left hand side
    of an ALIAS statement must be a new variable name, and the right hand side
    must be an established variable name.

    Aliases are not considered variable declarations, so do not count against
    the limits on the number of variable declarations allowed in the program
    text.


    Section 2.X.3.9, Program Resource Limits

    (see ARB_vertex_program specification, incorporates all the different
    limits on instruction counts, temporaries, attribute bindings, program
    parameters, and so on)


    Section 2.X.4, Program Execution Environment

    The set of instructions supported for GPU programs is given in Table X.13
    below and is described in detail in Section 2.X.8.  An instruction can use
    up to three operands when it executes, and most instructions can write a
    single result vector.

      Instruction    Out Inputs   Description
      -----------    --- ------   --------------------------------
      ABS            v   v         absolute value
      ADD            v   v,v       add
      ARL%           a   v         address register load
      ARR%           a   v         address register load with rounding
      BRK            -   p         break out of loop instruction
      CAL            -   p         subroutine call
      CMP            v   v,v,v     compare
      COS            s   s         cosine with reduction to [-PI,PI]
      DDX*           v   v         partial derivative relative to X
      DDY*           v   v         partial derivative relative to Y
      DP2            s   v,v       2-component dot product
      DP2A           s   v,v,v     2-comp. dot product w/scalar add
      DP3            s   v,v       3-component dot product
      DP4            s   v,v       4-component dot product
      DPH            s   v,v       homogeneous dot product
      DST            v   v,v       distance vector
      ELSE           -   -         start if test else block
      ENDIF          -   -         end if test block
      ENDLOOP        -   -         end of loop block
      ENDREP         -   -         end of repeat block
      EX2            s   s         exponential base 2
      EXP            s   v         exponential base 2 (approximate)
      FLR            v   v         floor
      FRC            v   v         fraction
      IF             -   p         start of if test block
      KIL*           -   v         kill fragment
      KIL*           -   p         kill fragment (predicate)
      LG2            s   s         logarithm base 2
      LIT            v   v         compute lighting coefficients
      LOG            s   v         logarithm base 2 (approximate)
      LOOP           a   v         start of loop block
      LRP            v   v,v,v     linear interpolation
      MAD            v   v,v,v     multiply and add
      MAX            v   v,v       maximum
      MIN            v   v,v       minimum
      MOV            v   v         move
      MUL            v   v,v       multiply
      NRM            v   v         normalize 3-component vector
      POW            s   s,s       exponentiate
      RCP            s   s         reciprocal
      REP            -   v         start of repeat block
      RET            -   p         subroutine return
      ROUND          v   v         round to nearest integer
      RSQ            s   s         reciprocal square root
      SCS            v   s         sine/cosine without reduction
      SEQ            v   v,v       set on equal
      SFL            v   v,v       set on false
      SGE            v   v,v       set on greater than or equal
      SGT            v   v,v       set on greater than
      SIN            s   s         sine with reduction to [-PI,PI]
      SLE            v   v,v       set on less than or equal
      SLT            v   v,v       set on less than
      SNE            v   v,v       set on not equal
      SSG            v   v         set sign
      STR            v   v,v       set on true
      SUB            v   v,v       subtract
      SWZ            v   v         extended swizzle
      TEX            v   v         texture sample
      TXB            v   v         texture sample with bias
      TXD            v   v,v,v     texture sample w/partials      
      TXL            v   v         texture sample w/LOD
      TXP            v   v         texture sample w/projection
      XPD            v   v,v       cross product

      Table X.13:  Summary of MESA_gpu_program3 instructions.  Instruction
      opcodes marked with * are restricted to fragment programs only.
      Instruction opcodes marked with % a restricted to vertex programs only.

      The input and output columns describe the formats of the operands and
      results of the instruction.

        v:  4-component vector (data type is inherited from operation)
        a:  4-component vector (data type is signed address)
        s:  scalar (replicated if written to a vector destination;
                    data type is inherited from operation)
        p:  predicate register


    Section 2.X.4.2, Program Operands

    Most program instructions operate on one or more scalar or vector
    operands.  Each operand specifies an operand variable, which is either the
    name of a previously declared variable or an implicit variable declaration
    created by using a variable binding in the instruction.  Attribute,
    parameter, or parameter buffer variables can be declared implicitly by
    using a valid binding name in an operand.  Instruction operands are
    specified by the <instOperandV>, <instOperandS>, or <instOperandVNS>
    grammar rules.

    If the operand variable is not an array, its contents are loaded directly.
    If the operand variable is an array, a single element of the array is
    loaded according to the <arrayMem> grammar rule.  The elements of an array
    are numbered from 0 to <n>-1, where <n> is the number of entries in the
    array.  Array members can be accessed using either absolute or relative
    addressing.

    Absolute array addressing is used when the <arrayMemAbs> grammar rule is
    matched; the array member to load is specified by the matching integer.
    Out-of-bounds array absolute accesses are not allowed.  If the specified
    member number is greater than or equal to the size of the array, the
    program will fail to load.

    Relative array addressing is used when the <arrayMemRel> grammar rule is
    matched.  This grammar rule allows the program to specify a scalar address register
    operand and an optional constant offset, according to the <arrayMemReg>
    and <arrayMemOffset> grammar rules.  When performing relative addressing,
    the GL evaluates the specified scalar address register operand (according to the
    rules specified in this section) and adds the constant offset.  The array
    member loaded is given by this sum.  The constant offset is considered
    zero if an offset is omitted.  If the sum is negative or exceeds the size
    of the array, the results of the access are undefined, but may not lead to
    program or GL termination.  The set of constant offsets supported for
    relative addressing is limited to values in the range -64 (for program
    parameter arrays) or 0 (attribute and result arrays) to the maximum
    array size supprted by the implementation.  A program
    will fail to load if it specifies an offset outside that range.
 
    The following pseudo-code spells out the process of loading a program
    parameter from an array.  "addrReg" refers to the address register
    component used for relative addressing, "absolute" is TRUE if the operand
    uses absolute addressing and FALSE otherwise.  "paramNumber" is the
    program parameter number for absolute addressing; "paramOffset" is the
    constant program parameter offset for relative addressing.  "paramArray"
    is the parameter array that matches the <paramVarName>, <attribVarName>,
    or <resultVarName> rules.

      floatVec ProgramParameterLoad(int addrReg)
      {
        int index;
        
        if (absolute) {
          index = paramNumber;
        } else {
          index = addrReg + paramOffset
        }

        return paramArray[index];
      }

    After the operand is loaded, its components can be rearranged according to
    the <swizzleSuffix> grammar rule, or it can be converted to a scalar
    operand according to the <scalarSuffix> grammar rule.

    The <swizzleSuffix> grammar rule rearranges the components of a loaded
    vector to produce another vector.  If the <swizzleSuffix> rule matches the
    <xyzwSwizzle> or <rgbaSwizzle> grammar rule, a pattern of the form ".????"
    is used, where each question mark is replaced with one of "x", "y", "z",
    "w", "r", "g", "b", or a".  For such patterns, the x, y, z, and w
    components of the operand are taken from the vector components named by
    the first, second, third, and fourth character of the pattern,
    respectively.  Swizzle components of "r", "g", "b", and "a" are equivalent
    to "x", "y", "z", and "w", respectively.  For example, if the swizzle
    suffix is ".yzzx" or ".gbbr" and the specified source contains {2,8,9,0},
    the result is the vector {8,9,9,2}.  If the <swizzleSuffix> matches the
    <component> grammar rule, a pattern of the form ".?" is used.  For this
    pattern, all four components of the operand are taken from the single
    component identified by the pattern.  If the swizzle suffix is omitted,
    components are not rearranged and swizzling has no effect, as though
    ".xyzw" were specified.

    The swizzle suffix rules do not allow mixing "x", "y", "z", or "w"
    selectors with "r", "g", "b", or "a" selectors.  A program will fail to
    load if it contains a swizzle suffix with selectors from both of these
    sets.

    The <scalarSuffix> grammar rule converts a vector to a scalar by selecting
    a single component.  The <scalarSuffix> rule is similar to the swizzle
    selector, except that only a single component is selected.  If the scalar
    suffix is ".y" and the specified source contains {2,8,9,0}, the value is
    the scalar value 8.

    Next, a component-wise negate operation is performed on the operand if the
    <operandNeg> grammar rule matches "-".  Negation is not performed if the
    operand has no sign prefix, or is prefixed with "+".

    Next, a component-wise absolute value operation is performed on the
    operand if the <instOperandAbsV> or <instOperandAbsS> grammar rule is
    matched, by surrounding the operand with two "|" characters.  The result
    is optionally negated if the <operandAbsNeg> grammar rule matches "-".

    The following pseudo-code spells out the operand generation process.  In
    the example, "float" is a floating-point scalar type, while "floatVec" is
    a four-component vector.  "source" refers to the register used for the
    operand, matching the <srcReg> rule.  "abs" is TRUE if an absolute value
    operation should be performed on the operand (<instOperandAbsV> or
    <instOperandAbsS> rules) "negate" is TRUE if the <optionalSign> rule in
    <scalarSrcReg> or <swizzleSrcReg> matches "-" and FALSE otherwise.  The
    ".c***", ".*c**", ".**c*", ".***c" modifiers refer to the x, y, z, and w
    components obtained by the swizzle operation; the ".c" modifier refers to
    the single component selected for a scalar load.

      floatVec VectorLoad(floatVec source)
      {
          floatVec operand;

          operand.x = source.c***;
          operand.y = source.*c**;
          operand.z = source.**c*;
          operand.w = source.***c;
          if (abs) {
             operand.x = abs(operand.x);
             operand.y = abs(operand.y);
             operand.z = abs(operand.z);
             operand.w = abs(operand.w);
          }
          if (negate) {
             operand.x = -operand.x;
             operand.y = -operand.y;
             operand.z = -operand.z;
             operand.w = -operand.w;
          }

          return operand;
      }

      float ScalarLoad(floatVec source) 
      {
          float operand;

          operand = source.c;
          if (abs) {
             operand = abs(operand);
          }
          if (negate) {
            operand = -operand;
          }

          return operand;
      }


    Section 2.X.4.3, Program Destination Variable Update

    Most program instructions perform computations that produce a result,
    which will be written to a variable.  Each instruction that computes a
    result specifies a destination variable, which is either the name of a
    previously declared variable or an implicit variable declaration created
    by using a variable binding in the instruction.  Result variables can be
    declared implicitly by using a valid program result binding name in the
    result portion of the instruction.  Instruction results are specified
    according to the <instResult> grammar rule.

    The destination variable may be a single member of an array.  In this
    case, a single array member is specified using the <arrayMem> grammar
    rule, and the array member to update is computed in the exact same manner
    as done for operand loads.  If the array member is computed at run time,
    and is negative or greater than or equal to the size of the array, the
    results of the destination variable update are undefined and could result
    in overwriting other program variables.

    Writes to individual components of a vector destination variable can be
    controlled at compile time by individual component write masks specified
    in the instruction.  The component write mask is specified by the
    <optWriteMask> grammar rule, and is a string of up to four characters,
    naming the components to enable for writing.  If no write mask is
    specified, all components are enabled for writing.  The characters "x",
    "y", "z", and "w" match the x, y, z, and w components respectively.  For
    example, a write mask mask of ".xzw" indicates that the x, z, and w
    components should be enabled for writing but the y component should not be
    written.  The grammar requires that the destination register mask
    components must be listed in "xyzw" order.  Additionally, write mask
    components of "r", "g", "b", and "a" are equivalent to "x", "y", "z", and
    "w", respectively.  The grammar does not allow mixing "x", "y", "z", or
    "w" components with "r", "g", "b", and "a" ones.

    The following pseudocode illustrates the process of writing a result
    vector to the destination register.  In the pseudocode, "instrmask" refers
    to the component write mask given by the <optionalMask> rule.  "result"
    and "destination" refer to the result vector and the register selected by
    <dstReg>, respectively.
 
      void UpdateDestination(floatVec destination, floatVec result)
      {
          floatVec merged;
 
          // Merge the converted result into the destination register, under
          // control of the compile-time write mask.
          merged = destination;
          if (instrMask.x) {
              merged.x = result.x;
          }
          if (instrMask.y) {
              merged.y = result.y;
          }
          if (instrMask.z) {
              merged.z = result.z;
          }
          if (instrMask.w) {
              merged.w = result.w;
          }
 
          // Write out the new destination register.
          destination = merged;
      }
 
 
    Section 2.14.4.4,  Vertex Program Result Processing
 
    As a vertex program executes, it will write to one or more result
    registers that are mapped to transformed vertex attributes.  When a vertex
    program completes, the transformed vertex attributes are used to generate
    primitives.
 
    The clip coordinates written to "result.position" are used to generate
    normalized device coordinates and window coordinates for the vertex in the
    manner described section 2.10.
 
    Transformed vertices are then assembled into primitives and clipped as
    described in section 2.11.
 
    The selection between front-facing and back-facing color attributes
    depends on the primitive to which the vertex belongs.  If the primitive is
    a point or a line segment, or if vertex program two-sided color mode is
    disabled, the front-facing colors are always selected.  If it is a polygon
    and two-sided color mode is enabled, then the selection is performed in
    exactly the same way as in two-sided lighting mode (section 2.13.1).
    Vertex program two-sided color mode is enabled and disabled by calling
    Enable or Disable with the symbolic value VERTEX_PROGRAM_TWO_SIDE_ARB.
 
    Finally, as primitives are assembled, color clamping (section 2.13.6),
    flatshading (section 2.13.7), color, attribute clipping (section 2.13.8),
    and final color processing (section 2.13.9) operations are applied to the
    transformed vertices.


    Section 2.X.4.4, Program Texture Access

    Certain program instructions may access texture images, as described in
    section 3.8.  The coordinates, level-of-detail, and partial derivatives
    used for performing the texture lookup are derived from values provided in
    the program as described in the various sub-sections of Section 2.X.8.
    These descriptions use the function

      float_vec
        TextureSample(float_vec coord, float lod, float_vec ddx, 
                      float_vec ddy);

    which obtains a filtered texel value <tau> as described in Section 3.8.8
    and returns a 4-component vector (R,G,B,A) according to the format
    conversions specified in Table 3.21.

    <coord> is a four-component floating-point vector from which the (s,t,r)
    texture coordinates used for the texture access
    and the reference value used for depth comparisons (section
    3.8.14) are extracted according to Table X.17.  If the texture is a cube
    map, (s,t,r) is projected to one of the six cube faces to produce a new
    (s,t) vector according to Section 3.8.6.

    <lod> specifies the level of detail parameter and replaces the value
    computed in equation 3.18.  <ddx> and <ddy> specify partial derivatives
    (ds/dx, dt/dx, dr/dx, ds/dy, dt/dy, and dr/dy) for the texture
    coordinates, and may be used to derive footprint shapes for anisotropic
    texture filtering.

    The texture used by TextureSample() is one of the textures bound to the
    texture image unit whose number is specified in the instruction according
    to the <texImageUnit> grammar rule.  The texture target accessed is
    specified according to the <texTarget> grammar rule and Table X.17.
    Fixed-function texture enables are always ignored when determining the
    texture to access in a program.

                                                     coordinates used
      texTarget          Texture Type               s t r  shadow
      ----------------   ---------------------      -----  ------
      1D                 TEXTURE_1D                 x - -    -
      2D                 TEXTURE_2D                 x y -    -
      3D                 TEXTURE_3D                 x y z    -
      CUBE               TEXTURE_CUBE_MAP           x y z    -
      RECT               TEXTURE_RECTANGLE_ARB      x y -    -
      SHADOW1D           TEXTURE_1D                 x - -    z
      SHADOW2D           TEXTURE_2D                 x y -    z
      SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    z

      Table X.17:  Texture types accessed for each of the <texTarget>, and
      coordinate mappings.  The "SHADOW" targets are special
      pseudo-targets described below.  The "coordinates used" column indicate
      the input values used for each coordinate of the texture lookup
      and the reference value for texture comparisons.

    Texture targets with "SHADOW" are used to access textures with a
    DEPTH_COMPONENT base internal format using depth comparisons (Section
    3.8.14).  Results of a texture access are undefined:

      * if a "SHADOW" target is used, and the corresponding texture has a base
        internal format other than DEPTH_COMPONENT or a TEXTURE_COMPARE_MODE
        of NONE, or

      * if a non-"SHADOW" target is used, and the corresponding texture has a
        base internal format of DEPTH_COMPONENT and a TEXTURE_COMPARE_MODE
        other than NONE.

    If the texture being accessed is not complete (or cube complete for
    cubemap textures), no texture access is performed and the result will
    be the vector (R, G, B, A) = (0, 0, 0, 1).

    A program will fail to load if it attempts to sample from multiple texture
    targets (including the SHADOW pseudo-targets) on the same texture image
    unit.  For example, a program containing any two the following
    instructions will fail to load:

      TEX out, coord, texture[0], 1D;
      TEX out, coord, texture[0], 2D;
      TEX out, coord, texture[0], ARRAY2D;
      TEX out, coord, texture[0], SHADOW2D;
      TEX out, coord, texture[0], 3D;

    Additionally, multiple texture targets for a single texture image unit may
    not be used at the same time by the GL.  The error INVALID_OPERATION is
    generated by Begin, RasterPos, or any command that performs an implicit
    Begin if an enabled program accesses one texture target for a texture unit
    while another enabled program or fixed-function fragment processing
    accesses a different texture target for the same texture image unit.

    Some texture instructions use standard methods to compute partial
    derivatives and/or the level-of-detail used to perform texture accesses.
    For fragment programs, the functions

      float_vec ComputePartialsX(float_vec coord);
      float_vec ComputePartialsY(float_vec coord);

    compute approximate component-wise partial derivatives of the
    floating-point vector <coord> relative to the X and Y coordinates,
    respectively.  For vertex programs, these functions always
    return (0,0,0,0).  The function

      float ComputeLOD(float_vec ddx, float_vec ddy);

    maps partial derivative vectors <ddx> and <ddy> to ds/dx, dt/dx, dr/dx,
    ds/dy, dt/dy, and dr/dy and computes lambda_base(x,y) according to
    equation 3.18.


    Section 2.X.5, Program Flow Control

    In addition to basic arithmetic, logical, and texture instructions, a
    number of flow control instructions are provided, which are described in
    detail in Section 2.X.8.  Programs can contain several types of
    instruction blocks:  IF/ELSE/ENDIF blocks, REP/ENDREP blocks, and
    subroutine blocks.  IF/ELSE/ENDIF blocks are a set of instructions
    beginning with an "IF" instruction, ending with an "ENDIF" instruction,
    and possibly containing an optional "ELSE" instruction.  REP/ENDREP blocks
    are a set of instructions beginning with a "REP" instruction and ending
    with an "ENDREP" instruction.  Subroutine blocks begin with an instruction
    label identifying the name of the subroutine and ending just before the
    next instruction label or the end of the program.  Examples include the
    following:

        PSGT P0, R0, {0.0}.xxxx;
        IF P0;
          MOV R0, R1;     # executes if R0.x > 0
        ELSE;
          MOV R0, R2;     # executes if R0.x <= 0
        ENDIF;

        REP repCount;
        ADD R0, R0, R1;
        ENDREP;

      square:             # subroutine to compute R0^2
        MUL R0, R0, R0;
        RET;
      main:
        MOV R0, 9.0;
        CAL square;       # compute 9.0^2 in R0

    IF/ELSE/ENDIF, REP/ENDREP, and LOOP/ENDLOOP blocks may be nested inside each other, and
    inside subroutines.  In all cases, each instruction block must be
    terminated with the appropriate instruction (ENDIF for IF, ENDREP for
    REP, ENDLOOP for LOOP).  Nested instruction blocks must be wholly contained within a block
    -- if a REP instruction is found between an IF and ELSE instruction, the
    corresponding ENDREP must also be present between the IF and ELSE.
    Subroutines may not be nested inside IF/ELSE/ENDIF or REP/ENDREP blocks,
    or inside other subroutines.  A program will fail to load if any
    instruction block is terminated by an incorrect instruction, is not
    terminated before the block containing it, or contains an instruction
    label.

    IF/ELSE/ENDIF blocks evaluate a condition to determine which instructions
    to execute.  If the condition is true, all instructions between the IF and
    ELSE are executed.  If the condition is false, all instructions between
    the ELSE and ENDIF are executed.  The ELSE instruction is optional.  If
    the ELSE is omitted, all instructions between the IF and ENDIF are
    executed if the condition is true, or skipped if the condition is false.
    A limited amount of nesting is supported -- a program will fail to load if
    an IF instruction is nested inside MAX_PROGRAM_IF_DEPTH_MESA or more
    IF/ELSE/ENDIF blocks.

    REP/ENDREP and LOOP/ENDLOOP blocks are used to execute a sequence of instructions multiple
    times.  The REP instruction includes a scalar operand to specify
    a loop count indicating the number of times the block of instructions
    should be repeated.  The LOOP instruction includes an address register
    destination and a vector containing the initial values for the loop count,
    loop index, and loop index increment.  A limited amount of nesting is supported -- a
    program will fail to load if a REP or LOOP instruction is nested inside
    MAX_PROGRAM_LOOP_DEPTH_MESA or more REP/ENDREP or LOOP/ENDLOOP blocks.

    Within a REP/ENDREP or LOOP/ENDLOOP block, the BRK instruction can be used to terminate the entire loop
    by effectively jumping to the instruction immediately following the ENDREP or ENDLOOP
    instruction.  If BRK instructions are found inside multiply
    nested REP/ENDREP or LOOP/ENDLOOP blocks, they apply to the innermost block.  A program
    will fail to load if it includes a BRK instruction that is not
    contained inside a REP/ENDREP or LOOP/ENDLOOP block.

    Subroutines are supported via the CAL and RET instructions.  A subroutine
    block is identified by an instruction, which can be any valid identifier
    according to the <instLabel> grammar rule.  The CAL instruction identifies
    a subroutine name to call according to the <instTarget> grammar rule.
    Instruction labels used in CAL instructions do not need to be defined in
    the program text that precedes the instruction, but a program will fail to
    load if it includes a CAL instruction that references an instruction label
    that is not defined anywhere in the program.  When a CAL instruction is
    executed, it transfers control to the instruction immediately following
    the specified instruction label.  Subsequent instructions in that
    subroutine are executed until a RET instruction is executed, or until
    program execution reaches another instruction label or the end of the
    program text.  After the subroutine finishes, execution continues with the
    instruction immediately following the CAL instruction.  When a RET
    instruction is issued, it will break out of any IF/ELSE/ENDIF,
    REP/ENDREP, or LOOP/ENDLOOP blocks that contain it.

    Subroutines may call other subroutines before completing, up to an
    implementation-dependent maximum depth of MAX_PROGRAM_CALL_DEPTH_MESA calls.
    Subroutines may call any subroutine in the program, including themselves,
    as long as the call depth limit is obeyed.  The results of issuing a CAL
    instruction while MAX_PROGRAM_CALL_DEPTH_MESA subroutines have not completed
    has undefined results, including possible program termination.

    Several flow control instructions include predicate tests.  The IF
    instruction requires a predicate to determine what instructions are
    executed.  The BRK, CAL, and RET instructions have an optional
    predicate test; if the test fails, the instructions are not executed.
    Predicate tests are specified by the <predicate> grammar rule.  The test
    is evaluated like the conditional write (section 2.X.4.3), and
    passes if and only if any of the four components passes.

    If an instruction label named "main" is specified, GPU program execution
    begins with the instruction immediately following that label.  Otherwise,
    it begins with the first instruction of the program.  Instructions are
    executed in sequence until either a RET instruction is issued in the main
    subroutine or the end of the program text is reached.


    Section 2.X.6, Program Options

    Programs may specify a number of options to indicate that one or more
    extended language features are used by the program.  All program options
    used by the program must be declared at the beginning of the program
    string.  Each program option specified in a program string will modify the
    syntactic or semantic rules used to interpret the program and the execution
    environment used to execute the program.  Features in program options
    not declared by the program are ignored, even if the option is otherwise
    supported by the GL.  Each option declaration consists of two tokens: the
    keyword "OPTION" and an identifier.

    The set of available options depends on the program type, and is
    enumerated in the specifications for each program type.  Some program
    types may not provide any options.

    Section 2.X.6.Y, Vertex Program Options

    + Position-Invariant Vertex Programs (ARB_position_invariant)

    If a vertex program specifies the "ARB_position_invariant" option, the
    program is used to generate all transformed vertex attributes except for
    position.  Instead, clip coordinates are computed as specified in section
    2.10.  Additionally, user clipping is performed as described in section
    2.11.  Use of position-invariant vertex programs should generally
    guarantee that the transformed position of a vertex should be the same
    whether vertex program mode is enabled or disabled, allowing for correct
    mixed multi-pass rendering semantics.

    When the position-invariant option is specified in a vertex program,
    vertex programs can no longer declare (explicitly or implicitly) a result
    variable bound to "result.position".  A semantic restriction is added to
    indicate that a vertex program will fail to load if the number of
    instructions it contains exceeds the implementation-dependent limit minus
    four.

    Section 2.X.6.Y, Fragment Program Options

    + Fixed-Function Fog Emulation (ARB_fog_exp, ARB_fog_exp2, ARB_fog_linear)

    If a fragment program specifies one of the options "ARB_fog_exp",
    "ARB_fog_exp2", or "ARB_fog_linear", the program will apply fog to the
    program's final color using a fog mode of EXP, EXP2, or LINEAR,
    respectively, as described in section 3.10.

    When a fog option is specified in a fragment program, semantic
    restrictions are added to indicate that a fragment program will fail to
    load if the number of temporaries it contains exceeds the
    implementation-dependent limit minus 1, if the number of attributes it
    contains exceeds the implementation-dependent limit minus 1, or if the
    number of parameters it contains exceeds the implementation-dependent
    limit minus 2.

    Additionally, when the ARB_fog_exp option is specified in a fragment
    program, a semantic restriction is added to indicate that a fragment
    program will fail to load if the number of instructions or ALU
    instructions it contains exceeds the implementation-dependent limit minus
    3.  When the ARB_fog_exp2 option is specified in a fragment program, a
    semantic restriction is added to indicate that a fragment program will
    fail to load if the number of instructions or ALU instructions it contains
    exceeds the implementation-dependent limit minus 4.  When the
    ARB_fog_linear option is specified in a fragment program, a semantic
    restriction is added to indicate that a fragment program will fail to load
    if the number of instructions or ALU instructions it contains exceeds the
    implementation-dependent limit minus 2.

    Only one fog application option may be specified by any given fragment
    program.  A fragment program that specifies more than one of the program
    options "ARB_fog_exp", "ARB_fog_exp2", and "ARB_fog_linear", will fail to
    load.

    + Precision Hints (ARB_precision_hint_fastest, ARB_precision_hint_nicest)

    Fragment program computations are carried out at an implementation-
    dependent precision.  However, some implementations may be able to perform
    fragment program computations at more than one precision, and may be able
    to trade off computation precision for performance.

    If a fragment program specifies the "ARB_precision_hint_fastest" program
    option, implementations should select precision to minimize program
    execution time, with possibly reduced precision.  If a fragment program
    specifies the "ARB_precision_hint_nicest" program option, implementations
    should maximize the precision, with possibly increased execution time.

    Only one precision control option may be specified by any given fragment
    program.  A fragment program that specifies both the
    "ARB_precision_hint_fastest" and "ARB_precision_hint_nicest" program
    options will fail to load.

    + Multiple Color Outputs (ARB_draw_buffers, ATI_draw_buffers)

    If a fragment program specifies the "ARB_draw_buffers" or
    "ATI_draw_buffers" option, it will generate multiple output colors, and
    the result binding "result.color[n]" is allowed, as described in section
    2.X.3.5.  If this option is not specified, a fragment program that
    attempts to bind "result.color[n]" will fail to load, and only
    "result.color" will be allowed.

    The multiple color outputs will typically be written to an ordered list of
    draw buffers in the manner described in the ARB_draw_buffers extension
    specification.

    + Fragment Program Shadows (ARB_fragment_program_shadow)

    If a fragment program specifies the "ARB_fragment_program_shadow"
    program option, the <texTarget> rule is modified to add the
    texture targets SHADOW1D, SHADOW2D and SHADOWRECT (See Section 2.X.2).


    Section 2.X.8, Program Instruction Set

    The following sections enumerate the set of instructions supported for GPU
    programs.  

    Each section contains pseudocode describing the
    instruction.  Instructions will have up to three operands, referred to as
    "op0", "op1", and "op2".  The operands are loaded using the mechanisms
    specified in section 2.14.4.1.  The variables "tmp", "tmp0", "tmp1", and
    "tmp2" describe scalars or vectors used to hold intermediate results in
    the instruction.  Most instructions will generate a result vector called
    "result".  The result vector is then written to the destination register
    specified in the instruction as described in section 2.14.4.3.


    Section 2.X.8.Z, ABS:  Absolute Value

    The ABS instruction performs a component-wise absolute value operation on
    the single operand to yield a result vector.

      tmp = VectorLoad(op0); 
      result.x = abs(tmp.x);
      result.y = abs(tmp.y);
      result.z = abs(tmp.z);
      result.w = abs(tmp.w);


    Section 2.X.8.Z, ADD:  Add

    The ADD instruction performs a component-wise add of the two operands to
    yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = tmp0.x + tmp1.x;
      result.y = tmp0.y + tmp1.y;
      result.z = tmp0.z + tmp1.z;
      result.w = tmp0.w + tmp1.w;

    The following rules apply to addition:

      1. <x> + <y> == <y> + <x>, for all <x> and <y>.
      2. <x> + 0.0 == <x>, for all <x>.


    Section 2.X.8.Z, ARL:  Address Register Load

    The ARL instruction loads a single vector operand and performs a
    component-wise floor operation to generate a signed integer result
    vector.

      tmp = VectorLoad(op0);
      result.x = floor(tmp.x);
      result.y = floor(tmp.y);
      result.z = floor(tmp.z);
      result.w = floor(tmp.w);

    The floor operation returns the largest integer less than or equal
    to the operand.  For example floor(-1.7) = -2.0, floor(+1.0) = +1.0,
    and floor(+3.7) = +3.0.


    Section 2.X.8.Z,  ARR:  Address Register Load (with rounding)

    The ARR instruction loads a single vector operand and performs a
    component-wise round operation to generate a signed integer result
    vector.

      tmp = VectorLoad(op0);
      result.x = round(tmp.x);
      result.y = round(tmp.y);
      result.z = round(tmp.z);
      result.w = round(tmp.w);

    The round operation returns the nearest integer to the operand.  If the
    fractional portion of the operand is 0.5, round() selects the nearest even
    integer.  For example round(-1.7) = -2.0, round(+1.0) = +1.0, and
    round(+3.7) = +4.0.


    Section 2.X.8.Z, BRK:  Break out of Loop Instruction

    The BRK instruction conditionally transfers control to the instruction
    immediately following the next ENDLOOP or ENDREP instruction.  A BRK instruction has
    no effect if the condition code test evaluates to FALSE.

    The following pseudocode describes the operation of the instruction:

      if (predicate.c*** || predicate.*c** ||
          predicate.**c* || predicate.***c) {
        continue execution at instruction following the next ENDLOOP or
          ENDREP;
      }


    Section 2.X.8.Z, CAL:  Subroutine Call

    The CAL instruction conditionally transfers control to the instruction
    following the label specified in the instruction.  It also pushes a
    reference to the instruction immediately following the CAL instruction
    onto the call stack, where execution will continue after executing the
    matching RET instruction.  The following pseudocode describes the
    operation of the instruction:

      if (predicate.c*** || predicate.*c** ||
          predicate.**c* || predicate.***c) {
        if (callStackDepth >= MAX_PROGRAM_CALL_DEPTH_MESA) {
          // undefined results
        } else {
          callStack[callStackDepth] = nextInstruction;
          callStackDepth++;
        }
        // continue execution at instruction following <instTarget>
      } else {
        // do nothing
      }

    In the pseudocode, <instTarget> is the label specified in the instruction
    matching the <branchLabel> grammar rule, <callStackDepth> is the current
    depth of the call stack, <callStack> is an array holding the call stack,
    and <nextInstruction> is a reference to the instruction immediately
    following the CAL instruction in the program string.

    If the call stack overflows, the results of the CAL instruction are
    undefined, and can result in immediate program termination.

    An instruction label signifies the beginning of a new subroutine.
    Subroutines may not nest or overlap.  If a CAL instruction is executed and
    subsequent program execution reaches an instruction label before a
    corresponding RET instruction is executed, the subroutine call returns
    immediately, as though an unconditional RET instruction were inserted
    immediately before the instruction label.


    Section 2.X.8.Z, CMP:  Compare

    The CMP instructions performs a component-wise comparison of the first
    operand against zero, and copies the values of the second or third
    operands based on the results of the compare.
    
      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      tmp2 = VectorLoad(op2);
      result.x = (tmp0.x < 0) ? tmp1.x : tmp2.x;
      result.y = (tmp0.y < 0) ? tmp1.y : tmp2.y;
      result.z = (tmp0.z < 0) ? tmp1.z : tmp2.z;
      result.w = (tmp0.w < 0) ? tmp1.w : tmp2.w;


    Section 2.X.8.Z, COS:  Cosine with Reduction to [-PI,PI]

    The COS instruction approximates the trigonometric cosine of the angle
    specified by the scalar operand and replicates it to all four components
    of the result vector.  The angle is specified in radians and does not have
    to be in the range [-PI,PI].

      tmp = ScalarLoad(op0);
      result.x = ApproxCosine(tmp);
      result.y = ApproxCosine(tmp);
      result.z = ApproxCosine(tmp);
      result.w = ApproxCosine(tmp);


    Section 2.X.8.Z, DDX:  Partial Derivative Relative to X

    The DDX instruction computes approximate partial derivatives of the four
    components of the single floating-point vector operand with respect to the
    X window coordinate to yield a result vector.  The partial derivatives are
    evaluated at the sample location of the pixel.

      f = VectorLoad(op0);
      result = ComputePartialX(f);

    Note that the partial derivatives obtained by this instruction are
    approximate, and derivative-of-derivative instruction sequences may not
    yield accurate second derivatives.  Note also that the sample locations
    for attributes declared with the CENTROID interpolation modifier may not
    be evenly spaced, which can lead to artifacts in derivative calculations.

    This instruction is only available in fragment programs.


    Section 2.X.8.Z, DDY:  Partial Derivative Relative to Y

    The DDY instruction computes approximate partial derivatives of the four
    components of the single operand with respect to the Y window coordinate
    to yield a result vector.  The partial derivatives are evaluated at the
    center of the pixel.

      f = VectorLoad(op0);
      result = ComputePartialY(f);

    Note that the partial derivatives obtained by this instruction are
    approximate, and derivative-of-derivative instruction sequences may not
    yield accurate second derivatives.  Note also that the sample locations
    for attributes declared with the CENTROID interpolation modifier may not
    be evenly spaced, which can lead to artifacts in derivative calculations.

    This instruction is only available in fragment programs.


    Section 2.X.8.Z, DP2:  2-Component Dot Product

    The DP2 instruction computes a two-component dot product of the two
    operands (using the first two components) and replicates the dot product
    to all four components of the result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y);
      result.x = dot;
      result.y = dot;
      result.z = dot;
      result.w = dot;


    Section 2.X.8.Z, DP2A:  2-Component Dot Product with Scalar Add

    The DP2 instruction computes a two-component dot product of the two
    operands (using the first two components), adds the x component of the
    third operand, and replicates the result to all four components of the
    result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      tmp2 = VectorLoad(op2);
      dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + tmp2.x;
      result.x = dot;
      result.y = dot;
      result.z = dot;
      result.w = dot;


    Section 2.X.8.Z, DP3:  3-Component Dot Product

    The DP3 instruction computes a three-component dot product of the two
    operands (using the x, y, and z components) and replicates the dot product
    to all four components of the result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + 
            (tmp0.z * tmp1.z);
      result.x = dot;
      result.y = dot;
      result.z = dot;
      result.w = dot;


    Section 2.X.8.Z, DP4:  4-Component Dot Product

    The DP4 instruction computes a four-component dot product of the two
    operands and replicates the dot product to all four components of the
    result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1):
      dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + 
            (tmp0.z * tmp1.z) + (tmp0.w * tmp1.w);
      result.x = dot;
      result.y = dot;
      result.z = dot;
      result.w = dot;


    Section 2.X.8.Z, DPH:  Homogeneous Dot Product

    The DPH instruction computes a three-component dot product of the two
    operands (using the x, y, and z components), adds the w component of the
    second operand, and replicates the sum to all four components of the
    result vector.  This is equivalent to a four-component dot product where
    the w component of the first operand is forced to 1.0.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1):
      dot = (tmp0.x * tmp1.x) + (tmp0.y * tmp1.y) + 
            (tmp0.z * tmp1.z) + tmp1.w;
      result.x = dot;
      result.y = dot;
      result.z = dot;
      result.w = dot;


    Section 2.X.8.Z, DST:  Distance Vector

    The DST instruction computes a distance vector from two specially-
    formatted operands.  The first operand should be of the form [NA, d^2,
    d^2, NA] and the second operand should be of the form [NA, 1/d, NA, 1/d],
    where NA values are not relevant to the calculation and d is a vector
    length.  If both vectors satisfy these conditions, the result vector will
    be of the form [1.0, d, d^2, 1/d].

    The exact behavior is specified in the following pseudo-code:

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = 1.0;
      result.y = tmp0.y * tmp1.y;
      result.z = tmp0.z;
      result.w = tmp1.w;

    Given an arbitrary vector, d^2 can be obtained using the DP3 instruction
    (using the same vector for both operands) and 1/d can be obtained from d^2
    using the RSQ instruction.

    This distance vector is useful for per-vertex light attenuation
    calculations:  a DP3 operation using the distance vector and an
    attenuation constants vector as operands will yield the attenuation
    factor.


    Section 2.X.8.Z, ELSE:  Start of If Test Else Block

    The ELSE instruction signifies the end of the "execute if true" portion of
    an IF/ELSE/ENDIF block and the beginning of the "execute if false"
    portion.

    If the condition evaluated at the IF statement was TRUE, when a program
    reaches the ELSE statement, it has completed the entire "execute if true"
    portion of the IF/ELSE/ENDIF block.  Execution will continue at the
    corresponding ENDIF instruction.

    If the condition evaluated at the IF statement was FALSE, program
    execution would skip over the entire "execute if true" portion of the
    IF/ELSE/ENDIF block, including the ELSE instruction.


    Section 2.X.8.Z, ENDIF:  End of If Test Block

    The ENDIF instruction signifies the end of an IF/ELSE/ENDIF block.  It has
    no other effect on program execution.


    Section 2.X.8.Z, ENDLOOP:  End of Loop Block

    The ENDLOOP instruction specifies the end of a LOOP block.  When an
    ENDLOOP instruction executes, the loop count is decremented and the loop
    index increment value is added to the loop index (specified in the LOOP
    instruction).  If the decremented loop count is greater than zero,
    execution continues at the top of the LOOP block.

      LoopCount--;
      LoopIndex.x += LoopIncr;
      if (LoopCount > 0) {
        continue execution at instruction following corresponding LOOP
          instruction;
      }

      if (loopStackDepth <= 0) {
        // terminate program
      } else {
        loopStackDepth--;
        LoopIndex = loopStack[loopStackDepth];
      }


    Section 2.X.8.Z, ENDREP:  End of Repeat Block

    The ENDREP instruction specifies the end of a REP block.  

    When used with in conjunction with a REP instruction with a loop count,
    ENDREP decrements the loop counter.  If the decremented loop counter is
    greater than zero, ENDREP transfers control to the instruction immediately
    after the corresponding REP instruction.  If the loop counter is less than
    or equal to zero, execution continues at the instruction following the
    ENDREP instruction.  When used in conjunction with a REP instruction
    without loop count, ENDREP always transfers control to the instruction
    immediately after the REP instruction.

      if (REP instruction includes a loop count) {
        LoopCount--;
        if (LoopCount > 0) {
          continue execution at instruction following corresponding REP
            instruction;
        }
      } else {
        continue execution at instruction following corresponding REP
          instruction;
      }


    Section 2.X.8.Z, EX2:  Exponential Base 2

    The EX2 instruction approximates 2 raised to the power of the scalar
    operand and replicates the approximation to all four components of the
    result vector.

      tmp = ScalarLoad(op0);
      result.x = Approx2ToX(tmp);
      result.y = Approx2ToX(tmp);
      result.z = Approx2ToX(tmp);
      result.w = Approx2ToX(tmp);


    Section 2.X.8.Z,  EXP:  Exponential Base 2 (approximate)

    The EXP instruction computes a rough approximation of 2 raised to the
    power of the scalar operand.  The approximation is returned in the "z"
    component of the result vector.  A vertex program can also use the "x" and
    "y" components of the result vector to generate a more accurate
    approximation by evaluating

        result.x * f(result.y),
    
    where f(x) is a user-defined function that approximates 2^x over the
    domain [0.0, 1.0).  The "w" component of the result vector is always 1.0.
    
    The exact behavior is specified in the following pseudo-code:

      tmp = ScalarLoad(op0);
      result.x = 2^floor(tmp);
      result.y = tmp - floor(tmp);
      result.z = RoughApprox2ToX(tmp);
      result.w = 1.0;

    The approximation function is accurate to at least 10 bits:

      | RoughApprox2ToX(x) - 2^x | < 1.0 / 2^11, if 0.0 <= x < 1.0,

    and, in general,
   
      | RoughApprox2ToX(x) - 2^x | < (1.0 / 2^11) * (2^floor(x)).


    Section 2.X.8.Z, FLR:  Floor

    The FLR instruction loads a single vector operand and performs a
    component-wise floor operation to generate a result vector.

      tmp = VectorLoad(op0);
      result.x = floor(tmp.x);
      result.y = floor(tmp.y);
      result.z = floor(tmp.z);
      result.w = floor(tmp.w);

    The floor operation returns the nearest integer less than or equal to the
    operand.  For example floor(-1.7) = -2.0, floor(+1.0) = +1.0, and floor(+3.7)
    = +3.0.


    Section 2.X.8.Z, FRC:  Fraction

    The FRC instruction extracts the fractional portion of each component of
    the operand to generate a result vector.  The fractional portion of a
    component is defined as the result after subtracting off the floor of the
    component (see FLR), and is always in the range [0.0, 1.0).

    For negative values, the fractional portion is NOT the number written to
    the right of the decimal point -- the fractional portion of -1.7 is not
    0.7 -- it is 0.3.  0.3 is produced by subtracting the floor of -1.7 (-2.0)
    from -1.7.

      tmp = VectorLoad(op0);
      result.x = fraction(tmp.x);
      result.y = fraction(tmp.y);
      result.z = fraction(tmp.z);
      result.w = fraction(tmp.w);


    Section 2.X.8.Z, IF:  Start of If Test Block

    The IF instruction performs a condition code test to determine what
    instructions inside an IF/ELSE/ENDIF block are executed.  If the test
    passes, execution continues at the instruction immediately following the
    IF instruction.  If the test fails, IF transfers control to the
    instruction immediately following the corresponding ELSE instruction (if
    present) or the ENDIF instruction (if no ELSE is present).

    Implementations may have a limited ability to nest IF blocks at run time.
    If the number of IF/ENDIF blocks that are currently active is
    MAX_PROGRAM_IF_DEPTH_MESA, an IF instruction may cause the fragment program
    to terminate.  If an IF instruction is executed inside a subroutine, any
    active IF/ENDIF blocks in the calling code count against this limit.

      if (IF block nested too deeply) {
        terminate fragment program;
      }

      // Evaluate the condition.  If the condition is true, continue at the
      // next instruction.  Otherwise, continue at the 
      if (predicate.c*** || predicate.*c** ||
          predicate.**c* || predicate.***c) {
        continue execution at the next instruction;
      } else if (IF block contains an ELSE statement) {
        continue execution at instruction following corresponding ELSE;
      } else {
        continue execution at instruction following corresponding ENDIF;
      }


    Section 2.X.8.Z, KIL:  Kill Fragment

    The KIL instruction evaluates a condition and kills a fragment if the test
    passes.  A fragment killed by the KIL instruction is discarded, and will
    not be seen by subsequent stages of the pipeline.

    A KIL instruction may be specified using either vector operand or a
    condition code test.

    If a vector is provided, the fragment is
    discarded if any of its components are negative:

      tmp = VectorLoad(op0);
      if ((tmp.x < 0) || (tmp.y < 0) || 
          (tmp.z < 0) || (tmp.w < 0))
      {
          exit;
      }

    If a condition code test is provided, the fragment is discarded if any
    component of the test passes:

      if (TestCC(rc.c***) || TestCC(rc.*c**) || 
          TestCC(rc.**c*) || TestCC(rc.***c)) 
      {
         exit;
      }

    KIL is available only to fragment programs.


    Section 2.X.8.Z, LG2:  Logarithm Base 2

    The LG2 instruction approximates the base 2 logarithm of the scalar
    operand and replicates it to all four components of the result vector.

      tmp = ScalarLoad(op0);
      result.x = ApproxLog2(tmp);
      result.y = ApproxLog2(tmp);
      result.z = ApproxLog2(tmp);
      result.w = ApproxLog2(tmp);

    If the scalar operand is zero or negative, the result is undefined.


    Section 2.X.8.Z, LIT:  Compute Lighting Coefficients

    The LIT instruction accelerates lighting computations by computing
    lighting coefficients for ambient, diffuse, and specular light
    contributions.  The "x" component of the single operand is assumed to hold
    a diffuse dot product (n dot VP_pli, as in the vertex lighting equations
    in Section 2.13.1).  The "y" component of the operand is assumed to hold a
    specular dot product (n dot h_i).  The "w" component of the operand is
    assumed to hold the specular exponent of the material (s_rm), and is
    clamped to the range (-128, +128) exclusive.

    The "x" component of the result vector receives the value that should be
    multiplied by the ambient light/material product (always 1.0).  The "y"
    component of the result vector receives the value that should be
    multiplied by the diffuse light/material product (n dot VP_pli).  The "z"
    component of the result vector receives the value that should be
    multiplied by the specular light/material product (f_i * (n dot h_i) ^
    s_rm).  The "w" component of the result is the constant 1.0.

    Negative diffuse and specular dot products are clamped to 0.0, as is done
    in the standard per-vertex lighting operations.  In addition, if the
    diffuse dot product is zero or negative, the specular coefficient is
    forced to zero.

      tmp = VectorLoad(op0);
      if (tmp.x < 0) tmp.x = 0;
      if (tmp.y < 0) tmp.y = 0;
      if (tmp.w < -(128.0-epsilon)) tmp.w = -(128.0-epsilon);
      else if (tmp.w > 128-epsilon) tmp.w = 128-epsilon;
      result.x = 1.0;
      result.y = tmp.x;
      result.z = (tmp.x > 0) ? RoughApproxPower(tmp.y, tmp.w) : 0.0;
      result.w = 1.0;

    The exponentiation approximation function may be defined in terms of the
    base 2 exponentiation and logarithm approximation operations in the EXP
    and LOG instructions, where

      RoughApproxPower(a,b) = RoughApproxExp2(b * RoughApproxLog2(a)).

    In particular, the approximation may not be any more accurate than the
    underlying EXP and LOG operations.

    Since 0^0 is defined to be 1, RoughApproxPower(0.0, 0.0) will produce 1.0.


    Section 2.X.8.Z, LOG:  Logarithm Base 2 (approximate)

    The LOG instruction computes a rough approximation of the base 2 logarithm
    of the absolute value of the scalar operand.  The approximation is
    returned in the "z" component of the result vector.  A vertex program can
    also use the "x" and "y" components of the result vector to generate a
    more accurate approximation by evaluating

        result.x + f(result.y),
    
    where f(x) is a user-defined function that approximates 2^x over the
    domain [1.0, 2.0).  The "w" component of the result vector is always 1.0.

    The exact behavior is specified in the following pseudo-code:

      tmp = fabs(ScalarLoad(op0));
      result.x = floor(log2(tmp));
      result.y = tmp / 2^(floor(log2(tmp)));
      result.z = RoughApproxLog2(tmp);
      result.w = 1.0;
   
    Here, "floor(log2(tmp))" refers to the floor of the exact logarithm, which
    can be easily computed for standard floating-point representations.  The
    approximation function is accurate to at least 10 bits:

      | RoughApproxLog2(x) - log_2(x) | < 1.0 / 2^11.


    Section 2.X.8.Y, LOOP:  Beginning of LOOP Block

    The LOOP instruction begins a LOOP block.  The x, y, and z components of
    the single vector operand specify the initial values for the loop count,
    loop index, and loop index increment, respectively.

    The loop count indicates the number of times the instructions between the
    LOOP and corresponding ENDLOOP instruction will be executed.  If the
    initial value of the loop count is not positive, the entire block is
    skipped and execution continues at the corresponding ENDLOOP instruction.

    The loop index can be used for indirect addressing in various program
    arrays.  A program can only use the loop index of the current LOOP block;
    loop indices for containing LOOP blocks are not available.  The loop index
    is stored in the x component of the destination address register.  The
    contents of all other components of the destination address register are
    undefined.  The x component of the destination is also updated with the
    current loop index upon execution of the matching ENDLOOP instruction.

    Implementations may have a limited ability to nest LOOP and REP blocks at
    run time.  If the number of LOOP/ENDLOOP and REP/ENDREP blocks that have
    not completed is MAX_PROGRAM_LOOP_DEPTH_MESA, a LOOP instruction will cause
    the program to terminate.  If a LOOP instruction is executed
    inside a subroutine, any active LOOP/ENDLOOP or REP/ENDREP blocks in the
    calling code count against this limit.

      if (loopStackDepth >= MAX_PROGRAM_LOOP_DEPTH_MESA) {
        // undefined results
      } else {
        loopStack[loopStackDepth] = LoopIndex;
        loopStackDepth++;
      }

      // Set up loop information for the new nesting level.
      tmp = VectorLoad(op0);
      LoopCount = floor(op0.x);
      LoopIndex.x = floor(op0.y);
      LoopIndex.y = undefined;
      LoopIndex.z = undefined;
      LoopIndex.w = undefined;
      LoopIncr  = floor(op0.z);
      if (LoopCount <= 0) {
        continue execution at the corresponding ENDLOOP;
      }

    LOOP blocks do not support fully general branching -- a program
    will fail to load if the vector operand is not a program parameter.


    Section 2.X.8.Z, LRP:  Linear Interpolation

    The LRP instruction performs a component-wise linear interpolation between
    the second and third operands using the first operand as the blend factor.
    
      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      tmp2 = VectorLoad(op2);
      result.x = tmp0.x * tmp1.x + (1 - tmp0.x) * tmp2.x;
      result.y = tmp0.y * tmp1.y + (1 - tmp0.y) * tmp2.y;
      result.z = tmp0.z * tmp1.z + (1 - tmp0.z) * tmp2.z;
      result.w = tmp0.w * tmp1.w + (1 - tmp0.w) * tmp2.w;


    Section 2.X.8.Z, MAD:  Multiply and Add

    The MAD instruction performs a component-wise multiply of the first two
    operands, and then does a component-wise add of the product to the third
    operand to yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      tmp2 = VectorLoad(op2);
      result.x = tmp0.x * tmp1.x + tmp2.x;
      result.y = tmp0.y * tmp1.y + tmp2.y;
      result.z = tmp0.z * tmp1.z + tmp2.z;
      result.w = tmp0.w * tmp1.w + tmp2.w;

    The multiplication and addition operations in this instruction are subject
    to the same rules as described for the MUL and ADD instructions.


    Section 2.X.8.Z, MAX:  Maximum

    The MAX instruction computes component-wise maximums of the values in the
    two operands to yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x > tmp1.x) ? tmp0.x : tmp1.x;
      result.y = (tmp0.y > tmp1.y) ? tmp0.y : tmp1.y;
      result.z = (tmp0.z > tmp1.z) ? tmp0.z : tmp1.z;
      result.w = (tmp0.w > tmp1.w) ? tmp0.w : tmp1.w;


    Section 2.X.8.Z, MIN:  Minimum

    The MIN instruction computes component-wise minimums of the values in the
    two operands to yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x > tmp1.x) ? tmp1.x : tmp0.x;
      result.y = (tmp0.y > tmp1.y) ? tmp1.y : tmp0.y;
      result.z = (tmp0.z > tmp1.z) ? tmp1.z : tmp0.z;
      result.w = (tmp0.w > tmp1.w) ? tmp1.w : tmp0.w;


    Section 2.X.8.Z, MOV:  Move

    The MOV instruction copies the value of the operand to yield a result
    vector.

      result = VectorLoad(op0);


    Section 2.X.8.Z, MUL:  Multiply

    The MUL instruction performs a component-wise multiply of the two operands
    to yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = tmp0.x * tmp1.x;
      result.y = tmp0.y * tmp1.y;
      result.z = tmp0.z * tmp1.z;
      result.w = tmp0.w * tmp1.w;

    The following rules apply to multiplication:

      1. <x> * <y> == <y> * <x>, for all <x> and <y>.
      2. +/-0.0 * <x> = +/-0.0, at least for all <x> that correspond to
         representable numbers (IEEE "not a number" and "infinity" encodings
         may be exceptions).
      3. +1.0 * <x> = <x>, for all <x>.

    Multiplication by zero and one should be invariant, as it may be used to
    evaluate conditional expressions without branching.


    Section 2.X.8.Z, NRM:  Normalize 3-Component Vector

    The NRM instruction normalizes the vector given by the x, y, and z
    components of the vector operand to produce the x, y, and z components of
    the result vector.  The w component of the result is undefined.

      tmp = VectorLoad(op0);
      scale = ApproxRSQ(tmp.x * tmp.x + tmp.y * tmp.y + tmp.z * tmp.z);
      result.x = tmp.x * scale;
      result.y = tmp.y * scale;
      result.z = tmp.z * scale;
      result.w = undefined;


    Section 2.X.8.Z, PSEQ:  Set Predicate on Equal

    The PSEQ instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is equal to that of the
    second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x == tmp1.x) ? 1 : 0;
      result.y = (tmp0.y == tmp1.y) ? 1 : 0;
      result.z = (tmp0.z == tmp1.z) ? 1 : 0;
      result.w = (tmp0.w == tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSFL:  Set Predicate on False

    The PSFL instruction is a degenerate case of the other predicate "Set on"
    instructions that sets all components of the result vector to a 0 value.

      result.x = 0;
      result.y = 0;
      result.z = 0;
      result.w = 0;


    Section 2.X.8.Z, PSGE:  Set Predicate on Greater Than or Equal

    The PSGE instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is greater than or equal to
    that of the second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x >= tmp1.x) ? 1 : 0;
      result.y = (tmp0.y >= tmp1.y) ? 1 : 0;
      result.z = (tmp0.z >= tmp1.z) ? 1 : 0;
      result.w = (tmp0.w >= tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSGT:  Set Predicate on Greater Than

    The PSGT instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is greater than to that of
    the second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x > tmp1.x) ? 1 : 0;
      result.y = (tmp0.y > tmp1.y) ? 1 : 0;
      result.z = (tmp0.z > tmp1.z) ? 1 : 0;
      result.w = (tmp0.w > tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSLE:  Set Predicate on Less Than or Equal

    The PSLE instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is less than or equal to that
    of the second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x <= tmp1.x) ? 1 : 0;
      result.y = (tmp0.y <= tmp1.y) ? 1 : 0;
      result.z = (tmp0.z <= tmp1.z) ? 1 : 0;
      result.w = (tmp0.w <= tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSLT:  Set Predicate on Less Than

    The PSLT instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is less than to that of
    the second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x < tmp1.x) ? 1 : 0;
      result.y = (tmp0.y < tmp1.y) ? 1 : 0;
      result.z = (tmp0.z < tmp1.z) ? 1 : 0;
      result.w = (tmp0.w < tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSNE:  Set Predicate on Not Equal

    The PSNE instruction performs a component-wise comparison of the two
    operands.  Each component of the result predicate returns a 1 value if the
    corresponding component of the first operand is not equal to that of the
    second, and a 0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x != tmp1.x) ? 1 : 0;
      result.y = (tmp0.y != tmp1.y) ? 1 : 0;
      result.z = (tmp0.z != tmp1.z) ? 1 : 0;
      result.w = (tmp0.w != tmp1.w) ? 1 : 0;


    Section 2.X.8.Z, PSTR:  Set Predicate on True

    The PSTR instruction is a degenerate case of the other predicate "Set on"
    instructions that sets all components of the result vector to a 1 value.

      result.x = 1;
      result.y = 1;
      result.z = 1;
      result.w = 1;


    Section 2.X.8.Z, POW:  Exponentiate

    The POW instruction approximates the value of the first scalar operand
    raised to the power of the second scalar operand and replicates it to all
    four components of the result vector.

      tmp0 = ScalarLoad(op0);
      tmp1 = ScalarLoad(op1);
      result.x = ApproxPower(tmp0, tmp1);
      result.y = ApproxPower(tmp0, tmp1);
      result.z = ApproxPower(tmp0, tmp1);
      result.w = ApproxPower(tmp0, tmp1);

    The exponentiation approximation function may be implemented using the
    base 2 exponentiation and logarithm approximation operations in the EX2
    and LG2 instructions.  In particular,

      ApproxPower(a,b) = ApproxExp2(b * ApproxLog2(a)).

    Note that a logarithm may be involved even for cases where the exponent is
    an integer.  This means that it may not be possible to exponentiate
    correctly with a negative base.  In contrast, it is possible in a
    "normal" mathematical formulation to raise negative numbers to integral
    powers (e.g., (-3)^2== 9, and (-0.5)^-2==4).


    Section 2.X.8.Z, RCP:  Reciprocal

    The RCP instruction approximates the reciprocal of the scalar operand and
    replicates it to all four components of the result vector.

      tmp = ScalarLoad(op0);
      result.x = ApproxReciprocal(tmp);
      result.y = ApproxReciprocal(tmp);
      result.z = ApproxReciprocal(tmp);
      result.w = ApproxReciprocal(tmp);

    The following rule applies to reciprocation:

      1. ApproxReciprocal(+1.0) = +1.0.


    Section 2.X.8.Z, REP:  Start of Repeat Block

    The REP instruction begins a REP/ENDREP block.  The x component of the single
    vector operand specifies the initial value for the loop count.  REP blocks
    are completely identical to LOOP blocks except that they don't use the
    loop index at all.

    The loop count indicates the number of times the instructions between the
    REP and corresponding ENDREP instruction will be executed.  If the initial
    value of the loop count is not positive, the entire block is skipped and
    execution continues at the instruction following the corresponding ENDREP
    instruction.

    Implementations may have a limited ability to nest LOOP and REP blocks at
    run time.  If the number of LOOP/ENDLOOP and REP/ENDREP blocks that have
    not completed is MAX_PROGRAM_LOOP_DEPTH_MESA, a REP instruction will cause
    the fragment program to terminate.  If a REP instruction is executed
    inside a subroutine, any active LOOP/ENDLOOP or REP/ENDREP blocks in the
    calling code count against this limit.

      if (REP block nested too deeply) {
        terminate fragment program;
      }

      // Set up loop information for the new nesting level.
      tmp = VectorLoad(op0);
      LoopCount = floor(op0.x);
      if (LoopCount <= 0) {
        continue execution at the corresponding ENDREP;
      }

    REP blocks do not support fully general branching -- a program
    will fail to load if the vector operand is not a program parameter.


    Section 2.X.8.Z, RET:  Subroutine Return

    The RET instruction conditionally returns from a subroutine initiated by a
    CAL instruction by popping an instruction reference off the top of the
    call stack and transferring control to the referenced instruction.  The
    following pseudocode describes the operation of the instruction:

      if (predicate.c*** || predicate.*c** ||
          predicate.**c* || predicate.***c) {
        if (callStackDepth <= 0) {
          // terminate program
        } else {
          callStackDepth--;
          instruction = callStack[callStackDepth];
        }

        // continue execution at <instruction>
      } else {
        // do nothing
      }

    In the pseudocode, <callStackDepth> is the depth of the call stack,
    <callStack> is an array holding the call stack, and <instruction> is a
    reference to an instruction previously pushed onto the call stack.

    If the call stack is empty when RET executes, the program terminates
    normally.


    Section 2.X.8.Z, ROUND:  Round to Nearest Integer

    The ROUND instruction loads a single vector operand and performs a
    component-wise round operation to generate a result vector.

      tmp = VectorLoad(op0);
      result.x = round(tmp.x);
      result.y = round(tmp.y);
      result.z = round(tmp.z);
      result.w = round(tmp.w);

    The round operation returns the nearest integer to the operand.  If the
    fractional portion of the operand is 0.5, round() selects the nearest even
    integer.  For example round(-1.7) = -2.0, round(+1.0) = +1.0, and
    round(+3.7) = +4.0.


    Section 2.X.8.Z, RSQ:  Reciprocal Square Root

    The RSQ instruction approximates the reciprocal of the square root of the
    absolute value of the scalar operand and replicates it to all four
    components of the result vector.

      tmp = fabs(ScalarLoad(op0));
      result.x = ApproxRSQRT(tmp);
      result.y = ApproxRSQRT(tmp);
      result.z = ApproxRSQRT(tmp);
      result.w = ApproxRSQRT(tmp);


    Section 2.X.8.Z, SCS:  Sine/Cosine without Reduction

    The SCS instruction approximates the trigonometric sine and cosine of the
    angle specified by the scalar operand and places the cosine in the x
    component and the sine in the y component of the result vector.  The z and
    w components of the result vector are undefined.  The angle is specified
    in radians and must be in the range [-PI,PI].

      tmp = ScalarLoad(op0);
      result.x = ApproxCosine(tmp);
      result.y = ApproxSine(tmp);
      result.z = undefined;
      result.w = undefined;

    If the scalar operand is not in the range [-PI,PI], the result vector is
    undefined.


    Section 2.X.8.Z, SEQ:  Set on Equal

    The SEQ instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector returns a 1.0 value if the
    corresponding component of the first operand is equal to that of the
    second, and a 0.0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x == tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y == tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z == tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w == tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SFL:  Set on False

    The SFL instruction is a degenerate case of the other "Set on"
    instructions that sets all components of the result vector to a 0.0
    value.

      result.x = 0.0;
      result.y = 0.0;
      result.z = 0.0;
      result.w = 0.0;


    Section 2.X.8.Z, SGE:  Set on Greater Than or Equal

    The SGE instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector is 1.0 if the corresponding
    component of the first operands is greater than or equal that of the
    second, and 0.0 otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x >= tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y >= tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z >= tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w >= tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SGT:  Set on Greater Than

    The SGT instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector is 1.0 if the corresponding
    component of the first operands is greater than that of the second, and
    0.0 otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x > tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y > tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z > tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w > tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SLE:  Set on Less Than or Equal

    The SLE instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector is 1.0 if the corresponding
    component of the first operand is less than or equal to that of the
    second, and 0.0 otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x <= tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y <= tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z <= tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w <= tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SLT:  Set on Less Than

    The SLT instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector is 1.0 if the corresponding
    component of the first operand is less than that of the second, and 0.0
    otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x < tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y < tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z < tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w < tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SNE:  Set on Not Equal

    The SNE instruction performs a component-wise comparison of the two
    operands.  Each component of the result vector returns a 1.0 value if the
    corresponding component of the first operand is not equal to that of the
    second, and a 0.0 value otherwise.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = (tmp0.x != tmp1.x) ? 1.0 : 0.0;
      result.y = (tmp0.y != tmp1.y) ? 1.0 : 0.0;
      result.z = (tmp0.z != tmp1.z) ? 1.0 : 0.0;
      result.w = (tmp0.w != tmp1.w) ? 1.0 : 0.0;


    Section 2.X.8.Z, SSG:  Set Sign

    The SSG instruction generates a result vector containing the signs of
    each component of the single vector operand.  Each component of the
    result vector is 1.0 if the corresponding component of the operand
    is greater than zero, 0.0 if the corresponding component of the
    operand is equal to zero, and -1.0 if the corresponding component
    of the operand is less than zero.

      tmp = VectorLoad(op0);
      result.x = SetSign(tmp.x);
      result.y = SetSign(tmp.y);
      result.z = SetSign(tmp.z);
      result.w = SetSign(tmp.w);


    Section 2.X.8.Z, STR:  Set on True

    The STR instruction is a degenerate case of the other "Set on"
    instructions that sets all components of the result vector to a 1.0
    value.

      result.x = 1.0;
      result.y = 1.0;
      result.z = 1.0;
      result.w = 1.0;


    Section 2.X.8.Z, SUB:  Subtract

    The SUB instruction performs a component-wise subtraction of the second
    operand from the first to yield a result vector.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = tmp0.x - tmp1.x;
      result.y = tmp0.y - tmp1.y;
      result.z = tmp0.z - tmp1.z;
      result.w = tmp0.w - tmp1.w;


    Section 2.X.8.Z, SWZ:  Extended Swizzle

    The SWZ instruction loads the single vector operand, and performs a
    swizzle operation more powerful than that provided for loading normal
    vector operands to yield an instruction vector.

    After the operand is loaded, the "x", "y", "z", and "w" components of the
    result vector are selected by the first, second, third, and fourth matches
    of the <extSwizComp> pattern in the <extendedSwizzle> rule.

    A result component can be selected from any of the four components of the
    operand or the constants 0.0 and 1.0.  The result component can also be
    optionally negated.  The following pseudocode describes the component
    selection method.  "operand" refers to the vector operand, "select" is an
    enumerant where the values ZERO, ONE, X, Y, Z, and W correspond to the
    <extSwizSel> rule matching "0", "1", "x", "y", "z", and "w", respectively.
    "negate" is TRUE if and only if the <optionalSign> rule in <extSwizComp>
    matches "-".

      float ExtSwizComponent(floatVec operand, enum select, boolean negate)
      {
          float result;
          switch (select) {
            case ZERO:  result = 0.0; break;
            case ONE:   result = 1.0; break;
            case X:     result = operand.x; break;
            case Y:     result = operand.y; break;
            case Z:     result = operand.z; break;
            case W:     result = operand.w; break;
          }
          if (negate) {
            result = -result;
          }
          return result;
      }

    The entire extended swizzle operation is then defined using the following
    pseudocode:

      tmp = VectorLoad(op0);
      result.x = ExtSwizComponent(tmp, xSelect, xNegate);
      result.y = ExtSwizComponent(tmp, ySelect, yNegate);
      result.z = ExtSwizComponent(tmp, zSelect, zNegate);
      result.w = ExtSwizComponent(tmp, wSelect, wNegate);

    "xSelect", "xNegate", "ySelect", "yNegate", "zSelect", "zNegate",
    "wSelect", and "wNegate" correspond to the "select" and "negate" values
    above for the four <extSwizComp> matches.  

    Since this instruction allows for component selection and negation for
    each individual component, the grammar does not allow the use of the
    normal swizzle and negation operations allowed for vector operands in
    other instructions.


    Section 2.X.8.Z, TEX:  Texture Sample

    The TEX instruction takes the four components of a single floating-point
    source vector and performs a filtered texture access as described in
    Section 2.X.4.4.  The returned (R,G,B,A) value is written to the
    floating-point result vector.  Partial derivatives and the level of detail
    are computed automatically.

      tmp = VectorLoad(op0);
      ddx = ComputePartialsX(tmp);
      ddy = ComputePartialsY(tmp);
      lambda = ComputeLOD(ddx, ddy);
      result = TextureSample(tmp, lambda, ddx, ddy, texelOffset);


    Section 2.X.8.Z, TXB:  Texture Sample with Bias

    The TXB instruction takes the four components of a single floating-point
    source vector and performs a filtered texture access as described in
    Section 2.X.4.4.  The returned (R,G,B,A) value is written to the
    floating-point result vector.  Partial derivatives and the level of detail
    are computed automatically, but the fourth component of the source vector
    is added to the computed LOD prior to sampling.

      tmp = VectorLoad(op0);
      ddx = ComputePartialsX(tmp);
      ddy = ComputePartialsY(tmp);
      lambda = ComputeLOD(ddx, ddy);
      result = TextureSample(tmp, lambda + tmp.w, ddx, ddy, texelOffset);


    Section 2.X.8.Z, TXD:  Texture Sample with Partials      

    The TXD instruction takes the four components of the first floating-point
    source vector and performs a filtered texture access as described in
    Section 2.X.4.4.  The returned (R,G,B,A) value is written to the
    floating-point result vector.  The partial derivatives of the texture
    coordinates with respect to X and Y are specified by the second and third
    floating-point source vectors.  The level of detail is computed
    automatically using the provided partial derivatives.

    Note that for cube map texture targets, the provided partial derivatives
    are in the coordinate system used before texture coordinates are projected
    onto the appropriate cube face.  The partial derivatives of the
    post-projection texture coordinates, which are used for level-of-detail
    and anisotropic filtering calculations, are derived from the original
    coordinates and partial derivatives in an implementation-dependent manner.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      tmp2 = VectorLoad(op2);
      lambda = ComputeLOD(tmp1, tmp2);
      result = TextureSample(tmp0, lambda, tmp1, tmp2, texelOffset);


    Section 2.X.8.Z, TXL:  Texture Sample with LOD

    The TXL instruction takes the four components of a single floating-point
    source vector and performs a filtered texture access as described in
    Section 2.X.4.4.  The returned (R,G,B,A) value is written to the
    floating-point result vector.  The level of detail is taken from the
    fourth component of the source vector.

    Partial derivatives are not computed by the TXL instruction and
    anisotropic filtering is not performed.

      tmp = VectorLoad(op0);
      ddx = (0,0,0);
      ddy = (0,0,0);
      result = TextureSample(tmp, tmp.w, ddx, ddy, texelOffset);


    Section 2.X.8.Z, TXP:  Texture Sample with Projection

    The TXP instruction divides the first three components of its single
    floating-point source vector by its fourth component, maps the results to
    s, t, and r, and performs a filtered texture access as described in
    Section 2.X.4.4.  The returned (R,G,B,A) value is written to the
    floating-point result vector.  Partial derivatives and the level of detail
    are computed automatically.

      tmp0 = VectorLoad(op0);
      tmp0.x = tmp0.x / tmp0.w;
      tmp0.y = tmp0.y / tmp0.w;
      tmp0.z = tmp0.z / tmp0.w;
      ddx = ComputePartialsX(tmp);
      ddy = ComputePartialsY(tmp);
      lambda = ComputeLOD(ddx, ddy);
      result = TextureSample(tmp, lambda, ddx, ddy, texelOffset);


    Section 2.X.8.Z, XPD:  Cross Product

    The XPD instruction computes the cross product using the first three
    components of its two vector operands to generate the x, y, and z
    components of the result vector.  The w component of the result vector is
    undefined.

      tmp0 = VectorLoad(op0);
      tmp1 = VectorLoad(op1);
      result.x = tmp0.y * tmp1.z - tmp0.z * tmp1.y;
      result.y = tmp0.z * tmp1.x - tmp0.x * tmp1.z;
      result.z = tmp0.x * tmp1.y - tmp0.y * tmp1.x;
      result.w = undefined;


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

    TBD.  Should language specific to fragment programs be moved from
    chapter 2 to chapter 3?  NV_gpu_program4 / NV_fragment_program4
    leave everything related to GPU programs in chapter 2.


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

    None.


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

    None.


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

    None.


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

    None.


Additions to the AGL/GLX/WGL Specifications

    None.


GLX Protocol

    None.


Errors

    None.


Dependencies on ARB_draw_buffers

    If ARB_draw_buffers is not supported, change the <colorNum> grammar rule
    for fragment programs to:

      <colorNum>              ::= 0

    Fragment programs that specify the MESA_gpu_program3 option need not also
    specify the ARB_draw_buffers option.  Specifying the ARB_draw_buffers
    option is not an error when the MESA_gpu_program3 option has been
    specified even if ARB_draw_buffers is not supported.

    Since Mesa enables ARB_draw_buffers in all drivers (but sets
    MAX_DRAW_BUFFERS_ARB to 1 on the vast majority), it is unlikely that an
    implementation exporting MESA_gpu_program3 but not ARB_draw_buffers will
    ever exist.


Dependencies on ARB_fragment_program_shadow

    If ARB_fragment_program_shadow is not supported, references to shadow
    comparisons and the SHADOW1D, SHADOW2D, and SHADOWRECT texture target
    identifiers should be removed.


Dependencies on ARB_texture_cube_map

    If ARB_texture_rectangle is not supported, references to cube map
    textures and the CUBE texture target identifier should be removed.


Dependencies on ARB_texture_rectangle

    If ARB_texture_rectangle is not supported, references to rectangle
    textures and the RECT and SHADOWRECT texture target identifiers should be
    removed.


Dependencies on ARB_vertex_blend and EXT_vertex_weighting

    If EXT_vertex_weighting and ARB_vertex_blend are both not supported, all
    discussions of vertex weights should be removed.  

    In particular, references to vertex weights should be removed from Table
    X.1, and the description of ArrayElement in section 2.8.  The line

      <vtxPrefix> "weight" <optArrayMemAbs>

    should be removed from the <attribBasic> grammar rule.
    "vertex.weight" and "vertex.weight[n]" should be removed from Table X.2.
    The discussion of vertex weights in section 2.14.3.1 should be removed.

    Additionally, the first line of Table X.3.8 should be modified to read:

      Binding                               Underlying State
      ------------------------------------  ---------------------------
        state.matrix.modelview              modelview matrix


New State

    None.


New Implementation Dependent State

                                                             Minimum
    Get Value                         Type  Get Command       Value   Description           Sec.   Attrib
    --------------------------------  ----  ---------------  -------  --------------------- ------ ------
    MAX_PROGRAM_EXEC_INSTRUCTIONS_MESA Z+   GetProgramivARB   65536   maximum program       2.X.5    -
                                                                      execution instruction
                                                                      count
    MAX_PROGRAM_CALL_DEPTH_MESA       Z+    GetProgramivARB     4     maximum program       2.X.5    -
                                                                      call stack depth
    MAX_PROGRAM_IF_DEPTH_MESA         Z+    GetProgramivARB     24    maximum program       2.X.5    -
                                                                      if nesting
    MAX_PROGRAM_LOOP_DEPTH_MESA       Z+    GetProgramivARB     4     maximum program       2.X.5    -
                                                                      loop nesting
    MAX_PROGRAM_LOOP_COUNT_MESA       Z+    GetProgramivARB    255    maximum program       2.X.X    -
                                                                      initial loop count
    MAX_VERTEX_TEXTURE_IMAGE_UNITS    Z+    GetIntegerv         0     Number of separate    2.15.5   -
                                                                      texture units that can
                                                                      be accessed by a vertex
                                                                      shader.
    MAX_PROGRAM_INSTRUCTIONS_ARB      Z+    GetProgramivARB    512    maximum program       6.1.12   -
                                                                      instructions
    MAX_PROGRAM_TEMPORARIES_ARB       Z+    GetProgramivARB     32    maximum program       6.1.12   -
                                                                      temporaries
    MAX_PROGRAM_PREDICATES_MESA       Z+    GetProgramivARB     1     maximum program       6.1.12   -
                                                                      predicate registers

    Table X.21:  New Implementation-Dependent Values Introduced by
    MESA_gpu_program3.


Issues

    (1) How should the extension strings be exposed to applications?
 
        RESOLVED: Copy-and-modify the extension string convention of
        NV_gpu_program4.  That extension created three specifications
        (NV_gpu_program4, NV_vertex_program4, and NV_fragment_program4) that
        were exposed using a single extension string (GL_NV_gpu_program4).
        We'll invert that method.  We'll provide one specification
        (MESA_gpu_program3) that is exposed using two extension strings
        (GL_MESA_vertex_program3 and GL_MESA_fragment_program3).
 
        NVIDIA likely chose their method because both the vertex and fragment
        functionality are always exposed together on their implementations.
        However, we expect that some hardware, particularly hardware that uses
        software vertex shaders, may expose GL_MESA_vertex_program3 but not
        expose GL_MESA_fragment_program3.
 
    (2) Is this extension backward-compatible with previous NV_vertex_program
    and NV_fragment_program extensions?  If not, what support has been
    removed?

      RESOLVED:  This extension is largely, but not completely,
      backward-compatible.  Functionality removed includes:

        - Unstructured branching:  NV_vertex_program2 included a general
          branch instruction "BRA" that could be used to jump to an arbitrary
          instruction.  The "CAL" instruction could "call" to an arbitrary
          instruction into code that was not necessarily structured as simple
          subroutine blocks.  Arbitrary unstructured branching can be
          difficult to implement efficiently on highly parallel GPU
          architectures, while basic structured branching is not nearly as
          difficult.

          This extension retains the "CAL" instruction but treats each block
          of code between instruction labels as a separate subroutine.  The
          "BRA" instruction and arbitrary branching has been removed.  The
          structured branching constructs in this extension are sufficient to
          implement almost all of the looping/branching support in high-level
          languages ("goto" being the most obvious exception).

        - Address registers:  NV_vertex_program added the notion of address
          registers, which were effectively under-powered integer temporaries.
          The set of instructions used to manipulate address registers was
          severely limited.  NV_vertex_program[23] extended the original
          scalars to vectors and added a few more instructions to manipulate
          address registers.  Specifically, NV_vertex_program2 adds the
          ability to perform rudimentary address register math with the ARA
          instruction.  This instruction is largely provided to support the
          LOOP/ENDLOOP instructions in vertex programs.  Many SM3 GPUs cannot
          support ARA as a separate instruction.  NV_vertex_program3 adds an
          address register stack that can be manipulated with the POPA and
          PUSHA instructions.  This extension keeps the vectored address
          registers of NV_vertex_program2, but it removes the ARA, POPA, and
          PUSHA instructions.

        - NV_vertex_program3 and NV_fragment_program2 provide the ability to
          do indirect addressing of inputs/outputs when using bindings in
          instructions -- for example:

            MOV R0, vertex.attrib[A0.x+2];      # vertex
            MOV result.texcoord[A0.y], R1;      # vertex
            MOV R2, fragment.texcoord[A0.x];    # fragment

          This extension provides indexing capability, but using named array
          variables instead.

            ATTRIB attribs[] = { vertex.attrib[2..5] };
            MOV R0, attribs[A0.x];
            OUTPUT outcoords[] = { result.texcoord[0..3] };
            MOV outcoords[A0.y], R1;
            ATTRIB texcoords[] = { fragment.texcoord[0..2] };
            MOV R2, texcoords[A0.x];

          This approach makes the set of attribute and result bindings more
          regular.  Additionally, it helps the assembler determine which
          vertex/fragment attributes are actually needed -- when the assembler
          sees constructs like "fragment.texcoord[A0.x]", it must treat *all*
          texture coordinates as live unless it can determine the range of
          values used for indexing.  The named array variable approach
          explicitly identifies which attributes are needed when indexing is
          used.
 
        - NV_fragment_program adds the ability to pack and unpack multiple
          integer values in a single floating-point component.  The PK2H,
          PK2US, PK4B, PK4UB, UP2H, UP2US, UP4B, and UP4UB instructions are
          not supported by this extension.
 
            - DIV instruction
            - RCC instruction
            - RFL instruction
            - X2D instruction
 
        - NV_vertex_program2 adds support for user defined clip distances
          calculated in vertex programs (vertex program result.clip[]).  This
          feature is supported by OpenGL starting with GLSL 1.30, but it is
          not supported by this extension.
 
        - NV_fragment_program supports multiple precisions (single and half)
          for storage and for calculations.  These are accessed using
          precision qualifiers on variables declarations and precision
          specifiers on instructions.
 
      Functionality altered includes:
 
         - NV_fragment_program2 LOOP construct:  NV_fragment_program2 added a
          LOOP instruction, which let you repeat a block of code <N> times,
          with a parallel loop counter that started at <A> and stepped by <B>
          on each iteration.  This extension adds a very similar mechanism.
          However, in NV_fragment_program2 the LOOP instruction operated on an
          implicit, predefined register named A0.  In this extension an
          address register defined using <ADDRESS_statement> can be used.
          Some additional restrictions exist and are documented in the
          extension body.
 
           - Vertex texturing is optional.  Implementations that do not support
             vertex texturing will set MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB to 0.
 
            - Conditional write masking is replaced with a slightly less
              general predication mechanism.
 
    (3) Is it valid to specify the MESA_gpu_program3 program option along with
       one of the NVIDIA program options?
 
        RESOLVED: NO.  Specifying MESA_gpu_program3 and any of
        NV_vertex_program2, NV_vertex_program3, NV_fragment_program, or
        NV_fragment_program2 in the same program is an error.
 
    (4) Should there be any support for address register math?
 
        RESOLVED: NO.  At least one family of GPUs capable of supporting the
        rest of this extension can only implement address registers as the
        destination of "float to integer" and "float to integer with rounding"
        move instructions (i.e., ARL and ARR).
 
    (5) Should there be support for NAN testing?
 
        RESOLVED: NO.  Some SM3.0 GPUs have no representation for NANs.  Some
        that can represent NAN and Inf do not have the ability to test for
        their existence.
 
    (6) How are predicates different from condition codes?
 
        RESOLVED: NV_vertex_program introduced the notion of four-component
        condition code registers.  Components of a condition code register are
        updated based on the results written by other instructions.  Each
        component stores a value from the set { LT, GT, EQ, UN }.  Register
        writes can then be conditionalized by comparing a condition encoded in
        the instruction with the value of a swizzled condition code register.
        Each condition code register requires two bits of storage per
        component.  Each instruction requires 11 bits to encode the
        conditional write mask:
 
            - two bits to encode the comparison from { LT, GT, EQ, TR }
            - one bit to optionally complement the comparison (this allows
              { GE, LE, NE, FL } as comparisons).
            - eight bits to encode the condition code register swizzle
 
        Additionally, each instruction requires one bit to enable or disable
        updates to the condition code register.
 
        Predicate registers store a four-component boolean flag.  Components
        of a predicate register are updated by special instructions.  These
        instructions compare values stored in registers and set components of
        the predicate register based on the result of the per-component
        comparisons.  Each predicate register requires one bit of storage per
        component.  Each instruction requires 10 bits to encode the
        conditional write mask:
 
            - one bit to enable predication
            - one bit to enable complement
            - eight bits to encode the predicate register swizzle
 
        Alternately a "predicate swizzle" instruction can be used to reorder
        bits in the predicate register.  This reduces the required
        per-instruction storage to two bits.
 
        Additionally, at least three special instructions are required to set
        the predicate register for the LT, GT, and EQ conditions.
 
        The two models are roughly equivalent.  In most cases, it is trivial
        to translate one to the other.  Translating condition codes to
        predicates requires the use of a temporary register as storage for the
        condition code and the insertion of extra instructions.  Translating
        predicates to condition codes does not require additional storage, but
        it does require more careful code inspection and translation to ensure
        the condition codes are properly tracked across branches.
 
        For example, the following code may be difficult to translate from
        predicates to condition codes:
 
            PSGE	P0, R0, R1;		# Set predicate if R0 >= R1
            CALL	function_that_uses_predicate
            PSLT	P0, R0, R1;		# Set predicate if R0 < R1
            CALL	function_that_uses_predicate
 
    (7) How should predicate registers be exposed?
 
        UNRESOLVED.  One option is to provide built-in predicate names of the
        form P[0-9].  One difficulty is that some implementation have more
        predicate registers than others.  Usually either 1 or 2 registers are
        supported.  Since predicate registers are modified using specific
        instructions and are not used directly as sources (as the condition
        codes are for the KIL instruction in NV_fragment_program_option),
        there is no difficulty for parsers when P[0-9] is not marked as
        reserved words.
 
    (8) How should loop index registers be exposed?
 
        RESOLVED: As address registers.  The syntax of the LOOP instruction is
        changed from NV_fragment_program2 to take the name of an address
        register as a parameter.  This name is then used inside the body of
        the loop as an index.
 
    (9) ARB_vertex_program specifies interactions with ARB_matrix_palette.
       Should this extension also specify interactions with this defunct
       extension?
 
        UNRESOLVED.  Probably not.
 
    (10) Should hexadecimal floating-point constants be allowed?  Should they
        follow the C99 model or should they be raw IEEE 754 bit patterns?
 
        UNRESOLVED.
 
    (11) Is relative addressing of temporaries allowed?

        UNRESOLVED.  It is unclear whether the relevant hardware has this
        capability.

    (12) Should this extension add bindings to pass generic attributes between
    vertex, geometry, and fragment programs, or are texture coordinates
    sufficient?

        UNRESOLVED.  NV_gpu_program4 introduces the GLSL concept of
        generic outputs and inputs.  It also introduces GLSL rules for
        how values are packed into the available slots.

    (13) Should labels enforce function scope?
  
        UNRESOLVED.  In NV_gpu_program4 a label starts a new function scope,
        and functions cannot overlap.  In NV_vertex_program2 labels may be
        placed anywhere and do not start new functions.  The current
        description of the CAL instruction uses the NV_gpu_program4
        semantics.  This should be fine as long as we don't expect a layered
        extension to add back the unstructured branches.  This may be needed
        for applications that wish to "cross compile" D3D shaders.
 
    (14) Should the EXP and LOG instructions be included?
 
        RESOLVED: YES.  At least one GPU targeted by this extension supports
        these instructions natively.  Not supporting these instructions could
        introduce portability issues for old programs and D3D cross compilers.
 
    (15) The structured branching support in NV_fragment_program2 provides a
    BRK instruction that operates like C's "break" statement.  Should we
    provide something similar to C's "continue" statement, which skips to the
    next iteration of the loop?

        RESOLVED: NO.  At least one GPU targeted by this extension is not able
        to implement CONT in the vertex shader.
 
    (16) Can the BRK or CONT instructions break out of multiple levels of
    nested loops at once?

      RESOLVED:  No.  BRK and CONT only exit the current nesting level.  To
      break out of multiple levels of nested loops, multiple BRK/CONT
      instructions are required.

    (17) Should negative offsets be available for relative addressing?

        RESOLVED: YES.  Negative offsets are allowed for program parameters
        only.  Attribute and result arrays can only be accessed using positive
        offsets.

    (19) Should we provide a method to declare how fragment attributes are
    interpolated?  It is possible to have flat-shaded attributes,
    perspective-corrected attributes, and centroid-sampled attributes.

      RESOLVED:  Yes.  Fragment program attribute variable declarations may
      specify the "FLAT", "NOPERSPECTIVE", and "CENTROID" modifiers.  

      These modifiers are identical in functionality to GLSL's
      "centroid" (GLSL 1.20), "flat" (GLSL 1.30), and "noperspective"
      (GLSL 1.30) interpolation qualifiers.

    (34) This extension provides subroutines, but doesn't provide a stack to
    push and pop parameters.  How do we deal with this?  NV_vertex_program3
    supported PUSHA/POPA instructions to push and pop address registers.

        UNRESOLVED.

    (38) Should recursion be allowed?  If so, how is the total amount of
    recursion limited?

        RESOLVED: YES.  Programs must stay within the limits of the maximum
        call depth.  Recursion is forbidden in GLSL because on many GPUs
        function local variables are stored in hidden global variables in a
        fashion similar to FORTRAN 77.  Assembly GPU programs will likely
        operate in the same way, but shader developers may be able to find
        creative ways to work around this limitation for their particular
        algorithm.


Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  --------------------------------------------
     2    10/19/09  idr       Moved ARL_instruction grammar to vertex program
                              section.
                              Added missing documentation for all predicate
                              set-on instructions.
                              Resolved issue #14 based on feedback from
                              José Fonseca and Nicolai Hähnle.
                              Resolved issue #15 based on feedback from
                              Nicolai Hähnle.
                              Resolved issue #17.  Negative offsets are only
                              supported for program parameter arrays.
                              Finished section 2.X.5, Program Flow Control.
                              Finish documenting the LOOP instruction.
     1    10/13/09  idr       Initial version for review.