readme.txt

A simple fragment program that converts every pixel to greyscale.

    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 environm