Name

    NV_vertex_program3

Name Strings

    GL_NV_vertex_program3

Contact

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

Status

    Shipping.

Version

    Last Modified Data:         10/12/2009
    NVIDIA Revision:            7

Number

    306

Dependencies

    ARB_vertex_program is required.
    NV_vertex_program2_option is required.
    This extension interacts with ARB_fragment_program_shadow.

Overview

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

        OPTION NV_vertex_program3;

    to the beginning of their vertex programs.

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

        * texture lookups in vertex programs,

        * ability to push and pop address registers on the stack,

        * address register-relative addressing for vertex attribute and
          result arrays, and

        * a second four-component condition code.

Issues

    Should we provided a separate "!!VP3.0" program type, like the
    "!!VP2.0" type defined in NV_vertex_program2?

      RESOLVED:  No.  Since ARB_vertex_program has been fully defined
      (it wasn't in the !!VP2.0 time-frame), we will simply define
      language extensions to !!ARBvp1.0 that expose new functionality.
      The NV_vertex_program2_option specification followed this same
      pattern for the NV3X family (GeForce FX, Quadro FX).

    Should this be called "NV_vertex_program3_option"?

      RESOLVED:  No.  The similar extension to !!ARBvp1.0 called
      "NV_vertex_program2_option" got that name only because the simpler
      "NV_vertex_program2" name had already been used.

    Is there a limit on the number of texture units that can be accessed
    by a vertex program?

      RESOLVED:  Yes.  The limit may be lower than the total number of texture
      image units available and is given by the implementation-dependent
      constant MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB.  Any program that attempts
      to use more unique texture image units will fail to load.  Programs can
      use any texture image unit number, as long as they don't use too many
      simultaneously.  As an example, the GeForce 6 series of GPUs provides 16
      texture image units accessible to vertex programs, but no more than four
      can be used simultaneously.  It is not an error to use texture image
      units 12-15 in a program.

      This limitation is identical to the one in the ARB_vertex_shader
      extensions -- both extensions use the same enum to query the number of
      available image units.  Violating this limit in GLSL results in a link
      error.

    Is there a restriction on the texture targets that can be accessed by a
    vertex program?

      RESOLVED:  Yes -- for any texture image unit, vertex and fragment
      processing can not use different targets.  If they do, an
      INVALID_OPERATION is generated at Begin-time.  This resolution is
      consistent with resultion of the same issue in the ARB_vertex_shader
      extension and OpenGL 2.0.

    Since vertices don't have screen space partial derivatives, how is
    the LOD used for texture accesses defined?

      RESOLVED:  The TXL instruction allows a program to explicitly
      set an LOD; the LOD for all other texture instructions is zero.
      The texture LOD bias specified in the texture object and environment
      do apply to all vertex texture lookups.


New Procedures and Functions

    None.

New Tokens

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
    GetFloatv, and GetDoublev:

        MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB              0x8B4C

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

    Modify Section 2.14.2, Vertex Program Grammar and Restrictions

    (mostly add to existing grammar rules, as extended by
    NV_vertex_program2_option)

    <optionName>            ::= "NV_vertex_program3"

    <instruction>           ::= <TexInstruction>

    <ALUInstruction>        ::= <ASTACKop_instruction>

    <TexInstruction>        ::= <TEXop_instruction>

    <ASTACKop_instruction>  ::= <PUSHAop> <instOperandAddrVNS>
                              | <POPAop> <instResultAddr>

    <PUSHAop>               ::= "PUSHA"

    <POPAop>                ::= "POPA"

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

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

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

    <texImageUnit>          ::= "texture" <optTexImageUnitNum>

    <optTexImageUnitNum>    ::= /* empty */
                              | "[" <texImageUnitNum> "]"

    <texImageUnitNum>       ::= <integer> 
                                /*[0,MAX_TEXTURE_IMAGE_UNITS_ARB-1]*/

    <texTargetType>         ::= "1D"
                              | "2D"
                              | "3D"
                              | "CUBE"
                              | "RECT"

    <attribVtxBasic>        ::= "texcoord" "[" <arrayMemRel> "]"
                              | "attrib" "[" <arrayMemRel> "]"

    <resultVtxBasic>        ::= "texcoord" "[" <arrayMemRel> "]"

    <ccMaskRule>            ::= "EQ0"
                              | "GE0"
                              | "GT0"
                              | "LE0"
                              | "LT0"
                              | "NE0"
                              | "TR0"
                              | "FL0"
                              | "EQ1"
                              | "GE1"
                              | "GT1"
                              | "LE1"
                              | "LT1"
                              | "NE1"
                              | "TR1"
                              | "FL1"

    (modify description of reserved identifiers)
    
    ... The following strings are reserved keywords and may not be used
    as identifiers:

        ABS, ADD, ADDRESS, ALIAS, ARA, ARL, ARR, ATTRIB, BRA, CAL, COS,
        DP3, DP4, DPH, DST, END, EX2, EXP, FLR, FRC, LG2, LIT, LOG, MAD,
        MAX, MIN, MOV, MUL, OPTION, OUTPUT, PARAM, POPA, POW, PUSHA, RCC,
        RCP, RET, RSQ, SEQ, SFL, SGE, SGT, SIN, SLE, SLT, SNE, SUB, SSG,
        STR, SWZ, TEMP, TEX, TXB, TXL, TXP, XPD, program, result, state,
        and vertex.

    Modify Section 2.14.3.1, Vertex Attributes

    (add new bindings to binding table)

      Vertex Attribute Binding  Components  Underlying State
      ------------------------  ----------  --------------------------------
      ...
      vertex.texcoord[A+n]      (s,t,r,q)   indexed texture coordinate
      vertex.attrib[A+n]        (x,y,z,w)   indexed generic vertex attribute

    If a vertex attribute binding matches "vertex.texcoord[A+n]", where
    "A" is a component of an address register (Section 2.14.3.5), a
    texture coordinate number <c> is computed by adding the current
    value of the address register component and <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 coordinates for texture unit <c>.  If <c>
    is negative or greater than or equal to MAX_TEXTURE_COORDS_ARB,
    the vertex attribute variable is undefined.

    If a vertex attribute binding matches "vertex.attrib[A+n]", where
    "A" is a component of an address register (Section 2.14.3.5), a
    vertex attribute number <a> is computed by adding the current value
    of the address register component and <n>.  The "x", "y", "z", and
    "w" components of the vertex attribute variable are filled with the
    "x", "y", "z", and "w" components, respectively, of generic vertex
    attribute <a>.  If <a> is negative or greater than or equal to
    MAX_VERTEX_ATTRIBS_ARB, the vertex attribute variable is undefined.

    Modify Section 2.14.3.4, Vertex Program Results

    (add new binding to binding table)

      Binding                        Components  Description
      -----------------------------  ----------  ----------------------------
      ...
      result.texcoord[A+n]           (s,t,r,q)   indexed texture coordinate

    If a result variable binding matches "result.texcoord[A+n]", where "A"
    is a component of an address register (Section 2.14.3.5), a texture
    coordinate number <c> is computed by adding the current value of
    the address register component and <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 <c>.  If <c> is negative or
    greater than or equal to MAX_TEXTURE_COORDS_ARB, the effects of
    updates to vertex attribute variable are undefined and may overwrite
    other programs results.

    Modify Section 2.14.3.X, Condition Code Registers (added in
    NV_Vertex_program2_option)

    The vertex program condition code registers are two four-component
    vectors, called CC0 and CC1.  Each component of this register is one
    of four enumerated values: GT (greater than), EQ (equal), LT (less
    than), or UN (unordered).  The condition code register can be used
    to mask writes to registers and to evaluate conditional branches.

    Most vertex program instructions can optionally update one of the
    two condition code registers.  When a vertex program instruction
    updates a condition code register, a condition code component is set
    to LT if the corresponding component of the result is less than zero,
    EQ if it is equal to zero, GT if it is greater than zero, and UN if
    it is NaN (not a number).

    The condition code registers are initialized to vectors of EQ values
    each time a vertex program executes.

    Modify Section 2.14.3.7, Vertex Program Resource Limits

    (add new paragraph to end of section) In addition to the previous limits,
    the number of unique texture image units that can be accessed
    simultaneously by a vertex program is limited.  The limit is given by the
    implementation-dependent constant MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB, and
    may be lower than the total number of texture image units provided.  If
    the number of texture image units referenced by a vertex program exceeds
    this limit, the program will fail to load.
    
    Modify Section 2.14.4, Vertex Program Execution Environment

    (modify Begin-time error language for vertex program execution to cover
    invalid texture uses)

    If vertex program mode is enabled and the currently bound program object
    does not contain a valid vertex program, the error INVALID_OPERATION will
    be generated by Begin, RasterPos, and any command that implicitly calls
    Begin (e.g., DrawArrays).

    If vertex program mode is enabled and the currently bound program object
    accesses a texture image unit, the texture target used must be consistent
    with the target (if any) used for fragment processing.  If vertex and
    fragment processing require the use of different texture targets on the
    same texture image unit, the error INVALID_OPERATION will be generated by
    Begin, RasterPos, and any command that implicitly calls Begin.

    (modify instruction table) There are forty-eight vertex program
    instructions.  Vertex program instructions may have up to eight
    variants, including a suffix of "C" or "C0" to allow an update of
    condition code register zero (section 2.14.3.X), a suffix of "C1"
    to allow an update of condition code register one, and a suffix of
    "_SAT" to clamp the result vector components to the range [0,1].
    For example, the eight forms of the "ADD" instruction are "ADD",
    "ADDC", "ADDC0", "ADDC1", "ADD_SAT", "ADDC_SAT", "ADDC0_SAT", and
    "ADDC1_SAT".  The instructions and their respective input and output
    parameters are summarized in Table X.5.

                  Modifiers
      Instruction   C S   Inputs  Output   Description
      -----------   - -   ------  ------   --------------------------------
      ABS           X X   v       v        absolute value
      ADD           X X   v,v     v        add
      ARA           X -   a       a        address register add
      ARL           X -   s       a        address register load
      ARR           X -   v       a        address register load (round)
      BRA           - -   c       -        branch
      CAL           - -   c       -        subroutine call
      COS           X X   s       ssss     cosine
      DP3           X X   v,v     ssss     3-component dot product
      DP4           X X   v,v     ssss     4-component dot product
      DPH           X X   v,v     ssss     homogeneous dot product
      DST           X X   v,v     v        distance vector
      EX2           X X   s       ssss     exponential base 2
      EXP           X X   s       v        exponential base 2 (approximate)
      FLR           X X   v       v        floor
      FRC           X X   v       v        fraction
      LG2           X X   s       ssss     logarithm base 2
      LIT           X X   v       v        compute light coefficients
      LOG           X X   s       v        logarithm base 2 (approximate)
      MAD           X X   v,v,v   v        multiply and add
      MAX           X X   v,v     v        maximum
      MIN           X X   v,v     v        minimum
      MOV           X X   v       v        move
      MUL           X X   v,v     v        multiply
      POPA          - -   -       a        pop address register
      POW           X X   s,s     ssss     exponentiate
      PUSHA         - -   a       -        push address register
      RCC           X X   s       ssss     reciprocal (clamped)
      RCP           X X   s       ssss     reciprocal
      RET           - -   c       -        subroutine return
      RSQ           X X   s       ssss     reciprocal square root
      SEQ           X X   v,v     v        set on equal
      SFL           X X   v,v     v        set on false
      SGE           X X   v,v     v        set on greater than or equal
      SGT           X X   v,v     v        set on greater than
      SIN           X X   s       ssss     sine
      SLE           X X   v,v     v        set on less than or equal
      SLT           X X   v,v     v        set on less than
      SNE           X X   v,v     v        set on not equal
      SSG           X X   v       v        set sign
      STR           X X   v,v     v        set on true
      SUB           X X   v,v     v        subtract
      SWZ           X X   v       v        extended swizzle
      TEX           X X   v       v        texture lookup
      TXB           X X   v       v        texture lookup with LOD bias
      TXL           X X   v       v        texture lookup with explicit LOD
      TXP           X X   v       v        projective texture lookup
      XPD           X X   v,v     v        cross product

      Table X.5:  Summary of vertex program instructions.  The columns
      "C" and "S" indicate whether the "C", "C0", and "C1" condition code
      update modifiers, and the "_SAT" saturation modifiers, respectively,
      are supported for the opcode.  "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, "a" indicates a vector address register, and "c"
      indicates a condition code test.

    Rewrite Section 2.14.4.3,  Vertex Program Destination Register Update

    A vertex program instruction can optionally clamp the results of
    a floating-point result vector to the range [0,1].  The components
    of the result vector are clamped to [0,1] if the saturation suffix
    "_SAT" is present in the instruction.

    Most vertex program instructions write a 4-component result vector to
    a single temporary or vertex result register.  Writes to individual
    components of the destination register are controlled by individual
    component write masks specified as part of the instruction.

    The component write mask is specified by the <optionalMask> rule
    found in the <maskedDstReg> rule.  If the optional mask is "",
    all components are enabled.  Otherwise, the optional mask names
    the individual components to enable.  The characters "x", "y",
    "z", and "w" match the x, y, z, and w components respectively.
    For example, an optional mask of ".xzw" indicates that the x, z,
    and w components should be enabled for writing but the y component
    should not.  The grammar requires that the destination register mask
    components must be listed in "xyzw" order.  The condition code write
    mask is specified by the <ccMask> rule found in the <instResultCC>
    and <instResultAddrCC> rules.  Otherwise, the selected condition
    code register is loaded and swizzled according to the swizzle
    codes specified by <swizzleSuffix>.  Each component of the swizzled
    condition code is tested according to the rule given by <ccMaskRule>.
    <ccMaskRule> may have the values "EQ", "NE", "LT", "GE", LE", or "GT",
    which mean to enable writes if the corresponding condition code field
    evaluates to equal, not equal, less than, greater than or equal, less
    than or equal, or greater than, respectively.  Comparisons involving
    condition codes of "UN" (unordered) evaluate to true for "NE" and
    false otherwise.  For example, if the condition code is (GT,LT,EQ,GT)
    and the condition code mask is "(NE.zyxw)", the swizzle operation
    will load (EQ,LT,GT,GT) and the mask will thus will enable writes on
    the y, z, and w components.  In addition, "TR" always enables writes
    and "FL" always disables writes, regardless of the condition code.
    If the condition code mask is empty, it is treated as "(TR)".

    Each component of the destination register is updated with the result
    of the vertex program instruction if and only if the component is
    enabled for writes by both the component write mask and the condition
    code write mask.  Otherwise, the component of the destination register
    remains unchanged.

    A vertex program instruction can also optionally update the condition
    code register.  The condition code is updated if the condition
    code register update suffix "C" is present in the instruction.
    The instruction "ADDC" will update the condition code; the otherwise
    equivalent instruction "ADD" will not.  If condition code updates
    are enabled, each component of the destination register enabled
    for writes is compared to zero.  The corresponding component of
    the condition code is set to "LT", "EQ", or "GT", if the written
    component is less than, equal to, or greater than zero, respectively.
    Condition code components are set to "UN" if the written component is
    NaN (not a number).  Values of -0.0 and +0.0 both evaluate to "EQ".
    If a component of the destination register is not enabled for writes,
    the corresponding condition code component is also unchanged.

    In the following example code,

        # R1=(-2, 0, 2, NaN)              R0                  CC
        MOVC R0, R1;               # ( -2,  0,   2, NaN) (LT,EQ,GT,UN)
        MOVC R0.xyz, R1.yzwx;      # (  0,  2, NaN, NaN) (EQ,GT,UN,UN)
        MOVC R0 (NE), R1.zywx;     # (  0,  0, NaN,  -2) (EQ,EQ,UN,LT)

    the first instruction writes (-2,0,2,NaN) to R0 and updates the
    condition code to (LT,EQ,GT,UN).  The second instruction, only the
    "x", "y", and "z" components of R0 and the condition code are updated,
    so R0 ends up with (0,2,NaN,NaN) and the condition code ends up with
    (EQ,GT,UN,UN).  In the third instruction, the condition code mask
    disables writes to the x component (its condition code field is "EQ"),
    so R0 ends up with (0,0,NaN,-2) and the condition code ends up with
    (EQ,EQ,UN,LT).

    The following pseudocode illustrates the process of writing a
    result vector to the destination register.  In the pseudocode,
    "instrSaturate" is TRUE if and only if result saturation is
    enabled, "instrMask" refers to the component write mask given by
    the <optWriteMask> rule.  "ccMaskRule" refers to the condition code
    mask rule given by <ccMask> and "updatecc" is TRUE if and only if
    condition code updates are enabled.  "result", "destination", and "cc"
    refer to the result vector, the register selected by <dstRegister>
    and the condition code, respectively.  Condition codes do not exist
    in the VP1 execution environment.

      boolean TestCC(CondCode field) {
          switch (ccMaskRule) {
          case "EQ":  return (field == "EQ");
          case "NE":  return (field != "EQ");
          case "LT":  return (field == "LT");
          case "GE":  return (field == "GT" || field == "EQ");
          case "LE":  return (field == "LT" || field == "EQ");
          case "GT":  return (field == "GT");
          case "TR":  return TRUE;
          case "FL":  return FALSE;
          case "":    return TRUE;
          }
      }

      enum GenerateCC(float value) {
        if (value == NaN) {
          return UN;
        } else if (value < 0) {
          return LT;
        } else if (value == 0) {
          return EQ;
        } else {
          return GT;
        }
      }

      void UpdateDestination(floatVec destination, floatVec result)
      {
          floatVec merged;
          ccVec    mergedCC;

          // Clamp result components to [0,1] if requested in the instruction.
          if (instrSaturate) {
              if (result.x < 0)      result.x = 0;
              else if (result.x > 1) result.x = 1;
              if (result.y < 0)      result.y = 0;
              else if (result.y > 1) result.y = 1;
              if (result.z < 0)      result.z = 0;
              else if (result.z > 1) result.z = 1;
              if (result.w < 0)      result.w = 0;
              else if (result.w > 1) result.w = 1;
          }

          // Merge the converted result into the destination register, under
          // control of the compile- and run-time write masks.
          merged = destination;
          mergedCC = cc;
          if (instrMask.x && TestCC(cc.c***)) {
              merged.x = result.x;
              if (updatecc) mergedCC.x = GenerateCC(result.x);
          }
          if (instrMask.y && TestCC(cc.*c**)) {
              merged.y = result.y;
              if (updatecc) mergedCC.y = GenerateCC(result.y);
          }
          if (instrMask.z && TestCC(cc.**c*)) {
              merged.z = result.z;
              if (updatecc) mergedCC.z = GenerateCC(result.z);
          }
          if (instrMask.w && TestCC(cc.***c)) {
              merged.w = result.w;
              if (updatecc) mergedCC.w = GenerateCC(result.w);
          }

          // Write out the new destination register and condition code.
          destination = merged;
          cc = mergedCC;
      }

    While this rule describes floating-point results, the same logic
    applies to the integer results generated by the ARA, ARL, and ARR
    instructions.

    Add to Section 2.14.4.5, Vertex Program Options

    Section 2.14.4.5.3, NV_vertex_program3 Program Option

    If a vertex program specifies the "NV_vertex_program3" option, the
    ARB_vertex_program grammar and execution environment are extended
    to take advantage of all the features of the "NV_vertex_program2"
    option, plus the following features:

        * several new instructions:

          * POPA -- pop address register off stack        
          * PUSHA -- push address register onto stack
          * TEX -- texture lookup
          * TXB -- texture lookup w/LOD bias
          * TXL -- texture lookup w/explicit LOD
          * TXP -- projective texture lookup

        * address register-relative addressing for vertex texture
          coordinate and generic attribute arrays,

        * address register-relative addressing for vertex texture
          coordinate result array, and

        * a second four-component condition code.


    Modify Section 2.14.5.34,  RET:  Subroutine Call 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 (TestCC(cc.c***) || TestCC(cc.*c**) || 
          TestCC(cc.**c*) || TestCC(cc.***c)) {
        if (callStackDepth <= 0) {
          // terminate vertex program normally
        } else {
          callStackDepth--;
          if (callStack[callStackDepth] is a instruction reference) {
            instruction = callStack[callStackDepth];
          } else {
            // terminate vertex program abnormally
          }
        }

        // 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 vertex program
    terminates normally.

    The vertex program terminates abnormally if the entry at the top of the
    call stack is not an instruction reference pushed by CAL.  When a vertex
    program terminates abnormally, all of the vertex program results are
    undefined.

    Add to Section 2.14.5,  Vertex Program Instruction Set

    Section 2.14.5.43, POPA:  Pop Address Register Stack    

    The POPA instruction generates a integer result vector by popping
    an entry off of the call stack.

      if (callStackDepth <= 0) {
        terminate vertex program;
      } else {
        callStackDepth--;
        if (callStack[callStackDepth] is an address register) {
          iresult = callStack[callStackDepth];
        } else {
          terminate vertex program;
        }
      }

    POPA does not support non-default write masks; a program will fail to load
    if it includes a component write mask other than ".xyzw" or a condition
    code write mask test other than "TR".

    In the pseudocode, <callStackDepth> is the current depth of the call
    stack and <callStack> is an array holding the call stack.  

    The vertex program terminates abnormally if it executes a POPA instruction
    when the call stack is empty, or when the entry at the top of the call
    stack is not an address register pushed by PUSHA.  When a vertex program
    terminates abnormally, all of the vertex program results are undefined.

    Section 2.14.5.44, PUSHA:  Push Address Register Stack    

    The PUSHA instruction pushes the address register operand onto the
    call stack, which is also used for subroutine calls.  The PUSHA
    instruction does not generate a result vector.

      tmp = AddrVectorLoad(op0);
      if (callStackDepth >= MAX_PROGRAM_CALL_DEPTH_NV) {
        terminate vertex program;
      } else {
        callStack[callStackDepth] = tmp;
        callStackDepth++;
      }

    In the pseudocode, <callStackDepth> is the current depth of the call
    stack and <callStack> is an array holding the call stack.

    The vertex program terminates abnormally if it executes a PUSHA
    instruction when the call stack is full.  When a vertex program terminates
    abnormally, all of the vertex program results are undefined.

    Component swizzling is not supported when the operand is loaded.

    Section 2.14.5.45, TEX:  Texture Lookup

    The TEX instruction uses the single vector operand to perform a
    lookup in the specified texture map, yielding a 4-component result
    vector containing filtered texel values.  The (s,t,r,q) coordinates
    used for the texture lookup are (x,y,z,1), where x, y, and z are
    components of the vector operand.

      tmp = VectorLoad(op0);
      result = TextureSample(tmp.x, tmp.y, tmp.z, 1.0, 0.0, unit, target);

    where <unit> and <target> are the texture image unit number and
    target type, matching the <texImageUnitNum> and <texTargetType>
    grammar rules.

    The resulting sample is mapped to RGBA as described in Table 3.21,
    and the R, G, B, and A values are written to the x, y, z, and w
    components, respectively, of the result vector.

    Since partial derivatives of the texture coordinates are not defined,
    the base LOD value for vertex texture lookups is defined to be
    zero.  The value of lambda' used in equation 3.16 will be simply
    clamp(texobj_bias + texunit_bias).

    Section 2.14.5.46, TXB:  Texture Lookup (With LOD Bias)

    The TXB instruction uses the single vector operand to perform a
    lookup in the specified texture map, yielding a 4-component result
    vector containing filtered texel values.  The (s,t,r,q) coordinates
    used for the texture lookup are (x,y,z,1), where x, y, and z are
    components of the vector operand.  The w component of the operand
    is used as an additional LOD bias.

      tmp = VectorLoad(op0);
      result = TextureSample(tmp.x, tmp.y, tmp.z, 1.0, tmp.w, unit, target);

    where <unit> and <target> are the texture image unit number and
    target type, matching the <texImageUnitNum> and <texTargetType>
    grammar rules.

    The resulting sample is mapped to RGBA as described in Table 3.21,
    and the R, G, B, and A values are written to the x, y, z, and w
    components, respectively, of the result vector.

    Since partial derivatives of the texture coordinates are not defined,
    the base LOD value for vertex texture lookups is defined to be
    zero.  The value of lambda' used in equation 3.16 will be simply
    clamp(texobj_bias + texunit_bias + tmp.w).  

    Since the base LOD value is zero, the TXB instruction is completely
    equivalent to the TXL instruction, where the w component contains
    an explicit base LOD value.

    Section 2.14.5.47, TXL:  Texture Lookup (With Explicit LOD)

    The TXL instruction uses the single vector operand to perform a
    lookup in the specified texture map, yielding a 4-component result
    vector containing filtered texel values.  The (s,t,r,q) coordinates
    used for the texture lookup are (x,y,z,1), where x, y, and z are
    components of the vector operand.  The w component of the operand
    is used as the base LOD for the texture lookup.

      tmp = VectorLoad(op0); 
      result = TextureSampleLOD(tmp.x, tmp.y, tmp.z, 1.0, tmp.w, unit, target);

    where <unit> and <target> are the texture image unit number and
    target type, matching the <texImageUnitNum> and <texTargetType>
    grammar rules.

    The resulting sample is mapped to RGBA as described in Table 3.21,
    and the R, G, B, and A values are written to the x, y, z, and w
    components, respectively, of the result vector.

    The value of lambda' used in equation 3.16 will be simply tmp.w +
    clamp(texobj_bias + texunit_bias), where tmp.w is the base LOD.

    Section 2.14.5.48, TXP:  Texture Lookup (Projective)

    The TXP instruction uses the single vector operand to perform a
    lookup in the specified texture map, yielding a 4-component result
    vector containing filtered texel values.  The (s,t,r,q) coordinates
    used for the texture lookup are (x,y,z,w), where x, y, z, and w are
    the four components of the vector operand.

      tmp = VectorLoad(op0);
      result = TextureSample(tmp.x, tmp.y, tmp.z, tmp.w, 0.0, unit, target);

    where <unit> and <target> are the texture image unit number and
    target type, matching the <texImageUnitNum> and <texTargetType>
    grammar rules.

    The resulting sample is mapped to RGBA as described in Table 3.21,
    and the R, G, B, and A values are written to the x, y, z, and w
    components, respectively, of the result vector.

    Since partial derivatives of the texture coordinates are not defined,
    the base LOD value for vertex texture lookups is defined to be
    zero.  The value of lambda' used in equation 3.16 will be simply
    clamp(texobj_bias + texunit_bias).

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

    None.

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_vertex_program

    ARB_vertex_program is required.

    This specification and NV_vertex_program2_option are based on a
    modified version of the grammar published in the ARB_vertex_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_vertex_program grammar.  See NV_vertex_program2_option for
    details on the base grammar.

Dependencies on NV_vertex_program2_option

    NV_vertex_program2_option is required.  

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

Dependencies on ARB_fragment_program_shadow

    If this extension and ARB_fragment_program shadow are both supported,
    vertex programs may include the option statement:

      OPTION ARB_fragment_program_shadow;

    which enables the use of SHADOW1D, SHADOW2D, and SHADOWRECT texture
    targets in texture lookup instructions, as described in the
    ARB_fragment_program_shadow specification.

    NVIDIA NOTE:  Drivers prior to September 2006 do not support the use of
    this option, and will not accept texture lookups with SHADOW1D, SHADOW2D,
    and SHADOWRECT targets.  Shadow mapping in vertex programs will result in
    software fallbacks on GeForce 6 and GeForce 7 series GPUs, but may be done
    in hardware on future GPUs.

Errors

    None.

New State

    None.

New Implementation Dependent State:

                                             Minimum
    Get Value             Type  Get Command   Value   Description                 Section   Attr.
    ---------             ----  -----------  -------  --------------------------  --------  -----
    MAX_VERTEX_TEXTURE_    Z+   GetIntegerv     1     Number of separate texture  2.14.3.7  -
      IMAGE_UNITS_ARB                                 image units that can be
                                                      accessed by a vertex program

Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  --------------------------------------------
    7     10/12/09  pbrown    Update grammar/documentation of PUSHA/POPA to
                              reflect the implementation.  <instResultAddr> is
                              used for POPA with some semantic checks.  Note
                              that some driver versions erroneously allowed
                              conditional write masks on POPA.  Also clarify
                              that ARB_fragment_program_shadow includes
                              support for "SHADOWRECT".

    6     09/27/06  pbrown    Document that ARB_fragment_program_shadow is
                              allowed, to enable the use of "SHADOW1D" and
                              "SHADOW2D" targets for texture lookups.

    5     11/07/05  pbrown    Fix PUSHA documentation to specify the right
                              constant name used for overflow testing.

    4     09/01/05  pbrown    Fix spec language to document that a vertex
                              program will fail to compile if it uses "too
                              many" textures -- previously only documented
                              in the issues section.

    3     08/25/05  pbrown    Document that using a different texture target
                              than fragment processing on the same texture
                              unit results in an INVALID_OPERATION error at
                              Begin time.  This is consistent with GLSL
                              language in the ARB_shader_objects and OpenGL
                              2.0 specifications.  The implementation has
                              always done this, but it was overlooked in
                              the spec language.

    2     06/23/04  pbrown    Documented that vertex results are undefined
                              when a vertex program terminates abnormally
                              (e.g., PUSHA/POPA stack overflow/underflow).
                              Documented error in RET if the top of the call
                              stack contains a value written by PUSHA.

    1     --------  pbrown    Initial pre-release revisions.