Name

    ARB_fragment_program

Name Strings

    GL_ARB_fragment_program

Contributors

    Bob Beretta
    Pat Brown
    Matt Craighead
    Cass Everitt
    Evan Hart
    Jon Leech
    Bill Licea-Kane
    Bimal Poddar
    Jeremy Sandmel
    Jon Paul Schelter
    Avinash Seetharamaiah
    Nick Triantos

    and contributors to the ARB_vertex_program working group,
    the product of which provided the basis for this spec

Contact

    Benj Lipchak, AMD (benj.lipchak 'at' amd.com)

Notice

    Copyright (c) 2002-2013 The Khronos Group Inc. Copyright terms at
        http://www.khronos.org/registry/speccopyright.html

IP Status

    Microsoft claims to own intellectual property related to this 
    extension.

Status

    Complete.  Approved by ARB on September 18, 2002

Version

    Last Modified Date: October 8, 2013
    Revision: 28

Number

    ARB Extension #27

Dependencies

    The extension is written against the OpenGL 1.3 Specification.

    OpenGL 1.3 is required.

    EXT_texture_lod_bias or OpenGL 1.4 is required.

    OpenGL 1.4 affects the definition of this extension.

    ARB_vertex_blend and EXT_vertex_weighting affect the definition of 
    this extension.

    ARB_matrix_palette affects the definition of this extension.

    ARB_transpose_matrix affects the definition of this extension.

    EXT_fog_coord affects the definition of this extension.

    EXT_texture_rectangle affects the definition of this extension.

    ARB_shadow interacts with this extension.

    ARB_vertex_program interacts with this extension.

    ATI_fragment_shader interacts with this extension.

    NV_fragment_program interacts with this extension.


Overview

    Unextended OpenGL mandates a certain set of configurable per-
    fragment computations defining texture application, texture 
    environment, color sum, and fog operations.  Several extensions have 
    added further per-fragment computations to OpenGL.  For example, 
    extensions have defined new texture environment capabilities 
    (ARB_texture_env_add, ARB_texture_env_combine, ARB_texture_env_dot3,
    ARB_texture_env_crossbar), per-fragment depth comparisons 
    (ARB_depth_texture, ARB_shadow, ARB_shadow_ambient, 
    EXT_shadow_funcs), per-fragment lighting (EXT_fragment_lighting, 
    EXT_light_texture), and environment mapped bump mapping 
    (ATI_envmap_bumpmap).  

    Each such extension adds a small set of relatively inflexible per-
    fragment computations.

    This inflexibility is in contrast to the typical flexibility 
    provided by the underlying programmable floating point engines 
    (whether micro-coded fragment engines, DSPs, or CPUs) that are 
    traditionally used to implement OpenGL's texturing computations.  
    The purpose of this extension is to expose to the OpenGL application 
    writer a significant degree of per-fragment programmability for 
    computing fragment parameters.

    For the purposes of discussing this extension, a fragment program is 
    a sequence of floating-point 4-component vector operations that 
    determines how a set of program parameters (not specific to an
    individual fragment) and an input set of per-fragment parameters are 
    transformed to a set of per-fragment result parameters.

    The per-fragment computations for standard OpenGL given a particular 
    set of texture and fog application modes (along with any state for 
    extensions defining per-fragment computations) is, in essence, a 
    fragment program.  However, the sequence of operations is defined 
    implicitly by the current OpenGL state settings rather than defined 
    explicitly as a sequence of instructions.

    This extension provides an explicit mechanism for defining fragment 
    program instruction sequences for application-defined fragment 
    programs.  In order to define such fragment programs, this extension 
    defines a fragment programming model including a floating-point
    4-component vector instruction set and a relatively large set of 
    floating-point 4-component registers.

    The extension's fragment programming model is designed for efficient
    hardware implementation and to support a wide variety of fragment 
    programs.  By design, the entire set of existing fragment programs 
    defined by existing OpenGL per-fragment computation extensions can 
    be implemented using the extension's fragment programming model.

Issues

    This extension is closely related to ARB_vertex_program, and is in 
    sync with revision 36 of that spec.  ARB_fragment_program will 
    continue to track changes made to ARB_vertex_program.

    (1) Should we provide precision queries?

      RESOLVED: We've decided not to include precision queries.
      Implementations are expected to meet or exceed the precision 
      guidelines set forth in the core GL spec, section 2.1.1, p. 6,
      as ammended by this extension.

      To summarize section 2.1.1, the maximum representable magnitude of 
      colors must be at least 2^10, while the maximum representable 
      magnitude of other floating-point values must be at least 2^32.  
      The individual results of floating-point operations must be 
      accurate to about 1 part in 10^5.

      Here are the reasons why precision queries were not included:
        1. It is unclear what the queries should be:
           a) min, max, [0,1) granularity
           b) min +, max +, min -, max -, [0,1) granularity
           c) IEEE mantissa bits, IEEE exponent bits
        2. Due to instruction emulation, there is no way to query the 
           actual precision that can be expected.  Should the query 
           return the best-case or worst-case precision?
        3. Implementations may support multiple precisions, on a per-
           instruction basis or across the board.  How would this be 
           exposed?
        4. Current implementations are able to meet the minimum 
           requirements specified in the core GL, thanks to its
           sufficiently loose wording "... so that the individual 
           results of floating-point operations are accurate to ABOUT 
           1 part in 10^5."  (Emphasis added.)
        5. A conformance test can act as watchdog to ensure 
           implementations are not cutting corners on precision.
        6. Adding precision queries would require a new entrypoint.

      See issue 22 regarding reduced-precision modes.

    (2) Should the LOD biased texture sample be optional?

      RESOLVED: TXB support is mandatory.  This exposes useful 
      functionality which enables blurring and sharpening effects.  It 
      will be more useful to entirely override derivatives (scale 
      factor) rather than just biasing the level-of-detail.  This would 
      be a future extension to fragment programs.

      It should be noted here that the bias introduced per-fragment by 
      TXB is added to any per-object or per-stage LOD bias.  If per-
      fragment LOD bias is not necessary, using the per-object and/or 
      per-stage LOD biases may perform better.

    (3) Should we include the ability to bind to the color matrix?  How
    about others?  Program matrices?

      RESOLVED: We will not specifically add anything that depends on 
      the ARB_imaging subset.  So we have not included matrix bindings 
      to the color matrix (or parameter bindings to the color biases, 
      etc.).  However, we have included matrix binding support and 
      support for all of the matrices present in ARB_vertex_program.

    (4) Should we include the ability to bind to just a texcoord 
    attribute's S,T components?  (Or just S, or S,T,P for that matter?) 

      RESOLVED: No.  Issue #15 below obviates this issue by making the
      texture coordinate usage within a program explicit, thereby making 
      optimizations to reduce the number of interpolated texture 
      coordinates something an implementation can do at compile time 
      instead of having to do it during every texture target change.

    (5) What other instructions should be added?  Should any be removed?

      RESOLVED: The differences between the ARB_vertex_program 
      instruction set and the ARB_fragment_program instruction set are
      minimal.  ARB_fragment_program removes the LOG and EXP rough
      approximation instructions and the ARL address register load
      instruction.  ARB_fragment_program adds the SIN/COS/SCS 
      trigonometric instructions, the LRP linear interpolation 
      instruction, the CMP compare instruction, and the TEX/TXP/TXB/KIL
      texture instructions.

    (6) Should depth output be a program option or a mandatory feature?
 
      RESOLVED: Depth output capability should be mandatory.

    (6a) How should per-vertex geometric depth clipping be handled when 
      replacing depth in a fragment program?

      RESOLVED: Per-vertex geometric depth clipping should be performed 
      by the GL as usual, so no spec change is required.  The ideal
      behavior would be to disable near and far clipping planes when
      replacing depth, but not all implementations can natively support
      disabling individual clip planes.

    (6b) How should depth output from the fragment program be further 
    processed before being handed to the per-fragment operations?

      RESOLVED: Depth gets clamped by GL to [0,1].  App has access to 
      depth range as a bindable parameter if it wants to either scale 
      and bias its depth to fall within the depth range, or to kill 
      fragments outside the depth range.

    (7) If a fragment program does not write a color value, what should
    be the final color of the fragment?

      RESOLVED: The final fragment color is undefined.  Note that it may
      be perfectly reasonable to have a program that computes depth 
      values but not colors.  Fragment colors are often irrelevant if
      color writes are disabled (via ColorMask).

    (7a) If a fragment program does not write a depth value, what should 
    be the final depth value of the fragment?

      RESOLVED: "Depth fly-over" (using the conventional depth produced
      by rasterization) should happen whenever a depth-replacing program 
      is not in use.  A depth-replacing program is defined as a program
      that writes to result.depth in at least one instruction.  The
      presence of a depth declaration alone DOES NOT designate a depth-
      replacing program.  The intention is that a future extension
      introducing conditional execution will still consider a program to
      be depth-replacing even if the instruction(s) writing to 
      result.depth do(es) not execute.

      Other considered definitions of depth-replacing program:
        1. The presence of a depth declaration -OR- the use of 
           result.depth as an instruction destination anywhere in the 
           program designates a depth-replacing program.
        2. Every program is a depth-replacing program, but the GL 
           initializes the depth output to be the depth produced by 
           rasterization.  The app may then overwrite the depth output.
        3. Every program is a depth-replacing program, and the app is 
           solely responsible for copying the depth input to depth 
           output if desired.

    (8) Should relative addressing, like that defined in 
    ARB_vertex_program, be supported in this spec?

      RESOLVED: No, relative addressing won't be included in this spec.

    (9) Should full-featured operand component swizzling, like that 
    defined in ARB_vertex_program, be supported in this spec?

      RESOLVED: Yes, full swizzling is mandatory.

    (10) Should texture instructions contain specific limitations on
    operations that can be performed?  For example, should write masks
    or operand component swizzling be disallowed?

      RESOLVED: Texture instructions are specified to be very similar to 
      ALU instructions.  They have been given 3-letter names, they allow 
      writemasking and saturation (which would be useful for floating-
      point texture formats), source swizzles and negates, and the 
      ability to use parameters as sources.

    (11) Should we standardize options for stencil or aux data buffer
    outputs?

      RESOLVED: Stencil and aux data buffers will be saved for a 
      possible future extension to fragment programs.

    (12) Should depth output be pulled from the 3rd or 4th component?

      RESOLVED: 3rd component, as the 3rd component is also used for
      depth input from the "fragment.position" attribute.

    (13) Which stages are subsumed by fragment programs?

      RESOLVED: Texturing, color sum, and fog.

    (14) What should the minimum resource limits be?

      RESOLVED: 10 attributes, 24 parameters, 4 texture indirections,
      48 ALU instructions, 24 texture instructions, and 16 temporaries.

    (15) OpenGL provides a hierarchy of texture enables (cube map, 3D, 
    2D, 1D).  Should the texture sampling instructions here override 
    that hierarchy and select specific texture targets?

      RESOLVED: Yes.  This removes a potential pitfall for developers: 
      leaving the hierarchy of enables in an undesired state.  It makes 
      programs more readable as the intent of the sample is more 
      obvious.  Finally, it allows compilers to be more aggressive as 
      to which texcoord components are "don't cares" without having to 
      recompile programs when fixed-function texenables change.  One 
      drawback is that programs cannot be reused for both 2D and 3D 
      texturing, for example, by simply changing the texture enables. 

      Texture sampling can be specified by instructions like 
      
        TEX myTexel, fragment.texcoord[1], texture[2], 3D;

      which would indicate to use texture coordinate set number 1 to
      sample from the texture object bound to the TEXTURE_3D target on 
      texture image unit 2.

      Each texture unit can have only one "active" target.  Programs are 
      not allowed to reference different texture targets in the same 
      texture image unit.  In the example above, any other texture 
      instructions using texture image unit 2 must specify the 3D 
      texture target.

      Note that every texture image unit always has a texture bound to 
      every texture target, whether it is a named texture object or a 
      default texture.  However, the texture may not be complete as
      defined in section 3.8.9 of the core GL spec.  See issue 23.

    (16) Should aux texture units be additional units on top of existing 
    full-featured texture units, or should this spec fully deprecate 
    "legacy" texture units and only expose texture coordinate sets and
    texture image units?

      Background: Some implementations are able to expose more 
      "texture image units" (texture maps and associated parameters) 
      than "texture coordinate sets" (current texcoords, texgen, and 
      texture matrices).  A conventional GL "texture unit" encompasses 
      both a texture image unit and a texture coordinate set as well as 
      texture environment state.

      RESOLVED: Yes, deprecate "legacy" texture units.  This is a more 
      flexible model.

    (17) Should fragment programs affect all fragments, or just those
    produced by the rasterization of points, lines, and triangles?

      RESOLVED: Every fragment generated by the GL is subject to 
      fragment program mode.  This includes point, line, and polygon 
      primitives as well as pixel rectangles and bitmaps.

    (18) Should per-fragment position and fogcoord be bindable as 
    fragment attributes?

      RESOLVED: Yes, interpolated fogcoord will make per-fragment 
      fog application possible, in addition to full fog stage 
      subsummation.  Interpolated window position, especially depth,
      enables interesting depth-replacing algorithms.

    (19) What characters should be used to identify individual 
    components in swizzle selectors and write masks?

      RESOLVED: ARB_vertex_program provides "xyzw".  This extension 
      supports "xyzw" and also provides "rgba" for better readability 
      when dealing with RGBA color values.  Adding support for special 
      identifiers for dealing with texture coordinates was considered 
      and rejected.  "strq" could be used to identify texture coordinate 
      components, but the "r" would conflict with the "r" from "rgba".
      "stpq" would be another possibility, but could be a source of 
      confusion.

    (20) Should implementations be required to support all programs that 
    fit within the exported limits on the number of resources (e.g.,
    instructions, temporaries) that can be present in a program, even if 
    it means falling back to software?  Should implementations be 
    required to reject programs that could never be accelerated?

      RESOLVED: No and no.  An implementation is allowed to fail 
      ProgramStringARB due to the program exceeding native resources.
      Note that this failure must be invariant with respect to all other
      OpenGL state.  In other words, a program cannot succeed to load
      with default state, but then fail to load when certain GL state
      is altered.  However, an implementation is not required to fail
      when a program would exceed native resources, and is in fact
      encouraged to fallback to a software path.  See issue 21 for a way
      of determining if this has happened.

      This notable departure from ARB_vertex_program was made as an
      accommodation to vendors who could not justify implementing a
      software fallback path which would be relatively slow even 
      compared to an ARB_vertex_program software fallback path.

      Two issues with this decision:
        1.  The API limits become hints, and one can no longer tell by
            visual inspection whether or not a program will load on
            every implementation.
        2.  Program loading will now depend on the optimizer, which may 
            vary from release to release of an implementation.  A 
            program that succeeded to load when an ISV first wrote it 
            may fail to load in a future driver version, and vice versa.

    (21) How can applications determine if their programs are too large
    to run on the native (likely hardware) implementation, and therefore may
    run with reduced performance?

      RESOLVED: The following code snippet uses a native resource
      query to guarantee a program is loaded natively (or not at all):

      GLboolean ProgramStringIsNative(GLenum target, GLenum format, 
                                     GLsizei len, const void *string)
      {
          GLint errorPos, isNative;
          glProgramStringARB(target, format, len, string);
          glGetIntegerv(GL_PROGRAM_ERROR_POSITION_ARB, &errorPos);
          glGetProgramivARB(GL_FRAGMENT_PROGRAM_ARB, 
              GL_PROGRAM_UNDER_NATIVE_LIMITS_ARB, &isNative);
          if ((errorPos == -1) && (isNative == 1))
              return GL_TRUE;
          else
              return GL_FALSE;
      }

      Note that a program that successfully loads, and falls under the
      native limits, is still not guaranteed to execute in hardware.
      Lack of other resources (e.g., texture memory) or the use of other 
      OpenGL features not natively supported by the implementation 
      (e.g., textures with borders) may also prevent the program from
      executing in hardware.

    (22) Should we provide applications with a method to control the 
    level of precision used to carry out fragment program computations?

      RESOLVED:  Yes.  The GL implementation ultimately has control over 
      the level of precision used for fragment program computations.  
      However, the "ARB_precision_hint_fastest" and 
      "ARB_precision_hint_nicest" program options allow applications to 
      guide the GL implementation in its precision selection.  The 
      "fastest" option encourages the GL to minimize execution time, 
      with possibly reduced precision.  The "nicest" option encourages 
      the GL to maximize precision, with possibly increased execution 
      time.

      If the precision hint is not "fastest", GL implementations should
      perform low-precision operations only if they could not 
      appreciably affect the final results of the program.  Regardless 
      of the precision hint, GL implementations are discouraged from 
      reducing the precision of computations so aggressively that final 
      rendering results could be seriously compromised due to overflow
      of intermediate values or insufficient number of mantissa bits.

      Some implementations may provide only a single level of precision, 
      in which case these hints may have no effect.  However, all
      implementations will accept these options, even if they are 
      silently ignored.

      More explicit control of precision, such as provided in "C" with 
      data types such as "short", "int", "float", "double", may also be 
      a desirable feature, but this level of detail is left to a 
      separate extension.

    (23) What is the result of a sample from an incomplete texture? 
    The definition of texture completeness can be found in section 3.8.9 
    of the core GL spec. 

      RESOLVED: The result of a sample from an incomplete texture is the 
      constant vector (0,0,0,1).  The benefit of defining the result to 
      be a constant is that broken apps are guaranteed to generate 
      unexpected (black) results from their bad samples.  If we were to 
      leave the result undefined, some implementations may generate 
      expected results some of the time, for example when magfiltering, 
      giving app developers a false sense of correctness in their apps. 

    (24) What is a texture indirection, and how is it counted?

       RESOLVED: On some implementations, fragment programs that have
       complex texture dependency chains may not be supported, even if 
       the instruction counts fit within the exported limits.  A texture
       dependency occurs when a texture instruction depends on the 
       result of a previous instruction (ALU or texture) for use as its 
       texture coordinate.

       A texture indirection can be considered a node in the texture 
       dependency chain.  Each node contains a set of texture 
       instructions which execute in parallel, followed by a sequence of 
       ALU instructions.  A dependent texture instruction is one that 
       uses a temporary as an input coordinate rather than an attribute 
       or a parameter.  A program with no dependent texture instructions 
       (or no texture instructions at all) will have a single node in 
       its texture dependency chain, and thus a single indirection.

       API-level texture indirections are counted by keeping track of
       which temporaries are read and written within the current node in 
       the texture dependency chain.  When a texture instruction is 
       encountered, an indirection may be added and a new node started 
       if either of the following two conditions is true:

         1. the source coordinate of the texture instruction is a
            temporary that has already been written in the current node, 
            either by a previous texture instruction or ALU instruction;

         2. the result of the texture instruction is a temporary that 
            has already been read or written in the current node by an 
            ALU instruction.

       The texture instruction provoking a new indirection and all
       subsequent instructions are added to the new node.  This process
       is repeated until the end of the program is encountered.  Below 
       is some pseudo-code to describe this:

         indirections = 1;
         tempsOutput = 0;
         aluTemps = 0;
         while (i = getInst()) 
         {
           if (i.type == TEX) 
           {
             if (((i.input.type == TEMP) && 
                   (tempsOutput & (1 << i.input.index))) ||
                 ((i.op != KILL) && (i.output.type == TEMP) && 
                   (aluTemps & (1 << i.output.index)))) 
             {
               indirections++;
               tempsOutput = 0;
               aluTemps = 0;
             }
           } else {
             if (i.input1.type == TEMP)
               aluTemps |= (1 << i.input1.index);
             if (i.input2 && i.input2.type == TEMP)
               aluTemps |= (1 << i.input2.index);
             if (i.input3 && i.input3.type == TEMP)
               aluTemps |= (1 << i.input3.index);
             if (i.output.type == TEMP)
               aluTemps |= (1 << i.output.index);
           }
           if ((i.op != KILL) && (i.output.type == TEMP))
             tempsOutput |= (1 << i.output.index);
         }

       For example, the following programs would have 1, 2, and 3
       texture indirections, respectively:

         !!ARBfp1.0
         # No texture instructions, but always 1 indirection
         MOV result.color, fragment.color;
         END

         !!ARBfp1.0
         # A simple dependent texture instruction, 2 indirections
         TEMP myColor;
         MUL myColor, fragment.texcoord[0], fragment.texcoord[1];
         TEX result.color, myColor, texture[0], 2D;
         END

         !!ARBfp1.0
         # A more complex example with 3 indirections
         TEMP myColor1, myColor2;
         TEX myColor1, fragment.texcoord[0], texture[0], 2D;
         MUL myColor1, myColor1, myColor1;
         TEX myColor2, fragment.texcoord[1], texture[1], 2D;
         # so far we still only have 1 indirection
         TEX myColor2, myColor1, texture[2], 2D;      # This is #2
         TEX result.color, myColor2, texture[3], 2D;  # And #3
         END

       Note that writemasks for the temporaries written and swizzles 
       for the temporaries read are not taken into consideration when
       counting indirections.  This makes hand-counting of indirections
       by a developer an easier task.

       Native texture indirections may be counted differently by an
       implementation to reflect its exact restrictions, to reflect the 
       true dependencies taking into account writemasks and swizzles, 
       and to reflect optimizations such as instruction reordering.  

       For implementations with no restrictions on the number of
       indirections, the maximum indirection count will equal the
       maximum texture instruction count.

    (25) How can a program reduce SCS's scalar operand to the 
    fundamental period [-PI,PI]?

       RESOLVED: Unlike the individual SIN and COS instructions, SCS 
       requires that its argument be reduced ahead of time to the 
       fundamental period.  The reason SCS doesn't perform this 
       operation automatically is that it may make unnecessary redundant 
       work for programs that already have their operand in the correct 
       range.  Other programs that do need to reduce their operand 
       simply need to add a block of code before the SCS instruction:

         PARAM myParams = { 0.5, -3.14159, 6.28319, 0.15915 };
         MAD myOperand.x, myOperand.x, myParams.w, myParams.x; # a = (a/(2*PI))+0.5
         FRC myOperand.x, myOperand.x;                         # a = frac(a)
         MAD myOperand.x, myOperand.x, myParams.z, myParams.y  # a = (a*2*PI)-PI
         ...
         SCS myResult, myOperand.x;

    (26) Is depth output from a fragment program guaranteed to be
    invariant with respect to depth produced via conventional 
    rasterization?

      RESOLVED:  No.  The floating-point representation of depth values 
      output from a fragment program may lead to the output of depth 
      with less precision than the depth output by convention GL 
      rasterization.  For example, a floating-point representation with 
      16 bits of mantissa will certainly produce depth with lesser 
      precision than that of conventional rasterization used in 
      conjunction with a 24-bit depth buffer, where all values are
      maintained as integers.  Be aware of this when mixing conventional 
      GL rendering with fragment program rendering.

    (27) How can conventional GL fog application be achieved within a 
    fragment program?

      RESOLVED: Program options have been introduced that allow a 
      program to request fog to be applied to the final clamped fragment 
      color before being passed along to the antialiasing application 
      stage.  This makes it easy for:
        1. developers to request conventional fog behavior
        2. implementations with dedicated fog hardware to use it
        3. implementations without dedicated fog hardware, so they need 
           not track fog state after compilation, and constantly 
           recompile when fog state changes.

      The three mandatory options are ARB_fog_exp, ARB_fog_exp2, and 
      ARB_fog_linear.  As these options are mutually exclusive by
      nature, specifying more than one is not useful.  If more than one
      is specified, the last one encountered in the <optionSequence> 
      will be the one to actually modify the execution environment.

    (28) Why have all of the enums, entrypoints, GLX protocol, and spec 
    language shared with ARB_vertex_program been reproduced here?

      RESOLVED: The two extensions are independent of one another, in
      so far as an implementation need not support both of them in order 
      to support one of them.  Everything needed to implement or make 
      use of ARB_fragment_program is present in this spec without the
      need to refer to the ARB_vertex_program spec.  When and if these
      two extensions are incorporated into the core OpenGL, the
      significant overlap of the two will be collapsed into a single
      instance of the shared parts.

    (29) How might an implementation implement the fog options?  To What
    does the extra resource consumption described in 3.11.4.5.1 
    correspond?

      RESOLVED: The following code snippets reflect possible
      implementations of the fog options.  While an implementation may
      use other instruction sequences to achieve the same result, or may 
      use external fog hardware if available, all implementations must 
      enforce the API-level resource consumption as described: 2 params,
      1 temp, 1 attribute, and 3, 4, or 2 instructions.  "finalColor" in
      the examples below is the color that would otherwise be 
      "result.color", with components clamped to the range [0,1].
      "result.color.a" is assumed to have already been written, as fog
      blending does not affect the alpha component.

      EXP:
        # Exponential fog
        # f = exp(-d*z)
        #
        PARAM p = {DENSITY/LN(2), NOT USED, NOT USED, NOT USED};
        PARAM fogColor = state.fog.color;
        TEMP fogFactor;
        ATTRIB fogCoord = fragment.fogcoord.x;
        MUL fogFactor.x, p.x, fogCoord.x;
        EX2_SAT fogFactor.x, -fogFactor.x;
        LRP result.color.rgb, fogFactor.x, finalColor, fogColor;

      EXP2:
        #
        # 2nd-order Exponential fog
        # f = exp(-(d*z)^2)
        #
        PARAM p = {DENSITY/SQRT(LN(2)), NOT USED, NOT USED, NOT USED};
        PARAM fogColor = state.fog.color;
        TEMP fogFactor;
        ATTRIB fogCoord = fragment.fogcoord.x;
        MUL fogFactor.x, p.x, fogCoord.x;
        MUL fogFactor.x, fogFactor.x, fogFactor.x;
        EX2_SAT fogFactor.x, -fogFactor.x;
        LRP result.color.rgb, fogFactor.x, finalColor, fogColor;

      LINEAR:
        #
        # Linear fog
        # f = (end-z)/(end-start)
        #
        PARAM p = {-1/(END-START), END/(END-START), NOT USED, NOT USED};
        PARAM fogColor = state.fog.color;
        TEMP fogFactor;
        ATTRIB fogCoord = fragment.fogcoord.x;
        MAD_SAT fogFactor.x, p.x, fogCoord.x, p.y;
        LRP result.color.rgb, fogFactor.x, finalColor, fogColor;

    (30) Why is the order of operands for the CMP instruction different
    than the order used by another popular graphics API?

      RESOLVED: No other graphics API was used as a basis for the
      design of ARB_fragment_program except ARB_vertex_program, which
      did not have a CMP instruction.  This independent evolution
      naturally led to differences in minor details such as order of
      operands.  This discrepancy is noted here to help developers 
      familiar with the other API to avoid this potential pitfall.

    (31) Is depth offset applied to the window z value before it enters
    the fragment program?

      RESOLVED: As in the base OpenGL specification, the depth offset
      generated by polygon offset is added during polygon rasterization.
      The depth value provided to shaders in the fragment.position.z
      attribute already includes polygon offset, if enabled.  If the
      depth value is replaced by a fragment program, the polygon offset
      value will NOT be recomputed and added back after fragment program
      execution.

      NOTE: This is probably not desirable for fragment programs that
      modify depth values since the partials used to generate the offset
      may not match the partials of the computed depth value.


New Procedures and Functions

    void ProgramStringARB(enum target, enum format, sizei len, 
                          const void *string); 

    void BindProgramARB(enum target, uint program);

    void DeleteProgramsARB(sizei n, const uint *programs);

    void GenProgramsARB(sizei n, uint *programs);

    void ProgramEnvParameter4dARB(enum target, uint index,
                                  double x, double y, double z, double w);
    void ProgramEnvParameter4dvARB(enum target, uint index,
                                   const double *params);
    void ProgramEnvParameter4fARB(enum target, uint index,
                                  float x, float y, float z, float w);
    void ProgramEnvParameter4fvARB(enum target, uint index,
                                   const float *params);

    void ProgramLocalParameter4dARB(enum target, uint index,
                                    double x, double y, double z, double w);
    void ProgramLocalParameter4dvARB(enum target, uint index,
                                     const double *params);
    void ProgramLocalParameter4fARB(enum target, uint index,
                                    float x, float y, float z, float w);
    void ProgramLocalParameter4fvARB(enum target, uint index,
                                     const float *params);

    void GetProgramEnvParameterdvARB(enum target, uint index,
                                     double *params);
    void GetProgramEnvParameterfvARB(enum target, uint index, 
                                     float *params);

    void GetProgramLocalParameterdvARB(enum target, uint index,
                                       double *params);
    void GetProgramLocalParameterfvARB(enum target, uint index, 
                                       float *params);

    void GetProgramivARB(enum target, enum pname, int *params);

    void GetProgramStringARB(enum target, enum pname, void *string);

    boolean IsProgramARB(uint program);


New Tokens

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

        FRAGMENT_PROGRAM_ARB                            0x8804

    Accepted by the <format> parameter of ProgramStringARB:

        PROGRAM_FORMAT_ASCII_ARB                        0x8875

    Accepted by the <pname> parameter of GetProgramivARB:

        PROGRAM_LENGTH_ARB                              0x8627
        PROGRAM_FORMAT_ARB                              0x8876
        PROGRAM_BINDING_ARB                             0x8677
        PROGRAM_INSTRUCTIONS_ARB                        0x88A0
        MAX_PROGRAM_INSTRUCTIONS_ARB                    0x88A1
        PROGRAM_NATIVE_INSTRUCTIONS_ARB                 0x88A2
        MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB             0x88A3
        PROGRAM_TEMPORARIES_ARB                         0x88A4
        MAX_PROGRAM_TEMPORARIES_ARB                     0x88A5
        PROGRAM_NATIVE_TEMPORARIES_ARB                  0x88A6
        MAX_PROGRAM_NATIVE_TEMPORARIES_ARB              0x88A7
        PROGRAM_PARAMETERS_ARB                          0x88A8
        MAX_PROGRAM_PARAMETERS_ARB                      0x88A9
        PROGRAM_NATIVE_PARAMETERS_ARB                   0x88AA
        MAX_PROGRAM_NATIVE_PARAMETERS_ARB               0x88AB
        PROGRAM_ATTRIBS_ARB                             0x88AC
        MAX_PROGRAM_ATTRIBS_ARB                         0x88AD
        PROGRAM_NATIVE_ATTRIBS_ARB                      0x88AE
        MAX_PROGRAM_NATIVE_ATTRIBS_ARB                  0x88AF
        MAX_PROGRAM_LOCAL_PARAMETERS_ARB                0x88B4
        MAX_PROGRAM_ENV_PARAMETERS_ARB                  0x88B5
        PROGRAM_UNDER_NATIVE_LIMITS_ARB                 0x88B6

        PROGRAM_ALU_INSTRUCTIONS_ARB                    0x8805
        PROGRAM_TEX_INSTRUCTIONS_ARB                    0x8806
        PROGRAM_TEX_INDIRECTIONS_ARB                    0x8807
        PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB             0x8808
        PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB             0x8809
        PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB             0x880A
        MAX_PROGRAM_ALU_INSTRUCTIONS_ARB                0x880B
        MAX_PROGRAM_TEX_INSTRUCTIONS_ARB                0x880C
        MAX_PROGRAM_TEX_INDIRECTIONS_ARB                0x880D
        MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB         0x880E
        MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB         0x880F
        MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB         0x8810

    Accepted by the <pname> parameter of GetProgramStringARB:

        PROGRAM_STRING_ARB                              0x8628

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

        PROGRAM_ERROR_POSITION_ARB                      0x864B
        CURRENT_MATRIX_ARB                              0x8641
        TRANSPOSE_CURRENT_MATRIX_ARB                    0x88B7
        CURRENT_MATRIX_STACK_DEPTH_ARB                  0x8640
        MAX_PROGRAM_MATRICES_ARB                        0x862F
        MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB              0x862E

        MAX_TEXTURE_COORDS_ARB                          0x8871
        MAX_TEXTURE_IMAGE_UNITS_ARB                     0x8872

    Accepted by the <name> parameter of GetString:

        PROGRAM_ERROR_STRING_ARB                        0x8874

    Accepted by the <mode> parameter of MatrixMode:
    
        MATRIX0_ARB                                     0x88C0
        MATRIX1_ARB                                     0x88C1
        MATRIX2_ARB                                     0x88C2
        MATRIX3_ARB                                     0x88C3
        MATRIX4_ARB                                     0x88C4
        MATRIX5_ARB                                     0x88C5
        MATRIX6_ARB                                     0x88C6
        MATRIX7_ARB                                     0x88C7
        MATRIX8_ARB                                     0x88C8
        MATRIX9_ARB                                     0x88C9
        MATRIX10_ARB                                    0x88CA
        MATRIX11_ARB                                    0x88CB
        MATRIX12_ARB                                    0x88CC
        MATRIX13_ARB                                    0x88CD
        MATRIX14_ARB                                    0x88CE
        MATRIX15_ARB                                    0x88CF
        MATRIX16_ARB                                    0x88D0
        MATRIX17_ARB                                    0x88D1
        MATRIX18_ARB                                    0x88D2
        MATRIX19_ARB                                    0x88D3
        MATRIX20_ARB                                    0x88D4
        MATRIX21_ARB                                    0x88D5
        MATRIX22_ARB                                    0x88D6
        MATRIX23_ARB                                    0x88D7
        MATRIX24_ARB                                    0x88D8
        MATRIX25_ARB                                    0x88D9
        MATRIX26_ARB                                    0x88DA
        MATRIX27_ARB                                    0x88DB
        MATRIX28_ARB                                    0x88DC
        MATRIX29_ARB                                    0x88DD
        MATRIX30_ARB                                    0x88DE
        MATRIX31_ARB                                    0x88DF


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

    Modify Section 2.1.1, Floating-Point Computation (p. 6)

    (modify first paragraph, p. 6) ... The maximum representable 
    magnitude of a floating-point number used to represent position,
    normal, or texture coordinates must be at least 2^32; the maximum
    representable magnitude for colors must be at least 2^10.  ...


    Modify Section 2.7, Vertex Specification (p. 19)

    (modify second paragraph, p. 20) Implementations support more than
    one set of texture coordinates.  The commands

      void MultiTexCoord{1234}{sifd}(enum texture, T coords);
      void MultiTexCoord{1234}{sifd}v(enum texture, T coords);

    take the coordinate set to be modified as the <texture> parameter.
    <texture> is a symbolic constant of the form TEXTUREi, indicating
    that texture coordinate set i is to be modified.  The constants obey
    TEXTUREi = TEXTURE0 + i (i is in the range 0 to k-1, where k is the
    implementation-dependent number of texture units defined by
    MAX_TEXTURE_COORDS_ARB).


    Modify Section 2.8, Vertex Arrays (p. 21)

    (modify first paragraph, p. 21) ... The client may specify up to 5
    plus the value of MAX_TEXTURE_COORDS_ARB arrays: one each to store
    vertex coordinates...


    (modify first paragraph, p. 23) The command

      void ClientActiveTexture(enum texture);

    is used to select the vertex array client state parameters to be
    modified by the TexCoordPointer command and the array affected by
    EnableClientState and DisableClientState with parameter
    TEXTURE_COORD_ARRAY.  This command sets the client state variable
    CLIENT_ACTIVE_TEXTURE.  Each texture coordinate set has a client 
    state vector which is selected when this command is invoked.  This
    state vector includes the vertex array state.  This call also 
    selects the texture coordinate set state used for queries of client
    state.


    (modify first paragraph, p. 28) If the number of supported texture
    coordinate sets (the value of MAX_TEXTURE_COORDS_ARB) is k, ...


    Modify Section 2.10.2, Matrices (p. 31)

    (modify first paragraph, p. 31) The projection matrix and model-view 
    matrix are set and modified with a variety of commands.  The 
    affected matrix is determined by the current matrix mode.  The 
    current matrix mode is set with

      void MatrixMode(enum mode);

    which takes one of the pre-defined constants TEXTURE, MODELVIEW, 
    COLOR, PROJECTION, or MATRIX<i>_ARB as the argument.  In the case of
    MATRIX<i>_ARB, <i> is an integer between 0 and <n>-1 indicating one 
    of <n> program matrices where <n> is the value of the implementation 
    defined constant MAX_PROGRAM_MATRICES_ARB.  Such program matrices 
    are described in section 3.11.7.  TEXTURE is described later in 
    section 2.10.2, and COLOR is described in section 3.6.3.  If the 
    current matrix mode is MODELVIEW, then matrix operations apply to 
    the model-view matrix; if PROJECTION, then they apply to the 
    projection matrix.


    (modify first paragraph, p. 34) For each texture coordinate set, a
    4x4 matrix is applied to the corresponding texture coordinates...


    (modify first and second paragraphs, p. 35) The command

      void ActiveTexture(enum texture);

    specifies the active texture unit selector, ACTIVE_TEXTURE.  Each
    texture unit contains up to two distinct sub-units: a texture 
    coordinate processing unit (consisting of a texture matrix stack and
    texture coordinate generation state) and a texture image unit
    (consisting of all the texture state defined in Section 3.8).  In
    implementations with a different number of supported texture 
    coordinate sets and texture image units, some texture units may
    consist of only one of the two sub-units.

    The active texture unit selector specifies the texture coordinate 
    set accessed by commands involving texture coordinate processing.  
    Such commands include those accessing the current matrix stack (if 
    MATRIX_MODE is TEXTURE), TexGen (section 2.10.4), Enable/Disable (if 
    any texture coordinate generation enum is selected), as well as 
    queries of the current texture coordinates and current raster 
    texture coordinates.  If the texture coordinate set number 
    corresponding to the current value of ACTIVE_TEXTURE is greater than 
    or equal to the implementation-dependent constant 
    MAX_TEXTURE_COORDS_ARB, the error INVALID_OPERATION is generated by 
    any such command.

    The active texture unit selector also selects the texture image unit
    accessed by commands involving texture image processing (section 
    3.8).  Such commands include all variants of TexEnv, TexParameter,
    and TexImage commands, BindTexture, Enable/Disable for any texture
    target (e.g., TEXTURE_2D), and queries of all such state.  If the
    texture image unit number corresponding to the current value of 
    ACTIVE_TEXTURE is greater than or equal to the implementation-
    dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB, the error
    INVALID_OPERATION is generated by any such command.

    ActiveTexture generates the error INVALID_ENUM if an invalid 
    <texture> is specified.  <texture> is a symbolic constant of the 
    form TEXTUREi, indicating that texture unit i is to be modified.  
    The constants obey TEXTUREi = TEXTURE0 + i (i is in the range 0 to
    k-1, where k is the larger of the MAX_TEXTURE_COORDS_ARB and
    MAX_TEXTURE_IMAGE_UNITS_ARB).  For compatibility with old OpenGL
    specifications, the implementation-dependent constant 
    MAX_TEXTURE_UNITS specifies the number of conventional texture units 
    supported by the implementation.  Its value must be no larger than 
    the minimum of MAX_TEXTURE_COORDS_ARB and 
    MAX_TEXTURE_IMAGE_UNITS_ARB.
    

    (modify last paragraph, p. 35) The state required to implement
    transformations consists of a <n>-value integer indicating the 
    current matrix mode (where <n> is 4 + the number of supported 
    texture and program matrices), a stack of at least two 4x4 matrices 
    for each of COLOR, PROJECTION, and TEXTURE with associated stack 
    pointers, <n> stacks (where <n> is at least 8) of at least one 4x4 
    matrix for each MATRIX<i>_ARB with associated stack pointers, and a 
    stack of at least 32 4x4 matrices with an associated stack pointer 
    for MODELVIEW.  Initially, there is only one matrix on each stack, 
    and all matrices are set to the identity.  The initial matrix mode 
    is MODELVIEW.  The initial value of ACTIVE_TEXTURE is TEXTURE0.


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

    Modify Chapter 3, Introduction (p. 58)

    (modify first paragraph, p. 58) ... Figure 3.1 diagrams the 
    rasterization process.  The color value assigned to a fragment is
    initially determined by the rasterization operations (sections 3.3
    through 3.7) and modified by either the execution of the texturing,
    color sum, and fog operations as defined in sections 3.8, 3.9, and
    3.10, or of a fragment program defined in section 3.11.  The final
    depth value is initially determined by the rasterization operations
    and may be modified or replaced by a fragment program.

    (modify Figure 3.1)

                 _ +---------------+   FRAGMENT_PROGRAM_ARB
                 /||    Point      |          enable
                /  | Rasterization |\           |
               /   +---------------+ \          V  o-------------+
       From   /    +---------------+  \                          |
    Primitive ---> |     Line      |---+++--->o    o             |
     Assembly \    | Rasterization |  / ||         |             |
               \   +---------------+ /  ||         |             |
                \  +---------------+/   ||   +-----+-----+  +----+-----+
                 \||    Polygon    |    ||   | Texturing |  | Fragment |
                 - | Rasterization |   / |   +-----+-----+  | Program  |
                   +---------------+  /  |         |        +----+-----+
                   +---------------+ /   |   +-----+-----+       |
                   |     Pixel     |/    |   | Color Sum |       |
    DrawPixels --> |   Rectangle   |    /    +-----+-----+       |
                   | Rasterization |   /           |             V
                   +---------------+  /      +-----+-----+
                   +---------------+ /       |    Fog    |---> Fragments
      Bitmap ----> |    Bitmap     |/        +-----------+
                   | Rasterization |
                   +---------------+


    Modify Section 3.3, Points (p. 63)

    (modify first and second paragraphs, p. 64) All fragments produced
    in rasterizing a non-antialiased point are assigned the same
    associated data, which are those of the vertex corresponding to the
    point.  (delete reference to divide by q)

    If antialiasing is enabled, then ...  The data associated with each 
    fragment are otherwise the data associated with the point being 
    rasterized.  (delete reference to divide by q)
    

    Modify Section 3.4.1, Basic Line Segment Rasterization (p. 66)

    (modify first paragraph, p. 68) ... (Note that t=0 at p_a and t=1 at
    p_b).  The value of an associated datum f from the fragment center,
    whether it be R, G, B, or A (in RGBA mode) or a color index (in 
    color index mode) or the s, t, r, or q texture coordinate or the 
    clip w coordinate (the depth value, window z, must be found using
    equation 3.3, below), is found as

      f = (1-t)*(f_a/w_a) + t*(f_b/w_b)                     (3.2)
          -----------------------------
            (1-t)*(1/w_a) + t*(1/w_b)

    where f_a and f_b are the data associated with the starting and 
    ending endpoints of the segment, respectively; w_a and w_b are the 
    clip w coordinates of the starting and ending endpoints of the 
    segments, respectively.  Note that linear interpolation would use

      f = (1-t)*f_a + t*f_b.                                (3.3)

    ... A GL implementation may choose to approximate equation 3.2 with
    3.3, but this will normally lead to inacceptable distortion effects
    when interpolating texture coordinates or clip w coordinates.


    Modify Section 3.5.1, Basic Polygon Rasterization (p. 73)

    (modify third and fourth paragraphs, p. 74) Denote a datum at p_a, 
    p_b, or p_c as f_a, f_b, or f_c, respectively.  Then the value f of 
    a datum at a fragment produced by rasterizing a triangle is given by

      f = a*(f_a/w_a) + b*(f_b/w_b) + c*(f_c/w_c)           (3.4)
          ---------------------------------------
             a*(1/w_a) + b*(1/w_b) + c*(1/w_c)

    where w_a, w_b, and w_c are the clip w coordinates of p_a, p_b, and
    p_c, respectively.  a, b, and c are the barycentric coordinates of
    the fragment for which the data are produced.  a, b, and c must
    correspond precisely to the ... at the fragment's center.

    Just as with line segment rasterization, equation 3.4 may be
    approximated by

      f = a*f_a + b*f_b + c*f_c;

    this may yield ... for texture coordinates or clip w coordinates.


    Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 91)

    (modify third paragraph, p. 103) A fragment arising from a group ...
    the color and texture coordinates are given by those associated with 
    the current raster position.  (delete reference to divide by q)
    Groups arising from DrawPixels...  


    Modify Section 3.7, Bitmaps (p. 113)

    (modify third paragraph, p. 114) Otherwise, a rectangular array ...
    The associated data for each fragment are those associated with the
    current raster position.  (delete reference to divide by q)  Once
    the fragments have been produced ...


    Modify Section 3.8, Texturing (p. 115)

    (add new paragraphs before first paragraph, p. 115) Texture 
    coordinate sets are mapped to RGBA colors for application to 
    primitives in one of two modes.  The first mode, described in this 
    and subsequent sections, is GL's conventional multitexture pipeline, 
    describing texture environment and texture application.  The second 
    mode, referred to as fragment program mode and described in section 
    3.11, applies textures, color sum, and fog as specified in an 
    application-supplied fragment program.

    The fragment program mode is enabled and disabled using the generic 
    Enable and Disable commands, respectively, with the symbolic 
    constant FRAGMENT_PROGRAM_ARB.  The required state is one bit 
    indicating whether the fragment program mode is enabled or disabled.
    In the initial state, the fragment program mode is disabled.  When
    fragment program mode is enabled, texturing, color sum, and fog
    application stages are ignored and a general purpose program is
    executed instead.

    (modify first and second paragraph, p. 115) Conventional texturing 
    is employed when fragment program mode is disabled.  Texturing maps 
    ... color of an image at the location indicated by a fragment's 
    texture coordinates to modify the fragment's primary RGBA color.  
    Texturing does not affect the secondary color.

    An implementation may support texturing using more than one image at
    a time.  In this case the fragment carries multiple sets of texture
    coordinates which are used to index ... 

    (add paragraph before 1st paragraph, p. 116) Except when in fragment
    program mode (section 3.11), the (s,t,r) texture coordinates used
    for texturing are the values s/q, t/q, and r/q, respectively, where
    s, t, r, and q are the texture coordinates associated with the
    fragment.  When in fragment program mode, the (s,t,r) texture
    coordinates are specified by the program.  If q is less than or
    equal to zero, the results of texturing are undefined.


    Modify Section 3.8.7, Texture Minification (p. 135)

    (add new paragraph after first paragraph, p. 137) When fragment 
    program mode is enabled, the derivatives of the coordinates may be 
    ill-defined or non-existent.  As a result, the implementation is 
    free to approximate these derivatives with such techniques as 
    differencing.  The only requirement is that texture samples be 
    equivalent across the two modes.  In other words, the texture sample 
    chosen for a fragment of a primitive must be invariant between 
    fragment program mode and conventional mode subject to the rules
    set forth in Appendix A, Invariance.


    Modify Section 3.8.13, Texture Application (p. 149)

    (modify fourth paragraph, p. 152) Texturing is enabled and disabled
    individually for each texture unit.  If texturing is disabled for
    one of the units, then the fragment resulting from the previous unit
    is passed unaltered to the following unit.  Individual texture units
    beyond those specified by MAX_TEXTURE_UNITS may be incomplete and 
    are always treated as disabled.


    Insert a new Section 3.11, (p. 154), between existing sections 3.10 
    and 3.11.  Renumber 3.11, Antialiasing Application, to 3.12.

    3.11  Fragment Programs

    The conventional GL texturing model described in section 3.8 is a
    configurable but essentially hard-wired sequence of per-fragment
    computations based on a canonical set of per-fragment parameters
    and texturing-related state such as texture images, texture 
    parameters, and texture environment parameters.  The general success 
    and utility of the conventional GL texturing model reflects its 
    basic correspondence to the typical texturing requirements of 3D 
    applications.

    However when the conventional GL texturing model is not sufficient, 
    the fragment program mode provides a substantially more flexible
    model for generating fragment colors.  The fragment program mode 
    permits applications to define their own fragment programs.

    A fragment program is a character string that specifies a sequence 
    of operations to perform.  Fragment program instructions are 
    typically 4-component vector operations that operate on per-fragment 
    attributes and program parameters.  Fragment programs execute on a 
    per-fragment basis and operate on each fragment completely 
    independently from any other fragments.  Fragment programs execute a 
    finite fixed sequence of instructions with no branching or looping.  
    Fragment programs execute without data hazards so results computed 
    in one instruction can be used immediately afterwards.  The result 
    of a fragment program is a set of fragment result registers that 
    becomes the color used by antialiasing application and/or a depth 
    value used in place of the interpolated depth value generated by 
    conventional rasterization.

    In fragment program mode, the color sum is subsumed by the fragment
    program.  An application desiring the primary and secondary colors
    to be summed must explicitly include this operation in its program.

    Fragment programs are defined to operate only in RGBA mode.  The 
    results of fragment program execution are undefined if the GL is in 
    color index mode.


    3.11.1  Program Objects

    The GL provides one or more program targets, each identifying a 
    portion of the GL that can be controlled through application-
    specified programs.  The program target for fragment programs is 
    FRAGMENT_PROGRAM_ARB.  Each program target has an associated program 
    object, called the current program object.  Each program target also 
    has a default program object, which is initially the current program 
    object.

    Each program object has an associated program string.  The command

      ProgramStringARB(enum target, enum format, sizei len, 
                       const void *string);

    updates the program string for the current program object for 
    <target>.  <format> describes the format of the program string, 
    which must currently be PROGRAM_FORMAT_ASCII_ARB.  <string> is a 
    pointer to the array of bytes representing the program string being 
    loaded, which need not be null-terminated.  The length of the array 
    is given by <len>.  If <string> is null-terminated, <len> should not 
    include the terminator.

    When a program string is loaded, it is interpreted according to 
    syntactic and semantic rules corresponding to the program target 
    specified by <target>.  If a program violates the syntactic or 
    semantic restrictions of the program target, ProgramStringARB 
    generates the error INVALID_OPERATION.  An implementation may also
    generate the error INVALID_OPERATION if the program would exceed
    the native resource limits defined in section 6.1.12.  A program
    which fails to load due to exceeding native resource limits must
    always fail, regardless of any other GL state.

    Additionally, ProgramString will update the program error position
    (PROGRAM_ERROR_POSITION_ARB) and error string 
    (PROGRAM_ERROR_STRING_ARB).  If a program fails to load, the value 
    of the program error position is set to the ubyte offset into the 
    specified program string indicating where the first program error 
    was detected.  If the program fails to load because of a semantic 
    restriction that is not detected until the program is fully 
    scanned, the error position is set to the value of <len>.  If a
    program loads successfully, the error position is set to the value
    negative one.  The implementation-dependent program error string 
    contains one or more error or warning messages.  If a program loads 
    succesfully, the error string may either contain warning messages or 
    be empty.

    Each program object has an associated array of program local 
    parameters.  The number and type of program local parameters is 
    target- and implementation-dependent.  For fragment programs, 
    program local parameters are four-component floating-point vectors.  
    The number of vectors is given by the implementation-dependent 
    constant MAX_PROGRAM_LOCAL_PARAMETERS_ARB, which must be at least 
    24.  The commands

      void ProgramLocalParameter4fARB(enum target, uint index,
                                      float x, float y, float z, float w);
      void ProgramLocalParameter4fvARB(enum target, uint index, 
                                       const float *params);
      void ProgramLocalParameter4dARB(enum target, uint index,
                                      double x, double y, double z, double w);
      void ProgramLocalParameter4dvARB(enum target, uint index, 
                                       const double *params);

    update the values of the program local parameter numbered <index>
    belonging to the program object currently bound to <target>.  For
    ProgramLocalParameter4fARB and ProgramLocalParameter4dARB, the four
    components of the parameter are updated with the values of <x>, <y>, 
    <z>, and <w>, respectively.  For ProgramLocalParameter4fvARB and
    ProgramLocalParameter4dvARB, the four components of the parameter 
    are updated with the array of four values pointed to by <params>.  
    The error INVALID_VALUE is generated if <index> is greater than or 
    equal to the number of program local parameters supported by 
    <target>.

    Additionally, each program target has an associated array of program 
    environment parameters.  Unlike program local parameters, program
    environment parameters are shared by all program objects of a given 
    target.  The number and type of program environment parameters is 
    target- and implementation-dependent.  For fragment programs, 
    program environment parameters are four-component floating-point 
    vectors.  The number of vectors is given by the implementation-
    dependent constant MAX_PROGRAM_ENV_PARAMETERS_ARB, which must be at 
    least 24.  The commands

      void ProgramEnvParameter4fARB(enum target, uint index,
                                    float x, float y, float z, float w);
      void ProgramEnvParameter4fvARB(enum target, uint index,
                                     const float *params);
      void ProgramEnvParameter4dARB(enum target, uint index,
                                    double x, double y, double z, double w);
      void ProgramEnvParameter4dvARB(enum target, uint index,
                                     const double *params);

    update the values of the program environment parameter numbered 
    <index> for the given program target <target>.  For 
    ProgramEnvParameter4fARB and ProgramEnvParameter4dARB, the four 
    components of the parameter are updated with the values of <x>, <y>, 
    <z>, and <w>, respectively.  For ProgramEnvParameter4fvARB and 
    ProgramEnvParameter4dvARB, the four components of the parameter are 
    updated with the array of four values pointed to by <params>.  The 
    error INVALID_VALUE is generated if <index> is greater than or equal 
    to the number of program environment parameters supported by 
    <target>.

    Each program target has a default program object.  Additionally, 
    named program objects can be created and operated upon.  The name 
    space for program objects is the positive integers and is shared by 
    programs of all targets.  The name zero is reserved by the GL.

    A named program object is created by binding an unused program 
    object name to a valid program target.  The binding is effected by 
    calling 

      BindProgramARB(enum target, uint program);

    with <target> set to the desired program target and <program> set to 
    the unused program name.  The resulting program object has a program 
    target given by <target> and is assigned target-specific default 
    values (see section 3.11.8 for fragment programs).  BindProgramARB 
    may also be used to bind an existing program object to a program 
    target.  If <program> is zero, the default program object for 
    <target> is bound.  If <program> is the name of an existing program
    object whose associated program target is <target>, the named 
    program object is bound.  The error INVALID_OPERATION is generated 
    if <program> names an existing program object whose associated 
    program target is anything other than <target>.

    Programs objects are deleted by calling

      void DeleteProgramsARB(sizei n, const uint *programs);

    <programs> contains <n> names of programs to be deleted.  After a 
    program object is deleted, its name is again unused.  If a program 
    object that is bound to any target is deleted, it is as though 
    BindProgramARB is first executed with same target and a <program> of 
    zero.  Unused names in <programs> are silently ignored, as is the 
    value zero.

    The command

      void GenProgramsARB(sizei n, uint *programs);

    returns <n> currently unused program names in <programs>.  These 
    names are marked as used, for the purposes of GenProgramsARB only, 
    but objects are created only when they are first bound using 
    BindProgramARB.


    3.11.2  Fragment Program Grammar and Semantic Restrictions

    Fragment program strings are specified as an array of ASCII 
    characters containing the program text.  When a fragment 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 fragment programs.  The set of valid tokens can 
    be inferred from the grammar.  The token "" represents an empty 
    string and is used to indicate optional rules.  A program is invalid 
    if it contains any undefined tokens or characters.

    A fragment program is required to begin with the header string 
    "!!ARBfp1.0", without any preceding whitespace.  This string 
    identifies the subsequent program text as a fragment program 
    (version 1.0) that should be parsed according to the following 
    grammar and semantic rules.  Program string parsing begins with the 
    character immediately following the header string.

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

    <optionSequence>       ::= <optionSequence> <option>
                             | ""

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

    <statementSequence>    ::= <statementSequence> <statement>
                             | ""

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

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

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

    <TexInstruction>       ::= <SAMPLE_instruction>
                             | <KIL_instruction>

    <VECTORop_instruction> ::= <VECTORop> <maskedDstReg> "," 
                               <vectorSrcReg>

    <VECTORop>             ::= "ABS" | "ABS_SAT"
                             | "FLR" | "FLR_SAT"
                             | "FRC" | "FRC_SAT"
                             | "LIT" | "LIT_SAT"
                             | "MOV" | "MOV_SAT"

    <SCALARop_instruction> ::= <SCALARop> <maskedDstReg> ","  
                               <scalarSrcReg> 
 
    <SCALARop>             ::= "COS" | "COS_SAT"
                             | "EX2" | "EX2_SAT"
                             | "LG2" | "LG2_SAT"
                             | "RCP" | "RCP_SAT"
                             | "RSQ" | "RSQ_SAT"
                             | "SIN" | "SIN_SAT"
                             | "SCS" | "SCS_SAT"
 
    <BINSCop_instruction>  ::= <BINSCop> <maskedDstReg> "," 
                               <scalarSrcReg> "," <scalarSrcReg> 

    <BINSCop>              ::= "POW" | "POW_SAT"
 
    <BINop_instruction>    ::= <BINop> <maskedDstReg> ","
                               <vectorSrcReg> "," <vectorSrcReg>

    <BINop>                ::= "ADD" | "ADD_SAT"
                             | "DP3" | "DP3_SAT"
                             | "DP4" | "DP4_SAT"
                             | "DPH" | "DPH_SAT"
                             | "DST" | "DST_SAT"
                             | "MAX" | "MAX_SAT"
                             | "MIN" | "MIN_SAT"
                             | "MUL" | "MUL_SAT"
                             | "SGE" | "SGE_SAT"
                             | "SLT" | "SLT_SAT"
                             | "SUB" | "SUB_SAT"
                             | "XPD" | "XPD_SAT"

    <TRIop_instruction>    ::= <TRIop> <maskedDstReg> ","
                               <vectorSrcReg> "," <vectorSrcReg> ","
                               <vectorSrcReg>

    <TRIop>                ::= "CMP" | "CMP_SAT"
                             | "LRP" | "LRP_SAT"
                             | "MAD" | "MAD_SAT"

    <SWZ_instruction>      ::= <SWZop> <maskedDstReg> "," 
                               <srcReg> "," <extendedSwizzle>

    <SWZop>                ::= "SWZ" | "SWZ_SAT"

    <SAMPLE_instruction>   ::= <SAMPLEop> <maskedDstReg> ","
                               <vectorSrcReg> "," <texImageUnit> "," 
                               <texTarget>

    <SAMPLEop>             ::= "TEX" | "TEX_SAT"
                             | "TXP" | "TXP_SAT"
                             | "TXB" | "TXB_SAT"

    <KIL_instruction>      ::= "KIL" <vectorSrcReg>

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

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

    <optTexImageUnitNum>   ::= ""
                             | "[" <texImageUnitNum> "]"

    <texImageUnitNum>      ::= <integer> from 0 to 
                               MAX_TEXTURE_IMAGE_UNITS_ARB-1

    <scalarSrcReg>         ::= <optionalSign> <srcReg> <scalarSuffix>

    <vectorSrcReg>         ::= <optionalSign> <srcReg> <optionalSuffix> 
 
    <maskedDstReg>         ::= <dstReg> <optionalMask>

    <extendedSwizzle>      ::= <xyzwExtendedSwizzle>
                             | <rgbaExtendedSwizzle>

    <xyzwExtendedSwizzle>  ::= <xyzwExtSwizComp> "," <xyzwExtSwizComp> "," 
                               <xyzwExtSwizComp> "," <xyzwExtSwizComp>

    <rgbaExtendedSwizzle>  ::= <rgbaExtSwizComp> "," <rgbaExtSwizComp> "," 
                               <rgbaExtSwizComp> "," <rgbaExtSwizComp>

    <xyzwExtSwizComp>      ::= <optionalSign> <xyzwExtSwizSel>

    <rgbaExtSwizComp>      ::= <optionalSign> <rgbaExtSwizSel>

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

    <rgbaExtSwizSel>       ::= "0" 
                             | "1" 
                             | <rgbaComponent>

    <srcReg>               ::= <fragmentAttribReg>
                             | <temporaryReg>
                             | <progParamReg>

    <dstReg>               ::= <temporaryReg>
                             | <fragmentResultReg>

    <fragmentAttribReg>    ::= <establishedName>
                             | <fragAttribBinding>

    <temporaryReg>         ::= <establishedName>

    <progParamReg>         ::= <progParamSingle>
                             | <progParamArray> "[" <progParamArrayAbs> "]"
                             | <paramSingleItemUse>

    <progParamSingle>      ::= <establishedName>

    <progParamArray>       ::= <establishedName>

    <progParamArrayAbs>    ::= <integer>

    <fragmentResultReg>    ::= <establishedName>
                             | <resultBinding>

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

    <optionalSuffix>       ::= "" 
                             | "." <component> 
                             | "." <xyzwComponent> <xyzwComponent>
                                   <xyzwComponent> <xyzwComponent>
                             | "." <rgbaComponent> <rgbaComponent>
                                   <rgbaComponent> <rgbaComponent>
 
    <component>            ::= <xyzwComponent>
                             | <rgbaComponent>

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

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

    <optionalMask>         ::= ""
                             | <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"

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

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

    <fragAttribBinding>    ::= "fragment" "." <fragAttribItem>

    <fragAttribItem>       ::= "color" <optColorType>
                             | "texcoord" <optTexCoordNum>
                             | "fogcoord"
                             | "position"

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

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

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

    <optArraySize>         ::= ""
                             | <integer> from 1 to MAX_PROGRAM_PARAMETERS_ARB
                                 (maximum number of allowed program 
                                  parameter bindings)

    <paramSingleInit>      ::= "=" <paramSingleItemDecl>

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

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

    <paramSingleItemDecl>  ::= <stateSingleItem>
                             | <programSingleItem>
                             | <paramConstDecl>

    <paramSingleItemUse>   ::= <stateSingleItem>
                             | <programSingleItem>
                             | <paramConstUse>

    <paramMultipleItem>    ::= <stateMultipleItem>
                             | <programMultipleItem>
                             | <paramConstDecl>

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

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

    <stateMaterialItem>    ::= "material" <optFaceType> "." <stateMatProperty>

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

    <stateLightItem>       ::= "light" "[" <stateLightNumber> "]" "." 
                                 <stateLightProperty>

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

    <stateSpotProperty>    ::= "direction" 

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

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

    <stateLightProdItem>   ::= "lightprod" "[" <stateLightNumber> "]"
                                 <optFaceType> "." <stateLProdProperty>

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

    <stateLightNumber>     ::= <integer> from 0 to MAX_LIGHTS-1

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

    <stateTexEnvProperty>  ::= "color"

    <optLegacyTexUnitNum>  ::= ""
                             | "[" <legacyTexUnitNum> "]"

    <legacyTexUnitNum>     ::= <integer> from 0 to MAX_TEXTURE_UNITS-1

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

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

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

    <stateDepthProperty>   ::= "range" 

    <stateMatrixRow>       ::= <stateMatrixItem> "." "row" "[" 
                                  <stateMatrixRowNum> "]"

    <stateMatrixRows>      ::= <stateMatrixItem> <optMatrixRows>

    <optMatrixRows>        ::= ""
                             | "." "row" "[" <stateMatrixRowNum> ".." 
                                  <stateMatrixRowNum> "]"

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

    <stateOptMatModifier>  ::= ""
                             | "." <stateMatModifier>

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

    <stateMatrixRowNum>    ::= <integer> from 0 to 3

    <stateMatrixName>      ::= "modelview" <stateOptModMatNum>
                             | "projection"
                             | "mvp"
                             | "texture" <optTexCoordNum>
                             | "palette" "[" <statePaletteMatNum> "]"
                             | "program" "[" <stateProgramMatNum> "]"
                             
    <stateOptModMatNum>    ::= ""
                             | "[" <stateModMatNum> "]"

    <stateModMatNum>       ::= <integer> from 0 to MAX_VERTEX_UNITS_ARB-1

    <optTexCoordNum>       ::= ""
                             | "[" <texCoordNum> "]"

    <texCoordNum>          ::= <integer> from 0 to MAX_TEXTURE_COORDS_ARB-1

    <statePaletteMatNum>   ::= <integer> from 0 to MAX_PALETTE_MATRICES_ARB-1

    <stateProgramMatNum>   ::= <integer> from 0 to MAX_PROGRAM_MATRICES_ARB-1

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

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

    <progEnvParams>        ::= "program" "." "env" 
                                 "[" <progEnvParamNums> "]"

    <progEnvParamNums>     ::= <progEnvParamNum>
                             | <progEnvParamNum> ".." <progEnvParamNum>

    <progEnvParam>         ::= "program" "." "env" 
                                 "[" <progEnvParamNum> "]"

    <progLocalParams>      ::= "program" "." "local" 
                                 "[" <progLocalParamNums> "]"

    <progLocalParamNums>   ::= <progLocalParamNum>
                             | <progLocalParamNum> ".." <progLocalParamNum>

    <progLocalParam>       ::= "program" "." "local" 
                                 "[" <progLocalParamNum> "]"

    <progEnvParamNum>      ::= <integer> from 0 to
                               MAX_PROGRAM_ENV_PARAMETERS_ARB - 1 

    <progLocalParamNum>    ::= <integer> from 0 to
                               MAX_PROGRAM_LOCAL_PARAMETERS_ARB - 1 

    <paramConstDecl>       ::= <paramConstScalarDecl>
                             | <paramConstVector>

    <paramConstUse>        ::= <paramConstScalarUse>
                             | <paramConstVector>

    <paramConstScalarDecl> ::= <signedFloatConstant>

    <paramConstScalarUse>  ::= <floatConstant>

    <paramConstVector>     ::= "{" <signedFloatConstant> "}"
                             | "{" <signedFloatConstant> "," 
                                   <signedFloatConstant> "}"
                             | "{" <signedFloatConstant> "," 
                                   <signedFloatConstant> ","
                                   <signedFloatConstant> "}"
                             | "{" <signedFloatConstant> "," 
                                   <signedFloatConstant> ","
                                   <signedFloatConstant> "," 
                                   <signedFloatConstant> "}"

    <signedFloatConstant>  ::= <optionalSign> <floatConstant>

    <floatConstant>        ::= see text

    <optionalSign>         ::= ""
                             | "-"
                             | "+"

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

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

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

    <resultBinding>        ::= "result" "." "color"
                             | "result" "." "depth"

    <optFaceType>          ::= ""
                             | "." "front"
                             | "." "back"

    <optColorType>         ::= ""
                             | "." "primary"
                             | "." "secondary"

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

    <establishName>        ::= <identifier>

    <establishedName>      ::= <identifier>

    <identifier>           ::= see text

    The <integer> rule matches an integer constant.  The integer 
    consists of a sequence of one or more digits ("0" through "9").

    The <floatConstant> 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.

    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, ABS_SAT, ADD, ADD_SAT, ALIAS, ATTRIB, CMP, CMP_SAT, COS,
        COS_SAT, DP3, DP3_SAT, DP4, DP4_SAT, DPH, DPH_SAT, DST, DST_SAT, 
        END, EX2, EX2_SAT, FLR, FLR_SAT, FRC, FRC_SAT, KIL, LG2, 
        LG2_SAT, LIT, LIT_SAT, LRP, LRP_SAT, MAD, MAD_SAT, MAX, MAX_SAT, 
        MIN, MIN_SAT, MOV, MOV_SAT, MUL, MUL_SAT, OPTION, OUTPUT, PARAM, 
        POW, POW_SAT, RCP, RCP_SAT, RSQ, RSQ_SAT, SIN, SIN_SAT, SCS, 
        SCS_SAT, SGE, SGE_SAT, SLT, SLT_SAT, SUB, SUB_SAT, SWZ, SWZ_SAT, 
        TEMP, TEX, TEX_SAT, TXB, TXB_SAT, TXP, TXP_SAT, XPD, XPD_SAT, 
        fragment, program, result, state, and texture.

    The error INVALID_OPERATION is generated if a fragment 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 fragment 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 3.11.5.

    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.


    3.11.3  Fragment Program Variables

    Fragment programs may access a number of different variables during 
    their execution.  The following sections define the variables that 
    can be declared and used by a fragment program.

    Explicit variable declarations allow a fragment program to establish 
    a variable name that can be used to refer to a specified resource in 
    subsequent instructions.  A fragment 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.

    Implicit variable declarations allow a fragment program to use the 
    name of certain available resources by name.


    3.11.3.1  Fragment Attributes

    Fragment program attribute variables are a set of four-component
    floating-point vectors holding the attributes of the fragment being
    processed.  Fragment attribute variables are read-only during 
    fragment program execution.

    Fragment attribute variables can be declared explicitly using the
    <ATTRIB_statement> grammar rule, or implicitly using the
    <fragAttribBinding> grammar rule in an executable instruction.

    Each fragment attribute variable is bound to a single item of 
    fragment state according to the <fragAttrBinding> grammar rule.  The 
    set of GL state that can be bound to a fragment attribute variable 
    is given in Table X.1.  Fragment attribute variables are initialized 
    at each fragment program invocation with the current values of the 
    bound state.

      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.position           (x,y,z,1/w) window position

      Table X.1:  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.

    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 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 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.position", the "x"
    and "y" components of the fragment attribute variable are filled 
    with the (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.  This 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.


    3.11.3.2  Fragment Program Parameters

    Fragment program parameter variables are a set of four-component
    floating-point vectors used as constants during fragment program 
    execution.  Fragment program parameters retain their values across 
    fragment program invocations, although their values can change 
    between invocations due to GL state changes.

    Single program parameter variables and arrays of program parameter
    variables can be declared explicitly using the <PARAM_statement> 
    grammar rule.  Single program parameter variables can also be 
    declared implicitly using the <paramSingleItemUse> grammar rule in 
    an executable instruction.

    Each single program parameter variable is bound to a constant vector 
    or to a GL state vector according to the <paramSingleInit> grammar 
    rule.  Individual items of a program parameter array are bound to 
    constant vectors or GL state vectors according to the 
    <programMultipleInit> grammar rule.  The set of GL state that can be 
    bound to program parameter variables are given in Tables X.2.1 
    through X.2.4.


    Constant Bindings

    A program parameter variable can be bound to a scalar or vector 
    constant using the <paramConstDecl> grammar rule (explicit 
    declarations) or the <paramConstUse> grammar rule (implicit 
    declarations).

    If a program parameter binding matches the <paramConstScalarDecl> or
    <paramConstScalarUse> 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.  Note that the 
    <paramConstScalarUse> grammar rule, used only in implicit 
    declarations, allows only non-negative constants.  This 
    disambiguates cases like "-2", which could conceivably be taken to 
    mean either the vector "(2,2,2,2)" with all components negated or 
    "(-2,-2,-2,-2)" without negation.  Only the former interpretation is 
    allowed by the grammar.

    If a program parameter binding matches <paramConstVector>, 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 <signedFloatConstant>.  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 parameter variables initialized to constant values can never 
    be modified.


    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.2.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 parameters <a> through <b> in order 
    or program local parameters <a> through <b> in order, respectively.  
    In either case, a program 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.2.2:  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.2.2, 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 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.2.3: 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.  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.2.3).  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 Environment Property Bindings

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

      Table X.2.4:  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.


    Fog Property Bindings

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

      Table X.2.5:  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.11).

    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.11), respectively.  The "w" component is 
    filled with 1/(end-start), where end and start are the linear fog 
    end and start parameters, respectively.


    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.2.6:  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.


    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.palette[n]             modelview palette matrix n
        state.matrix.program[n]             program matrix n

      Table X.2.7:  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.2.7, 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.2.7 is selected.  
    Otherwise, the matrix specified in Table X.2.7 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.


    Program Parameter Arrays

    A program parameter array variable can be declared explicitly by 
    matching the <PARAM_multipleStmt> grammar rule.  Programs can 
    optionally specify the number of individual program parameters in 
    the array, using the <optArraySize> grammar rule.  Program parameter 
    arrays may not be declared implicity.

    Individual parameter variables in a program parameter array are 
    bound to GL state vectors or constant vectors as specified by the 
    grammar rule <paramMultInitList>.  Each individual parameter in the 
    array is bound in turn as described above.  

    The total number of entries in the array is equal to the number of
    parameters bound in the initializer list.  A fragment program that 
    specifies an array size (<optArraySize> matches <integer>) that does 
    not match the number of parameter bindings in the initialization 
    list will fail to load.

    Program parameter array variables may only be accessed using 
    absolute addressing by matching the <progParamArrayAbs> grammar 
    rule.  Array accesses are checked against the limits of the array.  
    If any fragment program instruction accesses a program parameter
    array with an out-of-range index (greater than or equal to the size 
    of the array), the fragment program will fail to load.

    Individual state vectors can have no more than one unique binding in 
    any given program.  The GL will automatically combine multiple 
    bindings of the same state vector into a single unique binding.


    3.11.3.3  Fragment Program Temporaries

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

    Fragment program temporary variables can be declared explicitly 
    using the <TEMP_statement> grammar rule.  Each such statement can 
    declare one or more temporaries.  Fragment program temporary 
    variables can not be declared implicitly.


    3.11.3.4  Fragment Program Results

    Fragment program result variables are a set of four component 
    floating-point vectors used to hold the final results of a fragment 
    program.  Fragment program result variables are write-only during 
    fragment program execution.

    Fragment program result variables can be declared explicitly using 
    the <OUTPUT_statement> grammar rule, or implicitly using the
    <resultBinding> grammar rule in an executable instruction.  Each 
    fragment program result variable is bound to a fragment attribute 
    used in subsequent back-end processing.  The set of fragment program
    result variable bindings is given in Table X.3.

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

      Table X.3:  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.depth", updates to the 
    "z" component of the result variable modify the fragment's output
    depth value.  If "result.depth" is not both bound by the fragment 
    program and written by some instruction of the program, the 
    interpolated depth value produced by rasterization is used as if 
    fragment program mode is not enabled.  Writes to any component of 
    depth other than the "z" component have no effect.


    3.11.3.5  Fragment Program Aliases

    Fragment 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 named "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.


    3.11.3.6  Fragment Program Resource Limits

    The fragment program execution environment provides implementation-
    dependent resource limits on the number of ALU instructions, texture
    instructions, total instructions (ALU or texture), temporary 
    variable declarations, program parameter bindings, or texture
    indirections.  A program that exceeds any of these resource limits 
    will fail to load.  The resource limits for fragment programs can be 
    queried by calling GetProgramiv (section 6.1.12) with a target of 
    FRAGMENT_PROGRAM_ARB.
    
    The limit on fragment program ALU instructions can be queried with 
    a <pname> of MAX_PROGRAM_ALU_INSTRUCTIONS_ARB, and must be at least 
    48.  Each ALU instruction in the program (matches of the 
    <ALUInstruction> grammar rule) counts against this limit.

    The limit on fragment program texture instructions can be queried 
    with a <pname> of MAX_PROGRAM_TEX_INSTRUCTIONS_ARB, and must be at 
    least 24.  Each texture instruction in the program (matches of the 
    <TexInstruction> grammar rule) counts against this limit.

    The limit on fragment program total instructions can be queried with 
    a <pname> of MAX_PROGRAM_INSTRUCTIONS_ARB, and must be at least 72.  
    Each instruction in the program (matching the <instruction> grammar 
    rule) counts against this limit.  Note that the limit on total
    instructions is not necessarily equal to the sum of the limits on
    ALU instructions and texture instructions.

    The limit on fragment program texture indirections can be queried 
    with a <pname> of MAX_PROGRAM_TEX_INDIRECTIONS_ARB, and must be at 
    least 4.  Texture indirections are described in 3.11.6.  If an
    implementation has no limit on texture indirections, the limit will
    be equal to the limit on texture instructions.

    The limit on fragment program temporary variable declarations can be 
    queried with a <pname> of MAX_PROGRAM_TEMPORARIES_ARB, and must be at 
    least 16.  Each temporary declared in the program, using the 
    <TEMP_statement> grammar rule, counts against this limit.  Aliases 
    of declared temporaries do not.
    
    The limit on fragment program attribute bindings can be queried with 
    a <pname> of MAX_PROGRAM_ATTRIBS_ARB and must be at least 10.  Each 
    distinct vertex attribute bound explicitly or implicitly in the 
    program counts against this limit; vertex attributes bound multiple 
    times count only once.

    The limit on fragment program parameter bindings can be queried with 
    a <pname> of MAX_PROGRAM_PARAMETERS_ARB, and must be at least 24.  
    Each distinct GL state vector bound explicitly or implicitly in the 
    program counts against this limit; GL state vectors bound multiple 
    times count only once.  Every other constant vector bound in the 
    program is counted if and only if an identical constant vector has 
    not already been counted.  Two constant vectors are considered 
    identical if the four component values are numerically equivalent.
    Recall that scalar constants bound in a program are treated as 
    vector constants with the scalar value replicated.

    In addition to the limits described above, the GL provides a similar 
    set of implementation-dependent native resource limits.  These 
    limits, specified in Section 6.1.12, provide guidance as to whether 
    the program is small enough to use a "native" mode where fragment 
    programs may be executed with higher performance.  The native 
    resource limits and usage counts are implementation-dependent and 
    may not exactly correspond to limits and counts described above.   
    A program's native resource consumption may be reduced by program 
    optimizations performed by the GL.  Native resource consumption may
    be increased due to emulation of instructions or any other program
    features not natively supported by an implementation.  Notably, an
    additional texture indirection may be consumed due to an 
    implementation's lack of native support for texture instructions 
    with source coordinate swizzles or parameter source coordinates, 
    which may require emulation by prepending ALU instructions.  An 
    implementation may also fail to natively support all combinations of 
    attributes described in Table X.1, even if the total number of
    bound attributes is fewer than the native attribute limit.  In this
    case the program is still considered to exceed the native resource
    limits, as queried by PROGRAM_UNDER_NATIVE_LIMITS_ARB (section 
    6.1.12).

    To assist in resource counting, the GL additionally provides 
    GetProgram queries to determine the resource usage and native 
    resource usage of the currently bound program, and to determine 
    whether the bound program exceeds any native resource limit.

    Programs that exceed any native resource limit may or may not load 
    depending on the implementation.


    3.11.4  Fragment Program Execution Environment

    If fragment program mode is enabled, the currently bound fragment 
    program is executed when any fragment is produced by rasterization.

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

    Fragment programs execute a sequence of instructions without
    branching.  Fragment programs begin by executing the first 
    instruction in the program, and execute instructions in the order 
    specified in the program until the last instruction is completed.
    
    There are 33 fragment program instructions.  The instructions and 
    their respective input and output parameters are summarized in 
    Table X.5.

      Instruction    Inputs  Output   Description
      -----------    ------  ------   --------------------------------
      ABS            v       v        absolute value
      ADD            v,v     v        add
      CMP            v,v,v   v        compare
      COS            s       ssss     cosine with reduction to [-PI,PI]
      DP3            v,v     ssss     3-component dot product
      DP4            v,v     ssss     4-component dot product
      DPH            v,v     ssss     homogeneous dot product
      DST            v,v     v        distance vector
      EX2            s       ssss     exponential base 2
      FLR            v       v        floor
      FRC            v       v        fraction
      KIL            v       v        kill fragment
      LG2            s       ssss     logarithm base 2
      LIT            v       v        compute light coefficients
      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
      POW            s,s     ssss     exponentiate
      RCP            s       ssss     reciprocal
      RSQ            s       ssss     reciprocal square root
      SCS            s       ss--     sine/cosine without reduction
      SGE            v,v     v        set on greater than or equal
      SIN            s       ssss     sine with reduction to [-PI,PI]
      SLT            v,v     v        set on less than
      SUB            v,v     v        subtract
      SWZ            v       v        extended swizzle
      TEX            v,u,t   v        texture sample
      TXB            v,u,t   v        texture sample with bias
      TXP            v,u,t   v        texture sample with projection
      XPD            v,v     v        cross product

      Table X.5:  Summary of fragment program instructions.  "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, "u" indicates a 
      texture image unit identifier, and "t" indicates a texture target.


    3.11.4.1  Fragment Program Operands

    Most fragment program instructions operate on floating-point vectors 
    or scalars, as indicated by the grammar rules <vectorSrcReg> and
    <scalarSrcReg>, respectively.

    Vector and scalar operands can be obtained from fragment attribute, 
    program parameter, or temporary registers, as indicated by the 
    <srcReg> rule.  For scalar operands, a single vector component is 
    selected by the <scalarSuffix> rule, where the characters "x", "y", 
    "z", and "w", or "r", "g", "b", and "a" select the first, second, 
    third, and fourth components, respectively, of the vector.

    Vector operands can be swizzled according to the <optionalSuffix> 
    rule.  In its most general form, the <optionalSuffix> rule matches
    the pattern ".????" where each question mark is replaced with one of
    "x", "y", "z", "w", "r", "g", "b", or "a".  For such patterns, the 
    first, second, third, and fourth components of the operand are taken 
    from the vector components named by the first, second, third, and 
    fourth character of the pattern, respectively.  For example, if the 
    swizzle suffix is ".yzzx" or ".gbbr" and the specified source 
    contains {2,8,9,0}, the swizzled operand used by the instruction is 
    {8,9,9,2}.

    If the <optionalSuffix> rule matches "", it is treated as though it 
    were ".xyzw".  If the <optionalSuffix> rule matches (ignoring 
    whitespace) ".x", ".y", ".z", or ".w", these are treated the same as 
    ".xxxx", ".yyyy", ".zzzz", and ".wwww" respectively.  Likewise, if
    the <optionalSuffix> rule matches ".r", ".g", ".b", or ".a", these 
    are treated the same as ".rrrr", ".gggg", ".bbbb", and ".aaaa" 
    respectively.

    Floating-point scalar or vector operands can optionally be negated
    according to the <optionalSign> rule in <scalarSrcReg> and
    <vectorSrcReg>.  If the <optionalSign> matches "-", each operand or
    operand component is negated.

    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.  "negate" 
    is TRUE if the <optionalSign> rule in <scalarSrcReg> or 
    <vectorSrcReg> 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 (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 (negate) {
            operand = -operand;
          }

          return operand;
      }


    3.11.4.2  Fragment Program Parameter Arrays

    A fragment program can load a single element of a program parameter 
    array using only absolute addressing.  Program parameter arrays are 
    accessed when the <progParamArrayAbs> rule is matched.  The offset 
    of the selected entry in the array is given by the number matching 
    <progParamRegNum>.  If the offset exceeds the size of the 
    array, the results of the access are undefined, but may not lead to
    program or GL termination.


    3.11.4.3  Fragment Program Destination Register Update

    Fragment program instructions write a 4-component result vector to a
    single temporary or fragment result register.  Writes to individual 
    components of the destination register are controlled by individual 
    component write masks specified as part of the instruction.  
    Optional clamping of each component of the destination register to 
    the range [0,1] is controlled by an opcode modifier.

    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", or "r", "g", "b", and "a" match the first, second, third, and 
    fourth 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", or "rgba" order.  Component names from one set (xyzw or 
    rgba) cannot be mixed with component names from another set.  For 
    example, ".rgw" is not a valid writemask.

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

    If the instruction opcode has the "_SAT" suffix, requesting 
    saturated result vectors, each component of the result vector 
    enabled in the writemask is clamped to the range [0,1] before being 
    updated in the destination register.

    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.  
    "clamp" is TRUE if the instruction specifies that the result should
    be clamped.  "result" and "destination" refer to the result vector 
    and the register selected by <dstReg>, respectively.

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

          // Clamp the result vector components to [0,1], if requested.
          if (instrClamp) {
              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-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;
      }


    3.11.4.4  Fragment Program Result Processing

    As a fragment program executes, it will write to either one or two 
    result registers that are mapped to the fragment's color and depth.

    The fragment's color components are first clamped to the range [0,1] 
    then converted to fixed point as in section 2.13.9.  If the fragment
    program does not write result.color, the color will be undefined in 
    subsequent stages.

    If the fragment program contains an instruction to write to
    result.depth, the fragment's depth is replaced by the value of the
    "z" component of result.depth.  This z value is first clamped to the
    range [0,1] then converted to fixed-point as if it were a window z
    value (section 2.10.1).  If the fragment program does not write 
    result.depth, the fragment's original depth is unmodified.


    3.11.4.5  Fragment Program Options

    The <optionSequence> grammar rule provides a mechanism for programs 
    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 interpet the program and the execution 
    environment used to execute the program.  Program options not 
    present in the program string are ignored, even if they are 
    supported by the GL.

    The <identifier> token in the <option> rule must match the name of a
    program option supported by the implementation.  To avoid option 
    name conflicts, option identifiers are required to begin with a 
    vendor prefix.  A program will fail to load if it specifies a 
    program option not supported by the GL.

    Fragment program options should confine their semantic changes to 
    the domain of fragment programs.  Support for a fragment program 
    option should not change the specification and behavior of fragment 
    programs not requesting use of that option.


    3.11.4.5.1  Fog Application Fragment Program Options

    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 clamped 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.


    3.11.4.5.2  Precision Hint Options

    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.


    3.11.5  Fragment Program ALU Instruction Set

    The following sections describe the set of supported fragment 
    program instructions.  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 3.11.4.1.  The variables 
    "tmp", "tmp0", "tmp1", and "tmp2" describe scalars or vectors used 
    to hold intermediate results in the instruction.  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 3.11.4.3.
    

    3.11.5.1  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 = fabs(tmp.x);
      result.y = fabs(tmp.y);
      result.z = fabs(tmp.z);
      result.w = fabs(tmp.w);


    3.11.5.2  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>.


    3.11.5.3  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.0) ? tmp1.x : tmp2.x;
      result.y = (tmp0.y < 0.0) ? tmp1.y : tmp2.y;
      result.z = (tmp0.z < 0.0) ? tmp1.z : tmp2.z;
      result.w = (tmp0.w < 0.0) ? tmp1.w : tmp2.w;
 
   
    3.11.5.4  COS:  Cosine

    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);


    3.11.5.5  DP3:  Three-Component Dot Product

    The DP3 instruction computes a three-component dot product of the 
    two operands (using the first three 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;


    3.11.5.6  DP4:  Four-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;


    3.11.5.7  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;


    3.11.5.8  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-fragment light attenuation
    calculations:  a DP3 operation using the distance vector and an
    attenuation constants vector as operands will yield the attenuation
    factor.


    3.11.5.9  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);


    3.11.5.10  FLR:  Floor

    The FLR instruction performs a component-wise floor operation on the
    operand to generate a result vector.  The floor of a value is 
    defined as the largest integer less than or equal to the value.  The 
    floor of 2.3 is 2.0; the floor of -3.6 is -4.0.

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


    3.11.5.11  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);


    3.11.5.12  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.


    3.11.5.13  LIT:  Light Coefficients

    The LIT instruction accelerates per-fragment lighting 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 EX2 and LG2 instructions, where

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

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

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


    3.11.5.14  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;


    3.11.5.15  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.


    3.11.5.16  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;


    3.11.5.17  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;


    3.11.5.18  MOV:  Move

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

      result = VectorLoad(op0);


    3.11.5.19  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.


    3.11.5.20  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 constrast, 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).


    3.11.5.21  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.


    3.11.5.22  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);


    3.11.5.23  SCS:  Sine/Cosine

    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);

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


    3.11.5.24  SGE:  Set On Greater or Equal Than

    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;


    3.11.5.25  SIN:  Sine

    The SIN instruction approximates the trigonometric sine 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 = ApproxSine(tmp);
      result.y = ApproxSine(tmp);
      result.z = ApproxSine(tmp);
      result.w = ApproxSine(tmp);


    3.11.5.26  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;


    3.11.5.27  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;


    3.11.5.28  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 <xyzwExtSwizComp> or <rgbaExtSwizComp> 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 <xyzwExtSwizSel> rule matching "0", "1", "x", 
    "y", "z", and "w", respectively, or the <rgbaExtSwizSel> rule
    matching "0", 1", "r", "g", "b", and "a", respectively.  "negate" is 
    TRUE if and only if the <optionalSign> rule in <xyzwExtSwizComp> 
    or <rgbaExtSwizComp> 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 <xyzwExtSwizComp> or <rgbaExtSwizComp>
    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.


    3.11.5.29  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;


    3.11.6  Fragment Program Texture Instruction Set

    The first three texture instructions described below specify the 
    mapping of 4-tuple vectors to colors of an image.  The sampling of 
    the texture works as described in section 3.8, except that texture 
    environments and texture functions are not applicable, and the
    texture enables hierarchy is replaced by explicit references to
    the desired texture target (i.e., 1D, 2D, 3D, cube map, rectangle).  
    These texture instructions specify how the 4-tuple is mapped into 
    the coordinates used for sampling.  The following function is used 
    to describe the texture sampling in the descriptions below:

      vec4 TextureSample(float s, float t, float r, float lodBias,
                         int texImageUnit, enum texTarget);

    Note that not all three texture coordinates, s, t, and r, are
    used by all texture targets.  In particular, 1D texture targets only
    use the s component, and 2D and rectangle (non-power-of-two) texture
    targets only use the s and t components.  The descriptions of the
    texture instructions below supply all three components, as would be
    the case with 3D or cube map targets.

    If a fragment program samples from a texture target on a texture
    image unit where the bound texture object is not complete, as 
    defined in section 3.8.9, the result will be the vector 
    (R, G, B, A) = (0, 0, 0, 1).

    A fragment program will fail to load if it attempts to sample from
    multiple texture targets on the same texture image unit.  For 
    example, the following program would fail to load:

      !!ARBfp1.0
      TEX result.color, fragment.texcoord[0], texture[0], 2D;
      TEX result.depth, fragment.texcoord[1], texture[0], 3D;
      END

    The fourth texture instruction described below, KIL, does not sample
    from a texture, but rather prevents further processing of the 
    current fragment if any component of its 4-tuple vector is less than
    zero.

    A dependent texture instruction is one that samples using a texture
    coordinate residing in a temporary, rather than in an attribute or
    a parameter.  A program may have a chain of dependent texture
    instructions, where the result of the first texture instruction is 
    used as the coordinate for a second texture instruction, which is in 
    turn used as the coordinate for a third texture instruction, and so 
    on.  Each node in this chain is termed an indirection, and can be 
    thought of as a set of texture samples that execute in parallel
    followed by a sequence of ALU instructions.

    Some implementations may have limitations on how long the dependency 
    chain may be, and so indirections are counted as a resource just
    like instructions or temporaries are counted.  All programs have at 
    least one indirection, or one node in this chain, even if the 
    program performs no texture operation.  Each instruction encountered
    is included in this node until a texture instruction is encountered

      - whose texture coordinate is a temporary that has been previously 
        written in the current node; or

      - whose result vector is a temporary that is also the operand or 
        result vector of a previous ALU instruction in the current node.

    A new node is then started, including the texture instruction and 
    all subsequent instructions, and the process repeats for all 
    instructions in the program.  Note that for simplicity in counting, 
    result writemasks and operand suffixes are not taken into 
    consideration when counting indirections.


    3.11.6.1  TEX: Map coordinate to color

    The TEX instruction takes the first three components of 
    its source vector, and maps them to s, t, and r.  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 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);
   

    3.11.6.2  TXP: Project coordinate and map to color

    The TXP instruction divides the first three components of its source 
    vector by the fourth component and maps the results to s, t, and r.  
    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 resulting sample is mapped to RGBA as 
    described in table 3.21 and written to the result vector.  If the 
    value of the fourth component of the source vector is less than or 
    equal to zero, the result vector is undefined.

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


    3.11.6.3  TXB: Map coordinate to color while biasing its LOD

    The TXB instruction takes the first three components of its source 
    vector and maps them to s, t, and r.  These coordinates are used to 
    sample from the specified texture target on the specified texture
    image unit in a manner consistent with its parameters.  
    Additionally, the fourth component of the source vector is applied 
    to equation 3.14 as fragment_bias below to further bias the level of 
    detail.
    
     lambda'(x,y) = log2[p(x,y)] + 
                    clamp(texobj_bias + texunit_bias + fragment_bias)
    
    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, tmp.w, op1, op2);


    3.11.6.4  KIL: Kill fragment

    Rather than mapping a coordinate set to a color, this function
    prevents a fragment from receiving any future processing.  If any
    component of its source vector is negative, the processing of this 
    fragment will be discontinued and no further outputs to this 
    fragment will occur.  Subsequent stages of the GL pipeline will be 
    skipped for this fragment.

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


    3.11.7  Program Matrices

    In addition to GL's conventional matrices, several additional 
    program matrices are available for use as program parameters.  These 
    matrices have names of the form MATRIX<i>_ARB where <i> is between 
    zero and <n>-1 where <n> is the value of the implementation-
    dependent constant MAX_PROGRAM_MATRICES_ARB.  The MATRIX<i>_ARB 
    constants obey MATRIX<i>_ARB = MATRIX0_ARB + <i>.  The value of 
    MAX_PROGRAM_MATRICES_ARB must be at least eight.  The maximum stack 
    depth for program matrices is defined by the 
    MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB and must be at least 1.


    3.11.8  Required Fragment Program State 

    The state required to support program objects of all targets 
    consists of:

      an integer for the program error position, initially -1;

      an array of ubytes for the program error string, initially empty;

      and the state that must be maintained to indicate which integers 
      are currently in use as program object names.

    The state required to support the fragment program target consists 
    of:

      a bit indicating whether or not fragment program mode is enabled, 
      initially disabled;

      a set of MAX_PROGRAM_ENV_PARAMETERS_ARB four-component floating-
      point program environment parameters, initially set to (0,0,0,0);

      an unsigned integer naming the currently bound fragment program, 
      initially zero;

    The state required for each fragment program object consists of:

      an unsigned integer indicating the program object name;

      an array of type ubyte containing the program string, initially 
      empty;

      an unsigned integer holding the length of the program string, 
      initially zero;

      an enum indicating the program string format, initially
      PROGRAM_FORMAT_ASCII_ARB;

      a bit indicating whether or not the program exceeds the native 
      limits;

      six unsigned integers holding the number of instruction (ALU,
      texture, and total), texture indirection, temporary variable, and 
      program parameter binding resources used by the program, initially 
      all zero;

      six unsigned integers holding the number of native instruction 
      (ALU, texture, and total), texture indirection, temporary 
      variable, and program parameter binding resources used by the 
      program, initially all zero;

      and a set of MAX_PROGRAM_LOCAL_PARAMETERS_ARB four-component 
      floating-point program local parameters, initially set to 
      (0,0,0,0).

    Initially, no fragment program objects exist.


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

    None


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

    Modify Section 5.4, Display Lists (p. 191)

    (modify third paragraph, p. 195) ... These are IsList, GenLists, 
    ..., IsProgramARB, GenProgramsARB, and DeleteProgramsARB, as well as 
    IsEnabled and all the Get commands (chapter 6).


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

    Modify Section 6.1.2, Data Conversions (p. 198)

    (add before last paragraph, p. 198) The matrix selected by the 
    current matrix mode can be queried by calling GetBooleanv, 
    GetIntegerv, GetFloatv, and GetDoublev with <pname> set to 
    CURRENT_MATRIX_ARB; the matrix will be returned in transposed form 
    with <pname> set to TRANSPOSE_CURRENT_MATRIX_ARB.  The depth of the 
    selected matrix stack can be queried with <pname> set to 
    CURRENT_MATRIX_STACK_DEPTH_ARB.  Querying CURRENT_MATRIX_ARB and 
    CURRENT_MATRIX_STACK_DEPTH_ARB is the only means for querying the 
    matrix and matrix stack depth of the program matrices described in 
    section 3.11.7.


    (add to end of last paragraph, p. 199) Queries of texture state
    variables corresponding to texture coordinate processing unit
    (namely, TexGen state and enables, and matrices) will produce an
    INVALID_OPERATION error if the value of ACTIVE_TEXTURE is greater 
    than or equal to MAX_TEXTURE_COORDS_ARB.  All other texture state 
    queries will result in an INVALID_OPERATION error if the value of 
    ACTIVE_TEXTURE is greater than or equal to 
    MAX_TEXTURE_IMAGE_UNITS_ARB.


    Modify Section 6.1.11, Pointer and String Queries (p. 206)

    (modify last paragraph, p. 206) ... The possible values for <name> 
    are VENDOR, RENDERER, VERSION, EXTENSIONS, and 
    PROGRAM_ERROR_STRING_ARB.


    (add after last paragraph of section, p. 207) Queries of
    PROGRAM_ERROR_STRING_ARB return a pointer to an implementation-
    dependent program load error string.  If the last call to 
    ProgramStringARB failed to load a program, the returned string 
    describes at least one reason why the program failed to load.  If 
    the last call to ProgramStringARB successfully loaded a program, the 
    returned string may be empty (containing only a zero terminator) or 
    may contain one or more implementation-dependent warning messages.  
    The contents of the error string are guaranteed to remain constant 
    only until the next ProgramStringARB command, which may overwrite 
    the error string.


    Insert a new Section 6.1.12, Program Queries (p. 207), between 
    existing sections 6.1.11 and 6.1.12.

    6.1.12  Program Queries

    The commands

      void GetProgramEnvParameterdvARB(enum target, uint index,
                                       double *params);
      void GetProgramEnvParameterfvARB(enum target, uint index,
                                       float *params);

    obtain the current value for the program environment parameter 
    numbered <index> for the given program target <target>, and places 
    the information in the array <params>.  The error INVALID_ENUM is 
    generated if <target> specifies a nonexistent program target or a 
    program target that does not support program environment parameters.  
    The error INVALID_VALUE is generated if <index> is greater than or 
    equal to the implementation-dependent number of supported program 
    environment parameters for the program target.

    When <target> is FRAGMENT_PROGRAM_ARB, each program parameter 
    returned is an array of four values.

    The commands

      void GetProgramLocalParameterdvARB(enum target, uint index,
                                         double *params);
      void GetProgramLocalParameterfvARB(enum target, uint index,
                                         float *params);

    obtain the current value for the program local parameter numbered 
    <index> belonging to the program object currently bound to <target>, 
    and places the information in the array <params>.  The error 
    INVALID_ENUM is generated if <target> specifies a nonexistent 
    program target or a program target that does not support program 
    local parameters.  The error INVALID_VALUE is generated if <index> 
    is greater than or equal to the implementation-dependent number of 
    supported program local parameters for the program target.

    When the program target type is FRAGMENT_PROGRAM_ARB, each program
    local parameter returned is an array of four values.

    The command

      void GetProgramivARB(enum target, enum pname, int *params);

    obtains program state for the program target <target>, writing the 
    state into the array given by <params>.  GetProgramivARB can be used 
    to determine the properties of the currently bound program object or
    implementation limits for <target>.

    If <pname> is PROGRAM_LENGTH_ARB, PROGRAM_FORMAT_ARB, or
    PROGRAM_BINDING_ARB, GetProgramivARB returns one integer holding the
    program string length (in bytes), program string format, and program 
    name, respectively, for the program object currently bound to 
    <target>.

    If <pname> is MAX_PROGRAM_LOCAL_PARAMETERS_ARB or
    MAX_PROGRAM_ENV_PARAMETERS_ARB, GetProgramivARB returns one integer
    holding the maximum number of program local parameters or program
    environment parameters, respectively, supported for the program 
    target <target>.

    If <pname> is MAX_PROGRAM_INSTRUCTIONS_ARB, 
    MAX_PROGRAM_ALU_INSTRUCTIONS_ARB, MAX_PROGRAM_TEX_INSTRUCTIONS_ARB,
    MAX_PROGRAM_TEX_INDIRECTIONS_ARB, MAX_PROGRAM_TEMPORARIES_ARB,
    MAX_PROGRAM_PARAMETERS_ARB, or MAX_PROGRAM_ATTRIBS_ARB, 
    GetProgramivARB returns a single integer giving the maximum number 
    of total instructions, ALU instructions, texture instructions, 
    texture indirections, temporaries, parameters, and attributes that 
    can be used by a program of type <target>.  If <pname> is 
    PROGRAM_INSTRUCTIONS_ARB, PROGRAM_ALU_INSTRUCTIONS_ARB, 
    PROGRAM_TEX_INSTRUCTIONS_ARB, PROGRAM_TEX_INDIRECTIONS_ARB,
    PROGRAM_TEMPORARIES_ARB, PROGRAM_PARAMETERS_ARB, or
    PROGRAM_ATTRIBS_ARB, GetProgramivARB returns a single integer giving 
    the number of total instructions, ALU instructions, texture 
    instructions, texture indirections, temporaries, parameters, and
    attributes used by the current program for <target>.    

    If <pname> is MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB, 
    MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB, 
    MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB, 
    MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB, 
    MAX_PROGRAM_NATIVE_TEMPORARIES_ARB, 
    MAX_PROGRAM_NATIVE_PARAMETERS_ARB, or 
    MAX_PROGRAM_NATIVE_ATTRIBS_ARB, GetProgramivARB returns a single 
    integer giving the maximum number of native instruction, ALU 
    instruction, texture instruction, texture indirection, temporary, 
    parameter, and attribute resources available to a program of type 
    <target>.  If <pname> is PROGRAM_NATIVE_INSTRUCTIONS_ARB, 
    PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB, 
    PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB, 
    PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB, 
    PROGRAM_NATIVE_TEMPORARIES_ARB, PROGRAM_NATIVE_PARAMETERS_ARB, or
    PROGRAM_NATIVE_ATTRIBS_ARB, GetProgramivARB returns a single integer 
    giving the number of native instruction, ALU instruction, texture 
    instruction, texture indirection, temporary, parameter, and
    attribute resources consumed by the program currently bound to 
    <target>.  Native resource counts will reflect the results of 
    implementation-dependent scheduling and optimization algorithms 
    applied by the GL, as well as emulation of non-native features.  If 
    <pname> is PROGRAM_UNDER_NATIVE_LIMITS_ARB, GetProgramivARB returns 
    0 if the native resource consumption of the program currently bound 
    to <target> exceeds the number of available resources for any 
    resource type, and 1 otherwise.

    The command

      void GetProgramStringARB(enum target, enum pname, void *string);

    obtains the program string for the program object bound to <target> 
    and places the information in the array <string>.  <pname> must be
    PROGRAM_STRING_ARB.  <n> ubytes are returned into the array program 
    where <n> is the length of the program in ubytes, as returned by 
    GetProgramivARB when <pname> is PROGRAM_LENGTH_ARB.  The program 
    string is always returned using the format given when the program 
    string was specified.

    The command

      boolean IsProgramARB(uint program);

    returns TRUE if <program> is the name of a program object.  If 
    <program> is zero or is a non-zero value that is not the name of a 
    program object, or if an error condition occurs, IsProgramARB 
    returns FALSE.  A name returned by GenProgramsARB, but not yet 
    bound, is not the name of a program object.


    Modify Section 6.2, State Tables (p. 216)

    (add to caption of Table 6.5) When accessing the current texture
    coordinates (CURRENT_TEXTURE_COORDS) or the texture coordinates 
    associated with raster position (CURRENT_RASTER_TEXTURE_COORDS), the 
    active texture unit selector (ACTIVE_TEXTURE) must be less than the 
    implementation dependent maximum number of texture coordinate sets 
    (MAX_TEXTURE_COORDS_ARB).

    (add to caption of Table 6.8) When accessing the texture matrix 
    stack (TEXTURE_MATRIX, TRANSPOSE_TEXTURE_MATRIX) or the texture 
    matrix stack pointer (TEXTURE_STACK_DEPTH), the active texture unit 
    selector (ACTIVE_TEXTURE) must be less than the implementation 
    dependent maximum number of texture coordinate sets 
    (MAX_TEXTURE_COORDS_ARB).

    (split Table 6.17 into two tables, Texture Environment and Texture 
    Coordinate Generation; move active texture unit selector and texture 
    coordinate generation state to table 6.18; renumber subsequent 
    tables)
    
    (add to captions of Tables 6.14, 6.15, 6.16) The active texture unit 
    selector (ACTIVE_TEXTURE) identifies which texture object is 
    accessed, and must be less than the implementation dependent maximum 
    number of texture image units (MAX_TEXTURE_IMAGE_UNITS_ARB).

    (add to caption of Table 6.18) With the exception of ACTIVE_TEXTURE,
    the active texture unit selector (ACTIVE_TEXTURE) identifies which 
    texture coordinate set is accessed, and must be less than the 
    implementation dependent maximum number of texture coordinate sets 
    (MAX_TEXTURE_COORDS_ARB).

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

    Add to end of Section A.3 (p. 242):

      Rule 4.  Fragment program instructions not relevant to the 
      calculation of any result must have no effect on that result.

      Rule 5.  Fragment program instructions relevant to the calculation 
      of any result must always produce the identical result.

    Instructions relevant to the calculation of a result are any 
    instructions in a sequence of instructions that eventually determine 
    the source values for the calculation under consideration.

    There is no guaranteed invariance between fragment colors generated 
    by conventional GL texturing mode and fragment colors generated by 
    fragment program mode.  Multi-pass rendering algorithms that require 
    rendering invariances to operate correctly should not mix 
    conventional GL fragment texturing mode with fragment program mode 
    for different rendering passes.  However, such algorithms will 
    operate correctly if the algorithms limit themselves to a single 
    mode of fragment color generation.

    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.  Multi-pass rendering algorithms that
    use depth-replacing fragment programs should use depth-replacing
    fragment programs on each pass to guarantee identical z values.

    The texture sample chosen for a fragment of a primitive must be
    invariant between fragment program mode and conventional texture
    application mode subject to these conditions:

      1. All state with the exception of fragment program state is
         identical

      2. The primitives generating the fragments are identical

      3. The sample in the fragment program mode is the result of a
         'TEX' instruction (or a 'TXP' instruction with a unity q)

      4. The texture coordinate operand for the texture instruction uses 
         the same texture coordinate set as the conventional mode sample

      5. The texture coordinate operand for the texture instruction has 
         not been the result of any other operations in the fragment 
         program


Additions to the AGL/GLX/WGL Specifications

    Program objects are shared between AGL/GLX/WGL rendering contexts if
    and only if the rendering contexts share display lists.  No change
    is made to the AGL/GLX/WGL API.

    Changes to program objects shared between multiple rendering 
    contexts will be serialized (i.e., the changes will occur in a 
    specific order).  

    Changes to a program object made by one rendering context are not
    guaranteed to take effect in another rendering context until the 
    other calls BindProgram to bind the program object.  

    When a program object is deleted by one rendering context, the 
    object itself is not destroyed until it is no longer the current 
    program object in any context.  However, the name of the deleted 
    object is removed from the program object name space, so the next 
    attempt to bind a program using the same name will create a new 
    program object.  Recall that destroying a program object bound in 
    the current rendering context effectively unbinds the object being 
    destroyed.


Dependencies on OpenGL 1.4

    If OpenGL 1.4 is not supported, the modified equation for the 
    calculation of level of detail by the TXB instruction in 3.11.6.3 
    should read

      lambda'(x,y) = log2[p(x,y)] + 
                     clamp(texunit_bias + fragment_bias)

Dependencies on EXT_vertex_weighting and ARB_vertex_blend

    If EXT_vertex_weighting and ARB_vertex_blend are both not supported,
    all discussions of multiple modelview matrices should be removed.  

    In particular, the line in the grammar

      <stateMatrixName>      ::= "modelview" <stateOptModMatNum>

    should be changed to

      <stateMatrixName>      ::= "modelview"

    and the rules <stateOptModMatNum> and <stateModMatNum> should be 
    deleted.  The first line of Table X.2.7 should be modified to read:

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

    The caption for Table X.2.7 should be modified to exclude optional
    modelview matrix number.  Subsequent references to "modelview matrix 
    zero" and "modelview matrix 1" should be changed to "modelview 
    matrix" and the example "state.matrix.modelview[1].row[0]" should be 
    changed to "state.matrix.modelview.row[0]".


Dependencies on ARB_matrix_palette:

    If ARB_matrix_palette is not supported, all discussions of the 
    matrix palette should be removed.

    In particular, the line

      "palette" "[" <statePaletteMatNum> "]"

    should be removed from the <stateMatrixName> grammar rule, and the
    <statePaletteMatNum> grammar rule should be removed entirely.
    "state.matrix.palette[n]" should be removed from Table X.2.7.


Dependencies on ARB_transpose_matrix

    If ARB_transpose_matrix is not supported, the discussion of
    TRANSPOSE_CURRENT_MATRIX_ARB in the edits to section 6.1.2 should be
    removed.


Dependencies on EXT_fog_coord

    If EXT_fog_coord is not supported, references to "fog coordinate"
    in the definition of the "fragment.fogcoord" attribute should be 
    removed.

Dependencies on EXT_texture_rectangle

    If NV_texture_rectangle is not supported, the discussion of the
    rectangle (non-power-of-two) texture target in section 3.11.6 should
    be removed, and the line

      "RECT"

    should be removed from the <texTarget> grammar rule.


Interactions with ARB_shadow

    The texture comparison introduced by ARB_shadow can be expressed in 
    terms of a fragment program, and in fact use the same internal 
    resources on some implementations.  Therefore, if fragment program 
    mode is enabled, the GL behaves as if TEXTURE_COMPARE_MODE_ARB is 
    NONE.


Interactions with ARB_vertex_program

    The program object management entrypoints described in sections
    2.14.1 (for vertex programs) and 3.11.1 (for fragment programs)
    are shared by both program targets.  The PROGRAM_ERROR_STRING_ARB
    and program queries in sections 6.1.11 and 6.1.12 are also shared,
    as are all common tokens.

    The Errors section should be modified to generate INVALID_OPERATION
    from the Get command with argument CURRENT_MATRIX_ARB, 
    TRANSPOSE_CURRENT_MATRIX_ARB, and CURRENT_MATRIX_STACK_DEPTH_ARB
    when the current matrix mode is TEXTURE.

    In the presence of ARB_vertex_program, ARB_fragment_program must 
    recognize and return appropriate values for the GetProgram <pname> 
    tokens introduced in that spec but not otherwise shared by 
    ARB_fragment_program:

        PROGRAM_ADDRESS_REGISTERS_ARB                   0x88B0
        MAX_PROGRAM_ADDRESS_REGISTERS_ARB               0x88B1
        PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB            0x88B2
        MAX_PROGRAM_NATIVE_ADDRESS_REGISTERS_ARB        0x88B3

    The following tables list new program object state and 
    implementation-dependent state:

    Get Value                        Type   Get Command          Initial Value    Description             Sec       Attrib
    --------------------             -----  -------------------  ---------------  ----------------------  --------  ------
    PROGRAM_ADDRESS_REGISTERS_ARB    Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                  address registers
    PROGRAM_NATIVE_ADDRESS_          Z+     GetProgramivARB      0                bound program native    6.1.12    -
        REGISTERS_ARB                                                             address registers

    Table X.7.  Program Object State.  Program object queries return attributes of
    the program object currently bound to the program target <target>.


                                                                Minimum
    Get Value                            Type  Get Command      Value    Description             Sec.       Attrib
    ---------                            ----  -----------      -------  -----------             ----       ------
    MAX_PROGRAM_ADDRESS_REGISTERS_ARB    Z+    GetProgramivARB  0        maximum program         6.1.12     -
                                                                         address registers
    MAX_PROGRAM_NATIVE_ADDRESS_          Z+    GetProgramivARB  0        maximum program native  6.1.12     -
        REGISTERS_ARB                                                    address registers

    Table X.10.  New Implementation-Dependent Values Introduced by
    ARB_vertex_program.


    In the presence of ARB_fragment_program, ARB_vertex_program must
    recognize and return appropriate values for the GetProgram <pname> 
    tokens introduced in this spec.  The following tables list new 
    program object state and implementation-dependent state:

    Get Value                            Type   Get Command          Initial Value    Description             Sec       Attrib
    --------------------                 -----  -------------------  ---------------  ----------------------  --------  ------
    PROGRAM_ALU_INSTRUCTIONS_ARB         Z+     GetProgramivARB      0                maximum program         6.1.12    -
                                                                                      ALU instructions
    PROGRAM_TEX_INSTRUCTIONS_ARB         Z+     GetProgramivARB      0                maximum program         6.1.12    -
                                                                                      texture instructions
    PROGRAM_TEX_INDIRECTIONS_ARB         Z+     GetProgramivARB      0                maximum program         6.1.12    -
                                                                                      texture indirections
    PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB  Z+     GetProgramivARB      0                maximum program native  6.1.12    -
                                                                                      ALU instructions
    PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB  Z+     GetProgramivARB      0                maximum program native  6.1.12    -
                                                                                      texture instructions
    PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB  Z+     GetProgramivARB      0                maximum program native  6.1.12    -
                                                                                      texture indirections

    Table X.7.  Program Object State.  Program object queries return attributes of
    the program object currently bound to the program target <target>.


                                                                    Minimum
    Get Value                                Type  Get Command      Value    Description             Sec.       Attrib
    ---------                                ----  -----------      -------  -----------             ----       ------
    MAX_PROGRAM_ALU_INSTRUCTIONS_ARB         Z+    GetProgramivARB  0        Number of frag. prg.    6.1.12     -
                                                                             ALU instructions
    MAX_PROGRAM_TEX_INSTRUCTIONS_ARB         Z+    GetProgramivARB  0        Number of frag. prg.    6.1.12     -
                                                                             texture instructions
    MAX_PROGRAM_TEX_INDIRECTIONS_ARB         Z+    GetProgramivARB  0        Number of frag. prg.    6.1.12     -
                                                                             texture indirections       
    MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB  Z+    GetProgramivARB  0        maximum program native  6.1.12     -
                                                                             ALU instructions
    MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB  Z+    GetProgramivARB  0        maximum program native  6.1.12     -
                                                                             texture instructions
    MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB  Z+    GetProgramivARB  0        maximum program native  6.1.12     -
                                                                             texture indirections

    Table X.10.  New Implementation-Dependent Values Introduced by
    ARB_fragment_program.


Interactions with ATI_fragment_shader

    The existing ATI_fragment_shader extension, if supported, also
    provides a similar fragment programming model.  Mixing the two
    models in a single application is possible but not recommended.
    FRAGMENT_PROGRAM_ARB has priority over FRAGMENT_SHADER_ATI if
    both are enabled.


Interactions with NV_fragment_program

    The NV_fragment_program extension, if supported, also provides a 
    similar programming model.  This extension is incompatible with
    NV_fragment_program in a number of different ways.  Mixing the two 
    models in a single application is possible but not recommended.  The 
    interactions between the extensions are defined below.

    Functions, enumerants, and programs defined in NV_fragment_program 
    are called "NV functions", "NV enumerants", and "NV programs," 
    respectively.  Functions, enumerants, and programs defined in 
    ARB_fragment_program are called "ARB functions", "ARB enumerants", 
    and "ARB programs," respectively.

    The following GL state is identical in the two extensions:

      - Fragment program mode enable.  The NV and ARB enumerants have
        different values, but the same effect.

      - Program error position.

      - Program error string.

      - NV_fragment_program and ARB_fragment_program "program local
        parameters."

      - Fragment program names, targets, formats, program string, 
        program string lengths, and residency information.  The ARB and 
        NV query functions operate differently.  The ARB query function 
        does not allow queries of target (passed in to the query) and 
        residency information.  The NV query function does not allow 
        queries of program name (passed in to the query) or format.  The 
        format of NV programs is always PROGRAM_FORMAT_ASCII_ARB.

      - Program object name space.  Program objects are created 
        differently in the NV and ARB specs.  Under the NV spec, program 
        objects are created by calling LoadProgramNV.  Under the ARB 
        spec, program objects are created by calling BindProgramARB with 
        an unused program name.

    The following state is provided only by ARB_fragment_program:

      - Program environment parameters.

      - Implementation-dependent limits on the number of instructions, 
        ALU instructions, texture instructions, texture indirections, 
        program parameters, fragment attributes, resource counts, and 
        native resource counts.  The instruction limit is baked into the 
        NV spec.  Implementations supporting NV_fragment_program have no 
        specific restrictions on the number of ALU instructions, texture 
        instructions, texture indirections, or fragment attributes used.  
        Such implementations also have no limit on program parameters 
        used, except that no more than one may be used by any single 
        program instruction.

    The following state is provided only by NV_fragment_program:

      - Named program parameters (variables defined in the program text 
        and updated by name).

    The following are additional functional differences between
    ARB_fragment_program and NV_fragment_program:

      - NV programs use a set of register names, with no support for
        user-defined variables (other than parameters in the program).  
        ARB programs provide no support for fixed variable names; all 
        variables must be declared, explicitly or implicitly, in the 
        program.

      - ARB programs support parameter variables that can be bound to 
        selected GL state variables, and are updated automatically when 
        the underlying state changes.  NV programs provide no such 
        support; applications must set program parameters themselves.

      - ARB_fragment_program doesn't provide explicit support for 
        multiple data types (fx12, fp16, fp32) described in 
        NV_fragment_program, and provides no mechanism for controlling 
        the precision used to carry out arithmetic operations.

      - ARB_fragment_program doesn't support condition codes, 
        conditional writemasks, or the "C" instruction suffix that 
        specifies a condition code update.

      - ARB_fragment_program doesn't support an absolute value operator 
        that can be applied to a source vector as it is loaded.

      - ARB_fragment_program doesn't define behavior for many floating-
        point special cases.  On platforms where NV_fragment_program is 
        supported, ARB programs will have the same special-case 
        behavior.

      - Language to declare program parameters is slightly different
        (NV_fragment_program has "DECLARE" and "DEFINE"; 
        ARB_fragment_program has "PARAM").

      - NV_fragment_program provides a number of instructions not found 
        in ARB_fragment_program:

          * DDX, DDY:  partial derivatives relative to x and  y.

          * "PK*" and "UP*":  packing and unpacking instructions.

          * RFL:  reflection vector.

          * SEQ, SFL, SGT, SLE, SNE, STR:  set on equal, false, greater 
            than, less than or equal, not equal, and true, respectively.

          * TXD:  texture lookup w/partials.

          * X2D:  2D coordinate transformation.

      - ARB_fragment_program provides several instructions not found in
        NV_fragment_program, and there are a few instruction set 
        differences:

          * ABS:  absolute value.  ABS instructions are unnecessary in 
              NV_fragment_program because of the free absolute value on 
              input operator.  Equivalent to:
           
                 MOV dst, |src|;

          * CMP:  compare.  Roughly equivalent to the following 
              sequence, but may be optimized further:

                 SLT tmp, src0; 
                 LRP dst, tmp, src1, src2;

          * DPH:  homogenous dot product.  Equivalent to:

                 DP3 tmp, src0, src1;
                 ADD dst, tmp, src0.w;

          * KIL:  kill fragment.  Both extensions support this 
              instruction, but the ARB instruction takes a vector 
              operand rather than a condition code.

          * SCS:  sine/cosine.  Emulated using the separate SIN and COS
              instructions in NV_fragment_program, which also have no
              restriction on the input values.

          * SWZ:  extended swizzle.  On NV_fragment_program platforms, 
              this instruction will be emulated using a single MAD 
              instruction and a program parameter constant.

          * TXB:  texture sample with bias.  Not exposed in the
              NV_fragment_program API.

          * XPD:  cross product.  Emulated using a MUL and a MAD 
              instruction.


GLX Protocol

     The following rendering commands are sent to the server as part of
     a glXRender request:

        BindProgramARB
            2           12              rendering command length
            2           4180            rendering command opcode
            4           ENUM            target
            4           CARD32          program

        ProgramEnvParameter4fvARB
            2           32              rendering command length
            2           4184            rendering command opcode
            4           ENUM            target
            4           CARD32          index
            4           FLOAT32         params[0]
            4           FLOAT32         params[1]
            4           FLOAT32         params[2]
            4           FLOAT32         params[3]

        ProgramEnvParameter4dvARB
            2           44              rendering command length
            2           4185            rendering command opcode
            4           ENUM            target
            4           CARD32          index
            8           FLOAT64         params[0]
            8           FLOAT64         params[1]
            8           FLOAT64         params[2]
            8           FLOAT64         params[3]

        ProgramLocalParameter4fvARB
            2           32              rendering command length
            2           4215            rendering command opcode
            4           ENUM            target
            4           CARD32          index
            4           FLOAT32         params[0]
            4           FLOAT32         params[1]
            4           FLOAT32         params[2]
            4           FLOAT32         params[3]

        ProgramLocalParameter4dvARB
            2           44              rendering command length
            2           4216            rendering command opcode
            4           ENUM            target
            4           CARD32          index
            8           FLOAT64         params[0]
            8           FLOAT64         params[1]
            8           FLOAT64         params[2]
            8           FLOAT64         params[3]

    The ProgramStringARB is potentially large, and hence can be sent in 
    a glXRender or glXRenderLarge request.

        ProgramStringARB
            2           16+len+p        rendering command length
            2           4217            rendering command opcode
            4           ENUM            target
            4           ENUM            format
            4           sizei           len
            len         LISTofBYTE      program
            p                           unused, p=pad(len)

         If the command is encoded in a glxRenderLarge request, the 
         command opcode and command length fields above are expanded to 
         4 bytes each:

            4           16+len+p        rendering command length
            4           4217            rendering command opcode

    The remaining commands are non-rendering commands.  These commands 
    are sent separately (i.e., not as part of a glXRender or 
    glXRenderLarge request), using the glXVendorPrivateWithReply 
    request:

        DeleteProgramsARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           4+n             request length
            4           1294            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           INT32           n
            n*4         LISTofCARD32    programs

        GenProgramsARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           4               request length
            4           1295            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           INT32           n
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           n               reply length
            24                          unused
            n*4         LISTofCARD322   programs

        GetProgramEnvParameterfvARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           6               request length
            4           1296            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           CARD32          index
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           m               reply length, m=(n==1?0:n)
            4                           unused
            4           CARD32          n (number of parameter components)

            if (n=1) this follows:

            4           FLOAT32         params
            12                          unused

            otherwise this follows:

            16                          unused
            n*4         LISTofFLOAT32   params

        GetProgramEnvParameterdvARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           6               request length
            4           1297            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           CARD32          index
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           m               reply length, m=(n==1?0:n*2)
            4                           unused
            4           CARD32          n (number of parameter components)

            if (n=1) this follows:

            8           FLOAT64         params
            8                           unused

            otherwise this follows:

            16                          unused
            n*8         LISTofFLOAT64   params

        GetProgramLocalParameterfvARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           6               request length
            4           1305            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           CARD32          index
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           m               reply length, m=(n==1?0:n)
            4                           unused
            4           CARD32          n (number of parameter components)

            if (n=1) this follows:

            4           FLOAT32         params
            12                          unused

            otherwise this follows:

            16                          unused
            n*4         LISTofFLOAT32   params

        GetProgramLocalParameterdvARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           6               request length
            4           1306            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           CARD32          index
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           m               reply length, m=(n==1?0:n*2)
            4                           unused
            4           CARD32          n (number of parameter components)

            if (n=1) this follows:

            8           FLOAT64         params
            8                           unused

            otherwise this follows:

            16                          unused
            n*8         LISTofFLOAT64   params

        GetProgramivARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           5               request length
            4           1307            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           m               reply length, m=(n==1?0:n)
            4                           unused
            4           CARD32          n

            if (n=1) this follows:

            4           INT32           params
            12                          unused

            otherwise this follows:

            16                          unused
            n*4         LISTofINT32     params

        GetProgramStringARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           5               request length
            4           1308            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           ENUM            target
            4           ENUM            pname
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           (n+p)/4         reply length
            4                           unused
            4           CARD32          n
            16                          unused
            n           STRING          program
            p                           unused, p=pad(n)

        IsProgramARB
            1           CARD8           opcode (X assigned)
            1           17              GLX opcode (glXVendorPrivateWithReply)
            2           4               request length
            4           1304            vendor specific opcode
            4           GLX_CONTEXT_TAG context tag
            4           INT32           n
          =>
            1           1               reply
            1                           unused
            2           CARD16          sequence number
            4           0               reply length
            4           BOOL32          return value
            20                          unused


Errors
  
    The error INVALID_OPERATION is generated by ProgramStringARB if the
    program string <string> is syntactically incorrect or violates any
    semantic restriction of the execution environment of the specified 
    program target <target>.  The error INVALID_OPERATION may also be
    generated by ProgramStringARB if the specified program would exceed 
    native resource limits of the implementation.

    The error INVALID_OPERATION is generated by BindProgramARB if 
    <program> is the name of a program whose target does not match 
    <target>.

    The error INVALID_VALUE is generated by commands 
    ProgramEnvParameter{fd}ARB, ProgramEnvParameter{fd}vARB, and 
    GetProgramEnvParameter{fd}vARB if <index> is greater than or equal 
    to the value of MAX_PROGRAM_ENV_PARAMETERS_ARB corresponding to the 
    program target <target>.

    The error INVALID_VALUE is generated by commands 
    ProgramLocalParameter4{fd}ARB, ProgramLocalParameter4{fd}vARB, and
    GetProgramLocalParameter{fd}vARB if <index> is greater than or equal 
    to the value of MAX_PROGRAM_LOCAL_PARAMETERS_ARB corresponding to 
    the program target <target>.

    The error INVALID_OPERATION is generated if Begin, RasterPos, or any
    command that performs an explicit Begin is called when fragment 
    program mode is enabled and the currently bound fragment program 
    object does not contain a valid fragment program.

    The error INVALID_OPERATION is generated by any command accessing
    texture coordinate processing state if the texture unit number
    corresponding to the current value of ACTIVE_TEXTURE is greater than
    or equal to the implementation-dependent constant 
    MAX_TEXTURE_COORDS_ARB.  Such commands include: GetTexGen{if}v; 
    TexGen{ifd}, TexGen{ifd}v; Disable, Enable, IsEnabled with argument 
    TEXTURE_GEN_{STRQ}; Get with argument CURRENT_TEXTURE_COORDS, 
    CURRENT_RASTER_TEXTURE_COORDS, TEXTURE_STACK_DEPTH, TEXTURE_MATRIX, 
    TRANSPOSE_TEXTURE_MATRIX; when the current matrix mode is TEXTURE, 
    Frustum, LoadIdentity, LoadMatrix{fd}, LoadTransposeMatrix{fd}, 
    MultMatrix{fd}, MultTransposeMatrix{fd}, Ortho, PopMatrix, 
    PushMatrix, Rotate{fd}, Scale{fd}, Translate{fd}.

    The error INVALID_OPERATION is generated by any command accessing
    texture image processing state if the texture unit number 
    corresponding to the current value of ACTIVE_TEXTURE is greater than
    or equal to the implementation-dependent constant 
    MAX_TEXTURE_IMAGE_UNITS_ARB.  Such commands include: BindTexture;
    GetCompressedTexImage, GetTexEnv{if}v, GetTexImage, 
    GetTexLevelParameter{if}v, GetTexParameter{if}v; TexEnv{if}, 
    TexEnv{if}v, TexParameter{if}, TexParameter{if}v; Disable, Enable, 
    IsEnabled with argument TEXTURE_{123}D, TEXTURE_CUBE_MAP; Get with 
    argument TEXTURE_BINDING_{123}D, TEXTURE_BINDING_CUBE_MAP; 
    CompressedTexImage{123}D, CompressedTexSubImage{123}D, 
    CopyTexImage{12}D, CopyTexSubImage{123}D, TexImage{123}D, 
    TexSubImage{123}D.


New State


    Get Value                        Type    Get Command    Initial Value Description         Section       Attribute
    -------------------------------  ------  -------------  ------------- ------------------  ------------  ------------
    FRAGMENT_PROGRAM_ARB             B       IsEnabled      False         fragment program    3.8           enable
                                                                          enable
    -                                24+xR4  GetProgramEnv- (0,0,0,0)     program environment 3.11.1        -
                                             ParameterARB                 parameters
    PROGRAM_ERROR_POSITION_ARB       Z       GetIntegerv    -1            last program error  3.11.1        -
                                                                          position
    PROGRAM_ERROR_STRING_ARB         0+xub   GetString      ""            last program error  3.11.1        -
                                                                          string

    Table X.6.  New Accessible State Introduced by ARB_fragment_program.


    Get Value                            Type   Get Command          Initial Value    Description             Sec       Attrib
    --------------------                 -----  -------------------  ---------------  ----------------------  --------  ------
    PROGRAM_BINDING_ARB                  Z+     GetProgramivARB      object-specific  bound program name      6.1.12    -
    PROGRAM_LENGTH_ARB                   Z+     GetProgramivARB      0                bound program length    6.1.12    -
    PROGRAM_FORMAT_ARB                   Z1     GetProgramivARB      PROGRAM_FORMAT_  bound program format    6.1.12    -
                                                                     ASCII_ARB
    PROGRAM_STRING_ARB                   ubxn   GetProgramStringARB  (empty)          bound program string    6.1.12    -
    PROGRAM_INSTRUCTIONS_ARB             Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      total instructions
    PROGRAM_ALU_INSTRUCTIONS_ARB         Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      ALU instructions
    PROGRAM_TEX_INSTRUCTIONS_ARB         Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      texture instructions
    PROGRAM_TEX_INDIRECTIONS_ARB         Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      texture indirections
    PROGRAM_TEMPORARIES_ARB              Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      temporaries
    PROGRAM_PARAMETERS_ARB               Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      parameter bindings
    PROGRAM_ATTRIBS_ARB                  Z+     GetProgramivARB      0                bound program           6.1.12    -
                                                                                      attribute bindings
    PROGRAM_NATIVE_INSTRUCTIONS_ARB      Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      instructions
    PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB  Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      ALU instructions
    PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB  Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      texture instructions
    PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB  Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      texture indirections
    PROGRAM_NATIVE_TEMPORARIES_ARB       Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      temporaries
    PROGRAM_NATIVE_PARAMETERS_ARB        Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      parameter bindings
    PROGRAM_NATIVE_ATTRIBS_ARB           Z+     GetProgramivARB      0                bound program native    6.1.12    -
                                                                                      attribute bindings
    PROGRAM_UNDER_NATIVE_LIMITS_ARB      B      GetProgramivARB      0                bound program under     6.1.12    -
                                                                                      native resource limits
    -                                    24+xR4 GetProgramLocal-     (0,0,0,0)        bound program local     3.11.1    -
                                                ParameterARB                          parameter value

    Table X.7.  Program Object State.  Program object queries return attributes of
    the program object currently bound to the program target <target>.


    Get Value    Type    Get Command   Initial Value  Description                Sec       Attribute
    ---------    ------  -----------   -------------  -------------------------  --------  ---------
    -            16+xR4  -             undefined      temporary registers        3.11.3.3  -
    -            2xR4    -             undefined      fragment result registers  3.11.3.4  -

    Table X.8.  Fragment Program Per-fragment Execution State.  All per-fragment
    execution state registers are uninitialized at the beginning of program
    execution.


    Get Value                          Type      Get Command      Initial Value  Description          Sec      Attribute
    ------------------------------     --------  --------------   -------------  -------------------  -------  ---------
    CURRENT_MATRIX_ARB                 m*n*xM^4  GetFloatv        Identity       current matrix       6.1.2    -
    CURRENT_MATRIX_STACK_DEPTH_ARB     m*Z+      GetIntegerv      1              current stack depth  6.1.2    -

    Table X.9.  Current matrix state where m is the total number of matrices
    including texture matrices and program matrices and n is the number of
    matrices on each particular matrix stack.  Note that this state is aliased
    with existing matrix state.


New Implementation Dependent State
                                                                    Minimum
    Get Value                                Type  Get Command      Value      Description             Sec.       Attrib
    ---------                                ----  -----------      -------    -----------             ----       ------
    MAX_TEXTURE_COORDS_ARB                   Z+    GetIntegerv      2          number of texture       2.7        -
                                                                               coordinate sets
    MAX_TEXTURE_IMAGE_UNITS_ARB              Z+    GetIntegerv      2          number of texture       2.10.2     -
                                                                               image units
    MAX_PROGRAM_ENV_PARAMETERS_ARB           Z+    GetProgramivARB  24         maximum program         3.11.1     -
                                                                               env parameters
    MAX_PROGRAM_LOCAL_PARAMETERS_ARB         Z+    GetProgramivARB  24         maximum program         3.11.1     -
                                                                               local parameters
    MAX_PROGRAM_MATRICES_ARB                 Z+    GetIntegerv      8 (not to  maximum number of       3.11.7     -
                                                                    exceed 32) program matrices
    MAX_PROGRAM_MATRIX_STACK_DEPTH_ARB       Z+    GetIntegerv      1          maximum program         3.11.7     -
                                                                               matrix stack depth
    MAX_PROGRAM_INSTRUCTIONS_ARB             Z+    GetProgramivARB  72         maximum program         6.1.12     -
                                                                               total instructions
    MAX_PROGRAM_ALU_INSTRUCTIONS_ARB         Z+    GetProgramivARB  48         number of frag. prg.    6.1.12     -
                                                                               ALU instructions
    MAX_PROGRAM_TEX_INSTRUCTIONS_ARB         Z+    GetProgramivARB  24         number of frag. prg.    6.1.12     -
                                                                               texture instructions
    MAX_PROGRAM_TEX_INDIRECTIONS_ARB         Z+    GetProgramivARB  4          number of frag. prg.    6.1.12     -
                                                                               texture indirections       
    MAX_PROGRAM_TEMPORARIES_ARB              Z+    GetProgramivARB  16         maximum program         6.1.12     -
                                                                               temporaries
    MAX_PROGRAM_PARAMETERS_ARB               Z+    GetProgramivARB  24         maximum program         6.1.12     -
                                                                               parameter bindings
    MAX_PROGRAM_ATTRIBS_ARB                  Z+    GetProgramivARB  10         maximum program         6.1.12     -
                                                                               attribute bindings
    MAX_PROGRAM_NATIVE_INSTRUCTIONS_ARB      Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               total instructions
    MAX_PROGRAM_NATIVE_ALU_INSTRUCTIONS_ARB  Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               ALU instructions
    MAX_PROGRAM_NATIVE_TEX_INSTRUCTIONS_ARB  Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               texture instructions
    MAX_PROGRAM_NATIVE_TEX_INDIRECTIONS_ARB  Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               texture indirections
    MAX_PROGRAM_NATIVE_TEMPORARIES_ARB       Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               temporaries
    MAX_PROGRAM_NATIVE_PARAMETERS_ARB        Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               parameter bindings
    MAX_PROGRAM_NATIVE_ATTRIBS_ARB           Z+    GetProgramivARB  -          maximum program native  6.1.12     -
                                                                               attribute bindings

    Table X.10.  New Implementation-Dependent Values Introduced by
    ARB_fragment_program.  Values queried by GetProgram require a <pname> of
    FRAGMENT_PROGRAM_ARB.


Sample Usage

    The following program shows how to perform a simple modulation 
    between the interpolated color and a single texture:

      !!ARBfp1.0
      # Simple program to show how to code up the default texture environment

      ATTRIB tex = fragment.texcoord;      #first set of texture coordinates
      ATTRIB col = fragment.color.primary; #diffuse interpolated color

      OUTPUT outColor = result.color;

      TEMP tmp;

      TXP tmp, tex, texture, 2D;           #sample the texture
    
      MUL outColor, tmp, col;              #perform the modulation
    
      END 

    The following is an example the simulates a chrome surface:

      !!ARBfp1.0

      ########################
      # Input Textures:
      #-----------------------
      # Texture 0 contains the default 2D texture used for general mapping
      # Texture 2 contains a 1D pointlight falloff map
      # Texture 3 contains a 2D map for calculating specular lighting
      # Texture 4 contains normalizer cube map
      #
      # Input Texture Coordinates:
      #-----------------------
      # TexCoord1 contains the calculated normal
      # TexCoord2 contains the light to vertex vector
      # TexCoord3 contains the half-vector in tangent space
      # TexCoord4 contains the light vector in tangent space
      # TexCoord5 contains the eye vector in tangent space
      ########################

      TEMP     NdotH, lV, L;

      ALIAS    diffuse  = L;
      PARAM       half  = { 0.5, 0.5, 0.5, 0.5 };
      ATTRIB   norm_tc  = fragment.texcoord[1];
      ATTRIB     lv_tc  = fragment.texcoord[2];
      ATTRIB   half_tc  = fragment.texcoord[3];
      ATTRIB  light_tc  = fragment.texcoord[4];
      ATTRIB    eye_tc  = fragment.texcoord[5];
      OUTPUT      oCol  = result.color;

      TEX     L, light_tc, texture[4], CUBE; # Sample cube map normalizer

      # Calculate diffuse lighting (N.L)
      SUB     L, L, half;              # Bias L and then multiply by 2
      ADD     L, L, L;
      DP3     diffuse, norm_tc, L;     # N.L

      # Calculate specular lighting component { (N.H), |H|^2 }
      DP3     NdotH.x, norm_tc, half_tc;
      DP3     NdotH.y, half_tc, half_tc;

      DP3     lV.x, lv_tc, lv_tc;     # lV = (|light to vertex|)^2


      #############
      # Pass 2
      #############

      TEMP     base, specular;
      ALIAS    atten  = lV;

      TEX      base,     eye_tc, texture[0], 2D; # sample enviroment map using eye vector
      TEX      atten,    lV,     texture[2], 1D; # Sample attenuation map
      TEX      specular, NdotH,  texture[3], 2D; # Sample specular NHHH map= (N.H)^256

      # specular = (N.H)^256 * (N.L) 
      # this ensures a pixel is only lit if facing the light (since the specular
      # exponent makes negative N.H positive we must do this)
      MUL      specular, specular, diffuse;

      # specular = specular * environment map
      MUL      specular, base, specular;

      # diffuse = diffuse * environment map
      MUL      diffuse, base, diffuse;

      # outColor = (specular * environment map) + (diffuse * environment map)
      ADD      base, specular, diffuse;

      # Apply point light attenutaion
      MUL      oCol, base, atten.r;

      END


Revision History

   Date: 10/08/2013
   Revision: 28
      - Change GLvoid -> void (Bug 10412).

   Date: 11/04/2006
   Revision: 27
      - Updated contact info after ATI/AMD merger.

   Date: 8/22/2003
   Revision: 26
      - Added list of commands generating errors when active texture 
        unit selector is out of range.
      - Fixed typo in <stateMatrixItem> rule.
      - Clarified behavior of fragment.position.z with respect to depth 
        offset.

   Date: 2/26/2003
   Revision: 25
      - Fixed description of KIL instruction to reflect less than zero
        test, not less than or equal to zero.
      - Clarified the processing of incoming and outgoing depths and
        colors to reflect the conversion to floating-point on input and
        the conversion to fixed-point on output.

   Date: 1/10/2003
   Revision: 24
      - Fixed bug where "state.matrix.mvp" was specified incorrectly.
        It should be P*M0 rather than M0*P.
      - Added issue warning about CMP opcode's order of operands.

   Date: 10/22/2002
   Revision: 23
      - Fixed reference to <extSwizComp> rule in 3.11.5.28.  Instead
        reference both <xyzwExtSwizComp> and <rgbaExtSwizComp> rules.

   Date: 10/02/2002
   Revision: 22
      - Fixed typo in section 3.11.1, where 8 program environment and
        8 program local parameters are listed as the minimums instead
        of 24 of each.  Table X.10 had the correct values.
      - Fixed <stateTexEnvItem> to refer to legacy texture units.
      - Fixed typos in issue 29 pseudo-code, added some clarification.

   Date: 9/19/2002
   Revision: 21
      - Added clarifying paragraph for native texture indirection 
        counting, offering examples of possible cases where texture
        indirections may be increased.
      - Fixed typos in issues 25 and 29.

   Date: 9/16/2002
   Revision: 20
      - Added precision hint program options.
      - Fixed various typos, reworded some parts for consistency.
      - Updated issues list.

   Date: 9/13/2002
   Revision: 19
      - Promoted minimum precision of texture coordinates in 2.1.1.
      - Added ARB_fog_* program options.
      - Removed modification to 3.9, put clamps in 3.11.4.4.
      - Made 'texture' a reserved keyword in the grammar.
      - Fixed various typos.
      - Updated section 3.11.6.
      - Updated issues list.

   Date: 9/11/2002
   Revision: 18
      - Updated for consistency with ARB_vertex_program revision 36.
      - Depth output moved to 3rd component of result.depth.
      - Fixed various typos, reworded things in many places.
      - Added NV_fragment_program interactions.
      - Updated issues list.

   Date: 9/09/2002
   Revision: 17
      - Added fogcoord and position attributes.
      - Moved fragment program section to 3.11, after fog.
      - Changed MAX_TEXTURE_UNITS/MAX_AUX_TEXTURE_UNITS to 
        MAX_TEXTURE_COORDS/MAX_TEXTURE_IMAGE_UNITS.
      - Removed TRC and MOD instructions.
      - Added SIN and COS instructions.
      - Added more clarity to resource consumption wording.
      - Added invariance wording concerning depth-replacement.
      - Added rule that a program that fails to load must always fail to
        load, regardless of GL state.
      - Updated issues list.

   Date: 8/30/2002
   Revision: 16
      - Improved texture indirection description.
      - Defined result of sample from incomplete texture as (0,0,0,1).
      - Removed PROGRAMS_LOAD_OVER_NATIVE_LIMITS_ARB per-target query.
      - Allowed ProgramStringARB to fail on non-native programs.
      - Updated issues list.

   Date: 8/28/2002
   Revision: 15
      - Updated for consistency with ARB_vertex_program revision 35.
      - Added PROGRAMS_LOAD_OVER_NATIVE_LIMITS_ARB per-target query.
      - Changed MAX_AUX_TEXTURE_UNITS_ARB enum value.
      - Updated issues list.

   Date: 8/22/2002
   Revision: 14
      - Added sine/cosine instruction (SCS).
      - Updated texture sample grammar, replaced texenables hierarchy.
      - Added EXT_vertex_weighting and ARB_vertex_blend dependency.
      - Updated issues list.

   Date: 8/14/2002
   Revision: 13
      - Fixed <paramConstant> grammar rule.
      - Updated issues list.

   Date: 8/06/2002
   Revision: 12
      - Fixed various typos.
      - Updated issues list.
      - Added wording to 3.10.3.6 to reflect that native resource
        consumption may increase due to emulated instructions.

   Date: 7/29/2002
   Revision: 11
      - Updated for consistency with ARB_vertex_program revision 34.
      - Added support for matrix binding.
      - Removed precision queries.
      - Updated issues list.

   Date: 7/16/2002
   Revision: 10
      - Updated for consistency with ARB_vertex_program revision 31.
      - Added fog params and depth range bindings to grammar.
      - Removed stpq writemasks and swizzles from grammar.
      - Required swizzle components to come from same set, xyzw or rgba.

   Date: 7/10/2002
   Revision: 9
      - Made fog params and depth range bindable.
      - Changed texture instruction names to match 3-letter format.
      - Made texture instructions more consistent with ALU instructions.
      - Increased minimums for implementation-dependent values.
      - Re-introduced 4-components swizzles and the SWZ instruction.
      - Updated issues list.

   Date: 7/03/2002
   Revision: 8
      - Fixed typos.
      - Added DST, LIT, SGE, SLT instructions.
      - Changed FRC definition to match ARB_vertex_program, added MOD
        instruction to expose fmod(arg, 1.0) behavior.

   Date: 6/25/2002
   Revision: 7
      - Updated for consistency with ARB_vertex_program revision 29.

   Date: 6/19/2002
   Revision: 6
      - Updated for consistency with ARB_vertex_program revision 28.
      - Changed from ATI to ARB prefix/suffix.
      - Started using single integer revision number.
      - Added a few more issues to the list.

   Date: 6/14/2002
   Revision: 1.4
      - Updated for consistency with ARB_vertex_program revision 27.
      - Added a few more issues to the list.

   Date: 6/05/2002
   Revision: 1.3
      - Updated for consistency with ARB_vertex_program revision 26.
      - Incorporated program object management, removing dependency on
        ARB_vertex_program.
      - Added interaction with ARB_shadow.

   Date: 6/03/2002
   Revision: 1.2
      - Updated for consistency with ARB_vertex_program revision 25.
      - Fixed TexInstructions to use <texSrcReg>, i.e. no parameters.
      - Added TRC, POW, DPH instructions, updated FRC and LRP.
      - Added fog color parameter binding.

   Date: 5/23/2002
   Revision: 1.1
      - Updated for consistency with ARB_vertex_program revision 24.
      - Added GetProgramfvATI entrypoint for querying precision values.

   Date: 5/10/2002
   Revision: 1.0
      - First draft for circulation.