Merge head into branch

broken?

.dir-locals.el

@@ -1,12 +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)))
-  )
- (makefile-mode (indent-tabs-mode . t))
- )

.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,66 +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
-
-MESA_VERSION=$(shell cat $(MESA_TOP)/VERSION)
-# define ANDROID_VERSION (e.g., 4.0.x => 0x0400)
-LOCAL_CFLAGS += \
-	-DPACKAGE_VERSION=\"$(MESA_VERSION)\" \
-	-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\" \
-	-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,100 +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 ilo 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 ilo 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/loader \
-	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.DJ

@@ -0,0 +1,108 @@
+# Mesa 3-D graphics library
+# Version:  4.0
+# 
+# Copyright (C) 1999  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+# DOS/DJGPP makefile v1.4 for Mesa
+#
+#  Copyright (C) 2002 - Borca Daniel
+#  Email : dborca@users.sourceforge.net
+#  Web   : http://www.geocities.com/dborca
+
+
+#
+#  Available options:
+#
+#    Environment variables:
+#	CPU		optimize for the given processor.
+#			default = pentium
+#	GLU=[mesa|sgi]	specify GLU directory; can be `sgi' (requires GNU/C++)
+#			or `mesa'.
+#			default = mesa
+#	GLIDE		path to Glide3 SDK; used with FX.
+#			default = $(TOP)/glide3
+#	FX=1		build for 3dfx Glide3. Note that this disables
+#			compilation of most DMesa code and requires fxMesa.
+#			As a consequence, you'll need the DJGPP Glide3
+#			library to build any application.
+#			default = no
+#	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.
+#			This is experimental and not intensively tested.
+#			default = no
+#	HAVE_X86=1	optimize for i386.
+#			default = no
+#	HAVE_MMX=1	allow MMX specializations, provided your assembler
+#			supports MMX instruction set. However, the true CPU
+#			capabilities are checked at run-time to avoid crashes.
+#			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
+#
+
+
+
+.PHONY : all libgl libglu libglut clean realclean
+
+CPU ?= pentium
+
+GLU ?= mesa
+
+CFLAGS = -Wall -W -pedantic
+CFLAGS += -O2 -ffast-math -mcpu=$(CPU)
+
+export CFLAGS
+
+ifeq ($(wildcard $(addsuffix /rm.exe,$(subst ;, ,$(PATH)))),)
+UNLINK = del $(subst /,\,$(1))
+else
+UNLINK = $(RM) $(1)
+endif
+
+all: libgl libglu libglut
+
+libgl: lib
+	$(MAKE) -f Makefile.DJ -C src/mesa
+libglu: lib
+	$(MAKE) -f Makefile.DJ -C src/glu/$(GLU)
+libglut: lib
+	$(MAKE) -f Makefile.DJ -C src/glut/dos
+
+lib:
+	mkdir lib
+
+clean:
+	$(MAKE) -f Makefile.DJ clean -C src/mesa
+	$(MAKE) -f Makefile.DJ clean -C src/glu/mesa
+	$(MAKE) -f Makefile.DJ clean -C src/glu/sgi
+	$(MAKE) -f Makefile.DJ clean -C src/glut/dos
+
+realclean: clean
+	-$(call UNLINK,lib/*.a)
+	-$(call UNLINK,lib/*.dxe)

Makefile.X11

@@ -0,0 +1,622 @@
+# $Id: Makefile.X11,v 1.89.2.1 2003/11/24 12:01:39 keithw Exp $
+
+# Mesa 3-D graphics library
+# Version:  5.1
+# 
+# Copyright (C) 1999-2003  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 beos-r4               for BeOS R4"
+	@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 freebsd               for FreeBSD systems with GCC"
+	@echo "  make freebsd-386           for FreeBSD systems with GCC, w/ Intel assembly"
+	@echo "  make gcc-sl                for a generic system with GCC for shared libs"
+	@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 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"
+	@echo "  make linux-x86             for Linux with x86 optimizations"
+	@echo "  make linux-ggi             for Linux with libggi driver"
+	@echo "  make linux-x86-ggi         for Linux with libggi driver and x86 optimizations"
+	@echo "  make linux-glide           for Linux with 3Dfx Glide driver"
+	@echo "  make linux-x86-glide       for Linux with 3Dfx Glide driver and x86 opts"
+	@echo "  make linux-alpha           for Linux with Alpha optimizations"
+	@echo "  make linux-alpha-static    for Linux with Alpha opts, make static libs"
+	@echo "  make linux-ppc             for Linux with PowerPC opts"
+	@echo "  make linux-ppc-static      for Linux with PowerPC opts, make static libs"
+	@echo "  make linux-sparc           for Linux with Sparc optimzations"
+	@echo "  make linux-sparc5          for Linux with Sparc5 optimizations"
+	@echo "  make linux-sparc-ultra     for Linux with UltraSparc optimizations"
+	@echo "  make linux-osmesa16        for 16-bit/channel OSMesa"
+	@echo "  make linux-osmesa16-static for 16-bit/channel OSMesa, make static libs"
+	@echo "  make linux-osmesa32        for 32-bit/channel OSMesa"
+	@echo "  make linux-solo            for Linux standalone with dri drivers"
+	@echo "  make linux-icc             for Linux with the Intel C/C++ compiler"
+	@echo "  make lynxos                for LynxOS systems with GCC"
+	@echo "  make mklinux               for Linux on Power Macintosh"
+	@echo "  make netbsd                for NetBSD 1.0 systems with GCC"
+	@echo "  make openbsd               for OpenBSD systems"
+	@echo "  make openstep              for OpenStep/MacOSX Server systems"
+	@echo "  make osf1                  for DEC Alpha systems with OSF/1"
+	@echo "  make qnx                   for QNX V4 systems with Watcom compiler"
+	@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-smp            for Suns with SunOS 5.x, SMP optimization"
+	@echo "  make sunos5-gcc            for Suns with SunOS 5.x and GCC"
+	@echo "  make ultrix-gcc            for DEC systems with Ultrix and GCC"
+	@echo "  make unixware              for PCs running UnixWare"
+	@echo "  make unixware-shared       for PCs running UnixWare, shared libs"
+	@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 darwin freebsd freebsd-386 gcc-sl \
+hpux9 hpux9-sl hpux9-gcc hpux9-gcc-sl \
+hpux10 hpux10-sl hpux10-gcc hpux10-gcc-sl \
+linux linux-debug \
+linux-x86 linux-x86-sse linux-icc linux-x86-static linux-x86-debug \
+linux-glide linux-x86-glide linux-glide-debug \
+linux-alpha-static linux-alpha \
+linux-ppc-static linux-ppc \
+linux-sparc linux-sparc5 linux-sparc-ultra \
+mklinux netbsd osf1 openbsd qnx \
+solaris-x86 solaris-x86-gcc \
+sunos4 sunos4-sl sunos4-gcc sunos4-gcc-sl sunos4-gcc-x11r6-sl \
+sunos5 sunos5-smp sunos5-gcc \
+ultrix-gcc unixware:
+	-mkdir lib
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glu/sgi  ] ; then touch src/glu/sgi/depend  ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw      ] ; then touch src/glw/depend      ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx  ] ; then cd src/glut/glx  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw       ] ; then cd src/glw       ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+gcc-mesa-sl:
+	if [ -d src ] ; then cd src  ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+irix6-o32 irix6-o32-dso irix6-n32 irix6-n32-dso irix6-gcc-n32-sl:
+	-mkdir lib32
+	if [ -d src/mesa      ] ; then touch src/mesa/depend      ; fi
+	if [ -d src/glu/sgi   ] ; then touch src/glu/sgi/depend   ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw ] ; then touch src/glw/depend ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx ] ; then cd src/glut/glx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos    ] ; then cd progs/demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos   ] ; then cd progs/xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples  ] ; then cd progs/samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook     ] ; then cd progs/redbook     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(MAKE) -f Makefile.X11 $@ ; fi
+
+irix6-64 irix6-64-dso:
+	-mkdir lib64
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glu/sgi  ] ; then touch src/glu/sgi/depend  ; fi
+	if [ -d src/glut/glx ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw      ] ; then touch src/glw/depend      ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx  ] ; then cd src/glut/glx  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(MAKE) -f Makefile.X11 $@ ; fi
+
+
+beos-r4:
+	-mkdir lib
+	-rm src/mesa/depend
+	touch src/mesa/depend
+	-rm src/glu/sgi/depend
+	touch src/glu/sgi/depend
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glu/sgi   ] ; then cd src/glu/sgi   ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glut/beos ] ; then cd src/glut/beos ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d src/glut/beos ] ; then cp src/glut/beos/obj*/libglut.so lib  ; fi
+	if [ -d progs/beos    ] ; then cd progs/beos    ; $(MAKE)                        ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
+
+cygnus cygnus-linux:
+	-mkdir lib
+	touch src/depend
+	touch src-glu/depend
+	if [ -d src/mesa     ] ; then cd src/mesa     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi  ] ; then cd src/glu/sgi  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx ] ; then cd src/glut/glx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos  ] ; then cd progs/demos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos ] ; then cd progs/xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw      ] ; then cd src/glw      ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+openstep:
+	-mkdir lib
+	cd src/mesa    ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+	cd src/glu/sgi ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
+
+linux-ggi linux-x86-ggi:
+	-mkdir lib
+	touch src/depend
+	touch src/glu/sgi/depend
+	if [ -d src/glut/glx    ] ; then touch src/glut/glx/depend ; fi
+	if [ -d src/glw         ] ; then touch src/glw/depend ; fi
+	if [ -d src/mesa        ] ; then cd src            ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/sgi     ] ; then cd src/glu/sgi    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/glx    ] ; then cd src/glut/glx   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d ggi/demos       ] ; then cd ggi/demos      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos     ] ; then cd progs/demos    ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos    ] ; then cd progs/xdemos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples   ] ; then cd progs/samples  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook   ] ; then cd progs/redbook  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glw ] ; then cd src/glw; $(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-x86-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-osmesa16-static linux-osmesa32:
+	-mkdir lib
+	if [ -d src/mesa ] ; then touch src/mesa/depend ; fi
+	if [ -d src/mesa ] ; then cd src/mesa ; $(MAKE) -f Makefile.OSMesa16 $@ ; fi
+
+linux-solo:
+	-mkdir lib
+	if [ -d src/mesa     ] ; then touch src/mesa/depend     ; fi
+	if [ -d src/glx/mini ] ; then touch src/glx/mini/depend  ; fi
+	if [ -d src/glu/mini ] ; then touch src/glu/mini/depend  ; fi
+	if [ -d src/glut/mini ] ; then touch src/glut/mini/depend  ; fi
+	if [ -d src/mesa/drivers/dri/r200 ] ; then touch src/mesa/drivers/dri/r200/depend ; fi
+	if [ -d src/mesa/drivers/dri/r128 ] ; then touch src/mesa/drivers/dri/r128/depend ; fi
+	if [ -d src/mesa/drivers/dri/radeon ] ; then touch src/mesa/drivers/dri/radeon/depend ; fi
+	if [ -d src/mesa/drivers/dri/mga ] ; then touch src/mesa/drivers/dri/mga/depend ; fi
+	if [ -d src/mesa/drivers/dri/i810 ] ; then touch src/mesa/drivers/dri/i810/depend ; fi
+	if [ -d src/mesa/drivers/dri/i830 ] ; then touch src/mesa/drivers/dri/i830/depend ; fi
+	if [ -d src/mesa/drivers/dri/sis ] ; then touch src/mesa/drivers/dri/sis/depend ; fi
+	if [ -d src/mesa/drivers/dri/gamma ] ; then touch src/mesa/drivers/dri/gamma/depend ; fi
+	if [ -d src/mesa/drivers/dri/fb ] ; then touch src/mesa/drivers/dri/fb/depend ; fi
+	if [ -d src/glut/mini ] ; then touch src/glut/mini/depend ; fi
+	if [ -d progs/miniglx ] ; then touch progs/miniglx/depend ; fi
+	if [ -d progs/tests ] ; then touch progs/tests/depend ; fi
+	if [ -d src/mesa      ] ; then cd src/mesa      ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/r200 ] ; then cd src/mesa/drivers/dri/r200     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/r128 ] ; then cd src/mesa/drivers/dri/r128     ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/radeon ] ; then cd src/mesa/drivers/dri/radeon ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/mga ] ; then cd src/mesa/drivers/dri/mga       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/i810 ] ; then cd src/mesa/drivers/dri/i810       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/i830 ] ; then cd src/mesa/drivers/dri/i830       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/sis ] ; then cd src/mesa/drivers/dri/sis       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/gamma ] ; then cd src/mesa/drivers/dri/gamma       ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/mesa/drivers/dri/fb ] ; then cd src/mesa/drivers/dri/fb         ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glx/mini  ] ; then cd src/glx/mini  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glu/mini  ] ; then cd src/glu/mini  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d src/glut/mini ] ; then cd src/glut/mini ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/miniglx ] ; then cd progs/miniglx ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/tests   ] ; then cd progs/tests   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/demos   ] ; then cd progs/demos   ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/xdemos  ] ; then cd progs/xdemos  ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/samples ] ; then cd progs/samples ; $(MAKE) -f Makefile.X11 $@ ; fi
+	if [ -d progs/redbook ] ; then cd progs/redbook ; $(MAKE) -f Makefile.X11 $@ ; fi
+
+# Remove .o files, emacs backup files, etc.
+clean:
+	if ! [ -f src/mesa/depend      ] ; then touch src/mesa/depend      ; fi
+	if ! [ -f src/mesa/drivers/dri/r200/depend ];   then touch src/mesa/drivers/dri/r200/depend;   fi
+	if ! [ -f src/mesa/drivers/dri/r128/depend ];   then touch src/mesa/drivers/dri/r128/depend;   fi
+	if ! [ -f src/mesa/drivers/dri/radeon/depend ]; then touch src/mesa/drivers/dri/radeon/depend; fi
+	if ! [ -f src/mesa/drivers/dri/mga/depend ];    then touch src/mesa/drivers/dri/mga/depend;    fi
+	if ! [ -f src/mesa/drivers/dri/fb/depend ];     then touch src/mesa/drivers/dri/fb/depend;     fi
+	if ! [ -f src/glu/mesa/depend  ] ; then touch src/glu/mesa/depend  ; fi
+	if ! [ -f src/glu/sgi/depend   ] ; then touch src/glu/sgi/depend   ; fi
+	if ! [ -f src/glu/mini/depend  ] ; then touch src/glu/mini/depend  ; fi
+	if ! [ -f src/glut/glx/depend  ] ; then touch src/glut/glx/depend  ; fi
+	if ! [ -f src/glut/mini/depend ] ; then touch src/glut/mini/depend ; fi
+	if ! [ -f src/glx/mini/depend  ] ; then touch src/glx/mini/depend  ; fi
+	if ! [ -f progs/tests/depend   ] ; then touch progs/tests/depend   ; fi
+	if ! [ -f progs/miniglx/depend ] ; then touch progs/miniglx/depend ; fi
+	-rm -f include/GL/*~
+	cd src/mesa          && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/r200   && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/r128   && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/radeon && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/mga    && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/mesa/drivers/dri/fb     && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/mesa      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/sgi       && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glu/mini      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glut/glx      && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glut/mini     && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glw           && $(MAKE) -f Makefile.X11 $@ || true
+	cd src/glx/mini      && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/demos       && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/redbook     && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/xdemos      && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/samples     && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/tests       && $(MAKE) -f Makefile.X11 $@ || true
+	cd progs/miniglx     && $(MAKE) -f Makefile.X11 $@ || true
+	if [ -f src/mesa/depend      ] ; then rm src/mesa/depend      ; fi
+	if [ -f src/mesa/drivers/dri/r200/depend ];   then rm -f src/mesa/drivers/dri/r200/depend;   fi
+	if [ -f src/mesa/drivers/dri/r128/depend ];   then rm -f src/mesa/drivers/dri/r128/depend;   fi
+	if [ -f src/mesa/drivers/dri/radeon/depend ]; then rm -f src/mesa/drivers/dri/radeon/depend; fi
+	if [ -f src/mesa/drivers/dri/mga/depend ];    then rm -f src/mesa/drivers/dri/mga/depend;    fi
+	if [ -f src/mesa/drivers/dri/fb/depend ];     then rm -f src/mesa/drivers/dri/fb/depend;     fi
+	if [ -f src/glu/mesa/depend  ] ; then rm -f src/glu/mesa/depend  ; fi
+	if [ -f src/glu/sgi/depend   ] ; then rm -f src/glu/sgi/depend   ; fi
+	if [ -f src/glu/mini/depend  ] ; then rm -f src/glu/mini/depend  ; fi
+	if [ -f src/glut/glx/depend  ] ; then rm -f src/glut/glx/depend  ; fi
+	if [ -f src/glut/mini/depend ] ; then rm -f src/glut/mini/depend ; fi
+	if [ -f src/glx/mini/depend  ] ; then rm -f src/glx/mini/depend  ; fi
+	if [ -f progs/tests/depend   ] ; then rm -f progs/tests/depend   ; fi
+	if [ -f progs/miniglx/depend ] ; then rm -f progs/miniglx/depend ; fi
+
+# Remove everything that can be remade
+realclean: clean
+	-rm -fr lib lib32 lib64
+	cd progs/demos       && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/xdemos      && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/redbook     && $(MAKE) -f Makefile.X11 realclean || true
+	cd progs/samples     && $(MAKE) -f Makefile.X11 realclean || true
+
+# Remove everything not in CVS
+cvsclean: realclean
+	-rm -f acinclude.m4 aclocal.m4
+	-rm -f conf.h conf.h.in config.guess config.log config.status
+	-rm -f config.sub configure
+	-rm -f install-sh libtool ltmain.sh Makefile.in
+	-rm -f missing mkinstalldirs stamp-h stamp-h.in
+
+
+
+
+DIRECTORY = Mesa-5.1
+LIB_NAME = MesaLib-5.1
+DEMO_NAME = MesaDemos-5.1
+GLU_NAME = MesaGLU-5.1
+GLUT_NAME = GLUT-3.7
+
+
+LIB_FILES =	\
+	$(DIRECTORY)/Makefile*						\
+	$(DIRECTORY)/Make-config					\
+	$(DIRECTORY)/descrip.mms					\
+	$(DIRECTORY)/mms-config.					\
+	$(DIRECTORY)/Mesa.dsw						\
+	$(DIRECTORY)/bin/mklib*						\
+	$(DIRECTORY)/docs/*.html					\
+	$(DIRECTORY)/docs/COPYING					\
+	$(DIRECTORY)/docs/INSTALL.GNU					\
+	$(DIRECTORY)/docs/README.*					\
+	$(DIRECTORY)/docs/RELNOTES*					\
+	$(DIRECTORY)/docs/VERSIONS					\
+	$(DIRECTORY)/docs/*.spec					\
+	$(DIRECTORY)/include/GL/internal/glcore.h			\
+	$(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)/src/mesa/Makefile*					\
+	$(DIRECTORY)/src/mesa/descrip.mms				\
+	$(DIRECTORY)/src/mesa/depend					\
+	$(DIRECTORY)/src/mesa/main/*.[chS]				\
+	$(DIRECTORY)/src/mesa/main/main.dsp				\
+	$(DIRECTORY)/src/mesa/glapi/*.[chS]				\
+	$(DIRECTORY)/src/mesa/glapi/glapi.dsp				\
+	$(DIRECTORY)/src/mesa/array_cache/*.[ch]			\
+	$(DIRECTORY)/src/mesa/array_cache/array_cache.dsp		\
+	$(DIRECTORY)/src/mesa/math/*.[ch]				\
+	$(DIRECTORY)/src/mesa/math/math.dsp				\
+	$(DIRECTORY)/src/mesa/swrast/*.[ch]				\
+	$(DIRECTORY)/src/mesa/swrast/swrast.dsp				\
+	$(DIRECTORY)/src/mesa/swrast_setup/*.[ch]			\
+	$(DIRECTORY)/src/mesa/swrast_setup/swrast_setup.dsp		\
+	$(DIRECTORY)/src/mesa/tnl/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl/tnl.dsp				\
+	$(DIRECTORY)/src/mesa/tnl_dd/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl_dd/imm/*.[ch]				\
+	$(DIRECTORY)/src/mesa/tnl_dd/imm/NOTES.imm			\
+	$(DIRECTORY)/src/mesa/drivers/common/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/dos/*.[chS]			\
+	$(DIRECTORY)/src/mesa/drivers/dos/mga/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/beos/*.cpp			\
+	$(DIRECTORY)/src/mesa/drivers/glide/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/glide/*.def			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/ggimesa.conf.in		\
+	$(DIRECTORY)/src/mesa/drivers/ggi/default/*.c			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/default/genkgi.conf.in	\
+	$(DIRECTORY)/src/mesa/drivers/ggi/display/*.c			\
+	$(DIRECTORY)/src/mesa/drivers/ggi/display/fbdev.conf.in		\
+	$(DIRECTORY)/src/mesa/drivers/ggi/include/ggi/mesa/*.h		\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/Makefile.win		\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.def			\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.dsp			\
+	$(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/svga/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch]			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.def			\
+	$(DIRECTORY)/src/mesa/drivers/windows/*/*.dsp			\
+	$(DIRECTORY)/src/mesa/drivers/x11/*.[ch]			\
+	$(DIRECTORY)/src/mesa/sparc/*.[chS]				\
+	$(DIRECTORY)/src/mesa/x86/*.[ch]				\
+	$(DIRECTORY)/src/mesa/x86/*.S					\
+	$(DIRECTORY)/src/glu/sgi/Makefile.X11				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.win				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.DJ				\
+	$(DIRECTORY)/src/glu/sgi/cc*.txt				\
+	$(DIRECTORY)/src/glu/sgi/glu.def				\
+	$(DIRECTORY)/src/glu/sgi/glu.dsp				\
+	$(DIRECTORY)/src/glu/sgi/dummy.cc				\
+	$(DIRECTORY)/src/glu/sgi/descrip.mms				\
+	$(DIRECTORY)/src/glu/sgi/mesaglu.opt				\
+	$(DIRECTORY)/src/glu/sgi/include/gluos.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.cc		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.cc		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbtess/*.h			\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbtess/*.cc			\
+	$(DIRECTORY)/src/glu/sgi/libtess/README				\
+	$(DIRECTORY)/src/glu/sgi/libtess/alg-outline			\
+	$(DIRECTORY)/src/glu/sgi/libtess/*.[ch]				\
+	$(DIRECTORY)/src/glu/sgi/libutil/*.[ch]				\
+	$(DIRECTORY)/src/glu/mesa/README[12]				\
+	$(DIRECTORY)/src/glu/mesa/Makefile*				\
+	$(DIRECTORY)/src/glu/mesa/descrip.mms				\
+	$(DIRECTORY)/src/glu/mesa/mms_depend				\
+	$(DIRECTORY)/src/glu/mesa/*.def					\
+	$(DIRECTORY)/src/glu/mesa/depend				\
+	$(DIRECTORY)/src/glu/mesa/*.[ch]				\
+	$(DIRECTORY)/src/glw/*.[ch]					\
+	$(DIRECTORY)/src/glw/Makefile*					\
+	$(DIRECTORY)/src/glw/README					\
+	$(DIRECTORY)/progs/util/README					\
+	$(DIRECTORY)/progs/util/*.[ch]					\
+	$(DIRECTORY)/progs/util/sampleMakefile				\
+	$(DIRECTORY)/vms/analyze_map.com				\
+	$(DIRECTORY)/vms/xlib.opt					\
+	$(DIRECTORY)/vms/xlib_share.opt
+
+
+DEMO_FILES =	\
+	$(DIRECTORY)/include/GL/glut.h			\
+	$(DIRECTORY)/include/GL/glutf90.h		\
+	$(DIRECTORY)/src/glut/glx/Makefile*		\
+	$(DIRECTORY)/src/glut/glx/depend		\
+	$(DIRECTORY)/src/glut/glx/*def			\
+	$(DIRECTORY)/src/glut/glx/descrip.mms		\
+	$(DIRECTORY)/src/glut/glx/mms_depend		\
+	$(DIRECTORY)/src/glut/glx/glut.dsp		\
+	$(DIRECTORY)/src/glut/glx/*.[ch]		\
+	$(DIRECTORY)/src/glut/dos/*.[ch]		\
+	$(DIRECTORY)/src/glut/dos/Makefile.DJ		\
+	$(DIRECTORY)/src/glut/dos/PC_HW/*.[chS]		\
+	$(DIRECTORY)/progs/images/*			\
+	$(DIRECTORY)/progs/demos/Makefile*		\
+	$(DIRECTORY)/progs/demos/descrip.mms		\
+	$(DIRECTORY)/progs/demos/*.[ch]			\
+	$(DIRECTORY)/progs/demos/*.cxx			\
+	$(DIRECTORY)/progs/demos/*.dat			\
+	$(DIRECTORY)/progs/demos/README			\
+	$(DIRECTORY)/progs/demos/Windows/*		\
+	$(DIRECTORY)/progs/xdemos/Makefile*		\
+	$(DIRECTORY)/progs/xdemos/descrip.mms		\
+	$(DIRECTORY)/progs/xdemos/*.[chf]		\
+	$(DIRECTORY)/progs/redbook/Makefile*		\
+	$(DIRECTORY)/progs/redbook/README		\
+	$(DIRECTORY)/progs/redbook/*.[ch]		\
+	$(DIRECTORY)/progs/samples/Makefile*		\
+	$(DIRECTORY)/progs/samples/README		\
+	$(DIRECTORY)/progs/samples/*.c			\
+	$(DIRECTORY)/progs/windml/Makefile.ugl		\
+	$(DIRECTORY)/progs/windml/*.c			\
+	$(DIRECTORY)/progs/windml/*.bmp			\
+	$(DIRECTORY)/progs/ggi/*.c
+
+SI_GLU_FILES = \
+	$(DIRECTORY)/Makefile*					\
+	$(DIRECTORY)/Make-config				\
+	$(DIRECTORY)/bin/mklib*					\
+	$(DIRECTORY)/include/GL/glu.h				\
+	$(DIRECTORY)/src/glu/sgi/Makefile.X11			\
+	$(DIRECTORY)/src/glu/sgi/include/gluos.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/interface/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/internals/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbstess/*.h		\
+	$(DIRECTORY)/src/glu/sgi/libnurbs/nurbstess/*.cc	\
+	$(DIRECTORY)/src/glu/sgi/libtess/README			\
+	$(DIRECTORY)/src/glu/sgi/libtess/alg-outline		\
+	$(DIRECTORY)/src/glu/sgi/libtess/*.[ch]			\
+	$(DIRECTORY)/src/glu/sgi/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/mesa/README[12]	\
+	$(DIRECTORY)/src/glu/mesa/Makefile*	\
+	$(DIRECTORY)/src/glu/mesa/descrip.mms	\
+	$(DIRECTORY)/src/glu/mesa/mms_depend	\
+	$(DIRECTORY)/src/glu/mesa/*.def		\
+	$(DIRECTORY)/src/glu/mesa/depend	\
+	$(DIRECTORY)/src/glu/mesa/*.[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/glx/Makefile*	\
+	$(DIRECTORY)/src/glut/glx/depend	\
+	$(DIRECTORY)/src/glut/glx/*def		\
+	$(DIRECTORY)/src/glut/glx/descrip.mms	\
+	$(DIRECTORY)/src/glut/glx/mms_depend	\
+	$(DIRECTORY)/src/glut/glx/*.[ch]
+
+
+
+lib_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
+	gzip $(LIB_NAME).tar ; \
+	mv $(LIB_NAME).tar.gz $(DIRECTORY)
+
+demo_gz:
+	cd .. ; \
+	tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
+	gzip $(DEMO_NAME).tar ; \
+	mv $(DEMO_NAME).tar.gz $(DIRECTORY)
+
+lib_bz2:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
+	bzip2 $(LIB_NAME).tar ; \
+	mv $(LIB_NAME).tar.bz2 $(DIRECTORY)
+
+demo_bz2:
+	cd .. ; \
+	tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
+	bzip2 $(DEMO_NAME).tar ; \
+	mv $(DEMO_NAME).tar.bz2 $(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)
+
+md5:
+	@-md5sum $(LIB_NAME).tar.gz
+	@-md5sum $(LIB_NAME).tar.bz2
+	@-md5sum $(LIB_NAME).zip
+	@-md5sum $(DEMO_NAME).tar.gz
+	@-md5sum $(DEMO_NAME).tar.bz2
+	@-md5sum $(DEMO_NAME).zip
+
+# Everything for new Mesa release:
+tarballs: lib_gz demo_gz lib_bz2 demo_bz2 lib_zip demo_zip md5
+
+
+# not used
+glu_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLU_NAME).tar $(GLU_FILES) ; \
+	gzip $(GLU_NAME).tar ; \
+	mv $(GLU_NAME).tar.gz $(DIRECTORY)
+
+glut_gz:
+	cp Makefile.X11 Makefile ; \
+	cd .. ; \
+	tar -cvf $(GLUT_NAME).tar $(GLUT_FILES) ; \
+	gzip $(GLUT_NAME).tar ; \
+	mv $(GLUT_NAME).tar.gz $(DIRECTORY)

Makefile.am

@@ -1,106 +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)
-
-.PHONY: doxygen
-
-# Rules for making release tarballs
-
-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					\
-        bin/test-driver					\
-	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/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/program_parse.tab.c program/program_parse.tab.h
-
-# Everything for new a Mesa release:
-ARCHIVES = $(PACKAGE_NAME).tar.gz \
-	$(PACKAGE_NAME).tar.bz2 \
-	$(PACKAGE_NAME).zip
-
-tarballs: md5
-	rm -f ../$(PACKAGE_DIR) $(PACKAGE_NAME).tar
-
-manifest.txt: .git
-	( \
-		ls -1 $(EXTRA_FILES) ; \
-		git ls-files $(IGNORE_FILES) \
-	) | sed -e '/^\(.*\/\)\?\./d' -e "s@^@$(PACKAGE_DIR)/@" > $@
-
-../$(PACKAGE_DIR):
-	ln -s $(PWD) $@
-
-$(PACKAGE_NAME).tar: parsers ../$(PACKAGE_DIR) manifest.txt
-	cd .. ; tar -cf $(PACKAGE_DIR)/$(PACKAGE_NAME).tar -T $(PACKAGE_DIR)/manifest.txt
-
-$(PACKAGE_NAME).tar.gz: $(PACKAGE_NAME).tar ../$(PACKAGE_DIR)
-	gzip --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.gz
-
-$(PACKAGE_NAME).tar.bz2: $(PACKAGE_NAME).tar
-	bzip2 --stdout --best $(PACKAGE_NAME).tar > $(PACKAGE_NAME).tar.bz2
-
-$(PACKAGE_NAME).zip: parsers ../$(PACKAGE_DIR) manifest.txt
-	rm -f $(PACKAGE_NAME).zip ; \
-	cd .. ; \
-	zip -q -@ $(PACKAGE_NAME).zip < $(PACKAGE_DIR)/manifest.txt ; \
-	mv $(PACKAGE_NAME).zip $(PACKAGE_DIR)
-
-md5: $(ARCHIVES)
-	@-md5sum $(PACKAGE_NAME).tar.gz
-	@-md5sum $(PACKAGE_NAME).tar.bz2
-	@-md5sum $(PACKAGE_NAME).zip
-
-.PHONY: tarballs md5

Makefile.mgw

@@ -0,0 +1,91 @@
+# Mesa 3-D graphics library
+# Version:  4.0
+# 
+# Copyright (C) 1999  Brian Paul   All Rights Reserved.
+# 
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+# 
+# The above copyright notice and this permission notice shall be included
+# in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+# MinGW makefile v1.0 for Mesa
+#
+#  Copyright (C) 2002 - Borca Daniel
+#  Email : dborca@users.sourceforge.net
+#  Web   : http://www.geocities.com/dborca
+
+
+#
+#  Available options:
+#
+#    Environment variables:
+#	CPU		optimize for the given processor.
+#			default = pentium
+#	GLIDE		path to Glide3 SDK; used with FX.
+#			default = $(TOP)/glide3
+#	FX=1		build for 3dfx Glide3. Note that this disables
+#			compilation of most WMesa code and requires fxMesa.
+#			As a consequence, you'll need the Win32 Glide3
+#			library to build any application.
+#			default = no
+#	HAVE_X86=1	optimize for i386.
+#			default = no
+#	HAVE_MMX=1	allow MMX specializations, provided your assembler
+#			supports MMX instruction set. However, the true CPU
+#			capabilities are checked at run-time to avoid crashes.
+#			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
+#	clean:		remove object files
+#	realclean:	remove all generated files
+#
+
+
+
+.PHONY : all libgl clean realclean
+
+CPU ?= pentium
+
+CFLAGS = -Wall -W -pedantic
+CFLAGS += -O2 -ffast-math -mcpu=$(CPU)
+
+export CFLAGS
+
+ifeq ($(wildcard $(addsuffix /rm.exe,$(subst ;, ,$(PATH)))),)
+UNLINK = del $(subst /,\,$(1))
+else
+UNLINK = $(RM) $(1)
+endif
+
+all: libgl
+
+libgl: lib
+	$(MAKE) -f Makefile.mgw -C src/mesa
+
+lib:
+	mkdir lib
+
+clean:
+	$(MAKE) -f Makefile.mgw clean -C src/mesa
+
+realclean: clean
+	-$(call UNLINK,lib/*.a)
+	-$(call UNLINK,lib/*.dll)

Makefile.wfx

@@ -0,0 +1,87 @@
+# Mesa 3-D graphics library
+# Version:  5.1
+#
+# Copyright (C) 1999-2003  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.
+
+# Win32/FX makefile for Mesa
+#
+#  Copyright (c) 2003 - Hiroshi Morii
+#  Email : koolsmoky@users.sourceforge.net
+#  URL   : http://www.3dfxzone.it/koolsmoky
+
+# Debug build                : nmake -f Makefile.wfx debug
+# Optimized build            : nmake -f Makefile.wfx
+# Remove objects             : nmake -f Makefile.wfx clean
+# Remove files in bin, lib   : nmake -f Makefile.wfx clobber
+# Remove all generated files : nmake -f Makefile.wfx realclean
+
+# Build the libs
+SUBDIRS	  = src\mesa.dir
+DBGBUILD  = $(SUBDIRS:.dir=.debug)
+CLEAN	  = $(SUBDIRS:.dir=.clean)
+CLOBBER	  = $(SUBDIRS:.dir=.clobber)
+REALCLEAN = $(SUBDIRS:.dir=.realclean)
+LIBDIR    = lib
+
+# default rule
+default	  : $(LIBDIR) $(SUBDIRS)
+
+# debug build rules
+debug     : $(LIBDIR) $(DBGBUILD)
+
+# cleanup rules
+clean	  : $(CLEAN)
+clobber	  : $(CLOBBER)
+realclean : $(REALCLEAN)
+
+# inference rules
+$(LIBDIR):
+	@echo.
+	@mkdir $(LIBDIR)
+
+$(SUBDIRS):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx
+	@cd ..
+
+$(DBGBUILD):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx DEBUG=1
+	@cd ..
+
+$(CLEAN):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx clean
+	@cd ..
+
+$(CLOBBER):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx clobber
+	@cd ..
+
+$(REALCLEAN):
+	@echo.
+	@cd $*
+	@nmake -f Makefile.wfx realclean
+	@cd ..

Mesa.dsw

@@ -0,0 +1,179 @@
+Microsoft Developer Studio Workspace File, Format Version 6.00
+# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
+
+###############################################################################
+
+Project: "array_cache"=".\SRC\MESA\array_cache\array_cache.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "gdi"=".\src\mesa\drivers\windows\gdi\gdi.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name array_cache
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name main
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name math
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name swrast_setup
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name swrast
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name tnl
+    End Project Dependency
+    Begin Project Dependency
+    Project_Dep_Name glapi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "glapi"=".\SRC\MESA\glapi\glapi.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "glu"=".\src\glu\sgi\glu.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name gdi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "glut"=".\src\glut\glx\glut.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name glu
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "main"=".\SRC\MESA\main\main.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "math"=".\SRC\MESA\math\math.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "osmesa"=".\SRC\MESA\DRIVERS\osmesa\osmesa.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+    Begin Project Dependency
+    Project_Dep_Name gdi
+    End Project Dependency
+}}}
+
+###############################################################################
+
+Project: "swrast"=".\SRC\MESA\swrast\swrast.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "swrast_setup"=".\SRC\MESA\swrast_setup\swrast_setup.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Project: "tnl"=".\SRC\MESA\tnl\tnl.dsp" - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+}}}
+
+###############################################################################
+
+Global:
+
+Package=<5>
+{{{
+}}}
+
+Package=<3>
+{{{
+}}}
+
+###############################################################################
+

SConstruct

@@ -1,155 +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))
-
-#######################################################################
-# Environment setup
-
-with open("VERSION") as f:
-  mesa_version = f.read().strip()
-env.Append(CPPDEFINES = [
-    ('PACKAGE_VERSION', '\\"%s\\"' % mesa_version),
-    ('PACKAGE_BUGREPORT', '\\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\\"'),
-])
-
-# Includes
-env.Prepend(CPPPATH = [
-	'#/include',
-])
-env.Append(CPPPATH = [
-	'#/src/gallium/include',
-	'#/src/gallium/auxiliary',
-	'#/src/gallium/drivers',
-	'#/src/gallium/winsys',
-])
-
-# 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
-
-    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)

VERSION

@@ -1 +0,0 @@
-10.2.4

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,7 +0,0 @@
-# The first is the change, and the second is the revert of that change.
-e6967270c75a5b669152127bb7a746d55f4407a6 i965: Fix depth (array slices) computation for 1D_ARRAY render targets.
-155f98d49fdc2f46c760f8214327b3804ee60079 Revert "i965: Fix depth (array slices) computation for 1D_ARRAY render targets."
-
-# This patch didn't have enough in the commit message to convince me it
-# is a bug fix, (email sent to author asking for more information).
-41d759d076737f94976f5294b734dbc437a12bae

bin/.gitignore

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

bin/bugzilla_mesa.sh

@@ -1,52 +0,0 @@
-#!/bin/bash
-
-# This script is used to generate the list of fixed bugs that
-# appears in the release notes files, with HTML formatting.
-#
-# Note: This script could take a while until all details have
-#       been fetched from bugzilla.
-#
-# Usage examples:
-#
-# $ bin/bugzilla_mesa.sh mesa-9.0.2..mesa-9.0.3
-# $ bin/bugzilla_mesa.sh mesa-9.0.2..mesa-9.0.3 > bugfixes
-# $ bin/bugzilla_mesa.sh mesa-9.0.2..mesa-9.0.3 | tee bugfixes
-# $ DRYRUN=yes bin/bugzilla_mesa.sh mesa-9.0.2..mesa-9.0.3
-# $ DRYRUN=yes bin/bugzilla_mesa.sh mesa-9.0.2..mesa-9.0.3 | wc -l
-
-
-# regex pattern: trim before url
-trim_before='s/.*\(http\)/\1/'
-
-# regex pattern: trim after url
-trim_after='s/\(show_bug.cgi?id=[0-9]*\).*/\1/'
-
-# regex pattern: always use https
-use_https='s/http:/https:/'
-
-# extract fdo urls from commit log
-urls=$(git log $* | grep 'bugs.freedesktop.org/show_bug' | sed -e $trim_before -e $trim_after -e $use_https | sort | uniq)
-
-# if DRYRUN is set to "yes", simply print the URLs and don't fetch the
-# details from fdo bugzilla.
-#DRYRUN=yes
-
-if [ "x$DRYRUN" = xyes ]; then
-	for i in $urls
-	do
-		echo $i
-	done
-else
-	echo "<ul>"
-	echo ""
-
-	for i in $urls
-	do
-		id=$(echo $i | cut -d'=' -f2)
-		summary=$(wget --quiet -O - $i | grep -e '<title>.*</title>' | sed -e 's/ *<title>Bug [0-9]\+ &ndash; \(.*\)<\/title>/\1/')
-		echo "<li><a href=\"$i\">Bug $id</a> - $summary</li>"
-		echo ""
-	done
-
-	echo "</ul>"
-fi

bin/get-pick-list.sh

@@ -1,35 +0,0 @@
-#!/bin/sh
-
-# Script for generating a list of candidates for cherry-picking to a stable branch
-#
-# Usage examples:
-#
-# $ bin/get-pick-list.sh
-# $ bin/get-pick-list.sh > picklist
-# $ bin/get-pick-list.sh | tee picklist
-
-# 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\|CC:.*mesa-stable\)' 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

@@ -0,0 +1,351 @@
+#!/bin/sh
+
+# Make a shared library.
+# Basically do a switch/case depending on the OS and make a shared
+# lib conforming to that OS.
+
+
+# Usage:
+#   mklib [options] objects ...
+# Options:
+#   -o LIBRARY    specifies the name of resulting library ("GL" for example)
+#   -major N      specifies major version number (default is 1)
+#   -minor N      specifies minor version number (default is 0)
+#   -patch N      specifies patch version number (default is 0)
+#   -lLIBRARY     specifies a dependency on LIBRARY
+#   -LDIR         search in DIR for library dependencies
+#   -cplusplus    link with C++ runtime
+#   -static       make a static library (default is dynamic/shared)
+#   -install DIR  move resulting library files to DIR
+#   -arch ARCH    override using `uname` to determine architecture
+#   -archopt OPT  specify an extra achitecture-specific option OPT
+#
+# The library name should just be "GL" or "GLU", etc.  The 'lib' prefix
+# will be added here if needed, as well as the ".so" or ".a" suffix, etc.
+#
+# objects should be:  foo.o bar.o etc.o
+#
+# Environment variables recognized:
+#   CC   C compiler command
+#   CXX  C++ compiler command
+#
+
+
+#
+# Option defaults
+#
+LIBNAME=""
+MAJOR=1
+MINOR=0
+PATCH=0
+DEPS=""
+CPLUSPLUS=0
+STATIC=0
+INSTALLDIR="."
+ARCH="auto"
+ARCHOPT=""
+
+
+#
+# Parse arguments
+#
+while true
+do
+    case $1 in
+	'-o')         shift 1; LIBNAME=$1;;
+	'-major')     shift 1; MAJOR=$1;;
+	'-minor')     shift 1; MINOR=$1;;
+	'-patch')     shift 1; PATCH=$1;;
+	-l*)          DEPS="$DEPS $1";;
+	-L*)          DEPS="$DEPS $1";;
+	'-cplusplus') CPLUSPLUS=1;;
+	'-static')    STATIC=1;;
+	'-install')   shift 1; INSTALLDIR=$1;;
+	'-arch')      shift 1; ARCH=$1;;
+	'-archopt')   shift 1; ARCHOPT=$1;;
+	-*)           echo "mklib: Unknown option: " $1 ; exit 1;;
+	*) break
+    esac
+    shift 1
+done
+OBJECTS=$@
+
+if [ ${ARCH} = "auto" ] ; then
+    ARCH=`uname`
+fi
+
+
+#
+# Error checking
+#
+if [ "x${LIBNAME}" = "x" ] ; then
+    echo "mklib: Error: no library name specified"
+    exit 1
+fi
+if [ "x${OBJECTS}" = "x" ] ; then
+    echo "mklib: Error: no object files specified"
+    exit 1
+fi
+
+
+#
+# Debugging info
+#
+if [  ]  ; then
+    echo "-----------------"
+    echo ARCH is $ARCH
+    echo LIBNAME is $LIBNAME
+    echo MAJOR is $MAJOR
+    echo MINOR is $MINOR
+    echo PATCH is $PATCH
+    echo DEPS are $DEPS
+    echo "-----------------"
+fi
+
+
+#
+# OK, make the library now
+#
+case $ARCH in
+
+    'Linux')
+	LIBNAME="lib${LIBNAME}"     # prefix with "lib"
+
+        if [ $STATIC = 1 ] ; then
+            echo "mklib: Making Linux static library: " ${LIBNAME}.a
+            LINK="ar"
+            OPTS="-ruv"
+            # make lib
+            ${LINK} ${OPTS} ${LIBNAME}.a ${OBJECTS}
+            # finish up
+            FINAL_LIBS="${LIBNAME}.a"
+        else
+            OPTS="-Xlinker -Bsymbolic -shared -Wl,-soname,${LIBNAME}.so.${MAJOR}"
+            VERSION="${MAJOR}.${MINOR}.${PATCH}"
+
+            echo "mklib: Making Linux shared library: " ${LIBNAME}.so.${VERSION}
+
+            if [ $CPLUSPLUS = 1 ] ; then
+                LINK="g++"
+            else
+                LINK="gcc"
+            fi
+
+            # rm any old libs
+            rm -f ${LIBNAME}.so.${VERSION}
+            rm -f ${LIBNAME}.so.${MAJOR}
+            rm -f ${LIBNAME}.so
+
+            # make lib
+            ${LINK} ${OPTS} -o ${LIBNAME}.so.${VERSION} ${OBJECTS} ${DEPS}
+            # make usual symlinks
+            ln -s ${LIBNAME}.so.${VERSION} ${LIBNAME}.so.${MAJOR}
+            ln -s ${LIBNAME}.so.${MAJOR} ${LIBNAME}.so
+            # finish up
+            FINAL_LIBS="${LIBNAME}.so.${VERSION} ${LIBNAME}.so.${MAJOR} ${LIBNAME}.so"
+        fi
+	;;
+
+    'SunOS')
+	LIBNAME="lib${LIBNAME}.so"
+	echo "mklib: Making SunOS shared library: " ${LIBNAME}
+	OPTS="-G"
+	if [ $CPLUSPLUS = 1 ] ; then
+	    # link for C++
+	    if [ "x${CXX}" = "xg++" ] ; then
+		LINK="g++"
+	    elif [ "x${CXX}" = "xCC" ] ; then
+		LINK="CC"
+	    elif [ `which c++` ] ; then
+		LINK="c++"
+	    elif [ `type g++` ] ; then
+		LINK="g++"
+	    else
+		echo "mklib: warning: can't find C++ comiler, trying CC."
+		LINK="CC"
+	    fi
+	elif [ "x${CC}" = "xgcc" ] ; then
+	    # use gcc for linking
+	    LINK="gcc"
+	else
+	    # use native Sun linker
+	    LINK="ld"
+	fi
+	echo "mklib: linker is " ${LINK}
+	rm -f ${LIBNAME}
+	${LINK} ${OPTS} -o ${LIBNAME} ${OBJECTS} ${DEPS}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'FreeBSD')
+	SHLIB="lib${LIBNAME}.so.${MAJOR}.${MINOR}"
+	STLIB="lib${LIBNAME}.a"
+	echo "mklib: Making FreeBSD shared library: " ${SHLIB}
+	rm -f ${SHLIB} ${STLIB}
+	ar cq ${STLIB} ${OBJECTS}
+	ranlib ${STLIB}
+	ld -Bshareable -o ${SHLIB} ${OBJECTS}
+	# XXX make lib${LIBNAME}.so.${MAJOR} symlink?
+	FINAL_LIBS="${SHLIB} ${STLIB}"
+	;;
+
+    'OpenBSD')
+	LIBNAME="lib${LIBNAME}"
+	VERSION="${MAJOR}.${MINOR}"
+	echo "Building OpenBSD PIC library: " ${LIBNAME}
+	rm -f ${LIBNAME}_pic.a ${LIBNAME}.so.${VERSION}
+	ar cq ${LIBNAME}_pic.a ${OBJECTS}
+	ranlib ${LIBNAME}_pic.a
+	ld -x -Bshareable -Bforcearchive -o ${LIBNAME}.so.${VERSION} ${LIBNAME}_pic.a
+	ln -s ${LIBNAME}.so.${VERSION} ${LIBNAME}.so
+	FINAL_LIBS="${LIBNAME}_pic.a ${LIBNAME}.so.${VERSION} ${LIBNAME}.so"
+	;;
+
+    'NetBSD')
+	LIBNAME="lib${LIBNAME}"
+	echo "mklib: Making NetBSD PIC shared library: " ${LIBNAME}
+	VERSION="${MAJOR}.${MINOR}"
+	rm -f ${LIBNAME}_pic.a ${LIBNAME}.so.${VERSION}
+	ar cq ${LIBNAME}_pic.a ${OBJECTS}
+	ranlib ${LIBNAME}_pic.a
+	ld -x -Bshareable -Bforcearchive -o ${LIBNAME}.so.${VERSION} ${LIBNAME}_pic.a
+	FINAL_LIBS="${LIBNAME}_pic.a ${LIBNAME}.so.${VERSION}"
+	;;
+
+    'IRIX')
+	LIBNAME="lib${LIBNAME}.so"  # prefix with "lib", suffix with ".so"
+	if [ $ARCHOPTS = "64" ] ; then
+	    # 64-bit ABI
+	    OPTS="-64 -shared -all"
+	    echo "mklib: Making IRIX 64-bit shared library: " ${LIBNAME}
+	elif [ $ARCHOPTS = "o32" ] ; then
+	    # old 32-bit ABI
+	    OPTS="-32 -shared -all"
+	    echo "mklib: Making IRIX o32-bit shared library: " ${LIBNAME}
+	else
+	    # new 32-bit ABI
+	    OPTS="-n32 -shared -all"
+	    echo "mklib: Making IRIX n32-bit shared library: " ${LIBNAME}
+	fi
+	ld ${OPTS} -o ${LIBNAME} ${OBJECTS} ${DEPS}
+	FINAL_LIBS="${LIBNAME}"
+	;;
+
+    'IRIX64')
+	LIBNAME="lib${LIBNAME}.so"  # prefix with "lib", suffix with ".so"
+	echo "mklib: Making IRIX64 library: " ${LIBNAME}
+	# 64-bit ABI
+	OPTS="-64 -shared -all"
+	ld ${OPTS} -o ${LIBNAME} ${OBJECTS} ${DEPS}
+	FINAL_LIBS="${LIBNAME}"
+	;;
+
+    'linux-cygwin')
+	LIBNAME="lib${LIBNAME}.a"
+	echo "mklib: Making linux-cygwin library: " ${LIBNAME}
+	gnuwin32ar ruv ${LIBNAME} ${OBJECTS}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'HPUX')
+	RUNLIB="lib${LIBNAME}.${MAJOR}"
+	DEVLIB="lib${LIBNAME}.sl"
+	echo "mklib: Making HPUX library: " ${RUNLIB} ${DEVLIB}
+	ld -b -o ${RUNLIB} +b ${RUNLIB} ${OBJECTS} ${DEPS}
+	ln -s ${RUNLIB} ${DEVLIB}
+	FINAL_LIBS="{RUNLIB} ${DEVLIB}"
+	;;
+
+    'OpenSTEP')
+	LIBNAME="lib${LIBNAME}.a"
+	echo "mklib: Making OpenSTEP static library: " ${LIBNAME}
+	libtool -static -o ${LIBNAME} - ${OBJECTS}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'OSF1')
+	VERSION="${MAJOR}.${MINOR}"
+	LIBNAME="lib${LIBNAME}.so"
+	ARNAME="lib${LIBNAME}.a"
+	echo "mklib: Making OSF/1 library: " ${LIBNAME}
+	rm -f ${LIBNAME}.${VERSION}
+	ld -o ${LIBNAME}.${VERSION} -shared -no_archive -set_version ${VERSION} -soname ${LIBNAME}.${VERSION} -expect_unresolved \* -all ${OBJECTS} ${DEPS}
+	ln -sf ${LIBNAME}.${VERSION} ${LIBNAME}
+
+	# also make static lib
+	rm -f ${ARNAME}
+	ar clqz ${ARNAME} ${OBJECTS}
+	FINAL_LIBS="${ARNAME} ${LIBNAME} ${LIBNAME}.${VERSION}"
+	;;
+
+    'Darwin')
+	VERSION="${MAJOR}.${MINOR}.${TINY}"
+	LIBNAME="lib${LIBNAME}.dylib"
+	ARNAME="lib${LIBNAME}.dylib.a"
+	echo "mklib: Making Darwin libraries: " ${LIBNAME} ${ARNAME}
+	FLAGS="-dynamiclib -multiply_defined suppress"
+	cc ${FLAGS} -o ${LIBNAME} ${OBJECTS} ${DEPS}
+	# also make regular .a files,
+	# provided by Danek Duvall (duvall@dhduvall.student.princeton.edu)
+	ar ruv ${ARNAME} ${OBJECTS}
+	ranlib ${ARNAME}
+	FINAL_LIBS="${ARNAME} ${LIBNAME}"
+	;;
+
+    'LynxOS')
+	LIBNAME="lib${LIBNAME}.a"
+	echo "mklib: Making LynxOS library: " ${LIBNAME}
+	ar ru ${LIBNAME} ${OBJECTS}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'BeOS')
+	LIBNAME="lib${LIBNAME}.so"
+	echo "mklib: Making BeOS shared library: " ${LIBNAME}
+	gcc -nostart -Xlinker -soname=${LIBNAME} -L/Be/develop/lib/x86 ${OBJECTS} -lbe -o ${LIBNAME}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'QNX')
+	LIBNAME="lib${LIBNAME}.a"
+	echo "mklib: Making QNX library: " ${LIBNAME}
+	wlib ${LIBNAME} ${OBJECTS}
+	FINAL_LIBS=${LIBNAME}
+	;;
+
+    'MorphOS')
+	LIBNAME="lib${LIBNAME}.a"
+	echo "mklib: Making MorphOS library: " ${LIBNAME}
+	ppc-morphos-ar rc ${LIBNAME} ${OBJECTS}
+	FINAL_LIBS="${LIBNAME}"
+	;;
+
+    'example')
+	# If you're adding support for a new architecture, you can
+	# start with this:
+	LIBNAME="lib${LIBNAME}.so"  # prefix with "lib"
+	echo "mklib: Making library for example arch: " ${LIBNAME}
+	ld -o ${LIBNAME} ${OBJECTS} ${DEPS}
+	FINAL_LIBS="${LIBNAME}"
+	;;
+
+    *)
+	echo "mklib: WARNING: making library for unknown platform!"
+	echo "mklib: WARNING: this may not work!"
+	echo "mklib: WARNING: please update the bin/mklib script!"
+	# XXX this is a total hack for Mesa - remove someday
+	# fall-back to an old mklib.* script
+	LIBNAME="lib${LIBNAME}.a"
+	${TOP}/${MAKELIB} "lib${LIBNAME}.a" ${MAJOR} ${MINOR} ${PATCH} ${OBJECTS}
+	FINAL_LIBS="${LIBNAME}"
+	;;
+esac
+
+
+#
+# Put library files into installation directory if specified.
+#
+if [ ${INSTALLDIR} != "." ] ; then
+    echo "mklib: Installing" ${FINAL_LIBS} "in" ${INSTALLDIR}
+    mv ${FINAL_LIBS} ${INSTALLDIR}/
+fi

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/perf-annotate-jit

@@ -1,251 +0,0 @@
-#!/usr/bin/env python
-#
-# Copyright 2012 VMware Inc
-# Copyright 2008-2009 Jose Fonseca
-#
-# 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.
-#
-
-"""Perf annotate for JIT code.
-
-Linux `perf annotate` does not work with JIT code.  This script takes the data
-produced by `perf script` command, plus the diassemblies outputed by gallivm
-into /tmp/perf-XXXXX.map.asm and produces output similar to `perf annotate`.
-
-See docs/llvmpipe.html for usage instructions.
-
-The `perf script` output parser was derived from the gprof2dot.py script.
-"""
-
-
-import sys
-import os.path
-import re
-import optparse
-import subprocess
-
-
-class Parser:
-    """Parser interface."""
-
-    def __init__(self):
-        pass
-
-    def parse(self):
-        raise NotImplementedError
-
-
-class LineParser(Parser):
-    """Base class for parsers that read line-based formats."""
-
-    def __init__(self, file):
-        Parser.__init__(self)
-        self._file = file
-        self.__line = None
-        self.__eof = False
-        self.line_no = 0
-
-    def readline(self):
-        line = self._file.readline()
-        if not line:
-            self.__line = ''
-            self.__eof = True
-        else:
-            self.line_no += 1
-        self.__line = line.rstrip('\r\n')
-
-    def lookahead(self):
-        assert self.__line is not None
-        return self.__line
-
-    def consume(self):
-        assert self.__line is not None
-        line = self.__line
-        self.readline()
-        return line
-
-    def eof(self):
-        assert self.__line is not None
-        return self.__eof
-
-
-mapFile = None
-
-def lookupMap(filename, matchSymbol):
-    global mapFile
-    mapFile = filename
-    stream = open(filename, 'rt')
-    for line in stream:
-        start, length, symbol = line.split()
-
-        start = int(start, 16)
-        length = int(length,16)
-
-        if symbol == matchSymbol:
-            return start
-
-    return None
-
-def lookupAsm(filename, desiredFunction):
-    stream = open(filename + '.asm', 'rt')
-    while stream.readline() != desiredFunction + ':\n':
-        pass
-
-    asm = []
-    line = stream.readline().strip()
-    while line:
-        addr, instr = line.split(':', 1)
-        addr = int(addr)
-        asm.append((addr, instr))
-        line = stream.readline().strip()
-
-    return asm
-
-
-
-samples = {}
-
-
-class PerfParser(LineParser):
-    """Parser for linux perf callgraph output.
-
-    It expects output generated with
-
-        perf record -g
-        perf script
-    """
-
-    def __init__(self, infile, symbol):
-        LineParser.__init__(self, infile)
-	self.symbol = symbol
-
-    def readline(self):
-        # Override LineParser.readline to ignore comment lines
-        while True:
-            LineParser.readline(self)
-            if self.eof() or not self.lookahead().startswith('#'):
-                break
-
-    def parse(self):
-        # read lookahead
-        self.readline()
-
-        while not self.eof():
-            self.parse_event()
-
-        asm = lookupAsm(mapFile, self.symbol)
-
-        addresses = samples.keys()
-        addresses.sort()
-        total_samples = 0
-
-	sys.stdout.write('%s:\n' % self.symbol)
-        for address, instr in asm:
-            try:
-                sample = samples.pop(address)
-            except KeyError:
-                sys.stdout.write(6*' ')
-            else:
-                sys.stdout.write('%6u' % (sample))
-                total_samples += sample
-            sys.stdout.write('%6u: %s\n' % (address, instr))
-        print 'total:', total_samples
-        assert len(samples) == 0
-
-        sys.exit(0)
-
-    def parse_event(self):
-        if self.eof():
-            return
-
-        line = self.consume()
-        assert line
-
-        callchain = self.parse_callchain()
-        if not callchain:
-            return
-
-    def parse_callchain(self):
-        callchain = []
-        while self.lookahead():
-            function = self.parse_call(len(callchain) == 0)
-            if function is None:
-                break
-            callchain.append(function)
-        if self.lookahead() == '':
-            self.consume()
-        return callchain
-
-    call_re = re.compile(r'^\s+(?P<address>[0-9a-fA-F]+)\s+(?P<symbol>.*)\s+\((?P<module>[^)]*)\)$')
-
-    def parse_call(self, first):
-        line = self.consume()
-        mo = self.call_re.match(line)
-        assert mo
-        if not mo:
-            return None
-
-        if not first:
-            return None
-
-        function_name = mo.group('symbol')
-        if not function_name:
-            function_name = mo.group('address')
-
-        module = mo.group('module')
-
-        function_id = function_name + ':' + module
-
-        address = mo.group('address')
-        address = int(address, 16)
-
-        if function_name != self.symbol:
-            return None
-
-        start_address = lookupMap(module, function_name)
-        address -= start_address
-
-        #print function_name, module, address
-
-        samples[address] = samples.get(address, 0) + 1
-
-        return True
-
-
-def main():
-    """Main program."""
-
-    optparser = optparse.OptionParser(
-        usage="\n\t%prog [options] symbol_name")
-    (options, args) = optparser.parse_args(sys.argv[1:])
-    if len(args) != 1:
-        optparser.error('wrong number of arguments')
-
-    symbol = args[0]
-
-    p = subprocess.Popen(['perf', 'script'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
-    parser = PerfParser(p.stdout, symbol)
-    parser.parse()
-
-
-if __name__ == '__main__':
-    main()
-
-
-# vim: set sw=4 et:

bin/shortlog_mesa.sh

@@ -1,29 +0,0 @@
-#!/bin/bash
-
-# This script is used to generate the list of changes that
-# appears in the release notes files, with HTML formatting.
-#
-# Usage examples:
-#
-# $ bin/shortlog_mesa.sh mesa-9.0.2..mesa-9.0.3
-# $ bin/shortlog_mesa.sh mesa-9.0.2..mesa-9.0.3 > changes
-# $ bin/shortlog_mesa.sh mesa-9.0.2..mesa-9.0.3 | tee changes
-
-
-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,104 +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(BoolOption('analyze', 'enable static code analysis where available', '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('MSVC_VERSION', 'Microsoft Visual C/C++ version')

descrip.mms

@@ -0,0 +1,21 @@
+# Makefile for Mesa for VMS
+# contributed by Jouk Jansen  joukj@hrem.stm.tudelft.nl
+
+macro : 
+        @ macro=""
+.ifdef NOSHARE
+.else
+	@ if f$getsyi("HW_MODEL") .ge. 1024 then macro= "/MACRO=(SHARE=1)"
+.endif
+	$(MMS)$(MMSQUALIFIERS)'macro' all
+
+all :
+	if f$search("lib.dir") .eqs. "" then create/directory [.lib]
+	set default [.src]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.progs.demos]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.xdemos]
+	$(MMS)$(MMSQUALIFIERS)
+	set default [-.tests]
+	$(MMS)$(MMSQUALIFIERS)

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,196 +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.
-
-
-OpenGL Core and Compatibility context support
-
-OpenGL 3.1 and later versions are only supported with the Core profile.
-There are no plans to support GL_ARB_compatibility. The last supported OpenGL
-version with all deprecated features is 3.0. Some of the later GL features
-are exposed in the 3.0 context as extensions.
-
-
-Feature                                               Status
------------------------------------------------------ ------------------------
-
-GL 3.0 --- all DONE: i965, nv50, nvc0, r600, radeonsi
-
-  GLSL 1.30                                             DONE ()
-  glBindFragDataLocation, glGetFragDataLocation         DONE
-  Conditional rendering (GL_NV_conditional_render)      DONE (r300, swrast)
-  Map buffer subranges (GL_ARB_map_buffer_range)        DONE (r300, swrast)
-  Clamping controls (GL_ARB_color_buffer_float)         DONE (r300)
-  Float textures, renderbuffers (GL_ARB_texture_float)  DONE (r300)
-  GL_EXT_packed_float                                   DONE ()
-  GL_EXT_texture_shared_exponent                        DONE (swrast)
-  Float depth buffers (GL_ARB_depth_buffer_float)       DONE ()
-  Framebuffer objects (GL_ARB_framebuffer_object)       DONE (r300, swrast)
-  GL_ARB_half_float_pixel                               DONE (all drivers)
-  GL_ARB_half_float_vertex                              DONE (r300, swrast)
-  GL_EXT_texture_integer                                DONE ()
-  GL_EXT_texture_array                                  DONE ()
-  Per-buffer blend and masks (GL_EXT_draw_buffers2)     DONE (swrast)
-  GL_EXT_texture_compression_rgtc                       DONE (r300, swrast)
-  GL_ARB_texture_rg                                     DONE (r300, swrast)
-  Transform feedback (GL_EXT_transform_feedback)        DONE ()
-  Vertex array objects (GL_ARB_vertex_array_object)     DONE (all drivers)
-  sRGB framebuffer format (GL_EXT_framebuffer_sRGB)     DONE ()
-  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
-  Multisample anti-aliasing                             DONE (r300)
-
-
-GL 3.1 --- all DONE: i965, nv50, nvc0, r600, radeonsi
-
-  GLSL 1.40                                             DONE ()
-  Forward compatible context support/deprecations       DONE ()
-  Instanced drawing (GL_ARB_draw_instanced)             DONE (swrast)
-  Buffer copying (GL_ARB_copy_buffer)                   DONE (r300, swrast)
-  Primitive restart (GL_NV_primitive_restart)           DONE (r300)
-  16 vertex texture image units                         DONE ()
-  Texture buffer objs (GL_ARB_texture_buffer_object)    DONE for OpenGL 3.1 contexts ()
-  Rectangular textures (GL_ARB_texture_rectangle)       DONE (r300, swrast)
-  Uniform buffer objs (GL_ARB_uniform_buffer_object)    DONE (swrast)
-  Signed normalized textures (GL_EXT_texture_snorm)     DONE (r300)
-
-
-GL 3.2 --- all DONE: i965, nv50, nvc0, r600, radeonsi
-
-  Core/compatibility profiles                           DONE
-  GLSL 1.50                                             DONE ()
-  Geometry shaders                                      DONE ()
-  BGRA vertex order (GL_ARB_vertex_array_bgra)          DONE (r300, swrast)
-  Base vertex offset(GL_ARB_draw_elements_base_vertex)  DONE (r300, swrast)
-  Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (r300, swrast)
-  Provoking vertex (GL_ARB_provoking_vertex)            DONE (r300, swrast)
-  Seamless cubemaps (GL_ARB_seamless_cube_map)          DONE ()
-  Multisample textures (GL_ARB_texture_multisample)     DONE ()
-  Frag depth clamp (GL_ARB_depth_clamp)                 DONE (swrast)
-  Fence objects (GL_ARB_sync)                           DONE (r300, swrast)
-  GLX_ARB_create_context_profile                        DONE
-
-
-GL 3.3 --- all DONE: i965, nv50, nvc0, r600, radeonsi
-
-  GLSL 3.30                                             DONE ()
-  GL_ARB_blend_func_extended                            DONE (softpipe)
-  GL_ARB_explicit_attrib_location                       DONE (all drivers that support GLSL)
-  GL_ARB_occlusion_query2                               DONE (r300, swrast)
-  GL_ARB_sampler_objects                                DONE (all drivers)
-  GL_ARB_shader_bit_encoding                            DONE ()
-  GL_ARB_texture_rgb10_a2ui                             DONE ()
-  GL_ARB_texture_swizzle                                DONE (r300, swrast)
-  GL_ARB_timer_query                                    DONE ()
-  GL_ARB_instanced_arrays                               DONE (r300)
-  GL_ARB_vertex_type_2_10_10_10_rev                     DONE ()
-
-
-GL 4.0:
-
-  GLSL 4.0                                             not started
-  GL_ARB_texture_query_lod                             DONE (i965, nv50, nvc0)
-  GL_ARB_draw_buffers_blend                            DONE (i965, nv50, nvc0, r600, radeonsi, softpipe)
-  GL_ARB_draw_indirect                                 DONE (i965)
-  GL_ARB_gpu_shader5                                   started
-  - 'precise' qualifier                                not started
-  - Dynamically uniform sampler array indices          not started
-  - Dynamically uniform UBO array indices              not started
-  - Implicit signed -> unsigned conversions            not started
-  - Fused multiply-add                                 DONE
-  - Packing/bitfield/conversion functions              DONE
-  - Enhanced textureGather                             DONE
-  - Geometry shader instancing                         DONE
-  - Geometry shader multiple streams                   not started
-  - Enhanced per-sample shading                        DONE
-  - Interpolation functions                            started
-  - New overload resolution rules                      not started
-  GL_ARB_gpu_shader_fp64                               not started
-  GL_ARB_sample_shading                                DONE (i965, nv50, nvc0)
-  GL_ARB_shader_subroutine                             not started
-  GL_ARB_tessellation_shader                           not started
-  GL_ARB_texture_buffer_object_rgb32                   DONE (i965, nvc0, r600, radeonsi, softpipe)
-  GL_ARB_texture_cube_map_array                        DONE (i965, nv50, nvc0, r600, softpipe)
-  GL_ARB_texture_gather                                DONE (i965, nv50, nvc0)
-  GL_ARB_transform_feedback2                           DONE (i965, nv50, nvc0, r600, radeonsi)
-  GL_ARB_transform_feedback3                           DONE (i965, nv50, nvc0, r600, radeonsi)
-
-
-GL 4.1:
-
-  GLSL 4.1                                             not started
-  GL_ARB_ES2_compatibility                             DONE (i965, nv50, nvc0, r300, r600, radeonsi)
-  GL_ARB_get_program_binary                            DONE (0 binary formats)
-  GL_ARB_separate_shader_objects                       DONE (all drivers)
-  GL_ARB_shader_precision                              not started
-  GL_ARB_vertex_attrib_64bit                           not started
-  GL_ARB_viewport_array                                DONE (i965, nv50, r600)
-
-
-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                        DONE (i965)
-  GL_ARB_texture_storage                               DONE (all drivers)
-  GL_ARB_transform_feedback_instanced                  DONE (i965, nv50, nvc0, r600, radeonsi)
-  GL_ARB_base_instance                                 DONE (i965, nv50, nvc0, r600, radeonsi)
-  GL_ARB_shader_image_load_store                       in progress (curro)
-  GL_ARB_conservative_depth                            DONE (all drivers that support GLSL 1.30)
-  GL_ARB_shading_language_420pack                      DONE (all drivers that support GLSL 1.30)
-  GL_ARB_internalformat_query                          DONE (i965, nv50, nvc0, r300, r600, radeonsi)
-  GL_ARB_map_buffer_alignment                          DONE (all drivers)
-
-
-GL 4.3:
-
-  GLSL 4.3                                             not started
-  GL_ARB_arrays_of_arrays                              started
-  GL_ARB_ES3_compatibility                             DONE (i965)
-  GL_ARB_clear_buffer_object                           DONE (all drivers)
-  GL_ARB_compute_shader                                started (Paul Berry)
-  GL_ARB_copy_image                                    not started
-  GL_KHR_debug                                         DONE (all drivers)
-  GL_ARB_explicit_uniform_location                     not started
-  GL_ARB_fragment_layer_viewport                       not started
-  GL_ARB_framebuffer_no_attachments                    not started
-  GL_ARB_internalformat_query2                         not started
-  GL_ARB_invalidate_subdata                            DONE (all drivers)
-  GL_ARB_multi_draw_indirect                           DONE (i965)
-  GL_ARB_program_interface_query                       not started
-  GL_ARB_robust_buffer_access_behavior                 not started
-  GL_ARB_shader_image_size                             not started
-  GL_ARB_shader_storage_buffer_object                  not started
-  GL_ARB_stencil_texturing                             DONE (i965/gen8+)
-  GL_ARB_texture_buffer_range                          DONE (nv50, nvc0, i965, r600, radeonsi)
-  GL_ARB_texture_query_levels                          DONE (i965)
-  GL_ARB_texture_storage_multisample                   DONE (all drivers that support GL_ARB_texture_multisample)
-  GL_ARB_texture_view                                  DONE (i965)
-  GL_ARB_vertex_attrib_binding                         DONE (all drivers)
-
-
-GL 4.4:
-
-  GLSL 4.4                                             not started
-  GL_MAX_VERTEX_ATTRIB_STRIDE                          not started
-  GL_ARB_buffer_storage                                DONE (i965, nv30, nv50, nvc0, r300, r600, radeonsi)
-  GL_ARB_clear_texture                                 not started
-  GL_ARB_enhanced_layouts                              not started
-  GL_ARB_multi_bind                                    DONE (all drivers)
-  GL_ARB_query_buffer_object                           not started
-  GL_ARB_texture_mirror_clamp_to_edge                  DONE (i965, nv30, nv50, nvc0, r300, r600, radeonsi, swrast)
-  GL_ARB_texture_stencil8                              not started
-  GL_ARB_vertex_type_10f_11f_11f_rev                   DONE (i965, nv50, nvc0, r600, radeonsi)
-
-
-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

@@ -0,0 +1,88 @@
+Name
+
+    MESA_copy_sub_buffer
+
+Name Strings
+
+    GLX_MESA_copy_sub_buffer
+
+Contact
+
+    Brian Paul (brian 'at' mesa3d.org)
+
+Status
+
+    Shipping since Mesa 2.6 in February, 1998.
+
+Version
+
+    Last Modified Date:  8 June 2000
+
+Number
+
+    215
+
+Dependencies
+
+    OpenGL 1.0 or later is required.
+    GLX 1.0 or later is required.
+
+Overview
+
+    The glxCopySubBufferMESA() function copies a rectangular region
+    of the back color buffer to the front color buffer.  This can be
+    used to quickly repaint 3D windows in response to expose events
+    when the back color buffer cannot be damaged by other windows.
+
+IP Status
+
+    Open-source; freely implementable.
+
+Issues
+
+    None.
+
+New Procedures and Functions
+
+    void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+			       int x, int y, int width, int height );
+
+New Tokens
+
+    None.
+
+Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
+
+    Add to section 3.3.10 Double Buffering:
+
+    The function
+
+	 void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable,
+				    int x, int y, int width, int height );
+
+    may be used to copy a rectangular region of the back color buffer to
+    the front color buffer.  This can be used to quickly repaint 3D windows
+    in response to expose events when the back color buffer cannot be
+    damaged by other windows.
+
+    <x> and <y> indicates the lower-left corner of the region to copy and
+    <width> and <height> indicate the size in pixels.  Coordinate (0,0)
+    corresponds to the lower-left pixel of the window, like glReadPixels.
+
+GLX Protocol
+
+    None at this time.  The extension is implemented in terms of ordinary
+    Xlib protocol inside of Mesa.
+
+Errors
+
+    None.
+
+New State
+
+    None.
+
+Revision History
+
+    8 June 2000 - initial specification
+

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

@@ -17,6 +17,7 @@ Status
 
 Version
 
+    $Id: MESA_packed_depth_stencil.spec,v 1.2 2003/09/19 14:58:21 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_program_debug.spec

@@ -8,7 +8,7 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul (brian @ tungstengraphics.com)
 
 Status
 
@@ -18,6 +18,7 @@ Version
 
     Last Modified Date: July 20, 2003
     Author Revision: 1.0
+    $Date: 2003/09/23 14:46:11 $ $Revision: 1.3 $
 
 Number
 

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-
+    when the back color buffer, depth buffer, stencil buffer, and/or accum-
-    lation buffer associated with a drawable can be freed.
+    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,14 +8,15 @@ Name Strings
 
 Contact
 
-    Brian Paul (brian.paul 'at' tungstengraphics.com)
+    Brian Paul, brianp 'at' mesa3d.org
 
 Status
 
-    Obsolete.
+    Shipping (since Mesa version 2.2)
 
 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_sprite_point.spec

@@ -16,6 +16,7 @@ Status
 
 Version
 
+    $Id: MESA_sprite_point.spec,v 1.2 2003/09/19 14:58:21 brianp Exp $
 
 Number
 

docs/MESA_swap_control.spec

@@ -43,7 +43,7 @@ Issues
 
 New Procedures and Functions
 
-    int glXSwapIntervalMESA(unsigned int interval)
+    int glXSwapIntervalMESA(int interval)
     int glXGetSwapIntervalMESA(void)
 
 New Tokens
@@ -88,8 +88,8 @@ Additions to the GLX 1.3 Specification
     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-
+    If <interval> is set to a value of 0, buffer swaps are not synchron-
-    nized to a video frame.  The <interval> value is silently clamped to
+    ized to a video frame.  The <interval> value is silently clamped to
     the maximum implementation-dependent value supported before being
     stored.
 
@@ -103,8 +103,11 @@ Additions to the GLX 1.3 Specification
 
 Errors
 
+    glXSwapIntervalMESA returns GLX_BAD_VALUE if parameter <interval> is
+    less than zero.
+
     glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current
-    GLXContext or if the current context is not a direct rendering context.
+    GLXContext.
 
 GLX Protocol
 

docs/MESA_swap_frame_usage.spec

@@ -32,7 +32,7 @@ Dependencies
 
 Overview
 
-    This extension allows an application to determine what portion of the
+    This extension allows an application to deterine 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:
@@ -59,7 +59,7 @@ Overview
     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.
+    issuance of a swap and the swap actually occuring.
 
     There is also a mechanism to determine whether a frame swap was
     missed.
@@ -110,7 +110,7 @@ Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests)
 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
+    between two buffer-swap operations being commited.  In unextened 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
@@ -119,7 +119,7 @@ Additions to the GLX 1.3 Specification
     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
+    the swap is commited 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.
 
@@ -143,7 +143,7 @@ Additions to the GLX 1.3 Specification
 
     The current missed frame count and total number of swaps since
     the last call to glXBeginFrameTrackingMESA can be obtained by
-    calling the following function:
+    callling the following function:
 
        int glXQueryFrameTrackingMESA(Display *dpy,
                                      GLXDrawable drawable,
@@ -152,7 +152,7 @@ Additions to the GLX 1.3 Specification
                                      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 commited.  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.
@@ -171,7 +171,7 @@ Additions to the GLX 1.3 Specification
     application can call glXQueryFrameTrackingMESA for a final swap and
     missed frame count.
 
-    If these functions are successful, zero is returned.  If the context
+    If these functions are succesful, zero is returned.  If the context
     associated with dpy and drawable is not a direct context,
     GLX_BAD_CONTEXT is returned.
 

docs/MESA_trace.spec

@@ -4,7 +4,7 @@ Name
 
 Name Strings
 
-     GL_MESA_trace
+     GL_MESA_TRACE
 
 Contact
     
@@ -17,6 +17,7 @@ Status
 
 Version
 
+    $Id: MESA_trace.spec,v 1.3 2003/09/19 14:58:21 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,7 +26,7 @@ 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
@@ -75,14 +75,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_MESA       ushort         3         YCBCR_422_MESA
-    UNSIGNED_SHORT_8_8_REV_MESA   ushort         2         YCBCR_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 +103,13 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
     +-------------------------------+-------------------------------+
 
 
-    In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
+    In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
-    add the following to Table 3.12 (Packed pixel field assignments):
+    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
@@ -201,4 +201,3 @@ Revision History
      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/MiniGLX.html

@@ -0,0 +1,547 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Mini GLX Specification</title>
+</head>
+<body>
+<h1>
+<center>Mini GLX Specification</center>
+</h1>
+<h2>
+<center>Tungsten Graphics, Inc.<br>
+<br>
+January 20, 2003<br>
+<br>
+</center>
+</h2>
+<p> Copyright &copy; 2002-2003 by Tungsten Graphics, Inc., Cedar Park,
+Texas. All Rights Reserved. <br>
+<br>
+Permission is granted to make and distribute verbatim copies of this
+document provided the copyright notice and this permission notice are
+preserved on all copies.<br>
+<br>
+</p>
+<h1>1. Introduction</h1>
+<p>The Mini GLX interface facilitates OpenGL rendering on embedded
+devices. The interface is a subset of the GLX interface, plus a minimal
+set of Xlib-like functions.</p>
+<p>Programs written to the Mini GLX specification should run unchanged
+on systems with the X Window System and the GLX extension. The intention
+is to allow flexibility for prototyping and testing.</p>
+<p>This document serves as both the reference guide and programming
+guide for Mini GLX.<br>
+<br>
+</p>
+<h1>2. Mini GLX Concepts</h1>
+<p>The OpenGL specification does not describe how OpenGL rendering
+contexts and drawing surfaces (i.e. the frame buffer) are created and
+managed. Rather, this is handled by an OpenGL window system interface,
+such as Mini GLX.</p>
+<p>There are three main datatypes or resources managed by Mini GLX. The
+resources and their corresponding GLX or Xlib data types are:</p>
+<table cellspacing="10" align="center">
+  <tbody>
+    <tr>
+      <td><u>Resource</u></td>
+      <td><u>Data type</u></td>
+    </tr>
+    <tr>
+      <td>pixel formats</td>
+      <td>X Visual and XVisualInfo</td>
+    </tr>
+    <tr>
+      <td>drawing surfaces</td>
+      <td>X Window or GLXDrawable</td>
+    </tr>
+    <tr>
+      <td>rendering contexts</td>
+      <td>GLXContext</td>
+    </tr>
+  </tbody>
+</table>
+<p>Pixel formats or X Visuals describe the per-pixel attributes of the
+frame buffer.  For example, bits per color component, Z buffer size,
+stencil size, TrueColor vs PseudoColor, etc.</p>
+<p>Drawing surfaces or X Windows typically describe a spatial
+allocation of the frame buffer (i.e. the position and size of a
+rectangular region of pixels).  Since MiniGLX doesn't really support a
+window system, the window is effectively the entire frame buffer.</p>
+<p>A rendering context represents the current OpenGL state such as
+current drawing color, line width, blending mode, texture parameters,
+etc. Several rendering contexts can be created but only one can be in
+use at any given time.</p>
+<p>The Mini GLX interface provides all the functions needed for
+choosing pixel formats, create drawing surfaces, creating rendering
+contexts and binding rendering contexts to drawing surfaces.<br>
+<br>
+</p>
+<h1>3. Using Mini GLX</h1>
+<p>To use the Mini GLX interface in your application, include the
+GL/miniglx.h header file at compile time:</p>
+<blockquote><code>	#include &lt;GL/miniglx.h&gt;<br>
+  </code></blockquote>
+<code></code>Applications should link with libGL.so (i.e. <code>gcc
+myprogram.o -lGL -o myprogram</code>). &nbsp;libGL.so implements the
+MiniGLX API functions and, in turn, loads a hardware-specific device
+driver (such as <code>radeon_dri.so</code>) at runtime. &nbsp;The
+environment variable <code>LIBGL_DRIVERS_PATH</code> should name the
+directory where these modules are located.<br>
+<br>
+Prior to running a MiniGXL application, the following kernel modules
+must be installed:<br>
+<br>
+<div style="margin-left: 40px;"> agpgart.o<br>
+radeonfb.o &nbsp;(assuming Radeon hardware)<br>
+radeon.o &nbsp;(assuming Radeon hardware)<br>
+</div>
+<code></code> <br>
+Finally, MiniGLX reads a configuration file (by default,<code>
+/etc/miniglx.conf</code>) to determine basic configuration information.
+&nbsp;The configuration file may also be located in the directory
+specified by the <code>MINIGLX_CONF</code> environment variable).<br>
+<br>
+The remainder of this section describes the MiniGLX API functions.<br>
+<br>
+<h2>3.1 Initialization</h2>
+<p>The XOpenDisplay function is used to initialize the graphics system:</p>
+<blockquote>
+  <pre>Display *XOpenDisplay(const char *displayname)<br></pre>
+</blockquote>
+<p>The <code>displayName</code> parameter is currently ignored in Mini
+GLX. It is recommended that <code>NULL</code> be passed as the<code>displayName</code>
+parameter.</p>
+<p>If XOpenDisplay is able to initialize the graphics system a pointer
+to a Display will be returned.  Otherwise, NULL will be returned.</p>
+<h2>3.2 Choosing a Visual</h2>
+<p>A visual (i.e. pixel format) must be chosen before a drawing surface
+or rendering context can be created.  This is done with the
+glXChooseVisual function:</p>
+<blockquote>
+  <pre>XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)<br></pre>
+</blockquote>
+<p><code>dpy</code> is a pointer to the display returned by
+XOpenDisplay. </p>
+<p><code>screen</code> is currently ignored by Mini GLX and should be
+zero. </p>
+<p><code>attribList</code> is a list of GLX attributes which describe
+the desired pixel format.  It is terminated by the token <code>None</code>.
+The attributes are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>GLX_USE_GL</code></dt>
+    <dd>This attribute should always be present in order to maintain
+compatibility with GLX.</dd>
+    <dt><code>GLX_RGBA</code></dt>
+    <dd>If present, only RGBA pixel formats will be considered.
+Otherwise, only color index formats are considered.</dd>
+    <dt><code>GLX_DOUBLEBUFFER</code></dt>
+    <dd>if present, only double-buffered pixel formats will	be chosen.</dd>
+    <dt><code>GLX_RED_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per red pixel component that is acceptable.</dd>
+    <dt><code>GLX_GREEN_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per green pixel component that is acceptable.</dd>
+    <dt><code>GLX_BLUE_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per blue pixel component that is acceptable.</dd>
+    <dt><code>GLX_ALPHA_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per alpha pixel component that is acceptable.</dd>
+    <dt><code>GLX_STENCIL_SIZE n</code></dt>
+    <dd>Must be followed by a non-negative integer indicating the
+minimum number of bits per stencil value that is acceptable.</dd>
+    <dt><code>None</code></dt>
+    <dd>This token is used to terminate the attribute list.</dd>
+  </dl>
+</blockquote>
+<p>glXChooseVisual will return a pointer to an XVisualInfo object which
+most closely matches the requirements of the attribute list.  If there
+is no visual which matches the request, NULL will be returned.</p>
+<p>Note that visuals with accumulation buffers and depth buffers are
+not available.<br>
+<br>
+</p>
+<h2>3.3 Creating a Drawing Surface</h2>
+<p>Drawing surfaces are created as X windows. &nbsp;For Mini GLX,
+windows are <i>full-screen</i>; they cover the entire frame buffer.
+&nbsp;Also, Mini GLX imposes a limit of one window.  A second window
+cannot be created until the first one is destroyed.</p>
+<h3>3.3.1 Window Creation</h3>
+<p>The XCreateWindow function is used to create a drawing surface:</p>
+<blockquote>
+  <pre>Window XCreateWindow( Display *display,<br>                      Window parent,<br>                      int x, int y,<br>                      unsigned int width, unsigned int height,<br>                      unsigned int borderWidth,<br>                      int depth,<br>                      unsigned int class,<br>                      Visual *visual,<br>                      unsigned long valuemask,<br>                      XSetWindowAttributes *attributes )<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>display</code></dt>
+    <dd>A Display pointer, as returned by XOpenDisplay.</dd>
+    <dt><code>parent</code></dt>
+    <dd>The parent window for the new window.  For Mini GLX, this
+should be<code>RootWindow(dpy, 0)</code>.</dd>
+    <dt><code>x, y</code></dt>
+    <dd>The position of the window.  For Mini GLX, both values should
+be zero.</dd>
+    <dt><code>width, height</code></dt>
+    <dd>The size of the window.  For Mini GLX, this specifies the
+desired screen size such as 1024, 768 or 1280, 1024.</dd>
+    <dt><code>borderWidth</code></dt>
+    <dd>This parameter should be zero.</dd>
+    <dt><code>depth</code></dt>
+    <dd>The pixel depth for the window.  For Mini GLX this should be
+the depth found in the XVisualInfo object returned by <code>glxChooseVisual</code>.</dd>
+    <dt><code>class</code></dt>
+    <dd>The window class.  For Mini GLX this value should be <code>InputOutput</code>.</dd>
+    <dt><code>visual</code></dt>
+    <dd>This parameter should be the <code>visual</code> field of the <code>XVisualInfo</code>
+object returned by <code>glxChooseVisual</code>.</dd>
+    <dt><code>valuemask</code></dt>
+    <dd>This parameter indicates which fields of the <code>XSetWindowAttributes</code>
+are to be used. For Mini GLX this is typically the bitmask<code>CWBackPixel
+| CWBorderPixel | CWColormap</code>.</dd>
+    <dt><code>attributes</code></dt>
+    <dd>Initial window attributes. Of the fields in the <code>XSetWindowAttributes</code>
+structure, the<code>background_pixel</code>, <code>border_pixel</code>
+and <code>colormap</code> fields should be set. &nbsp;See the discussion
+below regarding colormaps.</dd>
+  </dl>
+</blockquote>
+<p><code>XCreateWindow</code> will return a window handle if it succeeds
+or zero if it fails.</p>
+<h3>3.3.2 Window Mapping</h3>
+<p>To display the window the XMapWindow function must be called:</p>
+<blockquote>
+  <pre>void XMapWindow(Display *dpy, Window w)</pre>
+</blockquote>
+<p>This function does nothing in Mini GLX but is required for Xlib/GLX
+compatibility</p>
+<h3>3.3.3 Colormaps<br>
+</h3>
+<p>Xlib requires specification of a colormap when creating a window.
+&nbsp;For purposes of interoperability, Mini GLX requires this as well,
+though the colormap is not actually used. &nbsp;The XCreateColormap
+function is used to create a colormap:</p>
+<blockquote><code>Colormap XCreateColormap(Display *dpy, Window window,
+Visual *visual, int alloc)</code><br>
+  <code></code></blockquote>
+<p>The parameters are as follows:<br>
+</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle as returned by XOpenDisplay.</dd>
+    <dt><code>window</code></dt>
+    <dd> This parameter is ignored by Mini GLX but should be the value
+returned by the <code>RootWindow(dpy, 0)</code> macro.<br>
+    </dd>
+    <dt><code>visual</code></dt>
+    <dd>This parameter is ignored by Mini GLX but should be the visual
+field of the XVisualInfo object returned by glXChooseVisual. </dd>
+    <dt><code>alloc</code></dt>
+    <dd>This parameter is ignored by Mini GLX but should be set to <code>AllocNone</code>.</dd>
+  </dl>
+</blockquote>
+<br>
+<h2>3.4 Creating a Rendering Context</h2>
+<p>An OpenGL rendering context is created with the <code>glXCreateContext</code>
+function:</p>
+<blockquote>
+  <pre>GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle as returned by XOpenDisplay.</dd>
+    <dt><code>visInfo</code></dt>
+    <dd>The visual as returned by glXChooseVisual.</dd>
+    <dt><code>shareList</code></dt>
+    <dd>If non-zero, texture objects and display lists are shared with
+the named rendering context. If zero, texture objects and display lists
+will (initially) be private to this context. They may be shared when a
+subsequent context is created.</dd>
+    <dt><code>direct</code></dt>
+    <dd>Specifies whether direct or indirect rendering is desired. For
+Mini GLX this value is ignored but it should be set to <code>True</code>.</dd>
+  </dl>
+</blockquote>
+<p><code>glXCreateContext</code> will return a GLXContext handle if it
+succeeds or zero if it fails due to invalid parameter or insufficient
+resources.<br>
+<br>
+</p>
+<h2>3.5 Binding a Rendering Context</h2>
+<p>The final step before beginning OpenGL rendering is to bind (i.e.
+activate) a rendering context and drawing surface with the
+glXMakeCurrent function:</p>
+<blockquote>
+  <pre>Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>drawable</code></dt>
+    <dd>The window or drawable to bind to the rendering context. This
+should be the value returned by XCreateWindow.</dd>
+    <dt><code>ctx</code></dt>
+    <dd>The rendering context to bind, as returned by glXCreateContext.</dd>
+  </dl>
+</blockquote>
+<p>If glXMakeCurrent succeeds True is returned.  Otherwise False is
+returned to indicate an invalid display, window or context parameter.</p>
+<p>After the rendering context has been bound to the drawing surface
+OpenGL rendering can begin.</p>
+<p>The current rendering context may be unbound by calling
+glXMakeCurrent with the window and context parameters set to zero.</p>
+<p>An application may create any number of rendering contexts and bind
+them as needed. Note that binding a rendering context is generally not a
+light-weight operation. &nbsp;Most simple OpenGL applications create
+only one rendering context.<br>
+<br>
+</p>
+<h2>3.6 Color Buffer Swapping</h2>
+<p>A double buffered window has two color buffers: a front buffer and a
+back buffer.  Normally, rendering is directed to the back buffer while
+the front buffer is displayed.  When rendering of a frame is finished
+the front and back buffers are swapped to provide the illusion of
+instanteous screen updates.</p>
+<p>The color buffers for a particular window (i.e. drawable) may be
+swapped with the glXSwapBuffers command:</p>
+<blockquote>
+  <pre>void glXSwapBuffers(Display *dpy, GLXDrawable drawable)<br></pre>
+</blockquote>
+Any pending rendering commands will be completed before the buffer swap
+takes place.<br>
+<br>
+Calling glXSwapBuffers on a window which is single-buffered has no
+effect.<br>
+<br>
+<h2>3.7 Releasing Resources</h2>
+<h3>3.7.1 Releasing Rendering Contexts</h3>
+<p>A rendering context may be destroyed by calling glXDestroyContext:</p>
+<blockquote>
+  <pre>void glXDestroyContext(Display *dpy, GLXContext ctx)<br></pre>
+</blockquote>
+<h3>3.7.2 Releasing Windows</h3>
+<p>A window may be destroyed by calling XDestroyWindow:</p>
+<blockquote>
+  <pre>void XDestroyWindow(Display *dpy, Window window)<br></pre>
+</blockquote>
+<h3>3.7.3 Releasing Visuals</h3>
+<p>An XVisualInfo object may be freed by calling XFree:</p>
+<blockquote>
+  <pre>void XFree(void *data)<br></pre>
+</blockquote>
+<h3>3.7.4 Releasing Colormaps</h3>
+<p>A colormap may be freed by calling XFreeColormap:</p>
+<blockquote>
+  <pre>void XFreeColormap(Display *dpy, Colormap colormap)<br></pre>
+</blockquote>
+<h3>3.7.4 Releasing Display Resources</h3>
+<p>When the application is about to exit, the resources associated with
+the graphics system can be released by calling XCloseDisplay:</p>
+<blockquote>
+  <pre>void XCloseDisplay(Display *dpy)<br></pre>
+</blockquote>
+<p>The display handle becomes invalid at this point.<br>
+<br>
+</p>
+<h2>3.8 Query Functions</h2>
+<h3>3.8.1 Querying Available Visuals</h3>
+A list of all available visuals can be obtained with the XGetVisualInfo
+function:<br>
+<br>
+<div style="margin-left: 40px;"><code>XVisualInfo
+*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo
+*vinfo_template, int *nitems_return)<br>
+</code></div>
+<br>
+The parameters are as follows:<br>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>vinfo_mask</code></dt>
+    <dd>A bitmask indicating which fields of the vinfo_template are to
+be matched. &nbsp;The value must be VisualScreenMask.</dd>
+    <dt><code>vinfo_template</code></dt>
+    <dd>A template whose fields indicate which visual attributes must
+be matched by the results. &nbsp;The screen field of this structure must
+be zero.</dd>
+    <dt><code>nitems_return</code></dt>
+    <dd>Returns the number of visuals returned. </dd>
+  </dl>
+</blockquote>
+The return value is the address of an array of all available visuals.<br>
+<br>
+An example of using XGetVisualInfo to get all available visuals follows:<br>
+<br>
+<div style="margin-left: 40px;"><code>XVisualInfo visTemplate, *results;</code><br>
+<code>int numVisuals;</code><br>
+<code>Display *dpy = XOpenDisplay(NULL);</code><br>
+<code>visTemplate.screen = 0;</code><br>
+<code>results = XGetVisualInfo(dpy, VisualScreenMask, &amp;visTemplate,
+&amp;numVisuals);</code><br>
+<code></code></div>
+<br>
+<h3>3.8.2 Querying Visual Attributes</h3>
+<p>The GLX attributes of an X visual may be queried with the
+glXGetConfig function:</p>
+<blockquote>
+  <pre>int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)<br></pre>
+</blockquote>
+<p>The parameters are as follows:</p>
+<blockquote>
+  <dl>
+    <dt><code>dpy</code></dt>
+    <dd>The display handle, as returned by XOpenDisplay.</dd>
+    <dt><code>vis</code></dt>
+    <dd>The visual, as returned by glXChooseVisual.</dd>
+    <dt><code>attribute</code></dt>
+    <dd>The attribute to query.  The attributes are listed below.</dd>
+    <dt><code>value</code></dt>
+    <dd>Pointer to an integer in which the result of the query will be
+stored. </dd>
+  </dl>
+</blockquote>
+<p>The return value will be zero if no error occurs.<code>
+&nbsp;GLX_INVALID_ATTRIBUTE</code> will be returned if the attribute
+parameter is invalid.<code> &nbsp;GLX_BAD_VISUAL</code> will be returned
+if the XVisualInfo parameter is invalid.</p>
+<p>The following attributes may be queried:</p>
+<blockquote>
+  <dl>
+    <dt><code>GLX_USE_GL</code></dt>
+    <dd>The result will be <code>True</code> or <code>False</code> to
+indicate if OpenGL rendering is supported with the visual.  Mini GLX
+always return <code>True</code>.</dd>
+    <dt><code>GLX_RGBA</code></dt>
+    <dd>The result will be <code>True</code> for RGBA visuals or <code>False</code>
+for color index visuals.</dd>
+    <dt><code>GLX_DOUBLEBUFFER</code></dt>
+    <dd>The result will be <code>True</code> if the visual has two
+color buffers or <code>False</code> if the visual has one color buffer.</dd>
+    <dt><code>GLX_RED_SIZE</code></dt>
+    <dd>The result will be the number of red bits per pixel.</dd>
+    <dt><code>GLX_GREEN_SIZE</code></dt>
+    <dd>The result will be the number of green bits per pixel.</dd>
+    <dt><code>GLX_BLUE_SIZE</code></dt>
+    <dd>The result will be the number of blue bits per pixel.</dd>
+    <dt><code>GLX_ALPHA_SIZE</code></dt>
+    <dd>The result will be the number of alpha bits per pixel.</dd>
+    <dt><code>GLX_DEPTH_SIZE</code></dt>
+    <dd>The result will be the number of bits per Z value.</dd>
+    <dt><code>GLX_STENCIL_SIZE</code></dt>
+    <dd>The result will be the number of bits per stencil value.<br>
+      <br>
+    </dd>
+  </dl>
+</blockquote>
+<h3>3.8.3 Querying the Current Rendering Context</h3>
+<p>The current rendering context can be queried with
+glXGetCurrentContext: </p>
+<blockquote>
+  <pre>GLXContext glXGetCurrentContext(void)<br></pre>
+</blockquote>
+<p>Zero will be returned if no context is currently bound.<br>
+<br>
+</p>
+<h3>3.8.4 Querying the Current Drawable</h3>
+<p>The current drawable (i.e. window or drawing surface) can be queried
+with glXGetCurrentDrawable:</p>
+<blockquote>
+  <pre>GLXDrawable glXGetCurrentDrawable(void)<br></pre>
+</blockquote>
+<p>Zero will be returned if no drawable is currently bound.<br>
+<br>
+</p>
+<h3>3.8.5 Function Address Queries</h3>
+<p>The glXGetProcAddress function will return the address of any
+available OpenGL or Mini GLX function:</p>
+<blockquote>
+  <pre>void *glXGetProcAddress(const GLubyte *procName)<br></pre>
+</blockquote>
+<p>If <code>procName</code> is a valid function name, a pointer to that
+function will be returned. &nbsp;Otherwise, NULL will be returned.</p>
+<p>The purpose of glXGetProcAddress is to facilitate using future
+extensions to OpenGL or Mini GLX.  If a future version of the library
+adds new extension functions they'll be accessible via
+glXGetProcAddress. The alternative is to hard-code calls to the new
+functions in the application but doing so will prevent linking the
+application with older versions of the library.<br>
+<br>
+</p>
+<h2>3.9 Versioning</h2>
+The Mini GLX version can be queried at run time with glXQueryVersion:
+<blockquote>
+  <pre>Bool glXQueryVersion(Display *dpy, int *major, int *minor)<br></pre>
+</blockquote>
+<p><code>major</code> will be set to the major version number and<code>minor</code>
+will be set to the minor version number.<code>True</code> will be
+returned if the function succeeds. <code>False</code> will be returned
+if the function fails due to invalid parameters. The <code>dpy</code>
+argument is currently ignored, but should be the value returned by
+XOpenDisplay.</p>
+<p>At compile time, the Mini GLX interface version can be tested with
+the MINI_GLX_VERSION_1_<i>x</i> preprocessor tokens. For example, if
+version 1.0 of Mini GLX is supported, then<code> MINI_GLX_VERSION_1_0</code>
+will be defined. If version 1.1 of Mini GLX is supported, then<code>
+MINI_GLX_VERSION_1_1</code> will be defined.</p>
+<p>At the time of writing the current Mini GLX version is 1.0.<br>
+<br>
+</p>
+<h1>4.0 Interoperability with GLX and Xlib</h1>
+While Mini GLX strives to be compatible with GLX and Xlib there are
+some unavoidable differences which must be taken into consideration.<br>
+<h2>4.1 Public vs Private Structures</h2>
+The structure of many X data types is public. &nbsp;For example, the <code>Display</code>
+data type is defined as a structure in /usr/include/X11/Xlib.h and
+programmers may access any fields of that structure at will. &nbsp;Mini
+GLX also defines a Display data type but its fields are hidden and not
+visiblein <code>miniglx.h</code>. &nbsp;Duplicating the Xlib
+declaration for the <code>Display</code> data type in minigl.h would
+require defining a large number of other superfluous Xlib datatypes.<br>
+<br>
+Mini GLX users are discouraged from directly accessing the fields of
+Xlib data types to maximize portability - though this is unavoidable to
+some extent. &nbsp;For example, the <code>XVisualInfo</code> and <code>XSetWindowAtttributes</code>
+data types must be completely public.
+<h2>4.2 Macros</h2>
+In some cases, Xlib defines macros which are meant to be used instead
+of direct structure accesses. &nbsp;For example, the <code>RootWindow(dpy,
+screen)</code> macro returns the root window for a given screen on a
+given display. &nbsp;Unfortunately, macros do nothing to aid in ABI
+compatibility since they are resolved at compile time instead of at
+link/run time.<br>
+<br>
+Mini GLX also defines a <code>RootWindow</code> macro since it's
+essential for creating windows. &nbsp;But the implementation of this
+macro by Xlib and Mini GLX is completely different.<br>
+<h2>4.3 Summary</h2>
+Because Xlib and Mini GLX define data types and macros differently,
+Mini GLX applications must be recompiled when retargeting Mini GLX or
+native Xlib/GLX. &nbsp;That is, applications can't simply be re-linked
+because of ABI incompatibilities.<br>
+<br>
+Nevertheless, the fact that Mini GLX programs can be recompiled for
+Xlib and GLX increases portability and flexibility for testing and
+prototyping.<br>
+<br>
+<h1>5.0 Example Program</h1>
+<p>This section shows an example program which uses the Mini GLX
+interface. The program simply draws several frames of a rotating square.<br>
+</p>
+<p>The program may be compiled for use with Xlib/GLX or Mini GLX by
+setting the <code>USE_MINIGLX</code> token to 0 or 1, respectively.
+&nbsp;Note that the only difference is the header files which are
+included.<br>
+</p>
+<p> </p>
+<pre><code><br></code>#define USE_MINIGLX 1  /* 1 = use Mini GLX, 0 = use Xlib/GLX */<br><br>#include &lt;stdio.h&gt;<br>#include &lt;stdlib.h&gt;<br>#include &lt;GL/gl.h&gt;<br><br>#if USE_MINIGLX<br>#include &lt;GL/miniglx.h&gt;<br>#else<br>#include &lt;GL/glx.h&gt;<br>#include &lt;X11/Xlib.h&gt;<br>#endif<br><br><code>/*<br> * Create a simple double-buffered RGBA window.<br> */<br>static Window<br>MakeWindow(Display * dpy, unsigned int width, unsigned int height)<br>{<br>   int visAttributes[] = {<br>      GLX_RGBA,<br>      GLX_RED_SIZE, 1,<br>      GLX_GREEN_SIZE, 1,<br>      GLX_BLUE_SIZE, 1,<br>      GLX_DOUBLEBUFFER,<br>      None<br>   };<br>   XSetWindowAttributes attr;<br>   unsigned long attrMask;<br>   Window root;<br>   Window win;<br>   GLXContext ctx;<br>   XVisualInfo *visinfo;<br><br>   root = RootWindow(dpy, 0);<br><br>   /* Choose GLX visual / pixel format */<br>   visinfo = glXChooseVisual(dpy, 0, visAttributes);<br>   if (!visinfo) {<br>      printf("Error: couldn't get an RGB, Double-buffered visual\n");<br>      exit(1);<br>   }<br><br>   /* Create the window */<br>   attr.background_pixel = 0;<br>   attr.border_pixel = 0;<br>   attr.colormap = XCreateColormap(dpy, root, visinfo-&gt;visual, AllocNone);<br>   attrMask = CWBackPixel | CWBorderPixel | CWColormap;<br>   win = XCreateWindow(dpy, root, 0, 0, width, height,<br>		       0, visinfo-&gt;depth, InputOutput,<br>		       visinfo-&gt;visual, attrMask, &amp;attr);<br>   if (!win) {<br>      printf("Error: XCreateWindow failed\n");<br>      exit(1);<br>   }<br><br>   /* Display the window */<br>   XMapWindow(dpy, win);<br><br>   /* Create GLX rendering context */<br>   ctx = glXCreateContext(dpy, visinfo, NULL, True);<br>   if (!ctx) {<br>      printf("Error: glXCreateContext failed\n");<br>      exit(1);<br>   }<br><br>   /* Bind the rendering context and window */<br>   glXMakeCurrent(dpy, win, ctx);<br><br>   return win;<br>}<br><br><br>/*<br> * Draw a few frames of a rotating square.<br> */<br>static void<br>DrawFrames(Display * dpy, Window win)<br>{<br>   int angle;<br>   glShadeModel(GL_FLAT);<br>   glClearColor(0.5, 0.5, 0.5, 1.0);<br>   for (angle = 0; angle &lt; 360; angle += 10) {<br>      glClear(GL_COLOR_BUFFER_BIT);<br>      glColor3f(1.0, 1.0, 0.0);<br>      glPushMatrix();<br>      glRotatef(angle, 0, 0, 1);<br>      glRectf(-0.8, -0.8, 0.8, 0.8);<br>      glPopMatrix();<br>      glXSwapBuffers(dpy, win);<br>   }<br>}<br><br><br>int<br>main(int argc, char *argv[])<br>{<br>   Display *dpy;<br>   Window win;<br><br>   dpy = XOpenDisplay(NULL);<br>   if (!dpy) {<br>      printf("Error: XOpenDisplay failed\n");<br>      return 1;<br>   }<br><br>   win = MakeWindow(dpy, 300, 300);<br><br>   DrawFrames(dpy, win);<br><br>   return 0;<br>}<br></code></pre>
+<br>
+</body>
+</html>

docs/README.3DFX

@@ -0,0 +1,672 @@
+
+                            3Dfx Glide device driver
+
+
+
+Mesa-5.1 release notes:
+-----------------------
+
+1) Glide2 support has been ceased; in order to keep Voodoo Graphics
+   and Voodoo Rush compatibility, please visit the Glide SourceForge
+   and help us to fix Glide3 for those cards.
+2) The current release is a WIP; among other things, the Linux build works
+   only to some extent. Any help will be appreciated.
+3) Glide3 can be found at http://sourceforge.net/projects/glide/
+
+
+
+Known supported HW/OS:
+----------------------
+
+Voodoo^2, Voodoo Banshee, Voodoo3, Voodoo4, Voodoo5
+DOS (DJGPP), Windows9x/2k (MinGW/MSVC), Linux
+
+
+
+How to compile:
+---------------
+
+DJGPP/MinGW/MSVC:
+   Place the Glide3 SDK in the top Mesa directory:
+	$(MESA)/glide3/include/*.h
+	$(MESA)/glide3/lib/
+   Required headers:
+	3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h
+   Required libraries:
+	OS specific
+   Type:
+	make -f Makefile.DJ HAVE_MMX=1 HAVE_3DNOW=1 FX=1
+	or
+	make -f Makefile.mgw HAVE_MMX=1 HAVE_3DNOW=1 FX=1
+	or
+	nmake -f Makefile.wfx
+   Look into the corresponding makefiles for further information.
+
+Linux:
+   Place the Glide3 SDK in /usr/local/glide
+   Type:
+	make linux-glide
+
+
+
+Contact:
+--------
+
+Daniel Borca <dborca@users.sourceforge.net>
+Hiroshi Morii <koolsmoky@users.sourceforge.net>
+
+
+
+The info below this line is outdated. You have been warned...
+*************************************************************
+
+
+
+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.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,227 @@
+			Mesa 5.1 DOS/DJGPP Port v1.4
+			~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+Description:
+~~~~~~~~~~~~
+
+Well, guess what... this is the DOS port of Mesa 5.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 = pentium
+	GLU=[mesa|sgi]	specify GLU directory; can be `sgi' (requires GNU/C++)
+			or `mesa'.
+			default = mesa
+	GLIDE		path to Glide3 SDK; used with FX.
+			default = $(TOP)/glide3
+	FX=1		build for 3dfx Glide3. Note that this disables
+			compilation of most DMesa code and requires fxMesa.
+			As a consequence, you'll need the DJGPP Glide3
+			library to build any application.
+			default = no
+	MATROX=1	build for Matrox Millennium I (MGA2064W) cards.
+			This is experimental and not intensively tested.
+			default = no
+	HAVE_X86=1	optimize for i386.
+			default = no
+	HAVE_MMX=1	allow MMX specializations, provided your assembler
+			supports MMX instruction set. However, the true CPU
+			capabilities are checked at run-time to avoid lockups.
+			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:		AMD Athlon XP 1800+
+	Mainboard:	EP-8KTA3 w/ 128 MB SDRAM
+	Video card:	Voodoo5 5500 AGP w/ 64 MB SDRAM
+	DJGPP:		djdev 2.04 + gcc v3.2.2 + make v3.80
+	OS:		DOS and Win98SE
+
+
+
+FAQ:
+~~~~
+
+1. Compilation
+
+   Q) `make' barfs and exits because it cannot find some stupid file.
+   A) You need LFN support.
+   A) When compiling for Glide (FX=1), pay attention to Glide path.
+
+   Q) Libraries built OK, but linker complains about `vsnprintf' every time I
+      compile some demo.
+   A) Upgrade to DJGPP 2.04.
+   A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!).
+   A) Patch `src/mesa/main/imports.c' with the following line:
+	#define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg)
+      This hack should be safe in 90% of the cases, but if anything goes wrong,
+      don't come back to me crying.
+
+   Q) `make' complains about DXE3 or something, yet it builds the libraries.
+   A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest
+      DJGPP distro, or download the separate package from my web page. Read the
+      DXE3 documentation on how to use them.
+   A) When compiling for Glide (FX=1), make sure `glide3x.dxe' can be found in
+      LD_LIBRARY_PATH (or top `lib' directory).
+
+2. Using Mesa for DJGPP
+
+   Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better...
+   A) Is that a question? If you have a 3dfx Voodoo Banshee or higher card,
+      you're lucky (check http://sourceforge.net/projects/glide for the DJGPP
+      port). If you have a Matrox Millennium I card, you just MIGHT be lucky...
+      If you haven't, sorry; everything is done in software. Suggestions?
+
+   Q) I tried to set refresh rate w/ DMesa, but without success.
+   A) Refresh rate control works only for VESA 3.0. If you were compiling for
+      Glide, see Glide info. If not, sorry!
+
+   Q) I made a simple application and it does nothing. It exits right away. Not
+      even a blank screen.
+   A) The pure software drivers (VESA/VGA) support only double-buffered modes.
+   A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a
+      lazy programmer and I found that the easiest way to keep buffer handling
+      at peak performance ;-).
+
+   Q) The GLUT is incomplete.
+   A) See below.
+
+
+
+libGLUT (the toolkit):
+~~~~~~~~~~~~~~~~~~~~~~
+
+Well, this "skeletal" GLUT implementation was taken from AllegGL project and
+heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian
+Paul and probably others (or probably not ;-). GLUT functionality will be
+extended only on an "as needed" basis.
+
+GLUT talks to hardware via PC_HW package which was put together from various
+pieces I wrote long time ago. It consists from the keyboard, mouse and timer
+drivers.
+
+My keyboard driver used only scancodes; as GLUT requires ASCII values for keys,
+I borrowed the translation tables (and maybe more) from Allegro -- many thanks
+to Shawn Hargreaves et co. 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 (hopefully) call the destructors, 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 drawing, etc), but is enough to
+make almost all the demos work. Supports the CuteMouse WheelAPI.
+
+The timer is pretty versatile for it supports multiple timers with different
+frequencies. While not being the most accurate timer in the known universe, 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. A bit of a hack, I
+know, because all messages come in bulk, but I think it's better than nothing.
+"Borrowed" from LIBRHUTI (Robert Hoehne).
+
+Window creating defaults: (0, 0, 300, 300), 16bpp. However, the video mode is
+chosen in such a way that first window will fit. If you need high resolution
+with small windows, set initial position far to the right (or way down); then
+you can move them back to any position right before the main loop.
+
+The following environment variables can customize GLUT behaviour:
+	GLUT_FPS		- print frames/second statistics to stderr
+	DMESA_GLUT_REFRESH	- set vertical screen refresh rate (VESA3)
+	DMESA_GLUT_BPP		- set default bits per pixel (VGA needs 8)
+	DMESA_GLUT_ALPHA	- set default alpha bits (8)
+	DMESA_GLUT_DEPTH	- set default depth bits (16)
+	DMESA_GLUT_STENCIL	- set default stencil bits (8)
+	DMESA_GLUT_ACCUM	- set default accum bits (16)
+
+
+
+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
+
+v1.3 (mar-2003)
+	+ enabled OpenGL 1.4 support
+	+ added MMX clear/blit routines
+	+ enabled SGI's GLU compilation
+	+ added samples makefile
+	+ added new GLUT functions
+	+ added color-index modes
+	+ added Matrox Millennium MGA2064W driver
+	+ added 8bit FakeColor (thanks to Neil Funk)
+	+ added VGA support (to keep Ben Decker happy)
+	! fixed some compilation errors (reported by Chan Kar Heng)
+	* optimized driver for faster callback access... yeah, right :)
+	* overhauled virtual buffer and internal video drivers
+	* better fxMesa integration
+	* revamped GLUT
+	* switched to DXE3
+
+v1.4 (nov-2003)
+	+ enabled GLUT fonts with DXE
+	+ truly added multi-window support in GLUT (for Adrian Woodward)
+	* accomodated makefiles with the new sourcetree
+	* fixed some ALPHA issues
+	* minor changes to PC_HW/timer interface
+	x hacked and slashed the 3dfx driver (w/ help from Hiroshi Morii)
+
+
+
+Contact:
+~~~~~~~~
+
+Name:   Borca Daniel
+E-mail: dborca@users.sourceforge.net
+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.MITS

@@ -0,0 +1,102 @@
+
+			Mesa 3.0 MITS Information
+
+
+This software is distributed under the terms of the GNU Library
+General Public License, see the LICENSE file for details.
+
+
+This document is a preliminary introduction to help you get
+started. For more detaile information consult the web page.
+
+http://10-dencies.zkm.de/~mesa/
+
+
+
+Version 0.1 (Yes it's very alpha code so be warned!)
+Contributors: 
+  Emil Briggs    	(briggs@bucky.physics.ncsu.edu)
+  David Bucciarelli 	(tech.hmw@plus.it)
+  Andreas Schiffler 	(schiffler@zkm.de)
+
+
+
+1. Requirements:
+     Mesa 3.0.
+     An SMP capable machine running Linux 2.x
+     libpthread installed on your machine.
+
+
+2. What does MITS stand for?
+     MITS stands for Mesa Internal Threading System. By adding
+     internal threading to Mesa it should be possible to improve
+     performance of OpenGL applications on SMP machines.
+
+
+3. Do applications have to be recoded to take advantage of MITS?
+     No. The threading is internal to Mesa and transparent to
+     applications.
+
+
+4. Will all applications benefit from the current implementation of MITS?
+     No. This implementation splits the processing of the vertex buffer
+     over two threads. There is a certain amount of overhead involved
+     with the thread synchronization and if there is not enough work
+     to be done the extra overhead outweighs any speedup from using
+     dual processors. You will not for example see any speedup when
+     running Quake because it uses GL_POLYGON and there is only one
+     polygon for each vertex buffer processed. Test results on a
+     dual 200 Mhz. Pentium Pro system show that one needs around
+     100-200 vertices in the vertex buffer before any there is any
+     appreciable benefit from the threading.
+
+
+5. Are there any parameters that I can tune to try to improve performance.
+     Yes. You can try to vary the size of the vertex buffer which is
+     define in VB_MAX located in the file src/vb.h from your top level
+     Mesa distribution. The number needs to be a multiple of 12 and
+     the optimum value will probably depend on the capabilities of
+     your machine and the particular application you are running.
+
+
+6. Are there any ways I can modify the application to improve its
+   performance with the MITS?
+     Yes. Try to use as many vertices between each Begin/End pair
+     as possbile. This will reduce the thread synchronization
+     overhead.
+
+
+7. What sort of speedups can I expect?
+     On some benchmarks performance gains of up to 30% have been
+     observerd. Others may see no gain at all and in a few rare
+     cases even some degradation.
+
+
+8. What still needs to be done?
+     Lots of testing and benchmarking.
+     A portable implementation that works within the Mesa thread API.
+     Threading of additional areas of Mesa to improve performance
+     even more.
+
+
+
+Installation:
+
+   1. This assumes that you already have a working Mesa 3.0 installation
+      from source.
+   2. Place the tarball MITS.tar.gz in your top level Mesa directory.
+   3. Unzip it and untar it. It will replace the following files in
+      your Mesa source tree so back them up if you want to save them.
+
+
+	 README.MITS
+         Make-config
+	 Makefile
+	 mklib.glide
+         src/vbxform.c
+	 src/vb.h
+
+   4. Rebuild Mesa using the command
+
+          make linux-386-glide-mits
+

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

@@ -0,0 +1,208 @@
+
+             Info on using Mesa 3.0 with Linux Quake I and Quake II
+
+
+
+Disclaimer
+----------
+
+I am _not_ a Quake expert by any means.  I pretty much only run it to
+test Mesa.  There have been a lot of questions about Linux Quake and
+Mesa so I'm trying to provide some useful info here.  If this file
+doesn't help you then you should look elsewhere for help.  The Mesa
+mailing list or the news://news.3dfx.com/3dfx.linux.glide newsgroup
+might be good.
+
+Again, all the information I have is in this file.  Please don't email
+me with questions.
+
+If you have information to contribute to this file please send it to
+me at brianp@elastic.avid.com
+
+
+
+Linux Quake
+-----------
+
+You can get Linux Quake from http://www.idsoftware.com/
+
+Quake I and II for Linux were tested with, and include, Mesa 2.6.  You
+shouldn't have too many problems if you simply follow the instructions
+in the Quake distribution.
+
+
+
+RedHat 5.0 Linux problems
+-------------------------
+
+RedHat Linux 5.x uses the GNU C library ("glibc" or "libc6") whereas
+previous RedHat and other Linux distributions use "libc5" for its
+runtime C library.
+
+Linux Quake I and II were compiled for libc5.  If you compile Mesa
+on a RedHat 5.x system the resulting libMesaGL.so file will not work
+with Linux Quake because of the different C runtime libraries.
+The symptom of this is a segmentation fault soon after starting Quake.
+
+If you want to use a newer version of Mesa (like 3.x) with Quake on
+RedHat 5.x then read on.
+
+The solution to the C library problem is to force Mesa to use libc5.
+libc5 is in /usr/i486-linux-libc5/lib on RedHat 5.x systems.
+
+Emil Briggs (briggs@tick.physics.ncsu.edu) nicely gave me the following
+info:
+
+>   I only know what works on a RedHat 5.0 distribution. RH5 includes
+> a full set of libraries for both libc5 and glibc. The loader ld.so
+> uses the libc5 libraries in /usr/i486-linux-libc5/lib for programs
+> linked against libc5 while it uses the glibc libraries in /lib and
+> /usr/lib for programs linked against glibc.
+> 
+> Anyway I changed line 41 of mklib.glide to
+>     GLIDELIBS="-L/usr/local/glide/lib -lglide2x -L/usr/i486-linux-libc5/lib"
+> 
+> And I started quake2 up with a script like this
+> #!/bin/csh
+> setenv LD_LIBRARY_PATH /usr/i486-linux-libc5/lib
+> setenv MESA_GLX_FX f
+> ./quake2 +set vid_ref gl
+> kbd_mode -a
+> reset
+
+
+I've already patched the mklib.glide file.  You'll have to start Quake
+with the script shown above though.
+
+
+
+**********************
+
+Daryll Strauss writes:
+
+Here's my thoughts on the problem. On a RH 5.x system, you can NOT build
+a libc5 executable or library. Red Hat just doesn't include the right
+stuff to do it.
+
+Since Quake is a libc5 based application, you are in trouble. You need
+libc5 libraries.
+
+What can you do about it? Well there's a package called gcc5 that does
+MOST of the right stuff to compile with libc5. (It brings back older
+header files, makes appropriate symbolic links for libraries, and sets
+up the compiler to use the correct directories) You can find gcc5 here: 
+ftp://ecg.mit.edu/pub/linux/gcc5-1.0-1.i386.rpm
+
+No, this isn't quite enough. There are still a few tricks to getting
+Mesa to compile as a libc5 application. First you have to make sure that
+every compile uses gcc5 instead of gcc. Second, in some cases the link
+line actually lists -L/usr/lib which breaks gcc5 (because it forces you
+to use the glibc version of things)
+
+If you get all the stuff correctly compiled with gcc5 it should work.
+I've run Mesa 3.0B6  and its demos in a window with my Rush on a Red Hat
+5.1 system. It is a big hassle, but it can be done. I've only made Quake
+segfault, but I think that's from my libRush using the wrong libc. 
+
+Yes, mixing libc5 and glibc is a major pain. I've been working to get
+all my libraries compiling correctly with this setup. Someone should
+make an RPM out of it and feed changes back to Brian once they get it
+all working. If no one else has done so by the time I get the rest of my
+stuff straightened out, I'll try to do it myself.
+
+							- |Daryll
+
+
+
+*********************
+
+David Bucciarelli (tech.hmw@plus.it) writes:
+
+I'm using the Mesa-3.0beta7 and the RedHat 5.1 and QuakeII is
+working fine for me.  I had only to make a small change to the
+Mesa-3.0/mklib.glide file, from:
+
+
+    GLIDELIBS="-L/usr/local/glide/lib -lglide2x
+-L/usr/i486-linux-libc5/lib -lm"
+
+to:
+
+    GLIDELIBS="-L/usr/i486-linux-libc5/lib -lglide2x"
+
+and to make two symbolic links:
+
+[david@localhost Mesa]$ ln -s libMesaGL.so libMesaGL.so.2
+[david@localhost Mesa]$ ln -s libMesaGLU.so libMesaGLU.so.2
+
+I'm using the Daryll's Linux glide rpm for the Voodoo2 and glibc (it
+includes also the Glide for the libc5). I'm not using the /dev/3Dfx and
+running QuakeII as root with the following env. var:
+
+export
+LD_LIBRARY_PATH=/dsk1/home/david/src/gl/Mesa/lib:/usr/i486-linux-libc5/lib
+
+I think that all problems are related to the glibc, Quake will never
+work if you get the following output:
+
+[david@localhost Mesa]$ ldd lib/libMesaGL.so
+        libglide2x.so => /usr/lib/libglide2x.so (0x400f8000)
+        libm.so.6 => /lib/libm.so.6 (0x40244000)
+        libc.so.6 => /lib/libc.so.6 (0x4025d000)
+        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
+
+You must get the following outputs:
+
+[david@localhost Mesa]# ldd lib/libMesaGL.so
+        libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
+(0x400f3000)
+
+[root@localhost quake2]# ldd quake2
+        libdl.so.1 => /lib/libdl.so.1 (0x40005000)
+        libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x40008000)
+        libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x40010000)
+
+[root@localhost quake2]# ldd ref_gl.so
+        libMesaGL.so.2 =>
+/dsk1/home/david/src/gl/Mesa/lib/libMesaGL.so.2 (0x400eb000)
+        libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
+(0x401d9000)
+        libX11.so.6 => /usr/i486-linux-libc5/lib/libX11.so.6
+(0x40324000)
+        libXext.so.6 => /usr/i486-linux-libc5/lib/libXext.so.6
+(0x403b7000)
+        libvga.so.1 => /usr/i486-linux-libc5/lib/libvga.so.1
+(0x403c1000)
+        libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x403f5000)
+        libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x403fd000)
+
+
+***********************
+
+Steve Davies (steve@one47.demon.co.uk) writes:
+
+
+Try using:
+
+    export LD_LIBRARY_PATH=/usr/i486-linux-libc5/lib
+    ./quake2 +set vid_ref gl
+
+to start the game... Works for me, but assumes that you have the
+compatability libc5 RPMs installed.
+
+
+***************************
+
+WWW resources - you may find additional Linux Quake help at these URLs:
+
+
+http://quake.medina.net/howto
+
+http://webpages.mr.net/bobz
+
+http://www.linuxgames.com/quake2/
+
+
+
+----------------------------------------------------------------------
+$Id: README.QUAKE,v 1.3 1998/08/23 15:26:26 brianp Exp $

docs/README.THREADS

@@ -0,0 +1,52 @@
+
+
+Mesa Threads README
+-------------------
+
+Thread safety was introduced in Mesa 2.6 by John Stone and
+Christoph Poliwoda.
+
+It was redesigned in Mesa 3.3 so that thread safety is
+supported by default (on systems which support threads,
+that is).  There is no measurable penalty on single
+threaded applications.
+
+NOTE that the only _driver_ which is thread safe at this time
+is the OS/Mesa driver!
+
+
+At present the mthreads code supports three thread APIS:
+  1) POSIX threads (aka pthreads).
+  2) Solaris / Unix International threads.
+  3) Win32 threads (Win 95/NT).
+
+Support for other thread libraries can be added src/glthread.[ch]
+
+
+In order to guarantee proper operation, it is
+necessary for both Mesa and application code to use the same threads API.
+So, if your application uses Sun's thread API, then you should build Mesa
+using one of the targets for Sun threads.
+
+The mtdemos directory contains some example programs which use 
+multiple threads to render to osmesa rendering context(s).
+
+Linux users should be aware that there exist many different POSIX
+threads packages. The best solution is the linuxthreads package
+(http://pauillac.inria.fr/~xleroy/linuxthreads/) as this package is the
+only one that really supports multiprocessor machines (AFAIK). See
+http://pauillac.inria.fr/~xleroy/linuxthreads/README for further
+information about the usage of linuxthreads.
+
+If you are interested in helping with thread safety work in Mesa
+join the Mesa developers mailing list and post your proposal.
+
+
+Regards,
+  John Stone           -- j.stone@acm.org  johns@cs.umr.edu
+  Christoph Poliwoda   -- poliwoda@volumegraphics.com
+
+
+Version info:
+   Mesa 2.6 - initial thread support.
+   Mesa 3.3 - thread support mostly rewritten (Brian Paul)

docs/README.UVD

@@ -1,44 +0,0 @@
-The software may implement third party technologies (e.g. third party
-libraries) that are not licensed to you by AMD and for which you may need
-to obtain licenses from other parties.  Unless explicitly stated otherwise,
-these third party technologies are not licensed hereunder.  Such third
-party technologies include, but are not limited, to H.264, MPEG-2, MPEG-4,
-AVC, and VC-1.
-
-For MPEG-2 Encoding Products ANY USE OF THIS PRODUCT IN ANY MANNER OTHER
-THAN PERSONAL USE THAT COMPLIES WITH THE MPEG-2 STANDARD FOR ENCODING VIDEO
-INFORMATION FOR PACKAGED MEDIA IS EXPRESSLY PROHIBITED WITHOUT A LICENSE
-UNDER APPLICABLE PATENTS IN THE MPEG-2 PATENT PORTFOLIO, WHICH LICENSES IS
-AVAILABLE FROM MPEG LA, LLC, 6312 S. Fiddlers Green Circle, Suite 400E,
-Greenwood Village, Colorado 80111 U.S.A.
-
-WARRANTY DISCLAIMER: THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
-KIND.  AMD DISCLAIMS ALL WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
-BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
-PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, THAT THE SOFTWARE WILL RUN
-UNINTERRUPTED OR ERROR-FREE OR WARRANTIES ARISING FROM CUSTOM OF TRADE OR
-COURSE OF USAGE.  THE ENTIRE RISK ASSOCIATED WITH THE USE OF THE SOFTWARE IS
-ASSUMED BY YOU.  Some jurisdictions do not allow the exclusion of implied
-warranties, so the above exclusion may not apply to You.
-
-LIMITATION OF LIABILITY AND INDEMNIFICATION:  AMD AND ITS LICENSORS WILL NOT,
-UNDER ANY CIRCUMSTANCES BE LIABLE FOR ANY PUNITIVE, DIRECT, INCIDENTAL,
-INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING FROM USE OF THE SOFTWARE OR
-THIS AGREEMENT EVEN IF AMD AND ITS LICENSORS HAVE BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.  In no event shall AMD's total liability to You
-for all damages, losses, and causes of action (whether in contract, tort
-(including negligence) or otherwise) exceed the amount of $100 USD.  You agree
-to defend, indemnify and hold harmless AMD and its licensors, and any of their
-directors, officers, employees, affiliates or agents from and against any and
-all loss, damage, liability and other expenses (including reasonable
-attorneys' fees), resulting from Your use of the Software or violation of the
-terms and conditions of this Agreement.
-
-U.S. GOVERNMENT RESTRICTED RIGHTS: The Software is provided with "RESTRICTED
-RIGHTS." Use, duplication, or disclosure by the Government is subject to the
-restrictions as set forth in FAR 52.227-14 and DFAR252.227-7013, et seq., or
-its successor.  Use of the Software by the Government constitutes
-acknowledgement of AMD's proprietary rights in them.
-
-EXPORT RESTRICTIONS: The Software may be subject to export restrictions as
-stated in the Software License Agreement.

docs/README.VCE

@@ -1,43 +0,0 @@
-The software may implement third party technologies (e.g. third party
-libraries) that are not licensed to you by AMD and for which you may need
-to obtain licenses from other parties.  Unless explicitly stated otherwise,
-these third party technologies are not licensed hereunder.  Such third
-party technologies include, but are not limited, to H.264, MPEG-2, MPEG-4,
-AVC, and VC-1.  
-
-For MPEG-2 Intermediate Products: ANY USE OF THIS PRODUCT IN ANY MANNER OTHER
-THAN PERSONAL USE THAT COMPLIES WITH THE MPEG-2 STANDARD IS EXPRESSLY
-PROHIBITED WITHOUT A LICENSE UNDER APPLICABLE PATENTS IN THE MPEG-2 PATENT
-PORTFOLIO, WHICH LICENSES IS AVAILABLE FROM MPEG LA, LLC, 6312 S. Fiddlers
-Green Circle, Suite 400E, Greenwood Village, Colorado 80111 U.S.A.
-
-WARRANTY DISCLAIMER: THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
-KIND.  AMD DISCLAIMS ALL WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING
-BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
-PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT, THAT THE SOFTWARE WILL RUN
-UNINTERRUPTED OR ERROR-FREE OR WARRANTIES ARISING FROM CUSTOM OF TRADE OR
-COURSE OF USAGE.  THE ENTIRE RISK ASSOCIATED WITH THE USE OF THE SOFTWARE IS
-ASSUMED BY YOU.  Some jurisdictions do not allow the exclusion of implied
-warranties, so the above exclusion may not apply to You.
-
-LIMITATION OF LIABILITY AND INDEMNIFICATION:  AMD AND ITS LICENSORS WILL NOT,
-UNDER ANY CIRCUMSTANCES BE LIABLE FOR ANY PUNITIVE, DIRECT, INCIDENTAL,
-INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING FROM USE OF THE SOFTWARE OR
-THIS AGREEMENT EVEN IF AMD AND ITS LICENSORS HAVE BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.  In no event shall AMD's total liability to You
-for all damages, losses, and causes of action (whether in contract, tort
-(including negligence) or otherwise) exceed the amount of $100 USD.  You agree
-to defend, indemnify and hold harmless AMD and its licensors, and any of their
-directors, officers, employees, affiliates or agents from and against any and
-all loss, damage, liability and other expenses (including reasonable
-attorneys' fees), resulting from Your use of the Software or violation of the
-terms and conditions of this Agreement.
-
-U.S. GOVERNMENT RESTRICTED RIGHTS: The Software is provided with "RESTRICTED
-RIGHTS." Use, duplication, or disclosure by the Government is subject to the
-restrictions as set forth in FAR 52.227-14 and DFAR252.227-7013, et seq., or
-its successor.  Use of the Software by the Government constitutes
-acknowledgement of AMD's proprietary rights in them.
-
-EXPORT RESTRICTIONS: The Software may be subject to export restrictions as
-stated in the Software License Agreement.

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,68 +1,91 @@
 File: docs/README.WIN32
 
-Last updated: 21 June 2013
+Last updated: Sep 18, 2003 - Karl Schultz - kschultz@users.sourceforge.net
-
 
 Quick Start
------ -----
 
-Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
+Unzip both ZIP files (MesaLib and MesaDemos) into the same directory.
-no longer shipped or supported.
+The libs and demos build separately, so if you do not care about the
+demos, you do not have to unzip that zip file.  But if you do, it does
+need to be unzipped into the same directory as the lib zip file because
+the demos depend on the libs.
 
-Run
+The build system has been changed to use Microsoft Visual Studio project
+workspaces and projects.  Makefiles are no longer shipped or supported, but
+can be generated from the projects using Visual Studio.
 
-  scons osmesa mesagdi
+Details and Notes
 
-to build classic mesa Windows GDI drivers; or
+- To build the Mesa libraries, open the Mesa.dsw workspace file
+  in the top directory.  You can build each project one-by-one,
+  or build the glut project to build everything except osmesa,
+  which needs to be built separately.  The build process will
+  create a lib directory in the top directory and will put the
+  following files there:
+	OPENGL32.LIB, GLU32.LIB, GLUT32.LIB, OSMESA32.LIB
+	OPENGL32.DLL, GLU32.DLL, GLUT32.DLL, OSMESA32.DLL
 
-  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).
+  Be careful about accidentially overwriting files of the same name in
+  the SYSTEM32 directory.
 
-to build gallium based GDI driver.
+- Build the demos by opening the appropriate *.dsw file in the
+  progs directory tree.  For example, to build the demos, use
+  progs/demos/Windows/demos.dsw.  The Windows directory contains
+  the workspace and all the projects for each demo program.  Each
+  project places the executable in the same directory as its source
+  code, which is required for some demos.
 
-This will work both with MSVS or Mingw.
+- The demo projects also copy the Mesa library DLL files from the lib
+  directory into the same directory as the demo executables, so that
+  the demos use the Mesa libs you just built.
+
+- 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.
+
+- 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.
+  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.
+
+- To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE
+  to the project settings.  You will also need to edit src/mesa.def to change
+  all the gl* symbols to mgl*.  Because this is easy to do with a global
+  replace operation in a text editor, no additional mangled version of mesa.def
+  is maintained or shipped.
+
+If you have a Windows-related build problem or question, it is
+probably better to direct it to me (kschultz@users.sourceforge.net),
+rather than directly to the other Mesa developers.  I will help you
+as much as I can.  I also monitor the Mesa mailing lists and will
+answer questions in this area there as well.
 
 
-Windows Drivers
+Karl Schultz
-------- -------
-
-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.
-
-Recipe
-------
-
-Building on windows requires several open-source packages. These are
-steps that work as of this writing.
-
-- install python 2.7
-- install scons (latest)
-- install mingw, flex, and bison
-- install pywin32 from here: http://www.lfd.uci.edu/~gohlke/pythonlibs
-  get pywin32-218.4.win-amd64-py2.7.exe
-- install git
-- download mesa from git
-  see http://www.mesa3d.org/repository.html
-- run scons
-
-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.

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,314 @@
+
+                          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
+==========
+   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)
+
+
+----------------------------------------------------------------------
+$Id: README.X11,v 3.10 2003/03/08 17:38:57 brianp Exp $

docs/RELNOTES-3.1

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

docs/RELNOTES-3.2

@@ -0,0 +1,12 @@
+
+                         Mesa 3.2 release notes
+
+                             PLEASE READ!!!!
+
+
+Mesa 3.2 is a stabilization of the Mesa 3.1 release.  No new features
+have been added.  For a list of bug fixes please read the VERSIONS file.
+
+
+----------------------------------------------------------------------
+$Id: RELNOTES-3.2,v 1.2 2000/04/07 17:08:06 brianp Exp $

docs/RELNOTES-3.2.1

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

docs/RELNOTES-3.3

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

docs/RELNOTES-3.4

@@ -0,0 +1,22 @@
+
+                         Mesa 3.4 release notes
+
+                             November 3, 2000
+
+                             PLEASE READ!!!!
+
+
+
+Introduction
+------------
+
+Mesa uses an even/odd version number scheme like the Linux kernel.
+Odd numbered versions (such as 3.3) designate new developmental releases.
+Even numbered versions (such as 3.4) designate stable releases.
+
+Mesa 3.4 simply fixes bugs found in the Mesa 3.3 release.  For details,
+see the VERSIONS file.
+
+
+----------------------------------------------------------------------
+$Id: RELNOTES-3.4,v 1.2 2002/03/23 02:37:17 brianp Exp $

docs/RELNOTES-3.4.1

@@ -0,0 +1,22 @@
+
+                         Mesa 3.4.1 release notes
+
+                             February 9, 2001
+
+                              PLEASE READ!!!!
+
+
+
+Introduction
+------------
+
+Mesa uses an even/odd version number scheme like the Linux kernel.
+Odd numbered versions (such as 3.3) designate new developmental releases.
+Even numbered versions (such as 3.4) designate stable releases.
+
+Mesa 3.4.1 is a maintenance release that simply fixes bugs found since
+the Mesa 3.4 release.  For details, see the VERSIONS file.
+
+
+----------------------------------------------------------------------
+$Id: RELNOTES-3.4.1,v 1.2 2001/05/23 14:45:01 brianp Exp $

docs/RELNOTES-3.4.2

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

docs/RELNOTES-3.5

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

docs/RELNOTES-4.0

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

docs/RELNOTES-4.0.1

@@ -0,0 +1,22 @@
+
+                          Mesa 4.0.1 release notes
+
+                             December 17, 2001
+
+                              PLEASE READ!!!!
+
+
+
+Introduction
+------------
+
+Mesa uses an even/odd version number scheme like the Linux kernel.
+Odd numbered versions (such as 3.3) designate new developmental releases.
+Even numbered versions (such as 3.4) designate stable releases.
+
+Mesa 4.0.1 only contains bug fixes since version 4.0.
+
+See the docs/VERSIONS file for the list of bug fixes.
+
+----------------------------------------------------------------------
+$Id: RELNOTES-4.0.1,v 1.2 2001/12/18 14:08:23 brianp Exp $

docs/RELNOTES-4.0.2

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

docs/RELNOTES-4.0.3

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

docs/RELNOTES-4.1

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

docs/RELNOTES-5.0

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

docs/RELNOTES-5.0.1

@@ -0,0 +1,46 @@
+
+                           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.
+
+
+----------------------------------------------------------------------
+$Id: RELNOTES-5.0.1,v 3.1 2003/03/30 16:17:54 brianp Exp $

docs/RELNOTES-5.0.2

@@ -0,0 +1,46 @@
+
+                           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.
+
+
+----------------------------------------------------------------------
+$Id: RELNOTES-5.0.2,v 1.1 2003/09/04 23:10:38 brianp Exp $

docs/RELNOTES-5.1

@@ -0,0 +1,228 @@
+
+                            Mesa 5.1 release notes
+
+                              Month day, 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_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.
+
+
+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
+	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
+
+Removed files:
+	swrast/s_histogram.[ch] - moved into src/histogram.c
+
+Other New files:
+	bufferobj.[ch]		- GL_ARB_vertex_buffer_object functions
+	version.h		- defines the Mesa version info
+
+
+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.
+
+
+
+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/VERSIONS

@@ -1146,10 +1146,9 @@ Mesa Version History
 	- build GLUT with -fexceptions so C++ apps propogate exceptions
 
 
-5.1  December 17, 2003
+5.1  Month day, 2003  (NOT RELEASED YET)
     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
@@ -1166,8 +1165,6 @@ Mesa Version History
 	- 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
@@ -1183,332 +1180,3 @@ Mesa Version History
 	- 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/application-issues.html

@@ -1,83 +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>Application Issues</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>Application Issues</h1>
-
-<p>
-This page documents known issues with some OpenGL applications.
-</p>
-
-
-<h2>Topogun</h2>
-
-<p>
-<a href="http://www.topogun.com/">Topogun</a> for Linux (version 2, at least)
-creates a GLX visual without requesting a depth buffer.
-This causes bad rendering if the OpenGL driver happens to choose a visual
-without a depth buffer.
-</p>
-
-<p>
-Mesa 9.1.2 and later (will) support a DRI configuration option to work around
-this issue.
-Using the <a href="http://dri.freedesktop.org/wiki/DriConf">driconf</a> tool,
-set the "Create all visuals with a depth buffer" option before running Topogun.
-Then, all GLX visuals will be created with a depth buffer.
-</p>
-
-
-<h2>Old OpenGL games</h2>
-
-<p>
-Some old OpenGL games (approx. ten years or older) may crash during
-start-up because of an extension string buffer-overflow problem.
-</p>
-
-<p>
-The problem is a modern OpenGL driver will return a very long string
-for the glGetString(GL_EXTENSIONS) query and if the application
-naively copies the string into a fixed-size buffer it can overflow the
-buffer and crash the application.
-</p>
-
-<p>
-The work-around is to set the MESA_EXTENSION_MAX_YEAR environment variable
-to the approximate release year of the game.
-This will cause the glGetString(GL_EXTENSIONS) query to only report extensions
-older than the given year.
-</p>
-
-<p>
-For example, if the game was released in 2001, do
-<pre>
-export MESA_EXTENSION_MAX_YEAR=2001
-</pre>
-before running the game.
-</p>
-
-
-
-<h2>Viewperf</h2>
-
-<p>
-See the <a href="viewperf.html">Viewperf issues</a> page for a detailed list
-of Viewperf issues.
-</p>
-
-
-</div>
-</body>
-</html>

docs/autoconf.html

@@ -1,233 +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>--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. Note that these options are mutually exclusive.</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 options <code>--enable-xlib-glx</code>, <code>--enable-osmesa</code>,
-and <code>--enable-dri</code>.
-</p>
-
-<h3 id="xlib">Xlib</h3><p>
-It uses Xlib as a software renderer to do all rendering. It corresponds
-to the option <code>--enable-xlib-glx</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>--enable-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.  It corresponds to the option
-<code>--enable-osmesa</code>.
-
-<!-- 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/banner.html

@@ -0,0 +1,15 @@
+<HTML>
+
+<title>Banner</title>
+
+
+<body text="#ffffff" bgcolor="#aa4444">
+
+<center>
+<p>
+<font size="5">The Mesa 3D Graphics Library</font>
+</p>
+</center>
+
+</body>
+</html>

docs/bugs.html

@@ -1,52 +1,27 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<HTML>
-<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">
+<TITLE>Mesa Bug Reporting</TITLE>
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
 
-<iframe src="contents.html"></iframe>
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
-<div class="content">
 
-<h1>Bug Database</h1>
+<H1>Bug Database</H1>
 
 <p>
-The Mesa bug database is hosted on
+Bug reports can be filed in the <a
-<a href="http://freedesktop.org">freedesktop.org</a>.
+href="http://sourceforge.net/bugs/?group_id=3" target="_parent">Bug
-The old bug database on SourceForge is no longer used.
+Database</a> on sourceforge.net. Please follow these guidelines:
-</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
+<li>Make sure you're using the most recent version of Mesa
-the problem.
+<li>Make sure your bug isn't already reported
-<li>Check if your bug is already reported in the database.
+<li>Include as much information as possible in the report
-<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
+<li>Check back for follow-ups to the report
 </ul>
 
 <p>
-Bug reports will automatically be forwarded by bugzilla to the Mesa
+Bug reports will automatically be forwarded to the Mesa developer's list.
-developer's mailing list.
 </p>
 
 <p>
@@ -56,6 +31,5 @@ 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>
-</body>
+</HTML>
-</html>

docs/conform.html

@@ -1,25 +1,15 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<HTML>
-<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">
+<TITLE>Conformance</TITLE>
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
 
-<iframe src="contents.html"></iframe>
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
-<div class="content">
 
-<h1>Conformance</h1>
+<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 publicly available.
+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
@@ -698,6 +688,6 @@ Conformx passed.
 
 NOTE: conformx passes for all machine path levels (-p option).
 
-</div>
+
 </body>
 </html>

docs/contents.html

@@ -1,105 +1,78 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
-<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: -->
+<title>Contents</title>
-  <style type="text/css">
+
-    <!--
+<body text="#ffffff" bgcolor="#119955" link="#ffffff" vlink="#dddddd" alink="#ffffff">
-    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="intro.html" target="MainFrame">Introduction</a>
-<li><a href="index.html" target="_parent">News</a>
+<li><a href="news.html" target="MainFrame">News</a>
-<li><a href="developers.html" target="_parent">Developers</a>
+<li><a href="systems.html" target="MainFrame">Platforms and Drivers</a>
-<li><a href="systems.html" target="_parent">Platforms and Drivers</a>
+<li><a href="license.html" target="MainFrame">License & Copyright</a>
-<li><a href="license.html" target="_parent">License &amp; Copyright</a>
+<li><a href="faq.html" target="MainFrame">FAQ</a>
-<li><a href="faq.html" target="_parent">FAQ</a>
+<li><a href="VERSIONS" target="MainFrame">Version History</a>
-<li><a href="relnotes.html" target="_parent">Release Notes</a>
+<li><a href="relnotes.html" target="MainFrame">Release Notes</a>
-<li><a href="thanks.html" target="_parent">Acknowledgements</a>
+<li><a href="thanks.html" target="MainFrame">Acknowledgements</a>
-<li><a href="conform.html" target="_parent">Conformance Testing</a>
+<li><a href="conform.html" target="MainFrame">Conformance Testing</a>
 <li>more docs below...
 </ul>
 
 <b>Download / Install</b>
 <ul>
-<li><a href="download.html" target="_parent">Downloading / Unpacking</a>
+<li><a href="http://www.sourceforge.net/projects/mesa3d" target="_parent">Stable Release (5.0.2)</a>
-<li><a href="install.html" target="_parent">Compiling / Installing</a>
+<li><a href="download.html" target="MainFrame">Downloading/Unpacking</a>
-  <ul>
+<li><a href="install.html" target="MainFrame">Compilation/Installation</a>
-    <li><a href="autoconf.html" target="_parent">Autoconf</a></li>
+<li><a href="glu.html" target="MainFrame">SGI's GLU</a>
-  </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="lists.html" target="MainFrame">Mailing Lists</a>
-<li><a href="bugs.html" target="_parent">Bug Database</a>
+<li><a href="bugs.html" target="MainFrame">Bug Database</a>
-<li><a href="webmaster.html" target="_parent">Webmaster</a>
+<li><a href="webmaster.html" target="MainFrame">Webmaster</a>
-<li><a href="http://dri.freedesktop.org/" target="_parent">Mesa/DRI Wiki</a>
 </ul>
 
 <b>User Topics</b>
 <ul>
-<li><a href="shading.html" target="_parent">Shading Language</a>
+<LI><A HREF="envvars.html" target="MainFrame">Environment Variables</A>
-<li><a href="egl.html" target="_parent">EGL</a>
+<LI><A HREF="osmesa.html" target="MainFrame">Off-Screen Rendering</A>
-<li><a href="opengles.html" target="_parent">OpenGL ES</a>
+<LI><A HREF="pbuffers.html" target="MainFrame">Pbuffer Rendering</A>
-<li><a href="openvg.html" target="_parent">OpenVG / Vega</a>
+<LI><A HREF="debugging.html" target="MainFrame">Debugging Tips</A>
-<li><a href="envvars.html" target="_parent">Environment Variables</a>
+<LI><A HREF="perf.html" target="MainFrame">Performance Tips</A>
-<li><a href="osmesa.html" target="_parent">Off-Screen Rendering</a>
+<LI><A HREF="extensions.html" target="MainFrame">Mesa Extensions</A>
-<li><a href="debugging.html" target="_parent">Debugging Tips</a>
+<LI><A HREF="mangling.html" target="MainFrame">Function Name Mangling</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="application-issues.html" target="_parent">Application Issues</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="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a>
-<li><a href="sourcetree.html" target="_parent">Source Code Tree</a>
+<li><a href="cvs_branches.html" target="MainFrame">CVS Branch Info</a>
-<li><a href="utilities.html" target="_parent">Utilities</a>
+<li><a href="cvs_anonymous.html" target="MainFrame">Anonymous CVS Access</a>
-<li><a href="helpwanted.html" target="_parent">Help Wanted</a>
+<li><a href="utilities.html" target="MainFrame">Utilities</a>
-<li><a href="devinfo.html" target="_parent">Development Notes</a>
+<li><a href="helpwanted.html" target="MainFrame">Help Wanted</a>
-<li><a href="sourcedocs.html" target="_parent">Source Documentation</a>
+<li><a href="devinfo.html" target="MainFrame">Development Notes</a>
-<li><a href="dispatch.html" target="_parent">GL Dispatch</a>
+<li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a>
+<li><a href="subset.html" target="MainFrame">Subset Information</a>
+<li><a href="fbdev-dri.html" target="MainFrame">fbdev/DRI Environment</a>
+<LI><A HREF="custom.html" target="MainFrame">Custom Development</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://dri.sourceforge.net" target="_parent">DRI website</a>
-<li><a href="http://www.freedesktop.org" target="_parent">freedesktop.org</a>
+<li><a href="games.html" target="MainFrame">Games and Entertainment</a>
+<li><a href="libraries.html" target="MainFrame">Libraries and Toolkits</a>
+<li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a>
+<li><a href="science.html" target="MainFrame">Science and Technical</a>
+<li><a href="utility.html" target="MainFrame">Utilities</a>
+<li><a href="demos.html" target="MainFrame">Demos / other</a>
 </ul>
 
-<b>Hosted by:</b>
+<A HREF="http://sourceforge.net"
-<br>
+target="_parent"><IMG SRC="http://sourceforge.net/sflogo.php?group_id=3&type=1"
-<blockquote>
+WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A>
-<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/custom.html

@@ -0,0 +1,25 @@
+<HTML>
+
+<TITLE>Custom Development</TITLE>
+
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
+
+<H1>Custom Development</H1>
+
+<p>
+Mesa is primarily developed and maintained on a volunteer basis.
+Some Mesa development work has been done in conjuction with contracted
+projects, such as the XFree86/DRI drivers.
+</p>
+
+<p>
+<pre>[Begin shameless plug]</pre>
+If you have a need for specific or custom Mesa development work,
+<a href="http://www.tungstengraphics.com/" target="_parent">
+Tungsten Graphics, Inc.</a> may be able to help you.
+<pre>[End shameless plug]</pre>
+</p>
+
+
+</body>
+</html>

docs/cvs_anonymous.html

@@ -0,0 +1,37 @@
+<HTML>
+
+<TITLE>Anonymous CVS</TITLE>
+
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
+
+<H1>Anonymous CVS</H1>
+
+<p>
+Anonymous, public, read-only access to the code in CVS is
+available. Here are the basic instructions for Unix systems:
+</p>
+
+<ol>
+	<li>Install CVS client software on your computer. Version 1.9.28 is known to work.
+	</li><li>Login as an anonymous user: <code>cvs -d:pserver:anonymous@cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d
+	login</code>
+	</li><li>Just hit return at the <code>CVS password:</code> prompt.
+	</li><li>Then checkout mesa: <code>cvs -z3 -d:pserver:anonymous@cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d
+	co Mesa-newtree</code>
+</li></ol>
+
+<p>To update your Mesa CVS source to the latest CVS source:
+
+</p><ol>
+	<li><code>cd Mesa</code>
+	</li><li><code>cvs -z3 -d:pserver:anonymous@cvs.mesa3d.sourceforge.net:/cvsroot/mesa3d
+	update</code>
+</li></ol>
+
+<p>You can browse the Mesa source code in CVS
+<a href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mesa3d/">here.
+</a>
+</p>
+
+</body>
+</html>

docs/cvs_branches.html

@@ -0,0 +1,59 @@
+<HTML>
+
+<TITLE>CVS Branches</TITLE>
+
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
+
+<H1>CVS Branch Information</H1>
+
+<p>
+The Mesa3d sources are split up into two branches. A branch that is to
+remain as stable as possible, and an unstable branch where development
+work for new versions will be done. The current stable branch is
+tagged <code>mesa_3_4_branch</code> while the unstable branch is just
+the default. The goal is to adopt and even/odd stable/unstable
+versioning scheme similar to the Linux kernel. Hence releases of Mesa
+3.2.X should be more stable than Mesa 3.3.X.<p></p> <p>All versions of
+Mesa after 3.0 will also be tagged with a branch id. Mesa 3.1 has the
+tag <code>mesa_3_1</code>, Mesa 3.2 will be <code>mesa_3_2</code>,
+Mesa 3.3 <code>mesa_3_3</code>, etc..</p>
+
+<p>
+To checkout a specific branch of mesa just pass <code>-r</code> and
+the branch tag after your cvs command. For example <code>cvs checkout
+-r mesa_3_4_branch Mesa</code> will checkout the 3.4 branch and
+<code>cvs update -r mesa_3_4_branch</code> will convert your current
+branch to the 3.4 dev branch.
+Consult <a href="http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54"
+target="_parent">http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54</a>
+for more on branching in cvs.
+</p>
+
+<p>
+To see a list of all the CVS branchs run <code>cvs log README</code> (or any
+other file) and look for the section labeled <code>symbolic names</code>.
+You'll see something like this:
+</p>
+
+<pre>  symbolic names:
+        mesa_4_0: 1.3
+        mesa_4_0_branch: 1.3.0.6
+        mesa_3_5: 1.3
+        mesa_3_4_2: 1.3
+        mesa_3_4_1: 1.3
+        mesa_3_4: 1.3
+        mesa_3_4_branch: 1.3.0.4
+        mesa_3_3: 1.3
+        mesa_3_2_1: 1.1.1.1
+        mesa_3_3_texture_env_combine2: 1.3.0.2
+        mesa_3_2: 1.1.1.1
+        mesa_3_2_beta_1: 1.1.1.1
+        mesa_3_1: 1.1.1.1
+        mesa_3_2_dev: 1.1.1.1.0.2
+        mesa_3_1_beta_3: 1.1.1.1
+        start: 1.1.1.1
+        mesa: 1.1.1
+</pre>
+
+</body>
+</html>

docs/debugging.html

@@ -1,20 +1,10 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<HTML>
-<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">
+<TITLE>Debugging Tips</TITLE>
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
 
-<iframe src="contents.html"></iframe>
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
-<div class="content">
 
-<h1>Debugging Tips</h1>
+<H1>Debugging Tips</H1>
 
 <p>
    Normally Mesa (and OpenGL) records but does not notify the user of
@@ -42,6 +32,5 @@
    src/dlist.c for details.
 </p>
 
-</div>
+</BODY>
-</body>
+</HTML>
-</html>

docs/demos.html

@@ -0,0 +1,16 @@
+<HTML>
+
+<TITLE>Demos</TITLE>
+
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
+
+<H1>Demos</H1>
+
+
+<ul>
+<li><a href="http://www.geocities.com/shobhand/homepage.html">Shobhan Dutta's Geartrain and Walkthrough Demos</a>
+</li></ul>
+
+
+</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,71 +1,42 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<HTML>
-<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">
+<TITLE>Development Notes</TITLE>
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
 
-<iframe src="contents.html"></iframe>
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
-<div class="content">
 
-<h1>Development Notes</h1>
+<H1>Development Notes</H1>
 
 
-<h2>Adding Extensions</h2>
+<H2>Adding Extentions</H2>
 
 <p>
-To add a new GL extension to Mesa you have to do at least the following.
+To add a new GL extension to Mesa you have to do the following.
+<pre>
+   If glext.h doesn't define the extension, edit include/GL/gl.h and add:
+	- new enum tokens
+	- new API function entry points
+	- #define GL_EXT_the_extension_name 1
 
-<ul>
+   If adding a new API function (call it glNewFunctionEXT):
-<li>
+	- insert glNewFunctionEXT()into src/apiext.h
-   If glext.h doesn't define the extension, edit include/GL/gl.h and add
+	- edit src/types.h and add NewFunction to the gl_api_table struct
-   code like this:
+	- implement gl_NewFunction() in the appropriate src file
-   <pre>
+	- hook gl_NewFunction() into pointers.c
-     #ifndef GL_EXT_the_extension_name
+	- add display list support in dlist.c for save_NewFunction()
-     #define GL_EXT_the_extension_name 1
+	- add glNewFunctionEXT to gl_GetProcAddress() in extensions.c or
-     /* declare the new enum tokens */
+	  in the device driver's GetProcAddress() function if appropriate
-     /* prototype the new functions */
+</pre>
-     /* TYPEDEFS for the new functions */
+<p>
-     #endif
+If adding new GL state be sure to update get.c and enable.c
-   </pre>
+</p>
-</li>
+<p>
-<li>
+In general, look for an extension similar to the new one that's already
-   In the src/mapi/glapi/gen/ directory, add the new extension functions and
+implemented in Mesa and follow it by example.
-   enums to the gl_API.xml file.
+</p>
-   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>
-<li>
-   The dispatch tests check_table.cpp and dispatch_sanity.cpp
-   should be updated with details about the new extensions functions. These
-   tests are run using 'make check'
-</li>
-</ul>
 
 
 
-<h2>Coding Style</h2>
+<H2>Coding Style</H2>
 
 <p>
 Mesa's code style has changed over the years.  Here's the latest.
@@ -84,13 +55,6 @@ well documented.  Also, strive to write clean, easily understandable code.
 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>
@@ -101,29 +65,13 @@ Brace example:
 	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
+	indent -br -i3 -npcs infile.c -o outfile.c
 </pre>
 
 
@@ -136,185 +84,147 @@ Constants and macros are ALL_UPPERCASE, with _ between words
 </p>
 
 <p>
-Global variables are not allowed.
+Global vars not allowed.
 </p>
 
 <p>
 Function name examples:
 </p>
 <pre>
-	glFooBar()       - a public GL entry point (in glapi_dispatch.c)
+	glFooBar()       - a public GL entry point (in 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>Submitting patches</h2>
+<H2>Writing a Device Driver</H2>
 
 <p>
-You should always run the Mesa Testsuite before submitting patches.
+XXX to do
-The Testsuite can be run using the 'make check' command. All tests
-must pass before patches will be accepted, this may mean you have
-to update the tests themselves.
 </p>
 
-<p>
-Patches should be sent to the Mesa mailing list for review.
-When submitting a patch make sure to use git send-email rather than attaching
-patches to emails. Sending patches as attachments prevents people from being
-able to provide in-line review comments.
-</p>
 
-<p>
-When submitting follow-up patches you can use --in-reply-to to make v2, v3,
-etc patches show up as replies to the originals. This usually works well
-when you're sending out updates to individual patches (as opposed to
-re-sending the whole series). Using --in-reply-to makes
-it harder for reviewers to accidentally review old patches.
-</p>
 
-<h2>Marking a commit as a candidate for a stable branch</h2>
+<H2>Making a New Mesa Release</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>CC: &lt;mesa-stable@lists.freedesktop.org&gt;</li>
-  <li>CC: "9.2 10.0" &lt;mesa-stable@lists.freedesktop.org&gt;</li>
-  <li>CC: "10.0" &lt;mesa-stable@lists.freedesktop.org&gt;</li>
-</ul>
-
-Simply adding the CC to the mesa-stable list address is adequate to nominate
-the commit for the most-recently-created stable branch. It is only necessary
-to specify a specific branch name, (such as "9.2 10.0" or "10.0" in the
-examples above), if you want to nominate the commit for an older stable
-branch. And, as in these examples, you can nominate the commit for the older
-branch in addition to the more recent branch, or nominate the commit
-exclusively for the older branch.
-
-This "CC" syntax for patch nomination will cause patches to automatically be
-copied to the mesa-stable@ mailing list when you use "git send-email" to send
-patches to the mesa-dev@ mailing list. Also, if you realize that a commit
-should be nominated for the stable branch after it has already been committed,
-you can send a note directly to the mesa-stable@lists.freedesktop.org where
-the Mesa stable-branch maintainers will receive it. Be sure to mention the
-commit ID of the commit of interest (as it appears in the mesa master branch).
-
-The latest set of patches that have been nominated, accepted, or rejected for
-the upcoming stable release can always be seen on the
-<a href=http://cworth.org/~cworth/mesa-stable-queue/">Mesa Stable Queue</a>
-page.
-
-<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
+Prerequisites (later versions may work):
-branch is relevant.
 </p>
-
+<ul>
-
+<li>	autoconf 2.50
-<h3>Verify and update version info in VERSION</h3>
+<li>	automake 1.4-p2
+<li>	libtool 1.4
+</ul>
 
 <p>
-Create a docs/relnotes/x.y.z.html file.
+Be sure to do a "cvs update -d ." in the Mesa directory to
-The bin/bugzilla_mesa.sh and bin/shortlog_mesa.sh scripts can be used to
+get all the latest files.
-create the HTML-formatted lists of bugfixes and 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>.
+Update the version definitions in src/version.h
 </p>
 
 <p>
-Tag the files with the release name (in the form <b>mesa-x.y</b>)
+Create/edit the docs/RELNOTES-X.Y file to document what's new in the release.
-with: <code>git tag -s mesa-x.y -m "Mesa x.y Release"</code>
+Edit the docs/VERSIONS file too.
-Then: <code>git push origin mesa-x.y</code>
 </p>
 
+<p>
+Edit Make-config and change the MESA_MAJOR and/or MESA_MINOR versions.
+</p>
+
+<p>
+Edit the GNU configure stuff to change versions numbers as needed:
+Update the version string (second argument) in the line
+"AM_INIT_AUTOMAKE(Mesa, 3.3)" in the configure.in file.
+</p>
+
+<p>
+Remove the leading `dnl' from the line "dnl AM_MAINTAINER_MODE".
+</p>
+
+<p>
+Verify the version numbers near the top of configure.in
+</p>
+
+<p>
+Run "fixam -f" to disable automatic dependency tracking.
+</p>
+
+<p>
+Run the bootstrap script to generate the configure script.
+</p>
+
+<p>
+Edit Makefile.X11 and verify DIRECTORY is set correctly.  The Mesa
+sources must be in that directory (or there must be a symbolic link).
+</p>
+
+<p>
+Edit Makefile.X11 and verify that LIB_NAME and DEMO_NAME are correct.
+If it's a beta release, be sure the bump up the beta release number.
+</p>
+
+<p>
+cp Makefile.X11 to Makefile so that the old-style Mesa makefiles
+still work.  ./configure will overwrite it if that's what the user runs.
+</p>
+
+<p>
+Make a symbolic link from $(DIRECTORY) to Mesa.  For example,
+ln -s Mesa Mesa-3.3    This is needed in order to make a correct
+tar file in the next step.
+</p>
 
-<h3>Make the tarballs</h3>
 <p>
 Make the distribution files.  From inside the Mesa directory:
 <pre>
-	./autogen.sh
+	make -f Makefile.X11 lib_tar
-	make tarballs
+	make -f Makefile.X11 demo_tar
+	make -f Makefile.X11 lib_zip
+	make -f Makefile.X11 demo_zip
 </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>
-Make a new directory for the release on annarchy.freedesktop.org with:
+Upload the *.tar.gz and *.zip files to ftp.mesa3d.org
-<br>
-<code>
-mkdir /srv/ftp.freedesktop.org/pub/mesa/x.y
-</code>
 </p>
 
 <p>
-Basically, to upload the tarball files with:
+Update the web site.
-<br>
-<code>
-rsync -avP -e ssh MesaLib-x.y.* USERNAME@annarchy.freedesktop.org:/srv/ftp.freedesktop.org/pub/mesa/x.y/
-</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>3</em><em>d</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>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em>,
-<em>mesa-dev@lists.freedesktop.org</em>,
+<em>m</em><em>e</em><em>s</em><em>a</em><em>3</em><em>d</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>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em>
-<em>mesa-users@lists.freedesktop.org</em>
 and
-<em>mesa-announce@lists.freedesktop.org</em>
+<em>m</em><em>e</em><em>s</em><em>a</em><em>3</em><em>d</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>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em>
 </p>
 
-</div>
+
+<H2>Autoconf info</H2>
+
+<p>
+In order to run the bootstrap script you'll need:
+<p>
+<pre>
+autoconf 2.50
+automake 1.4-p5
+libtool 1.4
+</pre>
+
+
 </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 every 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
-different 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 preceding 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 assembly 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 assembly 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 +1,104 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<HTML>
-<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">
+<TITLE>Getting Mesa</TITLE>
-  <h1>The Mesa 3D Graphics Library</h1>
-</div>
 
-<iframe src="contents.html"></iframe>
+<BODY text="#000000" bgcolor="#55bbff" link="#111188">
-<div class="content">
 
-<h1>Downloading</h1>
+<H1>Downloading / Unpacking</H1>
 
 <p>
-Primary Mesa download site:
+Mesa can be downloaded from the
-<a href="ftp://ftp.freedesktop.org/pub/mesa/">freedesktop.org</a> (FTP)
+<a href="http://www.sourceforge.net/projects/mesa3d" target="_parent">
+SourceForge download area</A>.
 </p>
 
 <p>
-When a new release is coming, release candidates (betas) may be found
+Since version 2.3, Mesa is distributed in two pieces:  main library code
-<a href="ftp://ftp.freedesktop.org/pub/mesa/beta/">here</a>.
+and demos.  If you're upgrading from a previous version of Mesa or you're not
-</p>
+interested in the demos you can just download the core Mesa archive file.
-
-
-<h1>Unpacking</h1>
-
-<p>
-Mesa releases are available in three formats: .tar.bz2, .tar.gz, and .zip
 </p>
 
 <p>
-To unpack .tar.gz files:
+Mesa is available in at least three archive formats:
 </p>
+
 <pre>
-	tar zxf MesaLib-x.y.z.tar.gz
+1. GNU zip/tar
-</pre>
+
-or
+	Download MesaLib-X.Y.tar.gz and optionally MesaDemos-X.Y.tar.gz
-<pre>
+	Unpack with:
-	gzcat MesaLib-x.y.z.tar.gz | tar xf -
+		gzcat MesaLib-X.Y.tar.gz | tar xf -
-</pre>
+		gzcat MesaDemos-X.Y.tar.gz | tar xf -
-or
+	or
-<pre>
+		gunzip MesaLib-X.Y.tar.gz ; tar xf MesaLib-X.Y.tar
-	gunzip MesaLib-x.y.z.tar.gz ; tar xf MesaLib-x.y.z.tar
+		gunzip MesaDemos-X.Y.tar.gz ; tar xf MesaLib-X.Y.tar
-</pre>
+	or
-<p>
+		tar zxf MesaLib-X.Y.tar.gz
-To unpack .tar.bz2 files:
+		tar zxf MesaDemos-X.Y.tar.gz
-</p>
+
-<pre>
+	If you don't have gzcat try zcat instead.
-	bunzip2 -c MesaLib-x.y.z.tar.gz | tar xf -
+
-</pre>
+2. Unix compressed/tar
-<p>
+
-To unpack .zip files:
+	Download MesaLib-X.Y.tar.Z and optionally MesaDemos-X.Y.tar.Z
-</p>
+	Unpack with:
-<pre>
+		zcat MesaLib-X.Y.tar.Z | tar xf -
-	unzip MesaLib-x.y.z.zip
+		zcat MesaDemos-X.Y.tar.Z | tar xf -
+
+3. ZIP format
+
+	Download MesaLib-X.Y.zip and optionally MesaDemos-X.Y.zip
+	Unpack with:
+		unzip MesaLib-X.Y.zip
+		unzip MesaDemos-X.Y.zip
 </pre>
 
-
-<h1>Contents</h1>
-
 <p>
-After unpacking you'll have these files and directories (among others):
+After unpacking you'll have these directories (and more):
 </p>
 <pre>
-Makefile	- top-level Makefile for most systems
+Makefile.X11	- top-level Makefile for X11-based systems
-configs/	- makefile parameter files for various systems
+Make-config	- system configurations used by the Makefile.X11
 include/	- GL header (include) files
 bin/		- shell scripts for making shared libraries, etc
+lib/		- final client libraries, created during compilation
 docs/		- documentation
 src/		- source code for libraries
 src/mesa	- sources for the main Mesa library and device drivers
-src/gallium     - sources for Gallium and Gallium drivers
+src/glu		- libGLU source code
-src/glx		- sources for building libGL with full GLX and DRI support
+src/glw		- Xt/Motif/OpenGL widget code
+
+
+and if you downloaded and unpacked the MesaDemos.X.Y archive:
+
+src/glut	- GLUT source code
+progs/		- OpenGL programs
+progs/demos	- original Mesa demos
+progs/xdemos	- GLX OpenGL/Mesa demos
+progs/redbook	- examples from the OpenGL Programming Guide
+progs/samples	- examples from SGI
+progs/images/	- image files
+
 </pre>
 
-
 <p>
-Proceed to the <a href="install.html">compilation and installation
+Proceed to <a href="install.html">compilation and installation
 instructions</a>.
 </p>
 
-
+<H1>GLUT</H1>
-<h1>Demos, GLUT, and GLU</h1>
 
 <p>
-A package of SGI's GLU library is available
+Mesa 2.5 and later includes Mark Kilgard's GLUT library (GL Utility Toolkit).
-<a href="ftp://ftp.freedesktop.org/pub/mesa/glu/">here</a>
+GLUT is built automatically on systems which support it.
 </p>
-
 <p>
-A package of Mark Kilgard's GLUT library is available
+The GLUT tests, demos, examples, etc are not included, just the main library.
-<a href="ftp://ftp.freedesktop.org/pub/mesa/glut/">here</a>
+To obtain the latest complete release of GLUT please visit the
+<a href="http://www.opengl.org/developers/documentation/glut/index.html"
+target ="_parent">GLUT homepage</a>
 </p>
 
-<p>
-The Mesa demos collection is available
-<a href="ftp://ftp.freedesktop.org/pub/mesa/demos/">here</a>
-</p>
 
-<p>
+</BODY>
-In the past, GLUT, GLU and the Mesa demos were released in conjunction with
+</HTML>
-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,331 +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
-separated 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
-hardware 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>
-
-<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>
-
-<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
-through <code>eglReleaseThread</code>, all current display resources should be
-released.  Another way to destroy 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>