Name

    NV_fragment_program2

Name Strings

    GL_NV_fragment_program2

Contact

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

Status

    Shipping.

Version

    Last Modified:      08/04/2004
    NVIDIA Revision:    8

Number

    304


Dependencies

    ARB_fragment_program is required.
    NV_fragment_program_option is required.

Overview

    This extension, like the NV_fragment_program_option extension, provides
    additional fragment program functionality to extend the standard
    ARB_fragment_program language and execution environment.  ARB programs
    wishing to use this added functionality need only add:

        OPTION NV_fragment_program2;

    to the beginning of their fragment programs.

    New functionality provided by this extension, above and beyond that
    already provided by the NV_fragment_program_option extension, includes:


      * structured branching support, including data-dependent IF tests, loops
        supporting a fixed number of iterations, and a data-dependent loop
        exit instruction (BRK),

      * subroutine calls,

      * instructions to perform vector normalization, divide vector components
        by a scalar, and perform two-component dot products (with or without a
        scalar add),

      * an instruction to perform a texture lookup with an explicit LOD,

      * a loop index register for indirect access into the texture coordinate
        attribute array, and

      * a facing attribute that indicates whether the fragment is generated
        from a front- or back-facing primitive.


Issues

    * Should this extension expose projective forms of the LOD-modifying
      texture instructions?

        RESOLVED: No. The user can manually add a DIV instruction to achieve
        the same effect.

    * Should this extension expose precision explicitly?

        RESOLVED: Only for storage using the SHORT TEMP and LONG TEMP syntax
        (similar to NV_fragment_program_option).

    * How are resources (such as registers and condition codes) scoped?

        RESOLVED: All resources are globally scoped. This means that if, for
        instance, a subroutine modifies a condition code, that modification
        effects both the caller and the callee.

    * How is the scope determined for instructions required to be within a
      specific loop construct?

        RESOLVED: The scope is determined statically at compile time. This means
        that calling BRK and using A0 from a subroutine called within a loop is
        a compile error.


New Procedures and Functions

    None.

New Tokens

    Accepted by the <pname> parameter of GetProgramivARB:

        MAX_PROGRAM_EXEC_INSTRUCTIONS_NV                0x88F4
        MAX_PROGRAM_CALL_DEPTH_NV                       0x88F5
        MAX_PROGRAM_IF_DEPTH_NV                         0x88F6
        MAX_PROGRAM_LOOP_DEPTH_NV                       0x88F7
        MAX_PROGRAM_LOOP_COUNT_NV                       0x88F8


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

    None.

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

    Modify Section 3.11 of ARB_fragment_program (Fragment Program):

    Delete the sentence referring to the lack of branching or looping.

    Modify Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar
    and Restrictions):

    (mostly add to existing grammar rules, as extended by
    NV_fragment_program_option)
    
    <optionName>            ::= "NV_fragment_program2"

    <statement>             ::= <branchLabel> ":"

    <instruction>           ::= <FlowInstruction>

    <ALUInstruction>        ::= <VECSCAop_instruction>

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

    <VECTORop>              ::= "NRM"

    <VECSCAop_instruction>  ::= <VECSCAop> <instResult> "," <instOperandV> "," 
                                <instOperandS>

    <VECSCAop>              ::= "DIV"

    <BINop>                 ::= "DP2"

    <TRIop>                 ::= "DP2A"

    <TEXop>                 ::= "TXL"

    <BRAop_instruction>     ::= <BRAop> <branchLabel> <optBranchCond>

    <BRAop>                 ::= "CAL"

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

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

    <IFop_instruction>      ::= <IFop> <ccTest>

    <IFop>                  ::= "IF"

    <LOOPop_instruction>    ::= <LOOPop> <instOperandV>

    <LOOPop>                ::= "LOOP"
                              | "REP"

    <ENDFLOWop_instruction> ::= <ENDFLOWop>

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

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

    <branchLabel>           ::= <identifier>

    <attribFragBasic>       ::= "texcoord" "[" <arrayMemRel> "]"
                              | "facing"

    <arrayMemRel>           ::= <addrUseS> <arrayMemRelOffset>

    <arrayMemRelOffset>     ::= /* empty */
                              | "+" <addrRegPosOffset>

    <addrRegPosOffset>      ::= <integer> from 0 to 9

    <addrUseS>              ::= <addrVarName> <scalarAddrSuffix>

    <scalarAddrSuffix>      ::= "." <addrComponent>

    <addrComponent>         ::= "x"

    Note:  This extension provides a pre-defined address register (A0) that
    matches the <addrVarName> grammar rule and can be used as a loop counter
    (Section 3.11.3.Y).  It is not possible to declare additional address
    register variables.
    

    Modify Section 3.11.3.1, Fragment Attributes

    (add new bindings to binding table)

      Fragment Attribute Binding  Components  Underlying State
      --------------------------  ----------  ----------------------------
      ...
      fragment.texcoord[A0.x+n]   (s,t,r,q)   indexed texture coordinate
      fragment.facing             (f,0,0,1)   fragment facing

    If a fragment attribute binding matches "fragment.texcoord[A0.x+n]", a
    texture coordinate number <c> is computed by adding the current value of
    the "A0.x" address register (the loop index -- Section 3.11.3.Y) and <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 coordinate set <c>.  If <c>
    is negative or greater than or equal to MAX_TEXTURE_COORDS_ARB, the
    fragment attribute variable is undefined.

    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 filled with 0, 0, and 1,
    respectively.


    Add New Section 3.11.3.Y, Fragment Program Address Register (insert after
    Section 3.11.3.X, Condition Code Register)

    Fragment program address register variables are a set of four-component
    signed integer vectors where only the "x" component of the address
    registers is currently accessible.  Address registers are used as indices
    when performing relative addressing in the "fragment.texcoord" attribute
    array (section 3.11.3.1).

    Fragment program address registers can not be declared in a fragment
    program.  There is only a single built-in address register, "A0.x" (loop
    index), which is available inside LOOP/ENDLOOP blocks.  A fragment program
    that accesses A0.x outside a LOOP/ENDLOOP block will fail to load.

    A0.x is initialized in by the LOOP instruction and updated by the ENDLOOP
    instruction.  When LOOP blocks are nested, each block has its own value
    for A0.x, but only the A0.x value for the innermost block can be used. The
    value of A0.x is clamped to be greater than or equal to 0.

    
    Modify Section 3.11.4, Fragment Program Execution Environment

    (modify instruction table) There are sixty-seven fragment program
    instructions....

               Modifiers
      Instr.   R H X C S  Inputs  Output   Description
      -------  - - - - -  ------  ------   --------------------------------
      ABS      X X X X X  v       v        absolute value
      ADD      X X X X X  v,v     v        add
      BRK      - - - - -  c       -        break out of loop instruction
      CAL      - - - - -  c       -        subroutine call
      CMP      - - - X X  v,v,v   v        compare
      COS      X X - X X  s       ssss     cosine with reduction to [-PI,PI]
      DDX      X X - X X  v       v        partial derivative relative to X
      DDY      X X - X X  v       v        partial derivative relative to Y
      DIV      X X - X X  v,s     v        divide vector components by scalar
      DP2      X X X X X  v,v     ssss     2-component dot product
      DP2A     X X X X X  v,v,v   ssss     2-comp. dot product w/scalar add
      DP3      X X X X X  v,v     ssss     3-component dot product
      DP4      X X X X X  v,v     ssss     4-component dot product
      DPH      X X X X X  v,v     ssss     homogeneous dot product
      DST      X X - X X  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      X X - X X  s       ssss     exponential base 2
      FLR      X X X X X  v       v        floor
      FRC      X X X X X  v       v        fraction
      IF       - - - - -  c       -        start of if test block
      KIL      - - - - -  v or c  -        kill fragment
      LG2      X X - X X  s       ssss     logarithm base 2
      LIT      X X - X X  v       v        compute light coefficients
      LOOP     - - - - -  v       -        start of loop block        
      LRP      X X X X X  v,v,v   v        linear interpolation
      MAD      X X X X X  v,v,v   v        multiply and add
      MAX      X X X X X  v,v     v        maximum
      MIN      X X X X X  v,v     v        minimum
      MOV      X X X X X  v       v        move
      MUL      X X X X X  v,v     v        multiply
      NRM      X X - X X  v       v        normalize 3-component vector
      PK2H     - - - - -  v       ssss     pack two 16-bit floats
      PK2US    - - - - -  v       ssss     pack two unsigned 16-bit scalars
      PK4B     - - - - -  v       ssss     pack four signed 8-bit scalars
      PK4UB    - - - - -  v       ssss     pack four unsigned 8-bit scalars
      POW      X X - X X  s,s     ssss     exponentiate
      RCP      X X - X X  s       ssss     reciprocal
      REP      - - - - -  v       -        start of repeat block
      RET      - - - - -  c       -        subroutine return
      RFL      X X - X X  v,v     v        reflection vector
      RSQ      X X - X X  s       ssss     reciprocal square root
      SCS      X X - X X  s       ss--     sine/cosine without reduction
      SEQ      X X X X X  v,v     v        set on equal
      SFL      X X X X X  v,v     v        set on false
      SGE      X X X X X  v,v     v        set on greater than or equal
      SGT      X X X X X  v,v     v        set on greater than
      SIN      X X - X X  s       ssss     sine with reduction to [-PI,PI]
      SLE      X X X X X  v,v     v        set on less than or equal
      SLT      X X X X X  v,v     v        set on less than
      SNE      X X X X X  v,v     v        set on not equal
      STR      X X X X X  v,v     v        set on true
      SUB      X X X X X  v,v     v        subtract
      SWZ      X X - X X  v       v        extended swizzle
      TEX      - - - X X  v       v        texture sample
      TXB      - - - X X  v       v        texture sample with bias
      TXD      - - - X X  v,v,v   v        texture sample w/partials      
      TXL      - - - X X  v       v        texture same w/explicit LOD
      TXP      - - - X X  v       v        texture sample with projection
      UP2H     - - - X X  s       v        unpack two 16-bit floats
      UP2US    - - - X X  s       v        unpack two unsigned 16-bit scalars
      UP4B     - - - X X  s       v        unpack four signed 8-bit scalars
      UP4UB    - - - X X  s       v        unpack four unsigned 8-bit scalars
      X2D      X X - X X  v,v,v   v        2D coordinate transformation
      XPD      X X - X X  v,v     v        cross product

      Table X.5:  Summary of fragment program instructions.  The columns "R",
      "H", "X", "C", and "S" indicate whether the "R", "H", or "X" precision
      modifiers, the C condition code update modifier, and the "_SAT"/"_SSAT"
      saturation modifiers, respectively, are supported for the opcode.  In
      the input/output columns, "v" indicates a floating-point vector input or
      output, "s" indicates a floating-point scalar input, "ssss" indicates a
      scalar output replicated across a 4-component result vector, "ss--"
      indicates two scalar outputs in the first two components, and "c"
      indicates a condition code test.  Instructions describe as "texture
      sample" also specify a texture image unit identifier and a texture
      target.


    Modify Section 3.11.4.3, Fragment Program Destination Register Update

    (modify saturation discussion) If the instruction opcode has the "_SAT"
    suffix, requesting saturated result vectors, each component of the result
    vector is clamped to the range [0,1] before updating the destination
    register.  If the instruction opcode has the "_SSAT" suffix, requesting
    signed saturation, each component of the result vector is clamped to the
    range [-1,1] before updating the destination register.


    Add Section 3.11.4.X, Fragment Program Branching (before Section 3.11.4.4,
    Fragment Program Result Processing)

    Fragment programs support a limited model of branching.  Fragment programs
    can specify one of several types of instruction blocks: IF/ELSE/ENDIF
    blocks, LOOP/ENDLOOP blocks, and REP/ENDREP blocks.  Examples include the
    following:

      LOOP {5, 0, 1};     # 5 iterations with loop index at 0,1,2,3,4
      ADD R0, R0, R1;
      ENDLOOP;

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

      MOVC CC, R0;
      IF GT.x;
        MOV R0, R1;  # executes if R0.x > 0
      ELSE;
        MOV R0, R2;  # executes if R0.x <= 0
      ENDIF;

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

    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 fragment program will fail
    to load if an IF instruction is nested inside MAX_PROGRAM_IF_DEPTH_NV or
    more IF/ELSE/ENDIF blocks.

    The condition of an IF test is specified by the <ccTest> grammar rule and
    may depend on the contents of the condition code register.  Branch
    conditions are evaluated by evaluating a condition code write mask in
    exactly the same manner as done for register writes (section 2.14.2.2).
    If any of the four components of the condition code write mask are
    enabled, the branch is taken and execution continues with the instruction
    following the label specified in the instruction.  Otherwise, the
    instruction is ignored and fragment program execution continues with the
    next instruction.  In the following example code,

        MOVC CC, c[0];         # c[0]=(-2, 0, 2, NaN), CC gets (LT,EQ,GT,UN)
        CAL label1 (LT.xyzw);  # call taken
        CAL label2 (LT.wyzw);  # call not taken

    the first CAL instruction loads a condition code of (LT,EQ,GT,UN) while
    the second CAL instruction loads a condition code of (UN,EQ,GT,UN).  The
    first call will be made because the "x" component evaluates to LT; the
    second call will not be made because no component evaluates to LT.

    LOOP/ENDLOOP and REP/ENDREP blocks involve a loop counter that indicates
    the number of times the instructions between the LOOP/REP and
    ENDLOOP/ENDREP are executed.  Looping blocks have a number of significant
    limitations.  First, the loop counter can not be computed at run time; it
    must be specified as a program parameter.  Second, the number of loop
    iterations is limited to the value MAX_PROGRAM_LOOP_COUNT_NV, which must
    be at least 255.  Third, only a limited amount of nesting is supported --
    a fragment program will fail to load if a LOOP or REP instruction is
    nested inside MAX_PROGRAM_LOOP_DEPTH_NV or more LOOP/ENDLOOP or REP/ENDREP
    blocks.

    The BRK instruction is available to terminate a loop block early.  A BRK
    instruction can be conditional; the condition is evaluated in the same
    manner as the condition of an IF instruction, and the loop is terminated
    if the condition is true.  A fragment program will fail to load if it
    contains a BRK instruction that is not nested inside a LOOP/ENDLOOP or
    REP/ENDREP block.

    Fragment programs can contain one or more instruction labels, matching the
    grammar rule <branchLabel>.  An instruction label can be referred to
    explicitly in subroutine call (CAL) instructions.  Instruction labels can
    be used at any point in the body of a program, and can be used in
    instructions before being defined in the program string.  Instruction
    labels can be defined anywhere in the program, except inside an
    IF/ELSE/ENDIF, LOOP/ENDLOOP, or REP/ENDREP instruction block.  A fragment
    program will fail to load if it contains an instruction label inside an
    instruction block.

    Fragment programs can also specify subroutine calls.  When a subroutine
    call (CAL) instruction is executed, a reference to the instruction
    immediately following the CAL instruction is pushed onto the call stack.
    When a subroutine return (RET) instruction is executed, an instruction
    reference is popped off the call stack and program execution continues
    with the popped instruction.  A fragment program will terminate if a CAL
    instruction is executed with MAX_PROGRAM_CALL_DEPTH_NV entries already in
    the call stack or if a RET instruction is executed with an empty call
    stack.  Subroutine calls may be conditional; the condition is specified by
    the <optBranchCond> grammar rule and evaluated in the same way as the
    condition of the IF instruction.  If no condition is specified, it is as
    though "(TR)" were specified -- the branch is unconditional.

    If a fragment program has an instruction label "main", program execution
    begins with the instruction immediately following the instruction label.
    Otherwise, program execution begins with the first instruction of the
    program.  Instructions will be executed sequentially in the order
    specified in the program, although branch instructions will affect the
    instruction execution order, as described above.  A fragment program will
    terminate after executing a RET instruction with an empty call stack.  A
    fragment program will also terminate after executing the last instruction
    in the program, unless that instruction was a taken branch.

    A fragment program will fail to load if an instruction refers to a label
    that is not defined in the program string.

    A fragment program will terminate abnormally if a subroutine call
    instruction produces a call stack overflow.  Additionally, a fragment
    program will terminate abnormally after executing
    MAX_PROGRAM_EXEC_INSTRUCTIONS instructions to prevent hangs caused by
    infinite loops in the program.

    When a fragment program terminates, normally or abnormally, it will emit a
    fragment whose attributes are taken from the final values of the fragment
    program result variables (section 3.11.3.4).


    Add to Section 3.11.4.5 of ARB_fragment_program (Fragment Program
    Options):

    Section 3.11.4.5.3, NV_fragment_program2 Option

    If a fragment program specifies the "NV_fragment_program2" option, the
    ARB_fragment_program grammar and execution environment are extended to
    take advantage of all the features of the "NV_fragment_program" option,
    plus the following features:

      * structured branching support, including data-dependent IF tests, loops
        supporting a fixed number of iterations, and a data-dependent loop
        exit instruction (BRK),

      * subroutine calls,

      * several new instructions:

        * NRM -- vector normalization
        * DIV -- divide vector components by a scalar
        * DP2 -- two-component dot product
        * DP2A -- two-component dot product with scalar add
        * TXL -- texture lookup with explicit LOD specified
        * IF/ELSE/ENDIF -- conditional execution blocks
        * REP/ENDREP -- loop block
        * LOOP/ENDLOOP -- loop block using index register
        * BRK -- break out of loop block
        * CAL -- subroutine call
        * RET -- subroutine return

      * a loop index register inside LOOP/ENDLOOP blocks that can be used for
        indirect access into the texture coordinate attribute array, and

      * a facing attribute that indicates whether the fragment is generated
        from a front- or back-facing primitive.


    Modify Section 3.11.5,  Fragment Program ALU Instruction Set

    Section 3.11.5.48, DIV:  Divide (Vector Components by Scalar)

    The DIV instruction divides each component of the first vector operand by
    the second scalar operand to produce a 4-component result vector.

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

    This instruction may not produce results identical to a RCP/MUL
    instruction sequence.


    Section 3.11.5.49, 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 3.11.5.50, DP2A:  2-Component Dot Product w/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 3.11.5.51, NRM:  3-Component Vector Normalize

    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;

    Note that the normalization uses an approximate scale and may be carried
    at lower precision than a corresponding sequence of DP3, RSQ, and MUL
    instructions.


    Add Section 3.11.6.6, TXL: Texture Lookup with Explicit LOD

    The TXL instruction takes the x, y, and z components of the vector operand
    and maps them to s, t, and r, respectively.  These coordinates are used to
    sample from the specified texture target on the specified texture image
    unit in a manner consistent with its parameters.

    The level of detail is computed as specified in section 3.8.8, except that
    rho(x,y) is given by 2^w, where w is the w component of the vector
    operand.
    
    The resulting sample is mapped to RGBA as described in table 3.21 
    and written to the result vector.

      tmp = VectorLoad(op0);
      result = TextureSample(tmp.x, tmp.y, tmp.z, 0.0, op1, op2);


    Add Section 3.11.X, Fragment Program Flow Control Instruction Set
    (immediately after Section 3.11.6, Fragment Program Texture Instruction
    Set)

    3.11.X.1, BRK:  Break

    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 (TestCC(cc.c***) || TestCC(cc.*c**) || 
          TestCC(cc.**c*) || TestCC(cc.***c)) {
        continue execution at instruction following the next ENDLOOP or
          ENDREP;
      }


    3.11.X.2, CAL:  Subroutine Call

    The CAL instruction conditionally transfers control to the instruction
    following the label specified in the instruction.  A CAL instruction has
    no effect if the condition code test evaluates to FALSE.

    When executed, the CAL instruction pushes a reference to the instruction
    immediately following the CAL instruction onto the call stack.  When a
    matching RET instruction is executed, execution will continue at that
    instruction after executing the matching RET instruction.  
    
    Implementations may have a limited call stack.  If the number of CAL
    instructions that have been performed without returning is
    MAX_PROGRAM_CALL_DEPTH_NV, a CAL instruction will cause the call stack to
    overflow and the fragment program to terminate.

    The following pseudocode describes the operation of the instruction:

      if (TestCC(cc.c***) || TestCC(cc.*c**) || 
          TestCC(cc.**c*) || TestCC(cc.***c)) {

        // Check for call stack overflow.
        if (callStackDepth >= MAX_PROGRAM_CALL_DEPTH_NV) {
          terminate fragment program;
        }

        push instruction following the CAL instruction on the call stack;
        continue execution at instruction following <branchLabel>;
      }


    3.11.X.3, ELSE:  Beginning of ELSE Block

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

    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.


    3.11.X.4, ENDIF:  End of IF/ELSE Block

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


    3.11.X.5, 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 (A0.x).  If the
    decremented loop count is greater than zero, execution continues at the
    top of the LOOP block.

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

    3.11.X.6, ENDREP:  End of REP Block

    The ENDREP instruction specifies the end of a REP block.  When an ENDREP
    instruction executes, the loop count is decremented.  If the decremented
    loop count is greater than zero, execution continues at the top of the REP
    block.

      LoopCount--;
      if (LoopCount > 0) {
        continue execution at instruction following corresponding LOOP
          instruction;
      }


    3.11.X.7, IF:  Beginning of IF Block

    The IF instruction conditionally transfers control to the instruction
    immediately following the corresponding ELSE instruction (if present) or
    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_NV, an IF instruction will 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 (TestCC(cc.c***) || TestCC(cc.*c**) || 
          TestCC(cc.**c*) || TestCC(cc.***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;
      }


    3.11.X.8, 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 (A0.x) can be used for indirect addressing in the set of
    texture coordinate fragment attributes.  A fragment program can only use
    the loop index of the current LOOP block; loop indices for containing LOOP
    blocks are not available.

    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_NV, a LOOP instruction will cause
    the fragment 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 (LOOP block nested too deeply) {
        terminate fragment program;
      }

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

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


    3.11.X.9, REP:  Beginning of REP Block

    The REP instruction begins a REP 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_NV, 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 fragment program
    will fail to load if the vector operand is not a program parameter.


    3.11.X.10, RET:  Subroutine Return

    The RET instruction conditionally returns from a subroutine initiated by a
    CAL instruction.  A RET instruction has no effect if the condition code
    test evaluates to FALSE.

    When executed, the RET instruction pops a reference to the instruction
    immediately following the corresponding CAL instruction onto the call
    stack and continues execution at that instruction.

    If a RET instruction is issued when the call stack is empty, the fragment
    program is terminated.

      if (TestCC(cc.c***) || TestCC(cc.*c**) || 
          TestCC(cc.**c*) || TestCC(cc.***c)) {

        if (callStackDepth <= 0) {
          terminate fragment program;
        }
        
        pop instruction following the CAL instruction off the call stack;
        continue execution at that instruction;
      }


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

    None.

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

    None.

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

    None.

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

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

Dependencies on ARB_fragment_program

    ARB_fragment_program is required.

    This specification and NV_fragment_program_option are based on a modified
    version of the grammar published in the ARB_fragment_program
    specification.  This modified grammar includes a few structural changes to
    better accommodate new functionality from this and other extensions, but
    should be functionally equivalent to the ARB_fragment_program grammar.
    See NV_fragment_program_option for details on the base grammar.

Dependencies on NV_fragment_program2_option

    NV_fragment_program_option is required.

    If the NV_fragment_program2 program option is specified, all the
    functionality described in both this extension and the
    NV_fragment_program_option specification is available.

GLX Protocol

    None.

Errors

    None.

New State

    None.

New Implementation Dependent State
                                                                  Min
    Get Value                            Type    Get Command      Value   Description         Sec       Attrib
    -----------------------------------  ----    ---------------  ------  -----------------   --------  ------
    MAX_PROGRAM_EXEC_INSTRUCTIONS_NV     Z+      GetProgramivARB  65536   maximum program     3.11.4.X  -
                                                                          execution inst-
                                                                          ruction count
    MAX_PROGRAM_CALL_DEPTH_NV            Z+      GetProgramivARB  4       maximum program     3.11.4.X  -
                                                                          call stack depth
    MAX_PROGRAM_IF_DEPTH_NV              Z+      GetProgramivARB  48      maximum program     3.11.4.X  -
                                                                          if nesting
    MAX_PROGRAM_LOOP_DEPTH_NV            Z+      GetProgramivARB  4       maximum program     3.11.4.X  -
                                                                          loop nesting
    MAX_PROGRAM_LOOP_COUNT_NV            Z+      GetProgramivARB  255     maximum program     3.11.4.X  -
                                                                          initial loop count

    (add to Table X.10.  New Implementation-Dependent Values Introduced by
     ARB_fragment_program.  Values queried by GetProgramivARB require a <pname>
     of FRAGMENT_PROGRAM_ARB.)

Revision History

    Rev.  Date      Author   Changes
    ----  --------  -------  --------------------------------------------
    8     08/04/04  pbrown   Fixed two typos in the TXL instruction.

    7     07/08/04  pbrown   Fixed entries for KIL and RFL in the opcode
                             table.

    6     05/16/04  pbrown   Documented that "A0" is a pre-defined address
                             register variable for the purposes of the 
                             grammar, and that no other address register
                             variables can be declared. 

    5     --------  pbrown   Internal pre-release revisions.