patches from Karl

.dir-locals.el

@@ -1,11 +0,0 @@
-((nil
-  (indent-tabs-mode . nil)
-  (tab-width . 8)
-  (c-basic-offset . 3)
-  (c-file-style . "stroustrup")
-  (fill-column . 78)
-  (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,46 +0,0 @@
-*.a
-*.dll
-*.exe
-*.ilk
-*.la
-*.lo
-*.log
-*.o
-*.obj
-*.os
-*.pc
-*.pdb
-*.pyc
-*.pyo
-*.so
-*.so.*
-*.sw[a-z]
-*.tar
-*.tar.bz2
-*.tar.gz
-*.trs
-*.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
-.dir-locals.el
-.deps/
-.dirstamp
-.libs/
-Makefile
-Makefile.in

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)
-LOCAL_CFLAGS += \
-	-DANDROID_VERSION=0x0$(MESA_ANDROID_MAJOR_VERSION)0$(MESA_ANDROID_MINOR_VERSION)
-
-LOCAL_CFLAGS += \
-	-DHAVE_PTHREAD=1 \
-	-fvisibility=hidden \
-	-Wno-sign-compare
-
-ifeq ($(strip $(MESA_ENABLE_ASM)),true)
-ifeq ($(TARGET_ARCH),x86)
-LOCAL_CFLAGS += \
-	-DUSE_X86_ASM \
-	-DHAVE_DLOPEN \
-
-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,99 +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_ANDROID_MAJOR_VERSION := $(word 1, $(subst ., , $(PLATFORM_VERSION)))
-MESA_ANDROID_MINOR_VERSION := $(word 2, $(subst ., , $(PLATFORM_VERSION)))
-MESA_ANDROID_VERSION := $(MESA_ANDROID_MAJOR_VERSION).$(MESA_ANDROID_MINOR_VERSION)
-
-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,765 @@
+# $Id: Makefile.X11,v 1.69 2002/11/13 15:33:51 brianp Exp $
+
+# Mesa 3-D graphics library
+# Version:  5.0
+# 
+# Copyright (C) 1999-2002  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 darwin               for Darwin - Mac OS X"
+	@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 and 11.x"
+	@echo "  make hpux10-sl            for HP systems with HPUX 10.x and 11.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 shared .so libs"
+	@echo "  make linux-static         for Linux systems, make static .a libs"
+	@echo "  make linux-trace          for Linux systems, with API trace extension"
+	@echo "  make linux-x86            for Linux on Intel, make shared .so libs"
+	@echo "  make linux-x86-static     for Linux on Intel, make static .a 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-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-x86-glide      for Linux w/ all x86 asm for Glide"
+	@echo "  make linux-alpha          for Linux on Alpha systems"
+	@echo "  make linux-alpha-static   for Linux on Alpha systems, static libs"
+	@echo "  make linux-ppc            for Linux on PowerPC systems"
+	@echo "  make linux-ppc-static     for Linux on PowerPC systems, static libs"
+	@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 linux-osmesa16       for 16-bit/channel OSMesa"
+	@echo "  make linux-osmesa32       for 32-bit/channel OSMesa"
+	@echo "  make linux-icc            for Linux with the Intel C/C++ compiler"
+	@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 sco5                 for SCO 5.0.5 OpenServer Unix"
+	@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"
+
+
+
+# XXX we may have to split up this group of targets into those that
+# have a C++ compiler and those that don't for the SI-GLU library.
+
+aix aix-sl amix bsdos bsdos4 darwin dgux freebsd freebsd-386 gcc \
+hpux9 hpux9-sl hpux9-gcc hpux9-gcc-sl \
+hpux10 hpux10-sl hpux10-gcc hpux10-gcc-sl \
+irix4 irix5 irix5-gcc irix5-dso \
+linux linux-static linux-debug linux-static-debug linux-prof \
+linux-x86 linux-icc linux-x86-static linux-x86-debug \
+linux-glide linux-386-glide linux-386-opt-glide \
+linux-x86-glide linux-glide-debug linux-glide-prof \
+linux-alpha-static linux-alpha \
+linux-ppc-static linux-ppc \
+linux-sparc \
+linux-sparc5-elf \
+linux-sparc-ultra \
+lynxos machten-2.2 machten-4.0 \
+mklinux netbsd osf1 osf1-sl openbsd qnx sco sco5 \
+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
+	if [ -d src      ] ; then touch src/depend      ; fi
+	if [ -d si-glu   ] ; then touch si-glu/depend  ; fi
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
+	if [ -d src      ] ; then cd src      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d si-glu   ] ; then cd si-glu   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	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
+	if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
+
+irix6-o32 irix6-o32-dso irix6-n32 irix6-n32-dso irix6-gcc-n32-sl irix-debug:
+	-mkdir lib32
+	if [ -d src      ] ; then touch src/depend      ; fi
+	if [ -d src-glu  ] ; then touch src-glu/depend  ; fi
+	if [ -d src-glut ] ; then touch src-glut/depend ; fi
+	if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
+	if [ -d src      ] ; then cd src      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src-glu  ] ; then cd src-glu  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	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
+	if [ -d widgets-sgi ] ; then cd widgets-sgi; $(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
+	if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
+	if [ -d src      ] ; then cd src      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src-glu  ] ; then cd src-glu  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	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
+	if [ -d widgets-sgi ] ; then cd widgets-sgi; $(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
+	if [ -d src     ] ; then cd src     ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src-glu ] ; then cd src-glu ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	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
+	if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
+	if [ -d src      ] ; then cd src      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src-glu  ] ; then cd src-glu  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	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 widgets-sgi ] ; then cd widgets-sgi; $(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 si-glu/depend
+	if [ -d src-glut        ] ; then touch src-glut/depend ; fi
+	if [ -d widgets-sgi     ] ; then touch widgets-sgi/depend ; fi
+	if [ -d ggi             ] ; then touch ggi/depend      ; fi
+	if [ -d src             ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/GGI/default ] ; then cd src/GGI/default ; $(MAKE)      ; fi
+	if [ -d src/GGI/display ] ; then cd src/GGI/display ; $(MAKE)      ; fi
+	if [ -d si-glu ]   ; then cd si-glu   ; $(MAKE) -f Makefile.X11 $@ ; fi
+#	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 [ -d widgets-sgi ] ; then cd widgets-sgi; $(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
+
+linux-osmesa16 linux-osmesa32:
+	-mkdir lib
+	if [ -d src ] ; then touch src/depend ; fi
+	if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.OSMesa16 $@ ; 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 si-glu/*/*.o si-glu/*/*/*.o
+	-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
+	-rm -f widgets-sgi/*.o
+	-rm -f widgets-mesa/*/*.o
+
+# Remove everything that can be remade
+realclean: clean
+	-rm -fr lib lib32 lib64
+	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
+
+
+DIRECTORY = Mesa-5.0
+LIB_NAME = MesaLib-5.0
+DEMO_NAME = MesaDemos-5.0
+GLU_NAME = MesaGLU-5.0
+GLUT_NAME = GLUT-3.7
+
+
+LIB_FILES =	\
+	$(DIRECTORY)/Makefile*						\
+	$(DIRECTORY)/Make-config					\
+	$(DIRECTORY)/acconfig.h						\
+	$(DIRECTORY)/acinclude.m4					\
+	$(DIRECTORY)/aclocal.m4						\
+	$(DIRECTORY)/common_rules.make					\
+	$(DIRECTORY)/conf.h.in						\
+	$(DIRECTORY)/config.guess					\
+	$(DIRECTORY)/config.sub						\
+	$(DIRECTORY)/configure						\
+	$(DIRECTORY)/configure.in					\
+	$(DIRECTORY)/install-sh						\
+	$(DIRECTORY)/ltmain.sh						\
+	$(DIRECTORY)/missing						\
+	$(DIRECTORY)/mkinstalldirs					\
+	$(DIRECTORY)/stamp-h.in						\
+	$(DIRECTORY)/docs/CONFORM					\
+	$(DIRECTORY)/docs/COPYING					\
+	$(DIRECTORY)/docs/COPYRIGHT					\
+	$(DIRECTORY)/docs/DEVINFO					\
+	$(DIRECTORY)/docs/INSTALL					\
+	$(DIRECTORY)/docs/INSTALL.GNU					\
+	$(DIRECTORY)/docs/README					\
+	$(DIRECTORY)/docs/README.*					\
+	$(DIRECTORY)/docs/RELNOTES*					\
+	$(DIRECTORY)/docs/VERSIONS					\
+	$(DIRECTORY)/docs/*.spec					\
+	$(DIRECTORY)/bin/README						\
+	$(DIRECTORY)/bin/mklib*						\
+	$(DIRECTORY)/descrip.mms					\
+	$(DIRECTORY)/mms-config						\
+	$(DIRECTORY)/m4/*.m4						\
+	$(DIRECTORY)/xlib.opt						\
+	$(DIRECTORY)/mesawin32.mak					\
+	$(DIRECTORY)/include/GL/internal/glcore.h			\
+	$(DIRECTORY)/include/GL/Makefile.in				\
+	$(DIRECTORY)/include/GL/Makefile.am				\
+	$(DIRECTORY)/include/GL/dmesa.h					\
+	$(DIRECTORY)/include/GL/amesa.h					\
+	$(DIRECTORY)/include/GL/fxmesa.h				\
+	$(DIRECTORY)/include/GL/ggimesa.h				\
+	$(DIRECTORY)/include/GL/gl.h					\
+	$(DIRECTORY)/include/GL/glext.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/glxext.h				\
+	$(DIRECTORY)/include/GL/glx_mangle.h				\
+	$(DIRECTORY)/include/GL/mesa_wgl.h				\
+	$(DIRECTORY)/include/GL/mglmesa.h				\
+	$(DIRECTORY)/include/GL/osmesa.h				\
+	$(DIRECTORY)/include/GL/svgamesa.h				\
+	$(DIRECTORY)/include/GL/ugl*.h					\
+	$(DIRECTORY)/include/GL/vms_x_fix.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)/include/Makefile.in				\
+	$(DIRECTORY)/include/Makefile.am				\
+	$(DIRECTORY)/src/Makefile*					\
+	$(DIRECTORY)/src/libGL_la_SOURCES				\
+	$(DIRECTORY)/src/descrip.mms					\
+	$(DIRECTORY)/src/mesa.conf					\
+	$(DIRECTORY)/src/*.def						\
+	$(DIRECTORY)/src/depend						\
+	$(DIRECTORY)/src/*.[chS]					\
+	$(DIRECTORY)/src/array_cache/*.[ch]				\
+	$(DIRECTORY)/src/array_cache/Makefile*				\
+	$(DIRECTORY)/src/array_cache/libMesaAC_la_SOURCES		\
+	$(DIRECTORY)/src/math/*.[ch]					\
+	$(DIRECTORY)/src/math/Makefile*					\
+	$(DIRECTORY)/src/swrast/*.[ch]					\
+	$(DIRECTORY)/src/swrast/Makefile*				\
+	$(DIRECTORY)/src/swrast/libMesaSwrast_la_SOURCES		\
+	$(DIRECTORY)/src/swrast_setup/*.[ch]				\
+	$(DIRECTORY)/src/swrast_setup/Makefile*				\
+	$(DIRECTORY)/src/tnl/*.[ch]					\
+	$(DIRECTORY)/src/tnl/Makefile*					\
+	$(DIRECTORY)/src/tnl/libMesaTnl_la_SOURCES			\
+	$(DIRECTORY)/src/tnl_dd/*.[ch]					\
+	$(DIRECTORY)/src/tnl_dd/imm/*.[ch]				\
+	$(DIRECTORY)/src/tnl_dd/imm/NOTES.imm				\
+	$(DIRECTORY)/src/windml/*.[ch]					\
+	$(DIRECTORY)/src/windml/tornado/*.c				\
+	$(DIRECTORY)/src/windml/tornado/*.cdf				\
+	$(DIRECTORY)/src/windml/man3/*.3				\
+	$(DIRECTORY)/src/windml/man3/*.html				\
+	$(DIRECTORY)/src/DOS/*.[chS]					\
+	$(DIRECTORY)/src/DOS/vesa/*.[ch]				\
+	$(DIRECTORY)/src/BeOS/*.cpp					\
+	$(DIRECTORY)/src/FX/Makefile.am					\
+	$(DIRECTORY)/src/FX/Makefile.in					\
+	$(DIRECTORY)/src/FX/libMesaFX_la_SOURCES			\
+	$(DIRECTORY)/src/FX/*.[ch]					\
+	$(DIRECTORY)/src/FX/*.def					\
+	$(DIRECTORY)/src/FX/X86/Makefile.am				\
+	$(DIRECTORY)/src/FX/X86/Makefile.in				\
+	$(DIRECTORY)/src/FX/X86/*.[Shc]					\
+	$(DIRECTORY)/src/GGI/Makefile.am				\
+	$(DIRECTORY)/src/GGI/Makefile.in				\
+	$(DIRECTORY)/src/GGI/*.[ch]					\
+	$(DIRECTORY)/src/GGI/ggimesa.conf.in				\
+	$(DIRECTORY)/src/GGI/default/*.c				\
+	$(DIRECTORY)/src/GGI/default/Makefile.am			\
+	$(DIRECTORY)/src/GGI/default/Makefile.in			\
+	$(DIRECTORY)/src/GGI/default/genkgi.conf.in			\
+	$(DIRECTORY)/src/GGI/display/*.c				\
+	$(DIRECTORY)/src/GGI/display/Makefile.am			\
+	$(DIRECTORY)/src/GGI/display/Makefile.in			\
+	$(DIRECTORY)/src/GGI/display/fbdev.conf.in			\
+	$(DIRECTORY)/src/GGI/include/Makefile.am			\
+	$(DIRECTORY)/src/GGI/include/Makefile.in			\
+	$(DIRECTORY)/src/GGI/include/ggi/Makefile.am			\
+	$(DIRECTORY)/src/GGI/include/ggi/Makefile.in			\
+	$(DIRECTORY)/src/GGI/include/ggi/mesa/Makefile.am		\
+	$(DIRECTORY)/src/GGI/include/ggi/mesa/Makefile.in		\
+	$(DIRECTORY)/src/GGI/include/ggi/mesa/*.h			\
+	$(DIRECTORY)/src/KNOWN_BUGS					\
+	$(DIRECTORY)/src/OSmesa/Makefile.am				\
+	$(DIRECTORY)/src/OSmesa/Makefile.in				\
+	$(DIRECTORY)/src/OSmesa/Makefile.win				\
+	$(DIRECTORY)/src/OSmesa/osmesa.def				\
+	$(DIRECTORY)/src/OSmesa/*.[ch]					\
+	$(DIRECTORY)/src/SPARC/*.[chS]					\
+	$(DIRECTORY)/src/SPARC/Makefile.am				\
+	$(DIRECTORY)/src/SPARC/Makefile.in				\
+	$(DIRECTORY)/src/SVGA/Makefile.am				\
+	$(DIRECTORY)/src/SVGA/Makefile.in				\
+	$(DIRECTORY)/src/SVGA/*.[ch]					\
+	$(DIRECTORY)/src/Trace/*.[ch]					\
+	$(DIRECTORY)/src/Trace/Makefile.am				\
+	$(DIRECTORY)/src/Trace/Makefile.in				\
+	$(DIRECTORY)/src/Windows/*.[ch]					\
+	$(DIRECTORY)/src/Windows/*.def					\
+	$(DIRECTORY)/src/X/Makefile.am					\
+	$(DIRECTORY)/src/X/Makefile.in					\
+	$(DIRECTORY)/src/X/*.[ch]					\
+	$(DIRECTORY)/src/X86/*.[ch]					\
+	$(DIRECTORY)/src/X86/Makefile.am				\
+	$(DIRECTORY)/src/X86/Makefile.in				\
+	$(DIRECTORY)/src/X86/*.S					\
+	$(DIRECTORY)/si-glu/Makefile.am					\
+	$(DIRECTORY)/si-glu/Makefile.in					\
+	$(DIRECTORY)/si-glu/Makefile.X11				\
+	$(DIRECTORY)/si-glu/Makefile.win				\
+	$(DIRECTORY)/si-glu/glu.def					\
+	$(DIRECTORY)/si-glu/dummy.cc					\
+	$(DIRECTORY)/si-glu/descrip.mms					\
+	$(DIRECTORY)/si-glu/mesaglu.opt					\
+	$(DIRECTORY)/si-glu/include/gluos.h				\
+	$(DIRECTORY)/si-glu/include/Makefile.am				\
+	$(DIRECTORY)/si-glu/include/Makefile.in				\
+	$(DIRECTORY)/si-glu/libnurbs/Makefile.am			\
+	$(DIRECTORY)/si-glu/libnurbs/Makefile.in			\
+	$(DIRECTORY)/si-glu/libnurbs/interface/*.h			\
+	$(DIRECTORY)/si-glu/libnurbs/interface/*.cc			\
+	$(DIRECTORY)/si-glu/libnurbs/interface/libNIFac_la_SOURCES	\
+	$(DIRECTORY)/si-glu/libnurbs/interface/Makefile.am		\
+	$(DIRECTORY)/si-glu/libnurbs/interface/Makefile.in		\
+	$(DIRECTORY)/si-glu/libnurbs/internals/*.h			\
+	$(DIRECTORY)/si-glu/libnurbs/internals/*.cc			\
+	$(DIRECTORY)/si-glu/libnurbs/internals/libNInt_la_SOURCES	\
+	$(DIRECTORY)/si-glu/libnurbs/internals/Makefile.am		\
+	$(DIRECTORY)/si-glu/libnurbs/internals/Makefile.in		\
+	$(DIRECTORY)/si-glu/libnurbs/nurbtess/*.h			\
+	$(DIRECTORY)/si-glu/libnurbs/nurbtess/*.cc			\
+	$(DIRECTORY)/si-glu/libnurbs/nurbtess/libNTess_la_SOURCES	\
+	$(DIRECTORY)/si-glu/libnurbs/nurbtess/Makefile.am		\
+	$(DIRECTORY)/si-glu/libnurbs/nurbtess/Makefile.in		\
+	$(DIRECTORY)/si-glu/libtess/README				\
+	$(DIRECTORY)/si-glu/libtess/alg-outline				\
+	$(DIRECTORY)/si-glu/libtess/*.[ch]				\
+	$(DIRECTORY)/si-glu/libtess/libtess_la_SOURCES			\
+	$(DIRECTORY)/si-glu/libtess/Makefile.am				\
+	$(DIRECTORY)/si-glu/libtess/Makefile.in				\
+	$(DIRECTORY)/si-glu/libutil/*.[ch]				\
+	$(DIRECTORY)/si-glu/libutil/libutil_la_SOURCES			\
+	$(DIRECTORY)/si-glu/libutil/Makefile.am				\
+	$(DIRECTORY)/si-glu/libutil/Makefile.in				\
+	$(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/depend					\
+	$(DIRECTORY)/src-glu/*.[ch]					\
+	$(DIRECTORY)/widgets-mesa/ChangeLog				\
+	$(DIRECTORY)/widgets-mesa/INSTALL				\
+	$(DIRECTORY)/widgets-mesa/Makefile.in				\
+	$(DIRECTORY)/widgets-mesa/README				\
+	$(DIRECTORY)/widgets-mesa/TODO					\
+	$(DIRECTORY)/widgets-mesa/configure				\
+	$(DIRECTORY)/widgets-mesa/configure.in				\
+	$(DIRECTORY)/widgets-mesa/demos/ChangeLog			\
+	$(DIRECTORY)/widgets-mesa/demos/Cube				\
+	$(DIRECTORY)/widgets-mesa/demos/Ed				\
+	$(DIRECTORY)/widgets-mesa/demos/Makefile.in			\
+	$(DIRECTORY)/widgets-mesa/demos/Mcube				\
+	$(DIRECTORY)/widgets-mesa/demos/Tea				\
+	$(DIRECTORY)/widgets-mesa/demos/*.[ch]				\
+	$(DIRECTORY)/widgets-mesa/demos/events				\
+	$(DIRECTORY)/widgets-mesa/include/GL/ChangeLog			\
+	$(DIRECTORY)/widgets-mesa/include/GL/*.h			\
+	$(DIRECTORY)/widgets-mesa/include/GL/Makefile.in		\
+	$(DIRECTORY)/widgets-mesa/man/ChangeLog				\
+	$(DIRECTORY)/widgets-mesa/man/GL*				\
+	$(DIRECTORY)/widgets-mesa/man/Makefile.in			\
+	$(DIRECTORY)/widgets-mesa/man/Mesa*				\
+	$(DIRECTORY)/widgets-mesa/src/ChangeLog				\
+	$(DIRECTORY)/widgets-mesa/src/*.c				\
+	$(DIRECTORY)/widgets-mesa/src/Makefile.in			\
+	$(DIRECTORY)/widgets-sgi/*.[ch]					\
+	$(DIRECTORY)/widgets-sgi/Makefile*				\
+	$(DIRECTORY)/widgets-sgi/README					\
+	$(DIRECTORY)/util/README					\
+	$(DIRECTORY)/util/Makefile.am					\
+	$(DIRECTORY)/util/Makefile.in					\
+	$(DIRECTORY)/util/*.[ch]					\
+	$(DIRECTORY)/util/sampleMakefile				\
+	$(DIRECTORY)/vms/analyze_map.com				\
+	$(DIRECTORY)/vms/xlib.opt					\
+	$(DIRECTORY)/vms/xlib_share.opt					\
+	$(DIRECTORY)/BeOS/Makefile					\
+	$(DIRECTORY)/BeOS/*.cpp
+
+OBSOLETE_LIB_FILES = \
+	$(DIRECTORY)/src/Allegro/*.[ch]					\
+	$(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/S3/*.[ch]					\
+	$(DIRECTORY)/src/S3/*.def					\
+	$(DIRECTORY)/src/S3/*.mak					\
+	$(DIRECTORY)/src/S3/*.rc					\
+	$(DIRECTORY)/macos/README					\
+	$(DIRECTORY)/macos/gli_api/*.h					\
+	$(DIRECTORY)/macos/cglpane/CGLPane.*				\
+	$(DIRECTORY)/macos/include-mac/*.h				\
+	$(DIRECTORY)/macos/libraries/*.stub				\
+	$(DIRECTORY)/macos/libraries/*Stub				\
+	$(DIRECTORY)/macos/projects/*.mcp				\
+	$(DIRECTORY)/macos/projects/*.exp				\
+	$(DIRECTORY)/macos/projects/*.h					\
+	$(DIRECTORY)/macos/resources/*.c				\
+	$(DIRECTORY)/macos/resources/*.r				\
+	$(DIRECTORY)/macos/resources/*.rsrc				\
+	$(DIRECTORY)/macos/src-agl/*.exp				\
+	$(DIRECTORY)/macos/src-agl/*.[ch]				\
+	$(DIRECTORY)/macos/src-gli/*.[ch]				\
+	$(DIRECTORY)/OpenStep
+
+
+
+DEMO_FILES =	\
+	$(DIRECTORY)/include/GL/glut.h		\
+	$(DIRECTORY)/include/GL/glutf90.h	\
+	$(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.dos/*.[ch]	\
+	$(DIRECTORY)/src-glut.dos/Makefile.DJ	\
+	$(DIRECTORY)/src-glut.dos/PC_HW/*.[chS]	\
+	$(DIRECTORY)/images/*			\
+	$(DIRECTORY)/demos/Makefile*		\
+	$(DIRECTORY)/demos/descrip.mms		\
+	$(DIRECTORY)/demos/*.[ch]		\
+	$(DIRECTORY)/demos/*.cxx		\
+	$(DIRECTORY)/demos/*.dat		\
+	$(DIRECTORY)/demos/README		\
+	$(DIRECTORY)/xdemos/Makefile*		\
+	$(DIRECTORY)/xdemos/descrip.mms		\
+	$(DIRECTORY)/xdemos/*.[chf]		\
+	$(DIRECTORY)/book/Makefile*		\
+	$(DIRECTORY)/book/README		\
+	$(DIRECTORY)/book/*.[ch]		\
+	$(DIRECTORY)/samples/Makefile*		\
+	$(DIRECTORY)/samples/README		\
+	$(DIRECTORY)/samples/*.c		\
+	$(DIRECTORY)/mtdemos			\
+	$(DIRECTORY)/windmldemos/Makefile.ugl	\
+	$(DIRECTORY)/windmldemos/*.c		\
+	$(DIRECTORY)/windmldemos/*.bmp		\
+	$(DIRECTORY)/ggi
+
+OBSOLETE_DEMO_FILES = \
+	$(DIRECTORY)/include/GL/glut_h.dja	\
+	$(DIRECTORY)/src-glut.dja/*		\
+	$(DIRECTORY)/src-glut.beos/Makefile	\
+	$(DIRECTORY)/src-glut.beos/*.cpp	\
+	$(DIRECTORY)/src-glut.beos/*.h		\
+
+
+SI_GLU_FILES = \
+	$(DIRECTORY)/Makefile*				\
+	$(DIRECTORY)/Make-config			\
+	$(DIRECTORY)/bin/mklib*				\
+	$(DIRECTORY)/include/GL/glu.h			\
+	$(DIRECTORY)/si-glu/Makefile.X11		\
+	$(DIRECTORY)/si-glu/include/gluos.h		\
+	$(DIRECTORY)/si-glu/libnurbs/interface/*.h	\
+	$(DIRECTORY)/si-glu/libnurbs/interface/*.cc	\
+	$(DIRECTORY)/si-glu/libnurbs/internals/*.h	\
+	$(DIRECTORY)/si-glu/libnurbs/internals/*.cc	\
+	$(DIRECTORY)/si-glu/libnurbs/nurbstess/*.h	\
+	$(DIRECTORY)/si-glu/libnurbs/nurbstess/*.cc	\
+	$(DIRECTORY)/si-glu/libtess/README		\
+	$(DIRECTORY)/si-glu/libtess/alg-outline		\
+	$(DIRECTORY)/si-glu/libtess/*.[ch]		\
+	$(DIRECTORY)/si-glu/libutil/*.[ch]
+
+GLU_FILES = \
+	$(DIRECTORY)/Makefile*			\
+	$(DIRECTORY)/Make-config		\
+	$(DIRECTORY)/bin/mklib*			\
+	$(DIRECTORY)/include/GL/gl.h		\
+	$(DIRECTORY)/include/GL/gl_mangle.h	\
+	$(DIRECTORY)/include/GL/glext.h		\
+	$(DIRECTORY)/include/GL/glu.h		\
+	$(DIRECTORY)/include/GL/glu_mangle.h	\
+	$(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/depend		\
+	$(DIRECTORY)/src-glu/*.[ch]
+
+GLUT_FILES = \
+	$(DIRECTORY)/Makefile*			\
+	$(DIRECTORY)/Make-config		\
+	$(DIRECTORY)/bin/mklib*			\
+	$(DIRECTORY)/include/GL/gl.h		\
+	$(DIRECTORY)/include/GL/gl_mangle.h	\
+	$(DIRECTORY)/include/GL/glext.h		\
+	$(DIRECTORY)/include/GL/glu.h		\
+	$(DIRECTORY)/include/GL/glu_mangle.h	\
+	$(DIRECTORY)/include/GL/glut.h		\
+	$(DIRECTORY)/include/GL/glutf90.h	\
+	$(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]
+
+
+OBSOLETE_GLUT_FILES = \
+	$(DIRECTORY)/include/GL/glut_h.dja	\
+	$(DIRECTORY)/src-glut.dja/*		\
+	$(DIRECTORY)/src-glut.beos/Makefile	\
+	$(DIRECTORY)/src-glut.beos/*.cpp	\
+	$(DIRECTORY)/src-glut.beos/*.h
+
+
+lib_tar:
+	cp Makefile.X11 Makefile ; \
+	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)
+
+glu_tar:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLU_NAME).tar $(GLU_FILES) ; \
+	gzip $(GLU_NAME).tar ; \
+	mv $(GLU_NAME).tar.gz $(DIRECTORY)
+
+glut_tar:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLUT_NAME).tar $(GLUT_FILES) ; \
+	gzip $(GLUT_NAME).tar ; \
+	mv $(GLUT_NAME).tar.gz $(DIRECTORY)
+
+
+lib_zip:
+	-rm $(LIB_NAME).zip ; \
+	cp Makefile.X11 Makefile ; \
+	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,118 +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
-
-ACLOCAL_AMFLAGS = -I m4
-
-doxygen:
-	cd doxygen && $(MAKE)
-
-check-local:
-	$(MAKE) -C src/mapi/glapi/tests check
-	$(MAKE) -C src/mapi/shared-glapi/tests check
-	$(MAKE) -C src/mesa/main/tests check
-	$(MAKE) -C src/glx/tests check
-
-.PHONY: doxygen
-
-# Rules for making release tarballs
-
-PACKAGE_VERSION=9.1.1
-PACKAGE_DIR = Mesa-$(PACKAGE_VERSION)
-PACKAGE_NAME = MesaLib-$(PACKAGE_VERSION)
-
-EXTRA_FILES = \
-	aclocal.m4					\
-	configure					\
-	bin/ar-lib					\
-	bin/compile					\
-	bin/config.sub					\
-	bin/config.guess				\
-	bin/depcomp					\
-	bin/install-sh					\
-	bin/ltmain.sh					\
-	bin/missing					\
-	bin/ylwrap					\
-	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		\
-	`git ls-files | grep "Makefile.am" | sed -e "s/Makefile.am/Makefile.in/"`
-
-
-IGNORE_FILES = \
-	-x autogen.sh
-
-
-parsers: configure
-	$(MAKE) -C src/glsl glsl_parser.cpp glsl_parser.h glsl_lexer.cpp glcpp/glcpp-lex.c glcpp/glcpp-parse.c glcpp/glcpp-parse.h
-	$(MAKE) -C src/mesa/program lex.yy.c program_parse.tab.c 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)

autogen.sh

@@ -1,14 +0,0 @@
-#! /bin/sh
-
-srcdir=`dirname "$0"`
-test -z "$srcdir" && srcdir=.
-
-ORIGDIR=`pwd`
-cd "$srcdir"
-
-autoreconf -v --install || exit 1
-cd $ORIGDIR || exit $?
-
-if test -z "$NOCONFIGURE"; then
-    "$srcdir"/configure "$@"
-fi

bin/.cherry-ignore

@@ -1,4 +0,0 @@
-d60da27273d2cdb68bc32cae2ca66718dab15f27 st/mesa: set ctx->Const.MaxSamples = 0, not 1
-5c86a728d4f688c0fe7fbf9f4b8f88060b65c4ee r600g: fix htile buffer leak
-496928a442cec980b534bc5da2523b3632b21b61 CopyTexImage: Don't check sRGB vs LINEAR for desktop GL
-3ee602314fc22054f69ee476f2e1037653d269bc mesa: Allow glGet* queries of MAX_VARYING_COMPONENTS in ES 3

bin/.gitignore

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

bin/get-pick-list.sh

@@ -1,29 +0,0 @@
-#!/bin/sh
-
-# Script for generating a list of candidates for cherry-picking to a stable branch
-
-# Grep for commits with "cherry picked from commit" in the commit message.
-git log --reverse --grep="cherry picked from commit" origin/master..HEAD |\
-	grep "cherry picked from commit" |\
-	sed -e 's/^[[:space:]]*(cherry picked from commit[[:space:]]*//' -e 's/)//' > already_picked
-
-# Grep for commits that were marked as a candidate for the stable tree.
-git log --reverse --pretty=%H -i --grep='^[[:space:]]*NOTE: .*[Cc]andidate' HEAD..origin/master |\
-while read sha
-do
-	# Check to see whether the patch is on the ignore list.
-	if [ -f bin/.cherry-ignore ] ; then
-		if grep -q ^$sha bin/.cherry-ignore ; then
-			continue
-		fi
-	fi
-
-	# Check to see if it has already been picked over.
-	if grep -q ^$sha already_picked ; then
-		continue
-	fi
-
-	git log -n1 --pretty=oneline $sha | cat
-done
-
-rm -f already_picked

bin/mklib.aix

@@ -0,0 +1,153 @@
+#!/bin/ksh
+
+# Make an AIX shared library (tricky!!!)
+# Based on a script from Athanasios G. Gaitatzes (gaitat@vnet.ibm.com)
+# Improved by Greg Thompson <gregt@visix.com> -gt
+
+#--identification------------------------------------------------------
+
+# $Id: mklib.aix,v 1.2 1999/09/15 15:10:20 brianp Exp $
+
+# $Log: mklib.aix,v $
+# Revision 1.2  1999/09/15 15:10:20  brianp
+# added third, tiny version number to arguments
+#
+# Revision 1.1  1999/08/19 13:52:56  brianp
+# initial check-in (post-crash)
+#
+
+
+#--common--------------------------------------------------------------
+
+LIBRARY=$1
+shift 1
+
+MAJOR=$1
+shift 1
+
+MINOR=$1
+shift 1
+
+TINY=$1
+shift 1
+
+OBJECTS=$*
+
+#--platform------------------------------------------------------------
+
+# BASENAME = LIBRARY without .a suffix
+BASENAME=`echo ${LIBRARY} | sed "s/\.a//g"`
+
+# Name of exports file
+EXPFILE=${BASENAME}.exp
+
+# Name of temporary shared lib file
+OFILE=shr.o
+####OFILE=${BASENAME}.o
+
+
+# Remove any old files from previous make
+rm -f ${LIBRARY} ${EXPFILE} ${OFILE}
+
+# Pick a way to use nm -gt
+NM=${NM-/bin/nm -eC}
+
+# Determine which version of AIX this is
+AIXVERSION=`uname -v`
+
+# Pick a way to tell the linker there's no entrypoint -gt
+case ${AIXVERSION}
+{
+	3*)
+		ENTRY='-e _nostart'
+		;;
+	4*)
+		ENTRY=-bnoentry
+		;;
+	*)
+		echo "Error in mklib.aix!"
+		exit 1
+		;;
+}
+
+
+# Other libraries which we may be dependent on.  Since we make the libraries
+# in the order libGL.a, libaGLU.a, libglut.a just depends on its predecessor.
+# modified to make otherlibs in the form of -lfoo -gt
+OTHERLIBS=`ls ../lib/*.a | sed "s/..\/lib\/lib/-l/g" | sed "s/\.a//g"`
+
+##echo OTHERLIBS are ${OTHERLIBS}
+
+
+# Make exports (.exp) file header
+echo "#! ${LIBRARY}" > ${EXPFILE}
+
+# Append list of exported symbols to exports file -gt
+case ${AIXVERSION}
+{
+    3*)
+	${NM} ${OBJECTS} | awk -F'|' '{
+	    if ($3 != "extern" || substr($7,1,1) == " ") continue
+	    sub ("  *", "", $1); sub ("  *", "", $7)
+	    if ( (($7 == ".text") || ($7 == ".data") || ($7 == ".bss"))  \
+		    && ( substr($1,1,1) != ".")) {
+		if (substr ($1, 1, 7) != "__sinit" &&
+			substr ($1, 1, 7) != "__sterm") {
+		    if (substr ($1, 1, 5) == "__tf1")
+			print (substr ($1, 7))
+		    else if (substr ($1, 1, 5) == "__tf9")
+			print (substr ($1, 15))
+		    else
+			print $1
+		}
+	    }
+	}' | sort -u >> ${EXPFILE}
+	;;
+
+    4*)
+	${NM} ${OBJECTS} | awk '{
+	    if ((($2 == "T") || ($2 == "D") || ($2 == "B")) \
+		    && ( substr($1,1,1) != ".")) {
+		if (substr ($1, 1, 7) != "__sinit" &&
+			substr ($1, 1, 7) != "__sterm") {
+		    if (substr ($1, 1, 5) == "__tf1")
+			print (substr ($1, 7))
+		    else if (substr ($1, 1, 5) == "__tf9")
+			print (substr ($1, 15))
+		    else
+			print $1
+		}
+	    }
+	}' | sort -u >> ${EXPFILE}
+	;;
+}
+
+
+# This next line is a hack to allow full compatibility with IBM's OpenGL
+# libraries.  IBM mistakenly exports glLoadIdentity from the libGLU.a
+# library.  We have to do the same thing.  Problem reported by Yemi Adesanya
+# (adesanya@afsmail.cern.ch) and Patrick Brown (pbrown@austin.ibm.com)
+if [ "${BASENAME}" = libGLU ] ; then
+    echo "glLoadIdentity" >> ${EXPFILE}
+fi
+
+
+# Make the shared lib file
+cc -o ${OFILE} ${OBJECTS} -L../lib ${OTHERLIBS} -lX11 -lXext -lXmu -lXi -lm -lc -bE:${EXPFILE} -bM:SRE ${ENTRY}
+
+
+# Make the .a file
+ar ruv ${LIBRARY} ${OFILE}
+
+# Put exports file in Mesa lib directory
+mv ${EXPFILE} ../lib
+
+# Remove OFILE
+rm -f ${OFILE}
+
+
+#NOTES
+# AIX 4.x /usr/bin/nm -B patch from ssclift@mach.me.queensu.ca (Simon Clift)
+# Robustified symbol extraction for AIX 3 and 4
+#   Greg Thompson <gregt@visix.com>
+

bin/mklib.ar-ruv

@@ -0,0 +1,38 @@
+#!/bin/sh
+
+# Make a standard Unix .a library file with 'ar ruv'
+
+#--identification------------------------------------------------------
+
+# $Id: mklib.ar-ruv,v 1.2 1999/09/15 15:10:20 brianp Exp $
+
+# $Log: mklib.ar-ruv,v $
+# Revision 1.2  1999/09/15 15:10:20  brianp
+# added third, tiny version number to arguments
+#
+# Revision 1.1  1999/08/19 13:52:57  brianp
+# initial check-in (post-crash)
+#
+
+
+#--common--------------------------------------------------------------
+
+LIBRARY=$1
+shift 1
+
+MAJOR=$1
+shift 1
+
+MINOR=$1
+shift 1
+
+TINY=$1
+shift 1
+
+OBJECTS=$*
+
+#--platform-------------------------------------------------------------
+
+#ar ruv $LIBRARY $OBJECTS
+ar ru $LIBRARY $OBJECTS
+

bin/mklib.solaris

@@ -0,0 +1,52 @@
+#!/bin/sh
+
+# Make a Solaris shared library
+# contributed by Arno Hahma (arno@nitro.pp.utu.fi)
+
+#--identification------------------------------------------------------
+
+# $Id: mklib.solaris,v 1.2 1999/09/15 15:10:20 brianp Exp $
+
+# $Log: mklib.solaris,v $
+# Revision 1.2  1999/09/15 15:10:20  brianp
+# added third, tiny version number to arguments
+#
+# Revision 1.1  1999/08/19 13:53:06  brianp
+# initial check-in (post-crash)
+#
+
+
+#--common--------------------------------------------------------------
+
+LIBRARY=$1
+shift 1
+
+MAJOR=$1
+shift 1
+
+MINOR=$1
+shift 1
+
+TINY=$1
+shift 1
+
+OBJECTS=$*
+
+#--platform-------------------------------------------------------------
+
+set -x
+
+LIBRARY=`basename $LIBRARY .a`
+
+VERSION=$MAJOR.$MINOR
+
+echo "Building shared object $LIBRARY.so.$VERSION and the archive library $LIBRARY.a"
+rm -f ${LIBRARY}.a ${LIBRARY}.so.${VERSION}
+ar ruv ${LIBRARY}.a ${OBJECTS}
+
+ld -G -o ${LIBRARY}.so.${VERSION} ${OBJECTS}
+
+cp ${LIBRARY}.a ${LIBRARY}.so.${VERSION} ../lib
+cd ../lib
+ln -s ${LIBRARY}.so.${VERSION} ${LIBRARY}.so
+

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,103 +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'))
-	opts.Add(BoolOption('texture_float', 'enable floating-point textures and renderbuffers', 'no'))
-	if host_platform == 'windows':
-		opts.Add(EnumOption('MSVC_VERSION', 'MS Visual C++ version', None, allowed_values=('7.1', '8.0', '9.0', '10.0', '11.0')))

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,160 +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, r600)
-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, r600)
-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                              DONE
-Depth format cube textures                            DONE
-GLX_ARB_create_context (GLX 1.4 is required)          DONE
-
-
-GL 3.1:
-
-GLSL 1.40                                             DONE (i965, r600)
-Forward compatibile context support/deprecations      DONE (i965, r600)
-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)    DONE for OpenGL 3.1 contexts (i965, r600)
-Rectangular textures (GL_ARB_texture_rectangle)       DONE (i965, r300, r600, swrast)
-Uniform buffer objs (GL_ARB_uniform_buffer_object)    DONE (i965, r600, swrast)
-Signed normalized textures (GL_EXT_texture_snorm)     DONE (i965, r300, r600)
-
-
-GL 3.2:
-
-Core/compatibility profiles                           DONE
-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 (i965, r300, r600, swrast)
-GL_ARB_sampler_objects                                DONE (i965, r300, r600)
-GL_ARB_shader_bit_encoding                            DONE
-GL_ARB_texture_rgb10_a2ui                             DONE (i965, r600)
-GL_ARB_texture_swizzle                                DONE (same as EXT version) (i965, r300, r600, swrast)
-GL_ARB_timer_query                                    DONE (i965, r600)
-GL_ARB_instanced_arrays                               DONE (i965, r300, r600)
-GL_ARB_vertex_type_2_10_10_10_rev                     DONE (i965, 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_shader5                                   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                   DONE (i965, softpipe)
-GL_ARB_texture_cube_map_array                        DONE (i965, softpipe)
-GL_ARB_texture_gather                                not started
-GL_ARB_transform_feedback2                           DONE
-GL_ARB_transform_feedback3                           DONE
-
-
-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, gallium)
-GL_ARB_transform_feedback_instanced                  DONE
-GL_ARB_base_instance                                 DONE (i965, 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                          DONE (r300, r600, radeonsi)
-
-
-GL 4.3:
-
-GLSL 4.3                                             not started
-ARB_arrays_of_arrays                                 not started
-ARB_ES3_compatibility                                not started
-ARB_clear_buffer_object                              not started
-ARB_compute_shader                                   started (gallium)
-ARB_copy_image                                       not started
-KHR_debug                                            some work done (ARB_debug_output)
-ARB_explicit_uniform_location                        not started
-ARB_fragment_layer_viewport                          not started
-ARB_framebuffer_no_attachments                       not started
-ARB_internalformat_query2                            not started
-ARB_invalidate_subdata                               not started
-ARB_multi_draw_indirect                              not started
-ARB_program_interface_query                          not started
-ARB_robust_buffer_access_behavior                    not started
-ARB_shader_image_size                                not started
-ARB_shader_storage_buffer_object                     not started
-ARB_stencil_texturing                                not started
-ARB_texture_buffer_range                             not started
-ARB_texture_query_levels                             not started
-ARB_texture_storage_multisample                      not started
-ARB_texture_view                                     not started
-ARB_vertex_attrib_binding                            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

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -48,7 +48,7 @@ Issues
 
 New Procedures and Functions
 
-    unsigned int glXGetAGPOffsetMESA( const void *pointer )
+    GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
 
 New Tokens
 
@@ -67,7 +67,7 @@ Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors)
     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
+    aperature.  The function
 
         GLuint glXGetAGPOffsetMESA( const GLvoid *pointer )
 
@@ -92,4 +92,3 @@ 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

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 
@@ -16,7 +16,7 @@ Status
 
 Version
 
-    Last Modified Date:  12 January 2009
+    Last Modified Date:  8 June 2000
 
 Number
 
@@ -69,12 +69,6 @@ Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
     <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
@@ -90,7 +84,5 @@ New State
 
 Revision History
 
-    12 January 2009 Ian Romanick - Added language about implicit flush
-                                   and command completion.
-    8 June 2000     Brian Paul   - initial specification
+    8 June 2000 - 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

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -48,7 +48,7 @@ IP Status
 
 Issues
 
-    1. Should we also define UNPACK_INVERT_MESA for glDrawPixels, etc?
+    1. Should we also defined 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

docs/MESA_packed_depth_stencil.spec

@@ -1,3 +1,5 @@
+XXX - Not complete yet!!!
+
 Name
 
     MESA_packed_depth_stencil
@@ -13,10 +15,11 @@ Contact
 
 Status
 
-    Obsolete.
+    Not yet shipping.
 
 Version
 
+    $Id: MESA_packed_depth_stencil.spec,v 1.1 2000/11/03 14:58:45 brianp Exp $
 
 Number
 

docs/MESA_pixmap_colormap.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 

docs/MESA_release_buffers.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 
@@ -31,12 +31,12 @@ 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
+    destroyed in order to free any ancilliary 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.
+    when the back color buffer, depth buffer, stencil buffer, and/or accum-
+    ulation buffer associated with a drawable can be freed.
 
 IP Status
 
@@ -60,7 +60,7 @@ Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
 
 	Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
 
-    causes all software ancillary buffers (back buffer, depth, stencil,
+    causes all software ancilliary 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

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,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_resize_buffers.spec,v 1.2 2000/04/04 23:29:32 brianp Exp $
 
 Number
 
@@ -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

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian 'at' mesa3d.org)
 
 Status
 

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

@@ -1,3 +1,5 @@
+XXX - Not complete yet!!!
+
 Name
 
     MESA_sprite_point
@@ -12,10 +14,11 @@ Contact
 
 Status
 
-    Obsolete - see GL_ARB_point_sprite.
+    Not yet shipping.
 
 Version
 
+    $Id: MESA_sprite_point.spec,v 1.1 2000/12/08 00:21:02 brianp Exp $
 
 Number
 

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

@@ -4,7 +4,7 @@ Name
 
 Name Strings
 
-     GL_MESA_trace
+     GL_MESA_TRACE
 
 Contact
     
@@ -13,10 +13,11 @@ Contact
 
 Status
 
-    Obsolete.
+    XXX - Not complete yet!!!
 
 Version
 
+    $Id: MESA_trace.spec,v 1.2 2001/01/29 16:10:18 brianp Exp $
 
 Number
 

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,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_window_pos.spec,v 1.3 2000/04/04 23:29:32 brianp Exp $
 
 Number
 
@@ -88,7 +89,7 @@ Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation)
       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
@@ -108,7 +109,7 @@ 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

docs/MESA_ycbcr_texture.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
     Keith Whitwell, Tungsten Graphics, Inc.  (keith 'at' tungstengraphics.com)
 
 Status
@@ -26,17 +26,16 @@ Number
 Dependencies
 
     OpenGL 1.0 or later is required
-    This extension is written against the OpenGL 1.4 Specification.
+    This extensions 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).
+    This extension supports texture images in the YCbCr format.  There is
+    no support for converting YCbCr images to RGB or vice versa.  The
+    intention is for YCbCr image data to be directly sent to the renderer
+    without any pixel transfer operations.  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
@@ -62,12 +61,12 @@ New Tokens
     Accepted by the <internalFormat> and <format> parameters of
     TexImage2D and TexSubImage2D:
 
-        YCBCR_MESA                   0x8757
+        GL_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 */
+        GL_UNSIGNED_SHORT_8_8_MESA      0x85BA /* same as Apple's */
+        GL_UNSIGNED_SHORT_8_8_REV_MESA  0x85BB /* same as Apple's */
 
 Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
 
@@ -75,14 +74,14 @@ Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
 
 Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
 
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
     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
+    UNSIGNED_SHORT_8_8_MESA       ushort         3         YCBCR_422_MESA
+    UNSIGNED_SHORT_8_8_REV_MESA   ushort         3         YCBCR_422_MESA
 
 
     In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
@@ -103,13 +102,13 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
     +-------------------------------+-------------------------------+
 
 
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
-    add the following to Table 3.12 (Packed pixel field assignments):
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
+    add the following to Table 3.12 (Packed pixel fiedl assignments):
 
                        First       Second     Third      Fourth
     Format             Element     Element    Element    Element
     ------             -------     -------    -------    -------
-    YCBCR_MESA         luminance   chroma
+    YCBCR_422_MESA     luminance   chroma
 
 
     In section 3.8.1, Texture Image Specification, on page 125, add
@@ -125,8 +124,7 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
       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.
+      sizes will return zero.
 
 
     In section 3.8.1, Texture Image Specification, on page 126, add
@@ -183,7 +181,7 @@ Errors
     <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.
+    format is YCBCR_MESA and format is not YCBCR_MESA.
 
     INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
     image is YCBCR_MESA.
@@ -197,8 +195,3 @@ New State
 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_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/README.3DFX

@@ -0,0 +1,613 @@
+
+                            3Dfx Glide device driver
+
+
+
+Info for Mesa 4.1
+-----------------
+
+The 3dfx Glide driver in Mesa is disabled by default.  Not too many people
+use this driver anymore and at some point down the road it will be dropped.
+
+To use/enable the Glide driver either do this:
+
+'./configure --with-glide=DIR'    Where DIR is the location of Glide, like
+                                  /usr/ or /usr/local
+
+OR
+
+'make linux-x86-glide'     If using the old-style Makefile system.
+
+The rest of this file hasn't changed since Mesa 3.3.  Some of it's out of
+date, but some is still valid.
+
+
+
+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");
+
+	- 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.);
+
+	- 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).
+
+	NOTE: the in-window rendering feature only works with double-buffering.
+
+
+        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.
+
+        - If you define the env. var. MESA_FX_NO_SIGNALS:
+		export MESA_FX_NO_SIGNALS=1
+          Mesa/FX will not install atexit() or signal() handlers.
+
+
+
+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.
+
+
+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,114 @@
+
+                         Mesa / BeOS Information
+
+
+
+* Introduction
+
+Mesa 4.1 features a driver for the BeOS.  The driver implements
+a clone of the BGLView class.  This class, derived from BView, allows
+OpenGL rendering into a BeOS window.
+The 4.1 BeOS driver is an update of Brian Paul's BeOS driver released in Mesa 3.1.
+
+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 R5) 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-4.1/src/BeOS/ directory.
+It's not 100% finished at this time but many GLUT-based demos are
+working.  No optimizations have been made at this time.
+
+
+
+* Compiling
+
+Requirements:
+  - gcc version 2.95.3 for BeOS 
+  You can find it here: http://www.bebits.com/app/2157
+
+Move to the Mesa-4.x src sub-directory and then type "make -f Makefile.BeOS-R5".
+When it finishes the Mesa based libGL.so library for
+BeOS will be in the Mesa-4.x/src/obj.{x86|ppc}/ directory.
+
+To install it as Be's default libGL.so replacement, put it in your 
+/boot/home/config/lib/ directory. All your GL/GLUTapps will use 
+the Mesa based then. 
+
+By default, it build a non-debug version library.
+The x86 (MMX, SSE and 3DNOW) optimizations are also supported for x86 target.
+Sorry, Mesa don't have ppc (Altivec) optimizations yet.
+
+
+* Example Programs
+
+Look in the Mesa-4.x/BeOS/ directory for one or two BGLView demo
+programs.  They should have been compiled along with the Mesa
+library.
+
+
+* GLUT
+
+A beta version of GLUT 3.7 port for BeOS can be found at 
+http://anobject.com/jehamby/Code/Glut-3.7-x86.zip.
+ 
+There's is a 2.5 version in src-glut.beos/, too.
+The original distribution can be obtained from
+http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip
+
+They are special version of GLUT adapted for the BeOS.  I don't
+believe Mark Kilgard's normal GLUT distribution includes BeOS
+support.
+
+
+* 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
+
+BDirectWindow single buffering support is not implemented yet.
+
+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.7 2002/09/19 16:19:44 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.DJ

@@ -0,0 +1,209 @@
+			Mesa 4.1 DOS/DJGPP Port v1.2
+			~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+Description:
+~~~~~~~~~~~~
+
+Well, guess what... this is the DOS port of Mesa 4.1, for DJGPP fans... Whoa!
+The driver has its origins in ddsample.c, written by Brian Paul and found by me
+in Mesa 3.4.2.
+
+
+
+Legal:
+~~~~~~
+
+Mesa copyright applies, provided this package is used within Mesa. For anything
+else, see GPL.
+
+
+
+Installation:
+~~~~~~~~~~~~~
+
+Unzip and type:
+
+	make -f Makefile.DJ [OPTIONS...]
+
+Available options:
+
+     Environment variables:
+	CPU		optimize for the given processor.
+			default = k6
+	BIG_OPT=1	crazy optimizations; not very useful, though...
+			default = no
+	GLIDE		absolute path to Glide library; used with FX.
+			default = $(TOP)/include/glide3
+	FX=1		build for 3dfx Glide3; use it if you have the Glide
+			SDK (designed for your platform), and, of course, a
+			3dfx card... Note that this disables compilation of
+			actual DMesa code, as Glide does all the stuff!
+			default = no
+	HAVE_X86=1	optimize for i386.
+			default = no
+	HAVE_MMX=1	MMX instructions; use only if you assembler/compiler
+			supports MMX instruction set; backwards compatibility
+			with older processors is still preserved.
+			default = no
+	HAVE_SSE=1	(see HAVE_MMX)
+			default = no
+	HAVE_3DNOW=1	(see HAVE_MMX)
+			default = no
+
+     Targets:
+	all:		build everything
+	libgl:		build GL
+	libglu:		build GLU
+	libglut:	build GLUT
+	clean:		remove object files
+	realclean:	remove all generated files
+
+
+
+Tested on:
+	CPU:		K6-2 (CXT) @500(412.5) MHz
+	Mainboard:	ViA Apollo VP2/97 w/ 128 MB SDRAM
+	Video card:	PowerColor Evil King3 (Voodoo3 3000) w/ 16384 kB SDRAM
+	DJGPP:		djdev 2.04 + gcc v3.2 + make v3.79.1
+
+
+
+FAQ:
+~~~~
+
+1. Compilation
+
+   Q) I tried to run `make' and it exits because `gcc' complains it cannot find
+      some stupid file.
+   A) You need LFN support.
+   A) When compiling for Glide (FX=1), pay attention to Glide path.
+
+2. Dynamic modules
+
+   Q) What are you mumbling about dynamic modules?
+   A) You must have the DXE2 package (available on SimTel.Net, courtesy of
+      Andrew Zabolotny) installed in order to build the dynamic modules.
+
+   Q) I have DXE2, but I couldn't build the `dxe2gen.exe'.
+   Q) I built `dxe2gen.exe', but it doesn't do the job right.
+   A) There is a patched version on my web page.
+
+   Q) DXE2 modules give me headaches...
+   A) The DXE2 modules are not compulsory. The static libraries are still built
+      and you can use them in the old-fashioned, classic way... and learn to
+      live with your ~2MB executable size. For example:
+	gcc -o OUT.exe IN.c -lglut -lglu -lgl
+
+   Q) Okay, DXE2 modules are built. How can I use them?
+   A) Build your export object file; then link it with your application.
+      For example:
+	dxe2res -o dmesadxe.c gl.dxe glu.dxe glut.dxe
+	gcc -o dmesadxe.o dmesadxe.c
+	gcc -o OUT.exe dmesadxe.o IN.c -liglut -liglu -ligl -ldl
+
+   Q) What is that `dxe2res.exe' thing?
+   A) That is an utility that generates the export file for a given set of
+      modules. If you can't find it in the DXE2 package, you must be looking at
+      the wrong archive :)
+
+3. Using Mesa for DJGPP
+
+   Q) Does this build work in Win9x?
+   A) Yes.
+
+   Q) Does it work under NT (W2k, XP) core?
+   A) Uh... probably not!
+
+   Q) I made a simple application and it does nothing. It exits right away. Not
+      even a blank screen.
+   A) The current version supports only RGB[A] modes, for it made no sense to
+      me to endorse color-index (aka palette) modes.
+   A) Single-buffered is not allowed at all. Until I can find a way to use
+      *REAL* hardware acceleration, it won't get implemented.
+   A) Another weird "feature" is that buffer width must be multiple of 4 (I'm a
+      lazy programmer and I found that the easiest way to keep buffer handling
+      at peak performance ;-).
+
+   Q) My demo doesn't display text. I know I used the glut font routines!
+   A) Then you probably use GLUT as a DXE. Well, there is no direct access to
+      variables due to the way DXE works. Read the documentation. The author of
+      GLUT took this into account for _WIN32 DLL's only; I don't want to modify
+      his headers. The only workaround is to link GLUT the old way :-(
+
+   Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much
+      better...
+   A) Is that a question? If you have a Voodoo3/Banshee card, you're lucky. The
+      Glide port is on my web page. If you haven't, sorry; everything is done
+      in software. Suggestions?
+
+   Q) I have a super/mega/ultra monitor and all you can do is 60Hz? My eyes are
+      leaking from the orbits...
+   A) If you were compiling for Glide, see Glide info. If not, be aware that
+      refresh rate control works only for VESA 3.0. The environment variable
+      DMESA_REFRESH sets the default screen refresh. For example:
+	set DMESA_REFRESH=75
+
+
+
+libGLUT (the toolkit):
+~~~~~~~~~~~~~~~~~~~~~~
+
+Well, this "skeletal" GLUT implementation is not mine. Thanks should go to
+Bernhard Tschirren, Mark Kilgard, Brian Paul and probably others (or probably
+not ;-). I only changed it to be self-standing (Allegro-free). The keyboard,
+mouse and timer drivers were inspired from an old project of mine (D3Xl) and
+fixed with many Allegro "infusions"; I deeply thank to Shawn Hargreaves et co.
+
+My keyboard driver used only scancodes, but since GLUT requires ASCII values
+for keys, I borrowed the translation tables (and maybe more) from Allegro.
+Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users) will shut down the GLUT
+engine unconditionally: it will raise SIGINT, which in turn will call the
+destructors (let's hope), thus cleaning up your/my mess ;-) NB: since the
+DJGPP guys ensured signal handlers won't go beyond program's space (and since
+dynamic modules shall) the SIGINT can't be hooked (well, it can, but it is
+useless), therefore you must live with the 'Exiting due to signal SIGINT'
+message...
+
+The mouse driver is far from complete (lack of positioning, drawing, etc),
+but is enough to make almost all the demos work.
+
+The timer is pretty versatile for it supports multiple timers with different
+frequencies. It may not be the most accurate timer in the known universe, but
+I think it's OK. Take this example: you have timer A with a very high rate,
+and then you have timer B with very low rate compared to A; now, A ticks OK,
+but timer B will probably loose precision!
+
+As an addition, stdout and stderr are redirected and dumped upon exit. This
+means that printf can be safely called during graphics, but all messages come
+in bulk! A bit of a hack, I know, but I think it's better than to miss them
+at all. "Borrowed" from RHIDE (Robert Hoehne) or SETEDIT (Salvador Eduardo
+Tropea)... I'm not sure.
+
+Window creating defaults: 640x480x16 at (0,0), 8-bit stencil, 16-bit accum.
+However, the video mode is chosen in such a way that first window will fit.
+
+
+
+History:
+~~~~~~~~
+
+v1.0	mar-2002	initial release
+
+v1.1	sep-2002	+ added 3dfx Glide3 support
+			+ added refresh rate control
+			+ added fonts in glut
+			* lots of minor changes
+
+v1.2	nov-2002	* synced w/ Mesa-4.1
+			- removed dmesadxe.h
+
+
+
+Contact:
+~~~~~~~~
+
+Name:   Borca Daniel
+E-mail: dborca@yahoo.com
+WWW:    http://www.geocities.com/dborca/

docs/README.GGI

@@ -0,0 +1,26 @@
+GGIMesa for LibGGI 2.x
+
+Requirements:
+-------------
+LibGGI 2.0 or greater
+
+Installation:
+-------------
+To install GGIMesa, follow the instructions in INSTALL.GNU.  If you 
+wish to install GGIGLUT as well, first install GGIMesa and then run
+
+make
+make install (must be root)
+
+in ggi/ggiglut.
+
+Notes:
+------
+
+* Set the environment variables GGIMESA_DEBUG and/or GGIGLUT_DEBUG 
+to 255 to see lots of debugging output.
+
+* GGIGLUT contains support for all of the GLUT 3.6 API except for the
+high-level primitive drawing functions, but many of the functions (in
+particular the menu drawing functions) are just stubs.
+

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,53 @@
+August 30, 1998 -- Paul Garceau
+Updated January 13, 2000 -- Paul Garceau (pgarceau@teleport.com)
+
+DISCLAIMER:  I make this port of 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
+build will work for your system.
+
+	The associated packages and batch files I have included as part of the GCC-2.95.2/Mingw32 extension are provided "As-is" with out any guarantee of support or functionality from this author.
+
+	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.
+
+	I recommend using GCC-2.95.2/Mingw32 which is available at Mumit Khans' ftp site:
+
+		(ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/)
+
+	This build has been tested under WinNT4/SP6.  Win9x and WinNT5 remain untested by me.  I have not tested any of the demos included with Mesa3d.
+
+	I recommend using the GCC-2.95.2/Mingw32.
+
+	ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2
+
+	Much thanks to the combined efforts of Mumit Khan, Jan-Jaap Vanderhagen
+and Colin Peters for making it possible for the Mingw32 toolchain to exist.  Also, thanks go out to Stephane Rehel for the work that was completed on the Cygwin build.
+
+Installing GCC-2.95.2/Mingw32 Build:
+
+	a) Open the file archive (either tar.gz or .zip extensions)
+
+	b) Decide the directory you want to move the archived files to.
+
+	d) Extract the files from the archive.
+	
+	e) Edit the mingw32.bat file to accomodate your choice of directory structure.
+
+		%mesaroot%:	This is your root directory (Mesa-3.3)
+		%mesasrc%:	This is the Mesa-3.3 src directory (Mesa-3.3\src)
+		%mesalib%:	This is where the build will put libGL.a and libGLU.a
+
+Running the Build:
+
+	Open your Command Prompt or MS-DOS prompt.
+	Go to your Mesa-3.3 'root' directory
+	At the command line type: mingw32
+
+	That's all there is to it.
+
+	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.VMS

@@ -0,0 +1,28 @@
+
+VMS support contributed by Jouk Jansen (joukj@hrem.stm.tudelft.nl)
+
+
+The latest version was tested on a VMSAlpha7.2 system using DECC6.0, but
+probably also works for other versions.
+
+At the moment only the libraries LIBMESGL.EXE/LIBMESGL.OLB,
+LIBMESAGLU.EXE/LIBMESAGLU.OLB and LIBGLUT.EXE/LIBGLUT.OLB and the demos of the
+directory [.DEMOS] can be build.
+However, feel free to create the missing "decrip.mms-files" in the other
+directories.
+
+ The make files were tested
+using the DIGITAL make utility called MMS.  There is also a public domain
+clone available (MMK) and I  think, but it is not tested, that this
+utility will give (hardly) any problem.
+
+To make everything just type MMS (or MMK) in the main directory of
+mesagl.  For MMS the deafult makefile is called descrip.mms, and
+that is what I have called it.  I included alse some config files,
+all having mms somewhere in the name which all the makefiles need
+(just as your unix makefiles).
+
+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.
+

docs/README.WIN32

@@ -1,53 +1,98 @@
 File: docs/README.WIN32
 
-Last updated: 23 April 2011
-
+Last updated: Nov 08, 2002 - Karl Schultz - kschultz@users.sourceforge.net
 
 Quick Start
------ -----
 
-Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
-no longer shipped or supported.
+Unzip both ZIP files (MesaLib and MesaDemos) into the same directory.
+This is important because the current makefiles in MesaLib assume that
+the directories in MesaDemos are present.
 
-Run
+If you have Microsoft Visual C++ 6.0 installed, simply go to the top directory
+of the Mesa distribution and type 'nmake -f Makefile.win NODEBUG=1' for
+an optimized build.  Note that you may have to run ...VC98/BIN/VCVARS32.BAT
+to set up the appropriate compiler environment variables.
 
-  scons osmesa mesagdi
+Details and Notes
 
-to build classic mesa Windows GDI drivers; or
+- Building Mesa as noted above should visit and build the following:
+  src        MesaGL.dll, MesaGL.lib, osmesa.dll, osmesa.lib
+  si-glu     MesaGLU.dll, MesaGLU.lib
+  src-glut   glut32.dll, glut32.lib
+  demos      a handful of demo executables.
+  book       more examples
+  samples    more examples
 
-  scons libgl-gdi
+- After building, you can copy the above DLL files to a place in your PATH
+  such as $SystemRoot/SYSTEM32.  If you don't like putting things in a
+  system directory, place them in the same directory as the executable(s).
+  For example, you can copy the DLL files to the demos directory if you
+  just want to run the demos. The build process places the DLL and LIB files
+  in the ./lib directory.  The makefile creates this directory if it does 
+  not already exist.
 
-to build gallium based GDI driver.
+- The make targets 'clean' and 'clobber' will remove objects and libraries.
+  But the files in ./lib are never cleaned.
 
-This will work both with MSVS or Mingw.
+- The make target 'install' will take its best shot at copying DLL files,
+  LIB files, and headers to the right places.  I strongly suggest that
+  you examine the makefiles to make sure that 'install' doesn't do anything
+  that you can't live with.
+
+- The makefiles are designed to work with Microsoft's NMAKE, and do,
+  unfortunately, have some Microsoft-specific things in them.  If you
+  would like to use gcc or some other build tools like the Cygnus tools,
+  then you will have to hack the makefiles to make them work with your
+  tools.  I'm sorry about this; I wasn't motivated to make this any
+  different, but if you end up modifying the makefiles for your tools,
+  you can send me the changes and I can apply the changes to the 
+  source tree.
+
+- There are no Microsoft Visual Studio project files.  However, these
+  should be very easy to create.  One can use the compiler and linker
+  options found in the makefiles to make quick progress in creating
+  projects.
+
+- The DLL files are built so that the external entry points use the
+  stdcall calling convention.
+
+- Static LIB files are not built.  The LIB files that are built with
+  the current makefiles are the linker import files associated with
+  the DLL files.  If static LIB's are desired, it should not be too
+  difficult to modify the makefiles to generate them.
+
+- The si-glu sources are used to build the GLU libs.  This was done
+  mainly to get the better tessellator code.
+
+- The osmesa driver builds and should work on Windows as well as
+  any other platform.
+
+- The Windows driver (in src/Windows) builds and runs at least at
+  a minimal level.  I modified this driver to work with the new
+  Mesa 4.0 code and driver architecture, but I did not do a great
+  deal of optimization and testing.  There are many opportunities
+  for optimization, many of which can be done by coding more specific
+  paths for the rasterizers.  See src/osmesa/osmesa.c for some good
+  examples.
+
+- There is DirectDraw support in the Windows driver, updated by
+  Daniel Slater.  You'll need to uncomment the #define DDRAW line
+  in src/Windows/wmesadef.h and add ddraw.lib to the list of libraries
+  in src/Makefile.win.  On some systems, you will acheive significantly
+  higher framerates with DirectDraw.
+
+- Some of the more specialized code like FX drivers, stereo, and
+  parallel support isn't compiled or tested.  I left much of this
+  code alone, but it may need some work to get it 'turned on' again.
+
+- No assembly code is compiled or assembled.  Again, this may need
+  some work to turn it back on or use it again.
+
+If you have a Windows-related build problem or question, it is
+probably better to direct it to me (kschultz@users.sourceforge.net),
+rather than directly to the other Mesa developers.  I will help you
+as much as I can.  I also monitor the Mesa mailing lists and will
+answer questions in this area there as well.
 
 
-Windows Drivers
-------- -------
-
-At this time, only the gallium GDI driver is known to work.
-
-Source code also exists in the tree for other drivers in
-src/mesa/drivers/windows, but the status of this code is unknown.
-
-
-General
--------
-
-After building, you can copy the above DLL files to a place in your
-PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things
-in a system directory, place them in the same directory as the
-executable(s).  Be careful about accidentially overwriting files of
-the same name in the SYSTEM32 directory.
-
-The DLL files are built so that the external entry points use the
-stdcall calling convention.
-
-Static LIB files are not built.  The LIB files that are built with are
-the linker import files associated with the DLL files.
-
-The si-glu sources are used to build the GLU libs.  This was done
-mainly to get the better tessellator code.
-
-If you have a Windows-related build problem or question, please post
-to the mesa-dev or mesa-users list.
+Karl Schultz

docs/README.WINDML

@@ -0,0 +1,146 @@
+
+                        WindML Driver for Mesa 4.0
+
+
+Requirements
+------------
+
+Tornado 2 + WindML, Cumulative Patchs are recommended. 
+  
+I suppose you have a valid WindML installation. Double buffer hardware
+gives better performance than double buffer software so if you can
+compile your WindML driver with this option, just do it. I/O
+redirection is adviced in target server.
+
+
+Tested on
+---------
+
+During the development, my main target was a CoolMonster:
+- Video card: CT69000
+- CPU: PENTIUM 266MHz
+
+and my host a Windows NT + Tornado 2.
+
+
+Installation
+------------
+
+1. Mesa sources must be in root directory (C:\)
+
+2. Add the following line to your torVars.bat:
+set MESA_BASE=C:\Mesa
+
+OR copy the new torVars.bat in your bin path:
+c:/Mesa/src/ugl/tornado/torVars.sample -> 
+/mnt/nt/Tornado/host/x86-win32/bin/torVars (for example)
+
+3. In a command prompt:
+$ torVars
+$ cd c:\Mesa
+$ make -f Makefile.ugl CPU=PENTIUM
+
+Take a long while...
+
+5. Include all the files from ugldemos folder to build some downloadable
+   application modules
+
+4. Download UGL/Mesa object files on target
+
+For example via the WindShell:
+ld < c:\Tornado\target\lib\objMesaGL.o
+ld < c:\Tornado\target\lib\objMesaUGL.o
+ld < c:\Tornado\target\lib\objMesaGLU.o
+ld < c:\Tornado\target\lib\objGLUTshapes.o
+ld < c:\Tornado\target\lib\objMesaOS.o
+
+You can put the previous lines in a file and use:
+< filename
+
+6. Download the application modules.
+
+7. In WindShell, run:
+-> uglalldemos
+
+During the show some messages will appear, it provides some useful
+information on key management.
+
+
+Coding
+------
+
+Sample Usage:
+
+In addition to the usual ugl calls to initialize UGL, (may be find an
+input driver), you must do the following to use the UGL/Mesa interface:
+
+1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context,
+   given the display format.
+
+2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an
+   UGL/Mesa Context and to make the context the current one.
+
+3. Make gl* calls to render your graphics.
+
+4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers.
+
+5. Before the UGL is destroyed, call MesaDestroyContext().
+
+6. Before exiting, call if required uglEventQDestroy and then
+   uglDeinitialize();
+
+Limitations
+-----------
+
+I found the following limitations in my driver :
+ - Color Indexed management is only in 8 bits
+ - It's possible to mix UGL/OpenGL application with a software
+   double buffer
+
+Modifications
+------------
+
+New files in Mesa:
+- Makefile.ugl
+- rules.windmlmesa
+- docs/README.UGL
+- include/GL/uglmesa.h
+- si-glu/Makefile.ugl
+- src/Makefile.ugl
+- src/ugl/torGLUTShapesInit.c
+- src/ugl/torMesaUGLInit.c
+- src/ugl/ugl_api.c
+- src/ugl/ugl_dd.c
+- src/ugl/ugl_glutshapes.c
+- src/ugl/ugl_line.c
+- src/ugl/ugl_span.c
+- src/ugl/ugl_tri.c
+- src/ugl/uglmesaP.h
+- ugldemos/*
+
+Modified files in Tornado 2.0:
+- c:\Tornado\host\x86-win32\bin\torVars.bat
+rem Command line build environments
+set WIND_HOST_TYPE=x86-win32
+set WIND_BASE=C:\Tornado
+set MESA_BASE=C:\Mesa
+set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%
+- c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf
+- c:\Tornado\target\h\GL\*
+
+Todo
+----
+- GCC 2.96, ASM compilation
+
+Thanks to:
+----------
+
+Precision Insight team for their great job around Mesa, XFree, and DRI.
+Wind River Systems to take me as an intern.
+
+
+Stephane Raimbault
+<stephane.raimbault@windriver.com>
+<stephane.raimbault@deesse.univ-lemans.fr>
+
+July 24, 2001

docs/README.X11

@@ -0,0 +1,320 @@
+
+                          Mesa Unix/X11 Information
+
+
+
+Installation
+============
+
+There are two ways to compile Mesa on Unix/X11 systems:
+
+1. The old way:
+    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.
+
+    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.
+
+    When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
+
+
+2. The new way:
+    Type './configure' and then 'make'.  This uses GNU autoconfig.
+    Run 'make check' to build the demos.
+    See docs/INSTALL for more details.
+    When finished, the Mesa libraries will be in the Mesa-x.y/src/.libs/,
+    Mesa-x.y/si-glu/.libs, etc directories.
+
+
+Notes on assembly language optimizations:
+
+   When using the old-style Makefiles, you can specify a configuration
+   that uses X86 assembly language optimizations (linux-3dnow for example).
+
+   The detection of MMX, 3DNow!, PIII/SSE, etc capability is done at
+   runtime.  That means you can compile Mesa for 3DNow! optimizations
+   even if you don't have an AMD CPU.
+
+   However, your Linux binutils and assembler must understand the
+   special instructions in order to compile them.  If you have
+   compilation problems, try upgrading your binutils.
+
+
+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)
+
+
+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
+       % 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://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:
+   The following OpenGL GLX extensions are currently implemented:
+
+      GLX_EXT_visual_info - GLX visual and transparent pixel extension
+      GLX_EXT_visual_rating - GLX visual caveats
+
+   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.9 2002/10/29 23:42:48 brianp Exp $

docs/RELNOTES-3.1

@@ -143,3 +143,4 @@ code).  Anyone want to help?
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.1,v 1.2 2000/04/07 17:08:06 brianp Exp $

docs/RELNOTES-3.2

@@ -9,3 +9,4 @@ have been added.  For a list of bug fixes please read the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.2,v 1.2 2000/04/07 17:08:06 brianp Exp $

docs/RELNOTES-3.2.1

@@ -29,3 +29,4 @@ GLU library.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.2.1,v 1.2 2000/07/21 16:32:33 brianp Exp $

docs/RELNOTES-3.3

@@ -268,3 +268,4 @@ image convolution.  This will (hopefully) be done for Mesa 3.5/3.6.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.3,v 1.8 2000/07/21 16:26:41 brianp Exp $

docs/RELNOTES-3.4

@@ -19,3 +19,4 @@ see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4,v 1.2 2002/03/23 02:37:17 brianp Exp $

docs/RELNOTES-3.4.1

@@ -19,3 +19,4 @@ the Mesa 3.4 release.  For details, see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4.1,v 1.2 2001/05/23 14:45:01 brianp Exp $

docs/RELNOTES-3.4.2

@@ -19,3 +19,4 @@ the Mesa 3.4.1 release.  For details, see the VERSIONS file.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.4.2,v 1.2 2001/05/23 14:45:01 brianp Exp $

docs/RELNOTES-3.5

@@ -225,3 +225,4 @@ In the future I hope to implement support for 32-bit, floating point
 color channels.
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-3.5,v 1.14 2001/06/20 19:02:48 brianp Exp $

docs/RELNOTES-4.0

@@ -160,3 +160,4 @@ See the VERSIONS file for more details about bug fixes, etc. in Mesa 4.0.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0,v 3.2 2001/10/17 14:59:21 brianp Exp $

docs/RELNOTES-4.0.1

@@ -19,3 +19,4 @@ Mesa 4.0.1 only contains bug fixes since version 4.0.
 See the docs/VERSIONS file for the list of bug fixes.
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.1,v 1.2 2001/12/18 14:08:23 brianp Exp $

docs/RELNOTES-4.0.2

@@ -47,3 +47,4 @@ D3D			needs updating
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.2,v 1.2 2002/03/23 02:38:39 brianp Exp $

docs/RELNOTES-4.0.3

@@ -49,3 +49,4 @@ D3D			needs updating
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.0.3,v 1.2 2002/06/26 02:36:34 brianp Exp $

docs/RELNOTES-4.1

@@ -305,3 +305,4 @@ are some things to change:
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-4.1,v 1.22 2002/10/29 15:06:37 brianp Exp $

docs/RELNOTES-5.0

@@ -82,3 +82,4 @@ driver call the _mesa_enable_1_4_extensions() function.
 
 
 ----------------------------------------------------------------------
+$Id: RELNOTES-5.0,v 3.2 2002/11/13 15:33:51 brianp Exp $

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.118 2002/11/13 15:33:50 brianp Exp $
 
 
 Mesa Version History
@@ -1079,436 +1080,3 @@ Mesa Version History
 	- 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,175 +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);
-
-    EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
-                                       struct wl_buffer *buffer,
-                                       EGLint attribute, EGLint *value);
-
-New Tokens
-
-    Accepted as <target> in eglCreateImageKHR
-
-        EGL_WAYLAND_BUFFER_WL                   0x31D5
-
-    Accepted in the <attrib_list> parameter of eglCreateImageKHR:
-
-        EGL_WAYLAND_PLANE_WL                    0x31D6
-
-    Possible values for EGL_TEXTURE_FORMAT:
-
-        EGL_TEXTURE_Y_U_V_WL                    0x31D7
-        EGL_TEXTURE_Y_UV_WL                     0x31D8
-        EGL_TEXTURE_Y_XUXV_WL                   0x31D9
-
-
-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.
-
-    A wl_buffer can have several planes, typically in case of planar
-    YUV formats.  Depending on the exact YUV format in use, the
-    compositor will have to create one or more EGLImages for the
-    various planes.  The eglQueryWaylandBufferWL function should be
-    used to first query the wl_buffer texture format using
-    EGL_TEXTURE_FORMAT as the attribute.  If the wl_buffer object is
-    not an EGL wl_buffer (wl_shm and other wayland extensions can
-    create wl_buffer objects of different types), this query will
-    return EGL_FALSE.  In that case the wl_buffer can not be used with
-    EGL and the compositor should have another way to get the buffer
-    contents.
-
-    If eglQueryWaylandBufferWL succeeds, the returned value will be
-    one of EGL_TEXTURE_RGB, EGL_TEXTURE_RGBA, EGL_TEXTURE_Y_U_V_WL,
-    EGL_TEXTURE_Y_UV_WL, EGL_TEXTURE_Y_XUXV_WL.  The value returned
-    describes how many EGLImages must be used, which components will
-    be sampled from each EGLImage and how they map to rgba components
-    in the shader.  The naming conventions separates planes by _ and
-    within each plane, the order or R, G, B, A, Y, U, and V indicates
-    how those components map to the rgba value returned by the
-    sampler.  X indicates that the corresponding component in the rgba
-    value isn't used.
-
-    RGB and RGBA buffer types:
-
-        EGL_TEXTURE_RGB
-                One plane, samples RGB from the texture to rgb in the
-                shader.  Alpha channel is not valid.
-
-        EGL_TEXTURE_RGBA
-                One plane, samples RGBA from the texture to rgba in the
-                shader.
-
-    YUV buffer types:
-
-        EGL_TEXTURE_Y_U_V_WL
-                Three planes, samples Y from the first plane to r in
-                the shader, U from the second plane to r, and V from
-                the third plane to r.
-
-        EGL_TEXTURE_Y_UV_WL
-                Two planes, samples Y from the first plane to r in
-                the shader, U and V from the second plane to rg.
-
-        EGL_TEXTURE_Y_XUXV_WL
-                Two planes, samples Y from the first plane to r in
-                the shader, U and V from the second plane to g and a.
-
-    After querying the wl_buffer layout, create EGLImages for the
-    planes by calling eglCreateImageKHR with wl_buffer as
-    EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
-    context.  If no attributes are given, an EGLImage will be created
-    for the first plane.  For multi-planar buffers, specify the plane
-    to create the EGLImage for by using the EGL_WAYLAND_PLANE_WL
-    attribute.  The value of the attribute is the index of the plane,
-    as defined by the buffer format.  Writing to an EGLImage created
-    from a wl_buffer in any way (such as glTexImage2D, binding the
-    EGLImage as a renderbuffer etc) will result in undefined behavior.
-
-    Further, eglQueryWaylandBufferWL accepts attributes EGL_WIDTH and
-    EGL_HEIGHT to query the width and height of the wl_buffer.
-
-Issues
-
-Revision History
-
-    Version 1, March 1, 2011
-        Initial draft (Benjamin Franzke)
-    Version 2, July 5, 2012
-        Add EGL_WAYLAND_PLANE_WL attribute to allow creating an EGLImage
-        for different planes of planar buffer. (Kristian Høgsberg)
-    Version 3, July 10, 2012
-        Add eglQueryWaylandBufferWL and the various buffer
-        formats. (Kristian Høgsberg)
-    Version 4, July 19, 2012
-        Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
-        and just define the new YUV texture formats.  Add support for
-        EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)

docs/autoconf.html

@@ -1,250 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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>
-</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:
-</p>
-<dl>
-<dt><code>--prefix=PREFIX</code></dt>
-<dd><p>This is the root directory where
-files will be installed by <code>make install</code>. The default is
-<code>/usr/local</code>.</p>
-</dd>
-
-<dt><code>--exec-prefix=EPREFIX</code></dt>
-<dd><p>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>.</p>
-</dd>
-
-<dt><code>--libdir=LIBDIR</code></dt>
-<dd><p>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.</p>
-</dd>
-
-<dt><code>--enable-static, --disable-shared</code></dt>
-<dd><p>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.</p>
-</dd>
-
-<dt><code>CC, CFLAGS, CXX, CXXFLAGS</code></dt>
-<dd><p>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>.</p>
-</dd>
-
-<dt><code>LDFLAGS</code></dt>
-<dd><p>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>.</p>
-</dd>
-
-<dt><code>PKG_CONFIG_PATH</code></dt>
-<dd><p>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.</p>
-</dd>
-</dl>
-
-<p>
-There are also a few general options for altering the Mesa build:
-</p>
-<dl>
-<dt><code>--with-x</code></dt>
-<dd><p>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.</p>
-</dd>
-
-<dt><code>--enable-gl-osmesa</code></dt>
-<dd><p>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.</p>
-</dd>
-
-<dt><code>--enable-debug</code></dt>
-<dd><p>This option will enable compiler
-options and macros to aid in debugging the Mesa libraries.</p>
-</dd>
-
-<dt><code>--disable-asm</code></dt>
-<dd><p>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.</p>
-</dd>
-
-<dt><code>--enable-32-bit</code></dt>
-<dt><code>--enable-64-bit</code></dt>
-<dd><p>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.</p>
-</dd>
-</dl>
-
-
-<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>.
-
-</div>
-</body>
-</html>

docs/bugs.html

@@ -1,61 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<h1>Bug Database</h1>
-
-<p>
-The Mesa bug database is hosted on
-<a href="http://freedesktop.org">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">
-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>
-
-</div>
-</body>
-</html>

docs/conform.html

@@ -1,703 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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).
-
-</div>
-</body>
-</html>

docs/contents.html

@@ -1,104 +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="_parent">Introduction</a>
-<li><a href="index.html" target="_parent">News</a>
-<li><a href="developers.html" target="_parent">Developers</a>
-<li><a href="systems.html" target="_parent">Platforms and Drivers</a>
-<li><a href="license.html" target="_parent">License &amp; Copyright</a>
-<li><a href="faq.html" target="_parent">FAQ</a>
-<li><a href="relnotes.html" target="_parent">Release Notes</a>
-<li><a href="thanks.html" target="_parent">Acknowledgements</a>
-<li><a href="conform.html" target="_parent">Conformance Testing</a>
-<li>more docs below...
-</ul>
-
-<b>Download / Install</b>
-<ul>
-<li><a href="download.html" target="_parent">Downloading / Unpacking</a>
-<li><a href="install.html" target="_parent">Compiling / Installing</a>
-  <ul>
-    <li><a href="autoconf.html" target="_parent">Autoconf</a></li>
-  </ul>
-</li>
-<li><a href="precompiled.html" target="_parent">Precompiled Libraries</a>
-</ul>
-
-<b>Resources</b>
-<ul>
-<li><a href="lists.html" target="_parent">Mailing Lists</a>
-<li><a href="bugs.html" target="_parent">Bug Database</a>
-<li><a href="webmaster.html" target="_parent">Webmaster</a>
-<li><a href="http://dri.freedesktop.org/" target="_parent">Mesa/DRI Wiki</a>
-</ul>
-
-<b>User Topics</b>
-<ul>
-<li><a href="shading.html" target="_parent">Shading Language</a>
-<li><a href="egl.html" target="_parent">EGL</a>
-<li><a href="opengles.html" target="_parent">OpenGL ES</a>
-<li><a href="openvg.html" target="_parent">OpenVG / Vega</a>
-<li><a href="envvars.html" target="_parent">Environment Variables</a>
-<li><a href="osmesa.html" target="_parent">Off-Screen Rendering</a>
-<li><a href="debugging.html" target="_parent">Debugging Tips</a>
-<li><a href="perf.html" target="_parent">Performance Tips</a>
-<li><a href="extensions.html" target="_parent">Mesa Extensions</a>
-<li><a href="mangling.html" target="_parent">Function Name Mangling</a>
-<li><a href="llvmpipe.html" target="_parent">Gallium llvmpipe driver</a>
-<li><a href="vmware-guest.html" target="_parent">VMware SVGA3D guest driver</a>
-<li><a href="postprocess.html" target="_parent">Gallium post-processing</a>
-<li><a href="viewperf.html" target="_parent">Viewperf Issues</a>
-</ul>
-
-<b>Developer Topics</b>
-<ul>
-<li><a href="repository.html" target="_parent">Source Code Repository</a>
-<li><a href="sourcetree.html" target="_parent">Source Code Tree</a>
-<li><a href="utilities.html" target="_parent">Utilities</a>
-<li><a href="helpwanted.html" target="_parent">Help Wanted</a>
-<li><a href="devinfo.html" target="_parent">Development Notes</a>
-<li><a href="sourcedocs.html" target="_parent">Source Documentation</a>
-<li><a href="dispatch.html" target="_parent">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>
-</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,47 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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>
-
-</div>
-</body>
-</html>

docs/developers.html

@@ -1,58 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<h1>Developers</h1>
-
-<p>
-Both professional and volunteer developers contribute to Mesa.
-</p>
-<p>
-<a href="http://www.vmware.com/">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">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/">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>
-
-</div>
-</body>
-</html>

docs/devinfo.html

@@ -1,277 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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>Marking a commit as a candidate for a stable branch</h2>
-
-<p>
-If you want a commit to be applied to a stable branch,
-you should add an appropriate note to the commit message.
-</p>
-
-<p>
-Here are some examples of such a note:
-</p>
-<ul>
-  <li>NOTE: This is a candidate for the 9.0 branch.</li>
-  <li>NOTE: This is a candidate for the 8.0 and 9.0 branches.</li>
-  <li>NOTE: This is a candidate for the stable branches.</li>
-</ul>
-
-
-<h2>Cherry-picking candidates for a stable branch</h2>
-
-<p>
-Please use <code>git cherry-pick -x &lt;commit&gt;</code> for cherry-picking a commit
-from master to a stable branch.
-</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>Makefile.am</dt>
-  <dd>PACKAGE_VERSION</dd>
-  <dt>configure.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="index.html">docs/index.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>
-
-</div>
-</body>
-</html>

docs/dispatch.html

@@ -1,279 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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>HAVE_PTHREAD</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>
-
-</div>
-</body>
-</html>

docs/download.html

@@ -1,117 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<h1>Downloading</h1>
-
-<p>
-Primary Mesa download site:
-<a href="ftp://ftp.freedesktop.org/pub/mesa/">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/">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/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, GLUT, and GLU</h1>
-
-<p>
-A package of SGI's GLU library is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/glu/">here</a>
-</p>
-
-<p>
-A package of Mark Kilgard's GLUT library is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/glut/">here</a>
-</p>
-
-<p>
-The Mesa demos collection is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/demos/">here</a>
-</p>
-
-<p>
-In the past, GLUT, GLU and the Mesa demos were released in conjunction with
-Mesa releases.  But since GLUT, GLU and the demos change infrequently, they
-were split off into their own git repositories:
-
-<a href="http://cgit.freedesktop.org/mesa/glut/">GLUT</a>,
-<a href="http://cgit.freedesktop.org/mesa/glu/">GLU</a> and
-<a href="http://cgit.freedesktop.org/mesa/demos/">Demos</a>,
-</p>
-
-</div>
-</body>
-</html>

docs/egl.html

@@ -1,345 +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>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<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/">
-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>
-
-<dl>
-<dt><code>--enable-egl</code></dt>
-<dd>
-
-<p>By default, EGL is enabled.  When disabled, the main library and the drivers
-will not be built.</p>
-
-</dd>
-
-<dt><code>--with-egl-driver-dir</code></dt>
-<dd>
-
-<p>The directory EGL drivers should be installed to.  If not specified, EGL
-drivers will be installed to <code>${libdir}/egl</code>.</p>
-
-</dd>
-
-<dt><code>--enable-gallium-egl</code></dt>
-<dd>
-
-<p>Enable the optional <code>egl_gallium</code> driver.</p>
-
-</dd>
-
-<dt><code>--with-egl-platforms</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>--enable-gles1</code></dt>
-<dt><code>--enable-gles2</code></dt>
-<dd>
-
-<p>These options enable OpenGL ES support in OpenGL.  The result is one big
-internal library that supports multiple APIs.</p>
-
-</dd>
-
-<dt><code>--enable-shared-glapi</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>--enable-openvg</code></dt>
-<dd>
-
-<p>OpenVG must be explicitly enabled by this option.</p>
-
-</dd>
-
-</dl>
-
-<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>
-
-<dl>
-<dt><code>EGL_DRIVERS_PATH</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>EGL_DRIVER</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>EGL_PLATFORM</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>EGL_LOG_LEVEL</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>EGL_SOFTWARE</code></dt>
-<dd>
-
-<p>For drivers that support both hardware and software rendering, setting this
-variable to true forces the use of software rendering.</p>
-
-</dd>
-</dl>
-
-<h2>EGL Drivers</h2>
-
-<dl>
-<dt><code>egl_dri2</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>egl_gallium</code></dt>
-<dd>
-
-<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>
-
-</dd>
-
-<dt><code>egl_glx</code></dt>
-<dd>
-
-<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>
-</dd>
-</dl>
-
-<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.
-
-</div>
-</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
-

docs/envvars.html

@@ -1,196 +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>Environment Variables</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<h1>Environment Variables</h1>
-
-<p>
-Normally, no environment variables need to be set.  Most of the environment
-variables used by Mesa/Gallium are for debugging purposes, but they can
-sometimes be useful for debugging end-user issues.
-</p>
-
-
-<h2>LibGL environment variables</h2>
-
-<ul>
-<li>LIBGL_DEBUG - If defined debug information will be printed to stderr.
-   If set to 'verbose' additional information will be printed.
-<li>LIBGL_DRIVERS_PATH - colon-separated list of paths to search for DRI drivers
-<li>LIBGL_ALWAYS_INDIRECT - forces an indirect rendering context/connection.
-<li>LIBGL_ALWAYS_SOFTWARE - if set, always use software rendering
-<li>LIBGL_NO_DRAWARRAYS - if set do not use DrawArrays GLX protocol (for debugging)
-</ul>
-
-
-
-<h2>Core Mesa environment variables</h2>
-
-<ul>
-<li>MESA_NO_ASM - if set, disables all assembly language optimizations
-<li>MESA_NO_MMX - if set, disables Intel MMX optimizations
-<li>MESA_NO_3DNOW - if set, disables AMD 3DNow! optimizations
-<li>MESA_NO_SSE - if set, disables Intel SSE optimizations
-<li>MESA_DEBUG - if set, error messages are printed to stderr.  For example,
-   if the application generates a GL_INVALID_ENUM error, a corresponding error
-   message indicating where the error occured, and possibly why, will be
-   printed to stderr.<br>
-   If the value of MESA_DEBUG is 'FP' floating point arithmetic errors will
-   generate exceptions.
-<li>MESA_LOG_FILE - specifies a file name for logging all errors, warnings,
-etc., rather than stderr
-<li>MESA_TEX_PROG - if set, implement conventional texture env modes with
-fragment programs (intended for developers only)
-<li>MESA_TNL_PROG - if set, implement conventional vertex transformation
-operations with vertex programs (intended for developers only).
-Setting this variable automatically sets the MESA_TEX_PROG variable as well.
-<li>MESA_EXTENSION_OVERRIDE - can be used to enable/disable extensions.
-A value such as "GL_EXT_foo -GL_EXT_bar" will enable the GL_EXT_foo extension
-and disable the GL_EXT_bar extension.
-<li>MESA_EXTENSION_MAX_YEAR - The GL_EXTENSIONS string returned by Mesa is sorted
-by extension year.
-If this variable is set to year X, only extensions defined on or before year
-X will be reported.
-This is to work-around a bug in some games where the extension string is
-copied into a fixed-size buffer without truncating.
-If the extension string is too long, the buffer overrun can cause the game
-to crash.
-This is a work-around for that.
-<li>MESA_GL_VERSION_OVERRIDE - changes the value returned by
-glGetString(GL_VERSION) and possibly the GL API type.
-<ul>
-<li> The format should be MAJOR.MINOR[FC]
-<li> FC is an optional suffix that indicates a forward compatible context.
-This is only valid for versions &gt;= 3.0.
-<li> GL versions &lt; 3.0 are set to a compatibility (non-Core) profile
-<li> GL versions = 3.0, see below
-<li> GL versions &gt; 3.0 are set to a Core profile
-<li> Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC
-<ul>
-<li> 2.1 - select a compatibility (non-Core) profile with GL version 2.1
-<li> 3.0 - select a compatibility (non-Core) profile with GL version 3.0
-<li> 3.0FC - select a Core+Forward Compatible profile with GL version 3.0
-<li> 3.1 - select a Core profile with GL version 3.1
-<li> 3.1FC - select a Core+Forward Compatible profile with GL version 3.1
-</ul>
-<li> Mesa may not really implement all the features of the given version.
-(for developers only)
-</ul>
-<li>MESA_GLSL_VERSION_OVERRIDE - changes the value returned by
-glGetString(GL_SHADING_LANGUAGE_VERSION). Valid values are integers, such as
-"130".  Mesa will not really implement all the features of the given language version
-if it's higher than what's normally reported. (for developers only)
-<li>MESA_GLSL - <a href="shading.html#envvars">shading language compiler options</a>
-</ul>
-
-
-<h2>Mesa Xlib driver environment variables</h2>
-
-<p>
-The following are only applicable to the Mesa Xlib software driver.
-See the <a href="xlibdriver.html">Xlib software driver page</a> for details.
-</p>
-<ul>
-<li>MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode
-<li>MESA_CI_VISUAL - specifies the X visual and depth for CI mode
-<li>MESA_BACK_BUFFER - specifies how to implement the back color buffer,
-    either "pixmap" or "ximage"
-<li>MESA_GAMMA - gamma correction coefficients for red, green, blue channels
-<li>MESA_XSYNC - enable synchronous X behavior (for debugging only)
-<li>MESA_GLX_FORCE_CI - if set, force GLX to treat 8bpp visuals as CI visuals
-<li>MESA_GLX_FORCE_ALPHA - if set, forces RGB windows to have an alpha channel.
-<li>MESA_GLX_DEPTH_BITS - specifies default number of bits for depth buffer.
-<li>MESA_GLX_ALPHA_BITS - specifies default number of bits for alpha channel.
-</ul>
-
-
-<h2>i945/i965 driver environment variables (non-Gallium)</h2>
-
-<ul>
-<li>INTEL_STRICT_CONFORMANCE - if set to 1, enable sw fallbacks to improve
-    OpenGL conformance.  If set to 2, always use software rendering.
-<li>INTEL_NO_BLIT - if set, disable hardware-accelerated glBitmap,
-    glCopyPixels, glDrawPixels.
-</ul>
-
-
-<h2>Radeon driver environment variables (radeon, r200, and r300g)</h2>
-
-<ul>
-<li>RADEON_NO_TCL - if set, disable hardware-accelerated Transform/Clip/Lighting.
-</ul>
-
-
-<h2>EGL environment variables</h2>
-
-<p>
-Mesa EGL supports different sets of environment variables.  See the
-<a href="egl.html">Mesa EGL</a> page for the details.
-</p>
-
-
-<h2>Gallium environment variables</h2>
-
-<ul>
-<li>GALLIUM_LOG_FILE - specifies a file for logging all errors, warnings, etc.
-    rather than stderr.
-<li>GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium environment
-    variables which are used, and their current values.
-<li>GALLIUM_NOSSE - if non-zero, do not use SSE runtime code generation for
-    shader execution
-<li>GALLIUM_NOPPC - if non-zero, do not use PPC runtime code generation for
-    shader execution
-<li>GALLIUM_DUMP_CPU - if non-zero, print information about the CPU on start-up
-<li>TGSI_PRINT_SANITY - if set, do extra sanity checking on TGSI shaders and
-    print any errors to stderr.
-<LI>DRAW_FSE - ???
-<LI>DRAW_NO_FSE - ???
-<li>DRAW_USE_LLVM - if set to zero, the draw module will not use LLVM to execute
-    shaders, vertex fetch, etc.
-</ul>
-
-<h3>Softpipe driver environment variables</h3>
-<ul>
-<li>SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment shaders
-    to stderr
-<li>SOFTPIPE_DUMP_GS - if set, the softpipe driver will print geometry shaders
-    to stderr
-<li>SOFTPIPE_NO_RAST - if set, rasterization is no-op'd.  For profiling purposes.
-<li>SOFTPIPE_USE_LLVM - if set, the softpipe driver will try to use LLVM JIT for
-    vertex shading procesing.
-</ul>
-
-
-<h3>LLVMpipe driver environment variables</h3>
-<ul>
-<li>LP_NO_RAST - if set LLVMpipe will no-op rasterization
-<li>LP_DEBUG - a comma-separated list of debug options is acceptec.  See the
-    source code for details.
-<li>LP_PERF - a comma-separated list of options to selectively no-op various
-    parts of the driver.  See the source code for details.
-<li>LP_NUM_THREADS - an integer indicating how many threads to use for rendering.
-    Zero turns of threading completely.  The default value is the number of CPU
-    cores present.
-</ul>
-
-
-<p>
-Other Gallium drivers have their own environment variables.  These may change
-frequently so the source code should be consulted for details.
-</p>
-
-</div>
-</body>
-</html>

docs/extensions.html

@@ -1,43 +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 Extensions</title>
-  <link rel="stylesheet" type="text/css" href="mesa.css">
-</head>
-<body>
-
-<div class="header">
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
-
-<iframe src="contents.html"></iframe>
-<div class="content">
-
-<h1>Mesa Extensions</h1>
-
-<p>
-A number of extensions have been developed especially for Mesa.
-The specifications follow.
-</p>
-
-
-<ul>
-<li><a href="MESA_agp_offset.spec">MESA_agp_offset.spec</a>
-<li><a href="MESA_copy_sub_buffer.spec">MESA_copy_sub_buffer.spec</a>
-<li><a href="MESA_packed_depth_stencil.spec">MESA_packed_depth_stencil.spec</a>
-<li><a href="MESA_pack_invert.spec">MESA_pack_invert.spec</a>
-<li><a href="MESA_pixmap_colormap.spec">MESA_pixmap_colormap.spec</a>
-<li><a href="MESA_release_buffers.spec">MESA_release_buffers.spec</a>
-<li><a href="MESA_resize_buffers.spec">MESA_resize_buffers.spec</a>
-<li><a href="MESA_set_3dfx_mode.spec">MESA_set_3dfx_mode.spec</a>
-<li><a href="MESA_sprite_point.spec">MESA_sprite_point.spec</a> (obsolete)
-<li><a href="MESA_texture_signed_rgba.spec">MESA_texture_signed_rgba.spec</a>
-<li><a href="MESA_trace.spec">MESA_trace.spec</a> (obsolete)
-<li><a href="MESA_window_pos.spec">MESA_window_pos.spec</a>
-<li><a href="MESA_ycbcr_texture.spec">MESA_ycbcr_texture.spec</a>
-</ul>
-
-</div>
-</body>
-</html>