From e3caa5f891125d273174ff4a136c8ca313430138 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 18 Apr 2007 09:07:56 -0600 Subject: prep for 6.5.3 release --- docs/download.html | 2 +- docs/news.html | 8 ++++++++ docs/relnotes-6.5.3.html | 46 +++++++++++++++++++++++++--------------------- docs/thanks.html | 2 +- 4 files changed, 35 insertions(+), 23 deletions(-) (limited to 'docs') diff --git a/docs/download.html b/docs/download.html index bf5fb24f20..1afe64ef96 100644 --- a/docs/download.html +++ b/docs/download.html @@ -9,7 +9,7 @@

Downloading

-Last development release: 6.5.2 +Last development release: 6.5.3

diff --git a/docs/news.html b/docs/news.html index 721d65e1d7..88c0ebe0a3 100644 --- a/docs/news.html +++ b/docs/news.html @@ -11,6 +11,14 @@

News

+

April ?, 2007

+

+Mesa 6.5.3 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). +

+ +

March 26, 2007

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..b0da0c530b 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -8,10 +8,11 @@ -

Mesa 6.5.3 Release Notes / (in progress)

+

Mesa 6.5.3 Release Notes / April ??, 2007

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

@@ -23,10 +24,10 @@ TBD

New features

Internal code changes

- @@ -72,17 +76,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 -Glide (3dfx Voodoo1/2) implements OpenGL 1.3 -SVGA implements OpenGL 1.3 -Wind River UGL implements OpenGL 1.3 +XMesa/GLX (on Xlib) implements OpenGL 2.1 +OSMesa (off-screen) implements OpenGL 2.1 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 +Glide (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA unsupported +Wind River UGL unsupported +DJGPP unsupported +GGI unsupported +BeOS unsupported +Allegro unsupported +D3D unsupported 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">

-
  • The Mesa CVS repository is hosted by +
  • The Mesa git repository is hosted by freedesktop.org.

    -- cgit v1.2.3 From 6d01f3f1ec21da5bdf3191869ee0be42b3c11d57 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 18 Apr 2007 09:28:38 -0600 Subject: added href to shading language info --- docs/relnotes-6.5.3.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index b0da0c530b..8f6ea8bea3 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -25,7 +25,8 @@ TBD

    New features

    • OpenGL 2.0 and 2.1 API support. -
    • Entirely new Shading Language code generator. +
    • Entirely new Shading Language code generator. See the +Shading Language page for more information.
    • Much faster software execution of vertex, fragment shaders.
    • New vertex buffer object (vbo) infrastructure
    • Updated glext.h file (version 39) -- cgit v1.2.3 From 8598f550916449b99351a51e2a20e4c4cff021d3 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 18 Apr 2007 09:30:07 -0600 Subject: glean glsl test now does over 150 tests --- docs/shading.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/shading.html b/docs/shading.html index fd96a41e85..3a10f1b0ce 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -294,7 +294,7 @@ A new Glean test has been create to exercise the GLSL compiler.

      -The glsl1 test runs over 130 sub-tests to check that the language +The glsl1 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. -- cgit v1.2.3 From ba3d384e94faaedd4b1e0a90c1a765452bf594f3 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 19 Apr 2007 14:24:29 -0600 Subject: dFdx(), etc. don't work yet --- docs/shading.html | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/shading.html b/docs/shading.html index 3a10f1b0ce..64ec9990d0 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -44,6 +44,7 @@ in Mesa:

    • Comparison of user-defined structs
    • Linking of multiple shaders is not supported
    • gl_ClipVertex +
    • The derivative functions such as dFdx() are not implemented

    -- cgit v1.2.3 From 535c37e85d9283f177825e7534e5d0abb4d93886 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 19 Apr 2007 14:24:58 -0600 Subject: Notes about shared lib version. Document depth-peel fixes. --- docs/relnotes-6.5.3.html | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index 8f6ea8bea3..0d0398aaf4 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -22,6 +22,22 @@ TBD +

    Shared library numbering

    +

    +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). +

    +

    +Other OpenGL vendors name their OpenGL 2.x libraries libGL.so.1.0.xxxxx +for the same reason. +

    + + +

    New features

    • OpenGL 2.0 and 2.1 API support. @@ -47,6 +63,7 @@ TBD
    • Fixed a few bugs in software-emulated alpha planes
    • Assorted minor bug fixes in glCopy/DrawPixels, glPixelZoom, etc.
    • Assorted DRI driver bug fixes. +
    • Fixed a number of bugs that prevented "depth-peeling" rendering from working.
    -- cgit v1.2.3 From fc3d6bd3519eac28d071ad6c3cfdf739a71921bb Mon Sep 17 00:00:00 2001 From: Brian Date: Sat, 21 Apr 2007 12:30:54 -0600 Subject: memory leaks fixed --- docs/shading.html | 1 - 1 file changed, 1 deletion(-) (limited to 'docs') diff --git a/docs/shading.html b/docs/shading.html index 64ec9990d0..aa19c88d86 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -67,7 +67,6 @@ All other major features of the shading language should function.
  • The quality of generated code is pretty good, register usage is fair.
  • Shader error detection and reporting of errors (InfoLog) is not very good yet. -
  • There are known memory leaks in the compiler.
  • The ftransform() function doesn't necessarily match the results of fixed-function transformation. -- cgit v1.2.3 From d59e6f233b02ffe2c36c2fb89ec26c208a421540 Mon Sep 17 00:00:00 2001 From: Brian Date: Sun, 22 Apr 2007 15:32:10 -0600 Subject: import glxext.h version 19 --- docs/relnotes-6.5.3.html | 2 +- include/GL/glxext.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index 0d0398aaf4..61ae904d02 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -46,7 +46,7 @@ for the same reason.
  • Much faster software execution of vertex, fragment shaders.
  • New vertex buffer object (vbo) infrastructure
  • Updated glext.h file (version 39) -
  • Updated glxext.h file (version 18) +
  • Updated glxext.h file (version 19)
  • GL_MAX_DRAWBUFFERS is now 4 (software rendering) so "multiple render targets" are really supported. diff --git a/include/GL/glxext.h b/include/GL/glxext.h index fb7ea22c1d..0f66df6277 100644 --- a/include/GL/glxext.h +++ b/include/GL/glxext.h @@ -46,9 +46,9 @@ extern "C" { /*************************************************************/ /* Header file version number, required by OpenGL ABI for Linux */ -/* glxext.h last updated 2007/02/13 */ +/* glxext.h last updated 2007/04/21 */ /* Current version at http://www.opengl.org/registry/ */ -#define GLX_GLXEXT_VERSION 18 +#define GLX_GLXEXT_VERSION 19 #ifndef GLX_VERSION_1_3 #define GLX_WINDOW_BIT 0x00000001 -- cgit v1.2.3 From 5814922d25fffb043b75ba8c1fd601e740e25ad7 Mon Sep 17 00:00:00 2001 From: Karl Schultz Date: Wed, 25 Apr 2007 10:28:37 -0600 Subject: updates for 6.5.3 w/ VC8 --- docs/README.WIN32 | 318 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 163 insertions(+), 155 deletions(-) (limited to 'docs') 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 -- cgit v1.2.3 From 4099531a0af5717087dca993ba780ec98936c4fc Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 26 Apr 2007 07:50:26 -0600 Subject: bump Windows to OpenGL 2.1, set release date --- docs/relnotes-6.5.3.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index 61ae904d02..0e69a84ee0 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -8,7 +8,7 @@ -

    Mesa 6.5.3 Release Notes / April ??, 2007

    +

    Mesa 6.5.3 Release Notes / April 26, 2007

    Mesa 6.5.3 is a development release with many changes and new features. @@ -96,7 +96,7 @@ 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 1.5 +Windows/Win32 implements OpenGL 2.1 Glide (3dfx Voodoo1/2) implements OpenGL 1.3 SVGA unsupported Wind River UGL unsupported -- cgit v1.2.3 From 74edc663a60522ff95dbd2b1e8711f3d5bfae60a Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 08:00:37 -0600 Subject: set 6.5.3 release date --- docs/news.html | 2 +- docs/relnotes-6.5.3.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/news.html b/docs/news.html index 88c0ebe0a3..d23fc6dfc6 100644 --- a/docs/news.html +++ b/docs/news.html @@ -11,7 +11,7 @@

    News

    -

    April ?, 2007

    +

    April 27, 2007

    Mesa 6.5.3 is released. This is a development release which will lead up to the Mesa 7.0 release diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index 0e69a84ee0..df7526f470 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -8,7 +8,7 @@ -

    Mesa 6.5.3 Release Notes / April 26, 2007

    +

    Mesa 6.5.3 Release Notes / April 27, 2007

    Mesa 6.5.3 is a development release with many changes and new features. -- cgit v1.2.3 From 7ff72a76590d5abdbe0891da51a5fed37d6fe312 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 15:23:19 -0600 Subject: document broken inverse trig functions --- docs/shading.html | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/shading.html b/docs/shading.html index aa19c88d86..99342a329f 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -45,6 +45,7 @@ in Mesa:

  • Linking of multiple shaders is not supported
  • gl_ClipVertex
  • The derivative functions such as dFdx() are not implemented +
  • The inverse trig functions asin(), acos(), and atan() are not implemented

    -- cgit v1.2.3 From 4b1d1b7b1865191a2687d548edb6c9a066005925 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 15:25:00 -0600 Subject: document perspective correction issues --- docs/shading.html | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs') diff --git a/docs/shading.html b/docs/shading.html index 99342a329f..0e1a5e1a7b 100644 --- a/docs/shading.html +++ b/docs/shading.html @@ -46,6 +46,8 @@ in Mesa:

  • gl_ClipVertex
  • The derivative functions such as dFdx() are not implemented
  • The inverse trig functions asin(), acos(), and atan() are not implemented +
  • The gl_Color and gl_SecondaryColor varying vars are interpolated + without perspective correction

    -- cgit v1.2.3 From 502ebe90e808853768a64853adfb8960dee64d68 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 16:53:26 -0600 Subject: 7.0 release notes (template) --- docs/relnotes-7.0.html | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 docs/relnotes-7.0.html (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html new file mode 100644 index 0000000000..534cc59436 --- /dev/null +++ b/docs/relnotes-7.0.html @@ -0,0 +1,67 @@ + + +Mesa Release Notes + + + + + + + +

    Mesa 7.0 Release Notes / (in progress)

    + +

    +Mesa 7.0 is a stable release, featuring OpenGL 2.1 API support. +

    + + +

    MD5 checksums

    +
    +TBD
+
    + + +

    New features

    + + +

    Bug fixes

    + + + +

    Internal code changes

    + + + +

    To Do (someday) items

    + + + +

    Driver Status

    + +
    +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
+
    + + + -- cgit v1.2.3 From 430e0364137565a8c5e227afd904a99bfcb5348e Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 16:53:42 -0600 Subject: added 6.5.3 MD5 sums --- docs/relnotes-6.5.3.html | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/relnotes-6.5.3.html b/docs/relnotes-6.5.3.html index df7526f470..0d68d99013 100644 --- a/docs/relnotes-6.5.3.html +++ b/docs/relnotes-6.5.3.html @@ -18,7 +18,15 @@ Mesa 7.0 is expected to follow shortly.

    MD5 checksums

    -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
    -- cgit v1.2.3 From c4615abb11a0fa0f6c2e0bdd543771564beb94c9 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 16:54:05 -0600 Subject: added 7.0 relnotes link --- docs/relnotes.html | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/relnotes.html b/docs/relnotes.html index f73500d4ac..c698dfe131 100644 --- a/docs/relnotes.html +++ b/docs/relnotes.html @@ -20,6 +20,7 @@ The release notes summarize what's new or changed in each Mesa release.

      +
    • 7.0 release notes
    • 6.5.3 release notes
    • 6.5.2 release notes
    • 6.5.1 release notes -- cgit v1.2.3 From af846712fdc3a6946dca74ea67e393fbd106ea84 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 17:00:13 -0600 Subject: updates for 7.0 --- docs/intro.html | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/intro.html b/docs/intro.html index 33a006a74b..ec481a9091 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.

      +

      +May 2007: Mesa 7.0 is released, implementing the OpenGL 2.1 specification +and OpenGL Shading Language. +

      +

      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 DRI project. I continue to enhance Mesa with new extensions and features.

      @@ -141,9 +146,16 @@ I continue to enhance Mesa with new extensions and features.

      Major Versions

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

      + + +

      Version 7.x features

      +

      +Version 7.x of Mesa implements the OpenGL 2.1 API. The main feature +of OpenGL 2.x is the OpenGL Shading Language.

      -- cgit v1.2.3 From d741b10be6c254a3c52f93b9f2241aeb8ba7eba1 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 27 Apr 2007 17:05:29 -0600 Subject: 7.0 blurb --- docs/news.html | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'docs') diff --git a/docs/news.html b/docs/news.html index d23fc6dfc6..cd09e2532d 100644 --- a/docs/news.html +++ b/docs/news.html @@ -11,6 +11,13 @@

      News

      +

      May ???, 2007

      +

      +Mesa 7.0 is released. +This is a stable release featuring OpenGL 2.1 support. +

      + +

      April 27, 2007

      Mesa 6.5.3 is released. -- cgit v1.2.3 From bfd5cf72c47646c0ae7e518d0a6adcbb81bd5e69 Mon Sep 17 00:00:00 2001 From: Brian Date: Tue, 1 May 2007 10:23:15 -0600 Subject: fog, mix() bug fixes --- docs/relnotes-7.0.html | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index 534cc59436..0cd7db8e2e 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -28,6 +28,8 @@ TBD

      Bug fixes

        +
      • Fixed a few fog-related bugs. +
      • Fixed broken GLSL mix() function.
      -- cgit v1.2.3 From 18cfe0c801229c91d3973282b0693b8fd7df74f3 Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 2 May 2007 18:46:45 -0600 Subject: document recent GLSL, R300 fixes --- docs/relnotes-7.0.html | 3 +++ 1 file changed, 3 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index 0cd7db8e2e..6772bc02a8 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -30,6 +30,9 @@ TBD
      • Fixed a few fog-related bugs.
      • Fixed broken GLSL mix() function. +
      • Implemented GLSL asin(), acos(), atan() functions. +
      • Fixed an R300 driver bug that caused Xorg composite manager to crash +
      • GLSL dFdx() and dFdy() work for fragment program inputs now (texcoords)
      -- cgit v1.2.3 From a6dad578b510d8876413871d7dc50738b7d32eb6 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 3 May 2007 13:52:33 -0600 Subject: document R300 bug fix 10848 --- docs/relnotes-7.0.html | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index 6772bc02a8..75e3431d40 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -32,6 +32,7 @@ TBD
    • Fixed broken GLSL mix() function.
    • Implemented GLSL asin(), acos(), atan() functions.
    • Fixed an R300 driver bug that caused Xorg composite manager to crash +
    • Fixed R300 vertex program/matrix bug (10848)
    • GLSL dFdx() and dFdy() work for fragment program inputs now (texcoords)
    -- cgit v1.2.3 From e75fbd3f918e86e545dfe6046b5d17a85be76f38 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 4 May 2007 18:26:41 -0600 Subject: Assorted miniglx updates. --- docs/MiniGLX.html | 13 ---- docs/contents.html | 2 +- docs/fbdev-dri.html | 210 ++++++++++++++++------------------------------------ docs/subset.html | 17 +---- 4 files changed, 70 insertions(+), 172 deletions(-) (limited to 'docs') 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 radeon_dri.so) at runtime.  The environment variable LIBGL_DRIVERS_PATH should name the directory where these modules are located.

    -Prior to running a MiniGXL application, the following kernel modules -must be installed:
    -
    -
    agpgart.o
    -radeonfb.o  (assuming Radeon hardware)
    -radeon.o  (assuming Radeon hardware)
    -
    -
    -Finally, MiniGLX reads a configuration file (by default, -/etc/miniglx.conf) to determine basic configuration information. - The configuration file may also be located in the directory -specified by the MINIGLX_CONF environment variable).
    -
    The remainder of this section describes the MiniGLX API functions.

    3.1 Initialization

    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 {
  • Help Wanted
  • Development Notes
  • Source Documentation -
  • Subset Information
  • fbdev/DRI Environment +
  • Mesa Subset Driver
  • glFBDev Driver
  • GL Dispatch diff --git a/docs/fbdev-dri.html b/docs/fbdev-dri.html index 4af503932b..cdc4bd62f8 100644 --- a/docs/fbdev-dri.html +++ b/docs/fbdev-dri.html @@ -12,161 +12,64 @@

    1. Introduction

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

    -Basically, the DRI 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.

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

    -

    -Much of the work for this project has been done by Jon Smirl and -Keith Whitwell. -

    - -

    -To use fbdev/DRI, you'll need a Linux 2.4 or 2.6 kernel. -

    - -

    Background Info

    - -

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

    - -

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

    - - -

    2. Compilation

    -

    2.1 Compiling the DRM modules

    -

    -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: +You'll need the DRM and pciaccess libraries. Check with: 

    -   cvs -d:pserver:anonymous@anoncvs.freedesktop.org:/cvs/dri login
-
    -

    -Press Enter/Return when prompted for a password. Then, -

    -
    -   cvs -d:pserver:anonymous@anoncvs.freedesktop.org:/cvs/dri co drm
+   pkg-config --modversion libdrm
+   pkg-config --modversion pciaccess

    -Compile the DRM kernel modules: +You'll need fbdev header files. Check with: 

    -  cd drm/linux
-  make
+   ls -l /usr/include/linux/fb.h

    -Note: you may need to be root in order to make a few symlinks. -

    -

    -When compilation is done, you should have at least the following -kernel modules: -

    -
    -  gamma.o
-  i810.o
-  i830.o
-  mach64.o
-  mga.o
-  r128.o
-  radeon.o
-  savage.o
-  sis.o
-  tdfx.o
-  via.o
-
    -

    -You'll probably want to copy/move them into your kernel module directory -(for example: /lib/modules/2.4.18-14/kernel/drivers/char/drm/). -

    - - - -

    2.2 Compiling the Mesa drivers

    - -

    -Begin by editing the Mesa/configs/default file to set -the DRM_SOURCE_PATH variable. -Set it to the location where the DRM module sources are located. -For example, if your current directory in step 2.1 was /home/fred/ -set DRM_SOURCE_PATH to /home/fred/drm -

    - -

    -Next, assuming you're starting with a fresh Mesa CVS checkout, -do the following: +Compile Mesa with the 'linux-solo' configuration: 

        make linux-solo

    -If you previously built the source tree, run make realclean -first to remove the old object files. -

    - -

    -When this is finished, check the Mesa/lib/ directory -to verify that the following files were made: +When complete you should have the following:

    - +

    3. Using fbdev/DRI

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

    @@ -175,12 +78,23 @@ working from the console.

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

    +

    +As root, the kernel modules can be loaded as follows:

    +

    +If you have Intel i915/i945 hardware: +

    +
    +   modprobe agpgart            # the AGP GART module
+   modprobe intelfb            # the Intel fbdev driver
+   modprobe i915               # the i915/945 DRI kernel module
+

    -If you have ATI Radeon/R200 hardware, run as root: +If you have ATI Radeon/R200 hardware: 

        modprobe agpgart            # the AGP GART module
@@ -189,7 +103,7 @@ If you have ATI Radeon/R200 hardware, run as root:

    -If you have ATI Rage 128 hardware, run as root: +If you have ATI Rage 128 hardware: 

        modprobe agpgart            # the AGP GART module
@@ -198,7 +112,7 @@ If you have ATI Rage 128 hardware, run as root:

    -If you have Matrox G200/G400 hardware, run as root: +If you have Matrox G200/G400 hardware: 

        modprobe agpgart            # the AGP GART module
@@ -207,37 +121,46 @@ If you have Matrox G200/G400 hardware, run as root:

    -Then run lsmod 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: 

    -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
    - +

    +Alternately, use lsmod to inspect the currently installed modules. +If you have problems, look at the output of dmesg. +

    3.2 Configuration File

    -The Mesa/lib/miniglx.conf file should be installed -in /etc/. +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

    +To determine the pciBusID value, run lspci and examine the output. +For example: +

    +
    +   /sbin/lspci:
+   00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04)
+

    -Edit /etc/miniglx.conf 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

    + +

    3.3 Running fbdev/DRI Programs

    Make sure your LD_LIBRARY_PATH environment variable is set to the -Mesa/lib/ 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.

    @@ -268,27 +191,24 @@ them from a remote shell so that you can stop them with ctrl-C.

    4.0 Troubleshooting

    -

    +

      +
    1. If you try to run miniglxtest and get the following: -

      +
          [miniglx] failed to probe chipset
    connect: Connection refused
    server connection lost
      -

      It means that the sample_server process is not running. -

      - +
      +
      +

      2. 5.0 Programming Information

      -

      -The full OpenGL API is available with fbdev/DRI. -

      -

      OpenGL/Mesa is interfaced to fbdev via the MiniGLX interface. 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 @@ -Mesa Subset +Mesa Subset Driver -

      Mesa Subset

      +

      Mesa Subset Driver

      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 +fbdev/DRI environment.

      @@ -19,15 +20,5 @@ The specification for this subset can be found here.

      -

      -The MiniGLX specification describes the -interface between fbdev and Mesa. -

      - -

      -More info to come... -

      - - -- cgit v1.2.3 From 91948f99ddd08b2929aa0b993994f2745eff8bd5 Mon Sep 17 00:00:00 2001 From: Brian Date: Fri, 4 May 2007 18:32:02 -0600 Subject: add
    tag --- docs/fbdev-dri.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/fbdev-dri.html b/docs/fbdev-dri.html index cdc4bd62f8..294ddb1e05 100644 --- a/docs/fbdev-dri.html +++ b/docs/fbdev-dri.html @@ -204,7 +204,7 @@ It means that the sample_server process is not running.

    • - +

    5.0 Programming Information

    -- cgit v1.2.3 From 62ef001de7c16aff459114c1dcc8097270689e6d Mon Sep 17 00:00:00 2001 From: Brian Date: Wed, 9 May 2007 08:17:57 -0600 Subject: add pointers to git repo for drm/libpciaccess, replace & with & --- docs/fbdev-dri.html | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/fbdev-dri.html b/docs/fbdev-dri.html index 294ddb1e05..c7f59bb0c2 100644 --- a/docs/fbdev-dri.html +++ b/docs/fbdev-dri.html @@ -39,6 +39,19 @@ You'll need the DRM and pciaccess libraries. Check with: pkg-config --modversion pciaccess +

    +You can get them from the git repository with: +

    +
    +   git clone git://anongit.freedesktop.org/git/mesa/drm
+   git clone git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
+
    + +

    +See the README files in those projects for build/install instructions. +

    + +

    You'll need fbdev header files. Check with:

    @@ -168,7 +181,7 @@ Change to the Mesa/progs/miniglx/ directory and start the sample_server program in the background: 

    -   ./sample_server &
+   ./sample_server &

    -- cgit v1.2.3 From 58239d2ae31b12c11055ca3cd0799803670b0b88 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 10 May 2007 10:52:19 -0600 Subject: document tex sampler bug fix, code changes --- docs/relnotes-7.0.html | 3 +++ 1 file changed, 3 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index 75e3431d40..51f0812538 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -34,11 +34,14 @@ TBD

  • Fixed an R300 driver bug that caused Xorg composite manager to crash
  • Fixed R300 vertex program/matrix bug (10848)
  • GLSL dFdx() and dFdy() work for fragment program inputs now (texcoords) +
  • Specifying an invalid texture unit as a sampler could lead to a crash

    Internal code changes

      +
    • Some texture code consolidation and simplifiction (Ian Romanick) +
    • R300 driver clean-ups.
    -- cgit v1.2.3 From 3dec7c57b0159a4d8fbb980de73264ef8b8a3720 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 10 May 2007 16:14:10 -0600 Subject: document exp(), mod() fixes --- docs/relnotes-7.0.html | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index 51f0812538..f329134bab 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -30,6 +30,8 @@ TBD
    • Fixed a few fog-related bugs.
    • Fixed broken GLSL mix() function. +
    • Fixed broken GLSL exp() functions. +
    • Fixed GLSL mod4(vec4, vec4) bug.
    • Implemented GLSL asin(), acos(), atan() functions.
    • Fixed an R300 driver bug that caused Xorg composite manager to crash
    • Fixed R300 vertex program/matrix bug (10848) -- cgit v1.2.3 From 347bb541f5a89f59e502888a5ae486bc52abfb66 Mon Sep 17 00:00:00 2001 From: Brian Date: Mon, 14 May 2007 14:40:59 -0600 Subject: Skeleton file for 7.1 release notes. --- docs/relnotes-7.1.html | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ docs/relnotes.html | 1 + 2 files changed, 68 insertions(+) create mode 100644 docs/relnotes-7.1.html (limited to 'docs') diff --git a/docs/relnotes-7.1.html b/docs/relnotes-7.1.html new file mode 100644 index 0000000000..974b3096ea --- /dev/null +++ b/docs/relnotes-7.1.html @@ -0,0 +1,67 @@ + + +Mesa Release Notes + + + + + + + +

      Mesa 7.1 Release Notes / (in progress)

      + +

      +Mesa 7.1 is a new development release. +

      + + +

      MD5 checksums

      +
      +TBD
+
      + + +

      New features

      +
        +
      + + +

      Bug fixes

      +
        +
      + + +

      Internal code changes

      +
        +
      + + +

      To Do (someday) items

      +
        +
      • Switch to freeglut +
      • Fix linux-glide target/driver. +
      • Improved lambda and derivative calculation for frag progs. +
      + + +

      Driver Status

      + +
      +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
+
      + + + diff --git a/docs/relnotes.html b/docs/relnotes.html index c698dfe131..73bae8590f 100644 --- a/docs/relnotes.html +++ b/docs/relnotes.html @@ -20,6 +20,7 @@ The release notes summarize what's new or changed in each Mesa release.

        +
      • 7.1 release notes
      • 7.0 release notes
      • 6.5.3 release notes
      • 6.5.2 release notes -- cgit v1.2.3 From 9ebffb86a699e49fd683ed9afbf6d5b2ac244ae0 Mon Sep 17 00:00:00 2001 From: Ian Romanick Date: Wed, 16 May 2007 15:33:36 -0700 Subject: Initial version of MESA_texture_array spec. --- docs/MESA_texture_array.spec | 805 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 805 insertions(+) create mode 100644 docs/MESA_texture_array.spec (limited to 'docs') 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 parameter of Enable, Disable, and IsEnabled, by + the parameter of GetBooleanv, GetIntegerv, GetFloatv, and + GetDoublev, and by the parameter of TexImage3D, GetTexImage, + GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and + GetTexParameterfv: + + TEXTURE_1D_ARRAY_EXT 0x8C18 + TEXTURE_2D_ARRAY_EXT 0x8C1A + + Accepted by the parameter of TexImage2D, TexSubImage2D, + CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D, + CompressedTexSubImage2D, GetTexLevelParameteriv, and + GetTexLevelParameterfv: + + TEXTURE_1D_ARRAY_EXT + PROXY_TEXTURE_1D_ARRAY_EXT 0x8C19 + + Accepted by the parameter of TexImage3D, TexSubImage3D, + CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D, + GetTexLevelParameteriv, and GetTexLevelParameterfv: + + TEXTURE_2D_ARRAY_EXT + PROXY_TEXTURE_2D_ARRAY_EXT 0x8C1B + + Accepted by the 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 parameter of TexParameterf, TexParameteri, + TexParameterfv, and TexParameteriv when the 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 parameter of TexImage3D and + CompressedTexImage3D, and by the 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 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 + "" 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 is + TEXTURE_1D_ARRAY_EXT, and 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 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 . ..." + + -- 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 set to the desired texture target and 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 + texture coordinate, clamped to the range [0, 1]. For texture lookups + from two-dimesional array texture targets, let R be the interpolated + 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) + + ::= "MESA_texture_array" + + ::= "1D" + | "2D" + | "3D" + | "CUBE" + | "RECT" + | (if program option is present) + | (if program option is present) + + ::= "ARRAY1D" + | "ARRAY2D" + + ::= "SHADOW1D" + | "SHADOW2D" + | "SHADOWRECT" + | (if program option is present) + + ::= "SHADOWARRAY1D" + | "SHADOWARRAY2D" + + + -- Add Section 3.11.4.5.4 "Texture Stack Option" + + "If a fragment program specifies the "MESA_texture_array" program + option, the 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 + are used by all texture targets. Component usage for each + 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 , 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. is an integer indicating the + layer number, and is treated identically to the parameter in + FramebufferTexture3DEXT. The error INVALID_VALUE is generated if + is negative. The error INVALID_OPERATION is generated if + is non-zero and is not the name of a three dimensional + texture or one- or two-dimensional array texture. Unlike + FramebufferTexture3D, no parameter is accepted. + + If is non-zero and the command does not result in an error, + the framebuffer attachment state corresponding to is + updated as in the other FramebufferTexture commands, except that + FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to ." + + -- 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 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 will contain the number of texture layer attached to the + attachment point. Otherwise, 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 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.|| -- cgit v1.2.3 From 80a579871904a05226bceeca6cf8725f58ed358e Mon Sep 17 00:00:00 2001 From: Brian Date: Sat, 19 May 2007 08:29:04 -0600 Subject: added GL_EXT_texture_from_pixmap --- docs/relnotes-7.1.html | 1 + 1 file changed, 1 insertion(+) (limited to 'docs') diff --git a/docs/relnotes-7.1.html b/docs/relnotes-7.1.html index 974b3096ea..b684447e70 100644 --- a/docs/relnotes-7.1.html +++ b/docs/relnotes-7.1.html @@ -23,6 +23,7 @@ TBD

        New features

          +
        • GL_EXT_texture_from_pixmap extension for Xlib driver
        -- cgit v1.2.3 From d70fa021d51993b1555c3c3149326f48209e89f6 Mon Sep 17 00:00:00 2001 From: Brian Date: Tue, 12 Jun 2007 15:16:21 -0600 Subject: added memcpy() to-do item --- docs/relnotes-7.1.html | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'docs') diff --git a/docs/relnotes-7.1.html b/docs/relnotes-7.1.html index b684447e70..d5d285803e 100644 --- a/docs/relnotes-7.1.html +++ b/docs/relnotes-7.1.html @@ -39,6 +39,10 @@ TBD

        To Do (someday) items

          +
        • 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...
        • Switch to freeglut
        • Fix linux-glide target/driver.
        • Improved lambda and derivative calculation for frag progs. -- cgit v1.2.3 From 02dd2221b648f7ce03dca47965764c71ccfba4b1 Mon Sep 17 00:00:00 2001 From: Brian Date: Thu, 28 Jun 2007 16:44:24 -0600 Subject: bring over 7.0 doc changes --- docs/download.html | 6 +----- docs/intro.html | 2 +- docs/news.html | 2 +- docs/relnotes-7.0.html | 19 +++++++++++++++++-- 4 files changed, 20 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/download.html b/docs/download.html index 1afe64ef96..90f566351e 100644 --- a/docs/download.html +++ b/docs/download.html @@ -9,11 +9,7 @@

          Downloading

          -Last development release: 6.5.3 -

          - -

          -Last stable release: 6.4.2 +Last stable release: 7.0

          diff --git a/docs/intro.html b/docs/intro.html index ec481a9091..0e37322823 100644 --- a/docs/intro.html +++ b/docs/intro.html @@ -129,7 +129,7 @@ GL_ARB_fragment_program extensions.

          -May 2007: Mesa 7.0 is released, implementing the OpenGL 2.1 specification +June 2007: Mesa 7.0 is released, implementing the OpenGL 2.1 specification and OpenGL Shading Language.

          diff --git a/docs/news.html b/docs/news.html index cd09e2532d..58aca31858 100644 --- a/docs/news.html +++ b/docs/news.html @@ -11,7 +11,7 @@

          News

          -

          May ???, 2007

          +

          June 22, 2007

          Mesa 7.0 is released. This is a stable release featuring OpenGL 2.1 support. diff --git a/docs/relnotes-7.0.html b/docs/relnotes-7.0.html index f329134bab..2c036b2ec7 100644 --- a/docs/relnotes-7.0.html +++ b/docs/relnotes-7.0.html @@ -8,16 +8,25 @@ -

          Mesa 7.0 Release Notes / (in progress)

          +

          Mesa 7.0 Release Notes / June 22, 2007

          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.

          MD5 checksums

          -TBD
+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
          @@ -37,6 +46,12 @@ TBD
        • Fixed R300 vertex program/matrix bug (10848)
        • GLSL dFdx() and dFdy() work for fragment program inputs now (texcoords)
        • Specifying an invalid texture unit as a sampler could lead to a crash +
        • The GLX protocol request for glXDestroyPBuffer() was incorrect (bug 10983) +
        • ARB vp state.light[n].half value was incorrect (bug 10987) +
        • Fixed a positional light source bug (bug 11009) +
        • Fixed point size attenuation problem (bug 11042) +
        • glPopAttrib didn't restore texture object's LOD bias (bug 11049) +
        • Fixed a TLS / TEXTREL problem (bug 7459)
        -- cgit v1.2.3