diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MESA_texture_signed_rgba.spec | 214 | ||||
| -rw-r--r-- | docs/cell.html | 13 | ||||
| -rw-r--r-- | docs/extensions.html | 1 | ||||
| -rw-r--r-- | docs/relnotes-7.5.html | 20 | ||||
| -rw-r--r-- | docs/shading.html | 32 |
5 files changed, 266 insertions, 14 deletions
diff --git a/docs/MESA_texture_signed_rgba.spec b/docs/MESA_texture_signed_rgba.spec new file mode 100644 index 0000000000..49c8e9e5dd --- /dev/null +++ b/docs/MESA_texture_signed_rgba.spec @@ -0,0 +1,214 @@ +Name + + MESA_texture_signed_rgba + +Name Strings + + GL_MESA_texture_signed_rgba + +Contact + + + +Notice + + + +IP Status + + No known IP issues + +Status + + + +Version + + 0.3, 2009-03-24 + +Number + + Not assigned ? + +Dependencies + + Written based on the wording of the OpenGL 2.0 specification. + + This extension trivially interacts with ARB_texture_float. + This extension shares some language with ARB_texture_compression_rgtc + but does not depend on it. + +Overview + + OpenGL prior to 3.1 does not support any signed texture formats. + ARB_texture_compression_rgtc introduces some compressed red and + red_green signed formats but no uncompressed ones, which might + still be useful. NV_texture_shader adds signed texture formats, + but also a lot of functionality which has been superceded by fragment + shaders. + It is usually possible to get the same functionality + using a unsigned format by doing scale and bias in a shader, but this + is undesirable since modern hardware has direct support for this. + This extension adds a signed 4-channel texture format by backporting + the relevant features from OpenGL 3.1, as a means to support this in + OpenGL implementations only supporting older versions. + +Issues + + 1) What should this extension be called? + + RESOLVED: MESA_texture_signed_rgba seems reasonable. + The rgba part is there because only 4 channel format is supported. + + + 2) Should the full set of signed formats (alpha, luminance, rgb, etc.) + be supported? + + RESOLVED: NO. To keep this extension simple, only add the most + universal format, rgba. alpha/luminance can't be trivially supported + since OpenGL 3.1 does not support them any longer, and there is some + implied dependency on ARB_texture_rg for red/red_green formats so + avoid all this. Likewise, only 8 bits per channel is supported. + + + 3) Should this extension use new enums for the texture formats? + + RESOLVED: NO. Same enums as those used in OpenGL 3.1. + + + 4) How are signed integer values mapped to floating-point values? + + RESOLVED: Same as described in issue 5) of + ARB_texture_compression_rgtc (quote): + A signed 8-bit two's complement value X is computed to + a floating-point value Xf with the formula: + + { X / 127.0, X > -128 + Xf = { + { -1.0, X == -128 + + This conversion means -1, 0, and +1 are all exactly representable, + however -128 and -127 both map to -1.0. Mapping -128 to -1.0 + avoids the numerical awkwardness of have a representable value + slightly more negative than -1.0. + + This conversion is intentionally NOT the "byte" conversion listed + in Table 2.9 for component conversions. That conversion says: + + Xf = (2*X + 1) / 255.0 + + The Table 2.9 conversion is incapable of exactly representing + zero. + + (Difference to ARB_texture_compression_rgtc): + This is the same mapping as OpenGL 3.1 uses. + This is also different to what NV_texture_shader used. + The above mapping should be considered the reference, but there + is some leeway so other mappings are allowed for implementations which + cannot do this. Particulary the mapping given in NV_texture_shader or + the standard OpenGL byte/float mapping is considered acceptable too, as + might be a mapping which represents -1.0 by -128, 0.0 by 0 and 1.0 by + 127 (that is, uses different scale factors for negative and positive + numbers). + Also, it is ok to store incoming GL_BYTE user data as-is, without + converting to GL_FLOAT (using the standard OpenGL float/byte mapping) + and converting back (using the mapping described here). + Other than those subtle issues there are no other non-standard + conversions used, so when using for instance CopyTexImage2D with + a framebuffer clamped to [0,1] all converted numbers will be in the range + [0, 127] (and not scaled and biased). + + + 5) How will signed components resulting from RGBA8_SNORM texture + fetches interact with fragment coloring? + + RESOLVED: Same as described in issue 6) of + ARB_texture_compression_rgtc (quote): + The specification language for this extension is silent + about clamping behavior leaving this to the core specification + and other extensions. The clamping or lack of clamping is left + to the core specification and other extensions. + + For assembly program extensions supporting texture fetches + (ARB_fragment_program, NV_fragment_program, NV_vertex_program3, + etc.) or the OpenGL Shading Language, these signed formats will + appear as expected with unclamped signed components as a result + of a texture fetch instruction. + + If ARB_color_buffer_float is supported, its clamping controls + will apply. + + NV_texture_shader extension, if supported, adds support for + fixed-point textures with signed components and relaxed the + fixed-function texture environment clamping appropriately. If the + NV_texture_shader extension is supported, its specified behavior + for the texture environment applies where intermediate values + are clamped to [-1,1] unless stated otherwise as in the case + of explicitly clamped to [0,1] for GL_COMBINE. or clamping the + linear interpolation weight to [0,1] for GL_DECAL and GL_BLEND. + + Otherwise, the conventional core texture environment clamps + incoming, intermediate, and output color components to [0,1]. + + This implies that the conventional texture environment + functionality of unextended OpenGL 1.5 or OpenGL 2.0 without + using GLSL (and with none of the extensions referred to above) + is unable to make proper use of the signed texture formats added + by this extension because the conventional texture environment + requires texture source colors to be clamped to [0,1]. Texture + filtering of these signed formats would be still signed, but + negative values generated post-filtering would be clamped to + zero by the core texture environment functionality. The + expectation is clearly that this extension would be co-implemented + with one of the previously referred to extensions or used with + GLSL for the new signed formats to be useful. + + + 6) Should the RGBA_SNORM tokens also be accepted by CopyTexImage + functions? + + RESOLVED: YES. + + + 7) What to do with GetTexParameter if ARB_texture_float is supported, + in particular what datatype should this return for TEXTURE_RED_TYPE_ARB, + TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB, TEXTURE_ALPHA_TYPE_ARB? + + RESOLVED: ARB_texture_float states type is either NONE, + UNSIGNED_NORMALIZED_ARB, or FLOAT. This extension adds a new enum, + SIGNED_NORMALIZED, which will be returned accordingly. This is the + same behaviour as in OpenGL 3.1. + + +New Tokens + + + Accepted by the <internalformat> parameter of + TexImage1D, TexImage2D, TexImage3D, CopyTexImage1D, and CopyTexImage2D: + + RGBA_SNORM 0x8F93 + RGBA8_SNORM 0x8F97 + + Returned by the <params> parameter of GetTexLevelParameter: + + SIGNED_NORMALIZED 0x8F9C + + +Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization): + + -- Section 3.8.1, Texture Image Specification + + Add to Table 3.16 (page 154): Sized internal formats + + Sized Base R G B A L I D + Internal Format Internal Format bits bits bits bits bits bits bits + --------------- --------------- ---- ---- ---- ---- ---- ---- ---- + RGBA8_SNORM RGBA 8 8 8 8 0 0 0 + + +Dependencies on ARB_texture_float extension: + + If ARB_texture_float is supported, GetTexParameter queries with <value> + of TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB or + TEXTURE_ALPHA_TYPE_ARB return SIGNED_NORMALIZED if + the base internal format is RGBA_SNORM. diff --git a/docs/cell.html b/docs/cell.html index 49b62cac7b..ada903cf8a 100644 --- a/docs/cell.html +++ b/docs/cell.html @@ -14,16 +14,7 @@ The Mesa driver is part of the <a href="http://www.tungstengraphics.com/wiki/index.php/Gallium3D" target="_parent">Gallium3D</a> architecture. -</p> - -<p> -<a href="http://www.tungstengraphics.com/" target="_parent">Tungsten Graphics</a> -is leading the project. -Two phases are planned. -First, to implement the framework for parallel rasterization using the Cell -SPEs, including texture mapping. -Second, to implement a full-featured OpenGL driver with support for GLSL, etc. -The second phase is now underway. +Tungsten Graphics did the original implementation of the Cell driver. </p> @@ -60,7 +51,7 @@ Mesa tree, then set <code>LD_LIBRARY_PATH</code> like this: Verify that the Cell driver is being used by running <code>progs/xdemos/glxinfo</code> and looking for: <pre> - OpenGL renderer string: Gallium 0.2, Cell on Xlib + OpenGL renderer string: Gallium 0.3, Cell on Xlib </pre> diff --git a/docs/extensions.html b/docs/extensions.html index dbb8ebadaf..91ed20e5ce 100644 --- a/docs/extensions.html +++ b/docs/extensions.html @@ -24,6 +24,7 @@ The specifications follow. <LI><A HREF="MESA_resize_buffers.spec">MESA_resize_buffers.spec</A> <LI><A HREF="MESA_set_3dfx_mode.spec">MESA_set_3dfx_mode.spec</A> <LI><A HREF="MESA_sprite_point.spec">MESA_sprite_point.spec</A> (obsolete) +<LI><A HREF="MESA_texture_signed_rgba.spec">MESA_texture_signed_rgba.spec</A> <LI><A HREF="MESA_trace.spec">MESA_trace.spec</A> (obsolete) <LI><A HREF="MESA_window_pos.spec">MESA_window_pos.spec</A> <LI><A HREF="MESA_ycbcr_texture.spec">MESA_ycbcr_texture.spec</A> diff --git a/docs/relnotes-7.5.html b/docs/relnotes-7.5.html index f29553b0fb..3c822da863 100644 --- a/docs/relnotes-7.5.html +++ b/docs/relnotes-7.5.html @@ -12,6 +12,13 @@ <p> Mesa 7.5 is a new development release. +People who are concerned with stability and reliability should stick +with the 7.4.x branch or wait for Mesa 7.6. +</p> +<p> +The main new feature of Mesa 7.5 is the +<a href="http://www.tungstengraphics.com/wiki/index.php/Gallium3D" +target="_parent">Gallium3D</a> infrastructure. </p> <p> Mesa 7.5 implements the OpenGL 2.1 API, but the version reported by @@ -32,6 +39,17 @@ tbd <h2>New features</h2> <ul> +<li>Gallium - this is the new architecture for OS-independent and + API-independent 3D drivers. + Gallium3D is intended for GPUs that fully support vertex/fragment shaders. + The Gallium3D drivers currently included are: + <ul> + <li>softpipe - a software/reference driver + <li>i915 - Intel 915/945 driver + <li><a href="cell.html">Cell</a> - IBM/Sony/Toshiba Cell processor driver + <li>nouveau - preliminary driver for NVIDIA GPUs (still under development) + <li>r300 - preliminary driver for R300 (still under development) + </ul> <li>GL_ARB_framebuffer_object extension (software drivers, i965 driver) <li>Reworked two-sided stencil support. This allows a driver to support all three variations of two-sided stencil @@ -45,8 +63,10 @@ including GL_ATI_separate_stencil, GL_EXT_stencil_two_side and OpenGL 2.0 <h2>Bug fixes</h2> <ul> +<li>Lots of i965 driver bug fixes </ul> + <h2>Changes</h2> <ul> <li>Remove support for GL_SGIX_shadow, GL_SGIX_shadow_ambient and diff --git a/docs/shading.html b/docs/shading.html index b77745fbf3..77c86be3aa 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -22,6 +22,7 @@ Last updated on 15 December 2008. Contents </p> <ul> +<li><a href="#envvars">Environment variables</a> <li><a href="#120">GLSL 1.20 support</a> <li><a href="#unsup">Unsupported Features</a> <li><a href="#notes">Implementation Notes</a> @@ -33,11 +34,32 @@ Contents +<a name="envvars"> +<h2>Environment Variables</h2> + +<p> +The <b>MESA_GLSL</b> environment variable can be set to a comma-separated +list of keywords to control some aspects of the GLSL compiler: +</p> +<ul> +<li>dump - print GLSL shader code to stdout at link time +<li>log - log all GLSL shaders to files. + The filenames will be "shader_X.vert" or "shader_X.frag" where X + the shader ID. +<li>nopt - disable compiler optimizations +<li>opt - force compiler optimizations +<li>uniform - print message to stdout when glUniform is called +</ul> +<p> +Example: export MESA_GLSL=dump,nopt +</p> + + <a name="120"> <h2>GLSL 1.20 support</h2> <p> -GLSL version 1.20 is supported in Mesa 7.3. +GLSL version 1.20 is supported in Mesa 7.3 and later. Among the features/differences of GLSL 1.20 are: <ul> <li><code>mat2x3, mat2x4</code>, etc. types and functions @@ -59,12 +81,14 @@ Among the features/differences of GLSL 1.20 are: <h2>Unsupported Features</h2> <p> -The following features of the shading language are not yet supported +The following features of the shading language are not yet fully supported in Mesa: </p> <ul> -<li>Linking of multiple shaders is not supported +<li>Linking of multiple shaders does not always work. Currently, linking + is implemented through shader concatenation and re-compiling. This + doesn't always work because of some #pragma and preprocessor issues. <li>gl_ClipVertex <li>The gl_Color and gl_SecondaryColor varying vars are interpolated without perspective correction @@ -177,6 +201,8 @@ This tool is useful for: After building Mesa, the glslcompiler can be built by manually running: </p> <pre> + make realclean + make linux cd src/mesa/drivers/glslcompiler make </pre> |