Merge branch 'master' of git+ssh://[email protected]/git/mesa/mesa into 965-glsl

15 files changed, 1305 insertions, 358 deletions

diff --git a/docs/MESA_texture_array.spec b/docs/MESA_texture_array.spec
new file mode 100644
index 00000000000..d3b77521151
--- /dev/null
+++ b/docs/MESA_texture_array.spec
@@ -0,0 +1,805 @@
+Name
+
+    MESA_texture_array
+
+Name Strings
+
+    GL_MESA_texture_array
+
+Contact
+
+    Ian Romanick, IBM (idr 'at' us.ibm.com)
+
+IP Status
+
+    No known IP issues.
+
+Status
+
+    Shipping in Mesa 7.1
+
+Version
+
+    $Date: 2007/05/16$ $Revision: 0.4$
+
+Number
+
+    TBD
+
+Dependencies
+
+    OpenGL 1.2 or GL_EXT_texture3D is required.
+
+    Support for ARB_fragment_program is assumed, but not required.
+
+    Support for ARB_fragment_program_shadow is assumed, but not required.
+
+    Support for EXT_framebuffer_object is assumed, but not required.
+
+    Written based on the wording of the OpenGL 2.0 specification and
+    ARB_fragment_program_shadow but not dependent on them.
+
+Overview
+
+    There are a number of circumstances where an application may wish to
+    blend two textures out of a larger set of textures.  Moreover, in some
+    cases the selected textures may vary on a per-fragment basis within
+    a polygon.  Several examples include:
+
+       1. High dynamic range textures.  The application stores several
+       different "exposures" of an image as different textures.  On a
+       per-fragment basis, the application selects which exposures are
+       used.
+
+       2. A terrain engine where the altitude of a point determines the
+       texture applied to it.  If the transition is from beach sand to
+       grass to rocks to snow, the application will store each texture
+       in a different texture map, and dynamically select which two
+       textures to blend at run-time.
+
+       3. Storing short video clips in textures.  Each depth slice is a
+       single frame of video.
+
+    Several solutions to this problem have been proposed, but they either
+    involve using a separate texture unit for each texture map or using 3D
+    textures without mipmaps.  Both of these options have major drawbacks.
+
+    This extension provides a third alternative that eliminates the major
+    drawbacks of both previous methods.  A new texture target,
+    TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
+    all aspects except the sizes of the non-base level images.  In
+    traditional 3D texturing, the size of the N+1 LOD is half the size
+    of the N LOD in all three dimensions.  For the TEXTURE_2D_ARRAY target,
+    the height and width of the N+1 LOD is halved, but the depth is the
+    same for all levels of detail. The texture then becomes an array of
+    2D textures.  The per-fragment texel is selected by the R texture
+    coordinate.
+
+    References:
+
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
+        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
+        http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
+
+New Procedures and Functions
+
+    All functions come directly from EXT_texture_array.
+
+    void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                    uint texture, int level, int layer);
+
+New Tokens
+
+    All token names and values come directly from EXT_texture_array.
+
+    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
+    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
+    GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
+    GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
+    GetTexParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT                            0x8C18
+        TEXTURE_2D_ARRAY_EXT                            0x8C1A
+
+    Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
+    CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
+    CompressedTexSubImage2D, GetTexLevelParameteriv, and 
+    GetTexLevelParameterfv:
+
+        TEXTURE_1D_ARRAY_EXT
+        PROXY_TEXTURE_1D_ARRAY_EXT                      0x8C19
+
+    Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
+    CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
+    GetTexLevelParameteriv, and GetTexLevelParameterfv:
+
+        TEXTURE_2D_ARRAY_EXT
+        PROXY_TEXTURE_2D_ARRAY_EXT                      0x8C1B
+
+    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+    GetFloatv, and GetDoublev
+
+        TEXTURE_BINDING_1D_ARRAY_EXT                    0x8C1C
+        TEXTURE_BINDING_2D_ARRAY_EXT                    0x8C1D
+        MAX_ARRAY_TEXTURE_LAYERS_EXT                    0x88FF
+
+    Accepted by the <param> parameter of TexParameterf, TexParameteri,
+    TexParameterfv, and TexParameteriv when the <pname> parameter is
+    TEXTURE_COMPARE_MODE_ARB:
+
+        COMPARE_REF_DEPTH_TO_TEXTURE_EXT                0x884E
+
+    (Note:  COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
+    existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
+    reflects the fact that the R coordinate is not always used.)
+
+    Accepted by the <internalformat> parameter of TexImage3D and
+    CompressedTexImage3D, and by the <format> parameter of
+    CompressedTexSubImage3D:
+
+        COMPRESSED_RGB_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT1_EXT
+        COMPRESSED_RGBA_S3TC_DXT3_EXT
+        COMPRESSED_RGBA_S3TC_DXT5_EXT
+
+    Accepted by the <pname> parameter of
+    GetFramebufferAttachmentParameterivEXT:
+
+        FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT          0x8CD4
+
+    (Note:  FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
+    FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
+    EXT_framebuffer_object.  This extension generalizes the notion of
+    "<zoffset>" to include layers of an array texture.)
+
+Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
+
+    None
+
+Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
+
+    -- Section 3.8.1 "Texture Image Specification"
+
+       Change the first paragraph (page 150) to say (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void TexImage3D(enum target, int level, int internalformat,
+                         sizei width, sizei height, sizei depth, int border,
+                         enum format, enum type, void *data);
+
+       is used to specify a three-dimensional texture image. target must be one
+       one of TEXTURE_3D for a three-dimensional texture or
+       TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
+       Additionally, target may be either PROXY_TEXTURE_3D for a
+       three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
+       two-dimensional proxy array texture."
+
+       Change the fourth paragraph on page 151 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Textures with a base internal format of DEPTH_COMPONENT are supported
+       by texture image specification commands only if target is TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
+       PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
+       PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
+       other target will result in an INVALID_OPERATION error."
+
+
+       Change the fourth paragraph on page 156 to say (spec changes identical
+       to EXT_texture_array):
+       
+       "The command
+
+         void TexImage2D(enum target, int level,
+                         int internalformat, sizei width, sizei height,
+                         int border, enum format, enum type, void *data);
+
+       is used to specify a two-dimensional texture image. target must be one
+       of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
+       one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
+       target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
+       texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
+       texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
+       special case discussed in section 3.8.11.  The other parameters match
+       the corresponding parameters of TexImage3D.
+
+       For the purposes of decoding the texture image, TexImage2D is
+       equivalent to calling TexImage3D with corresponding arguments and depth
+       of 1, except that
+
+         * The border depth, d_b, is zero, and the depth of the image is
+           always 1 regardless of the value of border. 
+
+         * The border height, h_b, is zero if <target> is
+           TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
+
+         * Convolution will be performed on the image (possibly changing its
+           width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
+
+         * UNPACK SKIP IMAGES is ignored."
+
+    -- Section 3.8.2 "Alternate Texture Image Specification Commands"
+
+       Change the second paragraph (page 159) (spec changes identical
+       to EXT_texture_array):
+
+       "The command
+
+         void CopyTexImage2D(enum target, int level,
+                             enum internalformat, int x, int y, sizei width,
+                             sizei height, int border);
+
+       defines a two-dimensional texture image in exactly the manner of
+       TexImage2D, except that the image data are taken from the framebuffer
+       rather than from client memory. Currently, target must be one of
+       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
+       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
+       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
+       TEXTURE_CUBE_MAP_NEGATIVE_Z.
+
+
+       Change the last paragraph on page 160 to say (spec changes identical
+       to EXT_texture_array):
+
+       "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
+       must be TEXTURE_1D, the target arguments of TexSubImage2D and
+       CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
+       TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
+       TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
+       TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
+       target arguments of TexSubImage3D and CopyTexSubImage3D must be
+       TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
+
+
+    -- Section 3.8.4 "Texture Parameters"
+
+       Change the first paragraph (page 166) to say:
+
+       "Various parameters control how the texel array is treated when
+       specified or changed, and when applied to a fragment. Each parameter is
+       set by calling
+
+         void TexParameter{if}(enum target, enum pname, T param); 
+         void TexParameter{if}v(enum target, enum pname, T params);
+
+       target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
+
+
+    -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
+
+       Change the first paragraph (page 172) to say:
+
+       "Let s(x,y) be the function that associates an s texture coordinate
+       with each set of window coordinates (x,y) that lie within a primitive;
+       define t(x,y) and r(x,y) analogously.  Let u(x,y) = w_t * s(x,y),
+       v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
+       and d_t are as defined by equations 3.15, 3.16, and 3.17 with
+       w_s, h_s, and d_s equal to the width, height, and depth of the
+       image array whose level is level_base.  For a one-dimensional
+       texture or a one-dimensional array texture, define v(x,y) = 0 and
+       w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
+       texture, define w(x,y) = 0..."
+
+    -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
+
+       Change the third paragraph (page 174) to say:
+       
+       "For a two-dimensional texture, two-dimensional array texture, or
+       cube map texture,"
+
+       Change the fourth paragraph (page 174) to say:
+
+       "And for a one-dimensional texture or a one-dimensional array texture,"
+
+       After the first paragraph (page 175) add:
+
+       "For one-dimensional array textures, h_b and d_b are treated as 1,
+       regardless of the actual values, when performing mipmap calculations.
+       For two-dimensional array textures, d_b is always treated as one,
+       regardless of the actual value, when performing mipmap calculations."
+
+    -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
+
+       Change the third paragraph (page 176) to say (spec changes identical
+       to EXT_texture_array):
+
+       "The contents of the derived arrays are computed by repeated, filtered
+       reduction of the level_base array.  For one- and two-dimensional array
+       textures, each layer is filtered independently.  ..."
+
+    -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
+
+       Change first paragraph to say (spec changes identical to
+       EXT_texture_array):
+
+       "Mipmaps can be generated manually with the command
+
+         void GenerateMipmapEXT(enum target);
+
+       where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
+       TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY.  Mipmap generation
+       affects the texture image attached to <target>.  ..."
+
+    -- Section 3.8.10 "Texture Completeness"
+
+       Change the second paragaph (page 177) to say (spec changes identical
+       to EXT_texture_array):
+
+       "For one-, two-, or three-dimensional textures and one- or
+       two-dimensional array textures, a texture is complete if the following
+       conditions all hold true:"
+
+    -- Section 3.8.11 "Texture State and Proxy State"
+
+       Change the second and third paragraphs (page 179) to say (spec changes
+       identical to EXT_texture_array):
+
+       "In addition to image arrays for one-, two-, and three-dimensional
+       textures, one- and two-dimensional array textures, and the six image
+       arrays for the cube map texture, partially instantiated image arrays
+       are maintained for one-, two-, and three-dimensional textures and one-
+       and two-dimensional array textures.  Additionally, a single proxy image
+       array is maintained for the cube map texture.  Each proxy image array
+       includes width, height, depth, border width, and internal format state
+       values, as well as state for the red, green, blue, alpha, luminance,
+       and intensity component resolutions. Proxy image arrays do not include
+       image data, nor do they include texture properties. When TexImage3D is
+       executed with target specified as PROXY_TEXTURE_3D, the
+       three-dimensional proxy state values of the specified level-of-detail
+       are recomputed and updated. If the image array would not be supported
+       by TexImage3D called with target set to TEXTURE 3D, no error is
+       generated, but the proxy width, height, depth, border width, and
+       component resolutions are set to zero. If the image array would be
+       supported by such a call to TexImage3D, the proxy state values are set
+       exactly as though the actual image array were being specified. No pixel
+       data are transferred or processed in either case.
+
+       Proxy arrays for one- and two-dimensional textures and one- and
+       two-dimensional array textures are operated on in the same way when
+       TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
+       TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
+       PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
+       specified as PROXY_TETXURE_2D_ARRAY_EXT."
+
+    -- Section 3.8.12 "Texture Objects"
+
+       Change section (page 180) to say (spec changes identical to 
+       EXT_texture_array):
+
+       "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
+       TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
+       named one-, two-, and three-dimensional, cube map, and one- and
+       two-dimensional array texture objects can be created and operated upon.
+       The name space for texture objects is the unsigned integers, with zero
+       reserved by the GL.
+
+       A texture object is created by binding an unused name to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
+
+         void BindTexture(enum target, uint texture);
+
+       with <target> set to the desired texture target and <texture> set to
+       the unused name.  The resulting texture object is a new state vector,
+       comprising all the state values listed in section 3.8.11, set to the
+       same initial values. If the new texture object is bound to TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
+       three-dimensional, cube map, one- or two-dimensional array texture
+       respectively until it is deleted.
+
+       BindTexture may also be used to bind an existing texture object to
+       either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
+       INVALID_OPERATION is generated if an attempt is made to bind a texture
+       object of different dimensionality than the specified target. If the
+       bind is successful no change is made to the state of the bound texture
+       object, and any previous binding to target is broken.
+
+       While a texture object is bound, GL operations on the target to which
+       it is bound affect the bound object, and queries of the target to which
+       it is bound return state from the bound object. If texture mapping of
+       the dimensionality of the target to which a texture object is bound is
+       enabled, the state of the bound texture object directs the texturing
+       operation.
+
+       In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
+       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
+       one-, two-, three-dimensional, cube map, and one- and two-dimensional
+       array texture state vectors respectively associated with them. In order
+       that access to these initial textures not be lost, they are treated as
+       texture objects all of whose names are 0. The initial one-, two-,
+       three-dimensional, cube map, one- and two-dimensional array textures
+       are therefore operated upon, queried, and applied as TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
+       TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
+       targets.
+
+       Change second paragraph on page 181 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "...  If a texture that is currently bound to one of the targets
+       TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
+       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
+       though BindTexture had been executed with the same target and texture
+       zero. ..."
+
+       Change second paragraph on page 182 to say (spec changes identical to 
+       EXT_texture_array):
+       
+       "The texture object name space, including the initial one-, two-, and
+       three dimensional, cube map, and one- and two-dimensional array texture
+       objects, is shared among all texture units. ..."
+
+
+    -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
+
+       Change second through fourth paragraphs (page 188) to say:
+
+       "Let D_t be the depth texture value, in the range [0, 1].  For
+       texture lookups from one- and two-dimesional, rectangle, and
+       one-dimensional array targets, let R be the interpolated <r>
+       texture coordinate, clamped to the range [0, 1].  For texture lookups
+       from two-dimesional array texture targets, let R be the interpolated
+       <q> texture coordinate, clamped to the range [0, 1].  Then the
+       effective texture value L_t, I_t, or A_t is computed as follows:
+
+       If the value of TEXTURE_COMPARE_MODE is NONE, then
+
+          r = Dt
+
+       If the value of TEXTURE_COMPARE_MODE is
+       COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
+       comparison function as shown in table 3.27."
+
+    -- Section 3.8.15 "Texture Application"
+
+       Change the first paragraph (page 189) to say:
+
+       "Texturing is enabled or disabled using the generic Enable and Disable
+       commands, respectively, with the symbolic constants TEXTURE_1D,
+       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
+       TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
+       map, one-dimensional array, or two-dimensional array texture,
+       respectively.  If both two- and one-dimensional textures are enabled,
+       the two-dimensional texture is used.  If the three-dimensional and
+       either of the two- or one-dimensional textures is enabled, the
+       three-dimensional texture is used.  If the cube map texture and any of
+       the three-, two-, or one-dimensional textures is enabled, then cube map
+       texturing is used.  If one-dimensional array texture is enabled and any
+       of cube map, three-, two-, or one-dimensional textures is enabled, 
+       one-dimensional array texturing is used.  If two-dimensional array
+       texture is enabled and any of cube map, three-, two-, one-dimensional
+       textures or one-dimensional array texture is enabled, two-dimensional
+       array texturing is used..."
+
+    -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
+
+       (mostly add to existing grammar rules)
+
+       <optionName>           ::= "MESA_texture_array"
+
+       <texTarget>            ::= "1D"
+                               | "2D"
+                               | "3D"
+                               | "CUBE"
+                               | "RECT"
+                               | <arrayTarget> (if program option is present)
+                               | <shadowTarget> (if program option is present)
+
+       <arrayTarget>          ::= "ARRAY1D"
+                               | "ARRAY2D"
+
+       <shadowTarget>         ::= "SHADOW1D"
+                               | "SHADOW2D"
+                               | "SHADOWRECT"
+                               | <shadowArrayTarget> (if program option is present)
+
+       <shadowArrayTarget>    ::= "SHADOWARRAY1D"
+                               | "SHADOWARRAY2D"
+
+
+    -- Add Section 3.11.4.5.4 "Texture Stack Option"
+
+       "If a fragment program specifies the "MESA_texture_array" program
+       option, the <texTarget> rule is modified to add the texture targets
+       ARRAY1D and ARRAY2D (See Section 3.11.2)."
+
+    -- Section 3.11.6 "Fragment Program Texture Instruction Set"
+
+       (replace 1st and 2nd paragraphs with the following paragraphs)
+
+       "The first three texture instructions described below specify the
+       mapping of 4-tuple input vectors to 4-tuple output vectors.
+       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, ARRAY1D, ARRAY2D).  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(vec4 coord, float lodBias, int texImageUnit,
+                            enum texTarget);
+
+       Note that not all four components of the texture coordinates <coord>
+       are used by all texture targets.  Component usage for each <texTarget>
+       is defined in table X.
+
+                                                        coordinates used
+         texTarget          Texture Type               s t r  layer  shadow
+         ----------------   ---------------------      -----  -----  ------
+         1D                 TEXTURE_1D                 x - -    -      -
+         2D                 TEXTURE_2D                 x y -    -      -
+         3D                 TEXTURE_3D                 x y z    -      -
+         CUBE               TEXTURE_CUBE_MAP           x y z    -      -
+         RECT               TEXTURE_RECTANGLE_ARB      x y -    -      -
+         ARRAY1D            TEXTURE_1D_ARRAY_EXT       x - -    y      -
+         ARRAY2D            TEXTURE_2D_ARRAY_EXT       x y -    z      -
+         SHADOW1D           TEXTURE_1D                 x - -    -      z
+         SHADOW2D           TEXTURE_2D                 x y -    -      z
+         SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    -      z
+         SHADOWARRAY1D      TEXTURE_1D_ARRAY_EXT       x - -    y      z
+         SHADOWARRAY2D      TEXTURE_2D_ARRAY_EXT       x y -    z      w
+
+         Table X:  Texture types accessed for each of the <texTarget>, and
+         coordinate mappings.  The "coordinates used" column indicate the
+         input values used for each coordinate of the texture lookup, the
+         layer selector for array textures, and the reference value for
+         texture comparisons."
+
+    -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
+    
+       Add to the end of the section:
+       
+       "A program will fail to load if the TXP instruction is used in
+       conjunction with the SHADOWARRAY2D target."
+
+Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
+
+    -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
+
+       Add to the end of the section (spec changes identical to
+       EXT_texture_array):
+
+       "The command
+
+         void FramebufferTextureLayerEXT(enum target, enum attachment,
+                                         uint texture, int level, int layer);
+
+       operates identically to FramebufferTexture3DEXT, except that it
+       attaches a single layer of a three-dimensional texture or a one- or
+       two-dimensional array texture.  <layer> is an integer indicating the
+       layer number, and is treated identically to the <zoffset> parameter in
+       FramebufferTexture3DEXT.  The error INVALID_VALUE is generated if
+       <layer> is negative.  The error INVALID_OPERATION is generated if
+       <texture> is non-zero and is not the name of a three dimensional
+       texture or one- or two-dimensional array texture.  Unlike
+       FramebufferTexture3D, no <textarget> parameter is accepted.
+
+       If <texture> is non-zero and the command does not result in an error,
+       the framebuffer attachment state corresponding to <attachment> is
+       updated as in the other FramebufferTexture commands, except that
+       FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
+
+    -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
+
+      Add to the end of the list of completeness rules (spec changes
+      identical to EXT_texture_array):
+
+        "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
+           FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or 
+           two-dimensional array texture, then
+           FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
+           number of layers in the texture."
+
+Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
+
+    -- Section 5.4 "Display Lists"
+
+       Change the first paragraphi on page 242 to say (spec changes
+       identical to EXT_texture_array):
+
+       "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
+       executed immediately when called with the corresponding proxy arguments
+       PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
+       PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
+       PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
+       PROXY_POST_CONVOLUTION_COLOR_TABLE, or
+       PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
+
+Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
+
+    -- Section 6.1.3 "Enumerated Queries"
+
+       Add after the line beginning "If the value of
+       FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
+       identical to EXT_texture_array):
+
+       "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
+       texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
+       three-dimensional texture or a one- or two-dimensional array texture,
+       then <params> will contain the number of texture layer attached to the
+       attachment point.  Otherwise, <params> will contain the value zero."
+
+    -- Section 6.1.4 "Texture Queries"
+    
+       Change the first three paragraphs (page 248) to say (spec changes
+       identical to EXT_texture_array):
+
+       "The command
+
+         void GetTexImage(enum tex, int lod, enum format,
+                          enum type, void *img);
+
+       is used to obtain texture images. It is somewhat different from the
+       other get commands; tex is a symbolic value indicating which texture
+       (or texture face in the case of a cube map texture target name) is to
+       be obtained.  TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
+       and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
+       texture, or one- or two-dimensional array texture, respectively.
+       TEXTURE_CUBE_MAP_POSITIVE_X, ...
+
+       GetTexImage obtains... from the first image to the last for
+       three-dimensional textures.  One- and two-dimensional array textures
+       are treated as two- and three-dimensional images, respectively, where
+       the layers are treated as rows or images.  These groups are then...
+
+       For three-dimensional and two-dimensional array textures, pixel storage
+       operations are applied as if the image were two-dimensional, except
+       that the additional pixel storage state values PACK_IMAGE_HEIGHT and
+       PACK_SKIP_IMAGES are applied. ..."
+
+Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
+
+    None
+
+Additions to the AGL/GLX/WGL Specifications
+
+    None
+
+GLX Protocol
+
+    None
+
+Dependencies on ARB_fragment_program
+
+    If ARB_fragment_program is not supported, the changes to section 3.11
+    should be ignored.
+
+Dependencies on EXT_framebuffer_object
+
+    If EXT_framebuffer_object is not supported, the changes to section
+    3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
+
+Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
+
+    (Identical dependency as EXT_texture_array.)
+
+    S3TC texture compression is supported for two-dimensional array textures.
+    When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
+    as a compressed two-dimensional textures.  When specifying or querying
+    compressed images using one of the S3TC formats, the images are provided
+    and/or returned as a series of two-dimensional textures stored
+    consecutively in memory, with the layer closest to zero specified first.
+    For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
+    the three-dimensional compression format provided in the
+    EXT_texture_compression_vtc extension.  Pixel store parameters, including
+    those specific to three-dimensional images, are ignored when compressed
+    image data are provided or returned, as in the
+    EXT_texture_compression_s3tc extension.
+
+    S3TC compression is not supported for one-dimensional texture targets in
+    EXT_texture_compression_s3tc, and is not supported for one-dimensional
+    array textures in this extension.  If compressed one-dimensional arrays
+    are needed, use a two-dimensional texture with a height of one.
+
+    This extension allows the use of the four S3TC internal format types in
+    TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
+
+Errors
+
+    None
+
+New State
+
+    (add to table 6.15, p. 276)
+
+                                                     Initial
+    Get Value                     Type   Get Command  Value Description           Sec.    Attribute
+    ----------------------------  -----  -----------  ----- --------------------  ------  ---------
+    TEXTURE_BINDING_1D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_1D_ARRAY
+    TEXTURE_BINDING_2D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
+                                                            to TEXTURE_2D_ARRAY
+
+
+New Implementation Dependent State
+
+    (add to Table 6.32, p. 293)
+
+                                                    Minimum
+    Get Value                     Type  Get Command  Value  Description         Sec.  Attribute
+    ----------------------------  ----  ----------- ------- ------------------  ----- ---------
+    MAX_TEXTURE_ARRAY_LAYERS_EXT   Z+   GetIntegerv   64    maximum number of   3.8.1     -
+                                                            layers for texture
+                                                            arrays
+
+Issues
+
+    (1) Is "texture stack" a good name for this functionality?
+
+        NO.  The name is changed to "array texture" to match the
+        nomenclature used by GL_EXT_texture_array.
+
+    (2) Should the R texture coordinate be treated as normalized or
+    un-normalized?  If it were un-normalized, floor(R) could be thought
+    of as a direct index into the array texture.  This may be more
+    convenient for applications.
+
+        RESOLVED.  All texture coordinates are normalized.  The issue of
+        un-normalized texture coordinates has been discussed in the ARB
+        before and should be left for a layered extension.
+
+        RE-RESOLVED.  The R coordinate is un-normalized.  Accessing an array
+        using [0, layers-1] coordinates is much more natural.
+
+    (3) How does LOD selection work for stacked textures?
+
+        RESOLVED.  For 2D array textures the R coordinate is ignored, and
+        the LOD selection equations for 2D textures are used.  For 1D
+        array textures the T coordinate is ignored, and the LOD selection
+        equations for 1D textures are used.  The expected usage is in a
+        fragment program with an explicit LOD selection.
+
+    (4) What is the maximum size of a 2D array texture?  Is it the same
+    as for a 3D texture, or should a new query be added?  How about for 1D
+    array textures?
+
+        RESOLVED.  A new query is added.
+
+    (5) How are array textures exposed in GLSL?
+    
+        RESOLVED.  Use GL_EXT_texture_array.
+        
+    (6) Should a 1D array texture also be exposed?
+
+        RESOLVED.  For orthogonality, yes.
+
+    (7) How are stacked textures attached to framebuffer objects?
+
+        RESOLVED.  Layers of both one- and two-dimensional array textures
+        are attached using FreambufferTextureLayerEXT.  Once attached, the
+        array texture layer behaves exactly as either a one- or
+        two-dimensional texture.
+
+    (8) How is this extension related to GL_EXT_texture_array?
+    
+        This extension adapats GL_MESAX_texture_stack to the notation,
+        indexing, and FBO access of GL_EXT_texture_array.  This extension
+        replaces the GLSL support of GL_EXT_texture_array with
+        GL_ARB_fragment_program support.
+
+        Assembly program support is also provided by GL_NV_gpu_program4.
+        GL_NV_gpu_program4 also adds support for other features that are
+        specific to Nvidia hardware, while this extension adds only support
+        for array textures.
+
+        Much of text of this extension that has changed since
+        GL_MESAX_texture_stack comes directly from either
+        GL_EXT_texture_array or GL_NV_gpu_program4.
+
+Revision History
+
+    ||2005/11/15||0.1||idr||Initial draft MESAX version.||
+    ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
+    ||2005/12/12||0.3||idr||Updated fragment program interactions.||
+    ||2007/05/16||0.4||idr||Converted to MESA_texture_array.  Brought in line with EXT_texture_array and NV_gpu_program4.||
diff --git a/docs/MiniGLX.html b/docs/MiniGLX.html
index 3429812993a..e7ebae68519 100644
--- a/docs/MiniGLX.html
+++ b/docs/MiniGLX.html
@@ -88,19 +88,6 @@ driver (such as <code>radeon_dri.so</code>) at runtime. &nbsp;The
 environment variable <code>LIBGL_DRIVERS_PATH</code> should name the
 directory where these modules are located.<br>
 <br>
-Prior to running a MiniGXL application, the following kernel modules
-must be installed:<br>
-<br>
-<div style="margin-left: 40px;"> agpgart.o<br>
-radeonfb.o &nbsp;(assuming Radeon hardware)<br>
-radeon.o &nbsp;(assuming Radeon hardware)<br>
-</div>
-<code></code> <br>
-Finally, MiniGLX reads a configuration file (by default,<code>
-/etc/miniglx.conf</code>) to determine basic configuration information.
-&nbsp;The configuration file may also be located in the directory
-specified by the <code>MINIGLX_CONF</code> environment variable).<br>
-<br>
 The remainder of this section describes the MiniGLX API functions.<br>
 <br>
 <h2>3.1 Initialization</h2>
diff --git a/docs/README.WIN32 b/docs/README.WIN32
index 8dc59b00fd4..ce595076bd5 100644
--- a/docs/README.WIN32
+++ b/docs/README.WIN32
@@ -1,155 +1,163 @@
-File: docs/README.WIN32
-
-Last updated: Mar 31, 2006 - Karl Schultz - [email protected]
-
-Quick Start
------ -----
-
-Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same
-directory.  The libs and demos build separately, so if you do not care
-about the demos or GLUT, you only need to unzip MesaLib.  If you unzip
-more than one ZIP file, they all need to be unzipped into the same
-directory.  Don't worry, you will not overwrite anything.
-
-The Windows build system uses Microsoft Visual Studio.  Project files
-for a specific version of Visual Studio are in their own directory in
-the top-level "windows" directory.  For example, Visual Studio 6 files
-are in windows/VC6.  If a directory does not exist for your version of
-Visual Studio, you can try importing the project files from an earlier
-version of Visual Studio.  At this time, project files exist for
-Version 6 and Version 7.  The code has been built with a beta version
-of Version 8 and it runs on 64-bit Windows.  If you want to try this,
-start by importing the VC7 files and create the 64-bit targets in the
-configuration manager.
-
-It is likely that the new and free Visual Studio Express can be used
-to build Mesa, but it hasn't been tried yet.  Start with the VC7
-project files.
-
-The project files to build the core Mesa library, Windows Mesa
-drivers, OSMesa, and GLU are in the mesa directory.  The project files
-to build GLUT and some demo programs are in the progs directory.
-
-Makefiles are no longer shipped or supported, but can be generated
-from the projects using Visual Studio.
-
-
-Windows Drivers
-------- -------
-
-At this time, only the GDI driver is known to work.  Most of the demos
-in progs/demos should work with this driver.
-
-Source code also exists in the tree for other drivers in
-src/mesa/drivers/windows, but the status of this code is unknown.
-
-The GDI driver operates basically by writing pixel spans into a DIB
-section and then blitting the DIB to the window.  The driver was
-recently cleaned up and rewitten and so may have bugs or may be
-missing some functionality.  The older versions of the CVS source may
-be useful in figuring out any problems, or report them to me.
-
-To build Mesa with the GDI driver, build the mesa, gdi, and glu
-projects in the Visual Studio workspace found at
-
-	windows/VC6/mesa/mesa.dsw
-or
-	windows/VC7/mesa/mesa.sln
-
-The osmesa DLL can also be built with the osmesa project.
-
-The build system creates a lib top-level directory and copies
-resulting LIB and DLL files to this lib directory.  The files are:
-
-	OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB
-	OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL
-
-If the MesaDemos ZIP file was extracted, the DLL files are also copied
-to the demos directory.  This facilitates running the demos as described
-below.
-
-
-GLUT and Demos
----- --- -----
-
-A Visual Studio workspace can be found at 
-
-	windows/VC6/progs/progs.dsw
-or
-	windows/VC7/progs/progs.sln
-
-It can be used to build GLUT and a few demos.  The GLUT lib and DLL
-are copied to the top-level lib directory, along with the Mesa libs.
-
-The demo build system expects to find the LIB files in the top level
-lib directory, so you must build the Mesa libs first.  The demo
-executables are placed in the demos directory, because some of them
-rely on data files found there.  Also, the Mesa lib DLL's were copied
-there by the Mesa lib build process.  Therefore, you should be able to
-simply run the demo executables from the demo directory.
-
-If you want to run the demos from the Visual Studio, you may have to
-change the startup directory and explicitly state where the executables are.
-
-You may also build all the demo programs by using a makefile.  Go to
-the progs/demos directory and make sure you have executed VCVARS32.BAT
-or whatever setup script is appropriate for your compiler.  Then,
-
-	nmake -f Makefile.win
-
-should build all the demos.
-
-
-Build System Notes
------ ------ -----
-
-VC6
----
-
-Visual Studio 6 does not recognize files with the .cc extension as C++
-language files, without a lot of unnatural tweaking.  So, the VC6
-build process uses custom build steps to compile these files in the
-GLU library.
-
-Two additional configurations are provided, Debug x86 and Release x86
-that activate the shader code compilation by defining SLANG_86.  It is
-unknown if and how this works.
-
-VC7
----
-
-The above-mentioned .cc problem does not exist in this version.
-
-
-General
--------
-
-After building, you can copy the above DLL files to a place in your
-PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things
-in a system directory, place them in the same directory as the
-executable(s).  Be careful about accidentially overwriting files of
-the same name in the SYSTEM32 directory.
-
-The DLL files are built so that the external entry points use the
-stdcall calling convention.
-
-Static LIB files are not built.  The LIB files that are built with are
-the linker import files associated with the DLL files.
-
-The si-glu sources are used to build the GLU libs.  This was done
-mainly to get the better tessellator code.
-
-To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE
-to the project settings.  You will also need to edit src/mesa.def to
-change all the gl* symbols to mgl*.  Because this is easy to do with a
-global replace operation in a text editor, no additional mangled
-version of mesa.def is maintained or shipped.
-
-If you have a Windows-related build problem or question, it is
-probably better to direct it to me ([email protected]),
-rather than directly to the other Mesa developers.  I will help you as
-much as I can.  I also monitor the Mesa mailing lists and will answer
-questions in this area there as well.
-
-
-Karl Schultz
+File: docs/README.WIN32

+

+Last updated: Apr 25, 2007 - Karl Schultz - [email protected]

+

+Quick Start

+----- -----

+

+Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same

+directory.  The libs and demos build separately, so if you do not care

+about the demos or GLUT, you only need to unzip MesaLib.  If you unzip

+more than one ZIP file, they all need to be unzipped into the same

+directory.  Don't worry, you will not overwrite anything.

+

+The Windows build system uses Microsoft Visual Studio.  Project files

+for a specific version of Visual Studio are in their own directory in

+the top-level "windows" directory.  For example, Visual Studio 8 files

+are in windows/VC8.

+

+Support has been dropped for versions of Visual Studio prior to 8. The

+main reason is because Microsoft now provides a free compiler and

+developer environment.  Visual Studio Express can be found at

+

+http://msdn.microsoft.com/vstudio/express/visualc/default.aspx

+

+You'll also need the Platform SDK.  Instructions for obtaining and

+using the SDK with Visual Studio Express can be found at

+

+http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/

+

+If you are stuck using VC6 or VC7, you may start with these project

+files, but you may need to modify them to reflect changes in the

+Mesa source code tree.  If you sucessfully update the project files,

+please submit them to the author of this document so that they may

+be included in the next distribution. 

+

+The project files to build the core Mesa library, Windows Mesa

+drivers, OSMesa, and GLU are in the mesa directory.  The project files

+to build GLUT and some demo programs are in the progs directory.

+

+Makefiles are no longer shipped or supported, but can be generated

+from the projects using Visual Studio.

+

+

+Windows Drivers

+------- -------

+

+At this time, only the GDI driver is known to work.  Most of the demos

+in progs/demos should work with this driver.

+

+Source code also exists in the tree for other drivers in

+src/mesa/drivers/windows, but the status of this code is unknown.

+

+The GDI driver operates basically by writing pixel spans into a DIB

+section and then blitting the DIB to the window.  The driver was

+recently cleaned up and rewitten and so may have bugs or may be

+missing some functionality.  The older versions of the CVS source may

+be useful in figuring out any problems, or report them to me.

+

+To build Mesa with the GDI driver, build the mesa, gdi, and glu

+projects in the Visual Studio workspace found at

+

+	windows/VC8/mesa/mesa.sln

+

+The osmesa DLL can also be built with the osmesa project.

+

+The build system creates a lib top-level directory and copies

+resulting LIB and DLL files to this lib directory.  The files are:

+

+	OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB

+	OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL

+

+If the MesaDemos ZIP file was extracted, the DLL files are also copied

+to the demos directory.  This facilitates running the demos as described

+below.

+

+

+GLUT and Demos

+---- --- -----

+

+A Visual Studio workspace can be found at 

+

+	windows/VC8/progs/progs.sln

+

+It can be used to build GLUT and a few demos.  The GLUT lib and DLL

+are copied to the top-level lib directory, along with the Mesa libs.

+

+The demo build system expects to find the LIB files in the top level

+lib directory, so you must build the Mesa libs first.  The demo

+executables are placed in the demos directory, because some of them

+rely on data files found there.  Also, the Mesa lib DLL's were copied

+there by the Mesa lib build process.  Therefore, you should be able to

+simply run the demo executables from the demo directory.

+

+If you want to run the demos from the Visual Studio, you may have to

+change the startup directory and explicitly state where the executables are.

+

+You may also build all the demo programs by using a makefile.  Go to

+the progs/demos directory and make sure you have executed VCVARS32.BAT

+or whatever setup script is appropriate for your compiler.  Then,

+

+	nmake -f Makefile.win

+

+should build all the demos.

+

+

+Build System Notes

+----- ------ -----

+

+VC6 (not actively supported)

+---

+

+Visual Studio 6 does not recognize files with the .cc extension as C++

+language files, without a lot of unnatural tweaking.  So, the VC6

+build process uses custom build steps to compile these files in the

+GLU library.

+

+Two additional configurations are provided, Debug x86 and Release x86

+that activate the shader code compilation by defining SLANG_86.  It is

+unknown if and how this works.

+

+VC7 (not actively supported)

+---

+

+The above-mentioned .cc problem does not exist in this version.

+

+VC8

+---

+

+No notes.

+

+

+General

+-------

+

+After building, you can copy the above DLL files to a place in your

+PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things

+in a system directory, place them in the same directory as the

+executable(s).  Be careful about accidentially overwriting files of

+the same name in the SYSTEM32 directory.

+

+The DLL files are built so that the external entry points use the

+stdcall calling convention.

+

+Static LIB files are not built.  The LIB files that are built with are

+the linker import files associated with the DLL files.

+

+The si-glu sources are used to build the GLU libs.  This was done

+mainly to get the better tessellator code.

+

+To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE

+to the project settings.  You will also need to edit src/mesa.def to

+change all the gl* symbols to mgl*.  Because this is easy to do with a

+global replace operation in a text editor, no additional mangled

+version of mesa.def is maintained or shipped.

+

+If you have a Windows-related build problem or question, it is

+probably better to direct it to me ([email protected]),

+rather than directly to the other Mesa developers.  I will help you as

+much as I can.  I also monitor the Mesa mailing lists and will answer

+questions in this area there as well.

+

+

+Karl Schultz

diff --git a/docs/contents.html b/docs/contents.html
index d8f427e59bc..a21341a5891 100644
--- a/docs/contents.html
+++ b/docs/contents.html
@@ -71,8 +71,8 @@ a:visited {
 <li><a href="helpwanted.html" target="MainFrame">Help Wanted</a>
 <li><a href="devinfo.html" target="MainFrame">Development Notes</a>
 <li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a>
-<li><a href="subset.html" target="MainFrame">Subset Information</a>
 <li><a href="fbdev-dri.html" target="MainFrame">fbdev/DRI Environment</a>
+<li><a href="subset.html" target="MainFrame">Mesa Subset Driver</a>
 <li><a href="glfbdev-driver.html" target="MainFrame">glFBDev Driver</a>
 <LI><A HREF="dispatch.html" target="MainFrame">GL Dispatch</A>
 </ul>
diff --git a/docs/download.html b/docs/download.html
index bf5fb24f206..90f566351e8 100644
--- a/docs/download.html
+++ b/docs/download.html
@@ -9,11 +9,7 @@
 <H1>Downloading</H1>
 
 <p>
-Last development release: <b>6.5.2</b>
-</p>
-
-<p>
-Last stable release: <b>6.4.2</b>
+Last stable release: <b>7.0</b>
 </p>
 
 <p>
diff --git a/docs/fbdev-dri.html b/docs/fbdev-dri.html
index 4af503932be..c7f59bb0c2f 100644
--- a/docs/fbdev-dri.html
+++ b/docs/fbdev-dri.html
@@ -12,161 +12,77 @@
 <H1>1. Introduction</H1>
 
 <p>
-The fbdev/DRI sub-project within Mesa brings hardware accelerated OpenGL
-rendering to the Linux fbdev environment.
-The X Window System / XFree86 is not needed.
+The fbdev/DRI environment supports hardware-accelerated 3D rendering without
+the X window system.  This is typically used for embedded applications.
 </p>
 
 <p>
-Basically, the <a href="http://dri.sf.net/">DRI</a> drivers for hardware
-accelerated OpenGL for XFree86 have been ported to fbdev so that X is
-not needed.
-This means fbdev/DRI works in full-screen mode only.
+Contributors to this project include Jon Smirl, Keith Whitwell and Dave Airlie.
 </p>
 
 <p>
-DRI driver writers may find this simplified environment easier to work in,
-compared to the full XFree86/DRI environment.
+Applications in the fbdev/DRI environment use
+the <a href="MiniGXL.html"> MiniGLX</a> interface to choose pixel
+formats, create rendering contexts, etc.  It's a subset of the GLX and
+Xlib interfaces allowing some degree of application portability between
+the X and X-less environments.
 </p>
 
-<p>
-Much of the work for this project has been done by Jon Smirl and
-Keith Whitwell.
-</p>
-
-<p>
-To use fbdev/DRI, you'll need a Linux 2.4 or 2.6 kernel.
-</p>
-
-<h3>Background Info</h3>
-
-<p>
-The Mesa-based DRI drivers used to be hosted in the DRI tree (which is
-basically a copy of the XFree86 tree).
-Since the Mesa-based DRI drivers are moreso "Mesa drivers" than "XFree86
-drivers" and the fact that with some work, the drivers could be used
-without X, the driver code was moved into the Mesa tree.
-</p>
-
-<p>
-So now the DRI drivers can be compiled for two different environments:
-fbdev and XFree86.
-To build the drivers for XFree86, one has to download/build the DRI
-source tree.
-Eventually, we'd like to be able to build the drivers for XFree86 outside
-of the XFree86/DRI trees.
-</p>
-
-
-
 
 <h1>2. Compilation</h1>
 
-<h2>2.1 Compiling the DRM modules</h2>
-
-<p>
-First, you'll need the DRM (Direct Rendering Manager) kernel module sources.
-They're found in a module of the DRI CVS tree.
-To obtain the code do the following:
-</p>
-<pre>
-   cvs -d:pserver:[email protected]:/cvs/dri login
-</pre>
 <p>
-Press Enter/Return when prompted for a password.  Then,
+You'll need the DRM and pciaccess libraries.  Check with:
 </p>
 <pre>
-   cvs -d:pserver:[email protected]:/cvs/dri co drm
+   pkg-config --modversion libdrm
+   pkg-config --modversion pciaccess
 </pre>
 
 <p>
-Compile the DRM kernel modules:
+You can get them from the git repository with:
 </p>
 <pre>
-  cd drm/linux
-  make
+   git clone git://anongit.freedesktop.org/git/mesa/drm
+   git clone git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
 </pre>
 
 <p>
-Note: you may need to be root in order to make a few symlinks.
-</p>
-<p>
-When compilation is done, you should have at least the following
-kernel modules:
+See the README files in those projects for build/install instructions.
 </p>
-<pre>
-  gamma.o
-  i810.o
-  i830.o
-  mach64.o
-  mga.o
-  r128.o
-  radeon.o
-  savage.o
-  sis.o
-  tdfx.o
-  via.o
-</pre>
-<p>
-You'll probably want to copy/move them into your kernel module directory
-(for example: <code>/lib/modules/2.4.18-14/kernel/drivers/char/drm/</code>).
-</p>
-
 
 
-<h2>2.2 Compiling the Mesa drivers</h2>
-
 <p>
-Begin by editing the <code>Mesa/configs/default</code> file to set
-the <code>DRM_SOURCE_PATH</code> variable.
-Set it to the location where the DRM module sources are located.
-For example, if your current directory in step 2.1 was <code>/home/fred/</code>
-set DRM_SOURCE_PATH to <code>/home/fred/drm</code>
+You'll need fbdev header files.  Check with:
 </p>
+<pre>
+   ls -l /usr/include/linux/fb.h
+</pre>
 
 <p>
-Next, assuming you're starting with a fresh Mesa CVS checkout,
-do the following:
+Compile Mesa with the 'linux-solo' configuration:
 </p>
 <pre>
    make linux-solo
 </pre>
 
 <p>
-If you previously built the source tree, run <code>make realclean</code>
-first to remove the old object files.
+When complete you should have the following:
 </p>
-
-<p>
-When this is finished, check the <code>Mesa/lib/</code> directory
-to verify that the following files were made:
-</p>
-
 <ul>
-<li><code>libGL.so.1.2</code> - the client-side OpenGL library
-    (and a few symlinks to it).
-<li><code>libGLU.so.1.1</code> - the GLU library (and a few symlinks to it).
-<li><code>libglut.so.3.7</code> - the GLUT library (and a few symlinks to it).
-<li><code>mga_dri.so</code> - DRI driver for Matrox G200/G400 cards.
-<li><code>r128_dri.so</code> - DRI driver for ATI Rage 128 cards.
-<li><code>r200_dri.so</code> - DRI driver for ATI R200 Radeon cards.
-<li><code>radeon_dri.so</code> - DRI driver for original ATI Radeon cards.
-<li><code>i810_dri.so</code> - DRI driver for Intel i810/i815 chips.
-<li><code>i830_dri.so</code> - DRI driver for Intel i830/i845 chips.
-<li><code>mga_dri.so</code> - DRI driver for Matrox G200/G400 cards.
-<li><code>sis_dri.so</code> - DRI driver for SIS cards.
-<li><code>tdfx_dri.so</code> - DRI driver for 3dfx Voodoo 3/4/5 cards.
-<li><code>gamma_dri.so</code> - DRI driver for 3Dlabs gamma cards.
-<li><code>fb_dri.so</code> - software-only fbdev driver.
-<li><code>miniglx.conf</code> - configuration file for the MiniGLX interface
+<li>lib/libGL.so - the GL library which applications link with
+<li>lib/*_dri_so - DRI drivers
+<li>lib/miniglx.conf - sample MiniGLX config file
+<li>progs/miniglx/* - several MiniGLX sample programs
 </ul>
 
 
+
 <h1>3. Using fbdev/DRI</h1>
 
 <p>
-If XFree86 is currently running, exit/stop the X server so you're
-working from the console.
+If an X server currently running, exit/stop it so you're working from
+the console.
 </p>
 
 
@@ -175,12 +91,23 @@ working from the console.
 <p>
 You'll need to load the kernel modules specific to your graphics hardware.
 Typically, this consists of the agpgart module, an fbdev driver module
-and the DRM kernel module (from step 2.1).
+and the DRM kernel module.
+</p>
+<p>
+As root, the kernel modules can be loaded as follows:
 </p>
 
+<p>
+If you have Intel i915/i945 hardware:
+</p>
+<pre>
+   modprobe agpgart            # the AGP GART module
+   modprobe intelfb            # the Intel fbdev driver
+   modprobe i915               # the i915/945 DRI kernel module
+</pre>
 
 <p>
-If you have ATI Radeon/R200 hardware, run as root:
+If you have ATI Radeon/R200 hardware:
 </p>
 <pre>
    modprobe agpgart            # the AGP GART module
@@ -189,7 +116,7 @@ If you have ATI Radeon/R200 hardware, run as root:
 </pre>
 
 <p>
-If you have ATI Rage 128 hardware, run as root:
+If you have ATI Rage 128 hardware:
 </p>
 <pre>
    modprobe agpgart            # the AGP GART module
@@ -198,7 +125,7 @@ If you have ATI Rage 128 hardware, run as root:
 </pre>
 
 <p>
-If you have Matrox G200/G400 hardware, run as root:
+If you have Matrox G200/G400 hardware:
 </p>
 <pre>
    modprobe agpgart            # the AGP GART module
@@ -207,37 +134,46 @@ If you have Matrox G200/G400 hardware, run as root:
 </pre>
 
 <p>
-Then run <code>lsmod</code> to be sure the modules are loaded.
-For a Radeon card, you should see something like this:
+To verify that the agpgart, fbdev and drm modules are loaded:
 </p>
 <pre>
-Module                  Size  Used by    Not tainted
-radeon                110308   0  (unused)
-radeonfb               21900   0  (unused)
-agpgart                43072   1 
+   ls -l /dev/agpgart /dev/fb* /dev/dri
 </pre>
-
+<p>
+Alternately, use lsmod to inspect the currently installed modules.
+If you have problems, look at the output of dmesg.
+</p>
 
 
 <h2>3.2 Configuration File</h2>
 
 <p>
-The <code>Mesa/lib/miniglx.conf</code> file should be installed
-in <code>/etc/</code>.
+Copy the sample miniglx.conf to /etc/miniglx.conf and review/edit its contents.
+Alternately, the MINIGLX_CONF environment variable can be used to
+indicate the location of miniglx.conf
 </p>
 
+To determine the pciBusID value, run lspci and examine the output.
+For example:
+</p>
+<pre>
+   /sbin/lspci:
+   00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04)
+</pre>
 <p>
-Edit <code>/etc/miniglx.conf</code> to be sure it's set up correctly
-for your hardware.
-Comments in the file explain the options.
+00:02.0 indicates that pciBusID should be PCI:0:2:0
 </p>
 
 
+
+
 <h2>3.3 Running fbdev/DRI Programs</h2>
 
 <p>
 Make sure your LD_LIBRARY_PATH environment variable is set to the
-<code>Mesa/lib/</code> directory.
+location of the libGL.so library.  You may need to append other paths
+to LD_LIBRARY_PATH if libpciaccess.so is in a non-standard location,
+for example.
 </p>
 
 <p>
@@ -245,7 +181,7 @@ Change to the <code>Mesa/progs/miniglx/</code> directory and
 start the sample_server program in the background:
 </p>
 <pre>
-   ./sample_server &
+   ./sample_server &amp;
 </pre>
 
 <p>
@@ -268,28 +204,25 @@ them from a remote shell so that you can stop them with ctrl-C.
 
 <h1>4.0 Troubleshooting</h1>
 
-<p>
+<ol>
+<li>
 If you try to run miniglxtest and get the following:
-</p>
+<br>
 <pre>
    [miniglx] failed to probe chipset
    connect: Connection refused
    server connection lost
 </pre>
-<p>
 It means that the sample_server process is not running.
-</p>
-
-
+<br>
+<br>
+</li>
+</ol>
 
 
 <h1>5.0 Programming Information</h1>
 
 <p>
-The full OpenGL API is available with fbdev/DRI.
-</p>
-
-<p>
 OpenGL/Mesa is interfaced to fbdev via the <a href="MiniGLX.html">MiniGLX</a>
 interface.
 MiniGLX is a subset of Xlib and GLX API functions which provides just
diff --git a/docs/intro.html b/docs/intro.html
index 33a006a74b5..0e37322823b 100644
--- a/docs/intro.html
+++ b/docs/intro.html
@@ -128,10 +128,15 @@ specification as well as the GL_ARB_vertex_program and
 GL_ARB_fragment_program extensions.
 </p>
 
+<p>
+June 2007: Mesa 7.0 is released, implementing the OpenGL 2.1 specification
+and OpenGL Shading Language.
+</p>
+
 
 <p>
 Ongoing: Mesa is used as the core of many hardware OpenGL drivers for
-the XFree86 X.org X servers within the
+the XFree86 and X.org X servers within the
 <A href="http://dri.freedesktop.org/" target="_parent">DRI project</A>.
 I continue to enhance Mesa with new extensions and features.
 </p>
@@ -141,9 +146,16 @@ I continue to enhance Mesa with new extensions and features.
 <H1>Major Versions</H1>
 
 <p>
-This is a summary of the major versions of Mesa.  Note that Mesa's major
-version number tracks OpenGL's minor version number (+1).
-Work is underway to implement the OpenGL 2.0 specification.
+This is a summary of the major versions of Mesa.
+Mesa's major version number has been incremented whenever a new version
+of the OpenGL specification is implemented.
+</p>
+
+
+<H2>Version 7.x features</H2>
+<p>
+Version 7.x of Mesa implements the OpenGL 2.1 API.  The main feature
+of OpenGL 2.x is the OpenGL Shading Language.
 </p>
 
 
diff --git a/docs/news.html b/docs/news.html
index 721d65e1d7e..58aca318587 100644
--- a/docs/news.html
+++ b/docs/news.html
@@ -11,6 +11,21 @@
 <H1>News</H1>
 
 
+<h2>June 22, 2007</h2>
+<p>
+<a href="relnotes-7.0.html">Mesa 7.0</a> is released.
+This is a stable release featuring OpenGL 2.1 support.
+</p>
+
+
+<h2>April 27, 2007</h2>
+<p>
+<a href="relnotes-6.5.3.html">Mesa 6.5.3</a> is released.
+This is a development release which will lead up to the Mesa 7.0 release
+(which will advertise OpenGL 2.1 API support).
+</p>
+
+
 <h2>March 26, 2007</h2>
 <p>
 The new Shading Language compiler branch has been merged into the git
diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html
index d7249aec8fb..0d68d990134 100644
--- a/docs/relnotes-6.5.3.html
+++ b/docs/relnotes-6.5.3.html
@@ -8,27 +8,53 @@
 
 <body bgcolor="#eeeeee">
 
-<H1>Mesa 6.5.3 Release Notes / (in progress)</H1>
+<H1>Mesa 6.5.3 Release Notes / April 27, 2007</H1>
 
 <p>
-Mesa 6.5.3 is a 6.5 follow-on development release with many internal changes.
+Mesa 6.5.3 is a development release with many changes and new features.
+Mesa 7.0 is expected to follow shortly.
 </p>
 
 
 <h2>MD5 checksums</h2>
 <pre>
-TBD
+39f33ea64e34e2d5b20640b008b57649  MesaLib-6.5.3.tar.gz
+46359457147c469745f24b5074a186f0  MesaLib-6.5.3.tar.bz2
+a8946fa861634ce15971396f47992c41  MesaLib-6.5.3.zip
+08e26948d57eaca74d02a530b2d8106e  MesaDemos-6.5.3.tar.gz
+8af91773ab2653fe537499676b05f2e8  MesaDemos-6.5.3.tar.bz2
+783f81b171bf89b0929abc894efd25a6  MesaDemos-6.5.3.zip
+9467d415388fe1ad82991fb20704b812  MesaGLUT-6.5.3.tar.gz
+360843e46b7ebb6909290b023f9b26fa  MesaGLUT-6.5.3.tar.bz2
+7686065e5c15a30de08a1610860b6840  MesaGLUT-6.5.3.zip
 </pre>
 
 
+<h2>Shared library numbering</h2>
+<p>
+Mesa 6.5.3 supports the OpenGL 2.0/2.1 API.  However, the (unix)
+shared library version is still 1.5 (i.e. libGL.so.1.5.xxxxxx).
+Bumping the shared library version to 2.x would cause linking problems
+with existing OpenGL applications.  Since OpenGL 2.x is backward
+compatible with OpenGL 1.x the shared library version number doesn't
+have to be incremented (which would indicate an incompatible ABI).
+</p>
+<p>
+Other OpenGL vendors name their OpenGL 2.x libraries libGL.so.1.0.xxxxx
+for the same reason.
+</p>
+
+
+
 <h2>New features</h2>
 <ul>
-<li>OpenGL 2.0 support.
-<li>Entirely new Shading Language code generator.
+<li>OpenGL 2.0 and 2.1 API support.
+<li>Entirely new Shading Language code generator.  See the
+<a href="shading.html">Shading Language</a> page for more information.
 <li>Much faster software execution of vertex, fragment shaders.
-<li>New vertex buffer object infrastructure (replaces old array_cache code).
+<li>New vertex buffer object (vbo) infrastructure
 <li>Updated glext.h file (version 39)
-<li>Updated glxext.h file (version 18)
+<li>Updated glxext.h file (version 19)
 <li>GL_MAX_DRAWBUFFERS is now 4 (software rendering) so
     "multiple render targets" are really supported.
 </ul>
@@ -43,18 +69,22 @@ TBD
 <li>Overlapping glCopyPixels with negative Y zoom didn't work (bug 10521)
 <li>Fixed a number of framebuffer/renderbuffer reference counting bugs
 <li>Fixed a few bugs in software-emulated alpha planes
+<li>Assorted minor bug fixes in glCopy/DrawPixels, glPixelZoom, etc.
+<li>Assorted DRI driver bug fixes.
+<li>Fixed a number of bugs that prevented "depth-peeling" rendering from working.
 </ul>
 
 
 <h2>Internal code changes</h2>
-
 <ul>
-<li>Massive changes to the Shading Language compiler.
-<li>The _MaintainTnlProgram, _MaintainTexEnvProgram, _TexEnvProgram and
-_TnlProgram fields have been moved.
-<li>The ctx->Vertex/FragmentProgram._Current fields point to the program
-in effect, whether it comes from a shader, user-program or generated
-fixed-function program.
+<li>Old array_cache module replaced by new vbo module.  All geometry
+rendering is now cast in the form of vertex buffer objects.
+<li>Massive changes to the Shading Language compiler and related state.
+<li>Vertex/fragment shaders are compiled into GPU instructions and
+programs very similar to GL_ARB_vertex/fragment_program.
+<li>Vertex and fragment programs are executed with the same code now.
+<li>The SSE-optimized vertex program path has been removed since it didn't
+support more than 12 temp registers, didn't support branching/looping, etc.
 </ul>
 
 
@@ -72,17 +102,17 @@ fixed-function program.
 Driver			Status
 ----------------------	----------------------
 DRI drivers		varies with the driver
-XMesa/GLX (on Xlib)	implements OpenGL 2.0
-OSMesa (off-screen)	implements OpenGL 2.0
+XMesa/GLX (on Xlib)	implements OpenGL 2.1
+OSMesa (off-screen)	implements OpenGL 2.1
+Windows/Win32		implements OpenGL 2.1
 Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
+SVGA			unsupported
+Wind River UGL		unsupported
+DJGPP			unsupported
+GGI			unsupported
+BeOS			unsupported
+Allegro			unsupported
+D3D			unsupported
 </pre>
 
 </body>
diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html
new file mode 100644
index 00000000000..2c036b2ec7f
--- /dev/null
+++ b/docs/relnotes-7.0.html
@@ -0,0 +1,93 @@
+<HTML>
+
+<TITLE>Mesa Release Notes</TITLE>
+
+<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<BODY>
+
+<body bgcolor="#eeeeee">
+
+<H1>Mesa 7.0 Release Notes / June 22, 2007</H1>
+
+<p>
+Mesa 7.0 is a stable release, featuring OpenGL 2.1 API support.
+A number of bugs have been fixed since the 6.5.3 release.
+</p>
+
+
+<h2>MD5 checksums</h2>
+<pre>
+35a1698986f7ac8dc435624ee9256cda  MesaLib-7.0.tar.gz
+50c371455fa7532c04aa0a970f9bc51f  MesaLib-7.0.tar.bz2
+bcedb6f43c97c1bc49e5cc7f12835722  MesaLib-7.0.zip
+9bad332c7b74f59be96556135212ca9e  MesaDemos-7.0.tar.gz
+fada2bc1f29da513e015fda1e3abd0c0  MesaDemos-7.0.tar.bz2
+84e3bbe470d983ae32f1f0c779faf99e  MesaDemos-7.0.zip
+76c7bb54f9850c689eba844f6daed332  MesaGLUT-7.0.tar.gz
+4af28296e02772ef1de00e4e79bf3d12  MesaGLUT-7.0.tar.bz2
+9043cb0b54cc03d1874728d74b12188c  MesaGLUT-7.0.zip
+</pre>
+
+
+<h2>New features</h2>
+<ul>
+<li>OpenGL 2.0 and 2.1 API support.
+</ul>
+
+<h2>Bug fixes</h2>
+<ul>
+<li>Fixed a few fog-related bugs.
+<li>Fixed broken GLSL mix() function.
+<li>Fixed broken GLSL exp() functions.
+<li>Fixed GLSL mod4(vec4, vec4) bug.
+<li>Implemented GLSL asin(), acos(), atan() functions.
+<li>Fixed an R300 driver bug that caused Xorg composite manager to crash
+<li>Fixed R300 vertex program/matrix bug (10848)
+<li>GLSL dFdx() and dFdy() work for fragment program inputs now (texcoords)
+<li>Specifying an invalid texture unit as a sampler could lead to a crash
+<li>The GLX protocol request for glXDestroyPBuffer() was incorrect (bug 10983)
+<li>ARB vp state.light[n].half value was incorrect (bug 10987)
+<li>Fixed a positional light source bug (bug 11009)
+<li>Fixed point size attenuation problem (bug 11042)
+<li>glPopAttrib didn't restore texture object's LOD bias (bug 11049)
+<li>Fixed a TLS / TEXTREL problem (bug 7459)
+</ul>
+
+
+<h2>Internal code changes</h2>
+<ul>
+<li>Some texture code consolidation and simplifiction (Ian Romanick)
+<li>R300 driver clean-ups.
+</ul>
+
+
+<h2>To Do (someday) items</h2>
+<ul>
+<li>Switch to freeglut
+<li>Fix linux-glide target/driver.
+<li>Improved lambda and derivative calculation for frag progs.
+</ul>
+
+
+<h2>Driver Status</h2>
+
+<pre>
+Driver			Status
+----------------------	----------------------
+DRI drivers		varies with the driver
+XMesa/GLX (on Xlib)	implements OpenGL 2.1
+OSMesa (off-screen)	implements OpenGL 2.1
+Windows/Win32		implements OpenGL 2.1
+Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
+SVGA			unsupported
+Wind River UGL		unsupported
+DJGPP			unsupported
+GGI			unsupported
+BeOS			unsupported
+Allegro			unsupported
+D3D			unsupported
+</pre>
+
+</body>
+</html>
diff --git a/docs/relnotes-7.1.html b/docs/relnotes-7.1.html
new file mode 100644
index 00000000000..d5d285803e8
--- /dev/null
+++ b/docs/relnotes-7.1.html
@@ -0,0 +1,72 @@
+<HTML>
+
+<TITLE>Mesa Release Notes</TITLE>
+
+<head><link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<BODY>
+
+<body bgcolor="#eeeeee">
+
+<H1>Mesa 7.1 Release Notes / (<em>in progress</em>)</H1>
+
+<p>
+Mesa 7.1 is a new development release.
+</p>
+
+
+<h2>MD5 checksums</h2>
+<pre>
+TBD
+</pre>
+
+
+<h2>New features</h2>
+<ul>
+<li>GL_EXT_texture_from_pixmap extension for Xlib driver
+</ul>
+
+
+<h2>Bug fixes</h2>
+<ul>
+</ul>
+
+
+<h2>Internal code changes</h2>
+<ul>
+</ul>
+
+
+<h2>To Do (someday) items</h2>
+<ul>
+<li>Remove the MEMCPY() and _mesa_memcpy() wrappers and just use memcpy().
+Probably do the same for malloc, calloc, etc.
+The wrappers were useful in the past for memory debugging but now we
+have valgrind.  Not worried about SunOS 4 support anymore either...
+<li>Switch to freeglut
+<li>Fix linux-glide target/driver.
+<li>Improved lambda and derivative calculation for frag progs.
+</ul>
+
+
+<h2>Driver Status</h2>
+
+<pre>
+Driver			Status
+----------------------	----------------------
+DRI drivers		varies with the driver
+XMesa/GLX (on Xlib)	implements OpenGL 2.1
+OSMesa (off-screen)	implements OpenGL 2.1
+Windows/Win32		implements OpenGL 2.1
+Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
+SVGA			unsupported
+Wind River UGL		unsupported
+DJGPP			unsupported
+GGI			unsupported
+BeOS			unsupported
+Allegro			unsupported
+D3D			unsupported
+</pre>
+
+</body>
+</html>
diff --git a/docs/relnotes.html b/docs/relnotes.html
index f73500d4aca..73bae8590f8 100644
--- a/docs/relnotes.html
+++ b/docs/relnotes.html
@@ -20,6 +20,8 @@ The release notes summarize what's new or changed in each Mesa release.
 </p>
 
 <UL>
+<LI><A HREF="relnotes-7.1.html">7.1 release notes</A>
+<LI><A HREF="relnotes-7.0.html">7.0 release notes</A>
 <LI><A HREF="relnotes-6.5.3.html">6.5.3 release notes</A>
 <LI><A HREF="relnotes-6.5.2.html">6.5.2 release notes</A>
 <LI><A HREF="relnotes-6.5.1.html">6.5.1 release notes</A>
diff --git a/docs/shading.html b/docs/shading.html
index fd96a41e85a..0e1a5e1a7bc 100644
--- a/docs/shading.html
+++ b/docs/shading.html
@@ -44,6 +44,10 @@ in Mesa:
 <li>Comparison of user-defined structs
 <li>Linking of multiple shaders is not supported
 <li>gl_ClipVertex
+<li>The derivative functions such as dFdx() are not implemented
+<li>The inverse trig functions asin(), acos(), and atan() are not implemented
+<li>The gl_Color and gl_SecondaryColor varying vars are interpolated
+    without perspective correction
 </ul>
 
 <p>
@@ -66,7 +70,6 @@ All other major features of the shading language should function.
 <li>The quality of generated code is pretty good, register usage is fair.
 <li>Shader error detection and reporting of errors (InfoLog) is not
     very good yet.
-<li>There are known memory leaks in the compiler.
 <li>The ftransform() function doesn't necessarily match the results of
     fixed-function transformation.
 </ul>
@@ -294,7 +297,7 @@ A new <a href="http://glean.sf.net" target="_parent">Glean</a> test has
 been create to exercise the GLSL compiler.
 </p>
 <p>
-The <em>glsl1</em> test runs over 130 sub-tests to check that the language
+The <em>glsl1</em> test runs over 150 sub-tests to check that the language
 features and built-in functions work properly.
 This test should be run frequently while working on the compiler to catch
 regressions.
diff --git a/docs/subset.html b/docs/subset.html
index dd1d742a821..4ac2eadffb9 100644
--- a/docs/subset.html
+++ b/docs/subset.html
@@ -1,17 +1,18 @@
 <HTML>
 
-<TITLE>Mesa Subset</TITLE>
+<TITLE>Mesa Subset Driver</TITLE>
 
 <link rel="stylesheet" type="text/css" href="mesa.css"></head>
 
 <BODY>
 
-<H1>Mesa Subset</H1>
+<H1>Mesa Subset Driver</H1>
 
 <p>
 In 2002/2003 Tungsten Graphics was contracted to develop a subset Mesa/Radeon
 driver for an embedded environment.  The result is a reduced-size DRI driver
-for the ATI R200 chip, for use with Linux fbdev rather than XFree86.
+for the ATI R200 chip, for use with
+<a href="fbdev-dri.html">fbdev/DRI environment</a>.
 </p>
 
 <p>
@@ -19,15 +20,5 @@ The specification for this subset can be found
 <a href="subset-A.html">here</a>.
 </p>
 
-<p>
-The <a href="MiniGLX.html">MiniGLX specification</a> describes the
-interface between fbdev and Mesa.
-</p>
-
-<p>
-More info to come...
-</p>
-
-
 </BODY>
 </HTML>
diff --git a/docs/thanks.html b/docs/thanks.html
index 78b9e3e5ec6..2031788f0dc 100644
--- a/docs/thanks.html
+++ b/docs/thanks.html
@@ -42,7 +42,7 @@ WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A>
 <br>
 <br>
 
-<li>The Mesa CVS repository is hosted by
+<li>The Mesa git repository is hosted by
 <a href="http://freedesktop.org/" target="_parent">freedesktop.org</a>.
 <br>
 <br>