Imported sources

.dir-locals.el

@@ -1,10 +0,0 @@
-((nil
-  (indent-tabs-mode . nil)
-  (tab-width . 8)
-  (c-basic-offset . 3)
-  (c-file-style . "stroustrup")
-  (eval . (progn
-	    (c-set-offset 'innamespace '0)
-	    (c-set-offset 'inline-open '0)))
-  )
- )

.gitattributes

@@ -1,4 +0,0 @@
-*.dsp -crlf
-*.dsw -crlf
-*.sln -crlf
-*.vcproj -crlf

.gitignore

@@ -1,43 +0,0 @@
-*.a
-*.dll
-*.exe
-*.ilk
-*.la
-*.lo
-*.o
-*.obj
-*.os
-*.pc
-*.pdb
-*.pyc
-*.pyo
-*.so
-*.so.*
-*.sw[a-z]
-*.tar
-*.tar.bz2
-*.tar.gz
-*.zip
-*~
-depend
-depend.bak
-bin/ltmain.sh
-lib
-lib64
-configure
-configure.lineno
-autom4te.cache
-aclocal.m4
-config.log
-config.status
-cscope*
-.scon*
-config.py
-build
-libtool
-manifest.txt
-Makefile.in
-.dir-locals.el
-.deps/
-.libs/
-/Makefile

Android.common.mk

@@ -1,63 +0,0 @@
-# Mesa 3-D graphics library
-#
-# Copyright (C) 2010-2011 Chia-I Wu <olvaffe@gmail.com>
-# Copyright (C) 2010-2011 LunarG Inc.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included
-# in all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-# use c99 compiler by default
-ifeq ($(LOCAL_CC),)
-ifeq ($(LOCAL_IS_HOST_MODULE),true)
-LOCAL_CC := $(HOST_CC) -std=c99
-else
-LOCAL_CC := $(TARGET_CC) -std=c99
-endif
-endif
-
-LOCAL_C_INCLUDES += \
-	$(MESA_TOP)/include
-
-# define ANDROID_VERSION (e.g., 4.0.x => 0x0400)
-major := $(word 1, $(subst ., , $(PLATFORM_VERSION)))
-minor := $(word 2, $(subst ., , $(PLATFORM_VERSION)))
-LOCAL_CFLAGS += \
-	-DANDROID_VERSION=0x0$(major)0$(minor)
-
-LOCAL_CFLAGS += \
-	-DPTHREADS \
-	-fvisibility=hidden \
-	-Wno-sign-compare
-
-ifeq ($(strip $(MESA_ENABLE_ASM)),true)
-ifeq ($(TARGET_ARCH),x86)
-LOCAL_CFLAGS += \
-	-DUSE_X86_ASM
-endif
-endif
-
-LOCAL_CPPFLAGS += \
-	-Wno-error=non-virtual-dtor \
-	-Wno-non-virtual-dtor
-
-# uncomment to keep the debug symbols
-#LOCAL_STRIP_MODULE := false
-
-ifeq ($(strip $(LOCAL_MODULE_TAGS)),)
-LOCAL_MODULE_TAGS := optional
-endif

Android.mk

@@ -1,94 +0,0 @@
-# Mesa 3-D graphics library
-#
-# Copyright (C) 2010-2011 Chia-I Wu <olvaffe@gmail.com>
-# Copyright (C) 2010-2011 LunarG Inc.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice shall be included
-# in all copies or substantial portions of the Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-# DEALINGS IN THE SOFTWARE.
-
-# BOARD_GPU_DRIVERS should be defined.  The valid values are
-#
-#   classic drivers: i915 i965
-#   gallium drivers: swrast i915g nouveau r300g r600g radeonsi vmwgfx
-#
-# The main target is libGLES_mesa.  For each classic driver enabled, a DRI
-# module will also be built.  DRI modules will be loaded by libGLES_mesa.
-
-MESA_TOP := $(call my-dir)
-MESA_COMMON_MK := $(MESA_TOP)/Android.common.mk
-MESA_PYTHON2 := python
-
-DRM_TOP := external/drm
-DRM_GRALLOC_TOP := hardware/drm_gralloc
-
-classic_drivers := i915 i965
-gallium_drivers := swrast i915g nouveau r300g r600g radeonsi vmwgfx
-
-MESA_GPU_DRIVERS := $(strip $(BOARD_GPU_DRIVERS))
-
-# warn about invalid drivers
-invalid_drivers := $(filter-out \
-	$(classic_drivers) $(gallium_drivers), $(MESA_GPU_DRIVERS))
-ifneq ($(invalid_drivers),)
-$(warning invalid GPU drivers: $(invalid_drivers))
-# tidy up
-MESA_GPU_DRIVERS := $(filter-out $(invalid_drivers), $(MESA_GPU_DRIVERS))
-endif
-
-# host and target must be the same arch to generate matypes.h
-ifeq ($(TARGET_ARCH),$(HOST_ARCH))
-MESA_ENABLE_ASM := true
-else
-MESA_ENABLE_ASM := false
-endif
-
-ifneq ($(filter $(classic_drivers), $(MESA_GPU_DRIVERS)),)
-MESA_BUILD_CLASSIC := true
-else
-MESA_BUILD_CLASSIC := false
-endif
-
-ifneq ($(filter $(gallium_drivers), $(MESA_GPU_DRIVERS)),)
-MESA_BUILD_GALLIUM := true
-else
-MESA_BUILD_GALLIUM := false
-endif
-
-# add subdirectories
-ifneq ($(strip $(MESA_GPU_DRIVERS)),)
-
-SUBDIRS := \
-	src/mapi \
-	src/glsl \
-	src/mesa \
-	src/egl/main
-
-ifeq ($(strip $(MESA_BUILD_CLASSIC)),true)
-SUBDIRS += \
-	src/egl/drivers/dri2 \
-	src/mesa/drivers/dri
-endif
-
-ifeq ($(strip $(MESA_BUILD_GALLIUM)),true)
-SUBDIRS += src/gallium
-endif
-
-mkfiles := $(patsubst %,$(MESA_TOP)/%/Android.mk,$(SUBDIRS))
-include $(mkfiles)
-
-endif

Makefile.X11

@@ -0,0 +1,521 @@
+# $Id: Makefile.X11,v 1.1.1.1 1999/08/19 00:55:39 jtg Exp $
+
+# Mesa 3-D graphics library
+# Version:  3.1
+# 
+# Copyright (C) 1999  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+
+# Top-level makefile for Mesa
+# To add a new configuration for your system add it to the list below
+# then update the Make-config file.
+
+SHELL = /bin/sh
+
+
+
+default:
+	@echo "Type one of the following:"
+	@echo "  make aix                  for IBM RS/6000 with AIX"
+	@echo "  make aix-sl               for IBM RS/6000, make shared libs"
+	@echo "  make amiwin               for Amiga with SAS/C and AmiWin"
+	@echo "  make amix                 for Amiga 3000 UX  SVR4 v2.1 systems"
+	@echo "  make beos-r4              for BeOS R4"
+	@echo "  make bsdos                for BSD/OS from BSDI using GCC"
+	@echo "  make bsdos4               for BSD/OS 4.x, dynamic libraries"
+	@echo "  make cygnus               for Win95/NT using Cygnus-Win32"
+	@echo "  make cygnus-linux         for Win95/NT using Cygnus-Win32 under Linux"
+	@echo "  make dgux                 for Data General"
+	@echo "  make freebsd              for FreeBSD systems with GCC"
+	@echo "  make freebsd-386          for FreeBSD systems with GCC, w/ Intel assembly"
+	@echo "  make gcc                  for a generic system with GCC"
+	@echo "  make hpux9                for HP systems with HPUX 9.x"
+	@echo "  make hpux9-sl             for HP systems with HPUX 9.x, make shared libs"
+	@echo "  make hpux9-gcc            for HP systems with HPUX 9.x using GCC"
+	@echo "  make hpux9-gcc-sl         for HP systems with HPUX 9.x, GCC, make shared libs"
+	@echo "  make hpux10               for HP systems with HPUX 10.x"
+	@echo "  make hpux10-sl            for HP systems with HPUX 10.x, shared libs"
+	@echo "  make hpux10-gcc           for HP systems with HPUX 10.x w/ GCC"
+	@echo "  make hpux10-gcc-sl        for HP systems with HPUX 10.x w/ GCC, shared libs"
+	@echo "  make irix4                for SGI systems with IRIX 4.x"
+	@echo "  make irix5                for SGI systems with IRIX 5.x"
+	@echo "  make irix5-gcc            for SGI systems with IRIX 5.x using GCC"
+	@echo "  make irix5-dso            for SGI systems with IRIX 5.x, make DSOs"
+	@echo "  make irix6-o32            for SGI systems with IRIX 6.x, make o32-bit libs"
+	@echo "  make irix6-o32-dso        for SGI systems with IRIX 6.x, make o32-bit DSOs"
+	@echo "  make irix6-n32            for SGI systems with IRIX 6.x, make n32-bit libs"
+	@echo "  make irix6-n32-dso        for SGI systems with IRIX 6.x, make n32-bit DSOs"
+	@echo "  make irix6-gcc-n32-sl     for SGI systems with IRIX 6.x, GCC, make n32 DSOs"
+	@echo "  make irix6-64             for SGI systems with IRIX 6.x, make 64-bit libs"
+	@echo "  make irix6-64-dso         for SGI systems with IRIX 6.x, make 64-bit DSOs"
+
+	@echo "  make linux                for Linux systems, make static .a libs"
+	@echo "  make linux-elf            for Linux systems, make ELF shared libs"
+	@echo "  make linux-386            for Linux w/ Intel assembly"
+	@echo "  make linux-386-elf        for Linux w/ Intel assembly, make ELF shared libs"
+	@echo "  make linux-ggi            for Linux systems with libggi"
+	@echo "  make linux-386-ggi        for Linux systems with libggi w/ Intel assembly"
+	@echo "  make linux-alpha          for Linux on Alpha systems"
+	@echo "  make linux-alpha-elf      for Linux on Alpha systems, make ELF shared libs"
+	@echo "  make linux-ppc            for Linux on PowerPC systems"
+	@echo "  make linux-ppc-so         for Linux on PowerPC systems, make shared libs"
+	@echo "  make linux-glide          for Linux w/ 3Dfx Glide driver"
+	@echo "  make linux-386-glide      for Linux w/ 3Dfx Glide driver, Intel assembly"
+	@echo "  make linux-386-opt-glide  for Linux with 3Dfx Voodoo1 for GLQuake"
+	@echo "  make linux-386-opt-V2-glide  for Linux with 3Dfx Voodoo2 for GLQuake"
+	@echo "  make linux-3dnow          for Linux on AMD w/ 3DNow!"
+	@echo "  make linux-3dnow-glide    for Linux on AMD w/ 3DNow! for Glide"
+	@echo "  make linux-386-pthread    for Linux w/ Intel assembly and linuxthreads"
+	@echo "  make linux-386-pthread-shared  for Linux w/ Intel assembly and linuxthreads"
+	@echo "  make linux-sparc          for Linux on Sparc systems"
+	@echo "  make linux-sparc5-elf     for Sparc5 systems, make ELF shared libs"
+	@echo "  make linux-sparc-ultra    for UltraSparc systems, make ELF shared libs"
+	@echo "  make lynxos               for LynxOS systems with GCC"
+	@echo "  make macintosh            for Macintosh"
+	@echo "  make machten-2.2          for Macs w/ MachTen 2.2 (68k w/ FPU)"
+	@echo "  make machten-4.0          for Macs w/ MachTen 4.0.1 or newer with GNU make"
+	@echo "  make mklinux              for Linux on Power Macintosh"
+	@echo "  make netbsd               for NetBSD 1.0 systems with GCC"
+	@echo "  make next                 for NeXT systems with NEXTSTEP 3.3"
+	@echo "  make openbsd              for OpenBSD systems"
+	@echo "  make openstep             for OpenStep/MacOSX Server systems"
+	@echo "  make os2-x11              for OS/2 with XFree86"
+	@echo "  make osf1                 for DEC Alpha systems with OSF/1"
+	@echo "  make osf1-sl              for DEC Alpha systems with OSF/1, make shared libs"
+	@echo "  make pgi-cygnus           for Cygnus with Portland Group, Inc. compiler"
+	@echo "  make pgi-mingw32          for mingW32 with Portland Group, Inc. compiler"
+	@echo "  make qnx                  for QNX V4 systems with Watcom compiler"
+	@echo "  make sco                  for SCO Unix systems with ODT"
+	@echo "  make solaris-x86          for PCs with Solaris"
+	@echo "  make solaris-x86-gcc      for PCs with Solaris using GCC"
+	@echo "  make sunos4               for Suns with SunOS 4.x"
+	@echo "  make sunos4-sl            for Suns with SunOS 4.x, make shared libs"
+	@echo "  make sunos4-gcc           for Suns with SunOS 4.x and GCC"
+	@echo "  make sunos4-gcc-sl        for Suns with SunOS 4.x, GCC, make shared libs"
+	@echo "  make sunos5               for Suns with SunOS 5.x"
+	@echo "  make sunos5-sl            for Suns with SunOS 5.x, make shared libs"
+	@echo "  make sunos5-ultra         for Sun UltraSPARCs with SunOS 5.x"
+	@echo "  make sunos5-ultra-sl      for Sun UltraSPARCs with SunOS 5.x, make shared libs"
+	@echo "  make sunos5-thread        for Suns with SunOS 5.x, using Solaris threads"
+	@echo "  make sunos5-pthread       for Suns with SunOS 5.[56] using POSIX threads"
+	@echo "  make sunos5-gcc-thread    for Suns with SunOS 5.x and GCC, using Solaris threads"
+	@echo "  make sunos5-gcc-pthread   for Suns with SunOS 5.[56] and GCC, using POSIX threads"
+	@echo "  make sunos5-gcc           for Suns with SunOS 5.x and GCC"
+	@echo "  make sunos5-gcc-sl        for Suns with SunOS 5.x, GCC, make shared libs"
+	@echo "  make sunos5-x11r6-gcc-sl  for Suns with X11R6, GCC, make shared libs"
+	@echo "  make sunos5-gcc-thread    for Suns with SunOS 5.x and GCC, using Solaris threads"
+	@echo "  make sunos5-gcc-pthread   for Suns with SunOS 5.[56] and GCC, using POSIX threads"
+	@echo "  make sunSolaris-CC        for Solaris using C++ compiler"
+	@echo "  make ultrix-gcc           for DEC systems with Ultrix and GCC"
+	@echo "  make unicos               for Cray C90 (and other?) systems"
+	@echo "  make unixware             for PCs running UnixWare"
+	@echo "  make unixware-shared      for PCs running UnixWare, shared libs"
+	@echo "  make uwin                 for Windows NT with AT&T/Wipro UWIN"
+	@echo "  make vistra               for Stardent Vistra systems"
+	@echo "  make clean                remove .o files"
+	@echo "  make realclean            remove .o, library and executable files"
+
+
+
+aix aix-sl amix bsdos bsdos4 dgux freebsd freebsd-386 gcc \
+hpux9 hpux9-sl hpux9-gcc hpux9-gcc-sl \
+hpux10 hpux10-sl hpux10-gcc hpux10-gcc-sl \
+irix-debug irix4 irix5 irix5-gcc irix5-dso irix6-o32 irix6-o32-dso \
+linux linux-debug linux-prof linux-elf linux-elf-debug \
+linux-glide linux-386-glide linux-386-opt-glide \
+linux-386-opt-V2-glide \
+linux-386 linux-386-elf \
+linux-3dnow linux-3dnow-glide \
+linux-alpha linux-alpha-elf \
+linux-ppc linux-ppc-so \
+linux-386-pthread linux-386-pthread-shared \
+linux-sparc \
+linux-sparc5-elf \
+linux-sparc-ultra \
+lynxos machten-2.2 machten-4.0 \
+mklinux netbsd osf1 osf1-sl openbsd qnx sco \
+solaris-x86 solaris-x86-gcc sunSolaris-CC \
+sunos4 sunos4-sl sunos4-gcc sunos4-gcc-sl sunos4-gcc-x11r6-sl \
+sunos5 sunos5-sl sunos5-ultra sunos5-ultra-sl sunos5-gcc sunos5-gcc-sl \
+sunos5-thread sunos5-pthread sunos5-gcc-thread sunos5-gcc-pthread \
+sunos5-x11r6-gcc-sl ultrix-gcc unicos unixware uwin vistra:
+	-mkdir lib
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	cd src ; $(MAKE) -f Makefile.X11 $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 $@
+	if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d demos ]    ; then cd demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d xdemos ]   ; then cd xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d samples ]  ; then cd samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d book ]     ; then cd book     ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+
+irix6-n32 irix6-n32-dso irix6-gcc-n32-sl:
+	-mkdir lib32
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	cd src ; $(MAKE) -f Makefile.X11 $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 $@
+	if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d demos ]    ; then cd demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d xdemos ]   ; then cd xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d samples ]  ; then cd samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d book ]     ; then cd book     ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+
+irix6-64 irix6-64-dso:
+	-mkdir lib64
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	cd src ; $(MAKE) -f Makefile.X11 $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 $@
+	if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d demos ]    ; then cd demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d xdemos ]   ; then cd xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d samples ]  ; then cd samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d book ]     ; then cd book     ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+
+amiwin:
+	bin/mklib.amiwin
+
+
+beos-r4:
+	-mkdir lib
+	-rm src/depend
+	touch src/depend
+	-rm src-glu/depend
+	touch src-glu/depend
+	cd src ; $(MAKE) -f Makefile.BeOS-R4 $@
+	cd src-glu ; $(MAKE) -f Makefile.BeOS-R4 $@
+	if [ -d BeOS ]          ; then cd BeOS          ; $(MAKE) ; fi
+	if [ -d src-glut.beos ] ; then cd src-glut.beos ; $(MAKE) ; fi
+	if [ -d src-glut.beos ] ; then cp src-glut.beos/obj*/libglut.so lib  ; fi
+	if [ -d demos ]   ; then cd demos   ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d book ]    ; then cd book    ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+
+pgi-cygnus pgi-mingw32 \
+cygnus cygnus-linux:
+	-mkdir lib
+	touch src/depend
+	touch src-glu/depend
+	cd src ; $(MAKE) -f Makefile.X11 $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 $@
+	cd src-glut ; $(MAKE) -f Makefile.X11 $@
+	cd demos ; $(MAKE) -f Makefile.X11 $@
+	if [ -d xdemos ]  ; then cd xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+macintosh:
+	@echo "See the README file for Macintosh intallation information"
+
+next:
+	-mkdir lib
+	cd src ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+
+openstep:
+	-mkdir lib
+	cd src ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+	cd src-glu ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+
+os2-x11:
+	if not EXIST .\lib md lib
+	touch src/depend
+	touch src-glu/depend
+	if exist src-glut touch src-glut/depend
+	cd src     & make -f Makefile.X11 $@
+	cd src-glu & make -f Makefile.X11 $@
+	if exist src-glut  cd src-glut & make -f Makefile.X11 $@
+	if exist demos     cd demos    & make -f Makefile.X11 $@
+	if exist xdemos    cd xdemos   & make -f Makefile.X11 $@
+	if exist samples   cd samples  & make -f Makefile.X11 $@
+	if exist book      cd book     & make -f Makefile.X11 $@
+
+linux-ggi linux-386-ggi:
+	-mkdir lib
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	if [ -d ggi ] ; then touch ggi/depend ; fi
+	cd src ; $(MAKE) -f Makefile.X11 $@
+	cd src/GGI/default ; $(MAKE)
+	cd src/GGI/display ; $(MAKE)
+	cd src-glu ; $(MAKE) -f Makefile.X11 $@
+#	if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d ggi ]      ; then cd ggi      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d ggi ]      ; then cd ggi/demos; $(MAKE)    ; fi
+	if [ -d demos ]    ; then cd demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d xdemos ]   ; then cd xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d samples ]  ; then cd samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d book ]     ; then cd book     ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+# if you change GGI_DEST please change it in ggimesa.conf, too.
+DESTDIR=/usr/local
+GGI_DEST=lib/ggi/mesa
+
+linux-ggi-install linux-386-ggi-install:
+	install -d $(DESTDIR)/$(GGI_DEST)/default $(DESTDIR)/$(GGI_DEST)/display $(DESTDIR)/etc/ggi
+	install -m 0755 src/GGI/default/*.so $(DESTDIR)/$(GGI_DEST)/default
+	install -m 0755 src/GGI/display/*.so $(DESTDIR)/$(GGI_DEST)/display
+	install -m 0644 src/GGI/ggimesa.conf $(DESTDIR)/etc/ggi
+#	if [ -z "`grep ggimesa $(DESTDIR)/etc/ggi/libggi.conf`" ]; then \
+#	echo ".include $(DESTDIR)/etc/ggi/ggimesa.conf" >> $(DESTDIR)/etc/ggi/libggi.conf ; \
+#	fi
+
+# Remove .o files, emacs backup files, etc.
+clean:
+	-rm -f ggi/*~ *.o
+	-rm -f src/GGI/default/*~ *.so
+	-rm -f src/GGI/display/*~ *.so
+	-rm -f include/*~
+	-rm -f include/GL/*~
+	-rm -f src/*.o src/*~ src/*.a src/*/*.o src/*/*~
+	-rm -f src-glu/*.o src-glu/*~ src-glu/*.a
+	-rm -f src-glut/*.o
+	-rm -f demos/*.o
+	-rm -f book/*.o book/*~
+	-rm -f xdemos/*.o xdemos/*~
+	-rm -f samples/*.o samples/*~
+	-rm -f ggi/*.o ggi/demos/*.o ggi/*.a
+
+# Remove everything that can be remade
+realclean: clean
+	-rm -f lib/*
+	cd demos       && $(MAKE) -f Makefile.X11 realclean || true
+	cd xdemos      && $(MAKE) -f Makefile.X11 realclean || true
+	cd book        && $(MAKE) -f Makefile.X11 realclean || true
+	cd samples     && $(MAKE) -f Makefile.X11 realclean || true
+	cd ggi/demos   && ($MAKE) -f Makefile.X11 realclean || true
+	cd src/GGI/default && $(MAKE) -f Makefile.X11 realclean || true
+
+
+
+DIRECTORY = Mesa-3.1
+LIB_NAME = MesaLib-3.1beta2
+DEMO_NAME = MesaDemos-3.1beta2
+
+
+LIB_FILES =	\
+	$(DIRECTORY)/Makefile*			\
+	$(DIRECTORY)/Make-config		\
+	$(DIRECTORY)/acconfig.h			\
+	$(DIRECTORY)/acinclude.m4		\
+	$(DIRECTORY)/aclocal.m4			\
+	$(DIRECTORY)/conf.h.in			\
+	$(DIRECTORY)/config.guess		\
+	$(DIRECTORY)/config.sub			\
+	$(DIRECTORY)/configure			\
+	$(DIRECTORY)/configure.in		\
+	$(DIRECTORY)/install-sh			\
+	$(DIRECTORY)/ltconfig			\
+	$(DIRECTORY)/ltmain.sh			\
+	$(DIRECTORY)/missing			\
+	$(DIRECTORY)/mkinstalldirs		\
+	$(DIRECTORY)/stamp-h.in			\
+	$(DIRECTORY)/INSTALL			\
+	$(DIRECTORY)/INSTALL.GNU		\
+	$(DIRECTORY)/configure			\
+	$(DIRECTORY)/docs/CONFIG		\
+	$(DIRECTORY)/docs/CONFORM		\
+	$(DIRECTORY)/docs/COPYRIGHT		\
+	$(DIRECTORY)/docs/IAFA-PACKAGE		\
+	$(DIRECTORY)/docs/LICENSE		\
+	$(DIRECTORY)/docs/README		\
+	$(DIRECTORY)/docs/README.*		\
+	$(DIRECTORY)/docs/RELNOTES		\
+	$(DIRECTORY)/docs/VERSIONS		\
+	$(DIRECTORY)/bin/mklib*			\
+	$(DIRECTORY)/*.BAT			\
+	$(DIRECTORY)/*.bat			\
+	$(DIRECTORY)/descrip.mms		\
+	$(DIRECTORY)/mms-config			\
+	$(DIRECTORY)/xlib.opt			\
+	$(DIRECTORY)/STARTUP.MK			\
+	$(DIRECTORY)/mesawin32.mak		\
+	$(DIRECTORY)/Names.win			\
+	$(DIRECTORY)/win32-openstep.sh		\
+	$(DIRECTORY)/*.dja			\
+	$(DIRECTORY)/include/GL/dosmesa.h	\
+	$(DIRECTORY)/include/GL/foomesa.h	\
+	$(DIRECTORY)/include/GL/fxmesa.h	\
+	$(DIRECTORY)/include/GL/ggimesa.h	\
+	$(DIRECTORY)/include/GL/gl.h		\
+	$(DIRECTORY)/include/GL/gl_mangle.h	\
+	$(DIRECTORY)/include/GL/glu.h		\
+	$(DIRECTORY)/include/GL/glu_mangle.h	\
+	$(DIRECTORY)/include/GL/glx.h		\
+	$(DIRECTORY)/include/GL/glx_mangle.h	\
+	$(DIRECTORY)/include/GL/mglmesa.h	\
+	$(DIRECTORY)/include/GL/osmesa.h	\
+	$(DIRECTORY)/include/GL/svgamesa.h	\
+	$(DIRECTORY)/include/GL/wmesa.h		\
+	$(DIRECTORY)/include/GL/xmesa.h		\
+	$(DIRECTORY)/include/GL/xmesa_x.h	\
+	$(DIRECTORY)/include/GL/xmesa_xf86.h	\
+	$(DIRECTORY)/include/GLView.h		\
+	$(DIRECTORY)/src/Makefile*		\
+	$(DIRECTORY)/src/descrip.mms		\
+	$(DIRECTORY)/src/mms_depend		\
+	$(DIRECTORY)/src/*.def			\
+	$(DIRECTORY)/src/depend			\
+	$(DIRECTORY)/src/*.[chS]		\
+	$(DIRECTORY)/src/Allegro/*.[ch]		\
+	$(DIRECTORY)/src/BeOS/*.cpp		\
+	$(DIRECTORY)/src/D3D/*.cpp		\
+	$(DIRECTORY)/src/D3D/*.CPP		\
+	$(DIRECTORY)/src/D3D/*.h		\
+	$(DIRECTORY)/src/D3D/*.H		\
+	$(DIRECTORY)/src/D3D/*.c		\
+	$(DIRECTORY)/src/D3D/*.C		\
+	$(DIRECTORY)/src/D3D/MAKEFILE		\
+	$(DIRECTORY)/src/D3D/*bat		\
+	$(DIRECTORY)/src/D3D/*DEF		\
+	$(DIRECTORY)/src/DOS/DEPEND.DOS		\
+	$(DIRECTORY)/src/DOS/*.c		\
+	$(DIRECTORY)/src/FX/*.[ch]		\
+	$(DIRECTORY)/src/FX/*.def		\
+	$(DIRECTORY)/src/GGI/*.[ch]		\
+	$(DIRECTORY)/src/GGI/ggimesa.conf	\
+	$(DIRECTORY)/src/GGI/default/*.c	\
+	$(DIRECTORY)/src/GGI/default/Makefile	\
+	$(DIRECTORY)/src/GGI/display/*.c	\
+	$(DIRECTORY)/src/GGI/display/Makefile	\
+	$(DIRECTORY)/src/KNOWN_BUGS		\
+	$(DIRECTORY)/src/MGL/*.[ch]		\
+	$(DIRECTORY)/src/MGL/*.txt		\
+	$(DIRECTORY)/src/OSmesa/*.[ch]		\
+	$(DIRECTORY)/src/S3/*.[ch]		\
+	$(DIRECTORY)/src/S3/*.def		\
+	$(DIRECTORY)/src/S3/*.mak		\
+	$(DIRECTORY)/src/S3/*.rc		\
+	$(DIRECTORY)/src/SVGA/*.[ch]		\
+	$(DIRECTORY)/src/Windows/*.[ch]		\
+	$(DIRECTORY)/src/Windows/*.def		\
+	$(DIRECTORY)/src/X/*.[ch]		\
+	$(DIRECTORY)/src/X86/*.[ch]		\
+	$(DIRECTORY)/src/X86/Makefile		\
+	$(DIRECTORY)/src/X86/*.m4		\
+	$(DIRECTORY)/src/X86/*.S		\
+	$(DIRECTORY)/src/*.dja			\
+	$(DIRECTORY)/src-glu/README[12]		\
+	$(DIRECTORY)/src-glu/Makefile*		\
+	$(DIRECTORY)/src-glu/descrip.mms	\
+	$(DIRECTORY)/src-glu/mms_depend		\
+	$(DIRECTORY)/src-glu/*.def		\
+	$(DIRECTORY)/src-glu/*.dja		\
+	$(DIRECTORY)/src-glu/depend		\
+	$(DIRECTORY)/src-glu/*.[ch]		\
+	$(DIRECTORY)/widgets-mesa		\
+	$(DIRECTORY)/widgets-sgi		\
+	$(DIRECTORY)/util/README		\
+	$(DIRECTORY)/util/*.[ch]		\
+	$(DIRECTORY)/util/sampleMakefile	\
+	$(DIRECTORY)/BeOS/Makefile		\
+	$(DIRECTORY)/BeOS/*.cpp			
+
+# old stuff
+#	$(DIRECTORY)/Win32			\
+#	$(DIRECTORY)/win32
+
+#	$(DIRECTORY)/OpenStep			\
+#
+#
+
+
+DEMO_FILES =	\
+	$(DIRECTORY)/include/GL/glut.h		\
+	$(DIRECTORY)/include/GL/glutf90.h	\
+	$(DIRECTORY)/include/GL/glut_h.dja	\
+	$(DIRECTORY)/src-glut/Makefile*		\
+	$(DIRECTORY)/src-glut/depend		\
+	$(DIRECTORY)/src-glut/*def		\
+	$(DIRECTORY)/src-glut/descrip.mms	\
+	$(DIRECTORY)/src-glut/mms_depend	\
+	$(DIRECTORY)/src-glut/*.[ch]		\
+	$(DIRECTORY)/src-glut.dja/*		\
+	$(DIRECTORY)/src-glut.beos/Makefile	\
+	$(DIRECTORY)/src-glut.beos/*.cpp	\
+	$(DIRECTORY)/src-glut.beos/*.h		\
+	$(DIRECTORY)/images/*			\
+	$(DIRECTORY)/demos/Makefile*		\
+	$(DIRECTORY)/demos/descrip.mms		\
+	$(DIRECTORY)/demos/*.[ch]		\
+	$(DIRECTORY)/demos/*.dat		\
+	$(DIRECTORY)/xdemos/Makefile*		\
+	$(DIRECTORY)/xdemos/descrip.mms		\
+	$(DIRECTORY)/xdemos/*.[cf]		\
+	$(DIRECTORY)/book/Makefile*		\
+	$(DIRECTORY)/book/README		\
+	$(DIRECTORY)/book/*.[ch]		\
+	$(DIRECTORY)/samples/Makefile*		\
+	$(DIRECTORY)/samples/README		\
+	$(DIRECTORY)/samples/*.c		\
+	$(DIRECTORY)/samples/*.dja		\
+	$(DIRECTORY)/3Dfx			\
+	$(DIRECTORY)/mtdemos			\
+	$(DIRECTORY)/ggi
+
+
+lib_tar:
+	cd .. ; \
+	tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
+	gzip $(LIB_NAME).tar ; \
+	mv $(LIB_NAME).tar.gz $(DIRECTORY)
+
+demo_tar:
+	cd .. ; \
+	tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
+	gzip $(DEMO_NAME).tar ; \
+	mv $(DEMO_NAME).tar.gz $(DIRECTORY)
+
+lib_zip:
+	-rm $(LIB_NAME).zip
+	cd .. ; \
+	zip -r $(LIB_NAME).zip $(LIB_FILES) ; \
+	mv $(LIB_NAME).zip $(DIRECTORY)
+
+demo_zip:
+	-rm $(DEMO_NAME).zip
+	cd .. ; \
+	zip -r $(DEMO_NAME).zip $(DEMO_FILES) ; \
+	mv $(DEMO_NAME).zip $(DIRECTORY)
+
+
+
+SRC_FILES =	\
+	RELNOTES		\
+	src/Makefile*		\
+	src/depend		\
+	src/*.[chS]		\
+	src/*/*.[ch]		\
+	include/GL/*.h
+
+srctar:
+	tar -cvf src.tar $(SRC_FILES) ; \
+	gzip src.tar
+
+srctar.zip:
+	-rm src.zip
+	zip -r src.zip $(SRC_FILES) ; \

Makefile.am

@@ -1,124 +0,0 @@
-# Copyright © 2012 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-
-SUBDIRS = src
-
-doxygen:
-	cd doxygen && $(MAKE)
-
-check-local:
-	$(MAKE) -C src/mapi/glapi/tests check
-	$(MAKE) -C src/mesa/main/tests check
-	$(MAKE) -C src/glsl/tests check
-	$(MAKE) -C src/glx/tests check
-
-clean-local:
-	-@touch $(top_builddir)/configs/current
-	-@for dir in $(SUBDIRS) ; do \
-		if [ -d $$dir ] ; then \
-			(cd $$dir && $(MAKE) clean) ; \
-		fi \
-	done
-	-@test -s $(top_builddir)/configs/current || rm -f $(top_builddir)/configs/current
-
-
-
-distclean-local:
-	-rm -rf lib*
-	-rm -f $(top_builddir)/configs/current
-	-find . '(' -name '*.o' -o -name '*.a' -o -name '*.so' -o \
-	  -name depend -o -name depend.bak ')' -exec rm -f '{}' ';'
-
-.PHONY: doxygen
-
-# Rules for making release tarballs
-
-PACKAGE_VERSION=8.1-devel
-PACKAGE_DIR = Mesa-$(PACKAGE_VERSION)
-PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
-
-EXTRA_FILES = \
-	aclocal.m4					\
-	configure					\
-	src/glsl/glsl_parser.cpp			\
-	src/glsl/glsl_parser.h				\
-	src/glsl/glsl_lexer.cpp				\
-	src/glsl/glcpp/glcpp-lex.c			\
-	src/glsl/glcpp/glcpp-parse.c			\
-	src/glsl/glcpp/glcpp-parse.h			\
-	src/mesa/main/api_exec_es1.c			\
-	src/mesa/main/api_exec_es1_dispatch.h		\
-	src/mesa/main/api_exec_es1_remap_helper.h	\
-	src/mesa/main/api_exec_es2.c			\
-	src/mesa/main/api_exec_es2_dispatch.h		\
-	src/mesa/main/api_exec_es2_remap_helper.h	\
-	src/mesa/program/lex.yy.c			\
-	src/mesa/program/program_parse.tab.c		\
-	src/mesa/program/program_parse.tab.h
-
-IGNORE_FILES = \
-	-x autogen.sh
-
-
-parsers: configure
-	-@touch $(top_builddir)/configs/current
-	$(MAKE) -C src/glsl glsl_parser.cpp glsl_parser.h glsl_lexer.cpp
-	$(MAKE) -C src/glsl/glcpp glcpp-lex.c glcpp-parse.c glcpp-parse.h
-	$(MAKE) -C src/mesa program/lex.yy.c program/program_parse.tab.c program/program_parse.tab.h
-
-# Everything for new a Mesa release:
-ARCHIVES = $(PACKAGE_NAME).tar.gz \
-	$(PACKAGE_NAME).tar.bz2 \
-	$(PACKAGE_NAME).zip
-
-tarballs: md5
-	rm -f ../$(PACKAGE_DIR) $(PACKAGE_NAME).tar
-
-manifest.txt: .git
-	( \
-		ls -1 $(EXTRA_FILES) ; \
-		git ls-files $(IGNORE_FILES) \
-	) | sed -e '/^\(.*\/\)\?\./d' -e "s@^@$(PACKAGE_DIR)/@" > $@
-
-../$(PACKAGE_DIR):
-	ln -s $(PWD) $@
-
-$(PACKAGE_NAME).tar: parsers ../$(PACKAGE_DIR) manifest.txt
-	cd .. ; tar -cf $(PACKAGE_DIR)/$(PACKAGE_NAME).tar -T $(PACKAGE_DIR)/manifest.txt
-
-$(PACKAGE_NAME).tar.gz: $(PACKAGE_NAME).tar ../$(PACKAGE_DIR)
-	gzip --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.gz
-
-$(PACKAGE_NAME).tar.bz2: $(PACKAGE_NAME).tar
-	bzip2 --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.bz2
-
-$(PACKAGE_NAME).zip: parsers ../$(PACKAGE_DIR) manifest.txt
-	rm -f $(PACKAGE_NAME).zip ; \
-	cd .. ; \
-	zip -q -@ $(PACKAGE_NAME).zip < $(PACKAGE_DIR)/manifest.txt ; \
-	mv $(PACKAGE_NAME).zip $(PACKAGE_DIR)
-
-md5: $(ARCHIVES)
-	@-md5sum $(PACKAGE_NAME).tar.gz
-	@-md5sum $(PACKAGE_NAME).tar.bz2
-	@-md5sum $(PACKAGE_NAME).zip
-
-.PHONY: tarballs md5

SConstruct

@@ -1,161 +0,0 @@
-#######################################################################
-# Top-level SConstruct
-#
-# For example, invoke scons as 
-#
-#   scons build=debug llvm=yes machine=x86
-#
-# to set configuration variables. Or you can write those options to a file
-# named config.py:
-#
-#   # config.py
-#   build='debug'
-#   llvm=True
-#   machine='x86'
-# 
-# Invoke
-#
-#   scons -h
-#
-# to get the full list of options. See scons manpage for more info.
-#  
-
-import os
-import os.path
-import sys
-import SCons.Util
-
-import common
-
-#######################################################################
-# Configuration options
-
-opts = Variables('config.py')
-common.AddOptions(opts)
-
-env = Environment(
-	options = opts,
-	tools = ['gallium'],
-	toolpath = ['#scons'],	
-	ENV = os.environ,
-)
-
-# XXX: This creates a many problems as it saves...
-#opts.Save('config.py', env)
-
-# Backwards compatability with old target configuration variable
-try:
-    targets = ARGUMENTS['targets']
-except KeyError:
-    pass
-else:
-    targets = targets.split(',')
-    print 'scons: warning: targets option is deprecated; pass the targets on their own such as'
-    print
-    print '  scons %s' % ' '.join(targets)
-    print 
-    COMMAND_LINE_TARGETS.append(targets)
-
-
-Help(opts.GenerateHelpText(env))
-
-# fail early for a common error on windows
-if env['gles']:
-    try:
-        import libxml2
-    except ImportError:
-        raise SCons.Errors.UserError, "GLES requires libxml2-python to build"
-
-#######################################################################
-# Environment setup
-
-# Includes
-env.Prepend(CPPPATH = [
-	'#/include',
-])
-env.Append(CPPPATH = [
-	'#/src/gallium/include',
-	'#/src/gallium/auxiliary',
-	'#/src/gallium/drivers',
-	'#/src/gallium/winsys',
-])
-
-if env['msvc']:
-    env.Append(CPPPATH = ['#include/c99'])
-
-# for debugging
-#print env.Dump()
-
-
-#######################################################################
-# Invoke host SConscripts 
-# 
-# For things that are meant to be run on the native host build machine, instead
-# of the target machine.
-#
-
-# Create host environent
-if env['crosscompile'] and not env['embedded']:
-    host_env = Environment(
-        options = opts,
-        # no tool used
-        tools = [],
-        toolpath = ['#scons'],
-        ENV = os.environ,
-    )
-
-    # Override options
-    host_env['platform'] = common.host_platform
-    host_env['machine'] = common.host_machine
-    host_env['toolchain'] = 'default'
-    host_env['llvm'] = False
-
-    host_env.Tool('gallium')
-
-    host_env['hostonly'] = True
-    assert host_env['crosscompile'] == False
-
-    if host_env['msvc']:
-        host_env.Append(CPPPATH = ['#include/c99'])
-
-    target_env = env
-    env = host_env
-    Export('env')
-
-    SConscript(
-        'src/SConscript',
-        variant_dir = host_env['build_dir'],
-        duplicate = 0, # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
-    )
-
-    env = target_env
-
-Export('env')
-
-#######################################################################
-# Invoke SConscripts
-
-# TODO: Build several variants at the same time?
-# http://www.scons.org/wiki/SimultaneousVariantBuilds
-
-SConscript(
-	'src/SConscript',
-	variant_dir = env['build_dir'],
-	duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
-)
-
-
-########################################################################
-# List all aliases
-
-try:
-    from SCons.Node.Alias import default_ans
-except ImportError:
-    pass
-else:
-    aliases = default_ans.keys()
-    aliases.sort()
-    env.Help('\n')
-    env.Help('Recognized targets:\n')
-    for alias in aliases:
-        env.Help('    %s\n' % alias)

acinclude.m4

@@ -1,119 +0,0 @@
-# A few convenience macros for Mesa, mostly to keep all the platform
-# specifics out of configure.ac.
-
-# MESA_PIC_FLAGS()
-#
-# Find out whether to build PIC code using the option --enable-pic and
-# the configure enable_static/enable_shared settings. If PIC is needed,
-# figure out the necessary flags for the platform and compiler.
-#
-# The platform checks have been shamelessly taken from libtool and
-# stripped down to just what's needed for Mesa. See _LT_COMPILER_PIC in
-# /usr/share/aclocal/libtool.m4 or
-# http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=blob;f=libltdl/m4/libtool.m4;hb=HEAD
-#
-AC_DEFUN([MESA_PIC_FLAGS],
-[AC_REQUIRE([AC_PROG_CC])dnl
-AC_ARG_VAR([PIC_FLAGS], [compiler flags for PIC code])
-AC_ARG_ENABLE([pic],
-    [AS_HELP_STRING([--disable-pic],
-        [compile PIC objects @<:@default=enabled for shared builds
-        on supported platforms@:>@])],
-    [enable_pic="$enableval"
-    test "x$enable_pic" = x && enable_pic=auto],
-    [enable_pic=auto])
-# disable PIC by default for static builds
-if test "$enable_pic" = auto && test "$enable_static" = yes; then
-    enable_pic=no
-fi
-# if PIC hasn't been explicitly disabled, try to figure out the flags
-if test "$enable_pic" != no; then
-    AC_MSG_CHECKING([for $CC option to produce PIC])
-    # allow the user's flags to override
-    if test "x$PIC_FLAGS" = x; then
-        # see if we're using GCC
-        if test "x$GCC" = xyes; then
-            case "$host_os" in
-            aix*|beos*|cygwin*|irix5*|irix6*|osf3*|osf4*|osf5*)
-                # PIC is the default for these OSes.
-                ;;
-            mingw*|os2*|pw32*)
-                # This hack is so that the source file can tell whether
-                # it is being built for inclusion in a dll (and should
-                # export symbols for example).
-                PIC_FLAGS="-DDLL_EXPORT"
-                ;;
-            darwin*|rhapsody*)
-                # PIC is the default on this platform
-                # Common symbols not allowed in MH_DYLIB files
-                PIC_FLAGS="-fno-common"
-                ;;
-            hpux*)
-                # PIC is the default for IA64 HP-UX and 64-bit HP-UX,
-                # but not for PA HP-UX.
-                case $host_cpu in
-                hppa*64*|ia64*)
-                    ;;
-                *)
-                    PIC_FLAGS="-fPIC"
-                    ;;
-                esac
-                ;;
-            *)
-                # Everyone else on GCC uses -fPIC
-                PIC_FLAGS="-fPIC"
-                ;;
-            esac
-        else # !GCC
-            case "$host_os" in
-            hpux9*|hpux10*|hpux11*)
-                # PIC is the default for IA64 HP-UX and 64-bit HP-UX,
-                # but not for PA HP-UX.
-                case "$host_cpu" in
-                hppa*64*|ia64*)
-                    # +Z the default
-                    ;;
-                *)
-                    PIC_FLAGS="+Z"
-                    ;;
-                esac
-                ;;
-            linux*|k*bsd*-gnu)
-                case `basename "$CC"` in
-                icc*|ecc*|ifort*)
-                    PIC_FLAGS="-KPIC"
-                    ;;
-                pgcc*|pgf77*|pgf90*|pgf95*)
-                    # Portland Group compilers (*not* the Pentium gcc
-                    # compiler, which looks to be a dead project)
-                    PIC_FLAGS="-fpic"
-                    ;;
-                ccc*)
-                    # All Alpha code is PIC.
-                    ;;
-                xl*)
-                    # IBM XL C 8.0/Fortran 10.1 on PPC
-                    PIC_FLAGS="-qpic"
-                    ;;
-                *)
-                    case `$CC -V 2>&1 | sed 5q` in
-                    *Sun\ C*|*Sun\ F*)
-                        # Sun C 5.9 or Sun Fortran
-                        PIC_FLAGS="-KPIC"
-                        ;;
-                    esac
-                esac
-                ;;
-            solaris*)
-                PIC_FLAGS="-KPIC"
-                ;;
-            sunos4*)
-                PIC_FLAGS="-PIC"
-                ;;
-            esac
-        fi # GCC
-    fi # PIC_FLAGS
-    AC_MSG_RESULT([$PIC_FLAGS])
-fi
-AC_SUBST([PIC_FLAGS])
-])# MESA_PIC_FLAGS

autogen.sh

@@ -1,20 +0,0 @@
-#! /bin/sh
-
-srcdir=`dirname "$0"`
-test -z "$srcdir" && srcdir=.
-
-SRCDIR=`(cd "$srcdir" && pwd)`
-ORIGDIR=`pwd`
-
-if test "x$SRCDIR" != "x$ORIGDIR"; then
-	echo "Mesa cannot be built when srcdir != builddir" 1>&2
-	exit 1
-fi
-
-MAKEFLAGS=""
-
-autoreconf -v --install || exit 1
-
-if test -z "$NOCONFIGURE"; then
-    "$srcdir"/configure "$@"
-fi

bin/.gitignore

@@ -1,8 +0,0 @@
-config.guess
-config.sub
-install-sh
-/depcomp
-/missing
-ylwrap
-compile
-ar-lib

bin/installmesa

@@ -1,74 +0,0 @@
-#!/bin/sh
-
-#
-# Simple shell script for installing Mesa's header and library files.
-# If the copy commands below don't work on a particular system (i.e. the
-# -f or -d flags), we may need to branch on `uname` to do the right thing.
-#
-
-
-TOP=.
-
-INCLUDE_DIR="/usr/local/include"
-LIB_DIR="/usr/local/lib"
-
-if [ "x$#" = "x0" ] ; then
-echo
-echo "***** Mesa installation - You may need root privileges to do this *****"
-echo
-echo "Default directory for header files is:" ${INCLUDE_DIR}
-echo "Enter new directory or press <Enter> to accept this default."
-
-read INPUT
-if [ "x${INPUT}" != "x" ] ; then
-	INCLUDE_DIR=${INPUT}
-fi
-
-echo
-echo "Default directory for library files is:" ${LIB_DIR}
-echo "Enter new directory or press <Enter> to accept this default."
-
-read INPUT
-if [ "x${INPUT}" != "x" ] ; then
-	LIB_DIR=${INPUT}
-fi
-
-echo
-echo "About to install Mesa header files (GL/*.h) in: " ${INCLUDE_DIR}/GL
-echo "and Mesa library files (libGL.*, etc) in: " ${LIB_DIR}
-echo "Press <Enter> to continue, or <ctrl>-C to abort."
-
-read INPUT
-
-else
-INCLUDE_DIR=$1/include
-LIB_DIR=$1/lib
-fi
-
-# flags:
-#  -f = force
-#  -d = preserve symlinks (does not work on BSD)
-
-if [ `uname` = "FreeBSD" ] ; then
-	CP_FLAGS="-f"
-elif [ `uname` = "Darwin" ] ; then
-	CP_FLAGS="-f"
-elif [ `uname` = "AIX" ] ; then
-	CP_FLAGS="-fh"
-else
-	CP_FLAGS="-fd"
-fi
-
-
-set -v
-
-mkdir -p ${INCLUDE_DIR}
-mkdir -p ${INCLUDE_DIR}/GL
-# NOT YET: mkdir -p ${INCLUDE_DIR}/GLES
-mkdir -p ${LIB_DIR}
-cp -f ${TOP}/include/GL/*.h ${INCLUDE_DIR}/GL
-cp -f ${TOP}/src/glw/*.h ${INCLUDE_DIR}/GL
-# NOT YET: cp -f ${TOP}/include/GLES/*.h ${INCLUDE_DIR}/GLES
-cp ${CP_FLAGS} ${TOP}/lib*/lib* ${LIB_DIR}
-
-echo "Done."

bin/minstall

@@ -1,112 +0,0 @@
-#!/bin/sh
-
-
-# A minimal replacement for 'install' that supports installing symbolic links.
-# Only a limited number of options are supported:
-# -d dir          Create a directory
-# -m mode         Sets a file's mode when installing
-
-
-# If these commands aren't portable, we'll need some "if (arch)" type stuff
-SYMLINK="ln -s"
-MKDIR="mkdir -p"
-RM="rm -f"
-
-MODE=""
-
-if [ "$1" = "-d" ] ; then
-	# make a directory path
-	$MKDIR "$2"
-	exit 0
-fi
-
-if [ "$1" = "-m" ] ; then
-	# set file mode
-	MODE=$2
-	shift 2
-fi
-
-# install file(s) into destination
-if [ $# -ge 2 ] ; then
-
-	# Last cmd line arg is the dest dir
-	for FILE in $@ ; do
-		DESTDIR="$FILE"
-	done
-
-	# Loop over args, moving them to DEST directory
-	I=1
-	for FILE in $@ ; do
-		if [ $I = $# ] ; then
-			# stop, don't want to install $DEST into $DEST
-			exit 0
-		fi
-
-                DEST=$DESTDIR
-
-                # On CYGWIN, because DLLs are loaded by the native Win32 loader,
-                # they are installed in the executable path.  Stub libraries used
-                # only for linking are installed in the library path
-                case `uname` in
-                    CYGWIN*)
-                        case $FILE in
-                            *.dll)
-                                DEST="$DEST/../bin"
-                                ;;
-                            *)
-                                ;;
-                        esac
-	                ;;
-                    *)
-                        ;;
-                esac
-
-		PWDSAVE=`pwd`
-
-		# determine file's type
-		if [ -h "$FILE" ] ; then
-			#echo $FILE is a symlink
-			# Unfortunately, cp -d isn't universal so we have to
-			# use a work-around.
-
-			# Use ls -l to find the target that the link points to
-			LL=`ls -l "$FILE"`
-			for L in $LL ; do
-				TARGET=$L
-			done
-			#echo $FILE is a symlink pointing to $TARGET
-
-			FILE=`basename "$FILE"`
-			# Go to $DEST and make the link
-			cd "$DEST"        # pushd
-				$RM "$FILE"
-				$SYMLINK "$TARGET" "$FILE"
-			cd "$PWDSAVE"     # popd
-
-		elif [ -f "$FILE" ] ; then
-			#echo "$FILE" is a regular file
-			# Only copy if the files differ
-			if ! cmp -s $FILE $DEST/`basename $FILE`; then
-				$RM "$DEST/`basename $FILE`"
-				cp "$FILE" "$DEST"
-			fi
-			if [ $MODE ] ; then
-				FILE=`basename "$FILE"`
-				chmod $MODE "$DEST/$FILE"
-			fi
-		else
-			echo "Unknown type of argument: " "$FILE"
-			exit 1
-		fi
-
-		I=`expr $I + 1`
-	done
-
-	exit 0
-fi
-
-# If we get here, we didn't find anything to do
-echo "Usage:"
-echo "  install -d dir                      Create named directory"
-echo "  install [-m mode] file [...] dest   Install files in destination"
-

bin/shortlog_mesa.sh

@@ -1,23 +0,0 @@
-#!/bin/bash
-
-# This script is used to generate the list of changes that
-# appears in the release notes files, with HTML formatting.
-
-
-typeset -i in_log=0
-
-git shortlog $* | while read l
-do
-    if [ $in_log -eq 0 ]; then
-	echo '<p>'$l'</p>'
-	echo '<ul>'
-	in_log=1
-    elif echo "$l" | egrep -q '^$' ; then
-	echo '</ul>'
-	echo
-	in_log=0
-    else
-        mesg=$(echo $l | sed 's/ (cherry picked from commit [0-9a-f]\+)//;s/\&/&amp;/g;s/</\&lt;/g;s/>/\&gt;/g')
-	echo '  <li>'${mesg}'</li>'
-    fi
-done

common.py

@@ -1,102 +0,0 @@
-#######################################################################
-# Common SCons code
-
-import os
-import os.path
-import re
-import subprocess
-import sys
-import platform as _platform
-
-import SCons.Script.SConscript
-
-
-#######################################################################
-# Defaults
-
-host_platform = _platform.system().lower()
-if host_platform.startswith('cygwin'):
-    host_platform = 'cygwin'
-
-# Search sys.argv[] for a "platform=foo" argument since we don't have
-# an 'env' variable at this point.
-if 'platform' in SCons.Script.ARGUMENTS:
-    target_platform = SCons.Script.ARGUMENTS['platform']
-else:
-    target_platform = host_platform
-
-_machine_map = {
-	'x86': 'x86',
-	'i386': 'x86',
-	'i486': 'x86',
-	'i586': 'x86',
-	'i686': 'x86',
-	'BePC': 'x86',
-	'Intel': 'x86',
-	'ppc' : 'ppc',
-	'BeBox': 'ppc',
-	'BeMac': 'ppc',
-	'AMD64': 'x86_64',
-	'x86_64': 'x86_64',
-	'sparc': 'sparc',
-	'sun4u': 'sparc',
-}
-
-
-# find host_machine value
-if 'PROCESSOR_ARCHITECTURE' in os.environ:
-	host_machine = os.environ['PROCESSOR_ARCHITECTURE']
-else:
-	host_machine = _platform.machine()
-host_machine = _machine_map.get(host_machine, 'generic')
-
-default_machine = host_machine
-default_toolchain = 'default'
-
-if target_platform == 'windows' and host_platform != 'windows':
-    default_machine = 'x86'
-    default_toolchain = 'crossmingw'
-
-
-# find default_llvm value
-if 'LLVM' in os.environ:
-    default_llvm = 'yes'
-else:
-    default_llvm = 'no'
-    try:
-        if target_platform != 'windows' and \
-           subprocess.call(['llvm-config', '--version'], stdout=subprocess.PIPE) == 0:
-            default_llvm = 'yes'
-    except:
-        pass
-
-
-#######################################################################
-# Common options
-
-def AddOptions(opts):
-	try:
-		from SCons.Variables.BoolVariable import BoolVariable as BoolOption
-	except ImportError:
-		from SCons.Options.BoolOption import BoolOption
-	try:
-		from SCons.Variables.EnumVariable import EnumVariable as EnumOption
-	except ImportError:
-		from SCons.Options.EnumOption import EnumOption
-	opts.Add(EnumOption('build', 'build type', 'debug',
-	                  allowed_values=('debug', 'checked', 'profile', 'release')))
-	opts.Add(BoolOption('verbose', 'verbose output', 'no'))
-	opts.Add(EnumOption('machine', 'use machine-specific assembly code', default_machine,
-											 allowed_values=('generic', 'ppc', 'x86', 'x86_64')))
-	opts.Add(EnumOption('platform', 'target platform', host_platform,
-											 allowed_values=('cygwin', 'darwin', 'freebsd', 'haiku', 'linux', 'sunos', 'windows')))
-	opts.Add(BoolOption('embedded', 'embedded build', 'no'))
-	opts.Add('toolchain', 'compiler toolchain', default_toolchain)
-	opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', 'no'))
-	opts.Add(BoolOption('llvm', 'use LLVM', default_llvm))
-	opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp (swrast)', 'no'))
-	opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes'))
-	opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no'))
-	opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes'))
-	if host_platform == 'windows':
-		opts.Add(EnumOption('MSVS_VERSION', 'MS Visual C++ version', None, allowed_values=('7.1', '8.0', '9.0')))

configs/.gitignore

@@ -1,2 +0,0 @@
-current
-autoconf

configs/current.in

@@ -1,227 +0,0 @@
-# Autoconf configuration
-
-# Pull in the defaults
-include $(TOP)/configs/default
-
-# This is generated by configure
-CONFIG_NAME = autoconf
-
-# Compiler and flags
-CC = @CC@
-CXX = @CXX@
-OPT_FLAGS = @OPT_FLAGS@
-ARCH_FLAGS = @ARCH_FLAGS@
-PIC_FLAGS = @PIC_FLAGS@
-DEFINES = @DEFINES@
-API_DEFINES = @API_DEFINES@
-SHARED_GLAPI = @SHARED_GLAPI@
-CFLAGS_NOVISIBILITY = @CPPFLAGS@ @CFLAGS@ \
-	$(OPT_FLAGS) $(PIC_FLAGS) $(ARCH_FLAGS) $(DEFINES)
-CXXFLAGS_NOVISIBILITY = @CPPFLAGS@ @CXXFLAGS@ \
-	$(OPT_FLAGS) $(PIC_FLAGS) $(ARCH_FLAGS) $(DEFINES)
-CFLAGS = $(CFLAGS_NOVISIBILITY) @VISIBILITY_CFLAGS@
-CXXFLAGS = $(CXXFLAGS_NOVISIBILITY) @VISIBILITY_CXXFLAGS@
-LDFLAGS = @LDFLAGS@
-EXTRA_LIB_PATH = @EXTRA_LIB_PATH@
-RADEON_CFLAGS = @RADEON_CFLAGS@
-RADEON_LIBS = @RADEON_LIBS@
-NOUVEAU_CFLAGS = @NOUVEAU_CFLAGS@
-NOUVEAU_LIBS = @NOUVEAU_LIBS@
-INTEL_LIBS = @INTEL_LIBS@
-INTEL_CFLAGS = @INTEL_CFLAGS@
-X11_LIBS = @X11_LIBS@
-X11_CFLAGS = @X11_CFLAGS@
-LLVM_BINDIR = @LLVM_BINDIR@
-LLVM_CFLAGS = @LLVM_CFLAGS@
-LLVM_CPPFLAGS = @LLVM_CPPFLAGS@
-LLVM_CXXFLAGS = @LLVM_CXXFLAGS@
-LLVM_LDFLAGS = @LLVM_LDFLAGS@
-LLVM_LIBDIR = @LLVM_LIBDIR@
-LLVM_LIBS = @LLVM_LIBS@
-LLVM_INCLUDEDIR = @LLVM_INCLUDEDIR@
-GLW_CFLAGS = @GLW_CFLAGS@
-GLX_TLS = @GLX_TLS@
-
-# dlopen
-DLOPEN_LIBS = @DLOPEN_LIBS@
-
-# Source selection
-MESA_ASM_FILES = @MESA_ASM_FILES@
-GLAPI_ASM_SOURCES = @GLAPI_ASM_SOURCES@
-
-# Misc tools and flags
-MAKE = @MAKE@
-SHELL = @SHELL@
-MKLIB_OPTIONS = @MKLIB_OPTIONS@
-MKDEP = @MKDEP@
-MKDEP_OPTIONS = @MKDEP_OPTIONS@
-INSTALL = @INSTALL@
-AWK = @AWK@
-GREP = @GREP@
-NM = @NM@
-
-# Perl
-PERL = @PERL@
-
-# Indent (used for generating dispatch tables)
-INDENT = @INDENT@
-INDENT_FLAGS = @INDENT_FLAGS@
-
-# Python and flags (generally only needed by the developers)
-PYTHON2 = @PYTHON2@
-PYTHON_FLAGS = -t -O -O
-
-# Flex and Bison for GLSL compiler
-FLEX = @LEX@
-BISON = @YACC@
-
-# Library names (base name)
-GL_LIB = @GL_LIB@
-GLU_LIB = @GLU_LIB@
-GLW_LIB = GLw
-OSMESA_LIB = @OSMESA_LIB@
-GLESv1_CM_LIB = GLESv1_CM
-GLESv2_LIB = GLESv2
-VG_LIB = OpenVG
-GLAPI_LIB = glapi
-
-# Library names (actual file names)
-GL_LIB_NAME = @GL_LIB_NAME@
-GLU_LIB_NAME = @GLU_LIB_NAME@
-GLW_LIB_NAME = @GLW_LIB_NAME@
-OSMESA_LIB_NAME = @OSMESA_LIB_NAME@
-EGL_LIB_NAME = @EGL_LIB_NAME@
-GLESv1_CM_LIB_NAME = @GLESv1_CM_LIB_NAME@
-GLESv2_LIB_NAME = @GLESv2_LIB_NAME@
-VG_LIB_NAME = @VG_LIB_NAME@
-GLAPI_LIB_NAME = @GLAPI_LIB_NAME@
-
-# Globs used to install the lib and all symlinks
-GL_LIB_GLOB = @GL_LIB_GLOB@
-GLU_LIB_GLOB = @GLU_LIB_GLOB@
-GLW_LIB_GLOB = @GLW_LIB_GLOB@
-OSMESA_LIB_GLOB = @OSMESA_LIB_GLOB@
-EGL_LIB_GLOB = @EGL_LIB_GLOB@
-GLESv1_CM_LIB_GLOB = @GLESv1_CM_LIB_GLOB@
-GLESv2_LIB_GLOB = @GLESv2_LIB_GLOB@
-VG_LIB_GLOB = @VG_LIB_GLOB@
-GLAPI_LIB_GLOB = @GLAPI_LIB_GLOB@
-
-# Directories to build
-LIB_DIR = @LIB_DIR@
-SRC_DIRS = @SRC_DIRS@
-GLU_DIRS = @GLU_DIRS@
-DRIVER_DIRS = @DRIVER_DIRS@
-GALLIUM_DIRS = @GALLIUM_DIRS@
-GALLIUM_DRIVERS_DIRS = @GALLIUM_DRIVERS_DIRS@
-GALLIUM_WINSYS_DIRS = @GALLIUM_WINSYS_DIRS@
-GALLIUM_TARGET_DIRS = @GALLIUM_TARGET_DIRS@
-GALLIUM_STATE_TRACKERS_DIRS = @GALLIUM_STATE_TRACKERS_DIRS@
-GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a
-GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a)
-
-# Driver specific build vars
-DRI_DIRS = @DRI_DIRS@
-EGL_PLATFORMS = @EGL_PLATFORMS@
-EGL_CLIENT_APIS = @EGL_CLIENT_APIS@
-
-# Dependencies
-X11_INCLUDES = @X11_INCLUDES@
-
-# GLw motif setup
-GLW_SOURCES = @GLW_SOURCES@
-MOTIF_CFLAGS = @MOTIF_CFLAGS@
-
-# Library/program dependencies
-GL_LIB_DEPS = $(EXTRA_LIB_PATH) @GL_LIB_DEPS@
-OSMESA_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @OSMESA_MESA_DEPS@ \
-	$(EXTRA_LIB_PATH) @OSMESA_LIB_DEPS@
-EGL_LIB_DEPS = $(EXTRA_LIB_PATH) @EGL_LIB_DEPS@
-GLU_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @GLU_MESA_DEPS@ \
-	$(EXTRA_LIB_PATH) @GLU_LIB_DEPS@
-GLW_LIB_DEPS = -L$(TOP)/$(LIB_DIR) @GLW_MESA_DEPS@ \
-	$(EXTRA_LIB_PATH) @GLW_LIB_DEPS@
-GLESv1_CM_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv1_CM_LIB_DEPS@
-GLESv2_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv2_LIB_DEPS@
-VG_LIB_DEPS = $(EXTRA_LIB_PATH) @VG_LIB_DEPS@
-GLAPI_LIB_DEPS = $(EXTRA_LIB_PATH) @GLAPI_LIB_DEPS@
-
-# DRI dependencies
-MESA_MODULES = @MESA_MODULES@
-DRI_LIB_DEPS = $(EXTRA_LIB_PATH) @DRI_LIB_DEPS@
-LIBDRM_CFLAGS = @LIBDRM_CFLAGS@
-LIBDRM_LIB = @LIBDRM_LIBS@
-DRI2PROTO_CFLAGS = @DRI2PROTO_CFLAGS@
-GLPROTO_CFLAGS = @GLPROTO_CFLAGS@
-EXPAT_INCLUDES = @EXPAT_INCLUDES@
-
-# Autoconf directories
-prefix = @prefix@
-exec_prefix = @exec_prefix@
-libdir = @libdir@
-includedir = @includedir@
-
-# Installation directories (for make install)
-INSTALL_DIR = $(prefix)
-INSTALL_LIB_DIR = $(libdir)
-INSTALL_INC_DIR = $(includedir)
-
-# DRI installation directories
-DRI_DRIVER_INSTALL_DIR = @DRI_DRIVER_INSTALL_DIR@
-
-# Where libGL will look for DRI hardware drivers
-DRI_DRIVER_SEARCH_DIR = @DRI_DRIVER_SEARCH_DIR@
-
-# EGL driver install directory
-EGL_DRIVER_INSTALL_DIR = @EGL_DRIVER_INSTALL_DIR@
-
-# XVMC library install directory
-XVMC_LIB_INSTALL_DIR=@XVMC_LIB_INSTALL_DIR@
-
-# VDPAU library install directory
-VDPAU_LIB_INSTALL_DIR=@VDPAU_LIB_INSTALL_DIR@
-
-# VA library install directory
-VA_LIB_INSTALL_DIR=@VA_LIB_INSTALL_DIR@
-
-# Xorg driver install directory (for xorg state-tracker)
-XORG_DRIVER_INSTALL_DIR = @XORG_DRIVER_INSTALL_DIR@
-
-# Path to OpenCL C library libclc
-LIBCLC_PATH = @LIBCLC_PATH@
-
-# pkg-config substitutions
-GL_PC_REQ_PRIV = @GL_PC_REQ_PRIV@
-GL_PC_LIB_PRIV = @GL_PC_LIB_PRIV@
-GL_PC_CFLAGS = @GL_PC_CFLAGS@
-DRI_PC_REQ_PRIV = @DRI_PC_REQ_PRIV@
-GLU_PC_REQ = @GLU_PC_REQ@
-GLU_PC_REQ_PRIV = @GLU_PC_REQ_PRIV@
-GLU_PC_LIB_PRIV = @GLU_PC_LIB_PRIV@
-GLU_PC_CFLAGS = @GLU_PC_CFLAGS@
-GLW_PC_REQ_PRIV = @GLW_PC_REQ_PRIV@
-GLW_PC_LIB_PRIV = @GLW_PC_LIB_PRIV@
-GLW_PC_CFLAGS = @GLW_PC_CFLAGS@
-OSMESA_PC_REQ = @OSMESA_PC_REQ@
-OSMESA_PC_LIB_PRIV = @OSMESA_PC_LIB_PRIV@
-GLESv1_CM_PC_LIB_PRIV = @GLESv1_CM_PC_LIB_PRIV@
-GLESv2_PC_LIB_PRIV = @GLESv2_PC_LIB_PRIV@
-EGL_PC_REQ_PRIV = @GL_PC_REQ_PRIV@
-EGL_PC_LIB_PRIV = @GL_PC_LIB_PRIV@
-EGL_PC_CFLAGS = @GL_PC_CFLAGS@
-
-XCB_DRI2_CFLAGS = @XCB_DRI2_CFLAGS@
-XCB_DRI2_LIBS = @XCB_DRI2_LIBS@
-LIBUDEV_CFLAGS = @LIBUDEV_CFLAGS@
-LIBUDEV_LIBS = @LIBUDEV_LIBS@
-WAYLAND_CFLAGS = @WAYLAND_CFLAGS@
-WAYLAND_LIBS = @WAYLAND_LIBS@
-
-MESA_LLVM = @MESA_LLVM@
-
-LLVM_VERSION = @LLVM_VERSION@
-
-HAVE_XF86VIDMODE = @HAVE_XF86VIDMODE@
-
-GALLIUM_PIPE_LOADER_DEFINES = @GALLIUM_PIPE_LOADER_DEFINES@
-GALLIUM_PIPE_LOADER_LIBS = @GALLIUM_PIPE_LOADER_LIBS@

configs/default

@@ -1,182 +0,0 @@
-# Default/template configuration
-
-# This is included by other config files which may override some
-# of these variables.
-# Think of this as a base class from which configs are derived.
-
-
-CONFIG_NAME = default
-
-# Version info
-MESA_MAJOR=8
-MESA_MINOR=1
-MESA_TINY=0
-MESA_VERSION = $(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY)
-
-# external projects.  This should be useless now that we use libdrm.
-DRM_SOURCE_PATH=$(TOP)/../drm
-
-# Compiler and flags
-CC = cc
-CXX = CC
-CFLAGS = -O
-CXXFLAGS = -O
-LDFLAGS =
-GLU_CFLAGS = 
-GLX_TLS = no
-
-# Compiler for building demos/tests/etc
-APP_CC = $(CC)
-APP_CXX = $(CXX)
-
-# Misc tools and flags
-SHELL = /bin/sh
-MKLIB = $(SHELL) $(TOP)/bin/mklib
-MKLIB_OPTIONS = 
-MKDEP = makedepend
-MKDEP_OPTIONS = -fdepend
-MAKE = make
-FLEX = flex
-BISON = bison
-PKG_CONFIG = pkg-config
-
-# Use MINSTALL for installing libraries, INSTALL for everything else
-MINSTALL = $(SHELL) $(TOP)/bin/minstall
-INSTALL = $(MINSTALL)
-
-# Tools for regenerating glapi (generally only needed by the developers)
-PYTHON2 = python
-PYTHON_FLAGS = -t -O -O
-INDENT = indent
-INDENT_FLAGS = -i4 -nut -br -brs -npcs -ce -T GLubyte -T GLbyte -T Bool
-
-# Library names (base name)
-GL_LIB = GL
-GLU_LIB = GLU
-GLW_LIB = GLw
-OSMESA_LIB = OSMesa
-EGL_LIB = EGL
-GLESv1_CM_LIB = GLESv1_CM
-GLESv2_LIB = GLESv2
-VG_LIB = OpenVG
-GLAPI_LIB = glapi
-
-# Library names (actual file names)
-GL_LIB_NAME = lib$(GL_LIB).so
-GLU_LIB_NAME = lib$(GLU_LIB).so
-GLW_LIB_NAME = lib$(GLW_LIB).so
-OSMESA_LIB_NAME = lib$(OSMESA_LIB).so
-EGL_LIB_NAME = lib$(EGL_LIB).so
-GLESv1_CM_LIB_NAME = lib$(GLESv1_CM_LIB).so
-GLESv2_LIB_NAME = lib$(GLESv2_LIB).so
-VG_LIB_NAME = lib$(VG_LIB).so
-GLAPI_LIB_NAME = lib$(GLAPI_LIB).so
-
-# globs used to install the lib and all symlinks
-GL_LIB_GLOB = $(GL_LIB_NAME)*
-GLU_LIB_GLOB = $(GLU_LIB_NAME)*
-GLW_LIB_GLOB = $(GLW_LIB_NAME)*
-OSMESA_LIB_GLOB = $(OSMESA_LIB_NAME)*
-EGL_LIB_GLOB = $(EGL_LIB_NAME)*
-GLESv1_CM_LIB_GLOB = $(GLESv1_CM_LIB_NAME)*
-GLESv2_LIB_GLOB = $(GLESv2_LIB_NAME)*
-VG_LIB_GLOB = $(VG_LIB_NAME)*
-GLAPI_LIB_GLOB = $(GLAPI_LIB_NAME)*
-
-# Optional assembly language optimization files for libGL
-MESA_ASM_FILES =
-
-# GLw widget sources (Append "GLwMDrawA.c" here and add -lXm to GLW_LIB_DEPS in
-# order to build the Motif widget too)
-GLW_SOURCES = GLwDrawA.c
-MOTIF_CFLAGS = -I/usr/include/Motif1.2
-
-
-# Directories to build
-LIB_DIR = lib
-SRC_DIRS = glsl mapi/glapi mapi/vgapi mesa \
-	gallium egl gallium/winsys gallium/targets glu
-GLU_DIRS = sgi
-DRIVER_DIRS = x11 osmesa
-
-# Gallium directories and
-GALLIUM_DIRS = auxiliary drivers state_trackers
-GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a
-GALLIUM_DRIVERS_DIRS = softpipe trace rbug noop identity galahad i915 svga r300 nvfx nv50
-GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a)
-GALLIUM_WINSYS_DIRS = sw sw/xlib
-GALLIUM_TARGET_DIRS = libgl-xlib
-GALLIUM_STATE_TRACKERS_DIRS = glx vega
-
-# native platforms EGL should support
-EGL_PLATFORMS = x11
-EGL_CLIENT_APIS = $(GL_LIB)
-
-# Library dependencies
-#EXTRA_LIB_PATH ?=
-GL_LIB_DEPS     = $(EXTRA_LIB_PATH) -lX11 -lXext -lm -lpthread
-EGL_LIB_DEPS    = $(EXTRA_LIB_PATH) -ldl -lpthread
-OSMESA_LIB_DEPS = $(EXTRA_LIB_PATH) -L$(TOP)/$(LIB_DIR) -l$(GL_LIB)
-GLU_LIB_DEPS    = $(EXTRA_LIB_PATH) -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -lm
-GLW_LIB_DEPS    = $(EXTRA_LIB_PATH) -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -lXt -lX11
-GLESv1_CM_LIB_DEPS = $(EXTRA_LIB_PATH) -lpthread
-GLESv2_LIB_DEPS = $(EXTRA_LIB_PATH) -lpthread
-VG_LIB_DEPS    = $(EXTRA_LIB_PATH) -lpthread
-GLAPI_LIB_DEPS = $(EXTRA_LIB_PATH) -lpthread
-
-# Program dependencies - specific GL libraries added in Makefiles
-X11_LIBS = -lX11
-
-DLOPEN_LIBS = -ldl
-
-# Installation directories (for make install)
-INSTALL_DIR = /usr/local
-INSTALL_LIB_DIR = $(INSTALL_DIR)/$(LIB_DIR)
-INSTALL_INC_DIR = $(INSTALL_DIR)/include
-DRI_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/dri
-
-# Where libGL will look for DRI hardware drivers
-DRI_DRIVER_SEARCH_DIR = $(DRI_DRIVER_INSTALL_DIR)
-
-# EGL driver install directory
-EGL_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/egl
-
-# Xorg driver install directory (for xorg state-tracker)
-XORG_DRIVER_INSTALL_DIR = $(INSTALL_LIB_DIR)/xorg/modules/drivers
-
-# pkg-config substitutions
-GL_PC_REQ_PRIV =
-GL_PC_LIB_PRIV =
-GL_PC_CFLAGS =
-DRI_PC_REQ_PRIV =
-GLU_PC_REQ = gl
-GLU_PC_REQ_PRIV =
-GLU_PC_LIB_PRIV =
-GLU_PC_CFLAGS =
-GLW_PC_REQ_PRIV =
-GLW_PC_LIB_PRIV =
-GLW_PC_CFLAGS =
-OSMESA_PC_REQ =
-OSMESA_PC_LIB_PRIV =
-GLESv1_CM_PC_REQ_PRIV =
-GLESv1_CM_PC_LIB_PRIV =
-GLESv1_CM_PC_CFLAGS =
-GLESv2_PC_REQ_PRIV =
-GLESv2_PC_LIB_PRIV =
-GLESv2_PC_CFLAGS =
-VG_PC_REQ_PRIV =
-VG_PC_LIB_PRIV =
-VG_PC_CFLAGS =
-
-# default targets
-# this helps reduce the mismatch between our automake Makefiles and the old
-# custom Makefiles while we transition.
-
-all: default
-
-am--refresh:
-
-distclean: clean
-
-check:
-test:

docs/ARB_color_buffer_float.txt

@@ -1,4 +0,0 @@
-Known issues in the ARB_color_buffer_float implementation:
-- Rendering to multiple render targets, some fixed-point, some floating-point, with FIXED_ONLY fragment clamping and polygon smooth enabled may write incorrect values to the fixed point buffers (depends on spec interpretation)
-- For fragment programs with ARB_fog_* options, colors are clamped before fog application regardless of the fragment clamping setting (this depends on spec interpretation)
-

docs/GL3.txt

@@ -1,132 +0,0 @@
-
-Status of OpenGL 3.x features in Mesa
-
-
-Note: when an item is marked as "DONE" it means all the core Mesa
-infrastructure is complete but it may be the case that few (if any) drivers
-implement the features.
-
-
-Feature                                               Status
------------------------------------------------------ ------------------------
-
-GL 3.0:
-
-GLSL 1.30                                             DONE
-glBindFragDataLocation, glGetFragDataLocation         DONE
-Conditional rendering (GL_NV_conditional_render)      DONE (i965, r300, r600, swrast)
-Map buffer subranges (GL_ARB_map_buffer_range)        DONE (i965, r300, r600, swrast)
-Clamping controls (GL_ARB_color_buffer_float)         DONE (i965, r300, r600)
-Float textures, renderbuffers (GL_ARB_texture_float)  DONE (i965, r300, r600)
-GL_EXT_packed_float                                   DONE (i965, r600)
-GL_EXT_texture_shared_exponent                        DONE (i965, r600, swrast)
-Float depth buffers (GL_ARB_depth_buffer_float)       DONE (i965, r600)
-Framebuffer objects (GL_ARB_framebuffer_object)       DONE (i965, r300, r600, swrast)
-Half-float                                            DONE
-Non-normalized Integer texture/framebuffer formats    DONE (i965)
-1D/2D Texture arrays                                  DONE
-Per-buffer blend and masks (GL_EXT_draw_buffers2)     DONE (i965, r600, swrast)
-GL_EXT_texture_compression_rgtc                       DONE (i965, r300, r600, swrast)
-Red and red/green texture formats                     DONE (i965, swrast, gallium)
-Transform feedback (GL_EXT_transform_feedback)        DONE (i965)
-Vertex array objects (GL_APPLE_vertex_array_object)   DONE (i965, r300, r600, swrast)
-sRGB framebuffer format (GL_EXT_framebuffer_sRGB)     DONE (i965, r600)
-glClearBuffer commands                                DONE
-glGetStringi command                                  DONE
-glTexParameterI, glGetTexParameterI commands          DONE
-glVertexAttribI commands                              ~50% done (converts int
-                                                                 values to floats)
-Depth format cube textures                            DONE
-GLX_ARB_create_context (GLX 1.4 is required)          DONE
-
-
-GL 3.1:
-
-GLSL 1.40                                             missing: UBOS, inverse(),
-                                                      highp change
-Instanced drawing (GL_ARB_draw_instanced)             DONE (i965, gallium, swrast)
-Buffer copying (GL_ARB_copy_buffer)                   DONE (i965, r300, r600, swrast)
-Primitive restart (GL_NV_primitive_restart)           DONE (i965, r600)
-16 vertex texture image units                         DONE
-Texture buffer objs (GL_ARB_texture_buffer_object)    needs GL3.1 enabling (i965)
-Rectangular textures (GL_ARB_texture_rectangle)       DONE (i965, r300, r600, swrast)
-Uniform buffer objs (GL_ARB_uniform_buffer_object)    not started
-Signed normalized textures (GL_EXT_texture_snorm)     DONE (i965, r300, r600)
-
-
-GL 3.2:
-
-Core/compatibility profiles                           not started
-GLSL 1.50                                             not started
-Geometry shaders (GL_ARB_geometry_shader4)            partially done (Zack)
-BGRA vertex order (GL_ARB_vertex_array_bgra)          DONE (i965, r300, r600, swrast)
-Base vertex offset(GL_ARB_draw_elements_base_vertex)  DONE (i965, r300, r600, swrast)
-Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (i965, r300, r600, swrast)
-Provoking vertex (GL_ARB_provoking_vertex)            DONE (i965, r300, r600, swrast)
-Seamless cubemaps (GL_ARB_seamless_cube_map)          DONE (i965, r600)
-Multisample textures (GL_ARB_texture_multisample)     not started
-Frag depth clamp (GL_ARB_depth_clamp)                 DONE (i965, r600, swrast)
-Fence objects (GL_ARB_sync)                           DONE (i965, r300, r600, swrast)
-GLX_ARB_create_context_profile                        DONE
-
-
-GL 3.3:
-
-GLSL 3.30                                             new features in this version pretty much done
-GL_ARB_blend_func_extended                            DONE (i965, r600, softpipe)
-GL_ARB_explicit_attrib_location                       DONE (i915, i965, r300, r600, swrast)
-GL_ARB_occlusion_query2                               DONE (r300, r600, swrast)
-GL_ARB_sampler_objects                                DONE (i965, r300, r600)
-GL_ARB_shader_bit_encoding                            DONE
-GL_ARB_texture_rgb10_a2ui                             DONE (r600)
-GL_ARB_texture_swizzle                                DONE (same as EXT version) (i965, r300, r600, swrast)
-GL_ARB_timer_query                                    ~60% done (the EXT variant)
-GL_ARB_instanced_arrays                               DONE (r300, r600)
-GL_ARB_vertex_type_2_10_10_10_rev                     DONE (r600)
-
-
-GL 4.0:
-
-GLSL 4.0                                             not started
-GL_ARB_texture_query_lod                             not started
-GL_ARB_draw_buffers_blend                            DONE (i965, r600, softpipe)
-GL_ARB_draw_indirect                                 not started
-GL_ARB_gpu_shader_fp64                               not started
-GL_ARB_sample_shading                                not started
-GL_ARB_shader_subroutine                             not started
-GL_ARB_tessellation_shader                           not started
-GL_ARB_texture_buffer_object_rgb32                   not started
-GL_ARB_texture_cube_map_array                        not started
-GL_ARB_texture_gather                                not started
-GL_ARB_transform_feedback2                           DONE
-GL_ARB_transform_feedback3                           not started
-
-
-GL 4.1:
-
-GLSL 4.1                                             not started
-GL_ARB_ES2_compatibility                             DONE (i965, r300, r600)
-GL_ARB_get_program_binary                            not started
-GL_ARB_separate_shader_objects                       some infrastructure done
-GL_ARB_shader_precision                              not started
-GL_ARB_vertex_attrib_64bit                           not started
-GL_ARB_viewport_array                                not started
-
-
-GL 4.2:
-GLSL 4.2                                             not started
-GL_ARB_texture_compression_bptc                      not started
-GL_ARB_compressed_texture_pixel_storage              not started
-GL_ARB_shader_atomic_counters                        not started
-GL_ARB_texture_storage                               DONE (r300, r600, swrast)
-GL_ARB_transform_feedback_instanced                  not started
-GL_ARB_base_instance                                 DONE (nv50, nvc0, r600, radeonsi)
-GL_ARB_shader_image_load_store                       not started
-GL_ARB_conservative_depth                            DONE (softpipe)
-GL_ARB_shading_language_420pack                      not started
-GL_ARB_internalformat_query                          not started
-GL_ARB_map_buffer_alignment                          not started
-
-
-More info about these features and the work involved can be found at
-http://dri.freedesktop.org/wiki/MissingFunctionality

docs/INSTALL.GNU

@@ -0,0 +1,182 @@
+Basic Installation
+==================
+
+   These are generic installation instructions.
+
+   The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation.  It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions.  Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, a file
+`config.cache' that saves the results of its tests to speed up
+reconfiguring, and a file `config.log' containing compiler output
+(useful mainly for debugging `configure').
+
+   If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release.  If at some point `config.cache'
+contains results you don't want to keep, you may remove or edit it.
+
+   The file `configure.in' is used to create `configure' by a program
+called `autoconf'.  You only need `configure.in' if you want to change
+it or regenerate `configure' using a newer version of `autoconf'.
+
+The simplest way to compile this package is:
+
+  1. `cd' to the directory containing the package's source code and type
+     `./configure' to configure the package for your system.  If you're
+     using `csh' on an old version of System V, you might need to type
+     `sh ./configure' instead to prevent `csh' from trying to execute
+     `configure' itself.
+
+     Running `configure' takes awhile.  While running, it prints some
+     messages telling which features it is checking for.
+
+  2. Type `make' to compile the package.
+
+  3. Optionally, type `make check' to run any self-tests that come with
+     the package.
+
+  4. Type `make install' to install the programs and any data files and
+     documentation.
+
+  5. You can remove the program binaries and object files from the
+     source code directory by typing `make clean'.  To also remove the
+     files that `configure' created (so you can compile the package for
+     a different kind of computer), type `make distclean'.  There is
+     also a `make maintainer-clean' target, but that is intended mainly
+     for the package's developers.  If you use it, you may have to get
+     all sorts of other programs in order to regenerate files that came
+     with the distribution.
+
+Compilers and Options
+=====================
+
+   Some systems require unusual options for compilation or linking that
+the `configure' script does not know about.  You can give `configure'
+initial values for variables by setting them in the environment.  Using
+a Bourne-compatible shell, you can do that on the command line like
+this:
+     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+
+Or on systems that have the `env' program, you can do it like this:
+     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+
+Compiling For Multiple Architectures
+====================================
+
+   You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory.  To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'.  `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script.  `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+   If you have to use a `make' that does not supports the `VPATH'
+variable, you have to compile the package for one architecture at a time
+in the source code directory.  After you have installed the package for
+one architecture, use `make distclean' before reconfiguring for another
+architecture.
+
+Installation Names
+==================
+
+   By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc.  You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PATH'.
+
+   You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files.  If you
+give `configure' the option `--exec-prefix=PATH', the package will use
+PATH as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+   In addition, if you use an unusual directory layout you can give
+options like `--bindir=PATH' to specify different values for particular
+kinds of files.  Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+   If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+   Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System).  The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+   For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+   There may be some features `configure' can not figure out
+automatically, but needs to determine by the type of host the package
+will run on.  Usually `configure' can figure that out, but if it prints
+a message saying it can not guess the host type, give it the
+`--host=TYPE' option.  TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name with three fields:
+     CPU-COMPANY-SYSTEM
+
+See the file `config.sub' for the possible values of each field.  If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the host type.
+
+   If you are building compiler tools for cross-compiling, you can also
+use the `--target=TYPE' option to select the type of system they will
+produce code for and the `--build=TYPE' option to select the type of
+system on which you are compiling the package.
+
+Sharing Defaults
+================
+
+   If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists.  Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Operation Controls
+==================
+
+   `configure' recognizes the following options to control how it
+operates.
+
+`--cache-file=FILE'
+     Use and save the results of the tests in FILE instead of
+     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
+     debugging `configure'.
+
+`--help'
+     Print a summary of the options to `configure', and exit.
+
+`--quiet'
+`--silent'
+`-q'
+     Do not print messages saying which checks are being made.  To
+     suppress all normal output, redirect it to `/dev/null' (any error
+     messages will still be shown).
+
+`--srcdir=DIR'
+     Look for the package's source code in directory DIR.  Usually
+     `configure' can determine that directory automatically.
+
+`--version'
+     Print the version of Autoconf used to generate the `configure'
+     script, and exit.
+
+`configure' also accepts some other, not widely useful, options.

docs/MESA_agp_offset.spec

@@ -1,95 +0,0 @@
-Name
-
-    MESA_agp_offset
-
-Name Strings
-
-    GLX_MESA_agp_offset
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Shipping (Mesa 4.0.4 and later.  Only implemented in particular
-    XFree86/DRI drivers.)
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    GLX_NV_vertex_array_range is required.
-    This extensions is written against the OpenGL 1.4 Specification.
-
-Overview
-
-    This extensions provides a way to convert pointers in an AGP memory
-    region into byte offsets into the AGP aperture.
-    Note, this extension depends on GLX_NV_vertex_array_range, for which
-    no real specification exists.  See GL_NV_vertex_array_range for more
-    information.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    unsigned int glXGetAGPOffsetMESA( const void *pointer )
-
-New Tokens
-
-    None
-
-Additions to the OpenGL 1.4 Specification
-
-    None
-
-Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
-
-    Add a new section, 3.6 as follows:
-
-    3.6 AGP Memory Access
-
-    On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV
-    and freed with glXFreeMemoryNV.  Sometimes it's useful to know where a
-    block of AGP memory is located with respect to the start of the AGP
-    aperture.  The function
-
-        GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
-
-    Returns the offset of the given memory block from the start of AGP
-    memory in basic machine units (i.e. bytes).  If pointer is invalid
-    the value ~0 will be returned.
-
-GLX Protocol
-
-    None.  This is a client side-only extension.
-
-Errors
-
-    glXGetAGPOffsetMESA will return ~0 if the pointer does not point to
-    an AGP memory region.
-
-New State
-
-    None
-
-Revision History
-
-    20 September 2002 - Initial draft
-    2 October 2002 - finished GLX chapter 3 additions
-    27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid

docs/MESA_copy_sub_buffer.spec

@@ -1,96 +0,0 @@
-Name
-
-    MESA_copy_sub_buffer
-
-Name Strings
-
-    GLX_MESA_copy_sub_buffer
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 2.6 in February, 1998.
-
-Version
-
-    Last Modified Date:  12 January 2009
-
-Number
-
-    215
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    The glxCopySubBufferMESA() function copies a rectangular region
-    of the back color buffer to the front color buffer.  This can be
-    used to quickly repaint 3D windows in response to expose events
-    when the back color buffer cannot be damaged by other windows.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
-			       int x, int y, int width, int height );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Add to section 3.3.10 Double Buffering:
-
-    The function
-
-	 void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
-				    int x, int y, int width, int height );
-
-    may be used to copy a rectangular region of the back color buffer to
-    the front color buffer.  This can be used to quickly repaint 3D windows
-    in response to expose events when the back color buffer cannot be
-    damaged by other windows.
-
-    <x> and <y> indicates the lower-left corner of the region to copy and
-    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
-    corresponds to the lower-left pixel of the window, like glReadPixels.
-
-    If dpy and drawable are the display and drawable for the calling
-    thread's current context, glXCopySubBufferMESA performs an
-    implicit glFlush before it returns.  Subsequent OpenGL commands
-    may be issued immediately after calling glXCopySubBufferMESA, but
-    are not executed until the copy is completed. 
-
-GLX Protocol
-
-    None at this time.  The extension is implemented in terms of ordinary
-    Xlib protocol inside of Mesa.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    12 January 2009 Ian Romanick - Added language about implicit flush
-                                   and command completion.
-    8 June 2000     Brian Paul   - initial specification
-

docs/MESA_drm_image.spec

@@ -1,153 +0,0 @@
-Name
-
-    MESA_drm_image
-
-Name Strings
-
-    EGL_MESA_drm_image
-
-Contact
-
-    Kristian Høgsberg <krh@bitplanet.net>
-
-Status
-
-    Proposal
-
-Version
-
-    Version 2, August 25, 2010
-
-Number
-
-    EGL Extension #not assigned
-
-Dependencies
-
-    Requires EGL 1.4 or later.  This extension is written against the
-    wording of the EGL 1.4 specification.
-
-    EGL_KHR_base_image is required.
-
-Overview
-
-    This extension provides entry points for integrating EGLImage with the
-    Linux DRM mode setting and memory management drivers.  The extension
-    lets applications create EGLImages without a client API resource and
-    lets the application get the DRM buffer handles.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
-                                      const EGLint *attrib_list);
-
-    EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
-                                     EGLImageKHR image,
-                                     EGLint *name,
-				     EGLint *handle,
-				     EGLint *stride);
-
-New Tokens
-
-    Accepted in the <attrib_list> parameter of eglCreateDRMImageMESA:
-
-        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
-        EGL_DRM_BUFFER_USE_MESA			0x31D1
-
-    Accepted as values for the EGL_IMAGE_FORMAT_MESA attribute:
-
-        EGL_DRM_BUFFER_FORMAT_ARGB32_MESA	0x31D2
-
-    Bits accepted in EGL_DRM_BUFFER_USE_MESA:
-
-        EGL_DRM_BUFFER_USE_SCANOUT_MESA		0x0001
-        EGL_DRM_BUFFER_USE_SHARE_MESA		0x0002
-        EGL_DRM_BUFFER_USE_CURSOR_MESA		0x0004
-
-    Accepted in the <target> parameter of eglCreateImageKHR:
-
-        EGL_DRM_BUFFER_MESA			0x31D3
-
-    Use when importing drm buffer:
-
-        EGL_DRM_BUFFER_STRIDE_MESA		0x31D4
-        EGL_DRM_BUFFER_FORMAT_MESA		0x31D0
-
-Additions to the EGL 1.4 Specification:
-
-    To create a DRM EGLImage, call
-
-        EGLImageKHR eglCreateDRMImageMESA(EGLDisplay dpy,
-                                          const EGLint *attrib_list);
-
-    In the attribute list, pass EGL_WIDTH, EGL_HEIGHT and format and
-    use in the attrib list using EGL_DRM_BUFFER_FORMAT_MESA and
-    EGL_DRM_BUFFER_USE_MESA.  The only format specified by this
-    extension is EGL_DRM_BUFFER_FORMAT_ARGB32_MESA, where each pixel
-    is a CPU-endian, 32-bit quantity, with alpha in the upper 8 bits,
-    then red, then green, then blue.  The bit values accepted by
-    EGL_DRM_BUFFER_USE_MESA are EGL_DRM_BUFFER_USE_SCANOUT_MESA,
-    EGL_DRM_BUFFER_USE_SHARE_MESA and EGL_DRM_BUFFER_USE_CURSOR_MESA.
-    EGL_DRM_BUFFER_USE_SCANOUT_MESA requests that the created EGLImage
-    should be usable as a scanout buffer with the DRM kernel
-    modesetting API.  EGL_DRM_BUFFER_USE_SHARE_MESA requests that the
-    EGLImage can be shared with other processes by passing the
-    underlying DRM buffer name.  EGL_DRM_BUFFER_USE_CURSOR_MESA
-    requests that the image must be usable as a cursor with KMS.  When
-    EGL_DRM_BUFFER_USE_CURSOR_MESA is set, width and height must both
-    be 64.
-
-    To create a process local handle or a global DRM name for a
-    buffer, call
-
-        EGLBoolean eglExportDRMImageMESA(EGLDisplay dpy,
-                                         EGLImageKHR image,
-                                         EGLint *name,
-                                         EGLint *handle,
-                                         EGLint *stride);
-
-    If <name> is non-NULL, a global name is assigned to the image and
-    written to <name>, the handle (local to the DRM file descriptor,
-    for use with DRM kernel modesetting API) is written to <handle> if
-    non-NULL and the stride (in bytes) is written to <stride>, if
-    non-NULL.
-
-    Import a shared buffer by calling eglCreateImageKHR with
-    EGL_DRM_BUFFER_MESA as the target, using EGL_WIDTH, EGL_HEIGHT,
-    EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_STRIDE_MESA
-    in the attrib list.
-
-Issues
-
-    1.  Why don't we use eglCreateImageKHR with a target that
-        indicates that we want to create an EGLImage from scratch?
-
-        RESOLVED: The eglCreateImageKHR entry point is reserved for
-        creating an EGLImage from an already existing client API
-        resource.  This is fine when we're creating the EGLImage from
-        an existing DRM buffer name, it doesn't seem right to overload
-        the function to also allocate the underlying resource.
-
-    2.  Why don't we use an eglQueryImageMESA type functions for
-        querying the DRM EGLImage attributes (name, handle, and stride)?
-
-        RESOLVED: The eglQueryImage function has been proposed often,
-        but it goes against the EGLImage design.  EGLImages are opaque
-        handles to a 2D array of pixels, which can be passed between
-        client APIs.  By referencing an EGLImage in a client API, the
-        EGLImage target (a texture, a renderbuffer or such) can be
-        used to query the attributes of the EGLImage.  We don't have a
-        full client API for creating and querying DRM buffers, though,
-        so we use a new EGL extension entry point instead.
-
-Revision History
-
-    Version 1, June 3, 2010
-        Initial draft (Kristian Høgsberg)
-    Version 2, August 25, 2010
-        Flesh out the extension a bit, add final EGL tokens, capture
-        some of the original discussion in the issues section.

docs/MESA_multithread_makecurrent.spec

@@ -1,158 +0,0 @@
-Name
-
-    MESA_multithread_makecurrent
-
-Name Strings
-
-    GLX_MESA_multithread_makecurrent
-
-Contact
-
-    Eric Anholt (eric@anholt.net)
-
-Status
-
-    Not shipping.
-
-Version
-
-    Last Modified Date:  21 February 2011
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.3 or later is required.
-
-Overview
-
-    The GLX context setup encourages multithreaded applications to
-    create a context per thread which each operate on their own
-    objects in parallel, and leaves synchronization for write access
-    to shared objects up to the application.
-
-    For some applications, maintaining per-thread contexts and
-    ensuring that the glFlush happens in one thread before another
-    thread starts working on that object is difficult.  For them,
-    using the same context across multiple threads and protecting its
-    usage with a mutex is both higher performance and easier to
-    implement.  This extension gives those applications that option by
-    relaxing the context binding requirements.
-
-    This new behavior matches the requirements of AGL, while providing
-    a feature not specified in WGL.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-
-    None.
-
-Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
-
-    Replace the following sentence from section 2.2 Rendering Contexts:
-	In addition, a rendering context can be current for only one
-	thread at a time.
-    with:
-	In addition, an indirect rendering context can be current for
-	only one thread at a time.  A direct rendering context may be
-	current to multiple threads, with synchronization of access to
-	the context thruogh the GL managed by the application through
-	mutexes.
-
-Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Replace the following sentence from section 3.3.7 Rendering Contexts:
-	If ctx is current to some other thread, then
-	glXMakeContextCurrent will generate a BadAccess error.
-    with:
-	If ctx is an indirect context current to some other thread,
-	then glXMakeContextCurrent will generate a BadAccess error.
-
-    Replace the following sentence from section 3.5 Rendering Contexts:
-	If ctx is current to some other thread, then
-	glXMakeCurrent will generate a BadAccess error.
-    with:
-	If ctx is an indirect context current to some other thread,
-	then glXMakeCurrent will generate a BadAccess error.
-
-GLX Protocol
-
-    None.  The GLX extension only extends to direct rendering contexts.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Issues
-
-    (1) What happens if the app binds a context/drawable in multiple
-	threads, then binds a different context/thread in one of them?
-
-    As with binding a new context from the current thread, the old
-    context's refcount is reduced and the new context's refcount is
-    increased.
-
-    (2) What happens if the app binds a context/drawable in multiple
-	threads, then binds None/None in one of them?
-
-    The GLX context is unreferenced from that thread, and the other
-    threads retain their GLX context binding.
-
-    (3) What happens if the app binds a context/drawable in 7 threads,
-	then destroys the context in one of them?
-
-    As with GLX context destruction previously, the XID is destroyed
-    but the context remains usable by threads that have the context
-    current.
-
-    (4) What happens if the app binds a new drawable/readable with
-        glXMakeCurrent() when it is already bound to another thread?
-
-    The context becomes bound to the new drawable/readable, and
-    further rendering in either thread will use the new
-    drawable/readable.
-
-    (5) What requirements should be placed on the user managing contexts
-        from multiple threads?
-
-    The intention is to allow multithreaded access to the GL at the
-    minimal performance cost, so requiring that the GL do general
-    synchronization (beyond that already required by context sharing)
-    is not an option, and synchronizing of GL's access to the GL
-    context between multiple threads is left to the application to do
-    across GL calls.  However, it would be unfortunate for a library
-    doing multithread_makecurrent to require that other libraries
-    share in synchronization for binding of their own contexts, so the
-    refcounting of the contexts is required to be threadsafe.
-
-    (6) Does this apply to indirect contexts?
-
-    This was ignored in the initial revision of the spec.  Behavior
-    for indirect contexts is left as-is.
-
-Revision History
-
-    20 November 2009 Eric Anholt - initial specification
-    22 November 2009 Eric Anholt - added issues from Ian Romanick.
-    3 February 2011 Eric Anholt - updated with resolution to issues 1-3
-    3 February 2011 Eric Anholt - added issue 4, 5
-    21 February 2011 Eric Anholt - Include glXMakeCurrent() sentence
-    along with glXMakeContextCurrent() for removal.

docs/MESA_pack_invert.spec

@@ -1,138 +0,0 @@
-Name
-
-    MESA_pack_invert
-
-Name Strings
-
-    GL_MESA_pack_invert
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Shipping (Mesa 4.0.4 and later)
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    This extensions is written against the OpenGL 1.4 Specification.
-
-Overview
-
-    This extension adds a new pixel storage parameter to indicate that
-    images are to be packed in top-to-bottom order instead of OpenGL's
-    conventional bottom-to-top order.  Only pixel packing can be
-    inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter,
-    etc).
-
-    Almost all known image file formats store images in top-to-bottom
-    order.  As it is, OpenGL reads images from the frame buffer in
-    bottom-to-top order.  Thus, images usually have to be inverted before
-    writing them to a file with image I/O libraries.  This extension
-    allows images to be read such that inverting isn't needed.
-
-IP Status
-
-    None
-
-Issues
-
-    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
-
-    Resolved:  No, we're only concerned with pixel packing.  There are other
-    solutions for inverting images when using glDrawPixels (negative Y pixel
-    zoom) or glTexImage (invert the vertex T coordinates).  It would be easy
-    enough to define a complementary extension for pixel packing in the
-    future if needed.
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    Accepted by the <pname> parameter of PixelStorei and PixelStoref
-    and the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev
-    and GetBooleanv:
-
-        PACK_INVERT_MESA                   0x8758
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    Add the following entry to table 4.4 (PixelStore parameters) on page 182:
-
-    Parameter Name       Type    Initial Value    Valid Range
-    ---------------------------------------------------------
-    PACK_INVERT_MESA     boolean     FALSE        TRUE/FALSE
-
-    In the section labeled "Placement in Client Memory" on page 184
-    insert the following text into the paragraph before the sentence
-    that starts with "If the format is RED, GREEN, BLUE...":
-
-    "The parameter PACK_INVERT_MESA controls whether the image is packed
-     in bottom-to-top order (the default) or top-to-bottom order.  Equation
-     3.8 is modified as follows:
-
-     ... the first element of the Nth row is indicated by
-
-         p + Nk,                if PACK_INVERT_MESA is false
-         p + k * (H - 1) - Nk,  if PACK_INVERT_MESA is true, where H is the
-                                image height
-    "
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    None
-
-New State
-
-    Add the following entry to table 6.20 (Pixels) on page 235:
-
-    Get Value         Type     Get Cmd    Initial Value  Description                Sec    Attribute
-    --------------------------------------------------------------------------------------------------
-    PACK_INVERT_MESA  boolean  GetBoolean  FALSE         Value of PACK_INVERT_MESA  4.3.2  pixel-store
-
-Revision History
-
-    21 September 2002 - Initial draft

docs/MESA_pixmap_colormap.spec

@@ -1,90 +0,0 @@
-Name
-
-    MESA_pixmap_colormap
-
-Name Strings
-
-    GLX_MESA_pixmap_colormap
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 1.2.8 in May, 1996.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    216
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    Since Mesa allows RGB rendering into drawables with PseudoColor,
-    StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap
-    in order to compute pixel values during rendering.
-
-    The colormap associated with a window can be queried with normal
-    Xlib functions but there is no colormap associated with pixmaps.
-
-    The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap
-    which allows specification of a colormap.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-				      Pixmap pixmap, Colormap cmap );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    Add to section 3.4.2 Off Screen Rendering
-
-    The Mesa implementation of GLX allows RGB rendering into X windows and
-    pixmaps of any visual class, not just TrueColor or DirectColor.  In order
-    to compute pixel values from RGB values Mesa requires a colormap.
-
-    The function
-
-	GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-					  Pixmap pixmap, Colormap cmap );
-
-    allows one to create a GLXPixmap with a specific colormap.  The image
-    rendered into the pixmap may then be copied to a window (which uses the
-    same colormap and visual) with the expected results.
-
-GLX Protocol
-
-    None since this is a client-side extension.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification

docs/MESA_release_buffers.spec

@@ -1,85 +0,0 @@
-Name
-
-    MESA_release_buffers
-
-Name Strings
-
-    GLX_MESA_release_buffers
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 2.0 in October, 1996.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    217
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    Mesa's implementation of GLX is entirely implemented on the client side.
-    Therefore, Mesa cannot immediately detect when an X window or pixmap is
-    destroyed in order to free any ancillary data associated with the window
-    or pixmap.
-
-    The glxMesaReleaseBuffers() function can be used to explicitly indicate
-    when the back color buffer, depth buffer, stencil buffer, and/or accumu-
-    lation buffer associated with a drawable can be freed.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
-
-New Tokens
-
-    None.
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    The function
-
-	Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
-
-    causes all software ancillary buffers (back buffer, depth, stencil,
-    accum, etc) associated with the named drawable to be immediately
-    deallocated.  True is returned if <d> is a valid Mesa GLX drawable,
-    else False is returned.  After calling glXReleaseBuffersMESA, the
-    drawable should no longer be used for GL rendering.  Results of
-    attempting to do so are undefined.
-
-
-GLX Protocol
-
-    None, since this is a client-side operation.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification

docs/MESA_resize_buffers.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, brianp 'at' mesa3d.org
 
 Status
 
@@ -16,10 +16,11 @@ Status
 
 Version
 
+    $Id: MESA_resize_buffers.spec,v 1.1 1999/07/20 00:30:41 brianp Exp $
 
 Number
 
-    196
+    XXX none assigned
 
 Dependencies
 
@@ -35,7 +36,7 @@ Overview
 
     Mesa's glViewport command queries the current window size and updates
     its internal data structors accordingly.  This normally works fine
-    since most applications call glViewport in response to window size
+    since most applications call glViewport in responce to window size
     changes.
 
     In some situations, however, the application may not call glViewport
@@ -65,7 +66,7 @@ Additions to the AGL/GLX/WGL Specifications
 
 Errors
 
-    INVALID_OPERATION is generated if glResizeBuffersMESA is called between
+    INVALID_OPERATION is generated if ResizeBuffersMESA is called betweeen
     Begin and End.
 
 New State

docs/MESA_set_3dfx_mode.spec

@@ -1,85 +0,0 @@
-Name
-
-    MESA_set_3dfx_mode
-
-Name Strings
-
-    GLX_MESA_set_3dfx_mode
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    Shipping since Mesa 2.6 in February, 1998.
-
-Version
-
-    Last Modified Date:  8 June 2000
-
-Number
-
-    218
-
-Dependencies
-
-    OpenGL 1.0 or later is required.
-    GLX 1.0 or later is required.
-
-Overview
-
-    The Mesa Glide driver allows full-screen rendering or rendering into
-    an X window.  The glXSet3DfxModeMESA() function allows an application
-    to switch between full-screen and windowed rendering.
-
-IP Status
-
-    Open-source; freely implementable.
-
-Issues
-
-    None.
-
-New Procedures and Functions
-
-    GLboolean glXSet3DfxModeMESA( GLint mode );
-
-New Tokens
-
-    GLX_3DFX_WINDOW_MODE_MESA	    0x1
-    GLX_3DFX_FULLSCREEN_MODE_MESA   0x2
-
-Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
-
-    The Mesa Glide device driver allows either rendering in full-screen
-    mode or rendering into an X window.  An application can switch between
-    full-screen and window rendering with the command:
-
-	GLboolean glXSet3DfxModeMESA( GLint mode );
-
-    <mode> may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window
-    rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode.
-
-    GL_TRUE is returned if <mode> is valid and the operation completed
-    normally.  GL_FALSE is returned if <mode> is invalid or if the Glide
-    driver is not being used.
-
-    Note that only one drawable and context can be created at any given
-    time with the Mesa Glide driver.
-
-GLX Protocol
-
-    None since this is a client-side extension.
-
-Errors
-
-    None.
-
-New State
-
-    None.
-
-Revision History
-
-    8 June 2000 - initial specification

docs/MESA_shader_debug.spec

@@ -1,264 +0,0 @@
-Name
-
-    MESA_shader_debug
-
-Name Strings
-
-    GL_MESA_shader_debug
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-    Michal Krol (mjkrol 'at' gmail.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-    Last Modified Date: July 30, 2006
-    Author Revision: 0.2
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 is required.
-
-    The ARB_shader_objects extension is required.
-
-    The ARB_shading_language_100 extension is required.
-
-    The extension is written against the OpenGL 1.5 specification.
-
-    The extension is written against the OpenGL Shading Language 1.10
-    Specification.
-
-Overview
-
-    This extension introduces a debug object that can be attached to
-    a program object to enable debugging. Vertex and/or fragment shader,
-    during execution, issue diagnostic function calls that are logged
-    to the debug object's log. A separate debug log for each shader type
-    is maintained. A debug object can be attached, detached and queried
-    at any time outside the Begin/End pair. Multiple debug objects can
-    be attached to a single program object.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    handleARB CreateDebugObjectMESA(void)
-    void ClearDebugLogMESA(handleARB obj, enum logType, enum shaderType)
-    void GetDebugLogMESA(handleARB obj, enum logType, enum shaderType,
-                         sizei maxLength, sizei *length,
-                         charARB *debugLog)
-    sizei GetDebugLogLengthMESA(handleARB obj, enum logType,
-                                enum shaderType)
-
-New Types
-
-    None
-
-New Tokens
-
-    Returned by the <params> parameter of GetObjectParameter{fi}vARB:
-
-        DEBUG_OBJECT_MESA                               0x8759
-
-    Accepted by the <logType> argument of ClearDebugLogMESA,
-    GetDebugLogLengthMESA and GetDebugLogMESA:
-
-        DEBUG_PRINT_MESA                                0x875A
-        DEBUG_ASSERT_MESA                               0x875B
-
-Additions to Chapter 2 of the OpenGL 1.5 Specification
-(OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None
-
-Additions to Chapter 5 of the OpenGL 1.5 Specification
-(Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State
-Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
-
-    None
-
-Additions to Chapter 1 of the OpenGL Shading Language 1.10 Specification
-(Introduction)
-
-    None
-
-Additions to Chapter 2 of the OpenGL Shading Language 1.10 Specification
-(Overview of OpenGL Shading)
-
-    None
-
-Additions to Chapter 3 of the OpenGL Shading Language 1.10 Specification
-(Basics)
-
-    None
-
-Additions to Chapter 4 of the OpenGL Shading Language 1.10 Specification
-(Variables and Types)
-
-    None
-
-Additions to Chapter 5 of the OpenGL Shading Language 1.10 Specification
-(Operators and Expressions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL Shading Language 1.10 Specification
-(Statements and Structure)
-
-    None
-
-Additions to Chapter 7 of the OpenGL Shading Language 1.10 Specification
-(Built-in Variables)
-
-    None
-
-Additions to Chapter 8 of the OpenGL Shading Language 1.10 Specification
-(Built-in Functions)
-
-    Add a new section 8.10 "Debug Functions":
-
-    Debug functions are available to both fragment and vertex shaders.
-    They are used to track the execution of a shader by logging
-    passed-in arguments to the debug object's log. Those values can be
-    retrieved by the application for inspection after shader execution
-    is complete.
-
-    The text, if any, produced by any of these functions is appended
-    to each debug object that is attached to the program object.
-    There are different debug log types
-
-    Add a new section 8.10.1 "Print Function":
-
-    The following printMESA prototypes are available.
-
-        void printMESA(const float value)
-        void printMESA(const int value)
-        void printMESA(const bool value)
-        void printMESA(const vec2 value)
-        void printMESA(const vec3 value)
-        void printMESA(const vec4 value)
-        void printMESA(const ivec2 value)
-        void printMESA(const ivec3 value)
-        void printMESA(const ivec4 value)
-        void printMESA(const bvec2 value)
-        void printMESA(const bvec3 value)
-        void printMESA(const bvec4 value)
-        void printMESA(const mat2 value)
-        void printMESA(const mat3 value)
-        void printMESA(const mat4 value)
-        void printMESA(const sampler1D value)
-        void printMESA(const sampler2D value)
-        void printMESA(const sampler3D value)
-        void printMESA(const samplerCube value)
-        void printMESA(const sampler1DShadow value)
-        void printMESA(const sampler2DShadow value)
-
-    The printMESA function writes the argument <value> to the "debug
-    print log" (XXX DEBUG_PRINT_MESA?). Each component is written in
-    text format (XXX format!) and is delimited by a white space (XXX 1
-    or more?).
-
-    Add a new section 8.10.2 "Assert Function":
-
-    The following assertMESA prototypes are available.
-
-        void assertMESA(const bool condition)
-        void assertMESA(const bool condition, const int cookie)
-        void assertMESA(const bool condition, const int cookie,
-                        const int file, const int line)
-
-    The assertMESA function checks if the argument <condition> is
-    true or false. If it is true, nothing happens. If it is false,
-    a diagnostic message is written to the "debug assert log".
-    The message contains the argument <file>, <line>, <cookie> and
-    implementation dependent double-quoted string, each of this
-    delimited by a white space. If the argument <cookie> is not present,
-    it is meant as if it was of value 0. If the arguments <file> and
-    <line> are not present, they are meant as if they were of values
-    __FILE__ and __LINE__, respectively. The following three calls
-    produce the same output, assuming they were issued from the same
-    file and line.
-
-        assertMESA (false);
-        assertMESA (false, 0);
-        assertMESA (false, 0, __FILE__, __LINE__);
-
-    The diagnostic message examples follow.
-
-        1 89 0 ""
-        1 45 333 "all (lessThanEqual (fragColor, vec4 (1.0)))"
-        1 66 1 "assertion failed in file 1, line 66, cookie 1"
-
-Additions to Chapter 9 of the OpenGL Shading Language 1.10 Specification
-(Shading Language Grammar)
-
-    None
-
-Additions to Chapter 10 of the OpenGL Shading Language 1.10
-Specification (Issues)
-
-    None
-
-Additions to the AGL/EGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    TBD
-
-New State
-
-    TBD
-
-New Implementation Dependent State
-
-    TBD
-
-Sample Code
-
-    TBD
-
-Revision History
-
-    29 May 2006
-        Initial draft. (Michal Krol)
-    30 July 2006
-        Add Overview, New Procedures and Functions, New Tokens sections.
-        Add sections 8.10.1, 8.10.2 to GLSL spec.

docs/MESA_swap_control.spec

@@ -1,129 +0,0 @@
-Name
-
-    MESA_swap_control
-
-Name Strings
-
-    GLX_MESA_swap_control
-
-Contact
-
-    Ian Romanick, IBM, idr at us.ibm.com
-
-Status
-
-    Deployed in DRI drivers post-XFree86 4.3.
-
-Version
-
-    Date: 5/1/2003   Revision: 1.1
-
-Number
-
-    ???
-
-Dependencies
-
-    None
-
-    Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control
-    version 1.5.
-
-Overview
-
-    This extension allows an application to specify a minimum periodicity
-    of color buffer swaps, measured in video frame periods.
-
-Issues
-
-    * Should implementations that export GLX_MESA_swap_control also export
-      GL_EXT_swap_control for compatibility with WGL_EXT_swap_control?
-
-    UNRESOLVED.
-
-New Procedures and Functions
-
-    int glXSwapIntervalMESA(unsigned int interval)
-    int glXGetSwapIntervalMESA(void)
-
-New Tokens
-
-    None
-
-Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
-and the Framebuffer)
-
-    None
-
-Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
-
-    None
-
-Additions to the GLX 1.3 Specification
-
-    [Add the following to Section 3.3.10 of the GLX Specification (Double
-     Buffering)]
-
-    glXSwapIntervalMESA specifies the minimum number of video frame periods
-    per buffer swap.  (e.g. a value of two means that the color buffers
-    will be swapped at most every other video frame.)  A return value
-    of zero indicates success; otherwise an error occurred.  The interval
-    takes effect when glXSwapBuffers is first called subsequent to the
-    glXSwapIntervalMESA call.
-
-    A video frame period is the time required by the monitor to display a 
-    full frame of video data.  In the case of an interlaced monitor,
-    this is typically the time required to display both the even and odd 
-    fields of a frame of video data.
-
-    If <interval> is set to a value of 0, buffer swaps are not synchro-
-    nized to a video frame.  The <interval> value is silently clamped to
-    the maximum implementation-dependent value supported before being
-    stored.
-
-    The swap interval is not part of the render context state.  It cannot
-    be pushed or popped.  The current swap interval for the window
-    associated with the current context can be obtained by calling
-    glXGetSwapIntervalMESA.  The default swap interval is 0.
-
-    On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets
-    the swap interval to 1.
-
-Errors
-
-    glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
-    GLXContext or if the current context is not a direct rendering context.
-
-GLX Protocol
-
-    None.  This extension only extends to direct rendering contexts.
-
-New State
-
-    Get Value		Get Command	Type	    Initial Value
-    ---------		-----------	----	    -------------
-    [swap interval]	GetSwapInterval	Z+	    0
-
-New Implementation Dependent State
-
-    None
-
-
-Revision History
-
-    1.1,  5/1/03   Added the issues section and contact information.
-    	  	   Changed the default swap interval to 0.
-    1.0,  3/17/03  Initial version based on GLX_SGI_swap_control and
-                   WGL_EXT_swap_control.

docs/MESA_swap_frame_usage.spec

@@ -1,201 +0,0 @@
-Name
-
-    MESA_swap_frame_usage
-
-Name Strings
-
-    GLX_MESA_swap_frame_usage
-
-Contact
-
-    Ian Romanick, IBM, idr at us.ibm.com
-
-Status
-
-    Deployed in DRI drivers post-XFree86 4.3.
-
-Version
-
-    Date: 5/1/2003   Revision: 1.1
-
-Number
-
-    ???
-
-Dependencies
-
-    GLX_SGI_swap_control affects the definition of this extension.
-    GLX_MESA_swap_control affects the definition of this extension.
-    GLX_OML_sync_control affects the definition of this extension.
-
-    Based on WGL_I3D_swap_frame_usage version 1.3.
-
-Overview
-
-    This extension allows an application to determine what portion of the
-    swap period has elapsed since the last swap operation completed.  The
-    "usage" value is a floating point value on the range [0,max] which is
-    calculated as follows:
-
-                              td
-                   percent = ----
-                              tf
-
-    where td is the time measured from the last completed buffer swap (or
-    call to enable the statistic) to when the next buffer swap completes, tf
-    is the entire time for a frame which may be multiple screen refreshes
-    depending on the swap interval as set by the GLX_SGI_swap_control or
-    GLX_OML_sync_control extensions. 
-
-    The value, percent, indicates the amount of time spent between the
-    completion of the two swaps.  If the value is in the range [0,1], the
-    buffer swap occurred within the time period required to maintain a
-    constant frame rate.  If the value is in the range (1,max], a constant
-    frame rate was not achieved.  The value indicates the number of frames
-    required to draw.
-
-    This definition of "percent" differs slightly from
-    WGL_I3D_swap_frame_usage.  In WGL_I3D_swap_frame_usage, the measurement
-    is taken from the completion of one swap to the issuance of the next.
-    This representation may not be as useful as measuring between
-    completions, as a significant amount of time may pass between the
-    issuance of a swap and the swap actually occurring.
-
-    There is also a mechanism to determine whether a frame swap was
-    missed.
-
-New Procedures and Functions
-
-    int glXGetFrameUsageMESA(Display *dpy,
-                             GLXDrawable drawable,
-    	                     float *usage)
-
-    int glXBeginFrameTrackingMESA(Display *dpy,
-                                  GLXDrawable drawable)
-
-    int glXEndFrameTrackingMESA(Display *dpy,
-                                GLXDrawable drawable)
-
-    int glXQueryFrameTrackingMESA(Display *dpy,
-                                  GLXDrawable drawable,
-				  int64_t *swapCount,
-                                  int64_t *missedFrames,
-                                  float *lastMissedUsage)
-
-New Tokens
-
-    None
-
-Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.4 GL Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations
-and the Framebuffer)
-
-    None
-
-Additions to Chapter 5 of the 1.4 GL Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
-
-    None
-
-Additions to the GLX 1.3 Specification
-
-    The frame usage is measured as the percentage of the swap period elapsed
-    between two buffer-swap operations being committed.  In unextended GLX the
-    swap period is the vertical refresh time.  If SGI_swap_control or
-    MESA_swap_control are supported, the swap period is the vertical refresh
-    time multiplied by the swap interval (or one if the swap interval is set
-    to zero).
-    
-    If OML_sync_control is supported, the swap period is the vertical
-    refresh time multiplied by the divisor parameter to
-    glXSwapBuffersMscOML.  The frame usage in this case is less than 1.0 if
-    the swap is committed before target_msc, and is greater than or equal to
-    1.0 otherwise.  The actual usage value is based on the divisor and is
-    never less than 0.0.
-
-       int glXBeginFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable,
-				     float *usage)
-
-    glXGetFrameUsageMESA returns a floating-point value in <usage>
-    that represents the current swap usage, as defined above.
-
-    Missed frame swaps can be tracked by calling the following function:
-
-       int glXBeginFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable)
-
-    glXBeginFrameTrackingMESA resets a "missed frame" count and
-    synchronizes with the next frame vertical sync before it returns.
-    If a swap is missed based in the rate control specified by the
-    <interval> set by glXSwapIntervalSGI or the default swap of once
-    per frame, the missed frame count is incremented.
-
-    The current missed frame count and total number of swaps since
-    the last call to glXBeginFrameTrackingMESA can be obtained by
-    calling the following function:
-
-       int glXQueryFrameTrackingMESA(Display *dpy,
-                                     GLXDrawable drawable,
-				     int64_t *swapCount,
-                                     int64_t *missedFrames,
-                                     float *lastMissedUsage)
-
-    The location pointed to by <swapCount> will be updated with the
-    number of swaps that have been committed.  This value may not match the
-    number of swaps that have been requested since swaps may be
-    queued by the implementation.  This function can be called at any
-    time and does not synchronize to vertical blank.
-
-    The location pointed to by <missedFrames> will contain the number
-    swaps that missed the specified frame.  The frame usage for the
-    last missed frame is returned in the location pointed to by
-    <lastMissedUsage>.
-
-    Frame tracking is disabled by calling the function
-
-       int glXEndFrameTrackingMESA(Display *dpy,
-                                   GLXDrawable drawable)
-
-    This function will not return until all swaps have occurred.  The
-    application can call glXQueryFrameTrackingMESA for a final swap and
-    missed frame count.
-
-    If these functions are successful, zero is returned.  If the context
-    associated with dpy and drawable is not a direct context,
-    GLX_BAD_CONTEXT is returned.
-
-Errors
-
-    If the function succeeds, zero is returned.  If the function
-    fails, one of the following error codes is returned:
-
-       GLX_BAD_CONTEXT         The current rendering context is not a direct
-       			       context.
-
-GLX Protocol
-
-    None.  This extension only extends to direct rendering contexts.
-
-New State
-
-    None
-
-New Implementation Dependent State
-
-    None
-
-Revision History
-
-    1.1,  5/1/03   Added contact information.
-    1.0,  3/17/03  Initial version based on WGL_I3D_swap_frame_usage.

docs/MESA_texture_array.spec

@@ -1,804 +0,0 @@
-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
-
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.2 or GL_EXT_texture3D is required.
-
-    Support for ARB_fragment_program is assumed, but not required.
-
-    Support for ARB_fragment_program_shadow is assumed, but not required.
-
-    Support for EXT_framebuffer_object is assumed, but not required.
-
-    Written based on the wording of the OpenGL 2.0 specification and
-    ARB_fragment_program_shadow but not dependent on them.
-
-Overview
-
-    There are a number of circumstances where an application may wish to
-    blend two textures out of a larger set of textures.  Moreover, in some
-    cases the selected textures may vary on a per-fragment basis within
-    a polygon.  Several examples include:
-
-       1. High dynamic range textures.  The application stores several
-       different "exposures" of an image as different textures.  On a
-       per-fragment basis, the application selects which exposures are
-       used.
-
-       2. A terrain engine where the altitude of a point determines the
-       texture applied to it.  If the transition is from beach sand to
-       grass to rocks to snow, the application will store each texture
-       in a different texture map, and dynamically select which two
-       textures to blend at run-time.
-
-       3. Storing short video clips in textures.  Each depth slice is a
-       single frame of video.
-
-    Several solutions to this problem have been proposed, but they either
-    involve using a separate texture unit for each texture map or using 3D
-    textures without mipmaps.  Both of these options have major drawbacks.
-
-    This extension provides a third alternative that eliminates the major
-    drawbacks of both previous methods.  A new texture target,
-    TEXTURE_2D_ARRAY, is added that functions identically to TEXTURE_3D in
-    all aspects except the sizes of the non-base level images.  In
-    traditional 3D texturing, the size of the N+1 LOD is half the size
-    of the N LOD in all three dimensions.  For the TEXTURE_2D_ARRAY target,
-    the height and width of the N+1 LOD is halved, but the depth is the
-    same for all levels of detail. The texture then becomes an array of
-    2D textures.  The per-fragment texel is selected by the R texture
-    coordinate.
-
-    References:
-
-        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011557
-        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=000516
-        http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011903
-        http://www.delphi3d.net/articles/viewarticle.php?article=terraintex.htm
-
-New Procedures and Functions
-
-    All functions come directly from EXT_texture_array.
-
-    void FramebufferTextureLayerEXT(enum target, enum attachment,
-                                    uint texture, int level, int layer);
-
-New Tokens
-
-    All token names and values come directly from EXT_texture_array.
-
-    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by
-    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
-    GetDoublev, and by the <target> parameter of TexImage3D, GetTexImage,
-    GetTexLevelParameteriv, GetTexLevelParameterfv, GetTexParameteriv, and
-    GetTexParameterfv:
-
-        TEXTURE_1D_ARRAY_EXT                            0x8C18
-        TEXTURE_2D_ARRAY_EXT                            0x8C1A
-
-    Accepted by the <target> parameter of TexImage2D, TexSubImage2D,
-    CopyTexImage2D, CopyTexSubImage2D, CompressedTexImage2D,
-    CompressedTexSubImage2D, GetTexLevelParameteriv, and 
-    GetTexLevelParameterfv:
-
-        TEXTURE_1D_ARRAY_EXT
-        PROXY_TEXTURE_1D_ARRAY_EXT                      0x8C19
-
-    Accepted by the <target> parameter of TexImage3D, TexSubImage3D,
-    CopyTexSubImage3D, CompressedTexImage3D, CompressedTexSubImage3D,
-    GetTexLevelParameteriv, and GetTexLevelParameterfv:
-
-        TEXTURE_2D_ARRAY_EXT
-        PROXY_TEXTURE_2D_ARRAY_EXT                      0x8C1B
-
-    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
-    GetFloatv, and GetDoublev
-
-        TEXTURE_BINDING_1D_ARRAY_EXT                    0x8C1C
-        TEXTURE_BINDING_2D_ARRAY_EXT                    0x8C1D
-        MAX_ARRAY_TEXTURE_LAYERS_EXT                    0x88FF
-
-    Accepted by the <param> parameter of TexParameterf, TexParameteri,
-    TexParameterfv, and TexParameteriv when the <pname> parameter is
-    TEXTURE_COMPARE_MODE_ARB:
-
-        COMPARE_REF_DEPTH_TO_TEXTURE_EXT                0x884E
-
-    (Note:  COMPARE_REF_DEPTH_TO_TEXTURE_EXT is simply an alias for the
-    existing COMPARE_R_TO_TEXTURE token in OpenGL 2.0; the alternate name
-    reflects the fact that the R coordinate is not always used.)
-
-    Accepted by the <internalformat> parameter of TexImage3D and
-    CompressedTexImage3D, and by the <format> parameter of
-    CompressedTexSubImage3D:
-
-        COMPRESSED_RGB_S3TC_DXT1_EXT
-        COMPRESSED_RGBA_S3TC_DXT1_EXT
-        COMPRESSED_RGBA_S3TC_DXT3_EXT
-        COMPRESSED_RGBA_S3TC_DXT5_EXT
-
-    Accepted by the <pname> parameter of
-    GetFramebufferAttachmentParameterivEXT:
-
-        FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT          0x8CD4
-
-    (Note:  FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER is simply an alias for the
-    FRAMEBUFFER_ATTACHMENT_TEXTURE_3D_ZOFFSET_EXT token provided in
-    EXT_framebuffer_object.  This extension generalizes the notion of
-    "<zoffset>" to include layers of an array texture.)
-
-Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
-
-    -- Section 3.8.1 "Texture Image Specification"
-
-       Change the first paragraph (page 150) to say (spec changes identical to
-       EXT_texture_array):
-
-       "The command
-
-         void TexImage3D(enum target, int level, int internalformat,
-                         sizei width, sizei height, sizei depth, int border,
-                         enum format, enum type, void *data);
-
-       is used to specify a three-dimensional texture image. target must be one
-       one of TEXTURE_3D for a three-dimensional texture or
-       TEXTURE_2D_ARRAY_EXT for an two-dimensional array texture.
-       Additionally, target may be either PROXY_TEXTURE_3D for a
-       three-dimensional proxy texture, or PROXY_TEXTURE_2D_ARRAY_EXT for a
-       two-dimensional proxy array texture."
-
-       Change the fourth paragraph on page 151 to say (spec changes identical
-       to EXT_texture_array):
-
-       "Textures with a base internal format of DEPTH_COMPONENT are supported
-       by texture image specification commands only if target is TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_2D_ARRAY_EXT,
-       PROXY_TEXTURE_1D, PROXY_TEXTURE_2D, PROXY_TEXTURE_1D_ARRAY_EXT, or
-       PROXY_TEXTURE_2D_ARRAY_EXT. Using this format in conjunction with any
-       other target will result in an INVALID_OPERATION error."
-
-
-       Change the fourth paragraph on page 156 to say (spec changes identical
-       to EXT_texture_array):
-       
-       "The command
-
-         void TexImage2D(enum target, int level,
-                         int internalformat, sizei width, sizei height,
-                         int border, enum format, enum type, void *data);
-
-       is used to specify a two-dimensional texture image. target must be one
-       of TEXTURE_2D for a two-dimensional texture, TEXTURE_1D_ARRAY_EXT for a
-       one-dimensional array texture, or one of TEXTURE_CUBE_MAP_POSITIVE_X,
-       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE_MAP_POSITIVE_Y,
-       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
-       TEXTURE_CUBE_MAP_NEGATIVE_Z for a cube map texture. Additionally,
-       target may be either PROXY_TEXTURE_2D for a two-dimensional proxy
-       texture, PROXY_TEXTURE_1D_ARRAY_EXT for a one-dimensional proxy array
-       texture, or PROXY TEXTURE_CUBE_MAP for a cube map proxy texture in the
-       special case discussed in section 3.8.11.  The other parameters match
-       the corresponding parameters of TexImage3D.
-
-       For the purposes of decoding the texture image, TexImage2D is
-       equivalent to calling TexImage3D with corresponding arguments and depth
-       of 1, except that
-
-         * The border depth, d_b, is zero, and the depth of the image is
-           always 1 regardless of the value of border. 
-
-         * The border height, h_b, is zero if <target> is
-           TEXTURE_1D_ARRAY_EXT, and <border> otherwise.
-
-         * Convolution will be performed on the image (possibly changing its
-           width and height) if SEPARABLE 2D or CONVOLUTION 2D is enabled.
-
-         * UNPACK SKIP IMAGES is ignored."
-
-    -- Section 3.8.2 "Alternate Texture Image Specification Commands"
-
-       Change the second paragraph (page 159) (spec changes identical
-       to EXT_texture_array):
-
-       "The command
-
-         void CopyTexImage2D(enum target, int level,
-                             enum internalformat, int x, int y, sizei width,
-                             sizei height, int border);
-
-       defines a two-dimensional texture image in exactly the manner of
-       TexImage2D, except that the image data are taken from the framebuffer
-       rather than from client memory. Currently, target must be one of
-       TEXTURE_2D, TEXTURE_1D_ARRAY_EXT, TEXTURE_CUBE_MAP_POSITIVE_X,
-       TEXTURE_CUBE_MAP_NEGATIVE_X, TEXTURE_CUBE MAP_POSITIVE_Y,
-       TEXTURE_CUBE_MAP_NEGATIVE_Y, TEXTURE_CUBE_MAP_POSITIVE_Z, or
-       TEXTURE_CUBE_MAP_NEGATIVE_Z.
-
-
-       Change the last paragraph on page 160 to say (spec changes identical
-       to EXT_texture_array):
-
-       "Currently the target arguments of TexSubImage1D and CopyTexSubImage1D
-       must be TEXTURE_1D, the target arguments of TexSubImage2D and
-       CopyTexSubImage2D must be one of TEXTURE_2D, TEXTURE_1D_ARRAY_EXT,
-       TEXTURE_CUBE_MAP_POSITIVE_X, TEXTURE_CUBE_MAP_NEGATIVE_X,
-       TEXTURE_CUBE_MAP_POSITIVE_Y, TEXTURE_CUBE_MAP_NEGATIVE_Y,
-       TEXTURE_CUBE_MAP_POSITIVE_Z, or TEXTURE_CUBE_MAP_NEGATIVE_Z, and the
-       target arguments of TexSubImage3D and CopyTexSubImage3D must be
-       TEXTURE_3D or TEXTURE_2D_ARRAY_EXT. ..."
-
-
-    -- Section 3.8.4 "Texture Parameters"
-
-       Change the first paragraph (page 166) to say:
-
-       "Various parameters control how the texel array is treated when
-       specified or changed, and when applied to a fragment. Each parameter is
-       set by calling
-
-         void TexParameter{if}(enum target, enum pname, T param); 
-         void TexParameter{if}v(enum target, enum pname, T params);
-
-       target is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
-       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT."
-
-
-    -- Section 3.8.8 "Texture Minification" in the section "Scale Factor and Level of Detail"
-
-       Change the first paragraph (page 172) to say:
-
-       "Let s(x,y) be the function that associates an s texture coordinate
-       with each set of window coordinates (x,y) that lie within a primitive;
-       define t(x,y) and r(x,y) analogously.  Let u(x,y) = w_t * s(x,y),
-       v(x,y) = h_t * t(x,y), and w(x,y) = d_t * r(x,y), where w_t, h_t,
-       and d_t are as defined by equations 3.15, 3.16, and 3.17 with
-       w_s, h_s, and d_s equal to the width, height, and depth of the
-       image array whose level is level_base.  For a one-dimensional
-       texture or a one-dimensional array texture, define v(x,y) = 0 and
-       w(x,y) = 0; for a two-dimensional texture or a two-dimensional array
-       texture, define w(x,y) = 0..."
-
-    -- Section 3.8.8 "Texture Minification" in the section "Mipmapping"
-
-       Change the third paragraph (page 174) to say:
-       
-       "For a two-dimensional texture, two-dimensional array texture, or
-       cube map texture,"
-
-       Change the fourth paragraph (page 174) to say:
-
-       "And for a one-dimensional texture or a one-dimensional array texture,"
-
-       After the first paragraph (page 175) add:
-
-       "For one-dimensional array textures, h_b and d_b are treated as 1,
-       regardless of the actual values, when performing mipmap calculations.
-       For two-dimensional array textures, d_b is always treated as one,
-       regardless of the actual value, when performing mipmap calculations."
-
-    -- Section 3.8.8 "Automatic Mipmap Generation" in the section "Mipmapping"
-
-       Change the third paragraph (page 176) to say (spec changes identical
-       to EXT_texture_array):
-
-       "The contents of the derived arrays are computed by repeated, filtered
-       reduction of the level_base array.  For one- and two-dimensional array
-       textures, each layer is filtered independently.  ..."
-
-    -- Section 3.8.8 "Manual Mipmap Generation" in the section "Mipmapping"
-
-       Change first paragraph to say (spec changes identical to
-       EXT_texture_array):
-
-       "Mipmaps can be generated manually with the command
-
-         void GenerateMipmapEXT(enum target);
-
-       where <target> is one of TEXTURE_1D, TEXTURE_2D, TEXTURE_CUBE_MAP,
-       TEXTURE_3D, TEXTURE_1D_ARRAY, or TEXTURE_2D_ARRAY.  Mipmap generation
-       affects the texture image attached to <target>.  ..."
-
-    -- Section 3.8.10 "Texture Completeness"
-
-       Change the second paragraph (page 177) to say (spec changes identical
-       to EXT_texture_array):
-
-       "For one-, two-, or three-dimensional textures and one- or
-       two-dimensional array textures, a texture is complete if the following
-       conditions all hold true:"
-
-    -- Section 3.8.11 "Texture State and Proxy State"
-
-       Change the second and third paragraphs (page 179) to say (spec changes
-       identical to EXT_texture_array):
-
-       "In addition to image arrays for one-, two-, and three-dimensional
-       textures, one- and two-dimensional array textures, and the six image
-       arrays for the cube map texture, partially instantiated image arrays
-       are maintained for one-, two-, and three-dimensional textures and one-
-       and two-dimensional array textures.  Additionally, a single proxy image
-       array is maintained for the cube map texture.  Each proxy image array
-       includes width, height, depth, border width, and internal format state
-       values, as well as state for the red, green, blue, alpha, luminance,
-       and intensity component resolutions. Proxy image arrays do not include
-       image data, nor do they include texture properties. When TexImage3D is
-       executed with target specified as PROXY_TEXTURE_3D, the
-       three-dimensional proxy state values of the specified level-of-detail
-       are recomputed and updated. If the image array would not be supported
-       by TexImage3D called with target set to TEXTURE 3D, no error is
-       generated, but the proxy width, height, depth, border width, and
-       component resolutions are set to zero. If the image array would be
-       supported by such a call to TexImage3D, the proxy state values are set
-       exactly as though the actual image array were being specified. No pixel
-       data are transferred or processed in either case.
-
-       Proxy arrays for one- and two-dimensional textures and one- and
-       two-dimensional array textures are operated on in the same way when
-       TexImage1D is executed with target specified as PROXY_TEXTURE_1D,
-       TexImage2D is executed with target specified as PROXY_TEXTURE_2D or
-       PROXY_TEXTURE_1D_ARRAY_EXT, or TexImage3D is executed with target
-       specified as PROXY_TETXURE_2D_ARRAY_EXT."
-
-    -- Section 3.8.12 "Texture Objects"
-
-       Change section (page 180) to say (spec changes identical to 
-       EXT_texture_array):
-
-       "In addition to the default textures TEXTURE_1D, TEXTURE_2D,
-       TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_EXT,
-       named one-, two-, and three-dimensional, cube map, and one- and
-       two-dimensional array texture objects can be created and operated upon.
-       The name space for texture objects is the unsigned integers, with zero
-       reserved by the GL.
-
-       A texture object is created by binding an unused name to TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT. The binding is effected by calling
-
-         void BindTexture(enum target, uint texture);
-
-       with <target> set to the desired texture target and <texture> set to
-       the unused name.  The resulting texture object is a new state vector,
-       comprising all the state values listed in section 3.8.11, set to the
-       same initial values. If the new texture object is bound to TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT, it is and remains a one-, two-,
-       three-dimensional, cube map, one- or two-dimensional array texture
-       respectively until it is deleted.
-
-       BindTexture may also be used to bind an existing texture object to
-       either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
-       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT. The error
-       INVALID_OPERATION is generated if an attempt is made to bind a texture
-       object of different dimensionality than the specified target. If the
-       bind is successful no change is made to the state of the bound texture
-       object, and any previous binding to target is broken.
-
-       While a texture object is bound, GL operations on the target to which
-       it is bound affect the bound object, and queries of the target to which
-       it is bound return state from the bound object. If texture mapping of
-       the dimensionality of the target to which a texture object is bound is
-       enabled, the state of the bound texture object directs the texturing
-       operation.
-
-       In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,
-       TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and TEXTURE_2D_ARRAY_EXT have
-       one-, two-, three-dimensional, cube map, and one- and two-dimensional
-       array texture state vectors respectively associated with them. In order
-       that access to these initial textures not be lost, they are treated as
-       texture objects all of whose names are 0. The initial one-, two-,
-       three-dimensional, cube map, one- and two-dimensional array textures
-       are therefore operated upon, queried, and applied as TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, and
-       TEXTURE_2D_ARRAY_EXT respectively while 0 is bound to the corresponding
-       targets.
-
-       Change second paragraph on page 181 to say (spec changes identical to 
-       EXT_texture_array):
-       
-       "...  If a texture that is currently bound to one of the targets
-       TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP,
-       TEXTURE_1D_ARRAY_EXT, or TEXTURE_2D_ARRAY_EXT is deleted, it is as
-       though BindTexture had been executed with the same target and texture
-       zero. ..."
-
-       Change second paragraph on page 182 to say (spec changes identical to 
-       EXT_texture_array):
-       
-       "The texture object name space, including the initial one-, two-, and
-       three dimensional, cube map, and one- and two-dimensional array texture
-       objects, is shared among all texture units. ..."
-
-
-    -- Section 3.8.14 "Depth Texture Comparison Modes" in "Texture Comparison Modes"
-
-       Change second through fourth paragraphs (page 188) to say:
-
-       "Let D_t be the depth texture value, in the range [0, 1].  For
-       texture lookups from one- and two-dimensional, rectangle, and
-       one-dimensional array targets, let R be the interpolated <r>
-       texture coordinate, clamped to the range [0, 1].  For texture lookups
-       from two-dimensional array texture targets, let R be the interpolated
-       <q> texture coordinate, clamped to the range [0, 1].  Then the
-       effective texture value L_t, I_t, or A_t is computed as follows:
-
-       If the value of TEXTURE_COMPARE_MODE is NONE, then
-
-          r = Dt
-
-       If the value of TEXTURE_COMPARE_MODE is
-       COMPARE_REF_DEPTH_TO_TEXTURE_EXT), then r depends on the texture
-       comparison function as shown in table 3.27."
-
-    -- Section 3.8.15 "Texture Application"
-
-       Change the first paragraph (page 189) to say:
-
-       "Texturing is enabled or disabled using the generic Enable and Disable
-       commands, respectively, with the symbolic constants TEXTURE_1D,
-       TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, TEXTURE_1D_ARRAY_EXT, or
-       TEXTURE_2D_ARRAY_EXT to enable one-, two-, three-dimensional, cube
-       map, one-dimensional array, or two-dimensional array texture,
-       respectively.  If both two- and one-dimensional textures are enabled,
-       the two-dimensional texture is used.  If the three-dimensional and
-       either of the two- or one-dimensional textures is enabled, the
-       three-dimensional texture is used.  If the cube map texture and any of
-       the three-, two-, or one-dimensional textures is enabled, then cube map
-       texturing is used.  If one-dimensional array texture is enabled and any
-       of cube map, three-, two-, or one-dimensional textures is enabled, 
-       one-dimensional array texturing is used.  If two-dimensional array
-       texture is enabled and any of cube map, three-, two-, one-dimensional
-       textures or one-dimensional array texture is enabled, two-dimensional
-       array texturing is used..."
-
-    -- Section 3.11.2 of ARB_fragment_program (Fragment Program Grammar and Restrictions):
-
-       (mostly add to existing grammar rules)
-
-       <optionName>           ::= "MESA_texture_array"
-
-       <texTarget>            ::= "1D"
-                               | "2D"
-                               | "3D"
-                               | "CUBE"
-                               | "RECT"
-                               | <arrayTarget> (if program option is present)
-                               | <shadowTarget> (if program option is present)
-
-       <arrayTarget>          ::= "ARRAY1D"
-                               | "ARRAY2D"
-
-       <shadowTarget>         ::= "SHADOW1D"
-                               | "SHADOW2D"
-                               | "SHADOWRECT"
-                               | <shadowArrayTarget> (if program option is present)
-
-       <shadowArrayTarget>    ::= "SHADOWARRAY1D"
-                               | "SHADOWARRAY2D"
-
-
-    -- Add Section 3.11.4.5.4 "Texture Stack Option"
-
-       "If a fragment program specifies the "MESA_texture_array" program
-       option, the <texTarget> rule is modified to add the texture targets
-       ARRAY1D and ARRAY2D (See Section 3.11.2)."
-
-    -- Section 3.11.6 "Fragment Program Texture Instruction Set"
-
-       (replace 1st and 2nd paragraphs with the following paragraphs)
-
-       "The first three texture instructions described below specify the
-       mapping of 4-tuple input vectors to 4-tuple output vectors.
-       The sampling of the texture works as described in section 3.8,
-       except that texture environments and texture functions are not
-       applicable, and the texture enables hierarchy is replaced by explicit
-       references to the desired texture target (i.e., 1D, 2D, 3D, cube map,
-       rectangle, ARRAY1D, ARRAY2D).  These texture instructions specify
-       how the 4-tuple is mapped into the coordinates used for sampling.  The
-       following function is used to describe the texture sampling in the
-       descriptions below: 
-
-         vec4 TextureSample(vec4 coord, float lodBias, int texImageUnit,
-                            enum texTarget);
-
-       Note that not all four components of the texture coordinates <coord>
-       are used by all texture targets.  Component usage for each <texTarget>
-       is defined in table X.
-
-                                                        coordinates used
-         texTarget          Texture Type               s t r  layer  shadow
-         ----------------   ---------------------      -----  -----  ------
-         1D                 TEXTURE_1D                 x - -    -      -
-         2D                 TEXTURE_2D                 x y -    -      -
-         3D                 TEXTURE_3D                 x y z    -      -
-         CUBE               TEXTURE_CUBE_MAP           x y z    -      -
-         RECT               TEXTURE_RECTANGLE_ARB      x y -    -      -
-         ARRAY1D            TEXTURE_1D_ARRAY_EXT       x - -    y      -
-         ARRAY2D            TEXTURE_2D_ARRAY_EXT       x y -    z      -
-         SHADOW1D           TEXTURE_1D                 x - -    -      z
-         SHADOW2D           TEXTURE_2D                 x y -    -      z
-         SHADOWRECT         TEXTURE_RECTANGLE_ARB      x y -    -      z
-         SHADOWARRAY1D      TEXTURE_1D_ARRAY_EXT       x - -    y      z
-         SHADOWARRAY2D      TEXTURE_2D_ARRAY_EXT       x y -    z      w
-
-         Table X:  Texture types accessed for each of the <texTarget>, and
-         coordinate mappings.  The "coordinates used" column indicate the
-         input values used for each coordinate of the texture lookup, the
-         layer selector for array textures, and the reference value for
-         texture comparisons."
-
-    -- Section 3.11.6.2 "TXP: Project coordinate and map to color"
-    
-       Add to the end of the section:
-       
-       "A program will fail to load if the TXP instruction is used in
-       conjunction with the SHADOWARRAY2D target."
-
-Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations)
-
-    -- Section 4.4.2.3 "Attaching Texture Images to a Framebuffer"
-
-       Add to the end of the section (spec changes identical to
-       EXT_texture_array):
-
-       "The command
-
-         void FramebufferTextureLayerEXT(enum target, enum attachment,
-                                         uint texture, int level, int layer);
-
-       operates identically to FramebufferTexture3DEXT, except that it
-       attaches a single layer of a three-dimensional texture or a one- or
-       two-dimensional array texture.  <layer> is an integer indicating the
-       layer number, and is treated identically to the <zoffset> parameter in
-       FramebufferTexture3DEXT.  The error INVALID_VALUE is generated if
-       <layer> is negative.  The error INVALID_OPERATION is generated if
-       <texture> is non-zero and is not the name of a three dimensional
-       texture or one- or two-dimensional array texture.  Unlike
-       FramebufferTexture3D, no <textarget> parameter is accepted.
-
-       If <texture> is non-zero and the command does not result in an error,
-       the framebuffer attachment state corresponding to <attachment> is
-       updated as in the other FramebufferTexture commands, except that
-       FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT is set to <layer>."
-
-    -- Section 4.4.4.1 "Framebuffer Attachment Completeness"
-
-      Add to the end of the list of completeness rules (spec changes
-      identical to EXT_texture_array):
-
-        "* If FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE and
-           FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT names a one- or 
-           two-dimensional array texture, then
-           FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT must be smaller than the
-           number of layers in the texture."
-
-Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
-
-    -- Section 5.4 "Display Lists"
-
-       Change the first paragraph on page 242 to say (spec changes
-       identical to EXT_texture_array):
-
-       "TexImage3D, TexImage2D, TexImage1D, Histogram, and ColorTable are
-       executed immediately when called with the corresponding proxy arguments
-       PROXY_TEXTURE_3D or PROXY_TEXTURE_2D_ARRAY_EXT; PROXY_TEXTURE_2D,
-       PROXY_TEXTURE_CUBE_MAP, or PROXY_TEXTURE_1D_ARRAY_EXT;
-       PROXY_TEXTURE_1D; PROXY_HISTOGRAM; and PROXY_COLOR_TABLE,
-       PROXY_POST_CONVOLUTION_COLOR_TABLE, or
-       PROXY_POST_COLOR_MATRIX_COLOR_TABLE."
-
-Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
-
-    -- Section 6.1.3 "Enumerated Queries"
-
-       Add after the line beginning "If the value of
-       FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT is TEXTURE" (spec changes
-       identical to EXT_texture_array):
-
-       "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT and the
-       texture object named FRAMEBUFFER_ATTACHMENT_OBJECT_NAME_EXT is a
-       three-dimensional texture or a one- or two-dimensional array texture,
-       then <params> will contain the number of texture layer attached to the
-       attachment point.  Otherwise, <params> will contain the value zero."
-
-    -- Section 6.1.4 "Texture Queries"
-    
-       Change the first three paragraphs (page 248) to say (spec changes
-       identical to EXT_texture_array):
-
-       "The command
-
-         void GetTexImage(enum tex, int lod, enum format,
-                          enum type, void *img);
-
-       is used to obtain texture images. It is somewhat different from the
-       other get commands; tex is a symbolic value indicating which texture
-       (or texture face in the case of a cube map texture target name) is to
-       be obtained.  TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_1D_ARRAY_EXT,
-       and TEXTURE_2D_ARRAY_EXT indicate a one-, two-, or three-dimensional
-       texture, or one- or two-dimensional array texture, respectively.
-       TEXTURE_CUBE_MAP_POSITIVE_X, ...
-
-       GetTexImage obtains... from the first image to the last for
-       three-dimensional textures.  One- and two-dimensional array textures
-       are treated as two- and three-dimensional images, respectively, where
-       the layers are treated as rows or images.  These groups are then...
-
-       For three-dimensional and two-dimensional array textures, pixel storage
-       operations are applied as if the image were two-dimensional, except
-       that the additional pixel storage state values PACK_IMAGE_HEIGHT and
-       PACK_SKIP_IMAGES are applied. ..."
-
-Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Dependencies on ARB_fragment_program
-
-    If ARB_fragment_program is not supported, the changes to section 3.11
-    should be ignored.
-
-Dependencies on EXT_framebuffer_object
-
-    If EXT_framebuffer_object is not supported, the changes to section
-    3.8.8 ("Manual Mipmap Generation"), 4.4.2.3, and 6.1.3 should be ignored.
-
-Dependencies on EXT_texture_compression_s3tc and NV_texture_compression_vtc
-
-    (Identical dependency as EXT_texture_array.)
-
-    S3TC texture compression is supported for two-dimensional array textures.
-    When <target> is TEXTURE_2D_ARRAY_EXT, each layer is stored independently
-    as a compressed two-dimensional textures.  When specifying or querying
-    compressed images using one of the S3TC formats, the images are provided
-    and/or returned as a series of two-dimensional textures stored
-    consecutively in memory, with the layer closest to zero specified first.
-    For array textures, images are not arranged in 4x4x4 or 4x4x2 blocks as in
-    the three-dimensional compression format provided in the
-    EXT_texture_compression_vtc extension.  Pixel store parameters, including
-    those specific to three-dimensional images, are ignored when compressed
-    image data are provided or returned, as in the
-    EXT_texture_compression_s3tc extension.
-
-    S3TC compression is not supported for one-dimensional texture targets in
-    EXT_texture_compression_s3tc, and is not supported for one-dimensional
-    array textures in this extension.  If compressed one-dimensional arrays
-    are needed, use a two-dimensional texture with a height of one.
-
-    This extension allows the use of the four S3TC internal format types in
-    TexImage3D, CompressedTexImage3D, and CompressedTexSubImage3D calls.
-
-Errors
-
-    None
-
-New State
-
-    (add to table 6.15, p. 276)
-
-                                                     Initial
-    Get Value                     Type   Get Command  Value Description           Sec.    Attribute
-    ----------------------------  -----  -----------  ----- --------------------  ------  ---------
-    TEXTURE_BINDING_1D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
-                                                            to TEXTURE_1D_ARRAY
-    TEXTURE_BINDING_2D_ARRAY_EXT  2*xZ+  GetIntegerv    0   texture object bound  3.8.12  texture
-                                                            to TEXTURE_2D_ARRAY
-
-
-New Implementation Dependent State
-
-    (add to Table 6.32, p. 293)
-
-                                                    Minimum
-    Get Value                     Type  Get Command  Value  Description         Sec.  Attribute
-    ----------------------------  ----  ----------- ------- ------------------  ----- ---------
-    MAX_TEXTURE_ARRAY_LAYERS_EXT   Z+   GetIntegerv   64    maximum number of   3.8.1     -
-                                                            layers for texture
-                                                            arrays
-
-Issues
-
-    (1) Is "texture stack" a good name for this functionality?
-
-        NO.  The name is changed to "array texture" to match the
-        nomenclature used by GL_EXT_texture_array.
-
-    (2) Should the R texture coordinate be treated as normalized or
-    un-normalized?  If it were un-normalized, floor(R) could be thought
-    of as a direct index into the array texture.  This may be more
-    convenient for applications.
-
-        RESOLVED.  All texture coordinates are normalized.  The issue of
-        un-normalized texture coordinates has been discussed in the ARB
-        before and should be left for a layered extension.
-
-        RE-RESOLVED.  The R coordinate is un-normalized.  Accessing an array
-        using [0, layers-1] coordinates is much more natural.
-
-    (3) How does LOD selection work for stacked textures?
-
-        RESOLVED.  For 2D array textures the R coordinate is ignored, and
-        the LOD selection equations for 2D textures are used.  For 1D
-        array textures the T coordinate is ignored, and the LOD selection
-        equations for 1D textures are used.  The expected usage is in a
-        fragment program with an explicit LOD selection.
-
-    (4) What is the maximum size of a 2D array texture?  Is it the same
-    as for a 3D texture, or should a new query be added?  How about for 1D
-    array textures?
-
-        RESOLVED.  A new query is added.
-
-    (5) How are array textures exposed in GLSL?
-    
-        RESOLVED.  Use GL_EXT_texture_array.
-        
-    (6) Should a 1D array texture also be exposed?
-
-        RESOLVED.  For orthogonality, yes.
-
-    (7) How are stacked textures attached to framebuffer objects?
-
-        RESOLVED.  Layers of both one- and two-dimensional array textures
-        are attached using FreambufferTextureLayerEXT.  Once attached, the
-        array texture layer behaves exactly as either a one- or
-        two-dimensional texture.
-
-    (8) How is this extension related to GL_EXT_texture_array?
-    
-        This extension adapats GL_MESAX_texture_stack to the notation,
-        indexing, and FBO access of GL_EXT_texture_array.  This extension
-        replaces the GLSL support of GL_EXT_texture_array with
-        GL_ARB_fragment_program support.
-
-        Assembly program support is also provided by GL_NV_gpu_program4.
-        GL_NV_gpu_program4 also adds support for other features that are
-        specific to Nvidia hardware, while this extension adds only support
-        for array textures.
-
-        Much of text of this extension that has changed since
-        GL_MESAX_texture_stack comes directly from either
-        GL_EXT_texture_array or GL_NV_gpu_program4.
-
-Revision History
-
-    ||2005/11/15||0.1||idr||Initial draft MESAX version.||
-    ||2005/12/07||0.2||idr||Added framebuffer object interactions.||
-    ||2005/12/12||0.3||idr||Updated fragment program interactions.||
-    ||2007/05/16||0.4||idr||Converted to MESA_texture_array.  Brought in line with EXT_texture_array and NV_gpu_program4.||

docs/MESA_texture_signed_rgba.spec

@@ -1,214 +0,0 @@
-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 superseded 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. Particularly 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.

docs/MESA_window_pos.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, brian.paul 'at' tungstengraphics.com
+    Brian Paul, brianp 'at' mesa3d.org
 
 Status
 
@@ -16,10 +16,11 @@ Status
 
 Version
 
+    $Id: MESA_window_pos.spec,v 1.1 1999/07/20 00:30:41 brianp Exp $
 
 Number
 
-    197
+    XXX non assigned
 
 Dependencies
 
@@ -32,7 +33,7 @@ Overview
     coordinate with the RasterPos command, the modelview matrix, projection
     matrix and viewport must be set very carefully.  Furthermore, if the
     desired window coordinate is outside of the window's bounds one must
-    rely on a subtle side-effect of the Bitmap command in order to circumvent
+    rely a subtle side-effect of the Bitmap command in order to circumvent
     frustum clipping.
 
     This extension provides a set of functions to directly set the
@@ -50,26 +51,6 @@ New Procedures and Functions
     void WindowPos2fMESA(float x, float y)
     void WindowPos2iMESA(int x, int y)
     void WindowPos2sMESA(short x, short y)
-    void WindowPos2ivMESA(const int *p)
-    void WindowPos2svMESA(const short *p)
-    void WindowPos2fvMESA(const float *p)
-    void WindowPos2dvMESA(const double *p)
-    void WindowPos3iMESA(int x, int y, int z)
-    void WindowPos3sMESA(short x, short y, short z)
-    void WindowPos3fMESA(float x, float y, float z)
-    void WindowPos3dMESA(double x, double y, double z)
-    void WindowPos3ivMESA(const int *p)
-    void WindowPos3svMESA(const short *p)
-    void WindowPos3fvMESA(const float *p)
-    void WindowPos3dvMESA(const double *p)
-    void WindowPos4iMESA(int x, int y, int z, int w)
-    void WindowPos4sMESA(short x, short y, short z, short w)
-    void WindowPos4fMESA(float x, float y, float z, float w)
-    void WindowPos4dMESA(double x, double y, double z, double )
-    void WindowPos4ivMESA(const int *p)
-    void WindowPos4svMESA(const short *p)
-    void WindowPos4fvMESA(const float *p)
-    void WindowPos4dvMESA(const double *p)
 
 New Tokens
 
@@ -83,12 +64,12 @@ Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
       WindowPosMESA commands:
 
          void WindowPos{234}{sidf}MESA( T coords );
-         void WindowPos{234}{sidf}vMESA( T coords );
+         void Window Pos{234}{sidf}vMESA( T coords );
 
       WindosPos4MESA takes four values indicating x, y, z, and w.
       WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only
       x, y, and z with w implicitly set to 1 (or only x and y with z
-      implicitly set to 0 and w implicitly set to 1).
+      implicititly set to 0 and w implicitly set to 1).
 
       WindowPosMESA operates like RasterPos except that the current modelview
       matrix, projection matrix and viewport parameters are ignored and the
@@ -97,6 +78,14 @@ Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
       color, color index and texture coordinate update the current raster
       position's associated data.
 
+      The current raster distance ??? XXX ???
+
+
+
+
+
+
+
 Additions to the AGL/GLX/WGL Specifications
 
     None
@@ -108,9 +97,10 @@ GLX Protocol
 
 Errors
 
-    INVALID_OPERATION is generated if WindowPosMESA is called between
+    INVALID_OPERATION is generated if WindowPosMESA is called betweeen
     Begin and End.
 
+
 New State
 
     None.
@@ -122,5 +112,3 @@ New Implementation Dependent State
 Revision History
 
   * Revision 1.0 - Initial specification
-  * Revision 1.1 - Minor clean-up  (7 Jan 2000, Brian Paul)
-

docs/MESA_ycbcr_texture.spec

@@ -1,204 +0,0 @@
-Name
-
-    MESA_ycbcr_texture
-
-Name Strings
-
-    GL_MESA_ycbcr_texture
-
-Contact
-
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
-    Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
-
-Status
-
-    Shipping (Mesa 4.0.4 and later)
-
-Version
-
-    1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.0 or later is required
-    This extension is written against the OpenGL 1.4 Specification.
-    NV_texture_rectangle effects the definition of this extension.
-
-Overview
-
-    This extension supports texture images stored in the YCbCr format.
-    There is no support for converting YCbCr images to RGB or vice versa
-    during pixel transfer.  The texture's YCbCr colors are converted to
-    RGB during texture sampling, after-which, all the usual per-fragment
-    operations take place.  Only 2D texture images are supported (not
-    glDrawPixels, glReadPixels, etc).
-
-    A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
-    The first component is luminance (Y).  For pixels in even-numbered
-    image columns, the second component is Cb.  For pixels in odd-numbered
-    image columns, the second component is Cr.  If one were to convert the
-    data to RGB one would need to examine two pixels from columns N and N+1
-    (where N is even) to deduce the RGB color.
-
-IP Status
-
-    None
-
-Issues
-
-    None
-
-New Procedures and Functions
-
-    None
-
-New Tokens
-
-    Accepted by the <internalFormat> and <format> parameters of
-    TexImage2D and TexSubImage2D:
-
-        YCBCR_MESA                   0x8757
-
-    Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
-
-        UNSIGNED_SHORT_8_8_MESA      0x85BA /* same as Apple's */
-        UNSIGNED_SHORT_8_8_REV_MESA  0x85BB /* same as Apple's */
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
-    add the following to Table 3.8 (Packed pixel formats):
-    
-    type Parameter                GL Data   Number of        Matching
-     Token Name                    Type     Components     Pixel Formats
-    --------------                -------   ----------     -------------
-    UNSIGNED_SHORT_8_8_MESA       ushort         2         YCBCR_MESA
-    UNSIGNED_SHORT_8_8_REV_MESA   ushort         2         YCBCR_MESA
-
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
-    add the following to Table 3.10 (UNSIGNED_SHORT formats):
-
-    UNSIGNED_SHORT_8_8_MESA:
-
-      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-    +-------------------------------+-------------------------------+
-    |              1st              |              2nd              |
-    +-------------------------------+-------------------------------+
-                        
-    UNSIGNED_SHORT_8_8_REV_MESA:
-
-      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-    +-------------------------------+-------------------------------+
-    |              2nd              |              1st              |
-    +-------------------------------+-------------------------------+
-
-
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
-    add the following to Table 3.12 (Packed pixel field assignments):
-
-                       First       Second     Third      Fourth
-    Format             Element     Element    Element    Element
-    ------             -------     -------    -------    -------
-    YCBCR_MESA         luminance   chroma
-
-
-    In section 3.8.1, Texture Image Specification, on page 125, add
-    another item to the list of TexImage2D and TexImage3D equivalence
-    exceptions:
-
-    * The value of internalformat and format may be YCBCR_MESA to
-      indicate that the image data is in YCbCr format.  type must
-      be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA
-      as seen in tables 3.8 and 3.10.  Table 3.12 describes the mapping
-      between Y and Cb/Cr to the components.
-      If NV_texture_rectangle is supported target may also be
-      TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
-      All pixel transfer operations are bypassed.  The texture is stored as
-      YCbCr, not RGB.  Queries of the texture's red, green and blue component
-      sizes will return zero.  The YCbCr colors are converted to RGB during
-      texture sampling using an implementation dependent conversion.
-
-
-    In section 3.8.1, Texture Image Specification, on page 126, add
-    another item to the list of TexImage1D and TexImage2D equivalence
-    exceptions:
-
-    * The value of internalformat and format can not be YCBCR_MESA.
-
-
-    In section 3.8.2, Alternate Texture Image Specification Commands, on
-    page 129, insert this paragraph after the first full paragraph on the
-    page:
-
-         "If the internal storage format of the image being updated by
-    TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA.
-    The error INVALID_OPERATION will be generated otherwise."
-
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    None
-
-Errors
-
-    INVALID_ENUM is generated by TexImage2D if <internalFormat> is
-    MESA_YCBCR but <format> is not MESA_YCBCR.
-
-    INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but
-    <internalFormat> is not MESA_YCBCR.
-
-    INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and
-    <internalFormat> is MESA_YCBCR and <border> is not zero.
-
-    INVALID_OPERATION is generated by TexSubImage2D if the internal image
-    format is YCBCR_MESA and <format> is not YCBCR_MESA.
-
-    INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
-    image is YCBCR_MESA.
-    
-New State
-
-    Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT
-    from n x Z42 to n x Z43 to indicate that internal format may also be
-    YCBCR_MESA.
-
-Revision History
-
-    20 September 2002 - Initial draft
-    29 April 2003 - minor updates
-     3 September 2003 - further clarify when YCbCr->RGB conversion takes place
-    19 September 2003 - a few more updates prior to submitting to extension
-                        registry.
-     3 April 2004 - fix assorted inaccuracies

docs/OLD/MESA_packed_depth_stencil.spec

@@ -1,230 +0,0 @@
-Name
-
-    MESA_packed_depth_stencil
-
-Name Strings
-
-    GL_MESA_packed_depth_stencil
-
-Contact
-
-    Keith Whitwell, VA Linux Systems Inc. (keithw 'at' valinux.com)
-    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
-
-Status
-
-    Obsolete.
-
-Version
-
-
-Number
-
-    ???
-
-Dependencies
-
-    EXT_abgr affects the definition of this extension
-    SGIS_texture4D affects the definition of this extension
-    EXT_cmyka affects the definition of this extension
-    ARB_packed_pixels affects the definition of this extension
-
-Overview
-	
-    Provides a mechanism for DrawPixels and ReadPixels to efficiently
-    transfer depth and stencil image data.  Specifically, we defined new
-    packed pixel formats and types which pack both stencil and depth
-    into one value.
-
-Issues:
-
-    1. Is this the right way to distinguish between 24/8 and 8/24
-       pixel formats?  Should we instead provide both:
-	
-       GL_DEPTH_STENCIL_MESA
-       GL_STENCIL_DEPTH_MESA
-
-       And perhaps just use GL_UNSIGNED_INT, GL_UNSIGNED_SHORT ?
-
-    2. If not, is it correct to use _REV to indicate that stencil
-       preceeds depth in the 1_15 and 8_24 formats?
-
-    3. Do we really want the GL_UNSIGNED_SHORT formats?  
-
-	
-New Procedures and Functions
-
-    None.
-
-New Tokens
-    
-    Accepted by the <format> parameter of ReadPixels and DrawPixels:
-
-	GL_DEPTH_STENCIL_MESA		0x8750
-
-    Accepted by the <type> parameter of ReadPixels and DrawPixels:
-
-	GL_UNSIGNED_INT_24_8_MESA	0x8751
-	GL_UNSIGNED_INT_8_24_REV_MESA	0x8752
-	GL_UNSIGNED_SHORT_15_1_MESA	0x8753
-	GL_UNSIGNED_SHORT_1_15_REV_MESA	0x8754
-
-Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.1 Specification (Rasterization)
-
-    One entry is added to table 3.5 (DrawPixels and ReadPixels formats).
-    The new table is:
-
-			Target
-	Format Name	Buffer	Element Meaning and Order
-	-----------	------	-------------------------
-	COLOR_INDEX	Color	Color index
-	STENCIL_INDEX	Stencil Stencil index
-	DEPTH_COMPONENT Depth	Depth component
-	RED		Color	R component
-	GREEN		Color	G component
-	BLUE		Color	B component
-	ALPHA		Color	A component
-	RGB		Color	R, G, B components
-	RGBA		Color	R, G, B, A components
-	BGRA	        Color   B, G, R, A components
-	ABGR_EXT	Color	A, B, G, R components
-	CMYK_EXT	Color	Cyan, Magenta, Yellow, Black components
-	CMYKA_EXT	Color	Cyan, Magenta, Yellow, Black, A components
-	LUMINANCE	Color	Luminance component
-	LUMINANCE_ALPHA Color	Luminance, A components
-	DEPTH_STENCIL   Depth,  Depth component, stencil index.
-			Stencil
-
-	Table 3.5: DrawPixels and ReadPixels formats.  The third column
-	gives a description of and the number and order of elements in a
-	group.
-
-    Add to the description of packed pixel formats:
-
-	<type> Parameter		Data	of	  Matching
-	Token Name			Type	Elements  Pixel Formats
-	----------------		----	--------  -------------
-
-	UNSIGNED_BYTE_3_3_2	      ubyte   3	      RGB
-	UNSIGNED_BYTE_2_3_3_REV       ubyte   3	      RGB
-	UNSIGNED_SHORT_5_6_5	      ushort  3	      RGB
-	UNSIGNED_SHORT_5_6_5_REV      ushort  3	      RGB
-	UNSIGNED_SHORT_4_4_4_4	      ushort  4	      RGBA,BGRA,ABGR_EXT,CMYK_EXT
-	UNSIGNED_SHORT_4_4_4_4_REV    ushort  4	      RGBA,BGRA
-	UNSIGNED_SHORT_5_5_5_1	      ushort  4	      RGBA,BGRA,ABGR_EXT,CMYK_EXT
-	UNSIGNED_SHORT_1_5_5_5_REV    ushort  4	      RGBA,BGRA
-	UNSIGNED_INT_8_8_8_8	      uint    4	      RGBA,BGRA,ABGR_EXT,CMYK_EXT
-	UNSIGNED_INT_8_8_8_8_REV      uint    4	      RGBA,BGRA
-	UNSIGNED_INT_10_10_10_2       uint    4	      RGBA,BGRA,ABGR_EXT,CMYK_EXT
-	UNSIGNED_INT_2_10_10_10_REV   uint    4	      RGBA,BGRA
-	UNSIGNED_SHORT_15_1_MESA      ushort  2       DEPTH_STENCIL_MESA
-	UNSIGNED_SHORT_1_15_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
-	UNSIGNED_SHORT_24_8_MESA      ushort  2       DEPTH_STENCIL_MESA
-	UNSIGNED_SHORT_8_24_REV_MESA  ushort  2       DEPTH_STENCIL_MESA
-
-	UNSIGNED_INT_8_24:
-
-	     31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10	9  8  7  6  5  4  3  2	1  0
-	    +-----------------------+-----------------------------------------------------------------------+
-	    |			    |			     			    			    |
-	    +-----------------------+-----------------------------------------------------------------------+
-
-		    first					second		    
-		    element					element		    
-
-
-	UNSIGNED_INT_24_8:
-
-	     31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10	9  8  7  6  5  4  3  2	1  0
-	    +----------------------------------------------------------------------+------------------------+
-	    |			    			     			   | 			    |
-	    +----------------------------------------------------------------------+------------------------+
-
-		    first								  second		    
-		    element								  element		    
-
-	UNSIGNED_SHORT_15_1:
-
-	      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-	    +-----------------------------------------------------------+---+
-	    |					    			|   |
-	    +-----------------------------------------------------------+---+
-
-	    		first						second	
-			element						element	
-
-
-	UNSIGNED_SHORT_1_15_REV:
-
-	      15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
-	    +---+-----------------------------------------------------------+
-	    |	|		     					    |
-	    +---+-----------------------------------------------------------+
-
-	    second		    first
-	    element		    element
-
-    The assignment of elements to fields in the packed pixel is as
-    described in the table below:
-
-			   First       Second	Third	    Fourth
-	Format		   Element     Element	Element     Element
-	------		   -------     -------	-------     -------
-	RGB		   red	       green	blue
-	RGBA		   red	       green	blue	    alpha
-	BGRA		   blue	       green	red	    alpha
-	ABGR_EXT	   alpha       blue	green	    red
-	CMYK_EXT	   cyan	       magenta	yellow	    black
-	DEPTH_STENCIL_MESA depth       stencil
-
-Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
-and the Frame Buffer)
-
-    The new format is added to the discussion of Obtaining Pixels from the
-    Framebuffer.  It should read " If the <format> is one of RED, GREEN,
-    BLUE, ALPHA, RGB, RGBA, ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, and
-    the GL is in color index mode, then the color index is obtained."
-
-    The new format is added to the discussion of Index Lookup.  It should
-    read "If <format> is one of RED, GREEN, BLUE, ALPHA, RGB, RGBA,
-    ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, then the index is used to
-    reference 4 tables of color components: PIXEL_MAP_I_TO_R,
-    PIXEL_MAP_I_TO_G, PIXEL_MAP_I_TO_B, and PIXEL_MAP_I_TO_A."
-
-
-Additions to Chapter 5 of the 1.1 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
-
-    None
-
-Additions to the GLX Specification
-
-    None
-
-GLX Protocol
-
-    TBD
-
-Errors
-
-    None
-
-New State
-
-    None
-
-Revision History
-
-    Version 1.0 - 23 Sep 2000
-        Keith's original version.
-
-    Version 1.1 - 3 Nov 2000
-        Brian's edits, assigned values to new enums.
-

docs/OLD/MESA_program_debug.spec

@@ -1,356 +0,0 @@
-Name
-
-    MESA_program_debug
-
-Name Strings
-
-    GL_MESA_program_debug
-
-Contact
-
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
-
-Status
-
-    XXX - Not complete yet!!!
-
-Version
-
-    Last Modified Date: July 20, 2003
-    Author Revision: 1.0
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.4 is required
-    The extension is written against the OpenGL 1.4 specification.
-    ARB_vertex_program or ARB_fragment_program or NV_vertex_program
-    or NV_fragment_program is required.
-
-Overview
-
-    The extension provides facilities for implementing debuggers for
-    vertex and fragment programs.
-
-    The concept is that vertex and fragment program debuggers will be
-    implemented outside of the GL as a utility package.  This extension
-    only provides the minimal hooks required to implement a debugger.
-
-    There are facilities to do the following:
-    1. Have the GL call a user-specified function prior to executing
-       each vertex or fragment instruction.
-    2. Query the current program string's execution position.
-    3. Query the current values of intermediate program values.
-
-    The main feature is the ProgramCallbackMESA function.  It allows the
-    user to register a callback function with the GL.  The callback will
-    be called prior to executing each vertex or fragment program instruction.
-
-    From within the callback, the user may issue Get* commands to
-    query current GL state.  The GetProgramRegisterfvMESA function allows
-    current program values to be queried (such as temporaries, input
-    attributes, and result registers).
-
-    There are flags for enabling/disabling the program callbacks.
-
-    The current execution position (as an offset from the start of the
-    program string) can be queried with
-    GetIntegerv(GL_FRAGMENT_PROGRAM_POSITION_MESA, &pos) or
-    GetIntegerv(GL_VERTEX_PROGRAM_POSITION_MESA, &pos).
-
-
-IP Status
-
-    None
-
-Issues
-
-    1. Is this the right model for a debugger?
-
-       It seems prudent to minimize the scope of this extension and leave
-       it up to the developer (or developer community) to write debuggers
-       that layer on top of this extension.
-
-       If the debugger were fully implemented within the GL it's not
-       clear how terminal and GUI-based interfaces would work, for
-       example.
-
-    2. There aren't any other extensions that register callbacks with
-       the GL.  Isn't there another solution?
-
-       If we want to be able to single-step through vertex/fragment
-       programs I don't see another way to do it.
-
-    3. How do we prevent the user from doing something crazy in the
-       callback function, like trying to call glBegin (leading to
-       recursion)?
-
-       The rule is that the callback function can only issue glGet*()
-       functions and no other GL commands.  It could be difficult to
-       enforce this, however.  Therefore, calling any non-get GL
-       command from within the callback will result in undefined
-       results.    
-
-    4. Is this extension amenable to hardware implementation?
-
-       Hopefully, but if not, the GL implementation will have to fall
-       back to a software path when debugging.  This may be acceptable
-       for debugging.
-
-    5. What's the <data> parameter to ProgramCallbackMESA for?
-
-       It's a common programming practice to associate a user-supplied
-       value with callback functions.
-
-    6. Debuggers often allow one to modify intermediate program values,
-       then continue.  Does this extension support that?
-
-       No.
-
-
-New Procedures and Functions (and datatypes)
-
-    typedef void (*programcallbackMESA)(enum target, void *data)
-
-    void ProgramCallbackMESA(enum target, programcallbackMESA callback,
-                             void *data)
-
-    void GetProgramRegisterfvMESA(enum target, sizei len,
-                                  const ubyte *registerName, float *v)
-
-New Tokens
-
-    Accepted by the <cap> parameter of Enable, Disable, IsEnabled,
-    GetBooleanv, GetDoublev, GetFloatv and GetIntegerv:
-
-        FRAGMENT_PROGRAM_CALLBACK_MESA      0x8bb1
-        VERTEX_PROGRAM_CALLBACK_MESA        0x8bb4
-
-    Accepted by the <pname> parameter GetBooleanv, GetDoublev,
-    GetFloatv and GetIntegerv:
-
-        FRAGMENT_PROGRAM_POSITION_MESA      0x8bb0
-        VERTEX_PROGRAM_POSITION_MESA        0x8bb4
-
-    Accepted by the <pname> parameter of GetPointerv:
-
-        FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8bb2
-        FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8bb3
-        VERTEX_PROGRAM_CALLBACK_FUNC_MESA   0x8bb6
-        VERTEX_PROGRAM_CALLBACK_DATA_MESA   0x8bb7
-
-Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
-
-    None.
-
-Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment
-Operations and the Frame Buffer)
-
-    None.
-
-Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions)
-
-    In section 5.4 "Display Lists", page 202, add the following command
-    to the list of those that are not compiled into display lists:
-
-        ProgramCallbackMESA.
-
-
-    Add a new section 5.7 "Callback Functions"
-
-    The function
-
-        void ProgramCallbackMESA(enum target, programcallbackMESA callback,
-                                 void *data)
-
-    registers a user-defined callback function with the GL.  <target>
-    may be FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.  The enabled
-    callback functions registered with these targets will be called
-    prior to executing each instruction in the current fragment or
-    vertex program, respectively.  The callbacks are enabled and
-    disabled by calling Enable or Disable with <cap>
-    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB.
-
-    The callback function's signature must match the typedef
-
-        typedef void (*programcallbackMESA)(enum target, void *data)
-
-    When the callback function is called, <target> will either be
-    FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which
-    program is currently executing and <data> will be the value
-    specified when ProgramCallbackMESA was called.
-
-    From within the callback function, only the following GL commands
-    may be called:
-
-        GetBooleanv
-        GetDoublev
-        GetFloatv
-        GetIntegerv
-        GetProgramLocalParameter
-        GetProgramEnvParameter
-        GetProgramRegisterfvMESA
-        GetProgramivARB
-        GetProgramStringARB
-        GetError
-
-    Calling any other command from within the callback results in
-    undefined behaviour.
-
-
-Additions to Chapter 6 of the OpenGL 1.4 Specification (State and
-State Requests)
-
-    Add a new section 6.1.3 "Program Value Queries":
-
-    The command
-
-        void GetProgramRegisterfvMESA(enum target, sizei len,
-                                      const ubyte *registerName,
-                                      float *v)
-        
-    Is used to query the value of program variables and registers
-    during program execution.  GetProgramRegisterfvMESA may only be
-    called from within a callback function registered with
-    ProgramCallbackMESA.
-
-    <registerName> and <len> specify the name a variable, input
-    attribute, temporary, or result register in the program string.
-    The current value of the named variable is returned as four
-    values in <v>.  If <name> doesn't exist in the program string,
-    the error INVALID_OPERATION is generated.
-
-Additions to Appendix A of the OpenGL 1.4 Specification (Invariance)
-
-    None.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None.
-
-GLX Protocol
-
-    XXX TBD
-
-Dependencies on NV_vertex_program and NV_fragment_program
-
-    If NV_vertex_program and/or NV_fragment_program are supported,
-    vertex and/or fragment programs defined by those extensions may
-    be debugged as well.  Register queries will use the syntax used
-    by those extensions (i.e. "v[X]" to query vertex attributes,
-    "o[X]" for vertex outputs, etc.)
-
-Errors
-
-    INVALID_OPERATION is generated if ProgramCallbackMESA is called
-    between Begin and End.
-
-    INVALID_ENUM is generated by ProgramCallbackMESA if <target> is not
-    a supported vertex or fragment program type.
-
-    Note: INVALID_OPERAION IS NOT generated by GetProgramRegisterfvMESA,
-    GetBooleanv, GetDoublev, GetFloatv, or GetIntegerv if called between
-    Begin and End when a vertex or fragment program is currently executing.
-
-    INVALID_ENUM is generated by ProgramCallbackMESA,
-    GetProgramRegisterfvMESA if <target> is not a program target supported
-    by ARB_vertex_program, ARB_fragment_program (or NV_vertex_program or
-    NV_fragment_program).
-
-    INVALID_VALUE is generated by GetProgramRegisterfvMESA if <registerName>
-    does not name a known program register or variable.
-
-    INVALID_OPERATION is generated by GetProgramRegisterfvMESA when a
-    register query is attempted for a program target that's not currently
-    being executed.
-
-
-New State
-
-    XXX finish
-
-(table 6.N, p. ###)
-                                                            Initial
-    Get Value                            Type Get Command   Value    Description  Sec.  Attribute
-    ---------                            ---- -----------   -----    -----------  ----  ---------
-    FRAGMENT_PROGRAM_CALLBACK_MESA        B   IsEnabled     FALSE    XXX          XXX   enable
-    VERTEX_PROGRAM_CALLBACK_MESA          B   IsEnabled     FALSE    XXX          XXX   enable
-    FRAGMENT_PROGRAM_POSITION_MESA        Z+  GetIntegerv   -1       XXX          XXX   -
-    VERTEX_PROGRAM_POSITION_MESA          Z+  GetIntegerv   -1       XXX          XXX   -
-    FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA   P   GetPointerv   NULL     XXX          XXX   -
-    VERTEX_PROGRAM_CALLBACK_FUNC_MESA     P   GetPointerv   NULL     XXX          XXX   -
-    FRAGMENT_PROGRAM_CALLBACK_DATA_MESA   P   GetPointerv   NULL     XXX          XXX   -
-    VERTEX_PROGRAM_CALLBACK_DATA_MESA     P   GetPointerv   NULL     XXX          XXX   -
-
-    XXX more?
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-    8 July 2003
-        Initial draft. (Brian Paul)
-    11 July 2003
-        Second draft. (Brian Paul)
-    20 July 2003
-        Third draft.  Lots of fundamental changes. (Brian Paul)
-    23 July 2003
-        Added chapter 5 and 6 spec language. (Brian Paul)
-
-Example Usage
-
-   The following is a very simple example of how this extension may
-   be used to print the values of R0, R1, R2 and R3 while executing
-   vertex programs.
-
-
-    /* This is called by the GL when the vertex program is executing.
-     * We can only make glGet* calls from within this function!
-     */
-    void DebugCallback(GLenum target, GLvoid *data)
-    {
-       GLint pos;
-       GLuint i;
-
-       /* Get PC and current instruction string */
-       glGetIntegerv(GL_VERTEX_PROGRAM_POSITION_ARB, &pos);
-
-       printf("Current position: %d\n", pos);
-
-       printf("Current temporary registers:\n");
-       for (i = 0; i < 4; i++) {
-	  GLfloat v[4];
-	  char s[10];
-	  sprintf(s, "R%d", i);
-	  glGetProgramRegisterfvMESA(GL_VERTEX_PROGRAM_ARB, strlen(s), s, v);
-	  printf("R%d = %g, %g, %g, %g\n", i, v[0], v[1], v[2], v[3]);
-       }
-    }
-
-
-    /*
-     * elsewhere...
-     */
-
-    /* Register our debugger callback function */
-    glProgramCallbackMESA(GL_VERTEX_PROGRAM_ARB, DebugCallback, NULL);
-    glEnable(GL_VERTEX_PROGRAM_CALLBACK_MESA);
-
-    /* define/bind a vertex program */
-
-    glEnable(GL_VERTEX_PROGRAM);
-
-    /* render something */
-    glBegin(GL_POINTS);
-    glVertex2f(0, 0);
-    glEnd();
-

docs/OLD/MESA_sprite_point.spec

@@ -1,190 +0,0 @@
-Name
-
-    MESA_sprite_point
-
-Name Strings
-
-    GL_MESA_sprite_point
-
-Contact
-
-    Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com)
-
-Status
-
-    Obsolete - see GL_ARB_point_sprite.
-
-Version
-
-
-Number
-
-    ???
-
-Dependencies
-
-    GL_EXT_point_parameters effects the definition of this extension
-    GL_ARB_multitexture effects the definition of this extension
-
-Overview
-	
-    This extension modifies the way in which points are rendered,
-    specifically when they're textured.  When SPRITE_POINT_MESA is enabled
-    a point is rendered as if it were a quadrilateral with unique texture
-    coordinates at each vertex.  This extension effectively turns points
-    into sprites which may be rendered more easily and quickly than using
-    conventional textured quadrilaterals.
-
-    When using point size > 1 or attenuated points this extension is an
-    effective way to render many small sprite images for particle systems
-    or other effects.
-
-Issues:
-
-    1. How are the texture coordinates computed?
-
-       The lower-left corner has texture coordinate (0,0,r,q).
-       The lower-right, (1,0,r,q).  The upper-right, (1,1,r,q).
-       The upper-left, (0,1,r,q).
-
-    2. What about texgen and texture matrices?
-
-       Texgen and the texture matrix have no effect on the point's s and t
-       texture coordinates.  The r and q coordinates may have been computed
-       by texgen or the texture matrix.  Note that with a 3D texture and/or
-       texgen that the r coordinate could be used to select a slice in the
-       3D texture.
-
-    3. What about point smoothing?
-
-       When point smoothing is enabled, a triangle fan could be rendered
-       to approximate a circular point.  This could be problematic to
-       define and implement so POINT_SMOOTH is ignored when drawing sprite
-       points.
-
-       Smoothed points can be approximated by using an appropriate texture
-       images, alpha testing and blending.
-
-       POLYGON_SMOOTH does effect the rendering of the quadrilateral, however.
-
-    4. What about sprite rotation?
-
-       There is none.  Sprite points are always rendered as window-aligned
-       squares.  One could define rotated texture images if desired.  A 3D
-       texture and appropriate texture r coordinates could be used to
-       effectively specify image rotation per point.
-
-    5. What about POLYGON_MODE?
-
-       POLYGON_MODE does not effect the rasterization of the quadrilateral.
-
-    6. What about POLYGON_CULL?
-
-       TBD.  Polygon culling is normally specified and implemented in the
-       transformation stage of OpenGL.  However, some rasterization hardware
-       implements it later during triangle setup.
-
-       Polygon culling wouldn't be useful for sprite points since the
-       quadrilaterals are always defined in counter-clockwise order in
-       window space.  For that reason, polygon culling should probably be
-       ignored.
-
-    7. Should sprite points be alpha-attenuated if their size is below the
-       point parameter's threshold size?
-
-    8. Should there be an advertisized maximum sprite point size?
-
-       No.  Since we're rendering the point as a quadrilateral there's no
-       need to limit the size.
-
-
-New Procedures and Functions
-
-    None.
-
-New Tokens
-    
-    Accepted by the <pname> parameter of Enable, Disable, IsEnabled,
-    GetIntegerv, GetBooleanv, GetFloatv and GetDoublev:
-
-	SPRITE_POINT_MESA		0x????
-        MAX_SPRITE_POINT_SIZE_MESA      0x????   (need this?)
-
-Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation)
-
-    None
-
-Additions to Chapter 3 of the 1.1 Specification (Rasterization)
-
-    Section ???.
-
-    When SPRITE_POINT_MESA is enabled points are rasterized as screen-
-    aligned quadrilaterals.  If the four vertices of the quadrilateral
-    are labeled A, B, C, and D, starting at the lower-left corner and moving
-    counter-clockwise around the quadrilateral, then the vertex and
-    texture coordinates are computed as follows:
-
-      vertex   window coordinate       texture coordinate
-        A      (x-r, y-r, z, w)          (0, 0, r, q)
-        B      (x+r, y-r, z, w)          (1, 0, r, q)
-        C      (x+r, y+r, z, w)          (1, 1, r, q)
-        D      (x-r, y+r, z, w)          (0, 1, r, q)
-
-    where x, y, z, w are the point's window coordinates, r and q are the
-    point's 3rd and 4th texture coordinates  and r is half the point's
-    size.  The other vertex attributes (such as the color and fog coordinate)
-    are simply duplicated from the original point vertex.
-
-    Point size may either be specified with PointSize or computed
-    according to the EXT_point_parameters extension.
-
-    The new texture coordinates are not effected by texgen or the texture
-    matrix.  Note, however, that the texture r and q coordinates are passed
-    unchanged and may have been computed with texgen and/or the texture
-    matrix.
-
-    If multiple texture units are present the same texture coordinate is
-    used for all texture units.
-
-    The point is then rendered as if it were a quadrilateral using the
-    normal point sampling rules.  POLYGON_MODE does not effect the
-    rasterization of the quadrilateral but POLYGON_SMOOTH does.
-
-    POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled.
-
-Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations
-and the Frame Buffer)
-
-    None.
-
-Additions to Chapter 5 of the 1.1 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the 1.1 Specification (State and State Requests)
-
-    None
-
-Additions to the GLX Specification
-
-    None
-
-GLX Protocol
-
-    TBD
-
-Errors
-
-    None
-
-New State
-
-    Add boolean variable SPRITE_POINT_MESA to the point attribute group.
-
-Revision History
-
-    Version 1.0 - 4 Dec 2000
-        Original draft.
-
-
-

docs/OLD/MESA_trace.spec

@@ -1,359 +0,0 @@
-Name
-
-     MESA_trace
-
-Name Strings
-
-     GL_MESA_trace
-
-Contact
-    
-    Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com
-    Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com
-
-Status
-
-    Obsolete.
-
-Version
-
-
-Number
-
-    none yet
-
-Dependencies
-
-    OpenGL 1.2 is required.
-    The extension is written against the OpenGL 1.2 Specification
-
-Overview
-
-    Provides the application with means to enable and disable logging
-    of GL calls including parameters as readable text. The verbosity
-    of the generated log can be controlled. The resulting logs are
-    valid (but possibly incomplete) C code and can be compiled and 
-    linked for standalone test programs. The set of calls and the 
-    amount of static data that is logged can be controlled at runtime. 
-    The application can add comments and enable or disable tracing of GL 
-    operations at any time. The data flow from the application to GL
-    and back is unaffected except for timing.
-
-    Application-side implementation of these features raises namespace
-    and linkage issues. In the driver dispatch table a simple
-    "chain of responsibility" pattern (aka "composable piepline")
-    can be added.
-
-IP Status
-
-    The extension spec is in the public domain.  The current implementation
-    in Mesa is covered by Mesa's XFree86-style copyright by the authors above.
-    This extension is partially inspired by the Quake2 QGL wrapper.
-
-Issues
-
- 
-    (1) Is this Extension obsolete because it can
-    be implemented as a wrapper DLL?
-
-      RESOLVED: No. While certain operating systems (Win32) provide linkers 
-      that facilitate this kind of solution, other operating systems
-      (Linux) do not support hierarchical linking, so a wrapper solution
-      would result in symbol collisions.
-      Further, IHV's might have builtin support for tracing GL execution 
-      that enjoys privileged access, or that they do not wish to separate
-      the tracing code from their driver code base.
-
-    (2) Should the Trace API explicitely support the notion of "frames? 
-    This would require hooking into glXSwapBuffers calls as well.
-
-      RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
-      and TraceComment along with external parsing tools to split the 
-      trace into frames, in whatever way considered adequate.
-
-    (2a) Should GLX calls be traced?
-
-      PBuffers and other render-to-texture solutions demonstrate that
-      context level commands beyond SwapBuffers might have to be
-      traced. The GL DLL exports the entry points, so this would not
-      be out of the question. 
-
-    (3) Should the specification mandate the actual output format?
-
-      RESOLVED: No. It is sufficient to guarantee that all data and commands 
-      will be traced as requested by Enable/DisableTraceMESA, in the order
-      encountered. Whether the resulting trace is available as a readable 
-      text file, binary metafile, compilable source code, much less which 
-      indentation and formatting has been used, is up to the implementation. 
-      For the same reason this specification does not enforce or prohibit
-      additional information added to the trace (statistics, profiling/timing, 
-      warnings on possible error conditions).
-
-    (4) Should the comment strings associated with names and pointer (ranges) 
-    be considered persistent state?
-
-      RESOLVED: No. The implementation is not forced to use this information 
-      on subsequent occurences of name/pointer, and is free to consider it 
-      transient state.
- 
-    (5) Should comment commands be prohibited between Begin/End?
-
-      RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA 
-      is transient, the other commands might cause storage of persistent
-      data in the context. There is no need to have the ability mark names 
-      or pointers between Begin and End.
-
-
-New Procedures and Functions
- 
-    void NewTraceMESA( bitfield mask, const ubyte * traceName )
-
-    void EndTraceMESA( void )
-
-    void EnableTraceMESA( bitfield mask )
-
-    void DisableTraceMESA( bitfield mask )
-
-    void TraceAssertAttribMESA( bitfield attribMask )
-
-    void TraceCommentMESA( const ubyte* comment )
-
-    void TraceTextureMESA( uint name, const ubyte* comment )
-
-    void TraceListMESA( uint name, const ubyte* comment )
-
-    void TracePointerMESA( void* pointer, const ubyte* comment )
-
-    void TracePointerRangeMESA( const void* first, 
-                                const void* last, 
-                                const ubyte* comment ) 
-
-New Tokens
- 
-    Accepted by the <mask> parameter of EnableTrace and DisableTrace:
-
-       TRACE_ALL_BITS_MESA           0xFFFF
-       TRACE_OPERATIONS_BIT_MESA     0x0001
-       TRACE_PRIMITIVES_BIT_MESA     0x0002
-       TRACE_ARRAYS_BIT_MESA         0x0004
-       TRACE_TEXTURES_BIT_MESA       0x0008
-       TRACE_PIXELS_BIT_MESA         0x0010
-       TRACE_ERRORS_BIT_MESA         0x0020
-
-    Accepted by the <pname> parameter of GetIntegerv, GetBooleanv,
-    GetFloatv, and GetDoublev:
-
-       TRACE_MASK_MESA               0x8755
-
-    Accepted by the <pname> parameter to GetString:
-
-       TRACE_NAME_MESA               0x8756
-
-
-Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation)
-
-    None.
-
-Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
-
-    Add a new section:
-
-    5.7 Tracing
-
-    The tracing facility is used to record the execution of a GL program
-    to a human-readable log.  The log appears as a sequence of GL commands
-    using C syntax.  The primary intention of tracing is to aid in program
-    debugging.
-
-    A trace is started with the command
-
-      void NewTraceMESA( bitfield mask, const GLubyte * traceName )
-
-    <mask> may be any value accepted by PushAttrib and specifies a set of
-    attribute groups.  The state values included in those attribute groups
-    is written to the trace as a sequence of GL commands.
-
-    <traceName> specifies a name or label for the trace.  It is expected
-    that <traceName> will be interpreted as a filename in most implementations.
-
-    A trace is ended by calling the command
-
-      void EndTraceMESA( void )
-
-    It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End. 
-
-    The commands
-
-      void EnableTraceMESA( bitfield mask )
-      void DisableTraceMESA( bitfield mask )
-
-    enable or disable tracing of different classes of GL commands.
-    <mask> may be the union of any of TRACE_OPERATIONS_BIT_MESA,
-    TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA,
-    and TRACE_PIXELS_BIT_MESA.  The special token TRACE_ALL_BITS_MESA
-    indicates all classes of commands are to be logged.
-
-    TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of
-    Begin/End, including Begin/End.
-  
-    TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of
-    Begin/End, including Begin/End.
- 
-    TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer,
-    ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands.
-
-    TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by
-    TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and
-    TexSubImage3D commands.
-
-    TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by
-    Bitmap and DrawPixels commands.
-
-    TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is 
-    set, GetError will be executed whereever applicable, and the result will 
-    be added to the trace as a comment. The error returns are cached and 
-    returned to the application on its GetError calls. If the user does not 
-    wish the additional GetError calls to be performed, this bit should not
-    be set.
-    
-    The command
-
-      void TraceCommentMESA( const ubyte* comment )
-
-    immediately adds the <comment> string to the trace output, surrounded
-    by C-style comment delimiters.
-
-    The commands
-
-      void TraceTextureMESA( uint name, const ubyte* comment )
-      void TraceListMESA( uint name, const ubyte* comment )
-
-    associates <comment> with the texture object or display list specified
-    by <name>.  Logged commands which reference the named texture object or
-    display list will be annotated with <comment>.  If IsTexture(name) or
-    IsList(name) fail (respectively) the command is quietly ignored.
-
-    The commands
-
-      void TracePointerMESA( void* pointer, const ubyte* comment )
-
-      void TracePointerRangeMESA( const void* first, 
-                                  const void* last,
-                                  const ubyte* comment ) 
-
-    associate <comment> with the address specified by <pointer> or with
-    a range of addresses specified by <first> through <last>.
-    Any logged commands which reference <pointer> or an address between
-    <first> and <last> will be annotated with <comment>.
-
-    The command
-
-      void TraceAssertAttribMESA( bitfield attribMask )
-
-    will add GL state queries and assertion statements to the log to
-    confirm that the current state at the time TraceAssertAttrib is
-    executed matches the current state when the trace log is executed
-    in the future.
-
-    <attribMask> is any value accepted by PushAttrib and specifies
-    the groups of state variables which are to be asserted.
-
-    The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA,
-    TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA, 
-    TracePointerMESA and TracePointerRangeMESA are not compiled into display lists.
-
-
-    Examples:
-
-    The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state
-    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
-    to get the values <test>, <func>, <mask>, and <clear> respectively.
-    Statements equivalent to the following will then be logged:
-
-       glEnable(GL_DEPTH_TEST);   (if <test> is true)
-       glDisable(GL_DEPTH_TEST);  (if <test> is false)
-       glDepthFunc(<func>); 
-       glDepthMask(<mask>);
-       glClearDepth(<clear>);
-   
-
-    The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state
-    variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE
-    to get the values <test>, <func>, <mask>, and <clear> respectively.
-    The resulting trace might then look will like this:
-
-    {
-      GLboolean b;
-      GLint i;
-      GLfloat f;
-      b = glIsEnabled(GL_DEPTH_TEST);
-      assert(b == <test>);
-      glGetIntegerv(GL_DEPTH_FUNC, &i);
-      assert(i == <func>);
-      glGetIntegerv(GL_DEPTH_MASK, &i);
-      assert(i == <mask>);
-      glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f);
-      assert(f == <clear>);
-    }
-
-
-Additions to Chapter 6 of the OpenGL 1.2.1 Specification 
-    (State and State Requests)
-
-    Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or
-    GetDoublev returns the current command class trace mask.
-
-    Querying TRACE_NAME_MESA with GetString returns the current trace name.
-
-
-Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance)
-
-    The MESA_trace extension can be used in a way that does not affect data 
-    flow from application to OpenGL, as well as data flow from OpenGL to 
-    application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA
-    will add additional GetError queries. Setting a trace mask with NewTraceMESA
-    as well as use of TraceAssertAttribMESA might cause additional state queries.
-    With the possible exception of performance, OpenGL rendering should not be
-    affected at all by a properly chosen logging operation.
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None.
-
-GLX Protocol
-
-    None. The logging operation is carried out client-side, by exporting
-    entry points to the wrapper functions that execute the logging operation.
-
-Errors
-
-    INVALID_OPERATION is generated if any trace command except TraceCommentMESA
-    is called between Begin and End.
-
-New State
-
-    The current trace name and current command class mask are stored
-    per-context.
-
-New Implementation Dependent State
-
-    None.
-
-Revision History
-
-  * Revision 0.1 - Initial draft from template (bk000415)
-  * Revision 0.2 - Draft (bk000906)
-  * Revision 0.3 - Draft (bk000913)
-  * Revision 0.4 - Reworked text, fixed typos (bp000914)
-  * Revision 0.5 - Assigned final GLenum values (bp001103)
-  * Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916)
-  * Revision 0.7 - Added MESA postfix (bk010126)
-

docs/README.3DFX

@@ -0,0 +1,596 @@
+
+                     3Dfx Glide device driver for Mesa 3.1
+				(see below for FAQ)
+
+
+This software is distributed under the terms of the GNU Library
+General Public License, see the LICENSE file for details.
+
+
+
+What do you need ?
+------------------
+
+	- A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board
+	  (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.).
+	  The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+	  under Linux (more information in the "Useful Glide Environment
+	  Variables");
+
+	- Mesa 3.1;
+
+	- The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
+	  The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not
+	  compatible with the Glide 2.x so it doesn't work with the current
+	  version of the driver;
+
+	- A compiler supported by the Glide library (Micro$oft VC++ (tested),
+	  Watcom (tested), GCC for Linux (tested), etc.);
+
+	- A lot of patience, this is an alpha release.
+
+	- It's nice to have two monitors - one for your normal graphics
+	  card and one for your 3Dfx card. If something goes wrong with
+	  an application using the 3Dfx hardware you can still see your
+	  normal screen in order to recover.
+
+
+
+Tested on:
+----------
+	Windows 95 - David Bucciarelli
+	Windows NT - Henri Fousse
+	MS-DOS
+	Linux - Daryll Strauss, Brian Paul, David Bucciarelli
+	FreeBSD
+	BeOS - Duncan Wilcox
+	MacOS - Fazekas Miklos
+
+
+What is able to do ?
+--------------------
+
+	- It is able accelerate points, lines and polygon with flat
+	  shading, gouraud shading, Z-buffer, texture mapping, blending, fog and
+	  antialiasing (when possible). There is also the support for rendering
+	  in a window with a slow trick for the Voodoo Graphics (available only
+	  for Linux) and at full speed with the Voodoo Rush chipset.
+	  Under Linux is also possible to switch on-the-fly between the fullscreen
+	  and in-window rendering hack.
+	  There is also the support for using more than one Voodoo Graphics in the
+	  some application/PC (you can create one context for each board and use
+	  multiple video outputs for driving monitors, videoprojectors or HMDs).
+	  The driver is able to fallback to pure software rendering when afeature
+	  isn't supported by the Voodoo hardware (however software rendering is
+	  very slow compared to hardware supported rendering)
+
+
+
+How to compile:
+---------------
+
+Linux:
+------
+	Here are the basic steps for using the 3Dfx hardware with Mesa
+	on Linux:
+
+	- You'll need the Glide library and headers.  Mesa expects:
+		/usr/local/glide/include/*.h        // all the Glide headers
+		/usr/local/glide/lib/libglide2x.so
+
+	  If your Glide libraries and headers are in a different directory
+	  you'll have to modify the Mesa-config and mklib.glide files.
+
+	- Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives;
+
+	- If you're going to use a newer Mesa/Glide driver than v0.27 then
+          unpack the new driver archive over the Mesa directory.
+
+	- In the Mesa-3.1 directory type "make linux-glide"
+
+	- Compilation _should_ finish without errors;
+
+	- Set your LD_LIBRARY_PATH environment variable so that the
+	  libglide2x.so and Mesa library files can be found.  For example:
+	    setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib"
+
+	- You'll have to run Glide-based programs as root or set the suid
+	  bit on executables;
+
+	- Try a demo:
+	    cd gdemos
+	    su
+	    setenv MESA_GLX_FX f
+	    ./gears     (hit ESC to exit)
+
+	- You can find the demos especially designed for the Voodoo driver in
+	  in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile
+	  everything).
+
+MacOS:
+------
+	Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html
+      
+MS Windows:
+-----------
+
+	For the MSVC++:
+	- The glide2x.lib have to be in the default MSVC++ lib directory;
+
+	- The Glide headers have to be in the default MSVC++ include directory;
+
+	- You must have the vcvars32.bat script in your PATH;
+
+	- Go to the directory Mesa-3.1 and run the mesafx.bat;
+
+	- The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll},
+	  Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and
+          Voodoo demos);
+
+	- At the end, you will be in the Mesa-3.1/3Dfx/demos directory;
+
+	- Try some demo (fire.exe, teapot.exe, etc.) in order to check if
+	  everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between
+	  the Voodoo screen and the windows desktop);
+
+	- Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the
+          some directory were you run your Mesa based applications.
+
+	- I think that you can easy change the Makefile.fx files in order
+	  to work with other kind of compilers;
+
+	- To discover how open the 3Dfx screen, read the sources under
+	  the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or
+          the Diego Picciani's wgl emulator.
+
+	NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the
+	SP3, you could have some problem (you can disable optimization in order
+	solve these kind of problems).
+
+
+Doing more with Mesa & Linux Glide:
+-----------------------------------
+
+	The MESA_GLX_FX environment variable can be used to coax most
+	GLX-based programs into using Glide (and the __GLUT library
+	is GLX-based__).
+
+        Full-screen 3Dfx rendering:
+        ---------------------------
+
+	1. Set the MESA_GLX_FX variable to "fullscreen":
+
+		ksh:
+			export MESA_GLX_FX = "fullscreen"
+		csh:
+			setenv MESA_GLX_FX fullscreen
+
+	2. As root, run a GLX-based program (any GLUT demo on Linux).
+	
+	3. Be careful:  once the 3Dfx screen appears you won't be able
+	to see the GLUT windows on your X display.  This can make using
+	the mouse tricky!  One solution is to hook up your 3Dfx card to
+	a second monitor.  If you can do this then set these env vars
+	first:
+
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN
+	
+	or for the Voodoo2:
+
+		setenv SSTV2_VGA_PASS 1
+		setenv SSTV2_NOSHUTDOWN
+
+        Rendering into an X window with the help of the Voodoo hardware:
+        ----------------------------------------------------------------
+
+	1. Start your X server in 16 bpp mode (XFree86:  startx -- -bpp 16)
+	   in order to have the best performance and the best visual
+	   quality. However you can use any visual depth supported by X.
+
+	2. Set the following environment variables:
+		export MESA_GLX_FX="window"	// to enable window rendering
+		export SST_VGA_PASS=1	// to stop video signal switching
+		export SST_NOSHUTDOWN=1	// to stop video signal switching
+	    OR
+		setenv MESA_GLX_FX window
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN 1
+
+	(the Voodoo2 requires to use "SSTV2_" instead "SST_").
+
+	3. As root, try running a GLX-based program
+
+	How does it work?  We use the 3Dfx hardware to do rendering then
+	copy the image from the 3Dfx frame buffer into an X window when
+	the SwapBuffers() function is called.  The problem with this
+	idea is it's slow.  The image must be copied from the 3Dfx frame
+	buffer to main memory then copied into the X window (and when the X
+	visual depth doesn't match the Voodoo framebufffer bit per pixel, it
+	is required also a pixel format translation).
+
+        On the fly switching between in window rendering and full screen rendering
+	--------------------------------------------------------------------------
+
+	The Mesa 2.6 has introduced the capability of switching
+	on-the-fly between the fullscreen/fullspeed rendering and the in-window
+	hack and vice versa. The on-the-fly switching requires a direct support
+	by the application but it is really easy to add. You have to start
+	your X server in 16 bpp mode and to add the following lines to your
+	application:
+
+		#if defined(FX) && define(XMESA)
+		#include <GL/xmesa.h>
+
+		static int fullscreen=1;
+		#endif
+
+		...
+
+		/* In the GLUT keyboard event callback */
+
+		#if defined(FX) && !define(WIN32)
+		  case ' ':
+		    fullscreen=(!fullscreen);
+		    XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW);
+		    break;
+		#endif
+		...
+
+       	See the 3Dfx/demos/tunnel.c program
+       	for an example.  You have to set the -DXMESA flag in the Makefile's COPTS
+       	to enable it.
+
+  	Rendering into an X window with the X11 software driver:
+        --------------------------------------------------------
+
+	Set the MESA_GLX_FX variable to "disable" your GLX-based program will use
+	the X11 software driver (the 3Dfx hardware isn't used at all).
+
+
+
+Useful Glide Environment Variables:
+-----------------------------------
+
+	- To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable.
+
+	- To disable video signal switching:
+		setenv SST_VGA_PASS 1
+		setenv SST_NOSHUTDOWN
+	  or for the Voodoo2:
+		setenv SSTV2_VGA_PASS 1
+		setenv SSTV2_NOSHUTDOWN
+
+        - To set the default screen refresh rate:
+                setenv SST_SCREENREFRESH=75
+
+          the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120.
+
+	- To force the Mesa library to swap buffers as fast as possible,
+	  without any vertical blanking synchronization (useful for benchmarks):
+		setenv FX_GLIDE_SWAPINTERVAL 0
+                setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0
+
+	- You can slight improve the performances of your Voodoo1 board with
+	  the following env. var.:
+		setenv SST_FASTMEM 1
+		setenv SST_PCIRD 1
+		setenv SST_GRXCLK 57
+
+	  (don't use this setting with the Quantum3D 100SB or with any other
+	  SLI configuration: it will hang everything !).
+	  The following setting can be used with the Voodoo2:
+		setenv SSTV2_FASTMEM_RAS_READS=1
+		setenv SSTV2_FASTPCIRD=1
+		setenv SSTV2_GRXCLK=95
+
+	- The Quantum3D Obsidian3D-2 X-24 requires some special env. setting
+	  in order to work under Linux:
+
+		export SSTV2_FT_CLKDEL=5
+		export SSTV2_TF0_CLKDEL=7
+		export SSTV2_TF1_CLKDEL=7
+		export SSTV2_TF2_CLKDEL=7
+		export SSTV2_SLIM_VIN_CLKDEL=3
+		export SSTV2_SLIM_VOUT_CLKDEL=2
+		export SSTV2_SLIS_VIN_CLKDEL=3
+		export SSTV2_SLIS_VOUT_CLKDEL=2
+
+	  (Thanks to Phil Ross for this trick).
+
+
+
+
+The Mesa/Voodoo Environment Variables:
+--------------------------------------
+
+	- Only for Windows/Voodoo Rush users, if you define the
+	  env. var. MESA_WGL_FX:
+		export MESA_WGL_FX=fullscreen
+	  you will get fullscreen rendering;
+
+	- Only for Windows/Voodoo Rush users, if you define the
+	  env. var. MESA_WGL_FX:
+		export MESA_WGL_FX=window
+	  you will get window rendering (default value);
+
+	- Only for Linux users, you can find more informations about
+	  the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide"
+	  section;
+
+	- If you define the env. var. MESA_FX_SWAP_PENDING:
+		export MESA_FX_SWAP_PENDING=4
+	  you will able to set the maximum number of swapbuffers
+	  commands in the Voodoo FIFO after a swapbuffer (default value: 2);
+
+        - If you define the env. var. MESA_FX_INFO:
+		export MESA_FX_INFO=1
+          you will get some useful statistic.
+
+
+Know BUGS and Problems:
+-----------------------
+
+	- fog doesn't work in the right way when using the glDepthRange() function;
+
+	- Maximum texture size: 256x256 (this is an hardware limit);
+
+	- Texture border aren't yet supported;
+
+	- A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit);
+
+        - Use the glBindTexture extension (standard in OpenGL 1.1) for texture
+	  mapping (the old way: glTexImage inside a display list, download
+	  the texture map each time that you call the display list !!!);
+
+	- Stencil buffer and Accumulation buffer are emulated in software (they are not
+	  directly supported by the Hardware);
+
+	- Color index mode not implemented (this is an hardware limit);
+
+	- Thre is an know bug in the Linux Glide library so the in-window-rendering hack
+	  and any other operations that requires to read the Voodoo frame buffer
+	  (like the accumulation buffer support) doesn't work on Voodoo SLI cards.
+
+	- The driver switch to pure software (_slow_) rendering when:
+
+		- Stencil enabled;
+		- Using the Accumulation buffer;
+		- Blend enabled and blend equation != GL_FUNC_ADD_EXT;
+		- Color logic operation enabled and color logic operation != GL_COPY;
+		- Using GL_SEPARATE_SPECULAR_COLOR;
+		- The four values of glColorMask() aren't the some;
+		- Texture 1D or 3D enabled;
+		- Texture function is GL_BLEND;
+		- Using the Multitexture extension with Voodoo cards with only one TMU;
+		- Using the Multitexture extension with Voodoo cards with more than
+		   one TMU, and texture function isn't GL_MODULATE;
+		- Point size is != 1.0 or point params vector != (1.0,0.0,0.0);
+		- Line width != 1.0 or using stipple lines.
+		- Using polygon offset or stipple polygons;
+
+	NOTE: this is list is not yet complete.
+		
+
+Hints and Special Features:
+---------------------------
+
+	- Under Linux and with a Voodoo Graphics board, you can use
+	  XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to
+	  switch on the fly between fullscreen rendering and the in-window-rendering
+	  hack.
+
+	- The driver is able to use all the texture memory available: 2/4MB on
+	  Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards.
+
+	- Trilinear filtering is fully supported on Voodoo boards with two TMUs
+	  (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is
+	  available the driver fallback to bilinear filter also if you ask
+	  for trilinear filtering.
+
+        - The Voodoo driver support multiple Voodoo Graphics boards in the
+          some PC. Using this feature, you can write applications that use
+          multiple monitors, videoprojectors or HMDs for the output. See
+	  Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one
+          context for each board.
+
+	- The v0.19 introduces a new powerful texture memory manager: the
+	  texture memory is used as a cache of the set of all defined texture
+	  maps. You can now define several MBs of texture maps also with a 2MB
+	  of texture memory (the texture memory manager will do automatically
+	  all the swap out/swap in
+	  texture memory work). The new texture memory manager has also
+	  solved a lot of other bugs/no specs compliance/problems
+	  related to the texture memory usage.
+
+	- Use triangles and quads strip: they are a LOT faster than sparse
+	  triangles and quads.
+
+	- The Voodoo driver supports the GL_EXT_paletted_texture. it works
+	  only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value
+	  is ignored because this is a limitation of the the current Glide
+	  version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for
+	  a demo of this extension.
+
+	- The Voodoo driver directly supports 3Dfx Global Palette extension.
+	  It was written for GLQuake and I think that it isn't a good idea
+	  to use this extension for any other purpose (it is a trick). See
+	  Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension.
+
+	- The Voodoo driver chooses the screen resolution according to the
+	  requested window size. If you open a 640x480 window, you will get
+	  a 640x480 screen resolution, if you open a 800x600 window, you
+	  will get a 800x600 screen resolution, etc.
+	  Most GLUT demos support the '-geometry' option, so you can choose
+	  the screen resolution: 'tunnel -geometry 800x600'.
+	  Clearly, you Voodoo board must have enough framebuffer RAM (otherwise
+	  the window creation will fail).
+
+	- The glGetString(GL_RENDERER) returns more information
+          about the hardware configuration: "Mesa Glide <version>
+          <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/
+          <num> TM/<num> TMU/<NOSLI|SLI>"
+          where: <num> CARD is the card used for the current context,
+          <num> FB is the number of MB for the framebuffer,
+          <num> TM is the number of MB for the texture memory,
+          <num> TMU is the number of TMU. You can try to run
+          Mesa/demos/glinfo in order to have an example of the output.
+
+Did you find a lot BUGs and problems ? Good, send me an email.
+
+
+
+FAQ:
+----
+
+For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO
+available at http://www.gamers.org/dEngine/xf3D (it includes also
+a lot of informations not strictly related to Linux, so it can be
+useful also if you don't use Linux)
+
+1. What is 3Dfx?
+
+3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics
+chipset (and others) used in popular PC cards such as the Diamond Monster 3D
+and the Orchid Righteous 3D (more informations at http://www.3dfx.com).
+
+
+2. What is Glide?
+
+Glide is a "thin" programming interface for the 3Dfx hardware.  It was
+originally written for Windows/Intel but has been ported to Linux/Intel
+by Daryll Strauss.
+
+3Dfx, Inc. should be applauded for allowing the Linux version of Glide
+to be written.
+
+You can directly program with the Glide library if you wish.  You can
+obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com
+There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux
+
+
+3. What is fxmesa?
+
+"fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library.
+It was written by David Bucciarelli and others.  It works on both Linux
+and Windows.  Basically, it allows you to write and run OpenGL-style programs
+on the 3Dfx hardware.
+
+
+4. What is GLQuake?
+
+Quake is a very popular game from id software, Inc.  See www.idsoftware.com
+GLQuake is a version of Quake written for OpenGL.  There is now a Linux
+version of GLQuake with works with the Mesa/3Dfx/Glide combo.
+
+Here's what you need to run GLQuake on Linux:
+   PC with 100MHz Pentium or better
+   a 3Dfx-based card
+   Mesa 3.1 libraries:  libMesaGL.so  libMesaGLU.so
+   Glide 2.4 libraries:  libglide2x.so  libtexus.so
+   GLQuake for Linux.
+
+Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll,
+you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory
+in order to test 'MesaQuake'.
+
+
+5. What is GLUT?
+
+GLUT is Mark Kilgard's OpenGL Utility Toolkit.  It provides an API for
+writing portable OpenGL programs with support for multiple windows, pop-
+up menus, event handling, etc.
+
+Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd).
+
+Every OpenGL programmer should check out GLUT.
+
+GLUT on Linux uses GLX.
+
+
+6. What is GLX?
+
+GLX is the OpenGL extension to the X Window System.  I defines both a
+programming API (glX*() functions) and a network protocol.  Mesa implements
+an emulation of GLX on Linux.  A real GLX implementation would requires
+hooks into the X server.  The 3Dfx hardware can be used with GLX-based
+programs via the MESA_GLX_FX environment variable.
+
+
+7. Is the Voodoo driver able to use the 4Mb texture memory of
+the Pure3D boards ?
+
+Yes, the Voodoo driver v0.20 includes the support for Voodoo
+Graphics boards with more than 2Mb of texture memory.
+
+
+8. Do the Voodoo driver support the Voodoo Rush under Windows ?
+
+Yes, Diego Picciani has developed the support for the Voodoo
+Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul
+has a Monster3D, so the new versions of the Mesa/Voodoo sometime are
+not tested with the Voodoo Rush.
+
+
+9. Do the Voodoo driver support the Voodoo Rush under Linux ?
+
+No because the Linux Glide doesn't (yet) support the Voodoo Rush.
+
+
+10. Can I sell my Mesa/Voodoo based software and include
+a binary copy of the Mesa in order to make the software
+working out of the box ?
+
+Yes, you have simply to include some informations about authors
+and where the library sources are available (check the LICENSE
+file for more informations about the GNU GPL).
+
+
+11. Which is the best make target for compiling the Mesa for
+Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ?
+
+'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide'
+for Voodoo2 boards because it doesn't include the '-fPIC'
+option (4-5% faster).
+
+
+12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide'
+for my applications/programs/demos ?
+
+Yes, there is only one constrain: you can't run two Mesa applications
+at the some time. This isn't a big issue with the today Voodoo Graphics.
+
+
+Thanks to:
+----------
+
+Henri Fousse       (he has written several parts of the v0.15 and the old GLUT
+	            emulator for Win);
+
+Diego Picciani     (he has developed all the Voodoo Rush support and the wgl
+	            emulator);
+
+Daryll Strauss     (for the Linux Glide and the first Linux support);
+
+Brian Paul         (of course);
+
+Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports)
+
+Bernd Kreimeier    (for the Linux 3Dfx HOWTO and for pushing companies to offer
+                    a better Linux support)
+
+3Dfx and Quantum3D (for actively supporting Linux)
+
+The most update places where find Mesa VooDoo driver related informations are
+the Mesa mailing list and my driver WEB page
+(http://www-hmw.caribel.pisa.it/fxmesa/index.shtml)
+
+
+David Bucciarelli (davibu@tin.it)
+
+Humanware s.r.l. 
+Via XXIV Maggio 62
+Pisa, Italy
+Tel./Fax +39-50-554108
+email: info.hmw@plus.it
+www: www-hmw.caribel.pisa.it

docs/README.AMIWIN

@@ -0,0 +1,181 @@
+AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION
+========================================================
+Port by Victor Ng-Thow-Hing (victorng@dgp.toronto.edu) 
+Original Author (Brian Paul (brianp@ssec.wisc.edu)
+
+Dec.1 , 1995: Port of release Mesa 1.2.5
+ - Modifications made to minimize changes to Mesa distribution.
+
+Nov.25, 1995: Port of release Mesa 1.2.4
+
+
+HISTORY
+=======
+As a 3D graphics progammer, I was increasingly frustrated to see OpenGL 
+appearing on so many platforms EXCEPT the Amiga. Up to now, the task
+of porting OpenGL directly from native Amiga drawing routines seemed like
+a daunting task. However, two important events made this port possible.
+
+First of all, Brian Paul wrote Mesa, the OpenGL software emulator that 
+can be found on many platforms - except the Amiga and Atari (who cares 
+about the latter!). This was pretty ironic considering that Mesa was 
+originally prototyped on an Amiga! The second great event was when 
+Holger Kruse developed AmiWin, the X11R6 server for the Amiga (definitely 
+register for this great piece of software) and released a development kit
+so one could compile X programs with SAS/C.
+
+Since Mesa had X routines as its primitive drawing operations, this made
+a marriage of Mesa and Amiwin feasible. I copied over the sources from
+an ftp site, played with the code, wrote some Smakefiles, and voila, 
+I had OpenGL programs displaying on my Amiga.
+
+Although the speed is nothing to be impressed about, this port can be
+potentially useful to those who want to quickly test their code in
+wireframe or perhaps learn more about programming with the OpenGL API.
+
+I hope Amiga developers will continue to write excellent software for
+their machine, especially more X clients for Amiwin. If you have any 
+solutions so some of my problems in the porting notes, please send me
+some email!
+
+See you around,
+Vic.
+
+HOW TO CREATE THE LIBRARIES AND SAMPLE CODE
+===========================================
+
+Just run the shell script mklib.amiwin in the mesa directory. This will
+make all the libraries and copy them into the mesa/lib directory. If you
+don't want to compile everything, just go to the desired directory and
+type smake in that directory.
+
+Change any of the variables in the smakefiles as necessary. You will REQUIRE
+the Amiwin development kit to compile these libraries since you need X11.LIB
+and the shareable X libraries. Some examples require the AmiTCP4.0
+net.lib static link library and related header files for unix related
+header files and functions like sleep().
+
+HOW TO USE THE MESA LIBRARIES
+=============================
+
+Study the Smakefiles in the demos, samples and book directories for the
+proper SAS/C options and linkable libraries to use. Basically aux calls
+require Mesaaux.LIB, gl calls require MesaGL.LIB, glu calls MesaGLU.LIB,
+tk calls Mesatk.LIB. There is a preliminary port of MesaGLUT.LIB toolkit
+available in the lib directory with the other Mesa libraries. However, 
+it seems to cause crashes on some of the sample code. Someone else may want
+to attempt a more stable port.
+
+PORTING NOTES TO AMIWIN
+=======================
+
+My strategy of porting was to leave as much of the code untouched as
+possible. I surrounded any amiga specific changes with 
+#ifdef AMIWIN ... #endif or #ifndef AMIWIN ... #endif preprocessor
+symbols. The code  was ported on an Amiga 2000, with Fusion 40 accelerator
+and a Picasso II graphics card. The SAS/C 6.56 compiler was used, with
+the AmiWin 2.16 X development kit.
+
+All compilations were done for a 68040 CPU with 68882 math coprocessor for
+maximum  speed. Please edit the smakefile for other compilers.
+I wrote smakefiles for the directories I ported. I omitted the Windows
+and Widgets directories. The former is for MS Windows and the latter 
+requires Motif, which is not easily available for the Amiga.
+
+Here are the changes I did per directory:
+
+* mesa
+Nov. 25, 1995 v 1.2.4
+  - added a mklib.amiwin shell script that will make all the libraries and
+    sample code for Mesa
+  - created this readme file: readme.AMIGA
+
+* mesa/include
+Dec. 1, 1995 v 1.2.5
+  - added the following to GL/xmesa.h 
+     #ifdef AMIWIN
+     #include <pragmas/xlib_pragmas.h>
+     extern struct Library *XLibBase;
+     #endif
+NET CHANGE: xmesa.h
+
+* mesa/src 
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c 
+    This prevents undefined symbols errors during the linking phase for 
+    X library calls
+  - created smakefile
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, 
+    glx.c since they are now defined in include/GL/xmesa.h
+NET CHANGE: smakefile
+   
+* mesa/src-tk
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    private.h
+  - created smakefile
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN includes from private.h since it is now defined in
+    include/GL/xmesa.h
+NET CHANGE: smakefile
+
+* mesa/src-glu
+Nov. 25, 1995 v 1.2.4
+  - created smakefile
+NET CHANGE: smakefile
+
+* mesa/src-aux
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    glaux.c
+  - created smakefile
+NET CHANGE: glaux.c, smakefile
+
+* mesa/demos
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    xdemo.c, glxdemo.c, offset.c
+  - created smakefile
+  - put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since 
+    they are not part of AmigaDOS.
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since
+    already defined in include/GL/xmesa.h
+  - modified Smakefile to include header and includes from the AmiTCP4.0
+    net.lib linkable library to provide unix-compatible sys/time.h and
+    the sleep() function
+    - removed AMIWIN defines in xdemo.c since sleep() now defined
+NET CHANGE: smakefile
+
+* mesa/samples
+Nov. 25, 1995 v 1.2.4
+  - added the necessary pragma calls for X functions to the following:
+    oglinfo.c
+  - created smakefile
+  - put #ifndef AMIWIN ... #endif around sleep() in blendxor.c
+  - removed olympic from smakefile targets since <sys/time.h> not defined
+Dec.  1, 1995 v 1.2.5
+  - removed AMIWIN defines from oglinfo.c, since already defined in 
+    include/GL/xmesa.h
+  - modified Smakefile to include header and includes from the AmiTCP4.0
+    net.lib linkable library to provide unix-compatible sys/time.h and
+    the sleep() function
+    - removed AMIWIN defines in blendxor.c for sleep()
+    - added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom()
+      functions are not defined in any libraries
+    - added olympic back into the Smakefile targets
+NET CHANGE: smakefile, olympic.c
+
+* mesa/book
+Nov. 25, 1995 v 1.2.4
+- created smakefile
+- removed accpersp and dof from smakefile targets since the SAS/C compile seems to
+  confuse the near,far variables with near/far memory models.
+NET CHANGE: smakefile
+
+* mesa/windows
+Dec.  1, 1995 v 1.2.5
+- Removed directory to save space since this is only needed for Windows based 
+  machines.

docs/README.BEOS

@@ -0,0 +1,102 @@
+
+                         Mesa / BeOS Information
+
+
+
+Introduction
+
+Mesa 3.1 features a new driver for the BeOS.  The new driver implements
+a clone of the BGLView class.  This class, derived from BView, allows
+OpenGL rendering into a BeOS window.
+
+Any application which uses the BGLView should be able to use Mesa
+instead of Be's OpenGL without changing any code.
+
+Since Be's OpenGL implementation (as of R4) is basically just the
+SGI sample implementation, it's pretty slow.  You'll see that Mesa
+is considerably faster.
+
+
+
+Source Code
+
+The source code for the driver is in Mesa-3.1/src/BeOS/GLView.cpp
+It's not 100% finished at this time but many GLUT-based demos are
+working.  No optimizations have been made at this time.
+
+
+
+Compiling
+
+Simply cd to the Mesa-3.x directory and type "make beos-r4".
+When it finishes the libMesaGL.so and libMesaGLU.so libraries for
+BeOS will be in the Mesa-3.x/lib/ directory.
+
+
+
+Example Programs
+
+Look in the Mesa-3.x/BeOS/ directory for one or two BGLView demo
+programs.  They should have been compiled along with the Mesa
+library.
+
+
+
+GLUT
+
+A version of GLUT 2.5 for BeOS can be found in src-glut.beos/.
+The original distribution can be obtained from
+http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip
+
+This is a special version of GLUT adapted for the BeOS.  I don't
+believe Mark Kilgard's normal GLUT distribution includes BeOS
+support.
+
+It seems that you have to recompile GLUT with libMesaGL.so instead
+of libGL.so in order for everything to work.  I'm not sure why.
+
+
+
+Special Features
+
+Mesa's implementation of the BGLView class has an extra member
+function:  CopySubBufferMESA().  It basically works like SwapBuffers()
+but it only copies a sub region from the back buffer to the front
+buffer.  This is a useful optimization for some applications.
+If you use this method in your code be sure that you check at runtime
+that you're actually using Mesa (with glGetString) so you don't
+cause a fatal error when running with Be's OpenGL.
+
+
+
+Work Left To Do
+
+Color index mode is not implemented yet.
+
+Reading pixels from the front buffer not implemented yet.
+
+There is also a BGLScreen class in BeOS for full-screen OpenGL
+rendering.  This should also be implemented for Mesa.
+
+
+
+Old BeOS Driver
+
+Mesa 2.6 had an earlier BeOS driver.  It was based on Mesa's Off-screen
+rendering interface, not BGLView.  If you're interested in the older
+driver you should get Mesa 2.6.
+
+
+
+BeOS and Glide
+
+Mesa 3.0 supported the 3Dfx/Glide library on Beos.  Download Mesa 3.0
+if interested.  Ideally, the 3Dfx/Glide support should be updated to
+work with the new Mesa 3.1 BGLView implementation.
+
+The Glide library hasn't been updated for BeOS R4, to my knowledge, as
+of February, 1999.
+
+
+----------------------------------------------------------------------
+$Id: README.BEOS,v 1.5 1999/03/03 02:34:04 brianp Exp $

docs/README.CYGWIN

@@ -1,256 +0,0 @@
-
-                          Mesa Cygwin/X11 Information
-
-
-WARNING
-=======
-
-If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the 
-latest setup.exe from Cygwin the GL (Mesa) libraries and include are already 
-installed in /usr/X11R6. 
-
-The following will explain how to "replace" them.
-
-Installation
-============
-
-How to compile Mesa on Cygwin/X11 systems:
-
-1. Shared libs:
-    type 'make cygwin-sl'.
-
-    When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and 
-    Mesa-x.y/bin directories.
-
-
-2. Static libs:
-    type 'make cygwin-static'.
-    When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
-
-Header and library files:
-   After you've compiled Mesa and tried the demos I recommend the following
-   procedure for "installing" Mesa.
-
-   Copy the Mesa include/GL directory to /usr/X11R6/include:
-	cp -a include/GL /usr/X11R6/include
-
-   Copy the Mesa library files to /usr/X11R6/lib:
-	cp -a lib/* /usr/X11R6ocal/lib
-
-   Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin:
-	cp -a lib/cyg* /usr/X11R6/bin
-
-Xt/Motif widgets:
-   If you want to use Mesa or OpenGL in your Xt/Motif program you can build
-   the widgets found in either the widgets-mesa or widgets-sgi directories.
-   The former were written for Mesa and the later are the original SGI
-   widgets.  Look in those directories for more information.
-   For the Motif widgets you must have downloaded the lesstif package.
-
-
-Using the library
-=================
-
-Configuration options:
-   The file src/mesa/main/config.h has many parameters which you can adjust
-   such as maximum number of lights, clipping planes, maximum texture size,
-   etc.  In particular, you may want to change DEPTH_BITS from 16 to 32
-   if a 16-bit depth buffer isn't precise enough for your application.
-
-
-Shared libraries:
-   If you compile shared libraries (Win32 DLLS) you may have to set an 
-   environment variable to specify where the Mesa libraries are located.  
-   Set the PATH variable to include /your-dir/Mesa-2.6/bin.   
-   Otherwise, when you try to run a demo it may fail with a message saying 
-   that one or more DLL couldn't be found.
-
-
-Xt/Motif Widgets:
-   Two versions of the Xt/Motif OpenGL drawing area widgets are included:
-
-      widgets-sgi/	SGI's stock widgets
-      widgets-mesa/	Mesa-tuned widgets
-
-   Look in those directories for details
-
-
-Togl:
-   Togl is an OpenGL/Mesa widget for Tcl/Tk.
-   See http://togl.sourceforge.net for more information.
-
-
-
-X Display Modes:
-   Mesa supports RGB(A) rendering into almost any X visual type and depth.
-
-   The glXChooseVisual function tries its best to pick an appropriate visual
-   for the given attribute list.  However, if this doesn't suit your needs
-   you can force Mesa to use any X visual you want (any supported by your
-   X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
-   environment variables.  When an RGB visual is requested, glXChooseVisual
-   will first look if the MESA_RGB_VISUAL variable is defined.  If so, it
-   will try to use the specified visual.  Similarly, when a color index
-   visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
-   variable.
-
-   The format of accepted values is:  <visual-class> <depth>
-   Here are some examples:
-
-   using the C-shell:
-	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor
-	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor
-	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor
-
-   using the KornShell:
-	$ export MESA_RGB_VISUAL="TrueColor 8"
-	$ export MESA_CI_VISUAL="PseudoColor 12"
-	$ export MESA_RGB_VISUAL="PseudoColor 8"
-
-
-Double buffering:
-   Mesa can use either an X Pixmap or XImage as the backbuffer when in
-   double buffer mode.  Using GLX, the default is to use an XImage.  The
-   MESA_BACK_BUFFER environment variable can override this.  The valid
-   values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first
-   letter is checked, case doesn't matter).
-
-   A pixmap is faster when drawing simple lines and polygons while an
-   XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you
-   need depth buffering the XImage will almost surely be faster.  Exper-
-   iment with the MESA_BACK_BUFFER variable to see which is faster for
-   your application.  
-
-
-Colormaps:
-   When using Mesa directly or with GLX, it's up to the application writer
-   to create a window with an appropriate colormap.  The aux, tk, and GLUT
-   toolkits try to minimize colormap "flashing" by sharing colormaps when
-   possible.  Specifically, if the visual and depth of the window matches
-   that of the root window, the root window's colormap will be shared by
-   the Mesa window.  Otherwise, a new, private colormap will be allocated.
-
-   When sharing the root colormap, Mesa may be unable to allocate the colors
-   it needs, resulting in poor color quality.  This can happen when a
-   large number of colorcells in the root colormap are already allocated.
-   To prevent colormap sharing in aux, tk and GLUT, define the environment
-   variable MESA_PRIVATE_CMAP.  The value isn't significant.
-
-
-Gamma correction:
-   To compensate for the nonlinear relationship between pixel values
-   and displayed intensities, there is a gamma correction feature in
-   Mesa.  Some systems, such as Silicon Graphics, support gamma
-   correction in hardware (man gamma) so you won't need to use Mesa's
-   gamma facility.  Other systems, however, may need gamma adjustment
-   to produce images which look correct.  If in the past you thought
-   Mesa's images were too dim, read on.
-
-   Gamma correction is controlled with the MESA_GAMMA environment
-   variable.  Its value is of the form "Gr Gg Gb" or just "G" where
-   Gr is the red gamma value, Gg is the green gamma value, Gb is the
-   blue gamma value and G is one gamma value to use for all three
-   channels.  Each value is a positive real number typically in the
-   range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling
-   gamma correction.  Examples using csh:
-
-	% setenv MESA_GAMMA "2.3 2.2 2.4"	// separate R,G,B values
-	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B
-
-   The demos/gamma.c program may help you to determine reasonable gamma
-   value for your display.  With correct gamma values, the color intensities
-   displayed in the top row (drawn by dithering) should nearly match those
-   in the bottom row (drawn as grays).
-
-   Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
-   on HP displays using the HP-ColorRecovery technology.
-
-   Mesa implements gamma correction with a lookup table which translates
-   a "linear" pixel value to a gamma-corrected pixel value.  There is a
-   small performance penalty.  Gamma correction only works in RGB mode.
-   Also be aware that pixel values read back from the frame buffer will
-   not be "un-corrected" so glReadPixels may not return the same data
-   drawn with glDrawPixels.
-
-   For more information about gamma correction see:
-   http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
-
-
-Overlay Planes
-
-   Overlay planes in the frame buffer are supported by Mesa but require
-   hardware and X server support.  To determine if your X server has
-   overlay support you can test for the SERVER_OVERLAY_VISUALS property:
-
-	xprop -root | grep SERVER_OVERLAY_VISUALS
-
-
-HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
-
-   If you set the MESA_HPCR_CLEAR environment variable then dithering
-   will be used when clearing the color buffer.  This is only applicable
-   to HP systems with the HPCR (Color Recovery) system.
-
-
-Extensions
-==========
-   There are three Mesa-specific GLX extensions at this time.
-
-   GLX_MESA_pixmap_colormap 
-
-      This extension adds the GLX function:
-
-         GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
-                                           Pixmap pixmap, Colormap cmap )
-
-      It is an alternative to the standard glXCreateGLXPixmap() function.
-      Since Mesa supports RGB rendering into any X visual, not just True-
-      Color or DirectColor, Mesa needs colormap information to convert RGB
-      values into pixel values.  An X window carries this information but a
-      pixmap does not.  This function associates a colormap to a GLX pixmap.
-      See the xdemos/glxpixmap.c file for an example of how to use this
-      extension.
-
-   GLX_MESA_release_buffers
-
-      Mesa associates a set of ancillary (depth, accumulation, stencil and
-      alpha) buffers with each X window it draws into.  These ancillary
-      buffers are allocated for each X window the first time the X window
-      is passed to glXMakeCurrent().  Mesa, however, can't detect when an
-      X window has been destroyed in order to free the ancillary buffers.
-
-      The best it can do is to check for recently destroyed windows whenever
-      the client calls the glXCreateContext() or glXDestroyContext()
-      functions.  This may not be sufficient in all situations though.
-
-      The GLX_MESA_release_buffers extension allows a client to explicitly
-      deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
-      just before an X window is destroyed.  For example:
-
-         #ifdef GLX_MESA_release_buffers
-            glXReleaseBuffersMESA( dpy, window );
-         #endif
-         XDestroyWindow( dpy, window );
-
-      This extension is new in Mesa 2.0.
-
-   GLX_MESA_copy_sub_buffer
-
-      This extension adds the glXCopySubBufferMESA() function.  It works
-      like glXSwapBuffers() but only copies a sub-region of the window
-      instead of the whole window.
-
-      This extension is new in Mesa version 2.6
-
-
-
-Summary of X-related environment variables:
-   MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
-   MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
-   MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
-   MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
-   MESA_GAMMA - gamma correction coefficients (X only)
-
-
-----------------------------------------------------------------------
-README.CYGWIN - lassauge April 2004 - based on README.X11

docs/README.D3D

@@ -0,0 +1,124 @@
+
+                     DirectX 6 Driver for Mesa 3.0
+
+
+This software is distributed under the terms of the GNU Library
+General Public License, see the LICENSE file for details.
+
+
+
+What do you need ?
+------------------
+
+	- A PC with a DirectX 6 video driver installed.
+
+	- Mesa 3.0
+
+	- The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine).
+	  The Voodoo2 requires the Glide library 2.51. The Glide 3.0 is not
+	  compatible with the Glide 2.x so it doesn't work with the current
+	  version of the driver;
+
+	- Visual C++ 5.0 is only compiler test but others should be ok with
+       changes to the makefiles (CFLAGS/LFLAGS).
+
+	- DirectX 6 SDK (was a MS download but not sure if still available).
+
+	- SoftIce or another debugger that will get DPF's is nice.
+
+
+Tested on:
+----------
+	Windows 95
+  	Windows 98
+	Windows NT 5.0 (beta 2)
+
+
+What is able to do ?
+--------------------
+
+	- the driver will try and use DirectX to rasterize the OpenGL primitives
+	that are sent to the driver.  The driver will fall back to SW  if the rendering 
+	context is too big.  The fallback to SW still uses DirectDraw.  If the driver
+	fails to support and operation (accum, stencil, etc) then it will try and get
+	Mesa to render it in SW.  DirectX 6 features that are unsupported by the 
+	installed DirectX 6 driver will be mapped to some other best fit feature.
+
+
+How to compile:
+---------------
+
+	These instructions assume you have Visual C++ installed.
+
+	  You might need to increase you enviroment space.  You can do this by 
+	adding the following statement to you config.sys.
+
+	shell=C:\COMMAND.COM C:\ /p /e:8198
+
+	  Next setup you compiler enviroment by running vcvars32.bat in the Visual C++
+ 	'bin' directoy.
+
+	c:\DevStudio\VC\bin\vcvars32.bat
+
+	  Modify the D3D makefile to point at your SDK install.  Example has the SDK
+	installed on my 'f' drive in the root.
+
+	file: \Mesa-3.0\src\makefile.d3d
+
+	SDKROOT=f:\mssdk
+
+	  Now you can simply make the project.  If you look in the makefile you can see
+	I have some different targets like 'install'.  
+
+	nmake /f makefile.d3d
+
+
+FAQ:
+----
+
+	1) I don't think the driver is using my DirectX driver.
+
+ 	  This maybe true as the current version will only select the Primary D3D driver
+	installed.  If you 3D card is the secondary (3dfx) then your out of luck for this
+	release.
+
+	2) The driver seems like its not HW accelerated.
+
+	  If you have a video card with limited memory then you might want to try and 
+	change your destop resolution to a low setting (640x480x16) so that the 3D part
+	of the card has more resources.  Remeber the driver can't make the card better...
+
+	3) Nothing works.
+
+	  Make sure you have a DirectX '6' driver installed.  Check you driver docs for this
+	info or use the SDK info utilities.
+	  The final 'dll' is named opengl32.dll and is either in the same directory as the 
+	OpenGL program or in your system directory (x:\windows\system or x:\winnt\system32).
+	  Check your destop resolution.  Most DirectX 6 drivers will only support 16bit and
+	32bit color depth.  To find out for sure you can check the DirectX Info Viewer in
+	the SDK.
+	  
+
+	4) Rendering doesn't look right.
+
+	  Sometimes this is because the card doesn't support a feature that that is required.
+	This is usually due to unsupported alpha functions (test/blend) or texture mapping.
+	Some cards suffer from too small of an alpha channel.  The driver does its best to
+	fallback on unsupported features.  This is not to say the driver may not have a bug(s).
+
+	5) Textures look bad.
+
+	  No mipmapping in this release.
+
+
+Thanks to:
+----------
+
+Brian Paul
+
+
+
+
+Leigh McRae (leigh@altsoftware.com)
+February 9, 1999
+

docs/README.GGI

@@ -0,0 +1,172 @@
+                       LibGGI driver for Mesa-3.0
+		  by Uwe Maurer (uwe_maurer@t-online.de)	
+
+
+Introduction
+============
+[from libggi.txt by Steve Cheng and Hartmut Niemann]
+
+ "LibGGI, the dynamic GGI (General Graphics Interface) library is a
+  flexible drawing library.
+
+  It provides an opaque interface to the display's acceleration
+  functions. It was originally intended to allow user programs to
+  interface with KGI, the kernel side of the GGI code, but other display
+  types can be easily used by loading the appropriate "display target"
+  (e.g. X, memory).
+
+  LibGGI consists of a main library (libggi.so) and a multitude of
+  dynamic drivers. The library then loads the necessary "drivers" for
+  the requested mode, taking hints from the graphics device if
+  necessary. LibGGI can also load extension libraries, e.g. to provide
+  enhanced 2D and 3D functions.
+
+  It has been designed after having a look at several existing
+  libraries, and so far we have found porting to be quite simple from
+  and to most of them."
+
+----------------------------------------------------------------------------
+
+	More information about the GGI project and LibGGI can be 
+	obtained from the GGI website:
+
+	www.ggi-project.org
+
+----------------------------------------------------------------------------
+
+Installation
+============
+
+	- Install LibGGI
+	
+	- Unpack the Mesa archives
+	
+	- In the Mesa directory type:
+		
+		make linux-ggi
+		su
+		make linux-ggi-install
+		exit
+	
+	- Now you can try some demos.
+	  If they don't work, you can set the GGIMESA_DEBUG
+	  variable to 255 and you will see some information from the
+	  LibGGI-driver.
+		 
+	   export GGIMESA_DEBUG=255
+	
+
+GLUT
+====	
+
+	You can change these default values in ggi/ggiglut.c:
+	#define WIDTH   640
+	#define HEIGHT  400
+	#define GRAPHTYPE_RGB   GT_16BIT
+	#define GRAPHTYPE_INDEX GT_8BIT
+
+	Options:
+		-bpp x		Set graphic mode with x bits per pixel	
+		-size x y	Screen (or window) is x*y pixels 
+
+	Example:
+		demos/gears -size 320 200 -bpp 24
+
+Updates
+=======
+	
+	You can find the latest LibGGI-driver and ggiglut on my
+	homepage:
+	
+	http://home.t-online.de/home/uwe_maurer/ggimesa.htm
+	
+		
+
+Uwe Maurer  -  uwe_maurer@t-online.de
+
+                       LibGGI driver for Mesa-3.0
+		  by Uwe Maurer (uwe_maurer@t-online.de)	
+
+
+Introduction
+============
+[from libggi.txt by Steve Cheng and Hartmut Niemann]
+
+ "LibGGI, the dynamic GGI (General Graphics Interface) library is a
+  flexible drawing library.
+
+  It provides an opaque interface to the display's acceleration
+  functions. It was originally intended to allow user programs to
+  interface with KGI, the kernel side of the GGI code, but other display
+  types can be easily used by loading the appropriate "display target"
+  (e.g. X, memory).
+
+  LibGGI consists of a main library (libggi.so) and a multitude of
+  dynamic drivers. The library then loads the necessary "drivers" for
+  the requested mode, taking hints from the graphics device if
+  necessary. LibGGI can also load extension libraries, e.g. to provide
+  enhanced 2D and 3D functions.
+
+  It has been designed after having a look at several existing
+  libraries, and so far we have found porting to be quite simple from
+  and to most of them."
+
+----------------------------------------------------------------------------
+
+	More information about the GGI project and LibGGI can be 
+	obtained from the GGI website:
+
+	www.ggi-project.org
+
+----------------------------------------------------------------------------
+
+Installation
+============
+
+	- Install LibGGI
+	
+	- Unpack the Mesa archives
+	
+	- In the Mesa directory type:
+		
+		make linux-ggi
+		su
+		make linux-ggi-install
+		exit
+	
+	- Now you can try some demos.
+	  If they don't work, you can set the GGIMESA_DEBUG
+	  variable to 255 and you will see some information from the
+	  LibGGI-driver.
+		 
+	   export GGIMESA_DEBUG=255
+	
+
+GLUT
+====	
+
+	You can change these default values in ggi/ggiglut.c:
+	#define WIDTH   640
+	#define HEIGHT  400
+	#define GRAPHTYPE_RGB   GT_16BIT
+	#define GRAPHTYPE_INDEX GT_8BIT
+
+	Options:
+		-bpp x		Set graphic mode with x bits per pixel	
+		-size x y	Screen (or window) is x*y pixels 
+
+	Example:
+		demos/gears -size 320 200 -bpp 24
+
+Updates
+=======
+	
+	You can find the latest LibGGI-driver and ggiglut on my
+	homepage:
+	
+	http://home.t-online.de/home/uwe_maurer/ggimesa.htm
+	
+		
+
+Uwe Maurer  -  uwe_maurer@t-online.de
+

docs/README.LYNXOS

@@ -0,0 +1,64 @@
+
+Mesa 3.0 for LynxOS builds in the following way:
+
+make lynxos
+
+This will build all the libraries and demo applications. You should have 
+around 400 megabytes free for everything since everything is done with 
+static
+libraries.
+
+Before using this make file however, you should perform the following 
+actions:
+0) cd to the Mesa-3.0 directory
+1) Copy the GL directory under the include directory to /usr/include.
+2) Copy the files in the lib directory to /lib.
+3) Make links so that the Mesa libraries look like ordinary OpenGL 
+libraries
+in /lib. This is important for compatibility with other OpenGL apps. This
+is done as follows:
+
+cd /lib
+ln -s libMesaGL.a libGL.a
+ln -s libMesaGLU.a libGLU.a
+
+Mesa 3.0 includes the GLUT (GL Utility Toolkit) by default.
+The demo applications are done using this toolkit.
+
+Mesa makefiles for building their apps could be used as well, but the
+following one is much more concise. Note that the order of the X libraries
+is important to the linker so that all symbols get resolved correctly.
+Changing the order may result in having to list a library twice to make
+sure all linkages are made correctly.
+
+----cut here for Makefile -----
+
+FILES = your_app.x
+
+SPECIAL_INCLUDES = -I/usr/include/GL
+
+SPECIAL_CFLAGS = -g  -ansi -pedantic -funroll-loops -ffast-math -DSHM
+
+SPECIAL_LIBS = -lglut -lGLU -lGL -lm -L/usr/X11/lib -lXext -lXmu -lXi \
+-lX11 -lbsd -g
+
+STANDARD_OFILES = $(FILES:.x=.o)
+
+%.o: %.c
+	gcc -c $(SPECIAL_CFLAGS) $(SPECIAL_INCLUDES) $< -o $@
+
+all: $(STANDARD_OFILES)
+	gcc -o your_app $(STANDARD_OFILES) $(SPECIAL_LIBS)
+
+
+----cut here for Makefile-----
+
+I have tested Mesa under LynxOS 3.0 and 3.01. It should build fine under 
+other
+versions as well. Note, however, that LynxOS versions prior to 3.0 are not
+binary compatible, so you will have to rebuild from source.
+
+
+Vik Sohal
+vik@lynx.com
+January 13, 1999

docs/README.MINGW32

@@ -0,0 +1,123 @@
+August 30, 1998 -- Paul Garceau (pgarceau@teleport.com)
+
+DISCLAIMER:  I make this extension to the Mesa 3-D Graphics Library as a service
+to the general public.  I can, in no way support or make any guarantee that the
+EGCS-Mingw32 build or any Gnu-Win32 build will work for your system. The
+associated packages and batch files I have included as part of the EGCS-Mingw32
+extension are provided "As-is" with out any guarantee of support or functionality
+from the author of this EGCS-Mingw32 native windows port of the Mesa 3-D Graphics
+Library.
+
+	Feel free to modify or change things as you see fit, just remember that
+I can't support any modifications you might want to make to the files which I
+have included OR the lgpl protected Mesa 3-D Graphics Library.
+
+
+	EGCS-Mingw32 Beta 3.08 Archive Manifest:
+		mingw32.bat
+		src/makefile.nt4
+		src/wmesa.c
+		src-glu/makefile.nt4
+
+###############
+
+Greetings,
+
+	In order to build the Mingw32 set of Mesa 3-D Graphics Library for Beta3.08
+it will be necessary for you to use the Dos or Command Prompt that is available
+on most of the i86 based MS Windows machines.  Also, I believe that this build
+will run on Win95, Win98, WinNT4 and WinNT5.
+
+	I haven't tested Win95/98 or WinNT5.  This build was generated under
+WinNT4 with SP3 installed.
+
+	This has not been tested under any systems outside of
+a WinNT4 Workstation with EGCS-Mingw32 toolchain, v.1.0.2 installed.
+
+	EGCS-Mingw32 uses a variation of gcc to handle its build.  The Mesa 3-D
+Graphics Library build that I have generated is based, in small part, on the
+Cygwin32 build and associated makefiles that Stephane Rehel (rehel@worldnet.fr)
+defined back in 1997.  The EGCS-Mingw32 toolchain is capable of generating
+native windows code and, as of the date of this readme, can be obtained from:
+
+	http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs-mingw32-102.html
+
+	Much thanks to the combined efforts of Mumit Khan, Jan-Jaap Vanderhagen
+and Colin Peters for making it possible for the EGCS-Mingw32 toolchain to exist.
+
+Installing EGCS-Mingw32 Build Revisions:
+
+	To install the makefile and source revisions incorporated with this build
+of the Mesa 3-D Graphics Library, you'll have to use a version of winzip.  I am
+in the process of finding a suitable Win32 compatible tar executable so that if
+you don't have winzip, you can still decompress the files into their respective
+folders/directories.
+
+	a) Move the mingw32.zip file to the top level of the hard drive on your
+system.
+
+	b) Copy all of the Beta 3.08 src/windows files to the src/ directory.
+
+	b) Open the Winzip file
+
+	c) Verify that the files will be properly extracted.
+
+	d) Extract the files with the Winzip "Overwrite" and "Use Folder Names"
+	   options enabled.
+
+	The zip file directory structure extraction defaults to the top level of
+the hard drive where the mingw32.zip file exists unless otherwise instructed by
+you.
+
+	The version of wmesa.c included with the mingw32 archive needs to replace
+the current version of the Beta 3.08 wmesa.c file in order for the egcs-mingw32
+build to work.  This is because the original Win32 stuff assumes that the glut
+utilities are to be installed.  The Glut utilities are not part of the
+egcs-mingw32 build for Beta 3.08.
+
+
+Build Considerations:
+
+	In order to get the build to work, I needed to create a special makefile
+for each library which the Mesa 3-D Graphics Library requires since there is no
+comparable make-config/config on a native windows platform.
+
+	Since I was only creating a few of the possible libraries for 
+Mesa (gl, glu), I only created the new make files in their respective libraries
+src, src-glu).  For libMesaaux.a. you will find a makefile for it in the
+src-aux directory.  libMesatk.a and libglut.a were not ported.
+
+	The build itself is a .bat based build and uses Gnu Make,Version 3.76.1 to
+process the makefiles noted above.  The build must be run from the directory
+where the mingw32.bat file is.  You can get the binary version of Make 3.76.1
+from Jan-Jaap van der Heijden's site in Germany:
+
+	http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/download.html
+
+	It was necessary to modify some source code, specifically the source code
+in the src-glu directory.  I needed to modify nurbs.c, quadric.c and tess.c in
+order to get them to work using the EGCS-Mingw32 toolchain.
+
+	The original EGCS-Mingw32 Toolchain, is available from:
+
+	http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs-mingw32-102.html	
+
+Running the Build:
+
+	Ok, now that we've got the basics out of the way, follows is all you need
+to do in order to build the EGCS-Mingw32 version of libMesaGL.a and libMesaGLU.a:
+
+	Open your Command Prompt/Dos prompt.
+	Go to your Mesa-3.0 beta 'root' directory.
+		This is the same directory that the Mesa mingw32.zip file was
+		originally stored in if you've installed the Mesa-3.0 beta 3-D
+		Graphics Library source as outlined in the "readme" file included
+		with the Mesa-3.0 beta distribution.
+	At the command line type: mingw32
+		mingw32 is the .bat file that actually does the build.
+
+	Enjoy!
+
+	Peace,
+
+		Paul G. (pgarceau@teleport.com)

docs/README.NeXT

@@ -0,0 +1,6 @@
+The NeXT support has now been incorporated into the OpenStep support.
+You can build NeXT libraries simply by typing "make next", though before
+linking they will need to be ranlib'd by hand. For more information see
+the README.OpenStep file, together with the README files in OpenStep/Old_Demos.
+
+-Pete French. (pete@ohm.york.ac.uk) 28/5/1998

docs/README.OS2

@@ -0,0 +1,96 @@
+            README for port of Mesa 3.x to XFree86 on OS/2 (X/2)
+                          (as of 19990514)
+
+
+                           Contents:
+
+                           1) Binary release
+                           2) Building from sources
+                           3) History
+                           4) Todo
+                           5) Mesa Home Page
+
+
+1) Binary release
+
+   Though the Mesa sources should build in a quite reasonable time even on
+   a 585 class machine a binary relase is available (check topic 4) for an URL)
+   This package includes:
+
+     - lib/MesaGL.dll,  MesaGL.a
+     - lib/MesaGLU.dll, MesaGLU.a
+     - lib/glut.dll,    glut.a
+     - include/GL/*.h
+
+    Installing this in your XFree86 tree will enable you to build and
+    run all applications compatible with Mesa (and the current DLL
+    interface, of course ;-)
+    As usual the OMF-style libraries can be created using emxomf.
+    (e.g. "emxomf foo.a"  creates the foo.lib omf-style library).
+    The static libraries are rarely used and you have to rebuild
+    Mesa to get them. They're a supported target, so you get
+    them in a straightforward way (see below).
+
+    The testing of these libraries was limited to the supplied
+    demos/examples and a quite small number of third-party apps.
+    No warranty ... as usual ...  ;-)
+
+
+2)  Instructions to build Mesa 3.x for XFree86/OS2 from sources:
+
+    Except the official Mesa source distribution you need:
+      - a recent version of XFree86 (3.3.x or above) including
+        the programming libraries
+      - EMX 0.9c (0.9d might work, never checked)
+      - GNU make
+      - REXX (!)
+
+    The creation of the DLLs as well as of the static libraries
+    (if you want to have them) is handled in "mklib-emx.cmd",
+    a small REXX script. Perhaps not the best idea, but this
+    way it fits best in the scheme used to build libraries
+    on all platforms in Mesa 3.x.
+
+    To actually build the libraries and demos, check mklib-emx.cmd
+    and modify it as desired. Then type
+      make os2-x11
+    and wait for completion ;-)
+
+
+3)  History
+
+    Initially Darren Abbott (abbott@hiwaay.net) ported Mesa versions 2.x
+    to XFree86 OS/2. This port might still be available from 
+       http://fly.HiWAAY.net/~abbott/xfree86-os2/xfree86.html
+
+    The current port picked up things during the beta test for 3.0. 
+    No major changes in the source were done. The build mechanism under OS/2
+    has been made very similar to other platforms (if you treat mklib-emx.cmd
+    as a "black box").
+    Advantage is that X/2 is now a valid target and all files are
+    integrated in the official source distribution.
+    Disadvantage is that this port (i.e. the DLLs' interface itself) is
+    definitly NOT COMPATIBLE to those of version 2.x. 
+    It's uncertain whether this would be at all possible but since there
+    a _very_ few those apps it's not worth to find out anyway.
+    Also some libs (MesaTK, MesaAUX) are withdrawn from the Mesa distribution,
+    and accordingly from the OS/2 port.
+
+4) Todo
+
+    By now binary compatiblity is ensured by using the function names
+    as entry points instead of ordinals. This might cost performance and
+    is subject to change in future. In addition the supplied X86 assembler
+    source is not used yet.
+
+5)  Mesa Home Page
+
+    You can get the source code and more information about Mesa from
+       http://www.mesa3d.org/
+
+    The OS/2 ports should be available from
+       http://r350.ee.ntu.edu.tw/~hcchu/os2/ports 
+
+--
+Alexander Mai
+st002279@hrzpub.tu-darmstadt.de

docs/README.OpenStep

@@ -0,0 +1,35 @@
+This is a port of the GL and GLU libraries to NeXT/Apple object
+orientated systems. As these systems have their own window handling
+systems we simply use the offscreen rendering capability of Mesa
+to generate bitmaps which may then be displayed by the application
+with a View as required. Example pieces of code may be found in the
+OpenStep directory.
+
+Sadly there are now a proliferation of different system that we need to
+support compilation for: The original NextStep system, The OpenStep
+system, the Rhapsody/Mac OS X system and also the windows implementations
+of the latter two systems. This version of the code has been compiled and
+tested under the following architectures:
+
+	NextStep 3.3 
+	OpenStep 4.2
+	Rhapsody DR2
+	WebObjects for NT 3.5
+	WebObjects for NT 4.0
+
+All tests were done with Intel processors. Feedback on other systems would,
+however, be appreciated !
+
+On UNIX systems simply type "make openstep". Under Windows systems
+with WebObjects run the "win32-openstep.sh" script from within the Bourne
+shell provided with the development environment. In both cases this will
+build the libraries and place them into the "lib" directory. Some examples
+may be found in the OpenStep directory showing how to use the code in an
+actual application (MesaView) as well as some command line demos.
+
+The CC variable may be specified on the command line for doing such things
+as building FFAT libraries or using alternative compilers to the standard 'cc'
+e.g.  make CC='cc -arch m68k -arch i386' openstep" will build the libraries
+with both intel and motorola architectures.
+
+-Pete French. (pete@ohm.york.ac.uk) 7/6/1999

docs/README.QUAKE

@@ -205,3 +205,4 @@ http://www.linuxgames.com/quake2/
 
 
 ----------------------------------------------------------------------
+$Id: README.QUAKE,v 1.3 1998/08/23 15:26:26 brianp Exp $

docs/README.THREADS

@@ -1,33 +1,45 @@
 
+NOTE: this information is obsolete for Mesa 3.1.  Due to the big
+changes in the Mesa code, the threads support is out of date.
+Someone will have to review/update it.
+
 
 Mesa Threads README
 -------------------
 
-Thread safety was introduced in Mesa 2.6 by John Stone and
+Mesa 2.6 is the starting point for an effort to make Mesa 
-Christoph Poliwoda.
+safe in multithreaded applications.  The files src/mthreads.c and
-
+src/mthreads.h provide a platform independent threads API which Mesa
-It was redesigned in Mesa 3.3 so that thread safety is
+uses internally to provide thread-safe operation.  At present the mthreads
-supported by default (on systems which support threads,
+code supports three thread APIS:
-that is).  There is no measurable penalty on single
-threaded applications.
-
-NOTE that the only _driver_ which is thread safe at this time
-is the OS/Mesa driver!
-
-
-At present the mthreads code supports three thread APIS:
   1) POSIX threads (aka pthreads).
   2) Solaris / Unix International threads.
   3) Win32 threads (Win 95/NT).
 
-Support for other thread libraries can be added src/glthread.[ch]
+Here's the current list of targets which enable multithreaded handling
+in Mesa:
 
+  linux-386-pthread    for Linux w/ Intel assembly and linuxthreads
+  sunos5-thread        for Suns with SunOS 5.x, using Solaris threads
+  sunos5-pthread       for Suns with SunOS 5.[56] using POSIX threads
+  sunos5-gcc-thread    for Suns with SunOS 5.x and GCC, using Solaris threads
+  sunos5-gcc-pthread   for Suns with SunOS 5.[56] and GCC, using POSIX threads
 
-In order to guarantee proper operation, it is
+In order to use Mesa with a multithreaded application, Mesa must be compiled
+using one of the thread-enabled configurations.  In cases where a platform
+supports multiple APIs which are acceptable to Mesa, Mesa must be built
+with the same threads API as the application in order for things to work
+properly.  For example, Solaris >= 2.5 support both POSIX threads and
+Sun's own threads API.  In order to guarantee proper operation, it is
 necessary for both Mesa and application code to use the same threads API.
 So, if your application uses Sun's thread API, then you should build Mesa
 using one of the targets for Sun threads.
 
+Since this effort is still very much a work in progress, not all 
+aspects of Mesa are thread safe.  As of this release (Mesa 2.6) only the
+osmesa drivers have been made MT-safe.  As work continues, other drivers
+such as the X11 drivers will also incorporate MT-safe features.
+
 The mtdemos directory contains some example programs which use 
 multiple threads to render to osmesa rendering context(s).
 
@@ -38,15 +50,17 @@ only one that really supports multiprocessor machines (AFAIK). See
 http://pauillac.inria.fr/~xleroy/linuxthreads/README for further
 information about the usage of linuxthreads.
 
-If you are interested in helping with thread safety work in Mesa
+If you are interested in helping develop MT-safe Mesa, please send email
-join the Mesa developers mailing list and post your proposal.
+to j.stone@acm.org and poliwoda@volumegraphics.com who are the two most
+directly involved in this effort currently.  Similarly, if you have problems
+using the MT-safe builds of Mesa, please send us comments/bugs etc.
 
+Future versions of Mesa will include more extensive documentation related
+to multithreading.  This is the first release of our work, so please bear
+with us.
 
 Regards,
   John Stone           -- j.stone@acm.org  johns@cs.umr.edu
   Christoph Poliwoda   -- poliwoda@volumegraphics.com
 
 
-Version info:
-   Mesa 2.6 - initial thread support.
-   Mesa 3.3 - thread support mostly rewritten (Brian Paul)

docs/README.VMS

@@ -26,13 +26,3 @@ On Alpha platforms at default a sharable images for the libraries are created.
 To get a static library make it by typing MMS/MACRO=(NOSHARE=1).
 On VAX platforms only static libraries can be build.
 
-23-sep-2005
-changed default compilation to use /float=ieee/ieee=denorm. The reason for 
-this is that it makes Mesa on OpenVMS better compatible with other platforms
-and other packages for VMS that I maintain.
-For more information see
-      http://nchrem.tnw.tudelft.nl/openvms
-      https://bugs.freedesktop.org/show_bug.cgi?id=4270
-You may want to compile Mesa to use VAX-floating point arithmetic, instead
-of IEEE floating point by removing the /float=IEEE/denorm flag from the
-compiler options in the descrip.mms files.

docs/README.WIN32

@@ -1,53 +1,606 @@
-File: docs/README.WIN32
+
-
+    Mesa/Readme.win32
-Last updated: 23 April 2011
+
-
+    Last Updated: Friday, July 9th, 1999 - tjump@tertius.com
-
+
-Quick Start
+*** What's New
------ -----
+
-
+- Updated for Mesa 3.1beta2/CVS.
-Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
+
-no longer shipped or supported.
+- DevStudio projects suspended for compatability reasons: projects modified
-
+  by DevStudio 6 are not compatible with DevStudio 5.
-Run
+
-
+- Build environment change: The Glide SDK is no longer assumed to be in
-  scons osmesa mesagdi
+  the global INCLUDE/LIB environment vars, it is required that you set the
-
+  value 'GLIDE2X' as either an environment variable pointing to your Glide
-to build classic mesa Windows GDI drivers; or
+  SDK install directory or that you configure that as a build option to
-
+  nmake.exe when building fxmesagl32.  Examples:
-  scons libgl-gdi
+
-
+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x fxmesagl32
-to build gallium based GDI driver.
+
-
+          <or>
-This will work both with MSVS or Mingw.
+
-
+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x allfx
-
+
-Windows Drivers
+          <or>
-------- -------
+
-
+    nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x progs.3dfx.demos
-At this time, only the gallium GDI driver is known to work.
+
-
+  The DevStudio workspace files for 3Dfx OpenGL require the definition of
-Source code also exists in the tree for other drivers in
+  GLIDE2SDK as an environment variable pointing to where your copy of the
-src/mesa/drivers/windows, but the status of this code is unknown.
+  Glide SDK has been installed. Adding this to your AUTOEXEC.BAT would do
-
+  so (change the directories to match):
-
+
-General
+       SET GLIDE2SDK=G:\SDK\GLIDE2X
--------
+
-
+*** Legalese
-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
+These build files are provided as-is and are submitted to be included with
-in a system directory, place them in the same directory as the
+the "Mesa 3-D Graphics Library" package as (currently) maintained by Brian
-executable(s).  Be careful about accidentially overwriting files of
+Paul. These project build files are free software; you can redistribute it
-the same name in the SYSTEM32 directory.
+and/or modify it under the terms of the GNU Library General Public License
-
+as published by the Free Software Foundation; either version 2 of the
-The DLL files are built so that the external entry points use the
+License, or (at your option) any later version.
-stdcall calling convention.
+
-
+These project files are distributed in the hope that they will be useful,
-Static LIB files are not built.  The LIB files that are built with are
+but WITHOUT ANY WARRANTY; without even the implied warranty of
-the linker import files associated with the DLL files.
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Library
-
+General Public License for more details.
-The si-glu sources are used to build the GLU libs.  This was done
+
-mainly to get the better tessellator code.
+You should have received a copy of the GNU Library General Public License
-
+along with this library; if not, write to the Free Software Foundation,
-If you have a Windows-related build problem or question, please post
+Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-to the mesa-dev or mesa-users list.
+
+*** Maintenance Responsiblity and Technical Support
+
+While these files are now part of the Mesa core distribution please do NOT
+contact Mr. Paul for help with them if you encounter problems as he can't
+help you (currently).  I will, however, attempt my straightforward best in
+assisting anyone with using these files on their system.  I can NOT
+guarantee instant responses owing to other responsiblities, but I do try
+dang hard to answer any mail w/in 24 hours.  I may be contacted at the
+above email address for the forseeable future.
+
+-Ted
+mailto://tjump@tertius.com
+http://www.tertius.com/tjump
+
+*** General Information
+
+These build files facilitate convenient building of many variants of Mesa,
+both as static link libraries (including mesaglu) and as dynamic link
+libraries that in some cases may be used as "drop-in" replacements for
+OpenGL32.DLL on both Windows95 and Windows NT.
+
+The construction of the Win32 command-line build files and projects has
+been something of a pet project of mine, and is based upon my own
+"standard" Win32 build environment as supplied by the "nmake.mif" file.
+They have been tested under Windows95 OSR2, Windows NT 4.0SP3, and Windows
+NT 5.0 beta 1.  The libraries that they generated have been tested (via the
+demo programs) in a *limited* fashion on the above three systems, including
+the 3Dfx versions.
+
+The reason I went with command-line build environment instead of the more
+convenient IDE-based project files is for two reasons: 1. These appear to
+have some amount of portability between versions (the nmake syntax hasn't
+changed much since Microsoft C 7.0) while the IDE project files seem to
+change drastically each version. and 2. These are readable with any ascii
+editor and such are better self-documentation of the file relationships for
+more people such that it will facilitate supporting other Win32 compilers.
+
+While these files only deal with building for x86 targeted code it *should*
+be possible to add the necessary logic to them to build for the other MSVC
+supported CPU targets, I simply have no hardware to test them on nor the
+alternative compilers to build with.
+
+*** Prerequisites for use
+
+1. You must have a 32-bit Microsoft compiler installed. I have tested
+this with Visual C 5.0 (SP3) and Visual C 4.2, but with minor
+(possibly no) modification to the nmake.mak and nmake.mif files this
+sequence should work on Visual C 2.0 also. The workspace files
+(mesalib.dsw and mesademos-*.dsw) and their included project files
+(*.dsp) are specific to the DevStudio IDE - I have made no attempt at
+building a VC4 IDE project set as I do not use that any more.  Note
+that the VC workspace files NO LONGER use NORE are dependant upon the
+nmake.mak and nmake.mif files for construction of definition (*.DEF)
+and resource (*.RC) files.
+
+*** Visual C 4.x Users Warning ****
+
+Note that early editions of VC4 do NOT have header files current enough
+for use building this code base. If you are using VC4 you will either need
+to get an update to version 4.2 *or* you may download the Platform SDK
+directly from Microsoft's web site (www.microsoft.com) and update your
+build environment that way.
+
+*** Visual C 4.x Users Warning ****
+
+2. You must have the PATH, INCLUDE, and LIB environment variables set
+properly. With VC5 you can easily get this by executing the VCVARS32.BAT
+file that was created for you upon installation. It is found in the
+DevStudio\VC\BIN directory, wherever you installed DevStudio. VC4 provides
+a similar batch file in it's BIN directory also.
+
+3. (optional) If you're going to build for 3Dfx/Voodoo you will need to
+have previously installed the Glide SDK version 2.3 or later, if I
+recall. This may be retrieved from www.3dfx.com for no money and some
+download time. ;-) These build files assume that you have the Glide SDK
+added to the respective environment variables (LIB and INCLUDE).
+
+4. (optional) If you're going to build for S3/Virge you will need the S3
+Developers Toolkit which may be downloaded from www.s3.com for the price of
+registering on-line and some time. NOTE: I can build the s3mesa.dll file to
+completion, however the compilation of s3mesa.c currently generates a large
+amount of compiler warnings and between that and the fact that I can not at
+all test it I can make no claims to it's ability to execute.  Again, like
+the 3Dfx version before this, these build files assume you have the S3Dtk H
+and LIB files in the path of their respective environment variables.
+Note 2: As of Mesa3.0beta6 I have build files, both command-line and IDE,
+which should be able to build the s3mesa code base if it weren't for updates
+being required in the S3 DD code support (Mesa-3.0/src/s3 directory).
+
+I advise putting any include and lib files for secondary toolkits (Glide,
+S3Tk, whatever) in their respective environment variables *before* the
+Microsoft-assigned default values.
+
+*** FAQ: Frequenty Asked Questions and Other Important Information ***
+
+- When running the 3Dfx demos under Windows NT, they crash on exit, what's
+  up?
+
+  This is apparently a problem in Glide itself. The workaround is to go to
+  your C:\WINNT\SYSTEM32 directory and rename the file FXOEM2X.DLL to
+  FXOEM2X.DL_ to prevent Glide from loading and initializing it upon
+  startup.  This is known to be an issue with cards that do not have "TV
+  out" and is known to cause crashes on Diamond Monster II 8M and 3Dfx
+  Reference boards, all using 3Dfx Reference Drivers version 2.53. Other
+  hardware/driver combinations will also likely exhibit this behavior.
+
+- I'm having a problem building Mesa for static library linking.
+
+  This was caused by some incomplete testing on my part, and a fix is now
+  available in the form of an add-on to the base Mesa 3.0 release.  The
+  file to get is:
+
+       via FTP download from: iris.ssec.wisc.edu
+         you want to go here: /pub/Mesa/patches_to_3.0/
+        you want to get file: Mesa-3.0-w32-static-fixes.tar.gz
+
+  This required a minor addition to INCLUDE/GL for a clean solution, the
+  file "include/gl/mesa_wgl.h" is automatically included by
+  "include/gl/gl.h" when a Win32 non-DLL build is in progress to provide
+  prototypes for the various wgl functions.
+
+  The only remaining hitch in this setup is that the 3Dfx build is not yet
+  running as a static build, because of problems with conflicts in
+  existance of the various GDI functions like ChoosePixelFormat,
+  etc. *sigh*
+
+  Anyway, the "allstatic" target now works as expected and builds all
+  book/sample/demos programs to boot. ;^)
+
+- How do I get fxMesa to render in a window on the desktop instead of only
+  full-screen?
+
+  Use the Microsoft Windows fxMesa-in-a-window hack!
+
+  Seriously, if you want fxMesaGL to render using the 3Dfx Voodoo1 or
+  Voodoo2 hardware into a window on the desktop then all you need to do is
+  set the MESA_WGL_FX environment variable to anything other than
+  "fullscreen" and it will render into a window.  If you wish to go
+  fullscreen then you only need to NOT have the environment variable, or
+  have it set to "fullscreen".  You may also switch at runtime between
+  fullscreen-mode and windowed by pressing ALT-ENTER on the keyboard
+  (unless the application using Mesa does something with those keystrokes,
+  of course).
+
+  As of 8/13/98 this should be running a LOT better for more people as a
+  low-compatability item was cleaned up which prevented it from working on
+  many (most?) display drivers under Windows 9x.
+
+- I have my 3Dfx card hooked to it's own monitor and I want the output to
+  stay on even if I switch to another program, is this possible?
+
+  If the Glide environment variable SST_DUALHEAD is set to '1' then fxMesa
+  will never disable the Voodoo output on a Voodoo1 or Voodoo2 display
+  regardless of whether the fxMesa application is "current" or not. This
+  works regardless of whether it's rendering using the window hack
+  mentioned above or not.
+
+- I want to run the Mesa demos on my Intel740 card using it's own OpenGL
+  acceleration, how do I do this?
+
+  Build GLUT standalone for use with system OpenGL and GLU drivers!
+
+  The Command-line project supports building all test/demo programs against
+  these drivers also! This allows you full use of GLUT on Windows using
+  hardware accelerated OpenGL. Wheee! This includes the "3dfx/demos"
+  directory of which only two programs will not run on "standard"
+  opengl. Note that there are a few of the sample programs which will NOT
+  work without Mesa as they directly call into Mesa instead of using the
+  extension mechanism.
+
+*** Included programs that exhibit unfortunate or bad behavior
+
+- demos/bounce - doesn't run on high-colors screens?  It's requesting an
+  INDEX display from GLUT and that fails on my true-color desktop. Changing
+  this to _RGB let's the program work, but it doesn't display
+  properly. This is probably just an idiosyncracy of my machine though, as
+  if I test the program using GLUT for System OpenGL on my Intel740 OpenGL
+  accelerated machine it's just hunky-dory.
+
+- demos/glutfx - runs, but crashes on exit (but not on my Intel740 machine)
+
+- demos/texobj - runs, but crashes on exit if ESC is pressed. Exits cleanly
+  if the Close box on the window frame is pressed with the mouse. Go figure.
+
+- book/aaindex - doesn't run, can't get pixel format, because it wants an
+  INDEX display maybe (but is okay on my Intel740 machine)?
+
+- most of the book/* demos don't respond to ESC being pressed.
+
+- 3dfx/demos/* - all demos run, however they all crash on exit. I've traced
+  this so far as to determine the call it's happening with. The crash comes
+  from within Glide during the processing of the grGlideShutdown() call, as
+  in invalid memory reference exception. I'm wondering if this is because
+  of some state or processing not being completed before the call. Dunno,
+  but putting grSstIdle() in just before grGlideShutdown() does NOT fix the
+  problem.
+
+- 3dfx/demos/tunnel2 - does not run on my system even with SLI mode
+  disabled. Hmmmm, maybe I need to disconnect my Voodoo2 cards?
+
+*** Important Notes and Changing Default values
+
+- The optimizer settings have been manually reworked in both command line
+  and DevStudio IDE files to hopefully prevent possible irrational code on
+  the part of the code generator.  Formerly, it was configured for "/Ox",
+  now it is configured for safer handling at a slight potential performance
+  cost. This may not be required for Visual Studio 6 but I can't test that
+  (yet).
+
+- These files build with the code targeted for Pentium processors and
+  8-byte structure padding.
+
+- The IDE-built programs seem to be "happier" in that the command line
+  build of the 3Dfx demo "fire" will grenade on exit (?). Otherwise pretty
+  much everything may be built with either interface.
+
+- The currently configured Mesa version is 3.1, and MesaDemos version is
+  the same. To change this permanently you will need to edit NMAKE.MAK and
+  change the lines that look like this (they start o/a line 116):
+
+    # Currently, Mesa is at rev 3.1 ...
+    #
+    !IF "$(MESAVER)" == ""
+    MESAVER=3.1
+    !ENDIF
+
+    # used in building all of the resource files for the Mesa DLLs
+    #
+    !IF "$(MESAFILEVER)" == ""
+    MESAFILEVER=3,1,0,0
+    !ENDIF
+
+- Currently the build files are configured to be used from a Win32
+  directory that is included inside the main Mesa-3.1 heirarchy.
+
+- The build files are smart enough to find the files for the core lib, glu,
+  glut, and the various demo programs if they are unpacked in the current
+  Mesa-3.1 heirarchy, like this:
+
+    \Mesa-3.1
+    \Mesa-3.1\src
+    \Mesa-3.1\src-glu
+    \Mesa-3.1\src-glut
+    \Mesa-3.1\Win32
+    \Mesa-3.1\samples
+    \Mesa-3.1\demos
+    \Mesa-3.1\book
+    \Mesa-3.1\3Dfx\demos
+
+    ... should work.  This arose because my initial build tests for the
+    demo files were done before MesaDemos 2.6 had been released.
+
+- With the exception of the static link libraries generated by this file
+  set (mesagl.lib, mesaglu.lib, mesaglut.lib) all DLLs and executables are
+  built against the "Multithreaded DLL" runtime - this means that they
+  require MSVCRT.DLL or MSVCRTD.DLL in the path to execute.
+
+  ** CHANGED 8/11/98 ***
+
+  Note also that the demos are all built aginst the "OpenGL32, GLU32, and
+  GLUT32" and as such they are fairly agnostic wrt: building against Mesa
+  for CPU-rendering, Mesa-for-3Dfx, Mesa-for-S3, or System OpenGL.
+
+  If you want to build them for use on your system and your display card
+  provides full OpenGL acceleration (Permedia, Intel740, Intergraph,
+  whatever) then you only need to build GLUT prior to building any of the
+  demo programs. For convenience, the GLUT project is included in each of
+  the demo projects Workspace files for the DevStudio IDE builds BUT it is
+  not automatically built - you still need to build it first manually.
+
+  Note that if you have GLUT already installed on your system (gl/glut.h in
+  yoru INCLUDE path, glut32.lib/glut32d.lib in your LIB path, and the DLL
+  in your PATH) then you do NOT need to build GLUT prior to the test
+  programs.
+
+- The 3Dfx build of Mesa has primarily been tested with Quake 2 and it runs
+  (mostly) fine on my PC (take that for what you want it)...
+
+  ** CHANGED  8/11/98 ***
+
+  There is still something going on that causes Glide to crash on shutdown,
+  when I run fxMesa under Windows NT, however it does not appear to occur
+  under Windows 9x on either Voodoo1 or Voodoo2 cards. *sigh*
+
+- I can not test the S3 build as I have no machines available with Virge
+  based display cards.
+
+- The multithreaded test code is *not* built as it requires pthreads and I
+  have as of yet spent not time trying to get that running. The latest word
+  that I saw WRT threading support on win32 was that they are intending to
+  support it natively within Win32 - so I'm waiting it out until they get
+  it done.
+
+- Similarly, the 'xdemos' are not currently built because I haven't gotten
+  around to building the client libs for native win32 and getting it all
+  setup for use.
+
+*** Output Files
+
+All final output files (DLL/LIB) are placed in the Mesa-3.1/lib directory,
+with the exception of the fxMesaGL32 build which is placed in
+Mesa-3./lib/FX and the executable images which are placed in their source
+directories.
+
+To be able to execute the various test programs, you will need to copy the
+requisite DLL files into the same directory as the EXE files. Note that
+most of the 3Dfx/demos/* programs WILL run with the non-FX build of Mesa -
+just very slowly. The two programs which are hard-linked with the FX build
+and will not run without it are "glbpaltx" which uses "gl3DfxSetPaletteEXT"
+directly instead of via the extensions mechanism and "tunnel2" which uses
+"fxMesaSelectCurrentBoard" API for selecting between multiple 3Dfx cards
+installed in one system. Likewise, "paltex" directly uses the
+"glColorTableEXT" extension and thus may not run on anything except
+Mesa. If these applications used the proper extension mechanism they could
+then be used on more than "just" fxMesa to good effect (for example, the
+rest of the "3Dfx/demos" run just peachy on the Intel740 card in my test
+machine) under WinNT.
+
+Because I'm anal about my computer and it's organization, and I like to
+prevent collision between builds, each of the subprojects has their own
+intermediate file directory inside .\win32\release (for example, when
+building mesagl.lib all of it's intermediate files will be found in
+.\win32\release\lib.mesagl).  This makes it very easy to cleanup as you
+only need to remove .\win32\release.
+
+*** Okay, Enough, how do I build with this stuff already Ted!
+
+Okay, no major calamity here. The basic way to use the project file is to
+call it via NMAKE from the command line. The format is:
+
+    nmake[.exe] /f nmake.mak [options] [target]
+
+The most likely [options] values you will use may be any combination of the
+following:
+
+    DEBUG=1 or DEBUG=0
+    USE_CRTDLL=1 or USE_CRTDLL=0
+
+    Note that all three of these options are OFF by default.
+
+The [target] includes but is not limited to the following (for full details
+please peruse the NMAKE.MAK and NMAKE.MIF files - but be warned that
+NMAKE.MIF is rather large and sometimes hard to follow):
+
+    --- convenience targets ---
+
+    all                 - builds everything
+    libfiles            - builds all linking library files
+    progs               - builds all executable images
+
+    --- library files, static and dynamic ---
+
+    mesagl              - static lib build of Mesa core.
+    mesaglu             - static lib build of MesaGLU core.
+    mesaglut            - static lib build of Mesa GLUT core.
+
+    mesagl32            - dynamic lib build of Mesa core.
+
+    mesaglu32           - dynamic lib build of GLU core, generates
+                          GLU32.DLL and/or GLU32d.DLL.
+
+    mesaglut32          - dynamic lib build of GLUT core, generates
+                          GLUT32.DLL and/or GLUT32d.dll.
+
+    --- hardware accelerated mesa builds ---
+
+    fxmesagl32          - builds Mesa for use on top of the 3Dfx
+                          Glide runtime libs
+
+    s3mesagl32          - builds mesa for use on top of the S3
+                          'S3Tk' runtime libs.
+
+    --- executable images ---
+
+    progs.book          - builds all programs in \book directory
+    progs.demos         - builds all programs in \demos directory
+    progs.samples       - builds all programs in \samples directory
+
+        These targets generate all of the programs in their respective
+        directories and link the executables against OpenGL32.DLL,
+        GLU32.DLL, and GLUT32.DLL (or their debug equivalents).
+
+    progs.3dfx.demos    - builds all programs in \3dfx\demos directory
+
+        This target generates the 3Dfx/Demo executables, linking them
+        against GLUT32.DLL, GLU32.DLL, OPENGL32.DLL and are thus NOT
+        hard-bound to using Mesa per-se as you can simply NOT build the
+        Mesa core and GLU libraries.
+
+   --- Microsoft/SGI OpenGL-based GLUT and Demo program builds ----
+
+   *** IMPORTANT SAFETY TIP: If you're going to build these variants of
+       GLUT then DO NOT build any other target libraries in this package
+       first, OR from the command line run the "nmake /f nmake.mak clean"
+       command first!  This is because generation of the GLUT for SGI
+       OpenGL target libraries conflicts in naming with the static build
+       libraries of Mesa and it's supporting GLUT build.
+
+   Currently, you may build GLUT as either GLUT32.DLL or GLUT.DLL for
+   use running against either Microsoft or SGI OpenGL for Window,
+   respectively.  This allows for the general use of GLUT 3.7 on Windows
+   systems with fully compliant OpenGL.
+
+   You can build the GLUT DLL files either with the command line by
+   issuing either of these commands:
+
+        nmake /f nmake.mak glut.sysgl
+
+        <or>
+
+        nmake /f nmake.mak glut.sgigl
+
+   OR by using the DevStudio MesaLib Worksapce build the GLUT_SGIGL or
+   GLUT_SYSGL projects within the DevStudio IDE.
+
+   Unfortunately, the only way to build the test programs against this
+   build of GLUT is via the command line, and I will NOT be making
+   duplicate demo program projects for the IDE as it's just not worth it,
+   sorry.
+
+   To build the test programs against either MS or SGI OpenGL, you do so
+   via either of these two commands:
+
+        nmake /f nmake.mak progs.sysgl
+
+        <or>
+
+        nmake /f nmake.mak progs.sgigl
+
+   To use the GLUT-for-system-OpenGL in your own programs, you need to do
+   three things by way of preparation, after building GLUT of course:
+
+         1. Copy include\gl\glut.h to somewhere in your %INCLUDE% path, one
+            likely candidate location would be in your
+            "DevStudio\VC\INCLUDE\GL" directory.
+
+         2. Copy the linking libraries to somewhere in your %LIB% path, one
+            likely candidate location would be in your "DevStudio\VC\LIB"
+            directory. The linking libraries you need to copy are as
+            follows:
+
+                .\Release\GLUT32.LIB
+                .\Release\GLUT.LIB
+                .\Debug\GLUT32.LIB
+                .\Debug\GLUT.LIB
+
+        3. Copy the runtime libraries to somewhere in your %PATH%, one
+           likely candidate location would be in WINDOWS\SYSTEM. the files
+           that you should copy are as follows:
+
+                .\Release\GLUT32.DLL
+                .\Release\GLUT32.PDB
+                .\Release\GLUT.DLL
+                .\Release\GLUT.PDB
+                .\Debug\GLUT32d.DLL
+                .\Debug\GLUT32d.PDB
+                .\Debug\GLUTd.DLL
+                .\Debug\GLUTd.PDB
+
+Some examples are in order ...
+
+    ... build all dynamic-link libs using MSVCRT.DLL for C runtime:
+
+        nmake /f nmake.mak USE_CRTDLL=1 alldynamic
+
+    ... To build all library variants and all test and demonstration
+        programs with the default settings you do this:
+
+        nmake /f nmake.mak all
+
+    ... to build all static link libs and nothing else you do this:
+
+        nmake /f nmake.mak allstatic
+
+    ... to build all non-accelerated dynamic link libs you do this:
+
+        nmake /f nmake.mak alldynamic
+
+    ... to build all 3Dfx targeted dynamic link libs you do this:
+
+        nmake /f nmake.mak allaccel
+
+    ... to build all S3 Virge targetd dynamic link libs you do this:
+
+        nmake /f nmake.mak alls3
+
+    ... to build all libraries, static and dynamic, in all versions
+        you do this:
+
+        nmake /f nmake.mak libfiles
+
+    ... to subsequently build all demo and test programs you do this:
+
+        nmake /f nmake.mak progs
+
+    ... to cleanup all intermediate files you do this:
+
+        nmake /f clean
+
+You get the picture. (I hope) ;^)  You may also specify specify
+single targets in a convenient fashion. The rule is simple, any of the
+above named lib files, static or dynamic, may be built by providing it's
+name on the command line as the target. Examples:
+
+    ... to build only Mesa as OpenGL32.DLL ...
+
+        nmake /f nmake.mak opengl32
+
+    ... to build only Mesa on top of the 3Dfx Glide API ...
+
+        nmake /f nmake.mak fxMesaGL32
+              <or>
+        nmake /f nmake.mak fxMesaGL
+
+    ... to build only Mesa on top of the S3 Toolkit ...
+
+        nmake /f nmake.mak s3MesaGL32
+              <or>
+        nmake /f nmake.mak s3mesaGL
+
+*** Revision history for ./win32 project files
+
+1/18/98 - initial cut submitted and included with core mesa
+2/5/98  - fixed internal dependency within nmake.mif upon there being
+          a $(DEVDIR) variable to make some temporary batch files
+          dependant upon (thanks to Keven T. McDonnell for finding
+          that there was this particular bug). I also updated the
+          build files for 2.6beta6.
+2/8/98  - added DevStudio workspace and project files for all lib
+          files and some test programs. Updated readme.win32.
+6/25/98 - initial revision for Mesa 3.0, does not include IDE files,
+          not everything is running. *sigh*
+7/20/98 - Mesa 3.0beta6 rev of all build files, all libs built and
+          minimally tested, all demo programs built and minimally
+          tested to within limits of my PC. ;^) Eveything looks
+          MUCH better now ...
+7/30/98 - Minor updates/edits based upon feedback from
+          Eero Pajarre <epajarre@koti.tpo.fi>. These updates include a fix
+          to the Mesa-on-3Dfx build such that Quake-II now runs almost
+          properly on my system. It runs, just *very* slowly and with *no*
+          textures. Hmmm. Doesn't make any difference whether Quake is set
+          to use 8-bit textures or not.
+8/13/98 - Lots of build cleanups, minor bug fixes in fxwgl.c, and
+          compatability fix in fxapi.c for in-window rendering using 3Dfx
+          hardware.
+8/26/98 - Final revisions for Mesa 3 release checked
+9/22/98 - Fixed static builds for all but fxMesaGL32 and s3MesaGL32 targets
+9/29/98 - Reorganized FAQ information and added Added faq entry about Glide
+          bug under NT (crash on exit) and a workaround.
+11/21/98 - Updated files for Mesa 3.1 beta 1
+           Updated fxMesa window-hack code
+           Updated fxMesa resolution support to handle 1600x1200 & 1280x1024
+7/9/99  - Rev'd for Mesa 3.1 beta 2

docs/README.X11

@@ -0,0 +1,316 @@
+
+                         Mesa 3.0 Unix/X11 Information
+
+
+
+Installation
+============
+
+To compile the library, first type 'make' alone to see the list of system
+configurations currently supported.  If you see your configuration on the
+list, type 'make <config>'.  Most popular Unix/X workstations are currently
+supported.
+
+The top-level makefile will execute the makefiles in a number of sub-
+directories.  When finished, the Mesa libraries will be in the Mesa-2.6/lib/
+directory.  A few GLUT demos in the demos/ directory should be ready to run.
+
+If you also downloaded and unpacked the demos there should be executables
+in the "xdemos/", "samples/", and "book/" directories for you to try out.
+If you only want to compile the contents of one subdirectory you can 'cd'
+to that directory and type 'make <config>' there.
+
+If your system configuration is not listed by 'make', you'll have to modify
+the top-level Makefile and Make-config files.  There are instructions in
+each file.
+
+If you have compilation problems you should try to fix them and return the
+patches to the author.
+
+
+Header and library files:
+   After you've compiled Mesa and tried the demos I recommend the following
+   procedure for "installing" Mesa.
+
+   Copy the Mesa include/GL directory to /usr/local/include:
+	cp -r include/GL /usr/local/include
+
+   Copy the Mesa library files to /usr/local/lib:
+	cp lib/* /usr/local/lib
+
+	(actually, use "cp -d" on Linux to preserve symbolic links)
+
+   Create a few symbolic links so that compiling OpenGL applications is easy:
+	cd /usr/local/lib
+	IF USING STATIC (lib*.a) FILES THEN
+		ln -s libMesaGL.a libGL.a
+		ln -s libMesaGLU.a libGLU.a
+	ELSE
+		ln -s libMesaGL.so libGL.so
+		ln -s libMesaGLU.so libGLU.so
+	ENDIF
+
+
+Xt/Motif widgets:
+   If you want to use Mesa or OpenGL in your Xt/Motif program you can build
+   the widgets found in either the widgets-mesa or widgets-sgi directories.
+   The former were written for Mesa and the later are the original SGI
+   widgets.  Look in those directories for more information.
+
+
+Notes:
+   HP users:  a Mesa user reports that the HP-UX 10.01 C compiler has
+   a bug which effects glReadPixels.  A patch for the compiler (PHSS_5743) is
+   available.  Otherwise be sure your compiler is version 10.13 or later.
+
+   QNX users:  if you have problems running the demos try setting the
+   stack size to 200K or larger with -N200K, for example.
+
+   SunOS 5.x users:  The X shared memory extension may not work
+   correctly.  If Mesa prints an error message to the effect of "Shared memory
+   error" then you'll have to append the following three lines to the end of
+   your /etc/system file then reboot:
+      set shmsys:shminfo_shmmax = 0x2000000
+      set shmsys:shminfo_shmmni = 0x1000
+      set shmsys:shminfo_shmseg = 0x100
+
+
+
+Using the library
+=================
+
+Configuration options:
+   The file src/config.h has many parameters which you can adjust such
+   as maximum number of lights, clipping planes, maximum texture size,
+   etc.  In particular, you may want to change DEPTH_BITS from 16 to 32
+   if a 16-bit depth buffer isn't precise enough for your application.
+
+
+Shared libraries:
+   If you compile shared libraries you may have to set an environment
+   variable to specify where the Mesa libraries are located.  On Linux and
+   Sun systems for example, set the LD_LIBRARY_PATH variable to include
+   /your-dir/Mesa-2.6/lib.   Otherwise, when you try to run a demo it
+   may fail with a message saying that one or more libraries couldn't be
+   found.
+
+
+Remote display of OpenGL/GLX programs:
+   As of version 1.2.3, Mesa's header files use the same GLenum and GLUenum
+   values as SGI's (and most/all other vendor's) OpenGL headers.  This means
+   you can freely mix object files compiled with OpenGL or Mesa headers.
+   In fact, on systems with dynamic runtime linkers it's possible to dynam-
+   ically link with Mesa or OpenGL shared libraries at runtime, without
+   recompiling or relinking anything!
+
+   Using IRIX 5.x as an example, you can run SGI's OpenGL demos with the
+   Mesa shared libraries as follows.  Let's assume you're installing Mesa
+   in /usr/local/Mesa and using the C-shell:
+       % cd /usr/local/Mesa
+       % make irix5-dso
+       % cd lib
+       % ln -s libMesaGL.so libGL.so
+       % setenv _RLD_LIST "/usr/local/Mesa/lib/libGL.so:DEFAULT"
+       % /usr/demos/bin/ideas_ogl      // this is a test
+
+   You can now run OpenGL executables on almost any X display!  There may
+   be some problems from the fact that Mesa supports many X visual types
+   that an OpenGL client may not expect (grayscale for example).  In this
+   case the application may abort, print error messages, or just behave
+   strangely.  You may have to experiment with the MESA_RGB_VISUAL envi-
+   ronment variable.
+
+
+Xt/Motif Widgets:
+   Two versions of the Xt/Motif OpenGL drawing area widgets are included:
+
+      widgets-sgi/	SGI's stock widgets
+      widgets-mesa/	Mesa-tuned widgets
+
+   Look in those directories for details
+
+
+Togl:
+   Togl is an OpenGL/Mesa widget for Tcl/Tk.
+   See http://www.ssec.wisc.edu/~brianp/Togl.html for more information.
+
+
+
+X Display Modes:
+   Mesa supports RGB(A) rendering into almost any X visual type and depth.
+
+   The glXChooseVisual function tries its best to pick an appropriate visual
+   for the given attribute list.  However, if this doesn't suit your needs
+   you can force Mesa to use any X visual you want (any supported by your
+   X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
+   environment variables.  When an RGB visual is requested, glXChooseVisual
+   will first look if the MESA_RGB_VISUAL variable is defined.  If so, it
+   will try to use the specified visual.  Similarly, when a color index
+   visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
+   variable.
+
+   The format of accepted values is:  <visual-class> <depth>
+   Here are some examples:
+
+   using the C-shell:
+	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor
+	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor
+	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor
+
+   using the KornShell:
+	$ export MESA_RGB_VISUAL="TrueColor 8"
+	$ export MESA_CI_VISUAL="PseudoColor 12"
+	$ export MESA_RGB_VISUAL="PseudoColor 8"
+
+
+Double buffering:
+   Mesa can use either an X Pixmap or XImage as the backbuffer when in
+   double buffer mode.  Using GLX, the default is to use an XImage.  The
+   MESA_BACK_BUFFER environment variable can override this.  The valid
+   values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first
+   letter is checked, case doesn't matter).
+
+   A pixmap is faster when drawing simple lines and polygons while an
+   XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you
+   need depth buffering the XImage will almost surely be faster.  Exper-
+   iment with the MESA_BACK_BUFFER variable to see which is faster for
+   your application.  
+
+
+Colormaps:
+   When using Mesa directly or with GLX, it's up to the application writer
+   to create a window with an appropriate colormap.  The aux, tk, and GLUT
+   toolkits try to minimize colormap "flashing" by sharing colormaps when
+   possible.  Specifically, if the visual and depth of the window matches
+   that of the root window, the root window's colormap will be shared by
+   the Mesa window.  Otherwise, a new, private colormap will be allocated.
+
+   When sharing the root colormap, Mesa may be unable to allocate the colors
+   it needs, resulting in poor color quality.  This can happen when a
+   large number of colorcells in the root colormap are already allocated.
+   To prevent colormap sharing in aux, tk and GLUT, define the environment
+   variable MESA_PRIVATE_CMAP.  The value isn't significant.
+
+
+Gamma correction:
+   To compensate for the nonlinear relationship between pixel values
+   and displayed intensities, there is a gamma correction feature in
+   Mesa.  Some systems, such as Silicon Graphics, support gamma
+   correction in hardware (man gamma) so you won't need to use Mesa's
+   gamma facility.  Other systems, however, may need gamma adjustment
+   to produce images which look correct.  If in the past you thought
+   Mesa's images were too dim, read on.
+
+   Gamma correction is controlled with the MESA_GAMMA environment
+   variable.  Its value is of the form "Gr Gg Gb" or just "G" where
+   Gr is the red gamma value, Gg is the green gamma value, Gb is the
+   blue gamma value and G is one gamma value to use for all three
+   channels.  Each value is a positive real number typically in the
+   range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling
+   gamma correction.  Examples using csh:
+
+	% setenv MESA_GAMMA "2.3 2.2 2.4"	// separate R,G,B values
+	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B
+
+   The demos/gamma.c program may help you to determine reasonable gamma
+   value for your display.  With correct gamma values, the color intensities
+   displayed in the top row (drawn by dithering) should nearly match those
+   in the bottom row (drawn as grays).
+
+   Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
+   on HP displays using the HP-ColorRecovery technology.
+
+   Mesa implements gamma correction with a lookup table which translates
+   a "linear" pixel value to a gamma-corrected pixel value.  There is a
+   small performance penalty.  Gamma correction only works in RGB mode.
+   Also be aware that pixel values read back from the frame buffer will
+   not be "un-corrected" so glReadPixels may not return the same data
+   drawn with glDrawPixels.
+
+   For more information about gamma correction see:
+   http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
+
+
+Overlay Planes
+
+   Overlay planes in the frame buffer are supported by Mesa but require
+   hardware and X server support.  To determine if your X server has
+   overlay support you can test for the SERVER_OVERLAY_VISUALS property:
+
+	xprop -root | grep SERVER_OVERLAY_VISUALS
+
+
+HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
+
+   If you set the MESA_HPCR_CLEAR environment variable then dithering
+   will be used when clearing the color buffer.  This is only applicable
+   to HP systems with the HPCR (Color Recovery) system.
+
+
+Extensions:
+   The following OpenGL GLX extensions are currently implemented:
+
+      GLX_EXT_visual_info - GLX visual and transparent pixel extension
+
+   For detailed information about the extensions see www.opengl.org
+
+   There are four Mesa-specific GL/GLX extensions at this time.
+
+   GLX_MESA_pixmap_colormap 
+
+      This extension adds the GLX function:
+
+         GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
+                                           Pixmap pixmap, Colormap cmap )
+
+      It is an alternative to the standard glXCreateGLXPixmap() function.
+      Since Mesa supports RGB rendering into any X visual, not just True-
+      Color or DirectColor, Mesa needs colormap information to convert RGB
+      values into pixel values.  An X window carries this information but a
+      pixmap does not.  This function associates a colormap to a GLX pixmap.
+      See the xdemos/glxpixmap.c file for an example of how to use this
+      extension.
+
+   GLX_MESA_release_buffers
+
+      Mesa associates a set of ancillary (depth, accumulation, stencil and
+      alpha) buffers with each X window it draws into.  These ancillary
+      buffers are allocated for each X window the first time the X window
+      is passed to glXMakeCurrent().  Mesa, however, can't detect when an
+      X window has been destroyed in order to free the ancillary buffers.
+
+      The best it can do is to check for recently destroyed windows whenever
+      the client calls the glXCreateContext() or glXDestroyContext()
+      functions.  This may not be sufficient in all situations though.
+
+      The GLX_MESA_release_buffers extension allows a client to explicitly
+      deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
+      just before an X window is destroyed.  For example:
+
+         #ifdef GLX_MESA_release_buffers
+            glXReleaseBuffersMESA( dpy, window );
+         #endif
+         XDestroyWindow( dpy, window );
+
+      This extension is new in Mesa 2.0.
+
+   GLX_MESA_copy_sub_buffer
+
+      This extension adds the glXCopySubBufferMESA() function.  It works
+      like glXSwapBuffers() but only copies a sub-region of the window
+      instead of the whole window.
+
+      This extension is new in Mesa version 2.6
+
+
+
+Summary of X-related environment variables:
+   MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
+   MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
+   MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
+   MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
+   MESA_GAMMA - gamma correction coefficients (X only)
+
+
+----------------------------------------------------------------------
+$Id: README.X11,v 3.2 1998/10/03 12:48:50 brianp Exp $

docs/RELNOTES-3.1

@@ -1,145 +0,0 @@
-
-                         Mesa 3.1 release notes
-
-                             PLEASE READ!!!!
-
-
-New copyright
--------------
-
-Mesa 3.1 will be distributed under an XFree86-style copyright instead
-of the GNU LGPL.
-
-
-New directories
----------------
-
-All documentation files are now in the docs/ directory.
-All shell scripts are now in the bin/ directory.
-
-
-New library names
------------------
-
-Formerly, the main Mesa library was named libMesaGL.so (or libMesaGL.a)
-and the GLU library was named libMesaGLU.so (or libMesaGLU.a).
-
-Now, the main library is named libGL.so (or libGL.a) and the GLU library
-is named libGLU.so (or libGLU.a).
-
-The change allows Mesa to be more easily substituted for OpenGL.
-Specifically, the linker/loader on some Unix-like systems won't
-allow libMesaGL.so to be used instead of libGL.so if the application
-was linked with the former.
-
-Warning: if you have another OpenGL implementation installed on your
-system (i.e. you have another OpenGL libGL.so) you'll have to be
-carefull about which library (OpenGL or Mesa) you link against.  Be
-aware of -L linker flags and the value of the LD_LIBRARY_PATH environment
-variable.
-
-
-New library versioning
-----------------------
-
-Previously, the Mesa GL library was named libMesaGL.so.3.0
-To better support Linux/OpenGL standards, the Mesa GL library is now
-named libGL.so.1.2.030100  This indicates version 1.2 of the OpenGL spec
-and Mesa implementation 3.1.0
-
-In the long term this will allow better interoperability with other
-OpenGL implementations, especially on Linux.  In the short term,
-OpenGL apps may have to be relinked to use the new library naming.
-
-
-
-New makefiles
--------------
-
-The old Makefiles found in the various directories have been renamed
-to Makefile.X11 in order to prevent filename collisions with autoconfig-
-generated Makefiles.
-
-The top-level Makefile simply includes Makefile.X11
-If your top-level Makefile get's overwritten/destroyed you can restore
-it by copying Makefile.X11 to Makefile
-
-
-New extensions
---------------
-
-GL_EXT_stencil_wrap
-	Implements two new stencil operations: GL_INCR_WRAP_EXT and
-	GL_DECR_WRAP_EXT which allow stencil increment and decrement
-	without clamping.
-
-GL_INGR_blend_func_separate
-	Allows specification of blend factors for RGB and Alpha independently.
-	(INGR = Intergraph)
-
-GL_ARB_multitexture
-	Multiple simultaneous textures.  (ARB = Architecture Review Board)
-
-GL_NV_texgen_reflection
-	nVidia texgen extension for better reflection mapping.
-
-GL_PGI_misc_hints
-	Assorted transformation hints.
-
-GL_EXT_compiled_vertex_array
-	Compiled vertex arrays.
-
-GL_EXT_clip_volume_hint
-	Allows one to disable clip volume (frustum) testing.
-
-
-
-Extensions removed
-------------------
-
-GL_EXT_multitexture - obsolete in favor of GL_ARB_multitexture
-
-
-
-Config file
------------
-
-By default, /etc/mesa.conf will be read when Mesa starts.  This
-file controls default hints, enable/disable of extensions, and
-more.  See the CONFIG file for documentation.
-
-
-
-Optimizations
--------------
-
-Keith Whitwell has contributed significant optimizations to Mesa's
-vertex transformation code.  Basically, the whole transformation
-stage of Mesa has been rewritten.
-
-It's impossible to give a speedup factor.  You'll just have to
-try your app and see how it performs.
-
-
-
-Device Driver changes
----------------------
-
-A bunch of new device driver functions have been added.  See src/dd.h
-Keith Harrison contributed many of them.  I've been planning on adding
-a bunch of functions like these to make writing hardware drivers easier.
-More such function will probably be added in the near future.
-
-
-
-Miscellaneous
--------------
-
-util/glstate.c has some handy functions for debugging.  Basically, it
-offers a simple function for printing GL state variables.  It's not
-finished yet.  There's a LOT more GLenum records to be added (see the
-code).  Anyone want to help?
-
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.2

@@ -1,11 +0,0 @@
-
-                         Mesa 3.2 release notes
-
-                             PLEASE READ!!!!
-
-
-Mesa 3.2 is a stabilization of the Mesa 3.1 release.  No new features
-have been added.  For a list of bug fixes please read the VERSIONS file.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.2.1

@@ -1,31 +0,0 @@
-
-                         Mesa 3.2.1 release notes
-
-                             PLEASE READ!!!!
-
-
-
-The Mesa 3.2.1 release mainly just fixes bugs since the 3.2 release.
-See the VERSIONS file for the exact list.
-
-
-
-GLU Polygon Tessellator
------------------------
-
-The GLU tessellator has been reverted back to the version included
-with Mesa 3.0 since it's more stable.  The Mesa 3.1/3.2 tessellator
-implemented the GLU 1.3 specification but suffered from a number of
-bugs.
-
-Mesa implements GLU 1.1.
-
-Ideally, people should use the GLU 1.3 library included in SGI's
-OpenGL Sample Implementation (SI) available from 
-http://oss.sgi.com/projects/ogl-sample/
-People are working to make easy-to-install Linux RPMs of the
-GLU library.
-
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.3

@@ -1,270 +0,0 @@
-
-                         Mesa 3.3 release notes
-
-                             July 21, 2000
-
-                             PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.2.1) designate stable releases.
-
-Mesa 3.3 has a undergone many internal changes since version 3.2
-and features a lot of new extensions.  3.3 is expected to be pretty
-stable, but perhaps not as stable as 3.2 which has been used by
-thousands of users over the past months.
-
-Everyone is encouraged to try Mesa 3.3.  Bugs should be reported to
-the Mesa bug database on www.sourceforge.net.
-
-
-
-Header file / GLenum changes
-----------------------------
-
-The gl.h and glu.h headers now use #defines to define all GL_* tokens
-instead of C-language enums.  This change improves Mesa/OpenGL
-interoperability.
-
-
-
-New API dispatch code
----------------------
-
-The core Mesa gl* functions are now implemented with a new dispatch
-(jump table) which will allow simultaneous direct/indirect rendering.
-
-The code is found in the glapi*.[ch] files.
-
-Of interest:  the actual "glFooBar" functions are generated with
-templatized code defined in glapitemp.h and included by glapi.c
-The glapitemp.h template should be reusable for all sorts of OpenGL
-projects.
-
-The new dispatch code has also optimized with x86 assembly code.
-This optimization eliminates copying the function arguments during
-dispatch.
-
-
-
-New thread support
-------------------
-
-Thread support in Mesa has been rewritten.  The glthread.[ch] files
-replace mthreads.[ch].  Thread safety is always enabled (on platforms
-which support threads, that is).  There is virtually no performance
-penalty for typical single-thread applications.  See the glapi.c
-file for details.
-
-The Xlib driver (XMesa) is now thread-safe as well.  Be sure to
-call XInitThreads() in your app first.  See the xdemos/glthreads.c
-demo for an example.
-
-
-
-Make configuration changes
---------------------------
-
-If you use the old-style (non GNU automake) method to build Mesa note
-that several of the configuration names have changed:
-
-   Old name        New name
-   -------------   ----------------
-   linux-elf       linux
-   linux           linux-static
-   linux-386-elf   linux-386
-   linux-386       linux-386-static
-   etc.
-
-
-
-New extensions
---------------
-
-GL_ARB_transpose_matrix
-	Adds glLoadTransposeMatrixARB() and glMultTransposeMatrixARB()
-        functions.
-
-GL_ARB_texture_cube_map
-	For cube-based reflection mapping.
-
-GL_EXT_texture_add_env
-	Adds GL_ADD texture environment mode.
-	See http://www.berkelium.com/OpenGL/EXT/texture_env_add.txt
-
-GL_EXT_texture_lod_bias
-	Allows mipmapped texture blurring and sharpening.
-
-GLX_EXT_visual_rating extension
-	This extension has no effect in stand-alone Mesa (used for DRI).
-
-GL_HP_occlusion_test
-	Used for bounding box occlusion testing (see demos/occlude.c).
-
-GL_SGIX_pixel_texture / GL_SGIS_pixel_texture
-	Lets glDraw/CopyPixels draw a texture coordinate image.
-
-GL_SGI_color_matrix
-	Adds a color matrix and another set of scale and bias parameters
-	to the glDraw/CopyPixels paths.
-
-GL_SGI_color_table
-	Adds additional color tables to the glDraw/Read/CopyPixels paths.
-
-GL_EXT_histogram
-	Compute histograms for glDraw/Read/CopyPixels.
-
-GL_EXT_blend_func_separate
-	This is the same as GL_INGR_blend_func_separate.
-
-GL_ARB_texture_cube_mapping
-	6-face cube mapping, nicer than sphere mapping
-
-GL_EXT_texture_env_combine
-	For advanced texture environment effects.
-
-
-Documentation for all these functions can be found at
-http://oss.sgi.com/projects/ogl-sample/registry/
-
-
-
-GLX_SGI_make_current_read functionality
----------------------------------------
-
-The functionality of this extension is needed for GLX 1.3 (and required
-for the Linux/OpenGL standards base).
-
-Implementing this function required a **DEVICE DRIVER CHANGE**.
-The old SetBuffer() function has been replaced by SetReadBuffer() and
-SetDrawBuffer().  All device drivers will have to be updated because
-of this change.
-
-The new function, glXMakeContextCurrent(), in GLX 1.3 now works in Mesa.
-The xdemos/wincopy.c program demonstrates it.
-
-
-
-Image-related code changes
---------------------------
-
-The imaging path code used by glDrawPixels, glTexImage[123]D,
-glTexSubImage[123], etc has been rewritten.  It's now faster,
-uses less memory and has several bug fixes.  This work was
-actually started in Mesa 3.1 with the glTexImage paths but has now
-been carried over to glDrawPixels as well.
-
-
-
-Device driver interface changes
--------------------------------
-
-Added new functions for hardware stencil buffer support:
-   WriteStencilSpan
-   ReadStencilSpan
-   WriteStencilPixels
-   ReadStencilPixels
-
-
-Removed old depth buffer functions:
-   AllocDepthBuffer
-   DepthTestSpan
-   DepthTestPixels
-   ReadDepthSpanFloat
-   ReadDepthSpanInt
-
-
-Added new depth buffer functions:
-   WriteDepthSpan
-   ReadDepthSpan
-   WriteDepthPixels
-   ReadDepthPixels
-
-   These functions always read/write 32-bit GLuints.  This will allow
-   drivers to have anywhere from 0 to 32-bit Z buffers without
-   recompiling for 16 vs 32 bits as was previously needed.
-
-
-New texture image functions
-   The entire interface for texture image specification has been updated.
-   With the new functions, it's optional for Mesa to keep an internal copy
-   of all textures.  Texture download should be a lot faster when the extra
-   copy isn't made.
-
-Misc changes
-   TexEnv now takes a target argument
-   Removed UseGlobalTexturePalette (use Enable function instead)
-
-
-Also added
-   ReadPixels
-   CopyPixels
-
-
-The SetBufffer function has been replaced by SetDrawBuffer and
-SetReadBuffer functions.  This lets core Mesa independently
-specify which buffer is to be used for reading and which for
-drawing.
-
-The Clear function's mask parameter has changed.  Instead of
-mask being the flags specified by the user to glClear, the
-mask is now a bitmask of the DD_*_BIT flags in dd.h.  Now
-multiple color buffers can be specified for clearing (ala
-glDrawBuffers).  The driver's Clear function must also
-check the glColorMask glIndexMask, and glStencilMask settings
-and do the right thing.  See the X/Mesa, OS/Mesa, or FX/Mesa
-drivers for examples.
-
-
-The depth buffer changes shouldn't be hard to make for existing
-drivers.  In fact, it should simply the code.  Be careful with
-the depthBits value passed to gl_create_context().  1 is a bad
-value!  It should normally be 0, 16, 24, or 32.
-
-
-gl_create_framebuffer() takes new arguments which explicitly tell
-core Mesa which ancillary buffers (depth, stencil, accum, alpha)
-should be implemented in software.  Mesa hardware drivers should
-carefully set these flags depending on which buffers are in the
-graphics card.
-
-
-
-Internal constants
-------------------
-
-Point and line size range and granularity limits are now stored
-in the gl_constants struct, which is the Const member of GLcontext.
-The limits are initialized from values in config.h but may be
-overridden by device drivers to reflect the limits of that driver's
-hardware.
-
-Also added constants for NumAuxBuffers and SubPixelBits.
-
-
-
-OpenGL Conformance
-------------------
-
-Mesa now passes all the OpenGL 1.1 conformance tests, except for
-antialiased lines.  AA lines fail on some, but not all, the tests.
-In order to fix the remaining failures, a new AA line algorithm will
-be needed (which computes coverage values for end-point fragments).
-This will be done for Mesa 3.5/3.6.
-
-
-
-OpenGL 1.2 GL_ARB_imaging subset
---------------------------------
-
-Mesa 3.3 implements all the features of GL_ARB_imaging except for
-image convolution.  This will (hopefully) be done for Mesa 3.5/3.6.
-
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.4

@@ -1,21 +0,0 @@
-
-                         Mesa 3.4 release notes
-
-                             November 3, 2000
-
-                             PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 3.4 simply fixes bugs found in the Mesa 3.3 release.  For details,
-see the VERSIONS file.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.4.1

@@ -1,21 +0,0 @@
-
-                         Mesa 3.4.1 release notes
-
-                             February 9, 2001
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 3.4.1 is a maintenance release that simply fixes bugs found since
-the Mesa 3.4 release.  For details, see the VERSIONS file.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.4.2

@@ -1,21 +0,0 @@
-
-                         Mesa 3.4.2 release notes
-
-                               May 17, 2001
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 3.4.2 is a maintenance release that simply fixes bugs found since
-the Mesa 3.4.1 release.  For details, see the VERSIONS file.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-3.5

@@ -1,227 +0,0 @@
-
-                         Mesa 3.5 release notes
-
-                             June 21, 2001
-
-                             PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.5) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-The biggest change in Mesa 3.5 is a complete overhaul of the source
-code in order to make it more modular.  This was driven by the DRI
-hardware drivers.  It simplifies the DRI drivers and opens the door
-to hardware transform/clip/lighting (TCL).  Keith Whitwell can take
-the credit for that.
-
-
-
-Driver Support
---------------
-
-The device driver interface in Mesa 3.5 has changed a lot since Mesa 3.4
-Not all of the older Mesa drivers have been updated.  Here's the status:
-
-Driver			Status
-----------------------	-----------
-XMesa (Xlib)		updated
-OSMesa (off-screen)	updated
-FX (3dfx Voodoo1/2)	updated
-SVGA			updated
-GGI			not updated
-Windows/Win32		not updated
-DOS/DJGPP		not updated
-BeOS			not updated
-Allegro			not updated
-D3D			not updated
-DOS			not updated
-
-We're looking for volunteers to update the remaining drivers.  Please
-post to the Mesa3d-dev mailing list if you can help.
-
-
-
-GLU 1.3
--------
-
-Mesa 3.5 includes the SGI Sample Implementation (SI) GLU library.
-This version of GLU supports the GLU 1.3 specification.  The old
-Mesa GLU library implemented the 1.1 specification.  The SI GLU
-library should work much better.
-
-You'll need a C++ compiler to compile the SI GLU library.  This may
-be a problem on some systems.
-
-
-
-New Extensions
---------------
-
-GL_EXT_convolution
-	Adds image convolution to glRead/Copy/DrawPixels/TexImage.
-
-GL_ARB_imaging
-	This is the optional imaging subset of OpenGL 1.2.
-	It's the GL_EXT_convolution, GL_HP_convolution_border_modes,
-	GL_EXT_histogram, GL_EXT_color_table, GL_EXT_color_subtable
-	GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract
-	and GL_SGI_color_matrix extensions all rolled together.
-	This is supported in all software renderers but not in all
-	hardware drivers (3dfx for example).
-
-GL_ARB_texture_compression
-	This is supported in Mesa but only used by the 3dfx DRI drivers
-	for Voodoo4 and later.
-
-GL_ARB_texture_env_add
-	This is identical to GL_EXT_texture_env_add.
-
-GL_NV_blend_square
-	Adds extra blend source and dest factors which allow squaring
-	of color values.
-
-GL_EXT_fog_coord
-	Allows specification of a per-vertex fog coordinate instead of
-	having fog always computed from the eye distance.
-
-GL_EXT_secondary_color
-	Allows specifying the secondary (specular) color for each vertex
-	instead of getting it only from lighting in GL_SEPARATE_SPECULAR_COLOR
-	mode.
-
-GL_ARB_texture_env_combine
-	Basically the same as GL_EXT_texture_env_combine
-
-GL_ARB_texture_env_add extension
-	Texture addition mode.
-
-GL_ARB_texture_env_dot3 extension
-	Dot product texture environment.
-
-GL_ARB_texture_border_clamp
-	Adds GL_CLAMP_TO_BORDER_ARB texture wrap mode
-
-GL_SGIX_depth_texture, GL_SGIX_shadow and GL_SGIX_shadow_ambient
-	Implements a shadow casting algorithm based on depth map textures
-
-GL_SGIS_generate_mipmap
-	Automatically generate lower mipmap images whenever the base mipmap
-	image is changed with glTexImage, glCopyTexImage, etc.
-
-
-
-libOSMesa.so
-------------
-
-libOSMesa.so is a new library which contains the OSMesa interface for
-off-screen rendering.  Apps which need the OSMesa interface should link
-with both -lOSMesa and -lGL.  This change was made so that stand-alone
-Mesa works the same way as XFree86/DRI's libGL.
-
-
-
-Device Driver Changes / Core Mesa Changes
------------------------------------------
-
-The ctx->Driver.LogicOp() function has been removed.  It used to
-be called during state update in order to determine if the driver
-could do glLogicOp() operations, and if not, set the SWLogicOpEnabled
-flag.  Drivers should instead examine the LogicOp state themselves
-and choose specialized point, line, and triangle functions appropriately,
-or fall back to software rendering.  The Xlib driver was the only driver
-to use this function.  And since the Xlib driver no longer draws
-points, lines or triangles using Xlib, the LogicOp function isn't needed.
-
-The ctx->Driver.Dither() function has been removed.  Drivers should
-detect dither enable/disable via ctx->Driver.Enable() instead.
-
-The ctx->Driver.IndexMask() and ctx->Driver.ColorMask() functions
-are now just called from glIndexMask and glColorMask like the other
-GL state-changing functions.  They are no longer called from inside
-gl_update_state().  Also, they now return void.  The change was made
-mostly for sake of uniformity.
-
-The NEW_DRVSTATE[0123] flags have been removed.  They weren't being used
-and are obsolete w.r.t. the way state updates are done in DRI drivers.
-
-
-Removed obsolete gl_create_visual() and gl_destroy_visual().
-
-Renamed functions (new namespace):
-
-old				new
-gl_create_framebuffer		_mesa_create_framebuffer
-gl_destroy_framebuffer		_mesa_destroy_framebuffer
-gl_create_context		_mesa_create_context
-gl_destroy_context		_mesa_destroy_context
-gl_context_initialize		_mesa_context_initialize
-gl_copy_context			_mesa_copy_context
-gl_make_current			_mesa_make_current
-gl_make_current2		_mesa_make_current2
-gl_get_current_context		_mesa_get_current_context
-gl_flush_vb			_mesa_flush_vb
-gl_warning			_mesa_warning
-gl_compile_error		_mesa_compile_error
-
-
-All the drivers have been updated, but not all of them have been
-tested since I can't test some platforms (DOS, Windows, Allegro, etc).
-
-
-X/Mesa Driver
--------------
-
-The source files for the X/Mesa driver in src/X have been renamed.
-The xmesa[1234].c files are gone.  The new files are xm_api.c,
-xm_dd.c, xm_line.c, xm_span.c and xm_tri.c.
-
-
-
-Multitexture
-------------
-
-Eight texture units are now supported by default.
-
-
-
-OpenGL SI related changes
--------------------------
-
-In an effort to make Mesa's internal interfaces more like the OpenGL
-SI interfaces, a number of changes have been made:
-
-1. Importing the SI's glcore.h file which defines a number of
-interface structures like __GLimports and __GLexports.
-
-2. Renamed "struct gl_context" to "struct __GLcontextRec".
-
-3. Added __glCoreCreateContext() and __glCoreNopDispatch() functions.
-
-4. The GLcontext member Visual is no longer a pointer.
-
-5. New file: imports.c to setup default import functions for Mesa.
-
-
-
-
-16-bit color channels
----------------------
-
-There's experimental support for 16-bit color channels (64-bit pixels)
-in Mesa 3.5.  Only the OSMesa interface can be used for 16-bit rendering.
-Type "make linux-osmesa16" in the top-level directory to build the
-special libOSMesa16.so library.
-
-This hasn't been tested very thoroughly yet so please file bug reports
-if you have trouble.
-
-In the future I hope to implement support for 32-bit, floating point
-color channels.
-
-----------------------------------------------------------------------

docs/RELNOTES-4.0

@@ -1,162 +0,0 @@
-
-                           Mesa 4.0 release notes
-
-                             October 18, 2001
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa version 4.0 signifies two things:
-
-  1. A stabilization of the 3.5 development release
-  2. Implementation of the OpenGL 1.3 specification
-
-
-Note that the Mesa major version number is incremented with the OpenGL
-minor version number:
-
-   Mesa 1.x  ==  OpenGL 1.0
-   Mesa 2.x  ==  OpenGL 1.1
-   Mesa 3.x  ==  OpenGL 1.2
-   Mesa 4.x  ==  OpenGL 1.3
-
-
-
-New Features
-------------
-
-Mesa 3.5 already had all the new features of OpenGL 1.3, implemented as
-extensions.  These extensions were simply promoted to standard features:
-
-   GL_ARB_multisample
-   GL_ARB_multitexture
-   GL_ARB_texture_border_clamp
-   GL_ARB_texture_compression
-   GL_ARB_texture_cube_map
-   GL_ARB_texture_env_add
-   GL_ARB_texture_env_combine
-   GL_ARB_texture_env_dot3
-   GL_ARB_transpose_matrix
-
-In Mesa 4.0 the functions defined by these extensions are now available
-without the "ARB" suffix.  For example, glLoadTransposeMatrixf() is now
-a standard API function.  The new functions in OpenGL 1.3 and Mesa 4.0 are:
-
-   glActiveTexture
-   glClientActiveTexture
-   glCompressedTexImage1D
-   glCompressedTexImage2D
-   glCompressedTexImage3D
-   glCompressedTexSubImage1D
-   glCompressedTexSubImage2D
-   glCompressedTexSubImage3D
-   glGetCompressedTexImage
-   glLoadTransposeMatrixd
-   glLoadTransposeMatrixf
-   glMultiTexCoord1d
-   glMultiTexCoord1dv
-   glMultiTexCoord1f
-   glMultiTexCoord1fv
-   glMultiTexCoord1i
-   glMultiTexCoord1iv
-   glMultiTexCoord1s
-   glMultiTexCoord1sv
-   glMultiTexCoord2d
-   glMultiTexCoord2dv
-   glMultiTexCoord2f
-   glMultiTexCoord2fv
-   glMultiTexCoord2i
-   glMultiTexCoord2iv
-   glMultiTexCoord2s
-   glMultiTexCoord2sv
-   glMultiTexCoord3d
-   glMultiTexCoord3dv
-   glMultiTexCoord3f
-   glMultiTexCoord3fv
-   glMultiTexCoord3i
-   glMultiTexCoord3iv
-   glMultiTexCoord3s
-   glMultiTexCoord3sv
-   glMultiTexCoord4d
-   glMultiTexCoord4dv
-   glMultiTexCoord4f
-   glMultiTexCoord4fv
-   glMultiTexCoord4i
-   glMultiTexCoord4iv
-   glMultiTexCoord4s
-   glMultiTexCoord4sv
-   glMultTransposeMatrixd
-   glMultTransposeMatrixf
-   glSampleCoverage
-   glSamplePass
-
-
-GLX 1.4 is the companion to OpenGL 1.3.  The only new features in GLX 1.4
-are support for multisampling and the GLX_ARB_get_proc_address extension.
-glXGetProcAddress() is the only new function in GLX 1.4.
-
-
-
-Multisample and Texture Compression
------------------------------------
-
-The OpenGL 1.3 specification allows the multisample and texture compression
-features to essentially be no-ops.  For example, if you query for multisample
-support you'll find none, but the API functions work.
-
-Similarly, texture compression is not implemented by any of the software
-drivers but you can specify a generic compressed texture format (like
-GL_COMPRESSED_RGBA) to glTexImage2D and it'll be accepted.
-
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the
-device driver.  If the driver enables all the ARB extensions which are part
-of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3".  Otherwise,
-it'll return "1.2".
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.3
-OSMesa (off-screen)	implements OpenGL 1.3
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.3
-GGI			needs updating
-DOS/DJGPP		needs updating
-BeOS			needs updating
-Allegro			needs updating
-D3D			needs updating
-DOS			needs updating
-
-Special thanks go to Karl Schultz for updating the Windows driver.
-
-The XFree86/DRI drivers	have not yet been updated to use Mesa 4.0 as of
-September 2001, but that should happen eventually.
-
-
-
-Other Changes
--------------
-
-See the VERSIONS file for more details about bug fixes, etc. in Mesa 4.0.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-4.0.1

@@ -1,21 +0,0 @@
-
-                          Mesa 4.0.1 release notes
-
-                             December 17, 2001
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 4.0.1 only contains bug fixes since version 4.0.
-
-See the docs/VERSIONS file for the list of bug fixes.
-
-----------------------------------------------------------------------

docs/RELNOTES-4.0.2

@@ -1,49 +0,0 @@
-
-                          Mesa 4.0.2 release notes
-
-                             March 25, 2002
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 4.0.2 only contains bug fixes and a new DOS driver since version 4.0.1.
-
-See the docs/VERSIONS file for the list of bug fixes.
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the
-device driver.  If the driver enables all the ARB extensions which are part
-of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3".  Otherwise,
-it'll return "1.2".
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.3
-OSMesa (off-screen)	implements OpenGL 1.3
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.3
-DOS/DJGPP		implements OpenGL 1.3 (new in Mesa 4.0.2)
-GGI			needs updating
-BeOS			needs updating
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-4.0.3

@@ -1,51 +0,0 @@
-
-                          Mesa 4.0.3 release notes
-
-                               June 25, 2002
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 3.3) designate new developmental releases.
-Even numbered versions (such as 3.4) designate stable releases.
-
-Mesa 4.0.3 basically just contains bug fixes version 4.0.2.
-
-See the docs/VERSIONS file for the list of bug fixes.
-
-The GGI driver has been updated, thanks to Filip Spacek.
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the
-device driver.  If the driver enables all the ARB extensions which are part
-of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3".  Otherwise,
-it'll return "1.2".
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.3
-OSMesa (off-screen)	implements OpenGL 1.3
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.3
-DOS/DJGPP		implements OpenGL 1.3 (new in Mesa 4.0.2)
-GGI			implements OpenGL 1.3
-BeOS			needs updating
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-4.1

@@ -1,307 +0,0 @@
-
-                            Mesa 4.1 release notes
-
-                               October 29, 2002
-
-                                PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even numbered versions (such as 4.0) designate stable releases.
-Odd numbered versions (such as 4.1) designate new developmental releases.
-
-
-New Features in Mesa 4.1
-------------------------
-
-New extensions.  Docs at http://oss.sgi.com/projects/ogl-sample/registry/
-
-GL_NV_vertex_program
-
-    NVIDIA's vertex programming extension
-
-GL_NV_vertex_program1_1
-
-    A few features built on top of GL_NV_vertex_program
-
-GL_ARB_window_pos
-
-    This is the ARB-approved version of GL_MESA_window_pos
-
-GL_ARB_depth_texture
-
-    This is the ARB-approved version of GL_SGIX_depth_texture.
-    It allows depth (Z buffer) data to be stored in textures.
-    This is used by GL_ARB_shadow
-
-GL_ARB_shadow
-
-    Shadow mapping with depth textures.
-    This is the ARB-approved version of GL_SGIX_shadow.
-
-GL_ARB_shadow_ambient
-
-    Allows one to specify the luminance of shadowed pixels.
-    This is the ARB-approved version of GL_SGIX_shadow_ambient.
-
-GL_EXT_shadow_funcs
-
-    Extends the set of GL_ARB_shadow texture comparision functions to
-    include all eight of standard OpenGL dept-test functions.
-
-GL_ARB_point_parameters
-
-    This is basically the same as GL_EXT_point_parameters.
-
-GL_ARB_texture_env_crossbar
-
-    Allows any texture combine stage to reference any texture source unit.
-
-GL_NV_point_sprite
-
-    For rendering points as textured quads.  Useful for particle effects.
-
-GL_NV_texture_rectangle  (new in 4.0.4 actually)
-
-    Allows one to use textures with sizes that are not powers of two.
-    Note that mipmapping and several texture wrap modes are not allowed.
-
-GL_EXT_multi_draw_arrays
-
-    Allows arrays of vertex arrays to be rendered with one call.
-
-GL_EXT_stencil_two_side
-
-   Separate stencil modes for front and back-facing polygons.
-
-GLX_SGIX_fbconfig & GLX_SGIX_pbuffer
-
-   Off-screen rendering support.
-
-GL_ATI_texture_mirror_once
-
-   Adds two new texture wrap modes: GL_MIRROR_CLAMP_ATI and
-   GL_MIRROR_CLAMP_TO_EDGE_ATI.
-
-
-
-Device Driver Status
---------------------
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of these drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.3
-OSMesa (off-screen)	implements OpenGL 1.3
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.3
-DOS/DJGPP		implements OpenGL 1.3
-GGI			implements OpenGL 1.3
-BeOS			needs updating (underway)
-Allegro			needs updating
-D3D			needs updating
-DOS			needs updating
-
-
-
-New features in GLUT
---------------------
-
-1. Frames per second printing
-
-   GLUT now looks for an environment variable called "GLUT_FPS".  If it's
-   set, GLUT will print out a frames/second statistic to stderr when
-   glutSwapBuffers() is called.  By default, frames/second is computed
-   and displayed once every 5 seconds.  You can specify a different
-   interval (in milliseconds) when you set the env var.  For example
-   'export GLUT_FPS=1000' or 'setenv GLUT_FPS 1000' will set the interval
-   to one second.
-
-   NOTE: the demo or application must call the glutInit() function for
-   this to work.  Otherwise, the env var will be ignored.
-
-   Finally, this feature may not be reliable in multi-window programs.
-
-
-2. glutGetProcAddress() function
-
-   The new function:
-
-        void *glutGetProcAddress(const char *procName)
-
-   is a wrapper for glXGetProcAddressARB() and wglGetProcAddress().  It
-   lets you dynamically get the address of an OpenGL function at runtime.
-   The GLUT_API_VERSION has been bumped to 5, but I haven't bumped the
-   GLUT version number from 3.7 since that's probably Mark Kilgard's role.
-
-   This function should probably also be able to return the address of
-   GLUT functions themselves, but it doesn't do that yet.
-
-
-
-XXX Things To Do Yet XXXX
--------------------------
-
-isosurf with vertex program exhibits some missing triangles (probably
-when recycling the vertex buffer for long prims).
-
-
-
-Porting Info
-------------
-
-If you're porting a DRI or other driver from Mesa 4.0.x to Mesa 4.1 here
-are some things to change:
-
-1. ctx->Texture._ReallyEnabled is obsolete.
-
-   Since there are now 5 texture targets (1D, 2D, 3D, cube and rect) that
-   left room for only 6 units (6*5 < 32) in this field.
-   This field is being replaced by ctx->Texture._EnabledUnits which has one
-   bit per texture unit.  If the bit k of _EnabledUnits is set, that means
-   ctx->Texture.Unit[k]._ReallyEnabled is non-zero.  You'll have to look at
-   ctx->Texture.Unit[k]._ReallyEnabled to learn if the 1D, 2D, 3D, cube or
-   rect texture is enabled for unit k.
-
-   This also means that the constants TEXTURE1_*, TEXTURE2_*, etc are
-   obsolete.
-
-   The tokens TEXTURE0_* have been replaced as well (since there's no
-   significance to the "0" part:
-
-   old token           new token
-   TEXTURE0_1D         TEXTURE_1D_BIT
-   TEXTURE0_2D         TEXTURE_2D_BIT
-   TEXTURE0_3D         TEXTURE_3D_BIT
-   TEXTURE0_CUBE       TEXTURE_CUBE_BIT
-   <none>              TEXTURE_RECT_BIT
-
-   These tokens are only used for the ctx->Texture.Unit[i].Enabled and
-   ctx->Texture.Unit[i]._ReallyEnabled fields.  Exactly 0 or 1 bits will
-   be set in _ReallyEnabled at any time!
-
-   Q: "What's the purpose of Unit[i].Enabled vs Unit[i]._ReallyEnabled?"
-   A: The user can enable GL_TEXTURE_1D, GL_TEXTURE_2D, etc for any
-      texure unit all at once (an unusual thing to do).
-      OpenGL defines priorities that basically say GL_TEXTURE_2D has
-      higher priority than GL_TEXTURE_1D, etc.  Also, just because a
-      texture target is enabled by the user doesn't mean we'll actually
-      use that texture!  If a texture object is incomplete (missing mip-
-      map levels, etc) it's as if texturing is disabled for that target.
-      The _ReallyEnabled field will have a bit set ONLY if the texture
-      target is enabled and complete.  This spares the driver writer from
-      examining a _lot_ of GL state to determine which texture target is
-      to be used.
-
-
-2. Tnl tokens changes
-
-   During the implementation of GL_NV_vertex_program some of the vertex
-   buffer code was changed.  Specifically, the VERT_* bits defined in
-   tnl/t_context.h have been renamed to better match the conventions of
-   GL_NV_vertex_program.  The old names are still present but obsolete.
-   Drivers should use the newer names.
-
-   For example:  VERT_RGBA is now VERT_BIT_COLOR0 and
-   VERT_SPEC_RGB is now VERT_BIT_COLOR1.
-
-
-
-3. Read/Draw Buffer changes
-
-   The business of setting the current read/draw buffers in Mesa 4.0.x
-   was complicated.  It's much simpler now in Mesa 4.1.
-
-   Here are the changes:
-
-   - Renamed ctx->Color.DrawDestMask to ctx->Color._DrawDestMask
-   - Removed ctx->Color.DriverDrawBuffer
-   - Removed ctx->Pixel.DriverReadBuffer
-   - Removed ctx->Color.MultiDrawBuffer
-   - Removed ctx->Driver.SetDrawBuffer()
-   - Removed swrast->Driver.SetReadBuffer().
-   - Added ctx->Color._DrawDestMask - a bitmask of FRONT/BACK_LEFT/RIGHT_BIT
-     values to indicate the current draw buffers.
-   - Added ctx->Pixel._ReadSrcMask to indicate the source for pixel reading.
-     The value is _one_ of the FRONT/BACK_LEFT/RIGHT_BIT values.
-   - Added ctx->Driver.DrawBuffer() and ctx->Driver.ReadBuffer().
-     These functions exactly correspond to glDrawBuffer and glReadBuffer calls.
-     Many drivers will set ctx->Driver.DrawBuffer = _swrast_DrawBuffer and
-     leave ctx->Draw.ReadBuffer NULL.
-     DRI drivers should implement their own function for ctx->Driver.DrawBuffer
-     and use it to set the current hardware drawing buffer.  You'll probably
-     also want to check for GL_FRONT_AND_BACK mode and fall back to software.
-     Call _swrast_DrawBuffer() too, to update the swrast state.
-   - Added swrast->Driver.SetBuffer().
-     This function should be implemented by all device drivers that use swrast.
-     Mesa will call it to specify the buffer to use for span reading AND
-     writing and point/line/triangle rendering.
-     There should be no confusion between current read or draw buffer anymore.
-   - Added swrast->CurrentBuffer to indicate which color buffer to read/draw.
-     Will be FRONT_LEFT_BIT, BACK_LEFT_BIT, FRONT_RIGHT_BIT or BACK_RIGHT_BIT.
-     This value is usually passed to swrast->Driver.SetBuffer().
-
-
-4. _mesa_create_context() changes.  This function now takes a pointer to
-   a __GLimports object.  The __GLimports structure contains function
-   pointers to system functions like fprintf(), malloc(), etc.
-   The _mesa_init_default_imports() function can be used to initialize
-   a __GLimports object.  Most device drivers (like the DRI drivers)
-   should use this.
-
-
-5. In tnl's struct vertex_buffer, the field "ProjectedClipCoords"
-   has been replaced by "NdcPtr" to better match the OpenGL spec's
-   terminology.
-
-
-6. Since GL_EXT_stencil_two_side has been implemented, many of the
-   ctx->Stencil fields are now 2-element arrays.  For example,
-   "GLenum Ref" is now "GLenum Ref[2]"  The [0] elements are the front-face
-   values and the [1] elements are the back-face values.
-   ctx->Stencil.ActiveFace is 0 or 1 to indicate the current face for
-   the glStencilOp/Func/Mask() functions.
-   ctx->Stencil.TestTwoSide controls whether or not 1 or 2-sided stenciling
-   is enabled.
-
-
-7. Removed ctx->Polygon._OffsetAny.  Removed ctx->Polygon.OffsetMRD.
-
-
-8. GLfloat / GLchan changes:
-
-   - Changed ctx->Driver.ClearColor() to take GLfloat[4] instead of GLchan[4].
-     ctx->Color.ClearColor is now GLfloat[4] too.
-   - Changed ctx->Driver.AlphaRef() to take GLfloat instead of GLchan.
-   - ctx->Color.AlphaRef is now GLfloat.
-   - texObj->BorderColor is now GLfloat[4].  texObj->_BorderChan is GLchan[4].
-
-   This is part of an effort to remove all GLchan types from core Mesa so
-   that someday we can support 8, 16 and 32-bit color channels dynamically
-   at runtime, instead of at compile-time.
-
-
-9. GLboolean ctx->Tranform.ClipEnabled[MAX_CLIP_PLANES] has been replaced
-   by GLuint ctx->Transform.ClipPlanesEnabled.  The later is a bitfield.
-
-
-10. There's a new matrix_stack type in mtypes.h used for the Modelview,
-   Projection, Color and Texcoord matrix stacks.
-
-
-11. The ctx->Current.* fields have changed a lot.  Now, there's a
-   ctx->Current.Attrib[] array for all vertex attributes which matches
-   the NV vertex program conventions.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-5.0

@@ -1,84 +0,0 @@
-
-                            Mesa 5.0 release notes
-
-                              November 13, 2002
-
-                                PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 5.0) designate stable releases.
-Odd-numbered versions (such as 4.1) designate new developmental releases.
-
-Mesa 5.0 is basically just a stabilization of Mesa 4.1.  To see a list of
-bug fixes, etc. see the VERSIONS file.
-
-
-
-New Features in Mesa 5.0
-------------------------
-
-Mesa 5.0 supports OpenGL 1.4.  Note Mesa's versioning convention:
-
-   OpenGL Version    Mesa Version
-   ------------------------------
-        1.0             1.x
-        1.1             2.x
-        1.2             3.x
-        1.3             4.x
-        1.4             5.x
-
-OpenGL 1.4 (and Mesa 5.0) incorporates the following OpenGL extensions as
-standard features:
-
-	GL_ARB_depth_texture
-	GL_ARB_shadow
-	GL_ARB_texture_env_crossbar
-	GL_ARB_texture_mirror_repeat
-	GL_ARB_window_pos
-	GL_EXT_blend_color
-	GL_EXT_blend_func_separate
-	GL_EXT_blend_logic_op
-	GL_EXT_blend_minmax
-	GL_EXT_blend_subtract
-	GL_EXT_fog_coord
-	GL_EXT_multi_draw_arrays
-	GL_EXT_point_parameters
-	GL_EXT_secondary_color
-	GL_EXT_stencil_wrap
-	GL_SGIS_generate_mipmap
-
-
-
-Device Driver Status
---------------------
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of these drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.4
-OSMesa (off-screen)	implements OpenGL 1.4
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.4
-DOS/DJGPP		implements OpenGL 1.3
-GGI			implements OpenGL 1.3
-DOS			implements OpenGL 1.4
-BeOS			needs updating (underway)
-Allegro			needs updating
-D3D			needs updating
-
-Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the
-driver call the _mesa_enable_1_4_extensions() function.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-5.0.1

@@ -1,45 +0,0 @@
-
-                           Mesa 5.0.1 release notes
-
-                               March 30, 2003
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 5.0.x) designate stable releases.
-Odd-numbered versions (such as 4.1.x) designate new developmental releases.
-
-Mesa 5.0.1 just fixes bugs found since the 5.0 release.  See the VERSIONS
-file for details.
-
-
-Device Driver Status
---------------------
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of these drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.4
-OSMesa (off-screen)	implements OpenGL 1.4
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.4
-DJGPP			implements OpenGL 1.4
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.4
-Allegro			needs updating
-D3D			needs updating
-
-Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the
-driver call the _mesa_enable_1_4_extensions() function.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-5.0.2

@@ -1,45 +0,0 @@
-
-                           Mesa 5.0.2 release notes
-
-                               September 5, 2003
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 5.0.x) designate stable releases.
-Odd-numbered versions (such as 4.1.x) designate new developmental releases.
-
-Mesa 5.0.2 just fixes bugs found since the 5.0.1 release.  See the VERSIONS
-file for details.
-
-
-Device Driver Status
---------------------
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of these drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.4
-OSMesa (off-screen)	implements OpenGL 1.4
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.4
-DJGPP			implements OpenGL 1.4
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.4
-Allegro			needs updating
-D3D			needs updating
-
-Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the
-driver call the _mesa_enable_1_4_extensions() function.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-5.1

@@ -1,279 +0,0 @@
-
-                            Mesa 5.1 release notes
-
-                              December 17, 2003
-
-                                PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 5.0) designate stable releases.
-Odd-numbered versions (such as 5.1) designate new developmental releases.
-
-
-Bug fixes
----------
-See the VERSIONS file for a list of bugs fixed in this release.
-
-
-
-New Features in Mesa 5.1
-------------------------
-
-GL_ARB_vertex_program / GL_ARB_fragment_program
-   Michal Krol and Karl Rasche implemented these extensions.  Thanks!
-   Be aware that there may be some rough edges and lurking bugs.
-
-GL_ATI_texture_env_combine3 extension
-   This adds a few new texture combine modes.
-   Contributed by Ian Romanick.
-
-GL_SGI_texture_color_table
-   Adds a color table lookup to the RGBA texture path.  There's a separate
-   color table for each texture unit.
-   Contributed by Eric Plante.
-
-GL_NV_fragment_program
-   NVIDIA's fragment-level programming feature.
-   Possible lurking bugs:
-     - the DDX and DDY commands aren't fully tested
-     - there may be bugs in the parser
-     - the TEX and TXP instructions both do perspective correction
-     - the pack/unpack instructions may not be correct
-
-GL_EXT_depth_bounds_test
-   This extension adds a scissor-like test for the Z axis.  It's used to
-   optimize stencil-volume shadow algorithms.
-
-GL_NV_light_max_exponent
-   Lifts the 128 limit for max light exponent.
-
-GL_EXT_texture_rectangle
-   Identical to GL_NV_texture_rectangle
-
-GL_ARB_occlusion_query
-   Useful for visibility-based culling.
-
-GL_ARB_texture_non_power_of_two
-   Removes the restriction that texture dimensions must be powers of two.
-
-GL_ARB_vertex_buffer_object
-   Allows server-side vertex arrays, optimized host/card data transfers, etc.
-
-GL_ARB_point_sprite
-   ARB-approved version of GL_NV_point_sprite.  Basically allows textures
-   to be applied to points.
-
-GL_IBM_multimode_draw_arrays
-   Allows multiple vertex arrays to be drawn with one call, including arrays
-   of different types of primitives.
-
-GL_SUN_multi_draw_arrays
-   An alias for GL_EXT_multi_draw_arrays, standard in OpenGL 1.4.
-
-Faster glDrawPixels / glCopyPixels in X11 driver
-   If your X screen is 32bpp, glDrawPixels to the front color buffer will
-   be accelerated (via XPutImage()) if the image format is GL_BGRA and the
-   type is GL_UNSIGNED_BYTE.  No raster operations, such as depth test,
-   blend, fog, etc. can be enabled.
-
-   If your X screen is 16bpp, glDrawPixels to the front color buffer will
-   be accelerated (via XPutImage()) if the image format is GL_RGB and the
-   type is GL_UNSIGNED_SHORT_5_6_5.  No raster operations, such as depth
-   test, blend, fog, etc. can be enabled.
-
-   glCopyPixels() calls for the front color buffer will be accelerated
-   (via XCopyArea()) if no raster operations, such as depth test, blend,
-   fog, pixel zoom, etc. are enabled.
-
-   The speed-up over typical software rendering is a factor of 10 for
-   glDrawPixels and 100 for glCopyPixels.
-
-
-With the addition of GL_ARB_occlusion_query, GL_ARB_vertex_buffer_object,
-GL_ARB_texture_non_power_of_two and GL_EXT_shadow_funcs, Mesa 5.1 supports
-all the new features of OpenGL 1.5.  Mesa 6.0 (the next stable release)
-will advertise GL_VERSION = "1.5".
- 
-
-
-Vertex/Fragment program debugger
---------------------------------
-
-GL_MESA_program_debug is an experimental extension to support
-interactive debugging of vertex and fragment programs.  See the
-docs/MESA_program_debug.spec file for details.
-
-The bulk of the vertex/fragment program debugger is implemented
-outside of Mesa.  The GL_MESA_program_debug extension just has minimal
-hooks for stopping running programs and inspecting programs.
-
-The progs/tests/debugger.c (only in CVS) program is an example of how
-the extension can be used.  Presently, the debugger code and demo code
-is in the same file.  Eventually the debugger code should be moved
-into a reusable module.
-
-As it is now, the demo lets you set breakpoings in vertex/fragment
-programs, single step, and print intermediate register values.  It's
-basically just a proof of concept.
-
-
-
-Directory tree reorganization
------------------------------
-
-The directory structure for Mesa has been overhauled to improve its layout.
-All source code for Mesa, GLU, GLUT, etc is now under the src/ directory
-in appropriate subdirectories.
-
-The Mesa source code and drivers has been reorganized under src/mesa/.
-
-All demonstration programs and tests are now in subdirectories under progs/.
-
-
-
-Build System Changes
---------------------
-
-The GNU automake/autoconf support has been removed.  As it was, it seldom
-worked on anything but Linux.  The Mesa developers aren't big fans of
-automake/autoconf/libtool and didn't have the time to maintain it.
-If someone wants to contribute new automake/autoconf support (and is
-willing to maintain it), it may be re-incorporated into Mesa, subject
-to some requirements.
-
-The "old style" makefile system has been updated:
-   1. Make-config has been trimmed down to fewer, modern configurations.
-   2. Most of the bin/mklib.* scripts have been rolled into a new "mklib"
-      script that works on all sorts of systems.  There are probably some
-      bugs in it, but it's been tested on Linux, SunOS 5.8 and IRIX 6.5.
-      Improvements/contributes are greatly appreciated.
-   3. The Makefile.X11 files have been cleaned up in various ways
-
-
-
-Source File Changes
--------------------
-
-The mmath.[ch] files are obsolete.  Their contents have been moved
-into the imports.[ch] and macros.[ch] files.
-
-The files related to vertex and fragment programming have changed.
-Old files:
-	vpexec.[ch]
-	vpparse.[ch]
-	vpstate.[ch]
-New files:
-	program.[ch]              - generic ARB/NV program code
-	arbprogram.[ch]           - ARB program API functions
-	arbfragparse.[ch]         - ARB fragment program parsing
-	arbvertparse.[ch]         - ARB vertex program parsing
-	arbparse.[ch]             - ARB vertex/fragment parsing
-	arbparse_syn.h            - vertex/fragment program syntax
-	nvprogram.[ch]            - NV program API functions
-	nvvertprog.h              - NV vertex program definitions
-	nvfragprog.h              - NV fragment program definitions
-	nvvertparse.[ch]          - NV vertex program parser
-	nvfragparse.[ch]          - NV fragment program parser
-	nvvertexec.[ch]           - NV vertex program execution
-	swrast/s_nvfragprog.[ch]  - NV fragment program execution
-
-The files related to per-vertex handling have changed.
-Old files:
-	tnl/t_eval_api.c          - old per-vertex code
-	tnl/t_imm_alloc.c         - old per-vertex code
-	tnl/t_imm_api.c           - old per-vertex code
-	tnl/t_imm_debug.c         - old per-vertex code
-	tnl/t_imm_dlist.c         - old per-vertex code
-	tnl/t_imm_elt.c           - old per-vertex code
-	tnl/t_imm_eval.c          - old per-vertex code
-	tnl/t_imm_exec.c          - old per-vertex code
-	tnl/t_imm_fixup.c         - old per-vertex code
-	tnl/t_vtx_sse.c           - old per-vertex code
-	tnl/t_vtx_x86.c           - old per-vertex code
-New files:
-	tnl/t_save_api.c          - new per-vertex code
-	tnl/t_save_loopback.c     - new per-vertex code
-	tnl/t_save_playback.c     - new per-vertex code
-	tnl/t_vtx_eval.c          - old per-vertex code
-
-Other new files:
-	bufferobj.[ch]		- GL_ARB_vertex_buffer_object functions
-	version.h		- defines the Mesa version info
-
-Other removed files:
-	swrast/s_histogram.[ch]   - moved into src/histogram.c
-
-
-
-Other Changes
--------------
-
-The ctx->Driver.CreateTexture function has been removed - it wasn't used.
-
-New device driver hook functions:
-   NewTextureObject   - used to allocate struct gl_texture_objects
-   NewTextureImage    - used to allocate struct gl_texture_images
-
-New ctx->Texture._EnabledCoordUnits field:
-   With the addition of GL_NV_fragment_program we may need to interpolate
-   various sets of texture coordinates even when the corresponding texture
-   unit is not enabled.  That is, glEnable(GL_TEXTURE_xD) may never get
-   called but we still may have to interpolate texture coordinates across
-   triangles so that the fragment program will get them.
-   This new field indicates which sets of texture coordinates are needed.
-   If a bit is set in the ctx->Texture._EnabledUnits bitmask is set, the
-   same bit MUST be set in ctx->Texture._EnabledCoordUnits.
-
-The ctx->_TriangleCaps field is deprecated.
-   Instead of testing the DD_* bits in _TriangleCaps, you should instead
-   directly test the relevant state variables, or use one of the helper
-   functions like NEED_SECONDARY_COLOR() at the bottom of context.h
-   While testing _TriangleCaps bits was fast, it was kludgey, and setting
-   the bits in the first place could be error prone.
-
-New vertex processing code.
-   The code behind glBegin, glEnd, glVertex, glNormal, etc. has been
-   totally rewritten.  It's a cleaner implementation now and should use
-   less memory. (Keith)
-
-
-
-To Do
------
-Add screen-awareness to fakeglx.c
-
-
-
-
-Device Driver Status
---------------------
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of these drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.4
-OSMesa (off-screen)	implements OpenGL 1.4
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.4
-DJGPP			implements OpenGL 1.4
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.4
-Allegro			needs updating
-D3D			needs updating
-
-Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the
-driver call the _mesa_enable_1_4_extensions() function.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.0

@@ -1,86 +0,0 @@
-
-                           Mesa 6.0 release notes
-
-                             January 16, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 5.1) designate new developmental releases.
-Even numbered versions (such as 6.0) designate stable releases.
-
-Mesa version 6.0 signifies two things:
-
-  1. A stabilization of the 5.1 development release
-  2. Implementation of the OpenGL 1.5 specification.  When you query
-     glGetString(GL_VERSION) "1.5" will be returned (as long as the
-     driver supports all the required features).
-
-
-Note that the Mesa major version number is incremented with the OpenGL
-minor version number:
-
-   Mesa 1.x  ==  OpenGL 1.0
-   Mesa 2.x  ==  OpenGL 1.1
-   Mesa 3.x  ==  OpenGL 1.2
-   Mesa 4.x  ==  OpenGL 1.3
-   Mesa 5.x  ==  OpenGL 1.4
-   Mesa 6.x  ==  OpenGL 1.5
-
-
-
-New Features
-------------
-
-Mesa 5.1 already had all the new features of OpenGL 1.5, implemented as
-extensions.  These extensions were simply promoted to standard features:
-
-   GL_ARB_occlusion_query extension
-   GL_ARB_texture_non_power_of_two extension
-   GL_ARB_vertex_buffer_object extension
-   GL_EXT_shadow_funcs
-
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on
-the device driver.  For example, if the driver enables all the ARB
-extensions which are part of OpenGL 1.3 then glGetString(GL_VERSION)
-will return "1.3".  Otherwise, it'll return "1.2".
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-
-
-Other Changes
--------------
-
-See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.0.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.0.1

@@ -1,49 +0,0 @@
-
-		       Mesa 6.0.1 release notes
-
-			    April 2, 2003
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Even-numbered versions (such as 6.0.x) designate stable releases.
-Odd-numbered versions (such as 6.1.x) designate new developmental releases.
-
-Mesa 6.0.1 just fixes bugs found since the 6.0 release.  See the VERSIONS
-file for details.
-
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5
-depending on the device driver's capabilities.  For example, if the
-driver enables all the ARB extensions which are part of OpenGL 1.5
-then glGetString(GL_VERSION) will return "1.5".  Otherwise, it'll
-return "1.4" or the next lower version that implements all required
-functionality.
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-FX (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.1

@@ -1,111 +0,0 @@
-
-                           Mesa 6.1 release notes
-
-                              August 18, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.0) designate stable releases.
-
-
-New Features
-------------
-
-Half-precision floating point (GLhalf) pixel formats are supported
-in Mesa, but the feature isn't exposed yet since the ARB extension
-hasn't been finalized yet.
-
-
-Texture image handling
-----------------------
-
-The code which implements image conversion, pixel transfer ops, etc
-for glTexImage commands has been rewritten.
-
-Now the gl_texture_format struct has a new StoreImage function
-pointer.  Each texture format must implement this function.  The
-function is totally responsible for converting the user's texture
-image into the specific format.  A few helper functions makes this
-relatively simple.
-
-Overall, the code is much simpler, cleaner and easier to work with
-now.  Adding new texture formats is straight-forward and there's no
-longer any distinction between "hardware" and "software" formats.
-
-Finally, the code for compressed texture images has been reorganized
-as well.
-
-Removed files:
-  texutil.c
-  texutil.h
-  texutil_tmp.h
-
-New files:
-  texcompress_s3tc.c
-  texcompress_fxt1.c
-
-
-
-Driver / context changes
-------------------------
-
-The _mesa_create_context() and _mesa_initialize_context() function
-parameters have changed.  They now take a pointer to a struct
-dd_function_table.  Drivers can initialize this table by calling
-_mesa_init_driver_functions().  Drivers should then plug in the special
-functions they implement.  In particular, the ctx->Driver.NewTextureObject
-pointer _must_ be set so that the default texture objects created in
-_mesa_create/initialize_context() are correctly built.
-
-The _mesa_init_driver_functions() function allows a lot of redundant code
-to be removed from the device drivers (such as initializing
-ctx->Driver.Accum to point to _swrast_Accum).  Adding new functions to
-the dd_function_table can be done with less hassle since the pointer can
-be initialized in _mesa_init_driver_functions() rather than in _all_ the
-drivers.
-
-
-Device Drivers
---------------
-
-Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5
-depending on the device driver's capabilities.  For example, if the
-driver enables all the ARB extensions which are part of OpenGL 1.5
-then glGetString(GL_VERSION) will return "1.5".  Otherwise, it'll
-return "1.4" or the next lower version that implements all required
-functionality.
-
-A number of Mesa's software drivers haven't been actively maintained for
-some time.  We rely on volunteers to maintain many of the drivers.
-Here's the current status of all included drivers:
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-
-Other Changes
--------------
-
-See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.1.
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.2

@@ -1,51 +0,0 @@
-
-                           Mesa 6.2 release notes
-
-                              October 2, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-This release primarily just fixes bugs found in the Mesa 6.1 release.
-See the VERSIONS file for details.
-
-
-ToDo: PBO for polygon stipple, convolution filter, etc.
-
-
-
-Known Issues
-------------
-
-The GL_EXT_pixel_buffer_object extension isn't fully implemented for
-functions like glPolygonStipple, glConvolutionFilter, glColorTable,
-etc.  The important functions like glRead/DrawPixels, glTex[Sub]Image,
-and glBitmap work with PBOs.
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.2.1

@@ -1,49 +0,0 @@
-
-                           Mesa 6.2.1 release notes
-
-                              December 9, 2004
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.1) designate new developmental releases.
-Even numbered versions (such as 6.2.x) designate stable releases.
-
-
-This release primarily just fixes bugs found in the Mesa 6.2 release.
-See the VERSIONS file for details.
-
-
-
-Known Issues
-------------
-
-The GL_EXT_pixel_buffer_object extension isn't fully implemented for
-functions like glPolygonStipple, glConvolutionFilter, glColorTable,
-etc.  The important functions like glRead/DrawPixels, glTex[Sub]Image,
-and glBitmap work with PBOs.  This has been fixed for Mesa 6.3.
-
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3

@@ -1,114 +0,0 @@
-
-                           Mesa 6.3 release notes
-
-                              July 20, 2005
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-
-New Features
-------------
-
-GL_ARB_draw_buffers - allows a fragment program to write to a number of
-  separate color buffers, instead of just one.
-
-GL_OES_read_format - allows one to query the fastest glReadPixels format
-  and datatype.
-
-GL_ARB_pixel_buffer_object - buffer objects for pixel read/write functions.
-
-GL_EXT_framebuffer_object - allows render-to-texture and provides a
-  window-system indepedent Pbuffer facility.
-  The Mesa CVS tree contains a couple tests of this extension.
-
-DirectFB driver, contributed by Claudio Ciccani.  See docs/README.directfb
-for details.
-
-
-
-Vertex/Fragment Program PRINT Instruction
------------------------------------------
-
-The GL_NV_vertex_program and GL_NV_fragment_program languages have been
-extended with a PRINT instruction.
-
-
-
-glDeleteTextures(), glDeletePrograms() and glDeleteBuffers() Changed
---------------------------------------------------------------------
-
-To match the behaviour of other OpenGL implementations, glDeleteTextures,
-glDeletePrograms and glDeleteBuffers have been modified so that:
-
-  * The named texture/program/buffer ID is immediately freed for re-use.
-
-  * The actual texture object, program or buffers isn't really deleted until
-    it is no longer bound in any rendering context (the reference count
-    is zero).
-
-Previously, the texture/program/buffer ID wasn't freed until the object
-was really deleted.
-
-Note that textures, programs and buffers can be shared by several rendering
-contexts so they can't be deleted until they're unbound in _all_ contexts.
-
-
-
-GL_EXT_framebuffer_object changes
----------------------------------
-
-Implementing this extension involved changing a lot of code (for the better).
-
-The gl_framebuffer object now a collection of gl_renderbuffer objects.
-Renderbuffers may store colors, stencil indices, or depth values.  The
-gl_framebuffer and gl_renderbuffer types are object-oriented in design.
-
-All the old RGB, color index, stencil and depth-related span functions for
-reading/writing pixels from/to buffers has changed.  Now, all pixels are
-read/written through a set of common renderbuffer functions (methods).
-
-Most device drivers have been updated for these changes, but some haven't.
-
-
-
-To Do (someday) items
----------------------
- Switch to freeglut
- Increase MAX_DRAWBUFFERS
- driver hooks for BeginQuery/EndQuery
-
-
-
-Miscellaneous
--------------
-
-The main/get.c file is now generated with a Python script (get_gen.py).
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3.1

@@ -1,48 +0,0 @@
-
-                           Mesa 6.3.1 release notes
-
-                               July XX, 2005
-
-                              PLEASE READ!!!!
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-
-DRI drivers
------------
-
-This release includes the DRI drivers and GLX code for hardware rendering.
-
-
-
-Bug fixes
----------
-
-Bugs fixed in 6.3.1 are listed in the VERSIONS file.
-
-
-
-Driver			Status
-----------------------	---------------------
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.3.2

@@ -1,36 +0,0 @@
-
-		       Mesa 6.3.2 Release Notes
-
-			   August 19, 2005
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.2) designate stable releases.
-
-
-6.3.2 is primarily a bug-fix release.  See the VERSIONS file for details.
-
-
-
-Driver			Status
-----------------------	----------------------
-DRI drivers		varies with the driver
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)	implements OpenGL 1.3
-SVGA			implements OpenGL 1.3
-Wind River UGL		implements OpenGL 1.3
-Windows/Win32		implements OpenGL 1.5
-DJGPP			implements OpenGL 1.5
-GGI			implements OpenGL 1.3
-BeOS			implements OpenGL 1.5
-Allegro			needs updating
-D3D			needs updating
-
-
-----------------------------------------------------------------------

docs/RELNOTES-6.4

@@ -1,49 +0,0 @@
-
-		        Mesa 6.4 Release Notes
-
-			   October 24, 2005
-
-
-
-Introduction
-------------
-
-Mesa uses an even/odd version number scheme like the Linux kernel.
-Odd numbered versions (such as 6.3) designate new developmental releases.
-Even numbered versions (such as 6.4) designate stable releases.
-
-
-6.4 is a bug-fix release.  See the VERSIONS file for details.
-
-
-
-GLUT tarball
-------------
-
-Starting with 6.4, the GLUT library sources are distributed in a separate
-tarball.  This was done at the request of Linux distro vendors who prefer
-to use freeglut.
-
-
-
-
-Driver			Status
-----------------------	----------------------
-DRI drivers		varies with the driver
-XMesa (Xlib)		implements OpenGL 1.5
-OSMesa (off-screen)	implements OpenGL 1.5
-Windows/Win32		implements OpenGL 1.5
-Glide (3dfx Voodoo1/2)  requires updates	
-SVGA			requires updates
-DJGPP			requires updates
-GGI			requires updates
-BeOS			requires updates
-Allegro			requires updates
-D3D			requires updates
-
-The drivers which require updates mostly need to be updated to work
-with the new gl_renderbuffer / gl_framebuffer infrastructure introduced
-in Mesa 6.3.
-
-
-----------------------------------------------------------------------

docs/VERSIONS

@@ -1,3 +1,4 @@
+$Id: VERSIONS,v 1.10 1999/07/30 18:58:30 brianp Exp $
 
 
 Mesa Version History
@@ -643,872 +644,12 @@ Mesa Version History
 	- new copyright on core Mesa code
 
 
-3.1 beta 3  September 17, 1999
+3.1 beta 3  August ??, 1999
     New:
 	- optimized glAccum function
-	- optimized 24bpp rendering in XMesa driver
-	- GLU 1.2 polygon tessellator
     Bug Fixes:
 	- glGetTexLevelParameter wasn't fully implemented
 	- glXUseXFont now handles multi-byte fonts
-	- glIsEnabled(GL_TEXTURE_2D / 3D) returned wrong result
-	- alpha channel of blending points, lines was sometimes incorrect
     Changes:
-	- New library names:  "libGL" instead of "libMesaGL"
+	- New library names:  libGL.so and libGLU.so
-	- New library numbering: libGL.so.1.2.310
 	- New subdirectories:  docs/ and bin/
-	- New Makefile-system (autoconf,automake,libtool)
-
-
-3.1 final  December 14, 1999
-    New:
-	- added demos/gloss.c
-	- added xdemos/glxdpyinfo.c
-	- added GLX_ARB_get_proc_address extension
-	- rewritten glTexImage code paths (faster, less memory, bug fixes)
-    Bug Fixes:
-	- several vertex array bug fixes
-	- overlapping glCopyPixels with pixel zooming now works
-	- glXUseXFont() bitmaps were vertically shifted by one pixel
-	- glCopyPixels with pixel zooming now works
-
-
-3.2 final  April 24, 2000
-    Bug fixes:
-	- fixed memcpy bugs in span.c
-	- fixed missing glEnd problem in demos/tessdemo.c
-	- fixed bug when clearing 24bpp Ximages
-	- fixed clipping problem found in Unreal Tournament
-	- fixed Loki's "ice bug" and "crazy triangles" seen in Heretic2
-	- fixed Loki's 3dfx RGB vs BGR bug
-	- fixed Loki's 3dfx smooth/flat shading bug in SoF
-    Changes:
-	- updated docs/README file
-	- use bcopy() optimizations on FreeBSD
-	- re-enabled the optimized persp_textured_triangle() function
-
-
-3.2.1  July 19, 2000
-    Bug fixes:
-	- gluBuild2DMipmaps() didn't accept GL_BGRA
-	- Fixed compile/makefile problems on IRIX
-	- fixed segfault in 3dfx driver when using GL selection/feedback
-	- no longer cull very, very tiny triangles
-	- blending w/ drawbuffer==GL_FRONT_BACK caused segfault (sw rendering)
-	- fixed Motif detection code in widgets-mesa/configure.in
-	- glColorMaterial and glMaterial updates to emissive and ambient
-	  didn't always work right
-	- Specular highlights weren't always in the right place
-	- clipped GL_LINE mode polygons had interior lines appear
-	- blend term GL_ONE_MINUS_CONSTANT_ALPHA was broken
-	- GL_NICEST fog didn't always work with flat shading
-	- glRect commands in display lists were sometimes miscolored
-	- Line Z offset didn't always work
-	- fixed texgen normal vector problem (gloss's teapot)
-	- numerous GL conformance bugs fixed
-    Changes:
-	- glColorMask(false, false, false, false) handled better/faster
-	- reverted to old GLU polygon tessellator, GLU 1.1
-	- updated Win32 build files
-
-
-3.3  July 21, 2000
-    New:
-	- antialiased triangles now implemented
-	- GL_EXT_texture_env_add texture mode extension
-	- GLX 1.3 API
-	- support for separate draw/read buffers (ie GL_SGI_make_current_read)
-	- thread-safe API dispath
-	- improved glxinfo program
-	- demos/texdown program to measure texture download performance
-	- glext.h header file
-	- demos/geartrain program
-	- GL_EXT_texture_lod_bias extension
-	- demos/lodbias program
-	- further optimized glRead/DrawPixels for 16-bit TrueColor X visuals
-	- GLX_EXT_visual_rating extension (a no-op, however)
-	- GL_HP_occlusion_test extension (for X and OS/Mesa drivers)
-	- demos/occlude program
-	- GL_SGIS_pixel_texture and GL_SGIX_pixel_texture extensions
-	- demos/pixeltex program
-	- GL_SGI_color_matrix extension
-	- GL_SGI_color_table extension
-	- GL_EXT_histogram extension
-	- GL_ARB_texture_cube_map extension
-	- added xdemos/glxheads and xdemos/manywin
-	- demos/texenv.c demo
-	- GL_EXT_texture_env_combine extension (by Holger Waechtler)
-	- Xlib driver is now thread-safe (see xdemos/glthreads)
-    Bug Fixes:
-	- various GL conformance failures fixed since 3.2.1
-    Changes:
-	- gl.h now uses #defines instead of C enums for all tokens
-	- glu.h now uses #defines instead of C enums for all tokens
-	- moved programs from 3Dfx/demos/ into demos/ directory
-
-
-3.4  November 3, 2000
-    New:
-	- optimized glDrawPixels for glPixelZoom(1,-1)
-    Bug Fixes:
-	- widgets-mesa/src/*.c files were missing from 3.3 distro
-	- include/GL/mesa_wgl.h file was missing from 3.3 distro
-	- fixed some Win32 compile problems
-	- texture object priorities weren't getting initialized to 1.0
-	- glAreTexturesResident return value was wrong when using hardware
-	- glXUseXFont segfaulted when using 3dfx driver (via MESA_GLX_FX)
-	- glReadPixels with GLushort packed types was broken
-	- fixed a few bugs in the GL_EXT_texture_env_combine texture code
-	- glPush/PopAttrib(GL_ENABLE_BIT) mishandled multi-texture enables
-	- fixed some typos/bugs in the VB code
-	- glDrawPixels(GL_COLOR_INDEX) to RGB window didn't work
-	- optimized glDrawPixels paths weren't being used
-	- per-fragment fog calculation didn't work without a Z buffer
-	- improved blending accuracy, fixes Glean blendFunc test failures
-	- glPixelStore(GL_PACK/UNPACK_SKIP_IMAGES) wasn't handled correctly
-	- glXGetProcAddressARB() didn't always return the right address
-	- gluBuild[12]DMipmaps() didn't grok the GL_BGR pixel format
-	- texture matrix changes weren't always detected (GLUT projtex demo)
-	- fixed random color problem in vertex fog code
-	- fixed Glide-related bug that let Quake get a 24-bit Z buffer
-    Changes:
-	- finished internal support for compressed textures for DRI
-
-
-3.4.1  February 14, 2001
-    New:
-	- fixed some Linux build problems
-	- fixed some Windows build problems
-	- GL_EXT_texture_env_dot3 extension (Gareth Hughes)
-    Bug fixes:
-	- added RENDER_START/RENDER_FINISH macros for glCopyTexImage in DRI
-	- various state-update code changes needed for DRI bugs
-	- disabled pixel transfer ops in glColorTable commands, not needed
-	- fixed bugs in glCopyConvolutionFilter1D/2D, glGetConvolutionFilter
-	- updated sources and fixed compile problems in widgets-mesa/
-	- GLX_PBUFFER enum value was wrong in glx.h
-	- fixed a glColorMaterial lighting bug
-	- fixed bad args to Read/WriteStencilSpan in h/w stencil clear function
-	- glXCopySubBufferMESA() Y position was off by one
-	- Error checking of glTexSubImage3D() was broken (bug 128775)
-	- glPopAttrib() didn't restore all derived Mesa state correctly
-	- Better glReadPixels accuracy for 16bpp color - fixes lots of OpenGL
-	  conformance problems at 16bpp.
-	- clearing depth buffer with scissoring was broken, would segfault
-	- OSMesaGetDepthBuffer() returned bad bytesPerValue value
-	- fixed a line clipping bug (reported by Craig McDaniel)
-	- fixed RGB color over/underflow bug for very tiny triangles
-    Known problems:
-	- NURBS or evaluator surfaces inside display lists don't always work
-
-
-3.4.2  May 17, 2001
-    Bug fixes:
-	- deleting the currently bound texture could cause bad problems
-	- using fog could result in random vertex alpha values
-	- AA triangle rendering could touch pixels outside right window bound
-	- fixed byteswapping problem in clear_32bit_ximage() function
-	- fixed bugs in wglUseFontBitmapsA(), by Frank Warmerdam
-	- fixed memory leak in glXUseXFont()
-	- fragment sampling in AA triangle function was off by 1/2 pixel
-	- Windows: reading pixels from framebuffer didn't always work
-	- glConvolutionFilter2D could segfault or cause FP exception
-	- fixed segfaults in FX and X drivers when using tex unit 1 but not 0
-	- GL_NAND logicop didn't work right in RGBA mode
-	- fixed a memory corruption bug in vertex buffer reset code
-	- clearing the softwara alpha buffer with scissoring was broken
-	- fixed a few color index mode fog bugs
-	- fixed some bad assertions in color index mode
-	- fixed FX line 'stipple' bug #420091
-	- fixed stencil buffer clear width/height typo
-	- fixed GL error glitches in gl[Client]ActiveTextureARB()
-	- fixed Windows compilation problem in texutil.c
-	- fixed 1/8-pixel AA triangle sampling error
-    Changes:
-	- optimized writing mono-colored pixel spans to X pixmaps
-	- increased max viewport size to 2048 x 2048
-
-
-3.5  June 21, 2001
-    New:
-	- internals of Mesa divided into modular pieces (Keith Whitwell)
-	- 100% OpenGL 1.2 conformance (passes all conformance tests)
-	- new AA line algorithm
-	- GL_EXT_convolution extension
-	- GL_ARB_imaging subset
-	- OSMesaCreateContextExt() function
-	- GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add)
-	- GL_MAX_TEXTURE_UNITS_ARB now defaults to eight
-	- GL_EXT_fog_coord extension (Keith Whitwell)
-	- GL_EXT_secondary_color extension (Keith Whitwell)
-	- GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add)
-	- GL_SGIX_depth_texture extension
-	- GL_SGIX_shadow and GL_SGIX_shadow_ambient extensions
-	- demos/shadowtex.c demo of GL_SGIX_depth_texture and GL_SGIX_shadow
-	- GL_ARB_texture_env_combine extension
-	- GL_ARB_texture_env_dot3 extension
-	- GL_ARB_texture_border_clamp (aka GL_SGIS_texture_border_clamp)
-	- OSMesaCreateContextExt() function
-	- libOSMesa.so library, contains the OSMesa driver interface
-	- GL/glxext.h header file for GLX extensions
-	- somewhat faster software texturing, fogging, depth testing
-	- all color-index conformance tests now pass (only 8bpp tested)
-	- SPARC assembly language TCL optimizations (David Miller)
-	- GL_SGIS_generate_mipmap extension
-    Bug Fixes:
-	- fbiRev and tmuRev were unitialized when using Glide3
-	- fixed a few color index mode conformance failures; all pass now
-	- now appling antialiasing coverage to alpha after texturing
-	- colors weren't getting clamped to [0,1] before color table lookup
-	- fixed RISC alignment errors caused by COPY_4UBV macro
-	- drawing wide, flat-shaded lines could cause a segfault
-	- vertices now snapped to 1/16 pixel to fix rendering of tiny triangles
-    Changes:
-	- SGI's Sample Implementation (SI) 1.3 GLU library replaces Mesa GLU
-	- new libOSMesa.so library, contains the OSMesa driver interface
-
-
-4.0  October 22, 2001
-    New:
-	- Mesa 4.0 implements the OpenGL 1.3 specification
-	- GL_IBM_rasterpos_clip extension
-	- GL_EXT_texture_edge_clamp extension (aka GL_SGIS_texture_edge_clamp)
-	- GL_ARB_texture_mirrored_repeat extension
-	- WindML UGL driver (Stephane Raimbault)
-	- added OSMESA_MAX_WIDTH/HEIGHT queries
-	- attempted compiliation fixes for Solaris 5, 7 and 8
-	- updated glext.h and glxext.h files
-	- updated Windows driver (Karl Schultz)
-    Bug fixes:
-	- added some missing GLX 1.3 tokens to include/GL/glx.h
-	- GL_COLOR_MATRIX changes weren't recognized by teximage functions
-	- glCopyPixels with scale and bias was broken
-	- glRasterPos with lighting could segfault
-	- glDeleteTextures could leave a dangling pointer
-	- Proxy textures for cube maps didn't work
-	- fixed a number of 16-bit color channel bugs
-	- fixed a few minor memory leaks
-	- GLX context sharing was broken in 3.5
-	- fixed state-update bugs in glPopClientAttrib()
-	- fixed glDrawRangeElements() bug
-	- fixed a glPush/PopAttrib() bug related to texture binding
-	- flat-shaded, textured lines were broken
-	- fixed a dangling pointer problem in the XMesa code (Chris Burghart)
-	- lighting didn't always produce the correct alpha value
-	- fixed 3DNow! code to not read past end of arrays (Andrew Lewycky)
-
-
-4.0.1 December 17, 2001
-    New:
-	- better sub-pixel sample positions for AA triangles (Ray Tice)
-	- slightly faster blending for (GL_ZERO, GL_ONE) and (GL_ONE, GL_ZERO)
-    Bug fixes:
-	- added missing break statements in glGet*() for multisample cases
-	- fixed uninitialized hash table mutex bug (display lists / texobjs)
-	- fixed bad teximage error check conditional (bug 476846)
-	- fixed demos readtex.c compilation problem on Windows (Karl Schultz)
-	- added missing glGet() query for GL_MAX_TEXTURE_LOD_BIAS_EXT
-	- silence some compiler warnings (gcc 2.96)
-	- enable the #define GL_VERSION_1_3 in GL/gl.h
-	- added GL 1.3 and GLX 1.4 entries to gl_mangle.h and glx_mangle.h
-	- fixed glu.h typedef problem found with MSDev 6.0
-	- build libGL.so with -Bsymbolic (fixes bug found with Chromium)
-	- added missing 'const' to glXGetContextIDEXT() in glxext.h
-	- fixed a few glXGetProcAddress() errors (texture compression, etc)
-	- fixed start index bug in compiled vertex arrays (Keith)
-	- fixed compilation problems in src/SPARC/glapi_sparc.S
-	- fixed triangle strip "parity" bug found in VTK medical1 demo (Keith)
-	- use glXGetProcAddressARB in GLUT to avoid extension linking problems
-	- provoking vertex of flat-shaded, color-index triangles was wrong
-	- fixed a few display list bugs (GLUT walker, molecule, etc) (Keith)
-	- glTexParameter didn't flush the vertex buffer (Ray Tice)
-	- feedback attributes for glDraw/CopyPixels and glBitmap were wrong
-	- fixed bug in normal length caching (ParaView lighting bug)
-	- fixed separate_specular color bug found in Chimera (18 Dec 2001)
-
-
-4.0.2  April 2, 2002
-    New:
-	- New DOS (DJGPP) driver written by Daniel Borca
-	- New driver interface functions for TCL drivers (such as Radeon DRI)
-	- GL_RENDERER string returns "Mesa Offscreen16" or "Mesa Offscreen32"
-	  if using deep color channels
-	- latest GL/glext.h and GL/glxext.h headers from SGI
-    Bug fixes:
-	- GL_BLEND with non-black texture env color wasn't always correct
-	- GL_REPLACE with GL_RGB texture format wasn't always correct (alpha)
-	- glTexEnviv( pname != GL_TEXTURE_ENV_COLOR ) was broken
-	- glReadPixels was sometimes mistakenly clipped by the scissor box
-	- glDraw/ReadPixels didn't catch all the errors that they should have
-	- Fixed 24bpp rendering problem in Windows driver (Karl Schultz)
-	- 16-bit GLchan mode fixes (m_trans_tmp.h, s_triangle.c)
-	- Fixed 1-bit float->int conversion bug in glDrawPixels(GL_DEPTH_COMP)
-	- glColorMask as sometimes effecting glXSwapBuffers()
-	- fixed a potential bug in XMesaGarbageCollect()
-	- N threads rendering into one window didn't work reliably
-	- glCopyPixels didn't work for deep color channels
-	- improved 8 -> 16bit/channel texture image conversion (Gerk Huisma)
-	- glPopAttrib() didn't correctly restore user clip planes
-	- user clip planes failed for some perspective projections (Chromium)
-    Known bugs:
-	- mipmap LOD computation
-
-
-4.0.3  June 25, 2002
-    New:
-	- updated GL/glext.h file (version 15)
-	- corrected MMX blend code (Jose Fonseca)
-	- support for software-based alpha planes in Windows driver
-	- updated GGI driver (Filip Spacek)
-    Bug fixes:
-	- glext.h had wrong values for GL_DOT3_RGB[A]_EXT tokens
-	- OSMesaMakeCurrent() didn't recognize buffer size changes
-	- assorted conformance fixes for 16-bit/channel rendering
-	- texcombine alpha subtraction mode was broken
-	- fixed lighting bug with non-uniform scaling and display lists
-	- fixed bug when deleting shared display lists
-	- disabled SPARC cliptest assembly code (Mesa bug 544665)
-	- fixed a couple Solaris compilation/link problems
-	- blending clipped glDrawPixels didn't always work
-	- glGetTexImage() didn't accept packed pixel types
-	- glPixelMapu[is]v() could explode given too large of pixelmap
-	- glGetTexParameter[if]v() didn't accept GL_TEXTURE_MAX_ANISOTROPY_EXT
-	- glXCopyContext() could lead to segfaults
-	- glCullFace(GL_FRONT_AND_BACK) didn't work (bug 572665)
-    Changes:
-	- lots of C++ (g++) code clean-ups
-	- lots of T&L updates for the Radeon DRI driver
-    Known bugs:
-	- mipmap LOD computation (fixed for Mesa 4.1)
-
-
-4.0.4  October 3, 2002
-    New:
-	- GL_NV_texture_rectangle extension
-	- updated glext.h header (version 17)
-	- updated DOS driver (Daniel Borca)
-	- updated BeOS R5 driver (Philippe Houdoin)
-	- added GL_IBM_texture_mirror_repeat
-	- glxinfo now takes -l option to print interesting OpenGL limits info
-	- GL_MESA_ycbcr_texture extension
-	- GL_APPLE_client_storage extension (for some DRI drivers only)
-	- GL_MESA_pack_invert extension
-    Bug fixes:
-	- fixed GL_LINEAR fog bug by adding clamping
-	- fixed FP exceptions found using Alpha CPU
-	- 3dfx MESA_GLX_FX=window (render to window) didn't work
-	- fixed memory leak in wglCreateContest (Karl Schultz)
-	- define GLAPIENTRY and GLAPI if undefined in glu.h
-	- wglGetProcAddress didn't handle all API functions
-	- when testing for OpenGL 1.2 vs 1.3, check for GL_ARB_texture_cube_map
-	- removed GL_MAX_CONVOLUTION_WIDTH/HEIGHT from glGetInteger/Float/etc()
-	- error checking in compressed tex image functions had some glitches
-	- fixed AIX compile problem in src/config.c
-	- glGetTexImage was using pixel unpacking instead of packing params
-	- auto-mipmap generation for cube maps was incorrect
-    Changes:
-	- max texture units reduced to six to accomodate texture rectangles
-	- removed unfinished GL_MESA_sprite_point extension code
-
-
-4.1  October 29, 2002
-    New:
-	- GL_NV_vertex_program extension
-	- GL_NV_vertex_program1_1 extension
-	- GL_ARB_window_pos extension
-	- GL_ARB_depth_texture extension
-	- GL_ARB_shadow extension
-	- GL_ARB_shadow_ambient extension
-	- GL_EXT_shadow_funcs extension
-	- GL_ARB_point_parameters extension
-	- GL_ARB_texture_env_crossbar
-	- GL_NV_point_sprite extension
-	- GL_NV_texture_rectangle extension
-	- GL_EXT_multi_draw_arrays extension
-	- GL_EXT_stencil_two_side extension
-	- GLX_SGIX_fbconfig and GLX_SGIX_pbuffer extensions
-	- GL_ATI_texture_mirror_once extension (Ian Romanick)
-	- massive overhaul/simplification of software rasterizer module,
-	  many contributions from Klaus Niederkrueger
-	- faster software texturing in some cases (i.e. trilinear filtering)
-	- new OSMesaGetProcAddress() function
-	- more blend modes implemented with MMX code (Jose Fonseca)
-	- added glutGetProcAddress() to GLUT
-	- added GLUT_FPS env var to compute frames/second in glutSwapBuffers()
-	- pbinfo and pbdemo PBuffer programs
-	- glxinfo -v prints transprent pixel info (Gerd Sussner)
-    Bug fixes:
-	- better mipmap LOD computation (prevents excessive blurriness)
-	- OSMesaMakeCurrent() didn't recognize buffer size changes
-	- assorted conformance fixes for 16-bit/channel rendering
-	- texcombine alpha subtraction mode was broken
-	- fixed some blend problems when GLchan==GLfloat (Gerk Huisma)
-	- clamp colors to [0,inf] in OSMesa if GLchan==GLfloat (Gerk Huisma)
-	- fixed divide by zero error in NURBS tessellator (Jon Perry)
-	- fixed GL_LINEAR fog bug by adding clamping
-	- fixed FP exceptions found using Alpha CPU
-	- 3dfx/glide driver render-to-window feature was broken
-	- added missing GLX_TRANSPARENT_RGB token to glx.h
-	- fixed error checking related to paletted textures
-	- fixed reference count error in glDeleteTextures (Randy Fayan)
-    Changes:
-	- New spec file and Python code to generate some GL dispatch files
-	- Glide driver defaults to "no" with autoconf/automake
-	- updated demos/stex3d with new options
-
-
-5.0  November 13, 2002
-    New:
-	- OpenGL 1.4 support (glGetString(GL_VERSION) returns "1.4")
-	- removed some overlooked debugging code
-	- glxinfo updated to support GLX_ARB_multisample
-	- GLUT now support GLX_ARB_multisample
-	- updated DOS driver (Daniel Borca)
-    Bug fixes:
-	- GL_POINT and GL_LINE-mode polygons didn't obey cull state
-	- fixed potential bug in _mesa_align_malloc/calloc()
-	- fixed missing triangle bug when running vertex programs
-	- fixed a few HPUX compilation problems
-	- FX (Glide) driver didn't compile
-	- setting GL_TEXTURE_BORDER_COLOR with glTexParameteriv() didn't work
-	- a few EXT functions, like glGenTexturesEXT, were no-ops
-	- a few OpenGL 1.4 functions like glFogCoord*, glBlendFuncSeparate,
-	  glMultiDrawArrays and glMultiDrawElements were missing
-	- glGet*(GL_ACTIVE_STENCIL_FACE_EXT) was broken
-	- Pentium 4 Mobile was mistakenly identified as having 3DNow!
-	- fixed one-bit error in point/line fragment Z calculation
-	- fixed potential segfault in fakeglx code
-	- fixed color overflow problem in DOT3 texture env mode
-
-
-5.0.1  March 30, 2003
-    New:
-	- DOS driver updates from Daniel Borca
-	- updated GL/gl_mangle.h file (Bill Hoffman)
-    Bug fixes:
-	- auto mipmap generation for cube maps was broken (bug 641363)
-	- writing/clearing software alpha channels was unreliable
-	- minor compilation fixes for OS/2 (Evgeny Kotsuba)
-	- fixed some bad assertions found with shadowtex demo
-	- fixed error checking bug in glCopyTexSubImage2D (bug 659020)
-	- glRotate(angle, -x, 0, 0) was incorrect (bug 659677)
-	- fixed potential segfault in texture object validation (bug 659012)
-	- fixed some bogus code in _mesa_test_os_sse_exception_support (Linus)
-	- fix fog stride bug in tnl code for h/w drivers (Michel Danzer)
-	- fixed glActiveTexture / glMatrixMode(GL_TEXTURE) bug (#669080)
-	- glGet(GL_CURRENT_SECONDARY_COLOR) should return 4 values, not 3
-	- fixed compilation problem on Solaris7/x86 (bug 536406)
-	- fixed prefetch bug in 3DNow! code (Felix Kuhling)
-	- fixed NeXT build problem (FABSF macro)
-	- glDrawPixels Z values when glPixelZoom!=1 were invalid (bug 687811)
-	- zoomed glDraw/CopyPixels with clipping sometimes failed (bug 689964)
-	- AA line and triangle Z values are now rounded, not truncated
-	- fixed color interpolation bug when GLchan==GLfloat (bug 694461)
-	- glArePrograms/TexturesResident() wasn't 100% correct (Jose Fonseca)
-	- fixed a minor GL_COLOR_MATERIAL bug
-	- NV vertex program EXP instruction was broken
-	- glColorMask misbehaved with X window / pixmap rendering
-	- fix autoconf/libtool GLU C++ linker problem on Linux (a total hack)
-	- attempt to fix GGI compilation problem when MesaDemos not present
-	- NV vertex program ARL-relative fetches didn't work
-    Changes:
-	- use glPolygonOffset in gloss demo to avoid z-fighting artifacts
-	- updated winpos and pointblast demos to use ARB extensions
-	- disable SPARC normal transformation code (bug 673938)
-	- GLU fixes for OS/2 (Evgeny Kotsuba)
-
-
-5.0.2  September 5, 2003
-    Bug fixes:
-	- fixed texgen problem causing texcoord's Q to be zero (stex3d)
-	- default GL_TEXTURE_COMPARE_MODE_ARB was wrong
-	- GL_CURRENT_MATRIX_NV query was wrong
-	- GL_CURRENT_MATRIX_STACK_DEPTH_NV query was off by one
-	- GL_LIST_MODE query wasn't correct
-	- GL_FOG_COORDINATE_SOURCE_EXT query wasn't supported
-	- GL_SECONDARY_COLOR_ARRAY_SIZE_EXT query returned wrong value
-	- blended, wide lines didn't always work correctly (bug 711595)
-	- glVertexAttrib4svNV w component was always 1
-	- fixed bug in GL_IBM_rasterpos_clip (missing return)
-	- GL_DEPTH_TEXTURE_MODE = GL_ALPHA didn't work correctly
-	- a few Solaris compilation fixes
-	- fixed glClear() problem for DRI drivers (non-existant stencil, etc)
-	- fixed int/REAL mixup in GLU NURBS curve evaluator (Eric Cazeaux)
-	- fixed delete [] bug in SI GLU (bug 721765) (Diego Santa Cruz)
-	- glFog() didn't clamp fog colors
-	- fixed bad float/int conversion for GL_TEXTURE_PRIORITY in the
-	  gl[Get]TexParameteri[v] functions
-	- fixed invalid memory references in glTexGen functions (bug 781602)
-	- integer-valued color arrays weren't handled correctly
-	- glDrawPixels(GL_DEPTH_COMPONENT) with glPixelZoom didn't work
-	- GL_EXT_texture_lod_bias is part of 1.4, overlooked in 5.0.1
-    Changes:
-	- build GLUT with -fexceptions so C++ apps propogate exceptions
-
-
-5.1  December 17, 2003
-    New:
-	- reorganized directory tree
-	- GL_ARB_vertex/fragment_program extensions (Michal Krol & Karl Rasche)
-	- GL_ATI_texture_env_combine3 extension (Ian Romanick)
-	- GL_SGI_texture_color_table extension (Eric Plante)
-	- GL_NV_fragment_program extension
-	- GL_NV_light_max_exponent extension
-	- GL_EXT_texture_rectangle (identical to GL_NV_texture_rectangle)
-	- GL_ARB_occlusion_query extension
-	- GL_ARB_point_sprite extension
-	- GL_ARB_texture_non_power_of_two extension
-	- GL_IBM_multimode_draw_arrays extension
-	- GL_EXT_texture_mirror_clamp extension (Ian Romanick)
-	- GL_ARB_vertex_buffer_object extension
-	- new X86 feature detection code (Petr Sebor)
-	- less memory used for display lists and vertex buffers
-	- demo of per-pixel lighting with a fragment program (demos/fplight.c)
-	- new version (18) of glext.h header
-	- new spriteblast.c demo of GL_ARB_point_sprite
-	- faster glDrawPixels in X11 driver in some cases (see RELNOTES-5.1)
-	- faster glCopyPixels in X11 driver in some cases (see RELNOTES-5.1)
-    Bug fixes:
-	- really enable OpenGL 1.4 features in DOS driver.
-	- fixed issues in glDrawPixels and glCopyPixels for very wide images
-	- glPixelMapf/ui/usv()'s size parameter is GLsizei, not GLint
-	- fixed some texgen bugs reported by Daniel Borca
-	- fixed wglMakeCurrent(NULL, NULL) bug (#835861)
-	- fixed glTexSubImage3D z-offset bug (Cedric Gautier)
-	- fixed RGBA blend enable bug (Ville Syrjala)
-	- glAccum is supposed to be a no-op in selection/feedback mode
-	- fixed texgen bug #597589 (John Popplewell)
-    Changes:
-	- dropped API trace feature (src/Trace/)
-	- documentation overhaul.  merged with website content.  more html.
-	- glxgears.c demo updated to use GLX swap rate extensions
-	- glTexImage1/2/3D now allows width/height/depth = 0
-	- disable SPARC asm code on Linux (bug 852204)
-
-
-6.0  January 16, 2004
-    New:
-	- full OpenGL 1.5 support
-	- updated GL/glext.h file to version 21
-    Changes:
-	- changed max framebuffer size to 4Kx4K (MAX_WIDTH/HEIGHT in config.h)
-    Bug fixes:
-	- fixed bug in UNCLAMPED_FLOAT_TO_UBYTE macro; solves a color
-	  clamping issue
-	- updated suno5-gcc configs
-	- glColor3 functions sometimes resulted in undefined alpha values
-	- fixed FP divide by zero error seen on VMS with xlockmore, others
-	- fixed vertex/fragment program debug problem (bug 873011)
-	- building on AIX with gcc works now
-	- glDeleteProgramsARB failed for ARB fragment programs (bug 876160)
-	- glDrawRangeElements tried to modify potentially read-only storage
-	- updated files for building on Windows
-
-
-6.0.1  April 2, 2004
-    New:
-	- upgraded glext.h to version 22
-	- new build targets (Dan Schikore)
-	- new linux-x86-opteron build target (Heath Feather)
-    Bug fixes:
-	- glBindProgramARB didn't update all necessary state
-	- fixed build problems on OpenBSD
-	- omit CVS directories from tarballs
-	- glGetTexImage(GL_COLOR_INDEX) was broken
-	- fixed an infinite loop in t&l module
-	- silenced some valgrind warnings about using unitialized memory
-	- fixed some compilation/link glitches on IRIX (Mike Stephens)
-	- glBindProgram wasn't getting compiled into display lists
-	- GLX_FBCONFIG_ID wasn't recognized in glXChooseFBConfig() (bug 888079)
-	- two-sided lighting and vertex program didn't work (bug 887330)
-	- stores to program parameter registers in vertex state programs
-	  didn't work.
-	- fixed glOrtho bug found with gcc 3.2.2 (RH9)
-	- glXCreateWindow() wasn't fully implemented (bug 890894)
-	- generic vertex attribute arrays didn't work in display lists
-	- vertex buffer objects' default usage and access fields were wrong
-	- glDrawArrays with start!=0 was broken
-	- fragment program PK2H, UP2H, UP4B and UP4UB instructions were broken
-	- linux-osmesa16-static config didn't work
-	- fixed a few color index rendering problems (bug 910687)
-	- glInterleavedArrays didn't respect GL_CLIENT_ACTIVE_TEXTURE
-	- OSMesa RGB and BGR modes were broken
-	- glProgramStringARB mistakenly required a null-terminated string
-	- fragment program XPD instruction was incorrect
-	- glGetMaterial() didn't work reliably
-	- ARB_fragment_program KIL instruction was incorrect
-
-
-6.1  August 18, 2004
-    New:
-	- Revamped Makefile system
-	- glXUseRotatedXFont() utility (see xdemos/xuserotfont.c)
-	- internal driver interface changes related to texture object
-	  allocation, vertex/fragment programs, BlendEquationSeparate, etc.
-	- option to walk triangle edges with double-precision floats
-	  (Justin Novosad of Discreet) (see config.h file)
-	- support for AUX buffers in software GLX driver
-	- updated glext.h to version 24 and glxext.h to version 6
-	- new MESA_GLX_FORCE_ALPHA and MESA_GLX_DEPTH_BITS env vars
-	- updated BeOS support (Philippe Houdoin)
-    Changes:
-	- fragment fog interpolation is perspective corrected now
-	- new glTexImage code, much cleaner, may be a bit faster
-    Bug fixes:
-	- glArrayElement in display lists didn't handle generic vertex attribs
-	- glFogCoord didn't always work properly
-	- ARB_fragment_program fog options didn't work
-	- frag prog TEX instruction no longer incorrectly divides s,t,r by q
-	- ARB frag prog TEX and TEXP instructions now use LOD=0
-	- glTexEnviv in display lists didn't work
-	- glRasterPos didn't do texgen or apply texture matrix
-	- GL_DOUBLE-valued vertex arrays were broken in some cases
-	- fixed texture rectangle edge/border sampling bugs
-	- sampling an incomplete texture in a fragment program would segfault
-	- glTexImage was missing a few error checks
-	- fixed some minor glGetTexParameter glitches
-	- GL_INTENSITY was mistakenly accepted as a <format> to glTexImage
-	- fragment program writes to RC/HC register were broken
-	- fixed a few glitches in GL_HP_occlusion_test extension
-	- glBeginQueryARB and glEndQueryARB didn't work inside display lists
-	- vertex program state references were broken
-	- fixed triangle color interpolation bug on AIX (Shane Blackett)
-	- fixed a number of minor memory leaks (bug #1002030)
-
-
-6.2  October 2, 2004
-    New:
-	- enabled GL_ARB_texture_rectangle (same as GL_NV_texture_rectangle)
-	- updated Doxygen support (Jose Fonseca)
-    Changes:
-	- some GGI driver updates (Christoph Egger, bug 1025977)
-    Bug fixes:
-	- Omit GL_ARB_texture_non_power_of_two from list of OpenGL 1.5 features
-	- fixed a few compilation issues on IRIX
-	- fixed a matrix classification bug (reported by Wes Bethel)
-	- we weren't reseting the vertex/fragment program error state
-	  before parsing (Dave Reveman)
-	- adjust texcoords for sampling texture rectangles (Dave Reveman)
-	- glGet*(GL_MAX_VERTEX_ATTRIBS_ARB) wasn't implemented
-	- repeated calls to glDeleteTexture(t) could lead to a crash
-	- fixed potential ref count bugs in VBOs and vertex/fragment programs
-	- spriteblast demo didn't handle window size changes correctly
-	- glTexSubImage didn't handle pixels=NULL correctly for PBOs
-	- fixed color index mode glDrawPixels bug (Karl Schultz)
-
-
-6.2.1  December 9, 2004
-    Bug fixes:
-	- don't apply regular fog or color sum when using a fragment program
-	- glProgramEnvParameter4fARB always generated an error on
-	  GL_FRAGMENT_PROGRAM_ARB (fdo bug 1645)
-	- glVertexAttrib3svNV and glVertexAttrib3svARB were broken
-	- fixed width/height mix-up in glSeparableFilter2D()
-	- fixed regression in glCopyPixels + convolution
-	- glReadPixels from a clipped front color buffer didn't always work
-	- glTexImage didn't accept GL_RED/GREEN/BLUE as the format
-	- Attempting queries/accesses of VBO 0 weren't detected as errors
-	- paletted textures failed if the palette had fewer than 256 entries
-    Changes:
-	- fixed a bunch of compiler warnings found with gcc 3.4
-	- bug reports should to go bugzilla.freedesktop.org
-
-
-6.3  July 20, 2005
-    New:
-	- GL_EXT_framebuffer_object extension
-	- GL_ARB_draw_buffers extension
-	- GL_ARB_pixel_buffer_object extension
-	- GL_OES_read_format extension (Ian Romanick)
-	- DirectFB driver (Claudio Ciccani)
-	- x86_64 vertex transformation code (Mikko T.)
-	- Updated GL/glext.h to version 29
-    Changes:
-	- added -stereo option for glxgears demo (Jacek Rosik)
-	- updated the PBuffer demo code in xdemos/ directory
-	- glDeleteTextures/Programs/Buffers() now makes the object ID
-	  available for immediate re-use
-	- assorted 64-bit clean-ups fixes (x86_64 and Win64)
-	- lots of internal changes for GL_EXT_framebuffer_object
-    Bug fixes:
-	- some functions didn't support PBO functionality
-	- glGetTexImage didn't convert color index images to RGBA as required
-	- fragment program texcoords were sometimes wrong for points and lines
-	- fixed problem with negative dot product in arbfplight, fplight demos
-	- fixed bug in perspective correction of antialiased, textured lines
-	- querying GL_POST_CONVOLUTION_ALPHA_BIAS_EXT returned wrong value
-	- fixed a couple per-pixel fog bugs (Soju Matsumoto)
-	- glGetBooleanv(GL_FRAGMENT_PROGRAM_BINDING_NV) was broken
-	- fixed float parsing bug in ARB frag/vert programs (bug 2520)
-	- XMesaGetDepthBuffer() returned incorrect value for bytesPerValue
-	- GL_COLOR_MATERIAL with glColor3 didn't properly set diffuse alpha
-	- glXChooseFBConfig() crashed if attribList pointer was NULL
-	- program state.light[n].spot.direction.w was wrong value (bug 3083)
-	- fragment program fog option required glEnable(GL_FOG) - wrong.
-	- glColorTable() could produce a Mesa implementation error (bug 3135)
-	- RasterPos could get corrupted by color index rendering path
-	- Removed bad XTranslateCoordinates call when rendering to Pixmaps
-	- glPopAttrib() didn't properly restore GL_TEXTURE_GEN enable state
-	- fixed a few Darwin compilation problems
-
-
-6.3.1
-    This was an intermediate release for X.org which wasn't otherwise released.
-
-
-6.3.2  August 19, 2005
-    New:
-	- The distribution now includes the DRI drivers and GLX code
-    Changes:
-	- Made the DRI "new" driver interface standard, remove old code
-    Bug fixes:
-	- GL_ARB_vertex/fragment_shader were mistakenly listed in the
-	  extensions string
-	- negative relative addressing in vertex programs was broken
-	- update/fix SPARC assembly code for vertex transformation
-	- fixed memory leak when freeing GLX drawables/renderbuffers
-	- fixed display list memory leak
-	- the GL_PIXEL_MAP_I_TO_I table is now floating point, not integer
-	- wglGetProcAddress() didn't handle wgl-functions
-	- fixed glxext.h cross-compile issue (Colin Harrison)
-	- assorted DRI driver fixes
-
-
-6.4  October 24, 2005
-    New:
-	- Added a fast XOR line drawing function in Xlib driver
-	- Added support for GL_ARB_texture_mirrored_repeat to savage
-	  driver (supported only on Savage4 hardware).
-    Changes:
-	- Mesa now packaged in three parts: Library, Demos and GLUT
-    Bug fixes:
-	- GLX_X_RENDERABLE token wasn't accepted by glXChooseFBConfig
-	- Some files were present multiple times in the 6.3.2 tarballs
-	- r200_vtxtmp_x86.S file was missing from 6.3.2 tarball (bug 4207)
-	- glxgears_fbconfig demo didn't work (bug 4237)
-	- fixed bug when bilinear sampling 2d textures with borders
-	- glXCreatePbuffer() could segfault instead of returning 0 (bug 4235)
-	- fixed undefined frexp and rand in X.org libGLcore.a (bug 4242)
-	- fixed a few problems with proxy color tables (bug 4270)
-	- fixed precision problem in Z clearing (bug 4395)
-	- glBitmap, glDraw/CopyPixels mistakenly generated selection hits
-	- fixed potential segfault caused by reading pixels outside
-	  of renderbuffer bounds
-	- glGetTexLevelParameter didn't accept GL_TEXTURE_DEPTH_SIZE_ARB
-	- fixed memory corruption bug involving software alpha buffers
-	- glReadPixels clipped by window bounds was sometimes broken
-	- glDraw/CopyPixels of stencil data ignored the stencil write mask
-	- glReadPixels from a texture bound to a framebuffer object didn't work
-	- glIsRender/FramebufferEXT weren't totally correct
-	- fixed a number of point size attenuation/fade bugs
-	- fixed glFogCoord bug 4729
-	- GLX encoding for transpose matrix functions was broken
-	- fixed broken fragment program KIL and SWZ instructions
-	- fragment programs that wrote result.depth.z didn't work
-
-
-6.4.1  November 30, 2005
-    Bug fixes:
-	- redefining a vertex program string didn't take effect in TNL module
-	- fixed occasional segfault upon vertex/fragment parsing error
-	- vertex program LIT instruction didn't handle 0^0=1 correctly
-	- fragment program fog option didn't work with glDrawPixels, glBitmap
-	- USE_MGL_NAMESPACE didn't work for x86-64
-	- OSMesa demos were missing from previous release tarballs
-	- fixed problem with float->ushort conversion in glClear (bug 4992)
-	- popping of GL_EYE_PLANE texgen state was broken (bug 4996)
-	- popping of GL_SPOT_DIRECTION light state was broken (bug 5005)
-	- fixed occasional triangle color interpolation problem on VMS
-	- work around invalid free() call (bug 5131)
-	- fixed BSD X server compilation problem by including stdint.h
-
-
-6.4.2  February 2, 2006
-    New:
-	- added OSMesaColorClamp() function/feature
-	- added wglGetExtensionStringARB() function
-    Bug fixes:
-	- fixed some problems when building on Windows
-	- GLw header files weren't installed by installmesa script (bug 5396)
-	- GL/glfbdev.h file was missing from tarballs
-	- fixed TNL initialization bug which could lead to crash (bug 5791)
-
-
-6.5  March 31, 2006
-    New:
-	- OpenGL Shading Language support through GL_ARB_shader_objects,
-	  GL_ARB_shading_language_100, GL_ARB_vertex_shader and
-	  GL_ARB_fragment_shader (done by Michal Krol)
-	- GL_EXT_packed_depth_stencil extension
-	- GL_EXT_timer_query extension
-	- GL_EXT_framebuffer_blit extension
-	- GL_ARB_half_float_pixel
-	- reflect demo improved to support multiple windows
-	- singlebuffer demo (shows no/little-flicker single-buffered rendering)
-	- r200: enable GL_ARB_texture_env_crossbar, separate the texture
-	  sampling unit bits from the texture env combine enable bits
-	- r200: add support for GL_ATI_fragment_shader
-	- added fast XOR-mode line drawing optimization
-	- radeon: add support for all 3 tmus, GL_ARB_texture_cube_map
-	  and GL_EXT_fog_coord
-	- MESA_GLX_ALPHA_BITS env var for xlib driver
-	- many DRI driver updates (including screen rotation support
-	  for the Intel DRI driver)
-    Changes:
-	- removed GL_HP_occlusion_test (use GL_ARB_occlusion_query instead)
-	- removed GL_SGIX/SGIS_pixel_texture extensions
-    Bug fixes:
-	- fixed glxcontextmodes.c datatype problem (bug 5835)
-	- fixed aix-gcc build/install bugs (bug 5874)
-	- fixed some bugs in texture env program generation
-	- glXCopyContext() didn't handle texture object bindings properly
-	- glXCopyContext() didn't copy all lighting state
-	- fixed FreeBSD config (Pedro Giffuni)
-	- fixed some minor framebuffer object bugs
-	- replaced dprintf() with _glu_printf() in GLU (bug 6244)
-	- fixed a number of thread safety bugs/regressions
-	- fixed a number of GLU tesselator bugs (John Shell, bug 6339)
-	- paletted texturing was broken w/ floating point palettes (K. Schultz)
-	- lots of assorted framebuffer object bug fixes
-
-6.5.1  August 31, 2006
-    New:
-	- Intel i965 DRI driver
-	- GL_APPLE_vertex_array_object extension (Ian Romanick)
-	- GL_EXT_texture_sRGB extension
-	- GL_EXT_gpu_program_parameters (Ian Romanick)
-	- "engine" demo
-	- updated fbdev driver and GLUT for fbdev (Sean D'Epagnier)
-	- many updates to the DRI drivers
-    Changes:
-	- The glVertexAttribARB functions no longer alias the conventional
-	  vertex attributes.
-	- glxinfo program prints more info with -l option
-	- GL_FRAGMENT_PROGRAM_NV and GL_FRAGMENT_PROGRAM_ARB are now
-	  compatible, in terms of glBindProgramARB()
-    Bug fixes:
-	- fixed broken texture border handling for depth textures (bug 6498)
-	- removed the test for duplicated framebuffer attachments, per
-	  version 117 of the GL_EXT_framebuffer_object specification
-	- fixed a few render-to-texture bugs, including render to depth texture
-	- clipping of lines against user-defined clip planes was broken (6512)
-	- assembly language dispatch for SPARC was broken (bug 6484)
-	- assorted compilation fixes on various Unix platforms (Dan Schikore)
-	- glPopAttrib could restore an invalid value for GL_DRAW_BUFFER
-	- assorted minor fixes for 16 and 32 bit/channel modes
-	- fixed assorted bugs in texture compression paths
-	- fixed indirect rendering vertex array crashes (bug 6863)
-	- glDrawPixels GL_INDEX_OFFSET didn't always work
-	- fixed convolution memory leak (bug 7077)
-	- rectangular depth textures didn't work
-	- invalid mode to glBegin didn't generate an error (bug 7142)
-	- 'normalized' parameter to glVertexAttribPointerARB didn't work
-	- disable bogus GLX_SGI_video_sync extension in xlib driver
-	- fixed R128 driver locking bug (Martijn van Oosterhout)
-	- using evaluators with vertex programs caused crashes (bug 7564)
-	- fragment.position wasn't set correctly for point/line primitives
-	- fixed parser bug for scalar sources for GL_NV_fragment_program
-	- max fragment program length was incorrectly 128, now 1024
-	- writes to result.depth in fragment programs weren't clamped to [0,1]
-	- fixed potential dangling pointer bug in glBindProgram()
-	- fixed some memory leaks (and potential crashes) in Xlib driver

docs/WL_bind_wayland_display.spec

@@ -1,92 +0,0 @@
-Name
-
-    WL_bind_wayland_display
-
-Name Strings
-
-    EGL_WL_bind_wayland_display
-
-Contact
-
-    Kristian Høgsberg <krh@bitplanet.net>
-    Benjamin Franzke <benjaminfranzke@googlemail.com>
-
-Status
-
-    Proposal
-
-Version
-
-    Version 1, March 1, 2011
-
-Number
-
-    EGL Extension #not assigned
-
-Dependencies
-
-    Requires EGL 1.4 or later.  This extension is written against the
-    wording of the EGL 1.4 specification.
-
-    EGL_KHR_base_image is required.
-
-Overview
-
-    This extension provides entry points for binding and unbinding the
-    wl_display of a Wayland compositor to an EGLDisplay.  Binding a
-    wl_display means that the EGL implementation should provide one or
-    more interfaces in the Wayland protocol to allow clients to create
-    wl_buffer objects.  On the server side, this extension also
-    provides a new target for eglCreateImageKHR, to create an EGLImage
-    from a wl_buffer
-
-    Adding an implementation specific wayland interface, allows the
-    EGL implementation to define specific wayland requests and events,
-    needed for buffer sharing in an EGL wayland platform.
-
-IP Status
-
-    Open-source; freely implementable.
-
-New Procedures and Functions
-
-    EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
-                                       struct wl_display *display);
-
-    EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
-                                         struct wl_display *display);
-
-New Tokens
-
-    Accepted as <target> in eglCreateImageKHR
-
-        EGL_WAYLAND_BUFFER_WL                   0x31D5
-
-Additions to the EGL 1.4 Specification:
-
-    To bind a server side wl_display to an EGLDisplay, call
-
-        EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
-                                           struct wl_display *display);
-
-    To unbind a server side wl_display from an EGLDisplay, call
-    
-        EGLBoolean eglUnbindWaylandDisplayWL(EGLDisplay dpy,
-                                             struct wl_display *display);
-
-    eglBindWaylandDisplayWL returns EGL_FALSE when there is already a
-    wl_display bound to EGLDisplay otherwise EGL_TRUE.
-
-    eglUnbindWaylandDisplayWL returns EGL_FALSE when there is no
-    wl_display bound to the EGLDisplay currently otherwise EGL_TRUE.
-
-    Import a wl_buffer by calling eglCreateImageKHR with
-    wl_buffer as EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target,
-    NULL context and an empty attribute_list.
-
-Issues
-
-Revision History
-
-    Version 1, March 1, 2011
-        Initial draft (Benjamin Franzke)

docs/autoconf.html

@@ -1,249 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Compilation and Installation using Autoconf</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Compilation and Installation using Autoconf</h1>
-
-<ol>
-<li><p><a href="#basic">Basic Usage</a></li>
-<li><p><a href="#driver">Driver Options</a>
-  <ul>
-  <li><a href="#xlib">Xlib Driver Options</a></li>
-  <li><a href="#dri">DRI Driver Options</a></li>
-  <li><a href="#osmesa">OSMesa Driver Options</a></li>
-  </ul>
-<li><p><a href="#library">Library Options</a>
-  <ul>
-  <li><a href="#glu">GLU</a></li>
-  </ul>
-<li><p><a href="#demos">Demo Program Options</a>
-</ol>
-
-
-<h2 id="basic">1. Basic Usage</h2>
-
-<p>
-The autoconf generated configure script can be used to guess your
-platform and change various options for building Mesa. To use the
-configure script, type:
-</p>
-
-<pre>
-    ./configure
-</pre>
-
-<p>
-To see a short description of all the options, type <code>./configure
---help</code>. If you are using a development snapshot and the configure
-script does not exist, type <code>./autogen.sh</code> to generate it
-first. If you know the options you want to pass to
-<code>configure</code>, you can pass them to <code>autogen.sh</code>. It
-will run <code>configure</code> with these options after it is
-generated. Once you have run <code>configure</code> and set the options
-to your preference, type:
-</p>
-
-<pre>
-    make
-</pre>
-
-<p>
-This will produce libGL.so and several other libraries depending on the
-options you have chosen. Later, if you want to rebuild for a different
-configuration run <code>make realclean</code> before rebuilding.
-</p>
-
-<p>
-Some of the generic autoconf options are used with Mesa:
-
-<ul>
-<li><code>--prefix=PREFIX</code> - This is the root directory where
-files will be installed by <code>make install</code>. The default is
-<code>/usr/local</code>.
-</li>
-<li><code>--exec-prefix=EPREFIX</code> - This is the root directory
-where architecture-dependent files will be installed. In Mesa, this is
-only used to derive the directory for the libraries. The default is
-<code>${prefix}</code>.
-</li>
-<li><code>--libdir=LIBDIR</code> - This option specifies the directory
-where the GL libraries will be installed. The default is
-<code>${exec_prefix}/lib</code>. It also serves as the name of the
-library staging area in the source tree. For instance, if the option
-<code>--libdir=/usr/local/lib64</code> is used, the libraries will be
-created in a <code>lib64</code> directory at the top of the Mesa source
-tree.
-</li>
-<li><code>--enable-static, --disable-shared</code> - By default, Mesa
-will build shared libraries. Either of these options will force static
-libraries to be built. It is not currently possible to build static and
-shared libraries in a single pass.
-</li>
-<li><code>CC, CFLAGS, CXX, CXXFLAGS</code> - These environment variables
-control the C and C++ compilers used during the build. By default,
-<code>gcc</code> and <code>g++</code> are used with the options
-<code>"-g -O2"</code>.
-</li>
-<li><code>LDFLAGS</code> - An environment variable specifying flags to
-pass when linking programs. These are normally empty, but can be used
-to direct the linker to use libraries in nonstandard directories. For
-example, <code>LDFLAGS="-L/usr/X11R6/lib"</code>.
-</li>
-<li><code>PKG_CONFIG_PATH</code> - When available, the
-<code>pkg-config</code> utility is used to search for external libraries
-on the system. This environment variable is used to control the search
-path for <code>pkg-config</code>. For instance, setting
-<code>PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig</code> will search for
-package metadata in <code>/usr/X11R6</code> before the standard
-directories.
-</li>
-</ul>
-
-<p>
-There are also a few general options for altering the Mesa build:
-<ul>
-<li><code>--with-x</code> - When the X11 development libraries are
-needed, the <code>pkg-config</code> utility <a href="#pkg-config">will
-be used</a> for locating them. If they cannot be found through
-<code>pkg-config</code> a fallback routing using <code>imake</code> will
-be used. In this case, the <code>--with-x</code>,
-<code>--x-includes</code> and <code>--x-libraries</code> options can
-control the use of X for Mesa.
-</li>
-<li><code>--enable-gl-osmesa</code> - The <a href="osmesa.html">OSMesa
-library</a> can be built on top of libGL for drivers that provide it.
-This option controls whether to build libOSMesa. By default, this is
-enabled for the Xlib driver and disabled otherwise. Note that this
-option is different than using OSMesa as the driver.
-</li>
-<li><code>--enable-debug</code> - This option will enable compiler
-options and macros to aid in debugging the Mesa libraries.
-</li>
-<li><code>--disable-asm</code> - There are assembly routines
-available for a few architectures. These will be used by default if
-one of these architectures is detected. This option ensures that
-assembly will not be used.
-</li>
-<li><code>--enable-32-bit, --enable-64-bit</code> - By default, the
-build will compile code as directed by the environment variables
-<code>CC</code>, <code>CFLAGS</code>, etc. If the compiler is
-<code>gcc</code>, these options offer a helper to add the compiler flags
-to force 32- or 64-bit code generation as used on the x86 and x86_64
-architectures.
-</li>
-</ul>
-
-
-<h2 id="driver">2. Driver Options</h2>
-
-<p>
-There are several different driver modes that Mesa can use. These are
-described in more detail in the <a href="install.html">basic
-installation instructions</a>. The Mesa driver is controlled through the
-configure option --with-driver. There are currently three supported
-options in the configure script.
-</p>
-
-<h3 id="xlib">Xlib</h3><p>This is the default mode for building Mesa.
-It uses Xlib as a software renderer to do all rendering. It corresponds
-to the option <code>--with-driver=xlib</code>. The libX11 and libXext
-libraries, as well as the X11 development headers, will be need to
-support the Xlib driver.
-
-<h3 id="dri">DRI</h3><p>This mode uses the DRI hardware drivers for
-accelerated OpenGL rendering. Enable the DRI drivers with the option
-<code>--with-driver=dri</code>. See the <a href="install.html">basic
-installation instructions</a> for details on prerequisites for the DRI
-drivers.
-
-<!-- DRI specific options -->
-<dl>
-<dt><code>--with-dri-driverdir=DIR</code>
-<dd><p> This option specifies the
-location the DRI drivers will be installed to and the location libGL
-will search for DRI drivers. The default is <code>${libdir}/dri</code>.
-<dt><code>--with-dri-drivers=DRIVER,DRIVER,...</code>
-<dd><p> This option
-allows a specific set of DRI drivers to be built. For example,
-<code>--with-dri-drivers="swrast,i965,radeon,nouveau"</code>. By
-default, the drivers will be chosen depending on the target platform.
-See the directory <code>src/mesa/drivers/dri</code> in the source tree
-for available drivers. Beware that the swrast DRI driver is used by both
-libGL and the X.Org xserver GLX module to do software rendering, so you
-may run into problems if it is not available.
-<!-- This explanation might be totally bogus. Kristian? -->
-<dt><code>--disable-driglx-direct</code>
-<dd><p> Disable direct rendering in
-GLX. Normally, direct hardware rendering through the DRI drivers and
-indirect software rendering are enabled in GLX. This option disables
-direct rendering entirely. It can be useful on architectures where
-kernel DRM modules are not available.
-<dt><code>--enable-glx-tls</code> <dd><p>
-Enable Thread Local Storage (TLS) in
-GLX.
-<dt><code>--with-expat=DIR</code> <dd> The DRI-enabled libGL uses expat to
-parse the DRI configuration files in <code>/etc/drirc</code> and
-<code>~/.drirc</code>. This option allows a specific expat installation
-to be used. For example, <code>--with-expat=/usr/local</code> will
-search for expat headers and libraries in <code>/usr/local/include</code>
-and <code>/usr/local/lib</code>, respectively.
-</dl>
-
-<h3 id="osmesa">OSMesa </h3><p> No libGL is built in this
-mode. Instead, the driver code is built into the Off-Screen Mesa
-(OSMesa) library. See the <a href="osmesa.html">Off-Screen Rendering</a>
-page for more details.
-
-<!-- OSMesa specific options -->
-<dl>
-<dt><code>--with-osmesa-bits=BITS</code>
-<dd><p> This option allows the size
-of the color channel in bits to be specified. By default, an 8-bit
-channel will be used, and the driver will be named libOSMesa. Other
-options are 16- and 32-bit color channels, which will add the bit size
-to the library name. For example, <code>--with-osmesa-bits=16</code>
-will create the libOSMesa16 library with a 16-bit color channel.
-</dl>
-
-
-<h2 id="library">3. Library Options</h2>
-
-<p>
-The configure script provides more fine grained control over the GL
-libraries that will be built. More details on the specific GL libraries
-can be found in the <a href="install.html">basic installation
-instructions</a>.
-
-<dl>
-<dt id="glu">GLU <dd><p> The libGLU library will be built by default
-on all drivers. This can be disable with the option
-<code>--disable-glu</code>.
-</dl>
-
-
-<h2 id="demos">4. Demo Program Options</h2>
-
-<p>
-There are many demonstration programs in the MesaDemos tarball. If the
-programs are available when <code>./configure</code> is run, a subset of
-the programs will be built depending on the driver and library options
-chosen. See the directory <code>progs</code> for the full set of demos.
-
-<dl>
-<dt><code>--with-demos=DEMOS,DEMOS,...</code>
-<dd><p> This option allows a
-specific set of demo programs to be built. For example,
-<code>--with-demos="xdemos,slang"</code>. Beware that if this option is
-used, it will not be ensured that the necessary GL libraries will be
-available.
-<dt><code>--without-demos</code> <dd><p> This completely disables building the
-demo programs. It is equivalent to <code>--with-demos=no</code>.
-</dl>
-
-</body>
-</html>

docs/banner.html

@@ -1,33 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Banner</title>
-  <style type="text/css">
-    <!--
-    body { background: black; color: white }
-    h1 {
-      font: x-large sans-serif; text-align: center;
-      height: 75px; margin-left: 100px; margin-right: 100px }
-    .gears { width: 100px; height: 73px; float: left; background: url('gears.png') right no-repeat }
-    div + .gears { float: right; background-position: left }
-    /*
-    This should happen in the future instead:
-    h1 {
-      border-left: 71px solid #c11800; border-right: 71px solid #00c130;
-      border-top: 0px; border-bottom: 0px;
-      border-image: url(gears.png) 100%; -webkit-border-image: url(gears.png) 100%;
-    }
-    */
-    -->
-  </style>
-</head>
-
-<body>
-
-<div class="gears"></div>
-<div class="gears"></div>
-<h1>The Mesa 3D Graphics Library</h1>
-
-</body>
-</html>

docs/bugs.html

@@ -1,54 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Mesa Bug Reporting</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Bug Database</h1>
-
-<p>
-The Mesa bug database is hosted on
-<a href="http://freedesktop.org" target="_parent">freedesktop.org</a>.
-The old bug database on SourceForge is no longer used.
-</p>
-
-<p>
-To file a Mesa bug, go to
-<a href="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa"
-target="_parent">
-Bugzilla on freedesktop.org</a>
-</p>
-
-<p>
-Please follow these bug reporting guidelines:
-</p>
-
-<ul>
-<li>Check if a new version of Mesa is available which might have fixed
-the problem.
-<li>Check if your bug is already reported in the database.
-<li>Monitor your bug report for requests for additional information, etc.
-<li>If you're reporting a crash, try to use your debugger (gdb) to get a stack
-trace. Also, recompile Mesa in debug mode to get more detailed information.
-<li>Describe in detail how to reproduce the bug, especially with games
-and applications that the Mesa developers might not be familiar with.
-<li>Provide a simple GLUT-based test program if possible
-</ul>
-
-<p>
-Bug reports will automatically be forwarded by bugzilla to the Mesa
-developer's mailing list.
-</p>
-
-<p>
-The easier a bug is to reproduce, the sooner it will be fixed.
-Please do everything you can to facilitate quickly fixing bugs.
-If your bug report is vague or your test program doesn't compile
-easily, the problem may not be fixed very quickly.
-</p>
-
-</body>
-</html>

docs/conform.html

@@ -1,696 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Conformance</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Conformance</h1>
-
-<p>
-The SGI OpenGL conformance tests verify correct operation of OpenGL
-implementations.  I, Brian Paul, have been given a copy of the tests
-for testing Mesa.  The tests are not publically available.
-</p>
-<p>
-This file has the latest results of testing Mesa with the OpenGL 1.2
-conformance tests.  Testing with the preliminary OpenGL 1.3 tests has
-also been done.  Mesa passes all the 1.3 tests.
-</p>
-<p>
-The tests were run using the software X11 device driver on 24-bpp
-and 16-bpp displays.
-</p>
-<p>
-Mesa 4.0 and later pass all conformance tests at all path levels.
-Note that this says nothing about the conformance of hardware drivers
-based upon Mesa.
-</p>
-
-
-<pre>
-
-COVERAGE TESTS
---------------
-
-Test that all API functions accept the legal parameters and reject
-illegal parameters.  The result of each test is either pass or fail.
-
-% covgl
-OpenGL Coverage Test.
-Version 1.2
-
-covgl passed.
-
-covgl passed at 1.1 level.
-
-covgl passed at 1.2 level.
-
-covgl passed for ARB_multitexture.
-
-
-% covglu
-OpenGL GLU Coverage Test.
-Version 1.3
-
-covglu passed.
-
-covglu passed at 1.1 level.
-
-
-% covglx
-OpenGL X Coverage Test.
-Version 1.1.1
-
-covglx passed.
-
-
-% primtest -v
-Open GL Primitives Test.
-Version 1.2
-
-[lots of output deleted]
-
-292159 Combinations.
-primtest passed.
-
-
-
-
-GL CONFORMANCE TEST
-===================
-
-Render test images, read them back, then test for expected results.
-
-
-----------------------------------------------------------------------
-% conform -v 2
-
-OpenGL Conformance Test
-Version 1.2
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path inactive.
-
-Visual Report.
-    Display ID = 35. Indirect Rendering.
-    Double Buffered.
-    RGBA (5, 6, 5, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-Must Pass test passed.
-Divide By Zero test passed.
-Viewport Clamp test passed.
-Matrix Stack test passed.
-Matrix Stack Mixing test passed.
-Vertex Order test passed.
-Transformations test passed.
-Transformation Normal test passed.
-Viewport Transformation test passed.
-Buffer Clear test passed.
-Buffer Corners test passed.
-Buffer Color test passed.
-Color Ramp test passed.
-Mask test passed.
-Buffer Invariance test passed.
-Accumulation Buffer test passed.
-Select test passed.
-Feedback test passed.
-Scissor test passed.
-Alpha Plane Function test passed.
-Stencil Plane Clear test passed.
-Stencil Plane Corners test passed.
-Stencil Plane Operation test passed.
-Stencil Plane Function test passed.
-Depth Buffer Clear test passed.
-Depth Buffer Function test passed.
-Blend test passed.
-Dither test passed.
-LogicOp Function test does not exist for an RGB visual.
-DrawPixels test passed.
-CopyPixels test passed.
-Bitmap Rasterization test passed.
-Point Rasterization test passed.
-Anti-aliased Point test passed.
-Line Rasterization test passed.
-Line Stipple test passed.
-Anti-aliased Line test passed.
-Horizontal and Vertical Line test passed.
-Triangle Rasterization test passed.
-Triangle Tile test passed.
-Triangle Stipple test passed.
-Anti-aliased Triangles test passed.
-Quad Rasterization test passed.
-Polygon Face test passed.
-Polygon Cull test passed.
-Polygon Stipple test passed.
-Polygon Edge test passed.
-Ambient Material test passed.
-Ambient Scene test passed.
-Attenuation Position test passed.
-Diffuse Light test passed.
-Diffuse Material test passed.
-Diffuse Material Normal test passed.
-Diffuse Material Positioning test passed.
-Emissive Material test passed.
-Specular Exponent test passed.
-Specular Exponent Normal test passed.
-Specular Local Eye Half Angle test passed.
-Specular Light test passed.
-Specular Material test passed.
-Specular Normal test passed.
-Spot Positioning test passed.
-Spot Exponent and Positioning test passed.
-Spot Exponent and Direction test passed.
-Fog Exponential test passed.
-Fog Linear test passed.
-Texture Decal test passed.
-Texture Border test passed.
-Mipmaps Selection test passed.
-Mipmaps Interpolation test passed.
-Display Lists test passed.
-Evaluator test passed.
-Evaluator Color test passed.
-Texture Edge Clamp test passed.
-Packed Pixels test passed.
-Texture LOD test passed.
-Rescale Normal test passed.
-Color Table test passed.
-Convolution test passed.
-Convolution Border test passed.
-Histogram test passed.
-MinMax test passed.
-MultiTexture test passed.
-
-Conform passed.
-
-----------------------------------------------------------------------
-% conform -v 2 -p 1
-
-OpenGL Conformance Test
-Version 1.2
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path level = 1.
-
-Visual Report.
-    Display ID = 35. Indirect Rendering.
-    Double Buffered.
-    RGBA (5, 6, 5, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-Must Pass test passed.
-Divide By Zero test passed.
-Viewport Clamp test passed.
-Matrix Stack test passed.
-Matrix Stack Mixing test passed.
-Vertex Order test passed.
-Transformations test passed.
-Transformation Normal test passed.
-Viewport Transformation test passed.
-Buffer Clear test passed.
-Buffer Corners test passed.
-Buffer Color test passed.
-Color Ramp test passed.
-Mask test passed.
-Buffer Invariance test passed.
-Accumulation Buffer test passed.
-Select test passed.
-Feedback test passed.
-Scissor test passed.
-Alpha Plane Function test passed.
-Stencil Plane Clear test passed.
-Stencil Plane Corners test passed.
-Stencil Plane Operation test passed.
-Stencil Plane Function test passed.
-Depth Buffer Clear test passed.
-Depth Buffer Function test passed.
-Blend test passed.
-Dither test passed.
-LogicOp Function test does not exist for an RGB visual.
-DrawPixels test passed.
-CopyPixels test passed.
-Bitmap Rasterization test passed.
-Point Rasterization test passed.
-Anti-aliased Point test passed.
-Line Rasterization test passed.
-Line Stipple test passed.
-Anti-aliased Line test passed.
-Horizontal and Vertical Line test passed.
-Triangle Rasterization test passed.
-Triangle Tile test passed.
-Triangle Stipple test passed.
-Anti-aliased Triangles test passed.
-Quad Rasterization test passed.
-Polygon Face test passed.
-Polygon Cull test passed.
-Polygon Stipple test passed.
-Polygon Edge test passed.
-Ambient Material test passed.
-Ambient Scene test passed.
-Attenuation Position test passed.
-Diffuse Light test passed.
-Diffuse Material test passed.
-Diffuse Material Normal test passed.
-Diffuse Material Positioning test passed.
-Emissive Material test passed.
-Specular Exponent test passed.
-Specular Exponent Normal test passed.
-Specular Local Eye Half Angle test passed.
-Specular Light test passed.
-Specular Material test passed.
-Specular Normal test passed.
-Spot Positioning test passed.
-Spot Exponent and Positioning test passed.
-Spot Exponent and Direction test passed.
-Fog Exponential test passed.
-Fog Linear test passed.
-Texture Decal test passed.
-Texture Border test passed.
-Mipmaps Selection test passed.
-Mipmaps Interpolation test passed.
-Display Lists test passed.
-Evaluator test passed.
-Evaluator Color test passed.
-Texture Edge Clamp test passed.
-Packed Pixels test passed.
-Texture LOD test passed.
-Rescale Normal test passed.
-Color Table test passed.
-Convolution test passed.
-Convolution Border test passed.
-Histogram test passed.
-MinMax test passed.
-MultiTexture test passed.
-
-Conform passed.
-
-----------------------------------------------------------------------
-% conform -v 2 -p 2
-
-OpenGL Conformance Test
-Version 1.2
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path level = 2.
-
-Visual Report.
-    Display ID = 35. Indirect Rendering.
-    Double Buffered.
-    RGBA (5, 6, 5, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-Must Pass test passed.
-Divide By Zero test passed.
-Viewport Clamp test passed.
-Matrix Stack test passed.
-Matrix Stack Mixing test passed.
-Vertex Order test passed.
-Transformations test passed.
-Transformation Normal test passed.
-Viewport Transformation test passed.
-Buffer Clear test passed.
-Buffer Corners test passed.
-Buffer Color test passed.
-Color Ramp test passed.
-Mask test passed.
-Buffer Invariance test passed.
-Accumulation Buffer test passed.
-Select test passed.
-Feedback test passed.
-Scissor test passed.
-Alpha Plane Function test passed.
-Stencil Plane Clear test passed.
-Stencil Plane Corners test passed.
-Stencil Plane Operation test passed.
-Stencil Plane Function test passed.
-Depth Buffer Clear test passed.
-Depth Buffer Function test passed.
-Blend test passed.
-Dither test passed.
-LogicOp Function test does not exist for an RGB visual.
-DrawPixels test passed.
-CopyPixels test passed.
-Bitmap Rasterization test passed.
-Point Rasterization test passed.
-Anti-aliased Point test passed.
-Line Rasterization test passed.
-Line Stipple test passed.
-Anti-aliased Line test passed.
-Horizontal and Vertical Line test passed.
-Triangle Rasterization test passed.
-Triangle Tile test passed.
-Triangle Stipple test passed.
-Anti-aliased Triangles test passed.
-Quad Rasterization test passed.
-Polygon Face test passed.
-Polygon Cull test passed.
-Polygon Stipple test passed.
-Polygon Edge test passed.
-Ambient Material test passed.
-Ambient Scene test passed.
-Attenuation Position test passed.
-Diffuse Light test passed.
-Diffuse Material test passed.
-Diffuse Material Normal test passed.
-Diffuse Material Positioning test passed.
-Emissive Material test passed.
-Specular Exponent test passed.
-Specular Exponent Normal test passed.
-Specular Local Eye Half Angle test passed.
-Specular Light test passed.
-Specular Material test passed.
-Specular Normal test passed.
-Spot Positioning test passed.
-Spot Exponent and Positioning test passed.
-Spot Exponent and Direction test passed.
-Fog Exponential test passed.
-Fog Linear test passed.
-Texture Decal test passed.
-Texture Border test passed.
-Mipmaps Selection test passed.
-Mipmaps Interpolation test passed.
-Display Lists test passed.
-Evaluator test passed.
-Evaluator Color test passed.
-Texture Edge Clamp test passed.
-Packed Pixels test passed.
-Texture LOD test passed.
-Rescale Normal test passed.
-Color Table test passed.
-Convolution test passed.
-Convolution Border test passed.
-Histogram test passed.
-MinMax test passed.
-MultiTexture test passed.
-
-Conform passed.
-
-----------------------------------------------------------------------
-% conform -v 2 -p 3
-
-OpenGL Conformance Test
-Version 1.2
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path level = 3.
-
-Visual Report.
-    Display ID = 35. Indirect Rendering.
-    Double Buffered.
-    RGBA (5, 6, 5, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-Must Pass test passed.
-Divide By Zero test passed.
-Viewport Clamp test passed.
-Matrix Stack test passed.
-Matrix Stack Mixing test passed.
-Vertex Order test passed.
-Transformations test passed.
-Transformation Normal test passed.
-Viewport Transformation test passed.
-Buffer Clear test passed.
-Buffer Corners test passed.
-Buffer Color test passed.
-Color Ramp test passed.
-Mask test passed.
-Buffer Invariance test passed.
-Accumulation Buffer test passed.
-Select test passed.
-Feedback test passed.
-Scissor test passed.
-Alpha Plane Function test passed.
-Stencil Plane Clear test passed.
-Stencil Plane Corners test passed.
-Stencil Plane Operation test passed.
-Stencil Plane Function test passed.
-Depth Buffer Clear test passed.
-Depth Buffer Function test passed.
-Blend test passed.
-Dither test passed.
-LogicOp Function test does not exist for an RGB visual.
-DrawPixels test passed.
-CopyPixels test passed.
-Bitmap Rasterization test passed.
-Point Rasterization test passed.
-Anti-aliased Point test passed.
-Line Rasterization test passed.
-Line Stipple test passed.
-Anti-aliased Line test passed.
-Horizontal and Vertical Line test passed.
-Triangle Rasterization test passed.
-Triangle Tile test passed.
-Triangle Stipple test passed.
-Anti-aliased Triangles test passed.
-Quad Rasterization test passed.
-Polygon Face test passed.
-Polygon Cull test passed.
-Polygon Stipple test passed.
-Polygon Edge test passed.
-Ambient Material test passed.
-Ambient Scene test passed.
-Attenuation Position test passed.
-Diffuse Light test passed.
-Diffuse Material test passed.
-Diffuse Material Normal test passed.
-Diffuse Material Positioning test passed.
-Emissive Material test passed.
-Specular Exponent test passed.
-Specular Exponent Normal test passed.
-Specular Local Eye Half Angle test passed.
-Specular Light test passed.
-Specular Material test passed.
-Specular Normal test passed.
-Spot Positioning test passed.
-Spot Exponent and Positioning test passed.
-Spot Exponent and Direction test passed.
-Fog Exponential test passed.
-Fog Linear test passed.
-Texture Decal test passed.
-Texture Border test passed.
-Mipmaps Selection test passed.
-Mipmaps Interpolation test passed.
-Display Lists test passed.
-Evaluator test passed.
-Evaluator Color test passed.
-Texture Edge Clamp test passed.
-Packed Pixels test passed.
-Texture LOD test passed.
-Rescale Normal test passed.
-Color Table test passed.
-Convolution test passed.
-Convolution Border test passed.
-Histogram test passed.
-MinMax test passed.
-MultiTexture test passed.
-
-Conform passed.
-
-----------------------------------------------------------------------
-% conform -v 2 -p 4
-
-OpenGL Conformance Test
-Version 1.2
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path level = 4.
-
-Visual Report.
-    Display ID = 35. Indirect Rendering.
-    Double Buffered.
-    RGBA (5, 6, 5, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-Must Pass test passed.
-Divide By Zero test passed.
-Viewport Clamp test passed.
-Matrix Stack test passed.
-Matrix Stack Mixing test passed.
-Vertex Order test passed.
-Transformations test passed.
-Transformation Normal test passed.
-Viewport Transformation test passed.
-Buffer Clear test passed.
-Buffer Corners test passed.
-Buffer Color test passed.
-Color Ramp test passed.
-Mask test passed.
-Buffer Invariance test passed.
-Accumulation Buffer test passed.
-Select test passed.
-Feedback test passed.
-Scissor test passed.
-Alpha Plane Function test passed.
-Stencil Plane Clear test passed.
-Stencil Plane Corners test passed.
-Stencil Plane Operation test passed.
-Stencil Plane Function test passed.
-Depth Buffer Clear test passed.
-Depth Buffer Function test passed.
-Blend test passed.
-Dither test passed.
-LogicOp Function test does not exist for an RGB visual.
-DrawPixels test passed.
-CopyPixels test passed.
-Bitmap Rasterization test passed.
-Point Rasterization test passed.
-Anti-aliased Point test passed.
-Line Rasterization test passed.
-Line Stipple test passed.
-Anti-aliased Line test passed.
-Horizontal and Vertical Line test passed.
-Triangle Rasterization test passed.
-Triangle Tile test passed.
-Triangle Stipple test passed.
-Anti-aliased Triangles test passed.
-Quad Rasterization test passed.
-Polygon Face test passed.
-Polygon Cull test passed.
-Polygon Stipple test passed.
-Polygon Edge test passed.
-Ambient Material test passed.
-Ambient Scene test passed.
-Attenuation Position test passed.
-Diffuse Light test passed.
-Diffuse Material test passed.
-Diffuse Material Normal test passed.
-Diffuse Material Positioning test passed.
-Emissive Material test passed.
-Specular Exponent test passed.
-Specular Exponent Normal test passed.
-Specular Local Eye Half Angle test passed.
-Specular Light test passed.
-Specular Material test passed.
-Specular Normal test passed.
-Spot Positioning test passed.
-Spot Exponent and Positioning test passed.
-Spot Exponent and Direction test passed.
-Fog Exponential test passed.
-Fog Linear test passed.
-Texture Decal test passed.
-Texture Border test passed.
-Mipmaps Selection test passed.
-Mipmaps Interpolation test passed.
-Display Lists test passed.
-Evaluator test passed.
-Evaluator Color test passed.
-Texture Edge Clamp test passed.
-Packed Pixels test passed.
-Texture LOD test passed.
-Rescale Normal test passed.
-Color Table test passed.
-Convolution test passed.
-Convolution Border test passed.
-Histogram test passed.
-MinMax test passed.
-MultiTexture test passed.
-
-Conform passed.
-
-
-
-GLX CONFORMANCE TEST
-====================
-
-% conformx -v 2
-
-OpenGL X Conformance Test
-Version 1.1.1
-
-Setup Report.
-    Verbose level = 2.
-    Random number seed = 1.
-    Path inactive.
-
-Visual Report.
-    Display ID = 34. Direct Rendering.
-    Double Buffered.
-    RGBA (8, 8, 8, 0).
-    Stencil (8).
-    Depth (16).
-    Accumulation (16, 16, 16, 16).
-
-Epsilon Report.
-    zero error epsilon = 0.000122.
-    RGBA error epsilon = 0.00404, 0.00404, 0.00404, 0.000122.
-    Depth buffer error epsilon = 0.000137.
-    Stencil plane error epsilon = 0.00404.
-    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
-
-Default State test passed.
-glReadPixels() test passed.
-Font test passed.
-
-Conformx passed.
-
-
-</pre>
-
-NOTE: conformx passes for all machine path levels (-p option).
-
-
-</body>
-</html>

docs/contents.html

@@ -1,107 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Contents</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-
-  <!--Override a few values from the style sheet: -->
-  <style type="text/css">
-    <!--
-    body {
-      background-color: #cccccc;
-      color: black;
-    }
-    a:link {
-      color: #000;
-    }
-    a:visited {
-      color: #000;
-    }
-    -->
-  </style>
-</head>
-<body>
-
-<b>Documentation</b>
-<ul>
-<li><a href="intro.html" target="MainFrame">Introduction</a>
-<li><a href="news.html" target="MainFrame">News</a>
-<li><a href="developers.html" target="MainFrame">Developers</a>
-<li><a href="systems.html" target="MainFrame">Platforms and Drivers</a>
-<li><a href="license.html" target="MainFrame">License &amp; Copyright</a>
-<li><a href="faq.html" target="MainFrame">FAQ</a>
-<li><a href="relnotes.html" target="MainFrame">Release Notes</a>
-<li><a href="thanks.html" target="MainFrame">Acknowledgements</a>
-<li><a href="conform.html" target="MainFrame">Conformance Testing</a>
-<li>more docs below...
-</ul>
-
-<b>Download / Install</b>
-<ul>
-<li><a href="download.html" target="MainFrame">Downloading / Unpacking</a>
-<li><a href="install.html" target="MainFrame">Compiling / Installing</a>
-<li><a href="precompiled.html" target="MainFrame">Precompiled Libraries</a>
-</ul>
-
-<b>Resources</b>
-<ul>
-<li><a href="lists.html" target="MainFrame">Mailing Lists</a>
-<li><a href="bugs.html" target="MainFrame">Bug Database</a>
-<li><a href="webmaster.html" target="MainFrame">Webmaster</a>
-<li><a href="http://dri.freedesktop.org/" target="_parent">Mesa/DRI Wiki</a>
-</ul>
-
-<b>User Topics</b>
-<ul>
-<li><a href="egl.html" target="MainFrame">EGL</a>
-<li><a href="opengles.html" target="MainFrame">OpenGL ES</a>
-<li><a href="openvg.html" target="MainFrame">OpenVG / Vega</a>
-<li><a href="envvars.html" target="MainFrame">Environment Variables</a>
-<li><a href="osmesa.html" target="MainFrame">Off-Screen Rendering</a>
-<li><a href="debugging.html" target="MainFrame">Debugging Tips</a>
-<li><a href="perf.html" target="MainFrame">Performance Tips</a>
-<li><a href="extensions.html" target="MainFrame">Mesa Extensions</a>
-<li><a href="mangling.html" target="MainFrame">Function Name Mangling</a>
-<li><a href="llvmpipe.html" target="MainFrame">Gallium llvmpipe driver</a>
-<li><a href="vmware-guest.html" target="MainFrame">VMware SVGA3D guest driver</a>
-<li><a href="postprocess.html" target="MainFrame">Gallium post-processing</a>
-<li><a href="viewperf.html" target="MainFrame">Viewperf Issues</a>
-</ul>
-
-<b>Developer Topics</b>
-<ul>
-<li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a>
-<li><a href="repository.html" target="MainFrame">Source Code Repository</a>
-<li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a>
-<li><a href="glu.html" target="MainFrame">SGI's GLU</a>
-<li><a href="utilities.html" target="MainFrame">Utilities</a>
-<li><a href="helpwanted.html" target="MainFrame">Help Wanted</a>
-<li><a href="devinfo.html" target="MainFrame">Development Notes</a>
-<li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a>
-<li><a href="subset.html" target="MainFrame">Mesa Subset Driver</a>
-<li><a HREF="dispatch.html" target="MainFrame">GL Dispatch</a>
-</ul>
-
-<b>Links</b>
-<ul>
-<li><a href="http://www.opengl.org" target="_parent">OpenGL website</a>
-<li><a href="http://dri.freedesktop.org" target="_parent">DRI website</a>
-<li><a href="http://www.freedesktop.org" target="_parent">freedesktop.org</a>
-<li><a href="games.html" target="MainFrame">Games and Entertainment</a>
-<li><a href="libraries.html" target="MainFrame">Libraries and Toolkits</a>
-<li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a>
-<li><a href="science.html" target="MainFrame">Science and Technical</a>
-<li><a href="utility.html" target="MainFrame">Utilities</a>
-</ul>
-
-<b>Hosted by:</b>
-<br>
-<blockquote>
-<a href="http://sourceforge.net"
-target="_parent"><img src="http://sourceforge.net/sflogo.php?group_id=3&amp;type=1"
-width="88" height="31" align="bottom" alt="Sourceforge.net" border="0"></a>
-</blockquote>
-
-</body>
-</html>

docs/debugging.html

@@ -1,39 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Debugging Tips</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Debugging Tips</h1>
-
-<p>
-   Normally Mesa (and OpenGL) records but does not notify the user of
-   errors.  It is up to the application to call
-   <code>glGetError</code> to check for errors.  Mesa supports an
-   environment variable, MESA_DEBUG, to help with debugging.  If
-   MESA_DEBUG is defined, a message will be printed to stdout whenever
-   an error occurs.
-</p>
-
-<p>
-   More extensive error checking is done when Mesa is compiled with the
-   DEBUG symbol defined.  You'll have to edit the Make-config file and
-   add -DDEBUG to the CFLAGS line for your system configuration.  You may
-   also want to replace any optimization flags with the -g flag so you can
-   use your debugger.  After you've edited Make-config type 'make clean'
-   before recompiling.
-</p>
-<p>
-   In your debugger you can set a breakpoint in _mesa_error() to trap Mesa
-   errors.
-</p>
-<p>
-   There is a display list printing/debugging facility.  See the end of
-   src/dlist.c for details.
-</p>
-
-</body>
-</html>

docs/developers.html

@@ -1,50 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Developers</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Developers</h1>
-
-<p>
-Both professional and volunteer developers contribute to Mesa.
-</p>
-<p>
-<a href="http://www.vmware.com/" target="_parent">VMware</a>
-employs several of the main Mesa developers including Brian Paul
-and Keith Whitwell.
-</p>
-
-<p>
-In the past, Tungsten Graphics contracts implemented many Mesa features
-including:
-</p>
-<ul>
-<li>DRI drivers for Intel i965, i945, i915 and other chips
-<li>Advanced memory manager and framebuffer object support
-<li>Shading language compiler and OpenGL 2.0 support
-<li>MiniGLX environment
-</ul>
-
-<p>
-Other companies including
-<a href="http://www.intellinuxgraphics.org/index.html" target="_parent">Intel</a>
-and RedHat also actively contribute to the project.
-Intel has recently contributed the new GLSL compiler in Mesa 7.9.
-</p>
-
-<p>
-<a href="http://www.lunarg.com/" target="_parent">LunarG</a> can be contacted
-for custom Mesa / 3D graphics development.
-</p>
-
-<p>
-Volunteers have made significant contributions to all parts of Mesa, including
-complete device drivers.
-</p>
-
-</body>
-</html>

docs/devinfo.html

@@ -1,247 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Development Notes</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Development Notes</h1>
-
-
-<h2>Adding Extentions</h2>
-
-<p>
-To add a new GL extension to Mesa you have to do at least the following.
-
-<ul>
-<li>
-   If glext.h doesn't define the extension, edit include/GL/gl.h and add
-   code like this:
-   <pre>
-     #ifndef GL_EXT_the_extension_name
-     #define GL_EXT_the_extension_name 1
-     /* declare the new enum tokens */
-     /* prototype the new functions */
-     /* TYPEDEFS for the new functions */
-     #endif
-   </pre>
-</li>
-<li>
-   In the src/mesa/glapi/ directory, add the new extension functions and
-   enums to the gl_API.xml file.
-   Then, a bunch of source files must be regenerated by executing the
-   corresponding Python scripts.
-</li>
-<li>
-   Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
-</li>
-<li>
-   Update the <code>extensions.c</code> file.
-</li>
-<li>
-   From this point, the best way to proceed is to find another extension,
-   similar to the new one, that's already implemented in Mesa and use it
-   as an example.
-</li>
-<li>
-   If the new extension adds new GL state, the functions in get.c, enable.c
-   and attrib.c will most likely require new code.
-</li>
-</ul>
-
-
-
-<h2>Coding Style</h2>
-
-<p>
-Mesa's code style has changed over the years.  Here's the latest.
-</p>
-
-<p>
-Comment your code!  It's extremely important that open-source code be
-well documented.  Also, strive to write clean, easily understandable code.
-</p>
-
-<p>
-3-space indentation
-</p>
-
-<p>
-If you use tabs, set them to 8 columns
-</p>
-
-<p>
-Line width: the preferred width to fill comments and code in Mesa is 78
-columns.  Exceptions are sometimes made for clarity (e.g. tabular data is
-sometimes filled to a much larger width so that extraneous carriage returns
-don't obscure the table).
-</p>
-
-<p>
-Brace example:
-</p>
-<pre>
-	if (condition) {
-	   foo;
-	}
-	else {
-	   bar;
-	}
-
-	switch (condition) {
-	case 0:
-	   foo();
-	   break;
-
-	case 1: {
-	   ...
-	   break;
-	}
-
-	default:
-	   ...
-	   break;
-	}
-</pre>
-
-<p>
-Here's the GNU indent command which will best approximate my preferred style:
-(Note that it won't format switch statements in the preferred way)
-</p>
-<pre>
-	indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
-</pre>
-
-
-<p>
-Local variable name example:  localVarName (no underscores)
-</p>
-
-<p>
-Constants and macros are ALL_UPPERCASE, with _ between words
-</p>
-
-<p>
-Global variables are not allowed.
-</p>
-
-<p>
-Function name examples:
-</p>
-<pre>
-	glFooBar()       - a public GL entry point (in glapi_dispatch.c)
-	_mesa_FooBar()   - the internal immediate mode function
-	save_FooBar()    - retained mode (display list) function in dlist.c
-	foo_bar()        - a static (private) function
-	_mesa_foo_bar()  - an internal non-static Mesa function
-</pre>
-
-<p>
-Places that are not directly visible to the GL API should prefer the use
-of <tt>bool</tt>, <tt>true</tt>, and
-<tt>false</tt> over <tt>GLboolean</tt>, <tt>GL_TRUE</tt>, and
-<tt>GL_FALSE</tt>.  In C code, this may mean that
-<tt>#include &lt;stdbool.h&gt;</tt> needs to be added.  The
-<tt>try_emit_</tt>* methods in src/mesa/program/ir_to_mesa.cpp and
-src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples.
-</p>
-
-
-<h2>Making a New Mesa Release</h2>
-
-<p>
-These are the instructions for making a new Mesa release.
-</p>
-
-<h3>Get latest source files</h3>
-<p>
-Use git to get the latest Mesa files from the git repository, from whatever
-branch is relevant.
-</p>
-
-
-<h3>Verify and update version info</h3>
-
-<dl>
-  <dt>configs/default</dt>
-  <dd>MESA_MAJOR, MESA_MINOR and MESA_TINY</dd>
-  <dt>Makefile.am</dt>
-  <dd>PACKAGE_VERSION</dd>
-  <dt>autoconf.ac</dt>
-  <dd>AC_INIT</dd>
-  <dt>src/mesa/main/version.h</dt>
-  <dd>MESA_MAJOR, MESA_MINOR, MESA_PATCH and MESA_VERSION_STRING</dd>
-</dl>
-
-<p>
-Create a docs/relnotes-x.y.z.html file.
-The bin/shortlog_mesa.sh script can be used to create a HTML-formatted list
-of changes to include in the file.
-Link the new docs/relnotes-x.y.z.html file into the main <a href="relnotes.html">relnotes.html</a> file.
-</p>
-
-<p>
-Update <a href="news.html">docs/news.html</a>.
-</p>
-
-<p>
-Tag the files with the release name (in the form <b>mesa-x.y</b>)
-with: <code>git tag -a mesa-x.y</code>
-Then: <code>git push origin mesa-x.y</code>
-</p>
-
-
-<h3>Make the tarballs</h3>
-<p>
-Make the distribution files.  From inside the Mesa directory:
-<pre>
-	make tarballs
-</pre>
-
-<p>
-After the tarballs are created, the md5 checksums for the files will
-be computed.
-Add them to the docs/relnotes-x.y.html file.
-</p>
-
-<p>
-Copy the distribution files to a temporary directory, unpack them,
-compile everything, and run some demos to be sure everything works.
-</p>
-
-<h3>Update the website and announce the release</h3>
-<p>
-Follow the directions on SourceForge for creating a new "release" and
-uploading the tarballs.
-</p>
-
-<p>
-Basically, to upload the tarball files with:
-<br>
-<code>
-rsync -avP ssh Mesa*-X.Y.* USERNAME@frs.sourceforge.net:uploads/
-</code>
-</p>
-
-<p>
-Update the web site by copying the docs/ directory's files to 
-/home/users/b/br/brianp/mesa-www/htdocs/ with:
-<br>
-<code>
-sftp USERNAME,mesa3d@web.sourceforge.net
-</code>
-</p>
-
-<p>
-Make an announcement on the mailing lists:
-
-<em>m</em><em>e</em><em>s</em><em>a</em><em>-</em><em>d</em><em>e</em><em>v</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>f</em><em>r</em><em>e</em><em>e</em><em>d</em><em>e</em><em>s</em><em>k</em><em>t</em><em>o</em><em>p</em><em>.</em><em>o</em><em>r</em><em>g</em>,
-<em>m</em><em>e</em><em>s</em><em>a</em><em>-</em><em>u</em><em>s</em><em>e</em><em>r</em><em>s</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>f</em><em>r</em><em>e</em><em>e</em><em>d</em><em>e</em><em>s</em><em>k</em><em>t</em><em>o</em><em>p</em><em>.</em><em>o</em><em>r</em><em>g</em>
-and
-<em>m</em><em>e</em><em>s</em><em>a</em><em>-</em><em>a</em><em>n</em><em>n</em><em>o</em><em>u</em><em>n</em><em>c</em><em>e</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>f</em><em>r</em><em>e</em><em>e</em><em>d</em><em>e</em><em>s</em><em>k</em><em>t</em><em>o</em><em>p</em><em>.</em><em>o</em><em>r</em><em>g</em>
-</p>
-
-</body>
-</html>

docs/dispatch.html

@@ -1,270 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>GL Dispatch in Mesa</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-<h1>GL Dispatch in Mesa</h1>
-
-<p>Several factors combine to make efficient dispatch of OpenGL functions
-fairly complicated.  This document attempts to explain some of the issues
-and introduce the reader to Mesa's implementation.  Readers already familiar
-with the issues around GL dispatch can safely skip ahead to the <a
-href="#overview">overview of Mesa's implementation</a>.</p>
-
-<h2>1. Complexity of GL Dispatch</h2>
-
-<p>Every GL application has at least one object called a GL <em>context</em>.
-This object, which is an implicit parameter to ever GL function, stores all
-of the GL related state for the application.  Every texture, every buffer
-object, every enable, and much, much more is stored in the context.  Since
-an application can have more than one context, the context to be used is
-selected by a window-system dependent function such as
-<tt>glXMakeContextCurrent</tt>.</p>
-
-<p>In environments that implement OpenGL with X-Windows using GLX, every GL
-function, including the pointers returned by <tt>glXGetProcAddress</tt>, are
-<em>context independent</em>.  This means that no matter what context is
-currently active, the same <tt>glVertex3fv</tt> function is used.</p>
-
-<p>This creates the first bit of dispatch complexity.  An application can
-have two GL contexts.  One context is a direct rendering context where
-function calls are routed directly to a driver loaded within the
-application's address space.  The other context is an indirect rendering
-context where function calls are converted to GLX protocol and sent to a
-server.  The same <tt>glVertex3fv</tt> has to do the right thing depending
-on which context is current.</p>
-
-<p>Highly optimized drivers or GLX protocol implementations may want to
-change the behavior of GL functions depending on current state.  For
-example, <tt>glFogCoordf</tt> may operate differently depending on whether
-or not fog is enabled.</p>
-
-<p>In multi-threaded environments, it is possible for each thread to have a
-differnt GL context current.  This means that poor old <tt>glVertex3fv</tt>
-has to know which GL context is current in the thread where it is being
-called.</p>
-
-<h2 id="overview">2. Overview of Mesa's Implementation</h2>
-
-<p>Mesa uses two per-thread pointers.  The first pointer stores the address
-of the context current in the thread, and the second pointer stores the
-address of the <em>dispatch table</em> associated with that context.  The
-dispatch table stores pointers to functions that actually implement
-specific GL functions.  Each time a new context is made current in a thread,
-these pointers a updated.</p>
-
-<p>The implementation of functions such as <tt>glVertex3fv</tt> becomes
-conceptually simple:</p>
-
-<ul>
-<li>Fetch the current dispatch table pointer.</li>
-<li>Fetch the pointer to the real <tt>glVertex3fv</tt> function from the
-table.</li>
-<li>Call the real function.</li>
-</ul>
-
-<p>This can be implemented in just a few lines of C code.  The file
-<tt>src/mesa/glapi/glapitemp.h</tt> contains code very similar to this.</p>
-
-<blockquote>
-<table border="1">
-<tr><td><pre>
-void glVertex3f(GLfloat x, GLfloat y, GLfloat z)
-{
-    const struct _glapi_table * const dispatch = GET_DISPATCH();
-
-    (*dispatch-&gt;Vertex3f)(x, y, z);
-}</pre></td></tr>
-<tr><td>Sample dispatch function</td></tr></table>
-</blockquote>
-
-<p>The problem with this simple implementation is the large amount of
-overhead that it adds to every GL function call.</p>
-
-<p>In a multithreaded environment, a naive implementation of
-<tt>GET_DISPATCH</tt> involves a call to <tt>pthread_getspecific</tt> or a
-similar function.  Mesa provides a wrapper function called
-<tt>_glapi_get_dispatch</tt> that is used by default.</p>
-
-<h2>3. Optimizations</h2>
-
-<p>A number of optimizations have been made over the years to diminish the
-performance hit imposed by GL dispatch.  This section describes these
-optimizations.  The benefits of each optimization and the situations where
-each can or cannot be used are listed.</p>
-
-<h3>3.1. Dual dispatch table pointers</h3>
-
-<p>The vast majority of OpenGL applications use the API in a single threaded
-manner.  That is, the application has only one thread that makes calls into
-the GL.  In these cases, not only do the calls to
-<tt>pthread_getspecific</tt> hurt performance, but they are completely
-unnecessary!  It is possible to detect this common case and avoid these
-calls.</p>
-
-<p>Each time a new dispatch table is set, Mesa examines and records the ID
-of the executing thread.  If the same thread ID is always seen, Mesa knows
-that the application is, from OpenGL's point of view, single threaded.</p>
-
-<p>As long as an application is single threaded, Mesa stores a pointer to
-the dispatch table in a global variable called <tt>_glapi_Dispatch</tt>.
-The pointer is also stored in a per-thread location via
-<tt>pthread_setspecific</tt>.  When Mesa detects that an application has
-become multithreaded, <tt>NULL</tt> is stored in <tt>_glapi_Dispatch</tt>.</p>
-
-<p>Using this simple mechanism the dispatch functions can detect the
-multithreaded case by comparing <tt>_glapi_Dispatch</tt> to <tt>NULL</tt>.
-The resulting implementation of <tt>GET_DISPATCH</tt> is slightly more
-complex, but it avoids the expensive <tt>pthread_getspecific</tt> call in
-the common case.</p>
-
-<blockquote>
-<table border="1">
-<tr><td><pre>
-#define GET_DISPATCH() \
-    (_glapi_Dispatch != NULL) \
-        ? _glapi_Dispatch : pthread_getspecific(&_glapi_Dispatch_key)
-</pre></td></tr>
-<tr><td>Improved <tt>GET_DISPATCH</tt> Implementation</td></tr></table>
-</blockquote>
-
-<h3>3.2. ELF TLS</h3>
-
-<p>Starting with the 2.4.20 Linux kernel, each thread is allocated an area
-of per-thread, global storage.  Variables can be put in this area using some
-extensions to GCC.  By storing the dispatch table pointer in this area, the
-expensive call to <tt>pthread_getspecific</tt> and the test of
-<tt>_glapi_Dispatch</tt> can be avoided.</p>
-
-<p>The dispatch table pointer is stored in a new variable called
-<tt>_glapi_tls_Dispatch</tt>.  A new variable name is used so that a single
-libGL can implement both interfaces.  This allows the libGL to operate with
-direct rendering drivers that use either interface.  Once the pointer is
-properly declared, <tt>GET_DISPACH</tt> becomes a simple variable
-reference.</p>
-
-<blockquote>
-<table border="1">
-<tr><td><pre>
-extern __thread struct _glapi_table *_glapi_tls_Dispatch
-    __attribute__((tls_model("initial-exec")));
-
-#define GET_DISPATCH() _glapi_tls_Dispatch
-</pre></td></tr>
-<tr><td>TLS <tt>GET_DISPATCH</tt> Implementation</td></tr></table>
-</blockquote>
-
-<p>Use of this path is controlled by the preprocessor define
-<tt>GLX_USE_TLS</tt>.  Any platform capable of using TLS should use this as
-the default dispatch method.</p>
-
-<h3>3.3. Assembly Language Dispatch Stubs</h3>
-
-<p>Many platforms has difficulty properly optimizing the tail-call in the
-dispatch stubs.  Platforms like x86 that pass parameters on the stack seem
-to have even more difficulty optimizing these routines.  All of the dispatch
-routines are very short, and it is trivial to create optimal assembly
-language versions.  The amount of optimization provided by using assembly
-stubs varies from platform to platform and application to application.
-However, by using the assembly stubs, many platforms can use an additional
-space optimization (see <a href="#fixedsize">below</a>).</p>
-
-<p>The biggest hurdle to creating assembly stubs is handling the various
-ways that the dispatch table pointer can be accessed.  There are four
-different methods that can be used:</p>
-
-<ol>
-<li>Using <tt>_glapi_Dispatch</tt> directly in builds for non-multithreaded
-environments.</li>
-<li>Using <tt>_glapi_Dispatch</tt> and <tt>_glapi_get_dispatch</tt> in
-multithreaded environments.</li>
-<li>Using <tt>_glapi_Dispatch</tt> and <tt>pthread_getspecific</tt> in
-multithreaded environments.</li>
-<li>Using <tt>_glapi_tls_Dispatch</tt> directly in TLS enabled
-multithreaded environments.</li>
-</ol>
-
-<p>People wishing to implement assembly stubs for new platforms should focus
-on #4 if the new platform supports TLS.  Otherwise, implement #2 followed by
-#3.  Environments that do not support multithreading are uncommon and not
-terribly relevant.</p>
-
-<p>Selection of the dispatch table pointer access method is controlled by a
-few preprocessor defines.</p>
-
-<ul>
-<li>If <tt>GLX_USE_TLS</tt> is defined, method #4 is used.</li>
-<li>If <tt>PTHREADS</tt> is defined, method #3 is used.</li>
-<li>If <tt>WIN32_THREADS</tt> is defined, method #2 is used.</li>
-<li>If none of the preceeding are defined, method #1 is used.</li>
-</ul>
-
-<p>Two different techniques are used to handle the various different cases.
-On x86 and SPARC, a macro called <tt>GL_STUB</tt> is used.  In the preamble
-of the assembly source file different implementations of the macro are
-selected based on the defined preprocessor variables.  The assmebly code
-then consists of a series of invocations of the macros such as:
-
-<blockquote>
-<table border="1">
-<tr><td><pre>
-GL_STUB(Color3fv, _gloffset_Color3fv)
-</pre></td></tr>
-<tr><td>SPARC Assembly Implementation of <tt>glColor3fv</tt></td></tr></table>
-</blockquote>
-
-<p>The benefit of this technique is that changes to the calling pattern
-(i.e., addition of a new dispatch table pointer access method) require fewer
-changed lines in the assembly code.</p>
-
-<p>However, this technique can only be used on platforms where the function
-implementation does not change based on the parameters passed to the
-function.  For example, since x86 passes all parameters on the stack, no
-additional code is needed to save and restore function parameters around a
-call to <tt>pthread_getspecific</tt>.  Since x86-64 passes parameters in
-registers, varying amounts of code needs to be inserted around the call to
-<tt>pthread_getspecific</tt> to save and restore the GL function's
-parameters.</p>
-
-<p>The other technique, used by platforms like x86-64 that cannot use the
-first technique, is to insert <tt>#ifdef</tt> within the assembly
-implementation of each function.  This makes the assembly file considerably
-larger (e.g., 29,332 lines for <tt>glapi_x86-64.S</tt> versus 1,155 lines for
-<tt>glapi_x86.S</tt>) and causes simple changes to the function
-implementation to generate many lines of diffs.  Since the assmebly files
-are typically generated by scripts (see <a href="#autogen">below</a>), this
-isn't a significant problem.</p>
-
-<p>Once a new assembly file is created, it must be inserted in the build
-system.  There are two steps to this.  The file must first be added to
-<tt>src/mesa/sources</tt>.  That gets the file built and linked.  The second
-step is to add the correct <tt>#ifdef</tt> magic to
-<tt>src/mesa/glapi/glapi_dispatch.c</tt> to prevent the C version of the
-dispatch functions from being built.</p>
-
-<h3 id="fixedsize">3.4. Fixed-Length Dispatch Stubs</h3>
-
-<p>To implement <tt>glXGetProcAddress</tt>, Mesa stores a table that
-associates function names with pointers to those functions.  This table is
-stored in <tt>src/mesa/glapi/glprocs.h</tt>.  For different reasons on
-different platforms, storing all of those pointers is inefficient.  On most
-platforms, including all known platforms that support TLS, we can avoid this
-added overhead.</p>
-
-<p>If the assembly stubs are all the same size, the pointer need not be
-stored for every function.  The location of the function can instead be
-calculated by multiplying the size of the dispatch stub by the offset of the
-function in the table.  This value is then added to the address of the first
-dispatch stub.</p>
-
-<p>This path is activated by adding the correct <tt>#ifdef</tt> magic to
-<tt>src/mesa/glapi/glapi.c</tt> just before <tt>glprocs.h</tt> is
-included.</p>
-
-<h2 id="autogen">4. Automatic Generation of Dispatch Stubs</h2>
-
-</body>
-</html>

docs/download.html

@@ -1,103 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Getting Mesa</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Downloading</h1>
-
-<p>
-Primary Mesa download site:
-<a href="ftp://ftp.freedesktop.org/pub/mesa/"
-target="_parent">freedesktop.org</a> (FTP)
-</p>
-
-<p>
-When a new release is coming, release candidates (betas) may be found
-<a href="ftp://ftp.freedesktop.org/pub/mesa/beta/" target="_parent">here</a>.
-</p>
-
-
-<h1>Unpacking</h1>
-
-<p>
-Mesa releases are available in three formats: .tar.bz2, .tar.gz, and .zip
-</p>
-
-<p>
-To unpack .tar.gz files:
-</p>
-<pre>
-	tar zxf MesaLib-x.y.z.tar.gz
-</pre>
-or
-<pre>
-	gzcat MesaLib-x.y.z.tar.gz | tar xf -
-</pre>
-or
-<pre>
-	gunzip MesaLib-x.y.z.tar.gz ; tar xf MesaLib-x.y.z.tar
-</pre>
-<p>
-To unpack .tar.bz2 files:
-</p>
-<pre>
-	bunzip2 -c MesaLib-x.y.z.tar.gz | tar xf -
-</pre>
-<p>
-To unpack .zip files:
-</p>
-<pre>
-	unzip MesaLib-x.y.z.zip
-</pre>
-
-
-<h1>Contents</h1>
-
-<p>
-After unpacking you'll have these files and directories (among others):
-</p>
-<pre>
-Makefile	- top-level Makefile for most systems
-configs/	- makefile parameter files for various systems
-include/	- GL header (include) files
-bin/		- shell scripts for making shared libraries, etc
-docs/		- documentation
-src/		- source code for libraries
-src/mesa	- sources for the main Mesa library and device drivers
-src/gallium     - sources for Gallium and Gallium drivers
-src/glu		- libGLU source code
-src/glx		- sources for building libGL with full GLX and DRI support
-</pre>
-
-
-<p>
-Proceed to the <a href="install.html">compilation and installation
-instructions</a>.
-</p>
-
-
-<h1>Demos and GLUT</h1>
-
-<p>
-A package of Mark Kilgard's GLUT library is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/glut/" target="_parent">here</a>
-</p>
-
-<p>
-The Mesa demos collection is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/demos/" target="_parent">here</a>
-</p>
-
-<p>
-In the past, GLUT and the Mesa demos were released in conjunction with
-Mesa releases.  But since GLUT and the demos change infrequently, they
-were split off some time ago.
-</p>
-
-
-</body>
-</html>

docs/egl.html

@@ -1,321 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html lang="en">
-<head>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <title>Mesa EGL</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<h1>Mesa EGL</h1>
-
-<p>The current version of EGL in Mesa implements EGL 1.4.  More information
-about EGL can be found at
-<a href="http://www.khronos.org/egl/" target="_parent">
-http://www.khronos.org/egl/</a>.</p>
-
-<p>The Mesa's implementation of EGL uses a driver architecture.  The main
-library (<code>libEGL</code>) is window system neutral.  It provides the EGL
-API entry points and helper functions for use by the drivers.  Drivers are
-dynamically loaded by the main library and most of the EGL API calls are
-directly dispatched to the drivers.</p>
-
-<p>The driver in use decides the window system to support.</p>
-
-<h2>Build EGL</h2>
-
-<ol>
-<li>
-<p>Run <code>configure</code> with the desired client APIs and enable
-the driver for your hardware.  For example</p>
-
-<pre>
-  $ ./configure --enable-gles1 --enable-gles2 \
-                --with-dri-drivers=... \
-                --with-gallium-drivers=...
-</pre>
-
-<p>The main library and OpenGL is enabled by default.  The first two options
-above enables <a href="opengles.html">OpenGL ES 1.x and 2.x</a>.  The last two
-options enables the listed classic and and Gallium drivers respectively.</p>
-
-</li>
-
-<li>Build and install Mesa as usual.</li>
-</ol>
-
-<p>In the given example, it will build and install <code>libEGL</code>,
-<code>libGL</code>, <code>libGLESv1_CM</code>, <code>libGLESv2</code>, and one
-or more EGL drivers.</p>
-
-<h3>Configure Options</h3>
-
-<p>There are several options that control the build of EGL at configuration
-time</p>
-
-<ul>
-<li><code>--enable-egl</code>
-
-<p>By default, EGL is enabled.  When disabled, the main library and the drivers
-will not be built.</p>
-
-</li>
-
-<li><code>--with-egl-driver-dir</code>
-
-<p>The directory EGL drivers should be installed to.  If not specified, EGL
-drivers will be installed to <code>${libdir}/egl</code>.</p>
-
-</li>
-
-<li><code>--enable-gallium-egl</code>
-
-<p>Enable the optional <code>egl_gallium</code> driver.</p>
-
-</li>
-
-<li><code>--with-egl-platforms</code>
-
-<p>List the platforms (window systems) to support.  Its argument is a comma
-seprated string such as <code>--with-egl-platforms=x11,drm</code>.  It decides
-the platforms a driver may support.  The first listed platform is also used by
-the main library to decide the native platform: the platform the EGL native
-types such as <code>EGLNativeDisplayType</code> or
-<code>EGLNativeWindowType</code> defined for.</p>
-
-<p>The available platforms are <code>x11</code>, <code>drm</code>,
-<code>fbdev</code>, and <code>gdi</code>.  The <code>gdi</code> platform can
-only be built with SCons.  Unless for special needs, the build system should
-select the right platforms automatically.</p>
-
-</li>
-
-<li><code>--enable-gles1</code> and <code>--enable-gles2</code>
-
-<p>These options enable OpenGL ES support in OpenGL.  The result is one big
-internal library that supports multiple APIs.</p>
-
-</li>
-
-<li><code>--enable-shared-glapi</code>
-
-<p>By default, <code>libGL</code> has its own copy of <code>libglapi</code>.
-This options makes <code>libGL</code> use the shared <code>libglapi</code>.  This
-is required if applications mix OpenGL and OpenGL ES.</p>
-
-</li>
-
-<li><code>--enable-openvg</code>
-
-<p>OpenVG must be explicitly enabled by this option.</p>
-
-</li>
-
-</ul>
-
-<h2>Use EGL</h2>
-
-<h3>Demos</h3>
-
-<p>There are demos for the client APIs supported by EGL.  They can be found in
-mesa/demos repository.</p>
-
-<h3>Environment Variables</h3>
-
-<p>There are several environment variables that control the behavior of EGL at
-runtime</p>
-
-<ul>
-<li><code>EGL_DRIVERS_PATH</code>
-
-<p>By default, the main library will look for drivers in the directory where
-the drivers are installed to.  This variable specifies a list of
-colon-separated directories where the main library will look for drivers, in
-addition to the default directory.  This variable is ignored for setuid/setgid
-binaries.</p>
-
-<p>This variable is usually set to test an uninstalled build.  For example, one
-may set</p>
-
-<pre>
-  $ export LD_LIBRARY_PATH=$mesa/lib
-  $ export EGL_DRIVERS_PATH=$mesa/lib/egl
-</pre>
-
-<p>to test a build without installation</p>
-
-</li>
-
-<li><code>EGL_DRIVER</code>
-
-<p>This variable specifies a full path to or the name of an EGL driver.  It
-forces the specified EGL driver to be loaded.  It comes in handy when one wants
-to test a specific driver.  This variable is ignored for setuid/setgid
-binaries.</p>
-
-</li>
-
-<li><code>EGL_PLATFORM</code>
-
-<p>This variable specifies the native platform.  The valid values are the same
-as those for <code>--with-egl-platforms</code>.  When the variable is not set,
-the main library uses the first platform listed in
-<code>--with-egl-platforms</code> as the native platform.</p>
-
-<p>Extensions like <code>EGL_MESA_drm_display</code> define new functions to
-create displays for non-native platforms.  These extensions are usually used by
-applications that support non-native platforms.  Setting this variable is
-probably required only for some of the demos found in mesa/demo repository.</p>
-
-</li>
-
-<li><code>EGL_LOG_LEVEL</code>
-
-<p>This changes the log level of the main library and the drivers.  The valid
-values are: <code>debug</code>, <code>info</code>, <code>warning</code>, and
-<code>fatal</code>.</p>
-
-</li>
-
-<li><code>EGL_SOFTWARE</code>
-
-<p>For drivers that support both hardware and software rendering, setting this
-variable to true forces the use of software rendering.</p>
-
-</li>
-</ul>
-
-<h2>EGL Drivers</h2>
-
-<ul>
-<li><code>egl_dri2</code>
-
-<p>This driver supports both <code>x11</code> and <code>drm</code> platforms.
-It functions as a DRI driver loader.  For <code>x11</code> support, it talks to
-the X server directly using (XCB-)DRI2 protocol.</p>
-
-<p>This driver can share DRI drivers with <code>libGL</code>.</p>
-
-</li>
-
-<li><code>egl_gallium</code>
-
-<p>This driver is based on Gallium3D.  It supports all rendering APIs and
-hardwares supported by Gallium3D.  It is the only driver that supports OpenVG.
-The supported platforms are X11, DRM, FBDEV, and GDI.</p>
-
-<p>This driver comes with its own hardware drivers
-(<code>pipe_&lt;hw&gt;</code>) and client API modules
-(<code>st_&lt;api&gt;</code>).</p>
-
-</li>
-
-<li><code>egl_glx</code>
-
-<p>This driver provides a wrapper to GLX.  It uses exclusively GLX to implement
-the EGL API.  It supports both direct and indirect rendering when the GLX does.
-It is accelerated when the GLX is.  As such, it cannot provide functions that
-is not available in GLX or GLX extensions.</p>
-</li>
-</ul>
-
-<h2>Packaging</h2>
-
-<p>The ABI between the main library and its drivers are not stable.  Nor is
-there a plan to stabilize it at the moment.  Of the EGL drivers,
-<code>egl_gallium</code> has its own hardware drivers and client API modules.
-They are considered internal to <code>egl_gallium</code> and there is also no
-stable ABI between them.  These should be kept in mind when packaging for
-distribution.</p>
-
-<p>Generally, <code>egl_dri2</code> is preferred over <code>egl_gallium</code>
-when the system already has DRI drivers.  As <code>egl_gallium</code> is loaded
-before <code>egl_dri2</code> when both are available, <code>egl_gallium</code>
-is disabled by default.</p>
-
-<h2>Developers</h2>
-
-<p>The sources of the main library and the classic drivers can be found at
-<code>src/egl/</code>.  The sources of the <code>egl</code> state tracker can
-be found at <code>src/gallium/state_trackers/egl/</code>.</p>
-
-<p>The suggested way to learn to write a EGL driver is to see how other drivers
-are written.  <code>egl_glx</code> should be a good reference.  It works in any
-environment that has GLX support, and it is simpler than most drivers.</p>
-
-<h3>Lifetime of Display Resources</h3>
-
-<p>Contexts and surfaces are examples of display resources.  They might live
-longer than the display that creates them.</p>
-
-<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all
-display resources should be destroyed.  Similarly, when a thread is released
-throught <code>eglReleaseThread</code>, all current display resources should be
-released.  Another way to destory or release resources is through functions
-such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p>
-
-<p>When a resource that is current to some thread is destroyed, the resource
-should not be destroyed immediately.  EGL requires the resource to live until
-it is no longer current.  A driver usually calls
-<code>eglIs&lt;Resource&gt;Bound</code> to check if a resource is bound
-(current) to any thread in the destroy callbacks.  If it is still bound, the
-resource is not destroyed.</p>
-
-<p>The main library will mark destroyed current resources as unlinked.  In a
-driver's <code>MakeCurrent</code> callback,
-<code>eglIs&lt;Resource&gt;Linked</code> can then be called to check if a newly
-released resource is linked to a display.  If it is not, the last reference to
-the resource is removed and the driver should destroy the resource.  But it
-should be careful here because <code>MakeCurrent</code> might be called with an
-uninitialized display.</p>
-
-<p>This is the only mechanism provided by the main library to help manage the
-resources.  The drivers are responsible to the correct behavior as defined by
-EGL.</p>
-
-<h3><code>EGL_RENDER_BUFFER</code></h3>
-
-<p>In EGL, the color buffer a context should try to render to is decided by the
-binding surface.  It should try to render to the front buffer if the binding
-surface has <code>EGL_RENDER_BUFFER</code> set to
-<code>EGL_SINGLE_BUFFER</code>;  If the same context is later bound to a
-surface with <code>EGL_RENDER_BUFFER</code> set to
-<code>EGL_BACK_BUFFER</code>, the context should try to render to the back
-buffer.  However, the context is allowed to make the final decision as to which
-color buffer it wants to or is able to render to.</p>
-
-<p>For pbuffer surfaces, the render buffer is always
-<code>EGL_BACK_BUFFER</code>.  And for pixmap surfaces, the render buffer is
-always <code>EGL_SINGLE_BUFFER</code>.  Unlike window surfaces, EGL spec
-requires their <code>EGL_RENDER_BUFFER</code> values to be honored.  As a
-result, a driver should never set <code>EGL_PIXMAP_BIT</code> or
-<code>EGL_PBUFFER_BIT</code> bits of a config if the contexts created with the
-config won't be able to honor the <code>EGL_RENDER_BUFFER</code> of pixmap or
-pbuffer surfaces.</p>
-
-<p>It should also be noted that pixmap and pbuffer surfaces are assumed to be
-single-buffered, in that <code>eglSwapBuffers</code> has no effect on them.  It
-is desirable that a driver allocates a private color buffer for each pbuffer
-surface created.  If the window system the driver supports has native pbuffers,
-or if the native pixmaps have more than one color buffers, the driver should
-carefully attach the native color buffers to the EGL surfaces, re-route them if
-required.</p>
-
-<p>There is no defined behavior as to, for example, how
-<code>glDrawBuffer</code> interacts with <code>EGL_RENDER_BUFFER</code>.  Right
-now, it is desired that the draw buffer in a client API be fixed for pixmap and
-pbuffer surfaces.  Therefore, the driver is responsible to guarantee that the
-client API renders to the specified render buffer for pixmap and pbuffer
-surfaces.</p>
-
-<h3><code>EGLDisplay</code> Mutex</h3>
-
-The <code>EGLDisplay</code> will be locked before calling any of the dispatch
-functions (well, except for GetProcAddress which does not take an
-<code>EGLDisplay</code>).  This guarantees that the same dispatch function will
-not be called with the sample display at the same time.  If a driver has access
-to an <code>EGLDisplay</code> without going through the EGL APIs, the driver
-should as well lock the display before using it.
-
-</body>
-</html>

docs/enums.txt

@@ -1,57 +0,0 @@
-
-See the OpenGL ARB enum registry at http://www.opengl.org/registry/api/enum.spec
-
-Blocks allocated to Mesa:
-       0x8750-0x875F
-       0x8BB0-0x8BBF
-
-
-GL_MESA_packed_depth_stencil
-	GL_DEPTH_STENCIL_MESA            0x8750
-	GL_UNSIGNED_INT_24_8_MESA        0x8751
-	GL_UNSIGNED_INT_8_24_REV_MESA    0x8752
-	GL_UNSIGNED_SHORT_15_1_MESA      0x8753
-	GL_UNSIGNED_SHORT_1_15_REV_MESA  0x8754
-
-GL_MESA_trace.spec:
-	GL_TRACE_ALL_BITS_MESA           0xFFFF
-	GL_TRACE_OPERATIONS_BIT_MESA     0x0001
-	GL_TRACE_PRIMITIVES_BIT_MESA     0x0002
-	GL_TRACE_ARRAYS_BIT_MESA         0x0004
-	GL_TRACE_TEXTURES_BIT_MESA       0x0008
-	GL_TRACE_PIXELS_BIT_MESA         0x0010
-	GL_TRACE_ERRORS_BIT_MESA         0x0020
-	GL_TRACE_MASK_MESA               0x8755
-	GL_TRACE_NAME_MESA               0x8756
-
-MESA_ycbcr_texture.spec:
-	GL_YCBCR_MESA                    0x8757
-	GL_UNSIGNED_SHORT_8_8_MESA       0x85BA /* same as Apple's */
-	GL_UNSIGNED_SHORT_8_8_REV_MESA   0x85BB /* same as Apple's */
-
-GL_MESA_pack_invert.spec
-	GL_PACK_INVERT_MESA              0x8758
-
-GL_MESA_shader_debug.spec: (obsolete)
-        GL_DEBUG_OBJECT_MESA             0x8759
-        GL_DEBUG_PRINT_MESA              0x875A
-        GL_DEBUG_ASSERT_MESA             0x875B
-
-GL_MESA_program_debug.spec: (obsolete)
-	GL_FRAGMENT_PROGRAM_CALLBACK_MESA      0x????
-	GL_VERTEX_PROGRAM_CALLBACK_MESA        0x????
-	GL_FRAGMENT_PROGRAM_POSITION_MESA      0x????
-	GL_VERTEX_PROGRAM_POSITION_MESA        0x????
-	GL_FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x????
-	GL_FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x????
-	GL_VERTEX_PROGRAM_CALLBACK_FUNC_MESA   0x????
-	GL_VERTEX_PROGRAM_CALLBACK_DATA_MESA   0x????
-
-GL_MESAX_texture_stack:
-	GL_TEXTURE_1D_STACK_MESAX            0x8759
-	GL_TEXTURE_2D_STACK_MESAX            0x875A
-	GL_PROXY_TEXTURE_1D_STACK_MESAX      0x875B
-	GL_PROXY_TEXTURE_2D_STACK_MESAX      0x875C
-	GL_TEXTURE_1D_STACK_BINDING_MESAX    0x875D
-	GL_TEXTURE_2D_STACK_BINDING_MESAX    0x875E
-