summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/MESA_texture_array.spec805
-rw-r--r--docs/MiniGLX.html13
-rw-r--r--docs/README.WIN32318
-rw-r--r--docs/contents.html2
-rw-r--r--docs/download.html6
-rw-r--r--docs/fbdev-dri.html213
-rw-r--r--docs/intro.html20
-rw-r--r--docs/news.html15
-rw-r--r--docs/relnotes-6.5.3.html78
-rw-r--r--docs/relnotes-7.0.html93
-rw-r--r--docs/relnotes-7.1.html72
-rw-r--r--docs/relnotes.html2
-rw-r--r--docs/shading.html7
-rw-r--r--docs/subset.html17
-rw-r--r--docs/thanks.html2
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 0000000000..d3b7752115
--- /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 3429812993..e7ebae6851 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 8dc59b00fd..ce595076bd 100644
--- a/docs/README.WIN32
+++ b/docs/README.WIN32
@@ -1,155 +1,163 @@
-File: docs/README.WIN32
-
-Last updated: Mar 31, 2006 - Karl Schultz - kschultz@users.sourceforge.net
-
-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 (kschultz@users.sourceforge.net),
-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 - kschultz@users.sourceforge.net
+
+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 (kschultz@users.sourceforge.net),
+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 d8f427e59b..a21341a589 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 bf5fb24f20..90f566351e 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 4af503932b..c7f59bb0c2 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:anonymous@anoncvs.freedesktop.org:/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:anonymous@anoncvs.freedesktop.org:/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 33a006a74b..0e37322823 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 721d65e1d7..58aca31858 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 d7249aec8f..0d68d99013 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 0000000000..2c036b2ec7
--- /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 0000000000..d5d285803e
--- /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 f73500d4ac..73bae8590f 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 fd96a41e85..0e1a5e1a7b 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 dd1d742a82..4ac2eadffb 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 78b9e3e5ec..2031788f0d 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-18 07:13:42 +0000