diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/MESA_texture_array.spec | 805 | ||||
-rw-r--r-- | docs/MiniGLX.html | 13 | ||||
-rw-r--r-- | docs/README.WIN32 | 318 | ||||
-rw-r--r-- | docs/contents.html | 2 | ||||
-rw-r--r-- | docs/download.html | 6 | ||||
-rw-r--r-- | docs/fbdev-dri.html | 213 | ||||
-rw-r--r-- | docs/intro.html | 20 | ||||
-rw-r--r-- | docs/news.html | 15 | ||||
-rw-r--r-- | docs/relnotes-6.5.3.html | 78 | ||||
-rw-r--r-- | docs/relnotes-7.0.html | 93 | ||||
-rw-r--r-- | docs/relnotes-7.1.html | 72 | ||||
-rw-r--r-- | docs/relnotes.html | 2 | ||||
-rw-r--r-- | docs/shading.html | 7 | ||||
-rw-r--r-- | docs/subset.html | 17 | ||||
-rw-r--r-- | docs/thanks.html | 2 |
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. 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 (assuming Radeon hardware)<br> -radeon.o (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. - 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 & </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> |