readme.txt

A simple fragment program that converts every pixel to greyscale.

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