Name

    ARB_fragment_coord_conventions

Name Strings

    GL_ARB_fragment_coord_conventions

Contributors

    Jason Green, TransGaming
    Daniel Koch, TransGaming
    Gavriel State, TransGaming
    Ryan Gordon, Destineer
    Nicholas Vining, Destineer
    John Kessenich, Intel

Contact

    Mark Kilgard, NVIDIA (mjk 'at' nvidia.com)
    Daniel Koch, TransGaming (daniel 'at' transgaming.com)

Notice

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

Status

    Complete. Approved by the ARB on July 3, 2009.

Version

    Last Modified Date:  August 2, 2009
    Version:             10

Number

    ARB Extension #63

Dependencies

    This extension is written against the OpenGL 3.1 Specification but
    can apply to prior specifications.

    This extension interacts with ARB_fragment_program.

    This extension interacts with ARB_fragment_shader.

    This extension interacts with NV_fragment_program.

    This extension interacts with NV_fragment_program_option.

    This extension interacts with NV_fragment_program2.

    This extension interacts with NV_fragment_program4.

Overview

    This extension provides alternative conventions for the fragment
    coordinate XY location available for programmable fragment processing.

    The scope of this extension deals *only* with how the fragment
    coordinate XY location appears during programming fragment processing.
    Beyond the scope of this extension are coordinate conventions used
    for rasterization or transformation.

    In the case of the coordinate conventions for rasterization and
    transformation, some combination of the viewport, depth range, culling
    state, and projection matrix state can be reconfigured to adopt other
    arbitrary clip-space and window-space coordinate space conventions.
    Adopting other clip-space and window-space conventions involves
    adjusting existing OpenGL state.  However it is non-trivial to massage
    an arbitrary fragment shader or program to adopt a different
    window-space coordinate system because such shaders are encoded in
    various textual representations.

    The dominant 2D and 3D rendering APIs make two basic choices of
    convention when locating fragments in window space.

    The two choices are:

    1)  Is the origin nearest the lower-left- or upper-left-most pixel
        of the window?

    2)  Is the (x,y) location of the pixel nearest the origin at (0,0)
        or (0.5,0.5)?

    OpenGL assumes a lower-left origin for window coordinates and assumes
    pixel centers are located at half-pixel coordinates.  This means
    the XY location (0.5,0.5) corresponds to the lower-left-most pixel
    in a window.

    Other window coordinate conventions exist for other rendering APIs.
    X11, GDI, and Direct3D version through DirectX 9 assume an upper-left
    window origin and locate pixel centers at integer XY values.
    By this alternative convention, the XY location (0,0) corresponds
    to the upper-left-most pixel in a window.

    Direct3D for DirectX 10 assumes an upper-left origin (as do prior
    DirectX versions) yet assumes half-pixel coordinates (unlike prior
    DirectX versions).  By the DirectX 10 convention, the XY location
    (0.5,0.5) corresponds to the upper-left-most pixel in a window.

    Fragment shaders can directly access the location of a given
    processed fragment in window space.  We call this location the
    "fragment coordinate".

    This extension provides a means for fragment shaders written in GLSL
    or OpenGL assembly extensions to specify alternative conventions
    for determining the fragment coordinate value accessed during
    programmable fragment processing.

    The motivation for this extension is to provide an easy, efficient
    means for fragment shaders accessing a fragment's window-space
    location to adopt the fragment coordinate convention for which the
    shader was originally written.

New Procedures and Functions

    None

New Tokens

    None

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

    None

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

    Modify Section 3.9.2, "Shader Execution"

    In subsection "Shader Inputs" replace the paragraph beginning "The
    built-in variable gl_FragCoord ..." with:

    "The built-in variable gl_FragCoord holds the fragment coordinate
    (x_f,y_f,z_f,w_f) for the fragment.  Computing the fragment coordinate
    depends on the fragment processing pixel-center and origin conventions
    (discussed below) as follows:

              { x_w - 0.5,   if the fragment processing pixel-center
       x_f  = {                 convention is integer
              { x_w,         otherwise

              { H - y_w,     if the fragment processing origin
       y_f' = {                 convention is upper-left
              {     y_w,     otherwise

              { y_f' - 0.5,  if the fragment processing pixel-center
       y_f  = {                 convention is integer
              { y_f',        otherwise

       z_f  = z_w

       w_f  = 1 / w_c

    where (x_w, y_w, z_w) is the fragment's window-space position, w_c
    is the w component of the fragment's clip-space position, and H is
    the window's height in pixels. Note that the value of z_w already
    has a polygon offset added in, if enabled (see section 3.6.4). Also
    z_f must be precisely 0 or 1 in the case where z_w is either 0 or 1
    respectively. The 1/w is computed from the w_c coordinate (see
    section 2.12), which is the result of the product of the projection
    matrix and the vertex's eye coordinates.

    Unless otherwise specified by layout qualifiers in the fragment
    shader (see section 4.3.x.1 "Input Layout Qualifier" of the OpenGL
    Shading Language Specification), the fragment processing
    pixel-center convention is half-integer and the fragment processing
    origin convention is lower-left."

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

    None

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

    None

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

    None

Additions to the AGL/GLX/WGL Specifications

    None

Additions to version 1.40.07 of the OpenGL Shading Language Specification

    "A new preprocessor #define is added to the OpenGL Shading Language:

      #define GL_ARB_fragment_coord_conventions 1

    Including the following line in a shader can be used to control the
    language features described in this extension:

      #extension GL_ARB_fragment_coord_conventions : <behavior>

    where <behavior> is as specified in section 3.3."

Additions to Chapter 4 of the OpenGL Shadering Language (Variables and Types)
version 1.40.07

    Add a new Section 4.3.x (Layout Qualifiers) as follows:

    "4.3.x Layout Qualifiers

    Layout qualifiers can appear with an individual variable declared with
    an interface qualifier:

        <layout-qualifier> <interface-qualifier> <declaration>;

        <layout-qualifier>:
            layout( <layout-qualifier-id-list> )

        <layout-qualifier-id-list>:
            comma separated list of <layout-qualifier-id>

        <interface-qualifier>:
            in
            out
            uniform

    Declarations of layouts can only be made at global scope, and only
    where indicated in the following subsection; their details are
    specific to what the interface qualifier is, and are discussed
    individually.

    The tokens in any <layout-qualifier-id-list> are identifiers, not
    keywords. Generally they can be listed in any order. Order-dependent
    meanings exist only if explicitly called out below. Similarily,
    these identifiers are not case-sensitive, unless explicitly noted
    otherwise.

    4.3.x.1 Input Layout Qualifiers

    Vertex shaders do not have any input layout qualifiers.

    Fragment shaders can have an input layout only for redeclaring the
    built-in variable gl_FragCoord (see section 7.2). The layout
    qualifier identifiers for gl_FragCoord are

        <layout-qualifier-id>
            origin_upper_left
            pixel_center_integer

    By default, gl_FragCoord assumes a lower-left origin for window
    coordinates and assumes pixel centers are located at half-pixel
    coordinates. For example, the (x, y) location (0.5, 0.5) is returned
    for the lower-left-most pixel in a window. The origin can be changed
    by redeclaring gl_FragCoord with the <origin_upper_left> identifier,
    moving the origin of gl_FragCoord to the upper left of the window,
    with y increasing in value toward the bottom of the window. The
    values returned can also be shifted by half a pixel in both x and y
    by the <pixel_center_integer> identifier so it appears the pixels
    are centered at whole number pixel offsets. This moves the (x, y)
    value returned by gl_FragCoord of (0.5, 0.5) by default, to (0.0,
    0.0) with <pixel_center_integer>. Redeclarations are done as follows

        in vec4 gl_FragCoord;  // redeclaration that changes nothing is allowed

        // All the following are allowed redeclarations that change behavior
        layout(origin_upper_left) in vec4 gl_FragCoord;
        layout(pixel_center_integer) in vec4 gl_FragCoord;
        layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

    If gl_FragCoord is redeclared in any fragment shader in a program,
    it must be redeclared in all the fragment shaders in that program
    that have a static use of gl_FragCoord. All redeclarations of
    gl_FragCoord in all fragment shaders in a single program must have
    the same set of qualifiers. Within any shader, the first
    redeclarations of gl_FragCoord must appear before any use of
    gl_FragCoord. The built-in gl_FragCoord is only predeclared in
    fragment shaders, so redeclaring it in any other shader language
    will be illegal.

    Redeclaring gl_FragCoord with <origin_upper_left> and/or
    <pixel_center_integer> qualifiers only affects gl_FragCoord.x and
    gl_FragCoord.y. It has no affect on rasterization, transformation,
    or any other part of the OpenGL pipeline or language features."


Dependencies on ARB_fragment_program extension

    3.11.3.1  Fragment Attributes

    Modify this paragraph:

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

    to read:

    "If a fragment attribute binding matches "fragment.position", the "x",
    "y", "z", and "w" components of the fragment attribute variable are
    filled with the (f_x,f_y,f_z,f_w) components respectively of the
    fragment coordinate for the fragment."

    Add this section:

   "3.11.4.5.3  Fragment Coordinate Conventions Fragment Program Options

    These options affect the fragment coordinate conventions specified
    in the "Shader Inputs" subsection of section 3.11.

    If a fragment program specifies one of the option
    "ARB_fragment_coord_origin_upper_left", the fragment processing origin
    convention is upper-left (and otherwise is lower-left) for purposes of
    computing the fragment coordinate when the fragment program executes.

    If a fragment program specifies one of the option
    "ARB_fragment_coord_pixel_center_integer", the fragment processing
    pixel-center convention is integer (and otherwise is half-integer)
    for purposes of computing the fragment coordinate when the fragment
    program executes."

Dependencies on NV_fragment_program extension

    When this extension is supported, modify the NV_fragment_program
    grammar to include:

    <program>              ::= <progPrefix> <optionSequence> <instructionSequence> "END"

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

    <option>               ::= "OPTION" "ARB_fragment_coord_origin_upper_left" ";"
                             | "OPTION" "ARB_fragment_coord_pixel_center_integer" ";"


    Section 3.11.1.1, Fragment Program Attribute Registers

    Modify this paragraph:

    "f[WPOS].x and f[WPOS].y hold the (x,y) window coordinates of the
    fragment center, and relative to the lower left corner of the window.
    f[WPOS].z holds the associated z window coordinate, normally in the
    range [0,1].  f[WPOS].w holds the reciprocal of the associated clip
    w coordinate."

    to read:

    "The f[WPOS] register holds the components (x_f,y_f,z_f,w_f)
    respectively of the fragment coordinate described in the "Shader
    Inputs" subsection of section 3.11 (Fragment Shaders).

    If the ARB_fragment_coord_origin_upper_left OPTION is specified, the
    fragment processing origin convention is upper-left (and otherwise
    is lower-left) for purposes of computing the fragment coordinate
    when the fragment program executes.

    If the ARB_fragment_coord_pixel_center_integer OPTION is specified,
    the fragment processing pixel-center convention is integer (and
    otherwise is half-integer) for purposes of computing the fragment
    coordinate when the fragment program executes."

Dependencies on NV_fragment_program4 extension

    The language this extension adds for the ARB_fragment_program extension
    also applies to the NV_fragment_program4 extension.  Specifically:

    The language added to section 3.11.3.1 (Fragment Attributes)
    replaces corresponding language in section 2.X.3.2 (Program Attribute
    Variables).

    The language added to section 3.11.4.5.3 (Fragment Coordinate
    Conventions Fragment Program Options) belongs in section 2.X.5.Y
    (Fragment Program Options) of the NV_fragment_program4 extension.

Dependencies on ARB_compatibility

    If ARB_compatibility is not supported, delete the clause
    "which is the result of the product of the projection matrix and the
    vertex's eye coordinates" in the sentence describing the computation of
    1/w, in section 3.9.2.

Errors

    None

New State

    None

New Implementation Dependent State

    None

Issues

    1. What should this extension be called?

       RESOLVED:  ARB_fragment_coord_conventions.

       We use "fragment" instead of "frag" in the name because other
       extension names (ARB_fragment_program, ARB_fragment_shader)
       use the term fragment.

       We use "coord" to match the EXT_fog_coord extension's naming.

       We use "conventions" because the extension provides two alternative
       choices of convention:  upper-left origin (instead of lower-left)
       and integer pixel center locations (instead of half-integer).

    2. To what scope of OpenGL functionality should this extension apply?

       RESOLVED:  This extension is limited to how the XY window-space
       coordinates available to fragment shaders and programs are
       computed.

       This extension does NOT affect other 2D window coordinates such
       as those passed to the glViewport, glReadPixels, glCopyPixels,
       or glWindowsPos commands.

    3. What is the primary goal of this extension have?

       RESOLVED:  The goal is to increase the cross-API portability
       of fragment shaders.  Most fragment shader inputs (texture
       coordinate sets, colors) are treated identically among OpenGL
       and other 3D APIs such as the various versions of Direct3D.
       The chief exception is the fragment coordinate XY values which
       depend on the 3D API's particular window space conventions.

       We seek to avoid situations where shader source code must
       be non-trivially modified to support differing window-space
       conventions.  We also want minimize the performance effect on
       fragment shader execution.  Rather than an application modifying
       the shader source to add extra operations and parameters/uniforms
       to adjust the native window coordinate origin, we want to control
       the hardware's underlying convention for how the window origin
       is provided to the shader.

    4. Should this extension provide an API for programmatically
       specifying a global or per-program/shader setting for the window
       coordinate origin?

       RESOLVED:  No, the fragment coordinate conventions are specified
       within the GLSL fragment shader or assembly source text only.

       The choice of convention for the fragment coordinate is best
       specified within the program.

       Having a hierarchy of alternative ways to specify the window
       coordinate origin makes this extension more cumbersome than
       necessary and increases driver validation overhead.

       The expectation is that a fragment shader authored for an API
       with alternative fragment coordinate conventions is converted
       into an OpenGL fragment shader.  In this case, it's natural to
       simply provide a way within the shader to express the originally
       intended fragment coordinate convention.

    5. Should this extension allow the pixel-center and origin choices
       to be specified orthogonally?

       RESOLVED:  Yes.

       Direct3D versions prior to DirectX 10 have an integer pixel-center
       convention while DirectX 10 has a half-integer pixel-center
       convention though all Direct3D versions use the upper-left origin.

       While RenderMan lacks access to a fragment coordinate during
       shading, it uses an upper-left origin while the half-integer
       pixel-center convention is most consistent with RenderMan's
       rendering operation.

       The upper-left origin convention in combination with the
       half-integer pixel-center convention is also interesting for
       developing compositing window systems since window systems
       typically assume an upper-left origin but compositing operations
       based on texture mapping works best with half-integer pixel-center
       convention.

    6. Should there be pragmas and OPTIONs for specifying both the OpenGL
       convention and the non-OpenGL convention?

       RESOLVED:  Just provide pragmas and OPTIONS for the non-OpenGL
       conventions.  This avoids have to specify how multiple inconsistent
       conventions are resolved.  Inconsistent conventions are more
       problematic for GLSL because multiple shader objects may be
       specified with inconsistent conventions and the inconsistency is
       then deferred until program object linking.

       Just allowing the non-OpenGL convention to be specified is simpler.
       For GLSL, if any shader object has a non-OpenGL convention
       specified, the convention applies to the linked program object.

    7. Does this extension apply to the NV_fragment_program_option and
       NV_fragment_program2 extensions?

       RESOLVED:  Yes.  These two extensions depend on the
       ARB_fragment_program extension grammar which this extension
       amends.

    8. Should there be any API for querying the fragment coordinate
       conventions a given GLSL fragment shader or assembly fragment
       program requests?

       RESOLVED:  No.

       There are not queries for other pragmas and OPTIONs.

       The text for the shader or program can be queried and it is easy
       enough to parse the text to determine the behavior of the program.

    9. This extension adds no new command or new tokens.  Is that ok?

       RESOLVED:  Yes.  The functionality of this extension is exercised
       by enabling extensions and OPTIONs in fragment shader/program source
       text.  If the extension string is advertised, you can assume the
       specified syntax is parsed and put into effect.

   10. Does the window origin convention apply to EXT_framebuffer_object
       (FBO) and pixel buffer (pbuffer) rendering as well as window
       rendering?

       RESOLVED:  Yes.

   11. Should this instead be a global state at the API level? This
       means that, among other things, it will also affect the fixed
       function pipeline?

       RESOLVED: The scope of this extension deals *only* with how the
       fragment coordinate XY location appears during programming
       fragment processing.

       See the Overview's third paragraph for the rationale for this
       extension's scope.

   12. For an implementation that does compile-time compilation (as
       opposed to link-time or on-the-fly compilation), this would
       appear to require the compiler to emit code to do the
       transformation using internal uniforms regardless of whether it
       is needed or not, because any other shader that it is linked
       against may enable the pragma.

       Some possible alternatives, none of which is caveat-free:
       a) Require all fragment shaders to be consistent in the presence
          or absence of the pragma. That makes it impossible to link a
          shader written with the pragma against a stock shader that
          doesn't do anything with gl_FragCoord.
       b) Apply the pragma only within the shader it appears in. That
          removes the spooky action at a distance (where linking another
          shader in changes the behaviour of an existing one) - but if
          your hardware has some magic knobs to implement these pragmas,
          that may no longer be sufficient if there are multiple
          flavours of gl_FragCoord in the same program.
       c) Make this global state. See Issue 11.

       RESOLVED:  Because this extension's pragmas only support requesting
       a half-pixel fragment coordinate system and/or an upper-left
       coordinate system, there is no way for multiple fragment shader
       objects to specify an inconsistent fragment coordinate system.
       This means for a given set of fragment shaders being linked
       into a program object, there is exactly one fragment coordinate
       convention.

       (Fragment coordinate conventions are parsed and ignored for
       non-fragment shader objects.  Generating a warning in the info
       log when the pragma is ignored by non-fragment shader objects is
       a reasonable response in this situation.)

       Option b is not desirable because there should be exactly one
       convention within a single linked program object.  Each fragment
       shader object linked within a program object should not be allowed
       its own convention.  The expected usage is shaders written for
       DirectX 9 or 10 will be compiled with these pragmas appropriately;
       such shaders only need one convention.  This extension assumes
       implementations supporting this extension likely have hardware
       modes that support both the OpenGL, DirectX 9, and DirectX 10
       conventions for a given fragment shader without require extra
       hidden uniforms.

       Option c is not desirable because the fragment coordinate
       convention really is a property of each shader rather than
       global state.  A shader assuming OpenGL's conventional lower-left
       convention expects to be able to add (0,1) to the fragment's
       (x,y) location and move "up" a pixel.  Whereas a similar shader
       coded for Direct3D would assume adding (0,1) to the fragment's
       (x,y) would move "down" a pixel.  Controlling the fragment
       coordinate convention from a global state setting is irrelevant to
       fixed-function processing (where the fragment coordinate position
       is never available).

       NOTE: much of the above discussion is largely irrelevant now that
       this extension uses layout qualifiers.  As noted in the
       shading language additions above, all redeclarations of gl_FragCoord
       must use the same set of qualifiers.  If a shader does not have a
       static use of gl_FragCoord it doesn't need to redeclare it. It is
       link-time error if multiple compilation units have inconsistent
       qualifiers.

   13. Is this "pragma" enough to provide DX compatibility? The
       following items may need to be addressed as well:
       a) edge rule: because of the y-inversion, rendering in DX mode or
          OGL mode is not equivalent (upper and lower edges are not
          rendered the same)
       b) gl_FragCoord value: this is addressed by this proposal
       c) viewport/scissor: if the shader is changed, it seems that
          there will be a mismatch with the value given to
          viewport/scissor which need to have the y-inversion as well.
       d) face ordering: if this adjusts the viewport, it will
          implicitly toggle the face ordering between CW and CCW.
       e) sample position?

       RESOLVED:  The scope of this extension deals *only* with how
       the fragment coordinate XY location appears during programming
       fragment processing.

       Trying to address these is a much bigger undertaking than was
       intended here, and is precisely why it was speced this way (to
       avoid touching these issues).

       See the Overview's third paragraph for the rationale for this
       extension's scope.

   14. Could this instead be done with functions (built-in or otherwise)
       in GLSL? Since the purpose of this extension seems to be to
       *ONLY* modify the gl_FragCoord when accessed in the fragment
       shader, couldn't one just write a GLSL function which does the
       same thing?

       RESOLVED:  The scope of this extension is really limited to
       support the straightforward translation of shaders written assuming
       Direct3D's fragment coordinate conventions into OpenGL.

       The intent is NOT to allow multiple conventions to be used with
       in the fragment domain of a single program object.

       The intent is also to support Direct3D's fragment coordinate
       conventions in a way that can leverage existing hardware modes
       used to support both OpenGL and Direct3D.  This is desirable
       because it avoids the introduction of extra "hidden" uniforms
       (to store a value such as the current window height).

       If you support a "different" gl_FragCoord or provide a function
       to return a Direct3D-style fragment coordinate, that introduces
       the possibility that multiple fragment coordinate conventions can
       exist in the same fragment shader program.  The pragma approach
       precludes this.

   15. Is the intent that the window origin convention is automatically
       adjusted for onscreen (in a window) vs offscreen rendering (FBOs
       or pbuffers)? ie if you have a fragment shader which is used with
       both onscreen and offscreen rendering is it the application's
       responsibility to track this and specify the appropriate window
       convention (and potentially recompile the shader), or does this
       happen automatically.

       RESOLVED:  The fragment coordinate convention is specified with
       respect to OpenGL window coordinates.

       This means developers don't need to be aware if they are rendering
       to a framebuffer object (FBO), pixel buffer (pbuffer), or window.

       The application doesn't have to "track" how the fragment shader
       is used.

       The expectation is that there is no need to recompile a fragment
       shader as the expectation is hardware modes exist to control the
       window space origin appropriately.

   16. Is there another way this could be specified other than a
       #pragma? Some people aren't keen on the use of a pragma for this.
       Other possibilities include providing a renamed gl_FragCoord with
       the different semantics, or allowing gl_FragCoord to be redefined
       in the shader with the desired qualifiers (similar to the
       invariant qualifier)?

       RESOLVED: Yes. This has been recast to use layout qualifiers
       originally introduced in GLSL 1.40 and extended in GLSL 1.50.
       However note that it is the intent of this extension to stand
       separately from the GLSL 1.40/1.50 and it is desinged to be
       implementable against GLSL 1.10 or 1.20.

   17. If this extension doesn't actually change how the window space
       positions are calculated and *only* modifies the gl_FragCoord
       which is visible in the fragment shader/program, how does this
       actually help an application which is using shaders which have
       the assumption of integer pixel centers baked in (and thus
       manually adjusting for the 0.5 offset) and which aren't accessing
       gl_FragCoord (or equivalent) directly?

       RESOLVED:  The scope of this extension deals *only* with how
       the fragment coordinate XY location appears during programming
       fragment processing.

       See the Overview's third paragraph for the rationale for this
       extension's scope.

       This extension simplifies the complicating task of converting
       OpenGL-style (lower-left, half-pixel) fragment coordinates to
       Direct3D-style fragment coordinates in a way that allows existing
       hardware mechanisms to support both OpenGL and Direct3D's
       conventions to be leveraged. In particular, "hidden" uniforms to
       track the current window height can be avoided when this is often
       already maintained by the hardware.

Revision History

    Rev.    Date    Author     Changes
    ----  -------- ---------  ----------------------------------------
      1   1/08/07  mjk        Initial version
      2   11/5/08  mjk        Feedback from Destineer
      3   3/27/09  dgkoch     Add issue 11
      4   5/01/09  dgkoch     fix typo, add discussion on issue 11
                              add issues 12,13 based on comments from PB and BM
      5   5/07/09  dgkoch     Update issue 13, add issues 14-17
      6   5/11/09  mjk        Work with Daniel Koch too:
                              Improve overview to clarify the extension's scope
                              Add resolutions to issues 11 through 17
                              Change language to make clear that pragmas apply
                              to fragment shaders only; they are accepted but
                              totally ignored for other shader types
      7   5/15/09  dgkoch     fix date and a few typos
      8   5/19/09  dgkoch     renamed as ARB extension
      9   6/26/09  dgkoch     add #extension mechanism
                              recast GLSL using layout qualifiers as in GLSL 1.50
                              synced up with GL3.2 changes/rebased on GL3.1
                              updated some issue resolutions
                              added interactions with ARB_compatibility
     10   8/02/09  Jon Leech  Reformat to 80 columns and assign ARB
                              extension number.