Compare commits

..

138 Commits

Author SHA1 Message Date
Brian Paul
2005348110 updated a few of the issues in appendix A 2003-01-20 17:55:55 +00:00
Brian Paul
634a7b2f00 describe libGL 2003-01-20 15:01:39 +00:00
Brian Paul
d73e21620a new Makefiles for miniglx 2003-01-20 14:54:50 +00:00
Keith Whitwell
d5cfbef5ad Remove -C option to install 2003-01-20 14:50:18 +00:00
Jose Fonseca
1d08fddfe6 Tell CVS to ignore Doxygen tag files and output directories. 2003-01-20 14:34:41 +00:00
Jose Fonseca
447ea351dd Some spellchecking fixes. 2003-01-20 14:30:04 +00:00
Keith Whitwell
0ebc838481 Add USE_MINIGLX flags. Build as a miniglx application. 2003-01-20 11:26:30 +00:00
Keith Whitwell
14a7a05251 Make more demanding 2003-01-20 11:25:50 +00:00
Keith Whitwell
c2edc07196 Fix typo 2003-01-20 11:24:17 +00:00
Keith Whitwell
222a212569 Build radeon.o from toplevel makefile.
Add comments to example.miniglx.conf.
Install a minglx.conf in lib directory.
Remove unused 'drmModuleName' config option
2003-01-20 10:53:34 +00:00
Keith Whitwell
78469e6e3d Notes on setting up a machine to run MiniGLX apps and a list of
available demos in the source tree.
2003-01-20 10:51:04 +00:00
Brian Paul
63d0a9055c minor fixes (remove some \internal attributes) 2003-01-19 23:48:32 +00:00
Keith Whitwell
27834f06b8 Some documentation updates relating to recent changes 2003-01-19 20:11:26 +00:00
Jose Fonseca
c262531518 Fixed several typos from spell-checking. 2003-01-19 18:47:53 +00:00
Jose Fonseca
1b2c02ae98 Some documentation fixes that were left out of previous commits 2003-01-19 14:23:45 +00:00
Jose Fonseca
fb5f90d71b Rewriten some of the detail documentation to improve readability.
Several fixes.
2003-01-19 14:08:20 +00:00
Jose Fonseca
4fb1eb7be2 Add the missing detailed documentation bits on miniglx.c and xf86drm.c.
Several updates and fixes to the documentation.
2003-01-19 12:18:08 +00:00
Jose Fonseca
cf119744c3 More detailed documentation. 2003-01-19 01:57:45 +00:00
Keith Whitwell
b07ed0113a Use frontbuffer if GLUT_DOUBLE not requested 2003-01-18 19:59:27 +00:00
Jose Fonseca
d6d8d1dfce Detailed documention for glapi.c. Brief description of the structures in sarea.h. Minor fix in drm.h. 2003-01-18 13:42:06 +00:00
Jose Fonseca
f483ebddeb Enable the documentation of static functions and also the internal documentation. 2003-01-18 13:01:17 +00:00
Keith Whitwell
35fe61ce7b Remove debug printf 2003-01-18 12:41:55 +00:00
Keith Whitwell
c3b1d1e63c Restore registers clobbered by radeonfb.o -- prevents slowdown to 200fps
of mesa demos.
2003-01-18 12:41:34 +00:00
Keith Whitwell
38bfead7d3 Remove some unused members from RADEONInfoRec, add saved value for
crtc_offset_cntl
2003-01-18 12:38:40 +00:00
Keith Whitwell
56f57500b9 Add PostValidateMode hook to allow drivers to restore registers after
fbdev has finished clobbering them.
2003-01-18 12:25:56 +00:00
Keith Whitwell
2ce0615ef1 Remove chipset line from example miniglx.conf 2003-01-18 12:17:02 +00:00
Keith Whitwell
559af8ace4 Probe for chipset if one isn't supplied 2003-01-18 12:16:16 +00:00
Keith Whitwell
f73e37e154 A standalone build environment for radeonfb.o, incorporating necessary
fixes from Ani Joshi and others.  This is probably the only version of
radeonfb that we can run against at the moment, so include it here.
2003-01-18 11:15:47 +00:00
Brian Paul
ec5b054b8f fix up loose ends 2003-01-17 21:45:04 +00:00
Brian Paul
8a63d4bc99 new Makefiles for subset 2003-01-17 21:21:57 +00:00
Keith Whitwell
f58e67787f Get colors working in 16bpp 2003-01-17 19:01:22 +00:00
Keith Whitwell
deb4d4de47 add support for 16bpp modes, disabled 2003-01-17 16:19:15 +00:00
Keith Whitwell
1449a2f759 Take stride properly into account when setting up window members. 2003-01-17 00:56:14 +00:00
Keith Whitwell
f0b66442e8 Clear framebuffer at startup 2003-01-17 00:36:05 +00:00
Keith Whitwell
8830b0a941 Make miniglut exit() on error, like real glut. 2003-01-17 00:32:50 +00:00
Keith Whitwell
deb5fe3b68 use a fixed resolution defined in a config file 2003-01-16 23:39:30 +00:00
Brian Paul
1e1e71e3a7 lots of updates, practically finished 2003-01-16 23:15:28 +00:00
Keith Whitwell
53362d8858 get conform working 2003-01-14 16:52:40 +00:00
Keith Whitwell
af82796ed1 Remove debug printf 2003-01-14 11:39:11 +00:00
Jose Fonseca
6ded963ac6 Documentation for most of the DRM ioctls argument structures in drm.h.
Fixes to the xf86drm.c documentation.
2003-01-13 16:02:32 +00:00
Keith Whitwell
b4f35d5191 example miniglx.conf 2003-01-13 15:34:00 +00:00
Keith Whitwell
0b9434aafd Add config file facility and remove hardwired options from minglx.c
Move functionality for setting up glx configs into the drivers.
Allow the driver to tweak modes (eg for pitch) before setting up fbdev.
2003-01-13 15:31:31 +00:00
Jose Fonseca
fb02d9f4eb Big chunk of documention of xf86drm.c. Some oddities left to document, and still needs a review to catch typos. 2003-01-13 14:36:40 +00:00
Brian Paul
2b83583994 s/union/enum/ 2003-01-11 14:13:25 +00:00
Brian Paul
76415ea859 tweaks to Doxygen config files 2003-01-10 21:57:59 +00:00
Brian Paul
10d05983ef documentation updates 2003-01-10 21:57:41 +00:00
Brian Paul
7c35ac6e82 doc updates, new PixelFormat enum 2003-01-10 21:56:04 +00:00
Keith Whitwell
ca9cccd81c Fix GLUT_ELAPSED_TIME query 2003-01-10 17:47:49 +00:00
Jose Fonseca
ea9f98b04b Enable internal documentation in doxy/miniglx.doxy.
Enable private and static documention in doxy/core.doxy (necessary now for src/glapi.c and others later).
2003-01-09 20:37:02 +00:00
Brian Paul
8b4a34dcdb Initial check in. 2003-01-09 18:24:46 +00:00
Keith Whitwell
267bc32309 Add documentation for GLX_DEPTH_SIZE 2003-01-09 16:54:49 +00:00
Keith Whitwell
8618425250 Remove some more unused functions 2003-01-09 15:16:57 +00:00
Keith Whitwell
24259ec2d0 Bump window sizes up to next supported size when choosing modes.
Recognize the GLX_DEPTH_SIZE attrib.
2003-01-09 15:16:35 +00:00
Keith Whitwell
97aa6f3734 Initialize lastStamp to 1, so that drivers know they need to update
(ie initialize) their internal data.
2003-01-09 15:15:33 +00:00
Keith Whitwell
6b723c7720 Add section on porting apps glx->miniglx 2003-01-09 15:14:24 +00:00
Keith Whitwell
211f26ca95 more cleanups 2003-01-09 15:13:49 +00:00
Keith Whitwell
df7cbe873e Remove earlier workaround 2003-01-09 15:12:38 +00:00
Keith Whitwell
da8a7e15a6 Build the full driver for now 2003-01-09 15:12:04 +00:00
Keith Whitwell
f6546f8384 Barebones glut-alike - just enough to get the mesa demos working 2003-01-09 12:43:40 +00:00
Keith Whitwell
cd22e4b78c Remove some debug 2003-01-03 11:37:10 +00:00
Keith Whitwell
5ff65a62df Require radeon.o 1.8.x 2003-01-02 19:02:23 +00:00
Keith Whitwell
fd55975710 Take advantage of the fact that the kernel module can now shut itself
down cleanly
2003-01-02 18:49:34 +00:00
Keith Whitwell
c83b869ed2 Cleanups 2003-01-02 18:47:05 +00:00
Keith Whitwell
592250e9fc Add a bit of compile-time flexibility 2003-01-02 18:44:41 +00:00
Keith Whitwell
cdb267a918 Allow the standard radeon driver to be built without the swrast and swtnl
modules.  This effectively merges the radeon-es driver back into the
radeon driver as a compile-time option.
2002-12-30 17:24:05 +00:00
Keith Whitwell
2c2bcf8268 Lay ground work for cut-down radeon driver.
NOTE: commented out a couple of places where core mesa calls directly into
      the swrast module.
2002-12-30 15:20:35 +00:00
Keith Whitwell
695b197cb2 Bring some more initialization code from the 2d driver. 2d accels now
work (glClear).  Pageflip now works for swapbuffers.
2002-12-30 13:15:55 +00:00
Keith Whitwell
e17d611067 Remove dead code 2002-12-27 13:17:53 +00:00
Keith Whitwell
9df9883a7a Do a better job of initializing the __DRIdrawablePrivate in driCreateDrawable 2002-12-27 13:07:11 +00:00
Keith Whitwell
22477c050e Turn off stereo flag in visual configs. 2002-12-27 11:25:08 +00:00
Keith Whitwell
39afeb7cf0 Resolve stability issues starting & stopping radeon driver.
Add drmtest program to exercise the drm without the added complications of
a full driver.

Bring fb driver uptodate with changes for hw drivers.
2002-12-25 12:51:21 +00:00
Keith Whitwell
9363bd862f missing files 2002-12-23 12:18:14 +00:00
Jose Fonseca
83b936adb3 Better documentation to the data structures of miniglx.h and miniglxP.h.
Document the implementation details of most of the public functions in
miniglx.c. These details are under the doxygen's \internal tag so their
presence in the output documentation is controlled by the INTERNAL_DOCS =
YES|NO variable in the doxygen configurations files.
2002-12-22 17:11:04 +00:00
Jose Fonseca
5134d4a98b Apply the doxygen treatment to some [big] files. Some enhancements. 2002-12-21 19:06:06 +00:00
Jose Fonseca
2481eda853 Give the doxygen treatment to include/GL/miniglx.h and src/miniglx/miniglxP.h.
More documentation fixes and enhancements to src/miniglx/miniglx.c.
2002-12-21 02:47:26 +00:00
Jose Fonseca
6b31afc236 Enable documentation for private and static members.
Disable the included file listing.
2002-12-21 02:43:09 +00:00
Jose Fonseca
8fd39b4e8c Added caller documentation to the remaining public API functions.
Renamed some function arguments to match the original Xlib and GLX documentation.
2002-12-20 19:41:41 +00:00
Keith Whitwell
094eed79c2 miniglxtest runs to completion and exits with radeon driver,
but produces no graphical output.
2002-12-20 15:07:56 +00:00
Jose Fonseca
d20f1768a6 Added documentation to some functions plus a main page with introduction and references to Mini GLX. 2002-12-20 01:28:15 +00:00
Keith Whitwell
3e06eed70a Move dri initialization into XCreateWindow 2002-12-19 13:48:27 +00:00
Keith Whitwell
3e13551969 eliminate unresolved symbols 2002-12-19 12:26:15 +00:00
Keith Whitwell
3af2be61fd Radeon driver and hw init code compiles. 2002-12-19 10:16:18 +00:00
Keith Whitwell
eb7eb6e171 restore some 'drmFree' strings previously clobbered 2002-12-18 15:34:22 +00:00
Keith Whitwell
e931e819f9 Remove references to ScrnInfoPtr 2002-12-18 14:52:58 +00:00
Jose Fonseca
95936ee9ba Added doxy/miniglx.doxy based on doxy/core.doxy.
Fixed typo in doxy/README.
2002-12-18 14:31:51 +00:00
Keith Whitwell
157d9a5ac6 remove some more unused functions 2002-12-16 18:55:42 +00:00
Keith Whitwell
134930b627 remove old comment 2002-12-16 18:38:29 +00:00
Keith Whitwell
a97ce86232 Dumb framebuffer driver now in pretty good shape, though some operations
(like swapbuffers) are quite slow because the backbuffer lives in video
ram.
2002-12-16 13:40:44 +00:00
Keith Whitwell
5ca95653c4 miniglxtest.c works against swrast driver 2002-12-13 15:18:09 +00:00
Keith Whitwell
1f01a4b3b6 miniglx test will run with fb_dri.so (ie. swrast) driver, but output is
garbled.
2002-12-12 14:22:02 +00:00
Keith Whitwell
8645472e00 new files 2002-12-11 14:44:09 +00:00
Keith Whitwell
1929cacdbf more cleanups 2002-12-11 14:41:20 +00:00
Brian Paul
65e30ac06a minor tweaks 2002-12-09 22:34:40 +00:00
Brian Paul
941efe8eda added XGetVisualInfo, glXGetConfig plus misc comments and clean-ups 2002-12-09 22:33:09 +00:00
Keith Whitwell
ea4b887ef7 readded 2002-12-06 16:24:07 +00:00
Keith Whitwell
ba8e63f05b Get rid of the 'proper' glx files -- glxclient.h, glxext.c
Move the interface lines for dri drivers -- the __driUtil functions which
know a lot about glx internals now live here.
2002-12-06 16:19:45 +00:00
Keith Whitwell
117a2d76b6 Remove -lX11 from miniglx link libraries... 2002-12-04 16:03:49 +00:00
Keith Whitwell
ce75913702 Caught a couple of things after a clean build on rh 7.3 2002-12-04 16:00:05 +00:00
Keith Whitwell
cbc41d4332 Remove the USE_DRI=0 case -- this is now in drv/fb/fb_dri.c 2002-12-04 15:33:12 +00:00
Keith Whitwell
40af4d7662 A full radeon driver, seems to build ok, haven't run yet 2002-12-04 15:31:04 +00:00
Brian Paul
702b2802a0 added XFree() and glXQueryVersion() 2002-12-04 15:25:37 +00:00
Keith Whitwell
44e4e437a0 new file 2002-12-04 13:09:17 +00:00
Keith Whitwell
366ca58ea6 new makefiles to build modules as .a files 2002-12-04 12:48:09 +00:00
Keith Whitwell
90925c9777 ignore .d files 2002-12-03 22:30:41 +00:00
Brian Paul
f6b40da9a7 *** empty log message *** 2002-12-03 21:27:54 +00:00
Keith Whitwell
80798c8eab minor changes from the end of last week 2002-12-03 17:38:19 +00:00
Brian Paul
65a7a3852d miniglx.c now loads DRI drivers. glxext.c and glxclient.h no longer needed.
Many functions in XF86DRI.c are #ifdef'd out and need new implementations.
2002-11-29 16:07:51 +00:00
Brian Paul
cf8aede714 mask is always non-null in write_rgba_pixels and write_monorgba_pixels 2002-11-28 15:55:41 +00:00
Brian Paul
1e27ca69f8 fixed breakage from last check-in, more clean-ups 2002-11-28 00:24:04 +00:00
Brian Paul
9fcd566e60 added DRI awareness (incomplete, disabled by default) 2002-11-28 00:03:07 +00:00
Brian Paul
78b5f5f44f remove resize() function 2002-11-27 21:04:18 +00:00
Brian Paul
8a82d9db15 support more screen sizes, more clean-ups 2002-11-27 21:03:33 +00:00
Brian Paul
fa747cdb0a miniglx layered on fbdev works now. 2002-11-27 17:02:39 +00:00
Keith Whitwell
fa50fae202 Narrow down the missing bits of information 2002-11-27 16:31:27 +00:00
Keith Whitwell
0fb48dba7c pull in more server code, particularly for radeon init 2002-11-27 15:52:13 +00:00
Keith Whitwell
2f3585d4f1 Auto-dependency generating makefile 2002-11-27 13:58:53 +00:00
Brian Paul
7c7789c029 do some simple MMIO register reads for sanity testing 2002-11-27 00:26:59 +00:00
Brian Paul
56ad63958b set timing values explicitly. new debugging info 2002-11-26 21:20:45 +00:00
Brian Paul
aa0109bf96 move WindowExists() code into glxext.c (effectively out of the driver) 2002-11-26 18:18:54 +00:00
Keith Whitwell
0201db5a22 Added two files which should (with much tweaking) eventually allow
the radeon_dri.so driver from the dri project to be loaded and run
against an fbdev environment.
2002-11-26 17:39:32 +00:00
Brian Paul
1a1069c7e9 more trimming / hacking 2002-11-25 21:38:08 +00:00
Brian Paul
fc88680a39 more tweaks 2002-11-22 16:13:49 +00:00
Brian Paul
ff89f4b639 fix some bugs, add colormap initialization 2002-11-22 15:26:56 +00:00
Brian Paul
7d5b5c0438 added glfbdevtest and miniglxtest 2002-11-22 00:19:31 +00:00
Brian Paul
6ccaeaaa16 from DRI CVS - hacked to some extent 2002-11-21 16:42:51 +00:00
Brian Paul
e4e72da501 from Mesa 5.1 2002-11-21 16:00:27 +00:00
Brian Paul
67f87d2463 disable thread safety for now 2002-11-21 15:45:55 +00:00
Brian Paul
431c1740d5 compile glfbdev.c and miniglx.c 2002-11-21 14:59:05 +00:00
Brian Paul
fa3f447234 fixed cube texture auto-mipmap generation bug (641363) 2002-11-20 21:40:02 +00:00
Brian Paul
3a08052714 stripped, subsetted DRI-capable libGL 2002-11-20 18:09:51 +00:00
Brian Paul
424096d581 prototype interfaces and tests 2002-11-20 02:10:37 +00:00
Brian Paul
2e5a88ab6a oops, wrong branch 2002-11-20 02:09:57 +00:00
Brian Paul
d520ff08d0 tests for new interfaces 2002-11-20 01:54:12 +00:00
Brian Paul
ef0e1dcc2e prototypes for new interfaces 2002-11-20 01:53:24 +00:00
Brian Paul
6412641b19 put FEATURE_NV_vertex_program around vpstate.h include 2002-11-19 15:25:16 +00:00
Brian Paul
3ee066b48f missed a couple version string updates 2002-11-14 16:16:45 +00:00
Brian Paul
33c0b3e233 patches from Karl 2002-11-13 22:26:23 +00:00
Brian Paul
658145bd82 fix compilation problem (Philippe Houdoin) 2002-11-13 22:21:47 +00:00
5478 changed files with 447841 additions and 1503926 deletions

View File

@@ -1,12 +0,0 @@
((prog-mode
(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))
)

4
.gitattributes vendored
View File

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

48
.gitignore vendored
View File

@@ -1,48 +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
*.tar.xz
*.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
.install-mesa-links

View File

@@ -1,89 +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 -D_GNU_SOURCE
else
LOCAL_CC := $(TARGET_CC) -std=c99
endif
endif
LOCAL_C_INCLUDES += \
$(MESA_TOP)/src \
$(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___BUILTIN_EXPECT \
-DHAVE___BUILTIN_FFS \
-DHAVE___BUILTIN_FFSLL \
-DHAVE_FUNC_ATTRIBUTE_FLATTEN \
-DHAVE_FUNC_ATTRIBUTE_UNUSED \
-DHAVE_FUNC_ATTRIBUTE_FORMAT \
-DHAVE_FUNC_ATTRIBUTE_PACKED \
-DHAVE___BUILTIN_CTZ \
-DHAVE___BUILTIN_POPCOUNT \
-DHAVE___BUILTIN_POPCOUNTLL \
-DHAVE___BUILTIN_CLZ \
-DHAVE___BUILTIN_CLZLL \
-DHAVE___BUILTIN_UNREACHABLE \
-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
ifeq ($(MESA_ENABLE_LLVM),true)
LOCAL_CFLAGS += \
-DHAVE_LLVM=0x0305 -DLLVM_VERSION_PATCH=2 \
-D__STDC_CONSTANT_MACROS \
-D__STDC_FORMAT_MACROS \
-D__STDC_LIMIT_MACROS
endif
LOCAL_CPPFLAGS += \
$(if $(filter true,$(MESA_LOLLIPOP_BUILD)),-D_USING_LIBCXX) \
-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

View File

@@ -1,104 +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 freedreno i915g ilo nouveau r300g r600g radeonsi vc4 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)
ifeq ($(filter 1 2 3 4,$(MESA_ANDROID_MAJOR_VERSION)),)
MESA_LOLLIPOP_BUILD := true
else
define local-generated-sources-dir
$(call local-intermediates-dir)
endef
endif
MESA_COMMON_MK := $(MESA_TOP)/Android.common.mk
MESA_PYTHON2 := python
DRM_GRALLOC_TOP := hardware/drm_gralloc
classic_drivers := i915 i965
gallium_drivers := swrast freedreno i915g ilo nouveau r300g r600g radeonsi vmwgfx vc4
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
MESA_ENABLE_LLVM := $(if $(filter radeonsi,$(MESA_GPU_DRIVERS)),true,false)
# add subdirectories
ifneq ($(strip $(MESA_GPU_DRIVERS)),)
SUBDIRS := \
src/loader \
src/mapi \
src/glsl \
src/mesa \
src/util \
src/egl/main \
src/egl/drivers/dri2 \
src/mesa/drivers/dri
ifeq ($(strip $(MESA_BUILD_GALLIUM)),true)
SUBDIRS += src/gallium
endif
include $(call all-named-subdir-makefiles,$(SUBDIRS))
endif

View File

@@ -1,16 +0,0 @@
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/STATIC_LIBRARIES/libmesa_*_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/SHARED_LIBRARIES/i9*5_dri_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/SHARED_LIBRARIES/libglapi_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/obj/SHARED_LIBRARIES/libGLES_mesa_intermediates)
$(call add-clean-step, rm -rf $(OUT_DIR)/host/$(HOST_OS)-$(HOST_ARCH)/obj/EXECUTABLES/mesa_*_intermediates)
$(call add-clean-step, rm -rf $(OUT_DIR)/host/$(HOST_OS)-$(HOST_ARCH)/obj/EXECUTABLES/glsl_compiler_intermediates)
$(call add-clean-step, rm -rf $(OUT_DIR)/host/$(HOST_OS)-$(HOST_ARCH)/obj/STATIC_LIBRARIES/libmesa_glsl_utils_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/*/STATIC_LIBRARIES/libmesa_*_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/*/SHARED_LIBRARIES/i9?5_dri_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/*/SHARED_LIBRARIES/libglapi_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/*/SHARED_LIBRARIES/libGLES_mesa_intermediates)
$(call add-clean-step, rm -rf $(HOST_OUT_release)/*/EXECUTABLES/mesa_*_intermediates)
$(call add-clean-step, rm -rf $(HOST_OUT_release)/*/EXECUTABLES/glsl_compiler_intermediates)
$(call add-clean-step, rm -rf $(HOST_OUT_release)/*/STATIC_LIBRARIES/libmesa_*_intermediates)
$(call add-clean-step, rm -rf $(PRODUCT_OUT)/*/SHARED_LIBRARIES/*_dri_intermediates)

1636
Make-config Normal file

File diff suppressed because it is too large Load Diff

765
Makefile.X11 Normal file
View File

@@ -0,0 +1,765 @@
# $Id: Makefile.X11,v 1.69 2002/11/13 15:33:51 brianp Exp $
# Mesa 3-D graphics library
# Version: 5.0
#
# Copyright (C) 1999-2002 Brian Paul All Rights Reserved.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included
# in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
# Top-level makefile for Mesa
# To add a new configuration for your system add it to the list below
# then update the Make-config file.
SHELL = /bin/sh
default:
@echo "Type one of the following:"
@echo " make aix for IBM RS/6000 with AIX"
@echo " make aix-sl for IBM RS/6000, make shared libs"
@echo " make amiwin for Amiga with SAS/C and AmiWin"
@echo " make amix for Amiga 3000 UX SVR4 v2.1 systems"
@echo " make beos-r4 for BeOS R4"
@echo " make bsdos for BSD/OS from BSDI using GCC"
@echo " make bsdos4 for BSD/OS 4.x, dynamic libraries"
@echo " make cygnus for Win95/NT using Cygnus-Win32"
@echo " make cygnus-linux for Win95/NT using Cygnus-Win32 under Linux"
@echo " make darwin for Darwin - Mac OS X"
@echo " make dgux for Data General"
@echo " make freebsd for FreeBSD systems with GCC"
@echo " make freebsd-386 for FreeBSD systems with GCC, w/ Intel assembly"
@echo " make gcc for a generic system with GCC"
@echo " make hpux9 for HP systems with HPUX 9.x"
@echo " make hpux9-sl for HP systems with HPUX 9.x, make shared libs"
@echo " make hpux9-gcc for HP systems with HPUX 9.x using GCC"
@echo " make hpux9-gcc-sl for HP systems with HPUX 9.x, GCC, make shared libs"
@echo " make hpux10 for HP systems with HPUX 10.x and 11.x"
@echo " make hpux10-sl for HP systems with HPUX 10.x and 11.x, shared libs"
@echo " make hpux10-gcc for HP systems with HPUX 10.x w/ GCC"
@echo " make hpux10-gcc-sl for HP systems with HPUX 10.x w/ GCC, shared libs"
@echo " make irix4 for SGI systems with IRIX 4.x"
@echo " make irix5 for SGI systems with IRIX 5.x"
@echo " make irix5-gcc for SGI systems with IRIX 5.x using GCC"
@echo " make irix5-dso for SGI systems with IRIX 5.x, make DSOs"
@echo " make irix6-o32 for SGI systems with IRIX 6.x, make o32-bit libs"
@echo " make irix6-o32-dso for SGI systems with IRIX 6.x, make o32-bit DSOs"
@echo " make irix6-n32 for SGI systems with IRIX 6.x, make n32-bit libs"
@echo " make irix6-n32-dso for SGI systems with IRIX 6.x, make n32-bit DSOs"
@echo " make irix6-gcc-n32-sl for SGI systems with IRIX 6.x, GCC, make n32 DSOs"
@echo " make irix6-64 for SGI systems with IRIX 6.x, make 64-bit libs"
@echo " make irix6-64-dso for SGI systems with IRIX 6.x, make 64-bit DSOs"
@echo " make linux for Linux systems, make shared .so libs"
@echo " make linux-static for Linux systems, make static .a libs"
@echo " make linux-trace for Linux systems, with API trace extension"
@echo " make linux-x86 for Linux on Intel, make shared .so libs"
@echo " make linux-x86-static for Linux on Intel, make static .a libs"
@echo " make linux-ggi for Linux systems with libggi"
@echo " make linux-386-ggi for Linux systems with libggi w/ Intel assembly"
@echo " make linux-glide for Linux w/ 3Dfx Glide driver"
@echo " make linux-386-glide for Linux w/ 3Dfx Glide driver, Intel assembly"
@echo " make linux-386-opt-glide for Linux with 3Dfx Voodoo1 for GLQuake"
@echo " make linux-x86-glide for Linux w/ all x86 asm for Glide"
@echo " make linux-alpha for Linux on Alpha systems"
@echo " make linux-alpha-static for Linux on Alpha systems, static libs"
@echo " make linux-ppc for Linux on PowerPC systems"
@echo " make linux-ppc-static for Linux on PowerPC systems, static libs"
@echo " make linux-sparc for Linux on Sparc systems"
@echo " make linux-sparc5-elf for Sparc5 systems, make ELF shared libs"
@echo " make linux-sparc-ultra for UltraSparc systems, make ELF shared libs"
@echo " make linux-osmesa16 for 16-bit/channel OSMesa"
@echo " make linux-osmesa32 for 32-bit/channel OSMesa"
@echo " make linux-icc for Linux with the Intel C/C++ compiler"
@echo " make lynxos for LynxOS systems with GCC"
@echo " make macintosh for Macintosh"
@echo " make machten-2.2 for Macs w/ MachTen 2.2 (68k w/ FPU)"
@echo " make machten-4.0 for Macs w/ MachTen 4.0.1 or newer with GNU make"
@echo " make mklinux for Linux on Power Macintosh"
@echo " make netbsd for NetBSD 1.0 systems with GCC"
@echo " make next for NeXT systems with NEXTSTEP 3.3"
@echo " make openbsd for OpenBSD systems"
@echo " make openstep for OpenStep/MacOSX Server systems"
@echo " make os2-x11 for OS/2 with XFree86"
@echo " make osf1 for DEC Alpha systems with OSF/1"
@echo " make osf1-sl for DEC Alpha systems with OSF/1, make shared libs"
@echo " make pgi-cygnus for Cygnus with Portland Group, Inc. compiler"
@echo " make pgi-mingw32 for mingW32 with Portland Group, Inc. compiler"
@echo " make qnx for QNX V4 systems with Watcom compiler"
@echo " make sco for SCO Unix systems with ODT"
@echo " make sco5 for SCO 5.0.5 OpenServer Unix"
@echo " make solaris-x86 for PCs with Solaris"
@echo " make solaris-x86-gcc for PCs with Solaris using GCC"
@echo " make sunos4 for Suns with SunOS 4.x"
@echo " make sunos4-sl for Suns with SunOS 4.x, make shared libs"
@echo " make sunos4-gcc for Suns with SunOS 4.x and GCC"
@echo " make sunos4-gcc-sl for Suns with SunOS 4.x, GCC, make shared libs"
@echo " make sunos5 for Suns with SunOS 5.x"
@echo " make sunos5-sl for Suns with SunOS 5.x, make shared libs"
@echo " make sunos5-ultra for Sun UltraSPARCs with SunOS 5.x"
@echo " make sunos5-ultra-sl for Sun UltraSPARCs with SunOS 5.x, make shared libs"
@echo " make sunos5-thread for Suns with SunOS 5.x, using Solaris threads"
@echo " make sunos5-pthread for Suns with SunOS 5.[56] using POSIX threads"
@echo " make sunos5-gcc-thread for Suns with SunOS 5.x and GCC, using Solaris threads"
@echo " make sunos5-gcc-pthread for Suns with SunOS 5.[56] and GCC, using POSIX threads"
@echo " make sunos5-gcc for Suns with SunOS 5.x and GCC"
@echo " make sunos5-gcc-sl for Suns with SunOS 5.x, GCC, make shared libs"
@echo " make sunos5-x11r6-gcc-sl for Suns with X11R6, GCC, make shared libs"
@echo " make sunos5-gcc-thread for Suns with SunOS 5.x and GCC, using Solaris threads"
@echo " make sunos5-gcc-pthread for Suns with SunOS 5.[56] and GCC, using POSIX threads"
@echo " make sunSolaris-CC for Solaris using C++ compiler"
@echo " make ultrix-gcc for DEC systems with Ultrix and GCC"
@echo " make unicos for Cray C90 (and other?) systems"
@echo " make unixware for PCs running UnixWare"
@echo " make unixware-shared for PCs running UnixWare, shared libs"
@echo " make uwin for Windows NT with AT&T/Wipro UWIN"
@echo " make vistra for Stardent Vistra systems"
@echo " make clean remove .o files"
@echo " make realclean remove .o, library and executable files"
# XXX we may have to split up this group of targets into those that
# have a C++ compiler and those that don't for the SI-GLU library.
aix aix-sl amix bsdos bsdos4 darwin dgux freebsd freebsd-386 gcc \
hpux9 hpux9-sl hpux9-gcc hpux9-gcc-sl \
hpux10 hpux10-sl hpux10-gcc hpux10-gcc-sl \
irix4 irix5 irix5-gcc irix5-dso \
linux linux-static linux-debug linux-static-debug linux-prof \
linux-x86 linux-icc linux-x86-static linux-x86-debug \
linux-glide linux-386-glide linux-386-opt-glide \
linux-x86-glide linux-glide-debug linux-glide-prof \
linux-alpha-static linux-alpha \
linux-ppc-static linux-ppc \
linux-sparc \
linux-sparc5-elf \
linux-sparc-ultra \
lynxos machten-2.2 machten-4.0 \
mklinux netbsd osf1 osf1-sl openbsd qnx sco sco5 \
solaris-x86 solaris-x86-gcc sunSolaris-CC \
sunos4 sunos4-sl sunos4-gcc sunos4-gcc-sl sunos4-gcc-x11r6-sl \
sunos5 sunos5-sl sunos5-ultra sunos5-ultra-sl sunos5-gcc sunos5-gcc-sl \
sunos5-thread sunos5-pthread sunos5-gcc-thread sunos5-gcc-pthread \
sunos5-x11r6-gcc-sl ultrix-gcc unicos unixware uwin vistra:
-mkdir lib
if [ -d src ] ; then touch src/depend ; fi
if [ -d si-glu ] ; then touch si-glu/depend ; fi
if [ -d src-glut ] ; then touch src-glut/depend ; fi
if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d si-glu ] ; then cd si-glu ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d xdemos ] ; then cd xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d book ] ; then cd book ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
irix6-o32 irix6-o32-dso irix6-n32 irix6-n32-dso irix6-gcc-n32-sl irix-debug:
-mkdir lib32
if [ -d src ] ; then touch src/depend ; fi
if [ -d src-glu ] ; then touch src-glu/depend ; fi
if [ -d src-glut ] ; then touch src-glut/depend ; fi
if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glu ] ; then cd src-glu ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d xdemos ] ; then cd xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d book ] ; then cd book ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
irix6-64 irix6-64-dso:
-mkdir lib64
touch src/depend
touch src-glu/depend
if [ -d src-glut ] ; then touch src-glut/depend ; fi
if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glu ] ; then cd src-glu ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d xdemos ] ; then cd xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d book ] ; then cd book ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
amiwin:
bin/mklib.amiwin
beos-r4:
-mkdir lib
-rm src/depend
touch src/depend
-rm src-glu/depend
touch src-glu/depend
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
if [ -d src-glu ] ; then cd src-glu ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
if [ -d BeOS ] ; then cd BeOS ; $(MAKE) ; fi
if [ -d src-glut.beos ] ; then cd src-glut.beos ; $(MAKE) ; fi
if [ -d src-glut.beos ] ; then cp src-glut.beos/obj*/libglut.so lib ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
if [ -d book ] ; then cd book ; $(MAKE) -f Makefile.BeOS-R4 $@ ; fi
pgi-cygnus pgi-mingw32 \
cygnus cygnus-linux:
-mkdir lib
touch src/depend
touch src-glu/depend
if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glu ] ; then cd src-glu ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d xdemos ] ; then cd xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
macintosh:
@echo "See the README file for Macintosh intallation information"
next:
-mkdir lib
cd src ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
cd src-glu ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
openstep:
-mkdir lib
cd src ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
cd src-glu ; $(MAKE) -f Makefile.X11 "MYCC=${CC}" $@
os2-x11:
if not EXIST .\lib md lib
touch src/depend
touch src-glu/depend
if exist src-glut touch src-glut/depend
cd src & make -f Makefile.X11 $@
cd src-glu & make -f Makefile.X11 $@
if exist src-glut cd src-glut & make -f Makefile.X11 $@
if exist demos cd demos & make -f Makefile.X11 $@
if exist xdemos cd xdemos & make -f Makefile.X11 $@
if exist samples cd samples & make -f Makefile.X11 $@
if exist book cd book & make -f Makefile.X11 $@
linux-ggi linux-386-ggi:
-mkdir lib
touch src/depend
touch si-glu/depend
if [ -d src-glut ] ; then touch src-glut/depend ; fi
if [ -d widgets-sgi ] ; then touch widgets-sgi/depend ; fi
if [ -d ggi ] ; then touch ggi/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d src/GGI/default ] ; then cd src/GGI/default ; $(MAKE) ; fi
if [ -d src/GGI/display ] ; then cd src/GGI/display ; $(MAKE) ; fi
if [ -d si-glu ] ; then cd si-glu ; $(MAKE) -f Makefile.X11 $@ ; fi
# if [ -d src-glut ] ; then cd src-glut ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d ggi ] ; then cd ggi ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d ggi ] ; then cd ggi/demos; $(MAKE) ; fi
if [ -d demos ] ; then cd demos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d xdemos ] ; then cd xdemos ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d samples ] ; then cd samples ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d book ] ; then cd book ; $(MAKE) -f Makefile.X11 $@ ; fi
if [ -d widgets-sgi ] ; then cd widgets-sgi; $(MAKE) -f Makefile.X11 $@ ; fi
# if you change GGI_DEST please change it in ggimesa.conf, too.
DESTDIR=/usr/local
GGI_DEST=lib/ggi/mesa
linux-ggi-install linux-386-ggi-install:
install -d $(DESTDIR)/$(GGI_DEST)/default $(DESTDIR)/$(GGI_DEST)/display $(DESTDIR)/etc/ggi
install -m 0755 src/GGI/default/*.so $(DESTDIR)/$(GGI_DEST)/default
install -m 0755 src/GGI/display/*.so $(DESTDIR)/$(GGI_DEST)/display
install -m 0644 src/GGI/ggimesa.conf $(DESTDIR)/etc/ggi
# if [ -z "`grep ggimesa $(DESTDIR)/etc/ggi/libggi.conf`" ]; then \
# echo ".include $(DESTDIR)/etc/ggi/ggimesa.conf" >> $(DESTDIR)/etc/ggi/libggi.conf ; \
# fi
linux-osmesa16 linux-osmesa32:
-mkdir lib
if [ -d src ] ; then touch src/depend ; fi
if [ -d src ] ; then cd src ; $(MAKE) -f Makefile.OSMesa16 $@ ; fi
# Remove .o files, emacs backup files, etc.
clean:
-rm -f ggi/*~ *.o
-rm -f src/GGI/default/*~ *.so
-rm -f src/GGI/display/*~ *.so
-rm -f include/*~
-rm -f include/GL/*~
-rm -f src/*.o src/*~ src/*.a src/*/*.o src/*/*~
-rm -f src-glu/*.o src-glu/*~ src-glu/*.a
-rm -f si-glu/*/*.o si-glu/*/*/*.o
-rm -f src-glut/*.o
-rm -f demos/*.o
-rm -f book/*.o book/*~
-rm -f xdemos/*.o xdemos/*~
-rm -f samples/*.o samples/*~
-rm -f ggi/*.o ggi/demos/*.o ggi/*.a
-rm -f widgets-sgi/*.o
-rm -f widgets-mesa/*/*.o
# Remove everything that can be remade
realclean: clean
-rm -fr lib lib32 lib64
cd demos && $(MAKE) -f Makefile.X11 realclean || true
cd xdemos && $(MAKE) -f Makefile.X11 realclean || true
cd book && $(MAKE) -f Makefile.X11 realclean || true
cd samples && $(MAKE) -f Makefile.X11 realclean || true
DIRECTORY = Mesa-5.0
LIB_NAME = MesaLib-5.0
DEMO_NAME = MesaDemos-5.0
GLU_NAME = MesaGLU-5.0
GLUT_NAME = GLUT-3.7
LIB_FILES = \
$(DIRECTORY)/Makefile* \
$(DIRECTORY)/Make-config \
$(DIRECTORY)/acconfig.h \
$(DIRECTORY)/acinclude.m4 \
$(DIRECTORY)/aclocal.m4 \
$(DIRECTORY)/common_rules.make \
$(DIRECTORY)/conf.h.in \
$(DIRECTORY)/config.guess \
$(DIRECTORY)/config.sub \
$(DIRECTORY)/configure \
$(DIRECTORY)/configure.in \
$(DIRECTORY)/install-sh \
$(DIRECTORY)/ltmain.sh \
$(DIRECTORY)/missing \
$(DIRECTORY)/mkinstalldirs \
$(DIRECTORY)/stamp-h.in \
$(DIRECTORY)/docs/CONFORM \
$(DIRECTORY)/docs/COPYING \
$(DIRECTORY)/docs/COPYRIGHT \
$(DIRECTORY)/docs/DEVINFO \
$(DIRECTORY)/docs/INSTALL \
$(DIRECTORY)/docs/INSTALL.GNU \
$(DIRECTORY)/docs/README \
$(DIRECTORY)/docs/README.* \
$(DIRECTORY)/docs/RELNOTES* \
$(DIRECTORY)/docs/VERSIONS \
$(DIRECTORY)/docs/*.spec \
$(DIRECTORY)/bin/README \
$(DIRECTORY)/bin/mklib* \
$(DIRECTORY)/descrip.mms \
$(DIRECTORY)/mms-config \
$(DIRECTORY)/m4/*.m4 \
$(DIRECTORY)/xlib.opt \
$(DIRECTORY)/mesawin32.mak \
$(DIRECTORY)/include/GL/internal/glcore.h \
$(DIRECTORY)/include/GL/Makefile.in \
$(DIRECTORY)/include/GL/Makefile.am \
$(DIRECTORY)/include/GL/dmesa.h \
$(DIRECTORY)/include/GL/amesa.h \
$(DIRECTORY)/include/GL/fxmesa.h \
$(DIRECTORY)/include/GL/ggimesa.h \
$(DIRECTORY)/include/GL/gl.h \
$(DIRECTORY)/include/GL/glext.h \
$(DIRECTORY)/include/GL/gl_mangle.h \
$(DIRECTORY)/include/GL/glu.h \
$(DIRECTORY)/include/GL/glu_mangle.h \
$(DIRECTORY)/include/GL/glx.h \
$(DIRECTORY)/include/GL/glxext.h \
$(DIRECTORY)/include/GL/glx_mangle.h \
$(DIRECTORY)/include/GL/mesa_wgl.h \
$(DIRECTORY)/include/GL/mglmesa.h \
$(DIRECTORY)/include/GL/osmesa.h \
$(DIRECTORY)/include/GL/svgamesa.h \
$(DIRECTORY)/include/GL/ugl*.h \
$(DIRECTORY)/include/GL/vms_x_fix.h \
$(DIRECTORY)/include/GL/wmesa.h \
$(DIRECTORY)/include/GL/xmesa.h \
$(DIRECTORY)/include/GL/xmesa_x.h \
$(DIRECTORY)/include/GL/xmesa_xf86.h \
$(DIRECTORY)/include/GLView.h \
$(DIRECTORY)/include/Makefile.in \
$(DIRECTORY)/include/Makefile.am \
$(DIRECTORY)/src/Makefile* \
$(DIRECTORY)/src/libGL_la_SOURCES \
$(DIRECTORY)/src/descrip.mms \
$(DIRECTORY)/src/mesa.conf \
$(DIRECTORY)/src/*.def \
$(DIRECTORY)/src/depend \
$(DIRECTORY)/src/*.[chS] \
$(DIRECTORY)/src/array_cache/*.[ch] \
$(DIRECTORY)/src/array_cache/Makefile* \
$(DIRECTORY)/src/array_cache/libMesaAC_la_SOURCES \
$(DIRECTORY)/src/math/*.[ch] \
$(DIRECTORY)/src/math/Makefile* \
$(DIRECTORY)/src/swrast/*.[ch] \
$(DIRECTORY)/src/swrast/Makefile* \
$(DIRECTORY)/src/swrast/libMesaSwrast_la_SOURCES \
$(DIRECTORY)/src/swrast_setup/*.[ch] \
$(DIRECTORY)/src/swrast_setup/Makefile* \
$(DIRECTORY)/src/tnl/*.[ch] \
$(DIRECTORY)/src/tnl/Makefile* \
$(DIRECTORY)/src/tnl/libMesaTnl_la_SOURCES \
$(DIRECTORY)/src/tnl_dd/*.[ch] \
$(DIRECTORY)/src/tnl_dd/imm/*.[ch] \
$(DIRECTORY)/src/tnl_dd/imm/NOTES.imm \
$(DIRECTORY)/src/windml/*.[ch] \
$(DIRECTORY)/src/windml/tornado/*.c \
$(DIRECTORY)/src/windml/tornado/*.cdf \
$(DIRECTORY)/src/windml/man3/*.3 \
$(DIRECTORY)/src/windml/man3/*.html \
$(DIRECTORY)/src/DOS/*.[chS] \
$(DIRECTORY)/src/DOS/vesa/*.[ch] \
$(DIRECTORY)/src/BeOS/*.cpp \
$(DIRECTORY)/src/FX/Makefile.am \
$(DIRECTORY)/src/FX/Makefile.in \
$(DIRECTORY)/src/FX/libMesaFX_la_SOURCES \
$(DIRECTORY)/src/FX/*.[ch] \
$(DIRECTORY)/src/FX/*.def \
$(DIRECTORY)/src/FX/X86/Makefile.am \
$(DIRECTORY)/src/FX/X86/Makefile.in \
$(DIRECTORY)/src/FX/X86/*.[Shc] \
$(DIRECTORY)/src/GGI/Makefile.am \
$(DIRECTORY)/src/GGI/Makefile.in \
$(DIRECTORY)/src/GGI/*.[ch] \
$(DIRECTORY)/src/GGI/ggimesa.conf.in \
$(DIRECTORY)/src/GGI/default/*.c \
$(DIRECTORY)/src/GGI/default/Makefile.am \
$(DIRECTORY)/src/GGI/default/Makefile.in \
$(DIRECTORY)/src/GGI/default/genkgi.conf.in \
$(DIRECTORY)/src/GGI/display/*.c \
$(DIRECTORY)/src/GGI/display/Makefile.am \
$(DIRECTORY)/src/GGI/display/Makefile.in \
$(DIRECTORY)/src/GGI/display/fbdev.conf.in \
$(DIRECTORY)/src/GGI/include/Makefile.am \
$(DIRECTORY)/src/GGI/include/Makefile.in \
$(DIRECTORY)/src/GGI/include/ggi/Makefile.am \
$(DIRECTORY)/src/GGI/include/ggi/Makefile.in \
$(DIRECTORY)/src/GGI/include/ggi/mesa/Makefile.am \
$(DIRECTORY)/src/GGI/include/ggi/mesa/Makefile.in \
$(DIRECTORY)/src/GGI/include/ggi/mesa/*.h \
$(DIRECTORY)/src/KNOWN_BUGS \
$(DIRECTORY)/src/OSmesa/Makefile.am \
$(DIRECTORY)/src/OSmesa/Makefile.in \
$(DIRECTORY)/src/OSmesa/Makefile.win \
$(DIRECTORY)/src/OSmesa/osmesa.def \
$(DIRECTORY)/src/OSmesa/*.[ch] \
$(DIRECTORY)/src/SPARC/*.[chS] \
$(DIRECTORY)/src/SPARC/Makefile.am \
$(DIRECTORY)/src/SPARC/Makefile.in \
$(DIRECTORY)/src/SVGA/Makefile.am \
$(DIRECTORY)/src/SVGA/Makefile.in \
$(DIRECTORY)/src/SVGA/*.[ch] \
$(DIRECTORY)/src/Trace/*.[ch] \
$(DIRECTORY)/src/Trace/Makefile.am \
$(DIRECTORY)/src/Trace/Makefile.in \
$(DIRECTORY)/src/Windows/*.[ch] \
$(DIRECTORY)/src/Windows/*.def \
$(DIRECTORY)/src/X/Makefile.am \
$(DIRECTORY)/src/X/Makefile.in \
$(DIRECTORY)/src/X/*.[ch] \
$(DIRECTORY)/src/X86/*.[ch] \
$(DIRECTORY)/src/X86/Makefile.am \
$(DIRECTORY)/src/X86/Makefile.in \
$(DIRECTORY)/src/X86/*.S \
$(DIRECTORY)/si-glu/Makefile.am \
$(DIRECTORY)/si-glu/Makefile.in \
$(DIRECTORY)/si-glu/Makefile.X11 \
$(DIRECTORY)/si-glu/Makefile.win \
$(DIRECTORY)/si-glu/glu.def \
$(DIRECTORY)/si-glu/dummy.cc \
$(DIRECTORY)/si-glu/descrip.mms \
$(DIRECTORY)/si-glu/mesaglu.opt \
$(DIRECTORY)/si-glu/include/gluos.h \
$(DIRECTORY)/si-glu/include/Makefile.am \
$(DIRECTORY)/si-glu/include/Makefile.in \
$(DIRECTORY)/si-glu/libnurbs/Makefile.am \
$(DIRECTORY)/si-glu/libnurbs/Makefile.in \
$(DIRECTORY)/si-glu/libnurbs/interface/*.h \
$(DIRECTORY)/si-glu/libnurbs/interface/*.cc \
$(DIRECTORY)/si-glu/libnurbs/interface/libNIFac_la_SOURCES \
$(DIRECTORY)/si-glu/libnurbs/interface/Makefile.am \
$(DIRECTORY)/si-glu/libnurbs/interface/Makefile.in \
$(DIRECTORY)/si-glu/libnurbs/internals/*.h \
$(DIRECTORY)/si-glu/libnurbs/internals/*.cc \
$(DIRECTORY)/si-glu/libnurbs/internals/libNInt_la_SOURCES \
$(DIRECTORY)/si-glu/libnurbs/internals/Makefile.am \
$(DIRECTORY)/si-glu/libnurbs/internals/Makefile.in \
$(DIRECTORY)/si-glu/libnurbs/nurbtess/*.h \
$(DIRECTORY)/si-glu/libnurbs/nurbtess/*.cc \
$(DIRECTORY)/si-glu/libnurbs/nurbtess/libNTess_la_SOURCES \
$(DIRECTORY)/si-glu/libnurbs/nurbtess/Makefile.am \
$(DIRECTORY)/si-glu/libnurbs/nurbtess/Makefile.in \
$(DIRECTORY)/si-glu/libtess/README \
$(DIRECTORY)/si-glu/libtess/alg-outline \
$(DIRECTORY)/si-glu/libtess/*.[ch] \
$(DIRECTORY)/si-glu/libtess/libtess_la_SOURCES \
$(DIRECTORY)/si-glu/libtess/Makefile.am \
$(DIRECTORY)/si-glu/libtess/Makefile.in \
$(DIRECTORY)/si-glu/libutil/*.[ch] \
$(DIRECTORY)/si-glu/libutil/libutil_la_SOURCES \
$(DIRECTORY)/si-glu/libutil/Makefile.am \
$(DIRECTORY)/si-glu/libutil/Makefile.in \
$(DIRECTORY)/src-glu/README[12] \
$(DIRECTORY)/src-glu/Makefile* \
$(DIRECTORY)/src-glu/descrip.mms \
$(DIRECTORY)/src-glu/mms_depend \
$(DIRECTORY)/src-glu/*.def \
$(DIRECTORY)/src-glu/depend \
$(DIRECTORY)/src-glu/*.[ch] \
$(DIRECTORY)/widgets-mesa/ChangeLog \
$(DIRECTORY)/widgets-mesa/INSTALL \
$(DIRECTORY)/widgets-mesa/Makefile.in \
$(DIRECTORY)/widgets-mesa/README \
$(DIRECTORY)/widgets-mesa/TODO \
$(DIRECTORY)/widgets-mesa/configure \
$(DIRECTORY)/widgets-mesa/configure.in \
$(DIRECTORY)/widgets-mesa/demos/ChangeLog \
$(DIRECTORY)/widgets-mesa/demos/Cube \
$(DIRECTORY)/widgets-mesa/demos/Ed \
$(DIRECTORY)/widgets-mesa/demos/Makefile.in \
$(DIRECTORY)/widgets-mesa/demos/Mcube \
$(DIRECTORY)/widgets-mesa/demos/Tea \
$(DIRECTORY)/widgets-mesa/demos/*.[ch] \
$(DIRECTORY)/widgets-mesa/demos/events \
$(DIRECTORY)/widgets-mesa/include/GL/ChangeLog \
$(DIRECTORY)/widgets-mesa/include/GL/*.h \
$(DIRECTORY)/widgets-mesa/include/GL/Makefile.in \
$(DIRECTORY)/widgets-mesa/man/ChangeLog \
$(DIRECTORY)/widgets-mesa/man/GL* \
$(DIRECTORY)/widgets-mesa/man/Makefile.in \
$(DIRECTORY)/widgets-mesa/man/Mesa* \
$(DIRECTORY)/widgets-mesa/src/ChangeLog \
$(DIRECTORY)/widgets-mesa/src/*.c \
$(DIRECTORY)/widgets-mesa/src/Makefile.in \
$(DIRECTORY)/widgets-sgi/*.[ch] \
$(DIRECTORY)/widgets-sgi/Makefile* \
$(DIRECTORY)/widgets-sgi/README \
$(DIRECTORY)/util/README \
$(DIRECTORY)/util/Makefile.am \
$(DIRECTORY)/util/Makefile.in \
$(DIRECTORY)/util/*.[ch] \
$(DIRECTORY)/util/sampleMakefile \
$(DIRECTORY)/vms/analyze_map.com \
$(DIRECTORY)/vms/xlib.opt \
$(DIRECTORY)/vms/xlib_share.opt \
$(DIRECTORY)/BeOS/Makefile \
$(DIRECTORY)/BeOS/*.cpp
OBSOLETE_LIB_FILES = \
$(DIRECTORY)/src/Allegro/*.[ch] \
$(DIRECTORY)/src/D3D/*.cpp \
$(DIRECTORY)/src/D3D/*.CPP \
$(DIRECTORY)/src/D3D/*.h \
$(DIRECTORY)/src/D3D/*.H \
$(DIRECTORY)/src/D3D/*.c \
$(DIRECTORY)/src/D3D/*.C \
$(DIRECTORY)/src/D3D/MAKEFILE \
$(DIRECTORY)/src/D3D/*bat \
$(DIRECTORY)/src/D3D/*DEF \
$(DIRECTORY)/src/DOS/DEPEND.DOS \
$(DIRECTORY)/src/S3/*.[ch] \
$(DIRECTORY)/src/S3/*.def \
$(DIRECTORY)/src/S3/*.mak \
$(DIRECTORY)/src/S3/*.rc \
$(DIRECTORY)/macos/README \
$(DIRECTORY)/macos/gli_api/*.h \
$(DIRECTORY)/macos/cglpane/CGLPane.* \
$(DIRECTORY)/macos/include-mac/*.h \
$(DIRECTORY)/macos/libraries/*.stub \
$(DIRECTORY)/macos/libraries/*Stub \
$(DIRECTORY)/macos/projects/*.mcp \
$(DIRECTORY)/macos/projects/*.exp \
$(DIRECTORY)/macos/projects/*.h \
$(DIRECTORY)/macos/resources/*.c \
$(DIRECTORY)/macos/resources/*.r \
$(DIRECTORY)/macos/resources/*.rsrc \
$(DIRECTORY)/macos/src-agl/*.exp \
$(DIRECTORY)/macos/src-agl/*.[ch] \
$(DIRECTORY)/macos/src-gli/*.[ch] \
$(DIRECTORY)/OpenStep
DEMO_FILES = \
$(DIRECTORY)/include/GL/glut.h \
$(DIRECTORY)/include/GL/glutf90.h \
$(DIRECTORY)/src-glut/Makefile* \
$(DIRECTORY)/src-glut/depend \
$(DIRECTORY)/src-glut/*def \
$(DIRECTORY)/src-glut/descrip.mms \
$(DIRECTORY)/src-glut/mms_depend \
$(DIRECTORY)/src-glut/*.[ch] \
$(DIRECTORY)/src-glut.dos/*.[ch] \
$(DIRECTORY)/src-glut.dos/Makefile.DJ \
$(DIRECTORY)/src-glut.dos/PC_HW/*.[chS] \
$(DIRECTORY)/images/* \
$(DIRECTORY)/demos/Makefile* \
$(DIRECTORY)/demos/descrip.mms \
$(DIRECTORY)/demos/*.[ch] \
$(DIRECTORY)/demos/*.cxx \
$(DIRECTORY)/demos/*.dat \
$(DIRECTORY)/demos/README \
$(DIRECTORY)/xdemos/Makefile* \
$(DIRECTORY)/xdemos/descrip.mms \
$(DIRECTORY)/xdemos/*.[chf] \
$(DIRECTORY)/book/Makefile* \
$(DIRECTORY)/book/README \
$(DIRECTORY)/book/*.[ch] \
$(DIRECTORY)/samples/Makefile* \
$(DIRECTORY)/samples/README \
$(DIRECTORY)/samples/*.c \
$(DIRECTORY)/mtdemos \
$(DIRECTORY)/windmldemos/Makefile.ugl \
$(DIRECTORY)/windmldemos/*.c \
$(DIRECTORY)/windmldemos/*.bmp \
$(DIRECTORY)/ggi
OBSOLETE_DEMO_FILES = \
$(DIRECTORY)/include/GL/glut_h.dja \
$(DIRECTORY)/src-glut.dja/* \
$(DIRECTORY)/src-glut.beos/Makefile \
$(DIRECTORY)/src-glut.beos/*.cpp \
$(DIRECTORY)/src-glut.beos/*.h \
SI_GLU_FILES = \
$(DIRECTORY)/Makefile* \
$(DIRECTORY)/Make-config \
$(DIRECTORY)/bin/mklib* \
$(DIRECTORY)/include/GL/glu.h \
$(DIRECTORY)/si-glu/Makefile.X11 \
$(DIRECTORY)/si-glu/include/gluos.h \
$(DIRECTORY)/si-glu/libnurbs/interface/*.h \
$(DIRECTORY)/si-glu/libnurbs/interface/*.cc \
$(DIRECTORY)/si-glu/libnurbs/internals/*.h \
$(DIRECTORY)/si-glu/libnurbs/internals/*.cc \
$(DIRECTORY)/si-glu/libnurbs/nurbstess/*.h \
$(DIRECTORY)/si-glu/libnurbs/nurbstess/*.cc \
$(DIRECTORY)/si-glu/libtess/README \
$(DIRECTORY)/si-glu/libtess/alg-outline \
$(DIRECTORY)/si-glu/libtess/*.[ch] \
$(DIRECTORY)/si-glu/libutil/*.[ch]
GLU_FILES = \
$(DIRECTORY)/Makefile* \
$(DIRECTORY)/Make-config \
$(DIRECTORY)/bin/mklib* \
$(DIRECTORY)/include/GL/gl.h \
$(DIRECTORY)/include/GL/gl_mangle.h \
$(DIRECTORY)/include/GL/glext.h \
$(DIRECTORY)/include/GL/glu.h \
$(DIRECTORY)/include/GL/glu_mangle.h \
$(DIRECTORY)/src-glu/README[12] \
$(DIRECTORY)/src-glu/Makefile* \
$(DIRECTORY)/src-glu/descrip.mms \
$(DIRECTORY)/src-glu/mms_depend \
$(DIRECTORY)/src-glu/*.def \
$(DIRECTORY)/src-glu/depend \
$(DIRECTORY)/src-glu/*.[ch]
GLUT_FILES = \
$(DIRECTORY)/Makefile* \
$(DIRECTORY)/Make-config \
$(DIRECTORY)/bin/mklib* \
$(DIRECTORY)/include/GL/gl.h \
$(DIRECTORY)/include/GL/gl_mangle.h \
$(DIRECTORY)/include/GL/glext.h \
$(DIRECTORY)/include/GL/glu.h \
$(DIRECTORY)/include/GL/glu_mangle.h \
$(DIRECTORY)/include/GL/glut.h \
$(DIRECTORY)/include/GL/glutf90.h \
$(DIRECTORY)/src-glut/Makefile* \
$(DIRECTORY)/src-glut/depend \
$(DIRECTORY)/src-glut/*def \
$(DIRECTORY)/src-glut/descrip.mms \
$(DIRECTORY)/src-glut/mms_depend \
$(DIRECTORY)/src-glut/*.[ch]
OBSOLETE_GLUT_FILES = \
$(DIRECTORY)/include/GL/glut_h.dja \
$(DIRECTORY)/src-glut.dja/* \
$(DIRECTORY)/src-glut.beos/Makefile \
$(DIRECTORY)/src-glut.beos/*.cpp \
$(DIRECTORY)/src-glut.beos/*.h
lib_tar:
cp Makefile.X11 Makefile ; \
cd .. ; \
tar -cvf $(LIB_NAME).tar $(LIB_FILES) ; \
gzip $(LIB_NAME).tar ; \
mv $(LIB_NAME).tar.gz $(DIRECTORY)
demo_tar:
cd .. ; \
tar -cvf $(DEMO_NAME).tar $(DEMO_FILES) ; \
gzip $(DEMO_NAME).tar ; \
mv $(DEMO_NAME).tar.gz $(DIRECTORY)
glu_tar:
cp Makefile.X11 Makefile ; \
cd .. ; \
tar -cvf $(GLU_NAME).tar $(GLU_FILES) ; \
gzip $(GLU_NAME).tar ; \
mv $(GLU_NAME).tar.gz $(DIRECTORY)
glut_tar:
cp Makefile.X11 Makefile ; \
cd .. ; \
tar -cvf $(GLUT_NAME).tar $(GLUT_FILES) ; \
gzip $(GLUT_NAME).tar ; \
mv $(GLUT_NAME).tar.gz $(DIRECTORY)
lib_zip:
-rm $(LIB_NAME).zip ; \
cp Makefile.X11 Makefile ; \
cd .. ; \
zip -r $(LIB_NAME).zip $(LIB_FILES) ; \
mv $(LIB_NAME).zip $(DIRECTORY)
demo_zip:
-rm $(DEMO_NAME).zip ; \
cd .. ; \
zip -r $(DEMO_NAME).zip $(DEMO_FILES) ; \
mv $(DEMO_NAME).zip $(DIRECTORY)
SRC_FILES = \
RELNOTES \
src/Makefile* \
src/depend \
src/*.[chS] \
src/*/*.[ch] \
include/GL/*.h
srctar:
tar -cvf src.tar $(SRC_FILES) ; \
gzip src.tar
srctar.zip:
-rm src.zip
zip -r src.zip $(SRC_FILES) ; \

View File

@@ -1,61 +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
AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-dri3 \
--enable-gallium-tests \
--enable-gbm \
--enable-gles1 \
--enable-gles2 \
--enable-glx-tls \
--enable-va \
--enable-vdpau \
--enable-xa \
--enable-xvmc \
--with-egl-platforms=x11,wayland,drm
ACLOCAL_AMFLAGS = -I m4
EXTRA_DIST = \
autogen.sh \
common.py \
docs \
doxygen \
scons \
SConstruct
noinst_HEADERS = \
include/c99_alloca.h \
include/c99_compat.h \
include/c99_math.h \
include/c99 \
include/c11 \
include/D3D9 \
include/HaikuGL \
include/no_extern_c.h \
include/pci_ids
# We list some directories in EXTRA_DIST, but don't actually want to include
# the .gitignore files in the tarball.
dist-hook:
find $(distdir) -name .gitignore -exec $(RM) {} +

View File

@@ -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)

View File

@@ -1 +0,0 @@
10.7.0-devel

View File

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

9
bin/.gitignore vendored
View File

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

View File

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

View File

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

153
bin/mklib.aix Executable file
View File

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

38
bin/mklib.ar-ruv Executable file
View File

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

52
bin/mklib.solaris Normal file
View File

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

View File

@@ -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:

View File

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

113
common.py
View File

@@ -1,113 +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')

File diff suppressed because it is too large Load Diff

View File

@@ -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)

View File

@@ -1,241 +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, GLSL 1.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe
glBindFragDataLocation, glGetFragDataLocation DONE
Conditional rendering (GL_NV_conditional_render) DONE ()
Map buffer subranges (GL_ARB_map_buffer_range) DONE ()
Clamping controls (GL_ARB_color_buffer_float) DONE ()
Float textures, renderbuffers (GL_ARB_texture_float) DONE ()
GL_EXT_packed_float DONE ()
GL_EXT_texture_shared_exponent DONE ()
Float depth buffers (GL_ARB_depth_buffer_float) DONE ()
Framebuffer objects (GL_ARB_framebuffer_object) DONE ()
GL_ARB_half_float_pixel DONE (all drivers)
GL_ARB_half_float_vertex DONE ()
GL_EXT_texture_integer DONE ()
GL_EXT_texture_array DONE ()
Per-buffer blend and masks (GL_EXT_draw_buffers2) DONE ()
GL_EXT_texture_compression_rgtc DONE ()
GL_ARB_texture_rg DONE ()
Transform feedback (GL_EXT_transform_feedback) DONE ()
Vertex array objects (GL_ARB_vertex_array_object) DONE ()
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 (llvmpipe (*), softpipe (*))
(*) llvmpipe and softpipe have fake Multisample anti-aliasing support
GL 3.1, GLSL 1.40 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe
Forward compatible context support/deprecations DONE ()
Instanced drawing (GL_ARB_draw_instanced) DONE ()
Buffer copying (GL_ARB_copy_buffer) DONE ()
Primitive restart (GL_NV_primitive_restart) DONE ()
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 ()
Uniform buffer objs (GL_ARB_uniform_buffer_object) DONE ()
Signed normalized textures (GL_EXT_texture_snorm) DONE ()
GL 3.2, GLSL 1.50 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe
Core/compatibility profiles DONE
Geometry shaders DONE ()
BGRA vertex order (GL_ARB_vertex_array_bgra) DONE ()
Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE ()
Frag shader coord (GL_ARB_fragment_coord_conventions) DONE ()
Provoking vertex (GL_ARB_provoking_vertex) DONE ()
Seamless cubemaps (GL_ARB_seamless_cube_map) DONE ()
Multisample textures (GL_ARB_texture_multisample) DONE ()
Frag depth clamp (GL_ARB_depth_clamp) DONE ()
Fence objects (GL_ARB_sync) DONE ()
GLX_ARB_create_context_profile DONE
GL 3.3, GLSL 3.30 --- all DONE: i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe
GL_ARB_blend_func_extended DONE ()
GL_ARB_explicit_attrib_location DONE (all drivers that support GLSL)
GL_ARB_occlusion_query2 DONE ()
GL_ARB_sampler_objects DONE (all drivers)
GL_ARB_shader_bit_encoding DONE ()
GL_ARB_texture_rgb10_a2ui DONE ()
GL_ARB_texture_swizzle DONE ()
GL_ARB_timer_query DONE ()
GL_ARB_instanced_arrays DONE ()
GL_ARB_vertex_type_2_10_10_10_rev DONE ()
GL 4.0, GLSL 4.00:
GL_ARB_draw_buffers_blend DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_draw_indirect DONE (i965, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_gpu_shader5 DONE (i965, nvc0)
- 'precise' qualifier DONE
- Dynamically uniform sampler array indices DONE (r600, softpipe)
- Dynamically uniform UBO array indices DONE (r600)
- Implicit signed -> unsigned conversions DONE
- Fused multiply-add DONE ()
- Packing/bitfield/conversion functions DONE (r600, radeonsi, softpipe)
- Enhanced textureGather DONE (r600, radeonsi, softpipe)
- Geometry shader instancing DONE (r600, llvmpipe, softpipe)
- Geometry shader multiple streams DONE ()
- Enhanced per-sample shading DONE (r600, radeonsi)
- Interpolation functions DONE (r600)
- New overload resolution rules DONE
GL_ARB_gpu_shader_fp64 DONE (nvc0, softpipe)
GL_ARB_sample_shading DONE (i965, nv50, nvc0, r600, radeonsi)
GL_ARB_shader_subroutine started (Dave)
GL_ARB_tessellation_shader started (Chris, Ilia)
GL_ARB_texture_buffer_object_rgb32 DONE (i965, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_cube_map_array DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_gather DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_query_lod DONE (i965, nv50, nvc0, r600, radeonsi)
GL_ARB_transform_feedback2 DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_transform_feedback3 DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL 4.1, GLSL 4.10:
GL_ARB_ES2_compatibility DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_get_program_binary DONE (0 binary formats)
GL_ARB_separate_shader_objects DONE (all drivers)
GL_ARB_shader_precision started (Micah)
GL_ARB_vertex_attrib_64bit DONE (nvc0, softpipe)
GL_ARB_viewport_array DONE (i965, nv50, nvc0, r600, llvmpipe)
GL 4.2, GLSL 4.20:
GL_ARB_texture_compression_bptc DONE (i965, nvc0, r600, radeonsi)
GL_ARB_compressed_texture_pixel_storage DONE (all drivers)
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, llvmpipe, softpipe)
GL_ARB_base_instance DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
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_shading_language_packing DONE (all drivers)
GL_ARB_internalformat_query DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_map_buffer_alignment DONE (all drivers)
GL 4.3, GLSL 4.30:
GL_ARB_arrays_of_arrays started (Timothy)
GL_ARB_ES3_compatibility DONE (all drivers that support GLSL 3.30)
GL_ARB_clear_buffer_object DONE (all drivers)
GL_ARB_compute_shader in progress (jljusten)
GL_ARB_copy_image DONE (i965) (gallium - in progress, VMware)
GL_KHR_debug DONE (all drivers)
GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL)
GL_ARB_fragment_layer_viewport DONE (nv50, nvc0, r600, llvmpipe)
GL_ARB_framebuffer_no_attachments DONE (i965)
GL_ARB_internalformat_query2 not started
GL_ARB_invalidate_subdata DONE (all drivers)
GL_ARB_multi_draw_indirect DONE (i965, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_program_interface_query DONE (all drivers)
GL_ARB_robust_buffer_access_behavior not started
GL_ARB_shader_image_size in progress (Martin Peres)
GL_ARB_shader_storage_buffer_object in progress (Iago Toral, Samuel Iglesias)
GL_ARB_stencil_texturing DONE (i965/gen8+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_buffer_range DONE (nv50, nvc0, i965, r600, radeonsi, llvmpipe)
GL_ARB_texture_query_levels DONE (all drivers that support GLSL 1.30)
GL_ARB_texture_storage_multisample DONE (all drivers that support GL_ARB_texture_multisample)
GL_ARB_texture_view DONE (i965, nv50, nvc0, llvmpipe, softpipe)
GL_ARB_vertex_attrib_binding DONE (all drivers)
GL 4.4, GLSL 4.40:
GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers)
GL_ARB_buffer_storage DONE (i965, nv50, nvc0, r600, radeonsi)
GL_ARB_clear_texture DONE (i965) (gallium - in progress, VMware)
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, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_stencil8 DONE (nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL 4.5, GLSL 4.50:
GL_ARB_ES3_1_compatibility not started
GL_ARB_clip_control DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_conditional_render_inverted DONE (i965, nv50, nvc0, llvmpipe, softpipe)
GL_ARB_cull_distance in progress (Tobias)
GL_ARB_derivative_control DONE (i965, nv50, nvc0, r600)
GL_ARB_direct_state_access DONE (all drivers)
- Transform Feedback object DONE
- Buffer object DONE
- Framebuffer object DONE
- Renderbuffer object DONE
- Texture object DONE
- Vertex array object DONE
- Sampler object DONE
- Program Pipeline object DONE
- Query object DONE (will require changes when GL_ARB_query_buffer_object lands)
GL_ARB_get_texture_sub_image started (Brian Paul)
GL_ARB_shader_texture_image_samples not started
GL_ARB_texture_barrier DONE (nv50, nvc0, r600, radeonsi)
GL_KHR_context_flush_control DONE (all - but needs GLX/EXT extension to be useful)
GL_KHR_robust_buffer_access_behavior not started
GL_KHR_robustness 90% done (the ARB variant)
GL_EXT_shader_integer_mix DONE (all drivers that support GLSL)
These are the extensions cherry-picked to make GLES 3.1
GLES3.1, GLSL ES 3.1
GL_ARB_arrays_of_arrays started (Timothy)
GL_ARB_compute_shader in progress (jljusten)
GL_ARB_draw_indirect DONE (i965, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL)
GL_ARB_framebuffer_no_attachments DONE (i965)
GL_ARB_program_interface_query DONE (all drivers)
GL_ARB_shader_atomic_counters DONE (i965)
GL_ARB_shader_image_load_store in progress (curro)
GL_ARB_shader_image_size in progress (Martin Peres)
GL_ARB_shader_storage_buffer_object in progress (Iago Toral, Samuel Iglesias)
GL_ARB_shading_language_packing DONE (all drivers)
GL_ARB_separate_shader_objects DONE (all drivers)
GL_ARB_stencil_texturing DONE (i965/gen8+, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
Multisample textures (GL_ARB_texture_multisample) DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe)
GL_ARB_texture_storage_multisample DONE (all drivers that support GL_ARB_texture_multisample)
GL_ARB_vertex_attrib_binding DONE (all drivers)
GS5 Enhanced textureGather DONE (i965, nvc0, r600, radeonsi)
GS5 Packing/bitfield/conversion functions DONE (i965, nvc0, r600, radeonsi)
GL_EXT_shader_integer_mix DONE (all drivers that support GLSL)
Additional functions not covered above:
glMemoryBarrierByRegion
glGetTexLevelParameter[fi]v - needs updates to restrict to GLES enums
glGetBooleani_v - needs updates to restrict to GLES enums
More info about these features and the work involved can be found at
http://dri.freedesktop.org/wiki/MissingFunctionality

182
docs/INSTALL.GNU Normal file
View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@@ -8,7 +8,7 @@ Name Strings
Contact
Brian Paul (brian.paul 'at' tungstengraphics.com)
Brian Paul (brian 'at' mesa3d.org)
Status
@@ -31,12 +31,12 @@ Overview
Mesa's implementation of GLX is entirely implemented on the client side.
Therefore, Mesa cannot immediately detect when an X window or pixmap is
destroyed in order to free any ancillary data associated with the window
destroyed in order to free any ancilliary data associated with the window
or pixmap.
The glxMesaReleaseBuffers() function can be used to explicitly indicate
when the back color buffer, depth buffer, stencil buffer, and/or accumu-
lation buffer associated with a drawable can be freed.
when the back color buffer, depth buffer, stencil buffer, and/or accum-
ulation buffer associated with a drawable can be freed.
IP Status
@@ -60,7 +60,7 @@ Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d );
causes all software ancillary buffers (back buffer, depth, stencil,
causes all software ancilliary buffers (back buffer, depth, stencil,
accum, etc) associated with the named drawable to be immediately
deallocated. True is returned if <d> is a valid Mesa GLX drawable,
else False is returned. After calling glXReleaseBuffersMESA, the

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@@ -8,7 +8,7 @@ Name Strings
Contact
Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com)
Brian Paul, Tungsten Graphics, Inc. (brian 'at' tungstengraphics.com)
Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com)
Status
@@ -26,17 +26,16 @@ Number
Dependencies
OpenGL 1.0 or later is required
This extension is written against the OpenGL 1.4 Specification.
This extensions is written against the OpenGL 1.4 Specification.
NV_texture_rectangle effects the definition of this extension.
Overview
This extension supports texture images stored in the YCbCr format.
There is no support for converting YCbCr images to RGB or vice versa
during pixel transfer. The texture's YCbCr colors are converted to
RGB during texture sampling, after-which, all the usual per-fragment
operations take place. Only 2D texture images are supported (not
glDrawPixels, glReadPixels, etc).
This extension supports texture images in the YCbCr format. There is
no support for converting YCbCr images to RGB or vice versa. The
intention is for YCbCr image data to be directly sent to the renderer
without any pixel transfer operations. Only 2D texture images are
supported (not glDrawPixels, glReadPixels, etc).
A YCbCr pixel (texel) is a 16-bit unsigned short with two components.
The first component is luminance (Y). For pixels in even-numbered
@@ -62,12 +61,12 @@ New Tokens
Accepted by the <internalFormat> and <format> parameters of
TexImage2D and TexSubImage2D:
YCBCR_MESA 0x8757
GL_YCBCR_MESA 0x8757
Accepted by the <type> parameter of TexImage2D and TexSubImage2D:
UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
GL_UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */
GL_UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */
Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
@@ -75,14 +74,14 @@ Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation)
Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
In section 3.6.4, Rasterization of Pixel Rectangles, on page 101,
In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
add the following to Table 3.8 (Packed pixel formats):
type Parameter GL Data Number of Matching
Token Name Type Components Pixel Formats
-------------- ------- ---------- -------------
UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA
UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA
UNSIGNED_SHORT_8_8_MESA ushort 3 YCBCR_422_MESA
UNSIGNED_SHORT_8_8_REV_MESA ushort 3 YCBCR_422_MESA
In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
@@ -103,13 +102,13 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
+-------------------------------+-------------------------------+
In section 3.6.4, Rasterization of Pixel Rectangles, on page 104,
add the following to Table 3.12 (Packed pixel field assignments):
In section 3.6.4, Rasterization of Pixel Rectangles, on page 102,
add the following to Table 3.12 (Packed pixel fiedl assignments):
First Second Third Fourth
Format Element Element Element Element
------ ------- ------- ------- -------
YCBCR_MESA luminance chroma
YCBCR_422_MESA luminance chroma
In section 3.8.1, Texture Image Specification, on page 125, add
@@ -125,8 +124,7 @@ Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization)
TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV.
All pixel transfer operations are bypassed. The texture is stored as
YCbCr, not RGB. Queries of the texture's red, green and blue component
sizes will return zero. The YCbCr colors are converted to RGB during
texture sampling using an implementation dependent conversion.
sizes will return zero.
In section 3.8.1, Texture Image Specification, on page 126, add
@@ -183,7 +181,7 @@ Errors
<internalFormat> is MESA_YCBCR and <border> is not zero.
INVALID_OPERATION is generated by TexSubImage2D if the internal image
format is YCBCR_MESA and <format> is not YCBCR_MESA.
format is YCBCR_MESA and format is not YCBCR_MESA.
INVALID_OPERATION is generated by CopyTexSubImage2D if the internal
image is YCBCR_MESA.
@@ -197,8 +195,3 @@ New State
Revision History
20 September 2002 - Initial draft
29 April 2003 - minor updates
3 September 2003 - further clarify when YCbCr->RGB conversion takes place
19 September 2003 - a few more updates prior to submitting to extension
registry.
3 April 2004 - fix assorted inaccuracies

613
docs/README.3DFX Normal file
View File

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

181
docs/README.AMIWIN Normal file
View File

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

114
docs/README.BEOS Normal file
View File

@@ -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 $

124
docs/README.D3D Normal file
View File

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

209
docs/README.DJ Normal file
View File

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

26
docs/README.GGI Normal file
View File

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

64
docs/README.LYNXOS Normal file
View File

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

53
docs/README.MINGW32 Normal file
View File

@@ -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)

102
docs/README.MITS Normal file
View File

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

6
docs/README.NeXT Normal file
View File

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

96
docs/README.OS2 Normal file
View File

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

35
docs/README.OpenStep Normal file
View File

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

208
docs/README.QUAKE Normal file
View File

@@ -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 $

52
docs/README.THREADS Normal file
View File

@@ -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)

View File

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

View File

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

28
docs/README.VMS Normal file
View File

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

View File

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

146
docs/README.WINDML Normal file
View File

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

320
docs/README.X11 Normal file
View File

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

146
docs/RELNOTES-3.1 Normal file
View File

@@ -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 $

12
docs/RELNOTES-3.2 Normal file
View File

@@ -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 $

32
docs/RELNOTES-3.2.1 Normal file
View File

@@ -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 $

271
docs/RELNOTES-3.3 Normal file
View File

@@ -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 $

22
docs/RELNOTES-3.4 Normal file
View File

@@ -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 $

22
docs/RELNOTES-3.4.1 Normal file
View File

@@ -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 $

22
docs/RELNOTES-3.4.2 Normal file
View File

@@ -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 $

228
docs/RELNOTES-3.5 Normal file
View File

@@ -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 $

163
docs/RELNOTES-4.0 Normal file
View File

@@ -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 $

22
docs/RELNOTES-4.0.1 Normal file
View File

@@ -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 $

50
docs/RELNOTES-4.0.2 Normal file
View File

@@ -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 $

52
docs/RELNOTES-4.0.3 Normal file
View File

@@ -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 $

308
docs/RELNOTES-4.1 Normal file
View File

@@ -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 $

85
docs/RELNOTES-5.0 Normal file
View File

@@ -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 $

View File

@@ -1,3 +1,4 @@
$Id: VERSIONS,v 1.118 2002/11/13 15:33:50 brianp Exp $
Mesa Version History
@@ -103,7 +104,7 @@ Mesa Version History
- Stencil-related functions now work in display lists
Changes:
- renamed aux.h as glaux.h (MS-DOS names can't start with aux)
- most filenames are in 8.3 format to accommodate MS-DOS
- most filenames are in 8.3 format to accomodate MS-DOS
- use GLubytes to store arrays of colors instead of GLints
1.2.2 August 2, 1995
@@ -1007,7 +1008,7 @@ Mesa Version History
- glGetTexImage was using pixel unpacking instead of packing params
- auto-mipmap generation for cube maps was incorrect
Changes:
- max texture units reduced to six to accommodate texture rectangles
- max texture units reduced to six to accomodate texture rectangles
- removed unfinished GL_MESA_sprite_point extension code
@@ -1079,436 +1080,3 @@ Mesa Version History
- fixed one-bit error in point/line fragment Z calculation
- fixed potential segfault in fakeglx code
- fixed color overflow problem in DOT3 texture env mode
5.0.1 March 30, 2003
New:
- DOS driver updates from Daniel Borca
- updated GL/gl_mangle.h file (Bill Hoffman)
Bug fixes:
- auto mipmap generation for cube maps was broken (bug 641363)
- writing/clearing software alpha channels was unreliable
- minor compilation fixes for OS/2 (Evgeny Kotsuba)
- fixed some bad assertions found with shadowtex demo
- fixed error checking bug in glCopyTexSubImage2D (bug 659020)
- glRotate(angle, -x, 0, 0) was incorrect (bug 659677)
- fixed potential segfault in texture object validation (bug 659012)
- fixed some bogus code in _mesa_test_os_sse_exception_support (Linus)
- fix fog stride bug in tnl code for h/w drivers (Michel Danzer)
- fixed glActiveTexture / glMatrixMode(GL_TEXTURE) bug (#669080)
- glGet(GL_CURRENT_SECONDARY_COLOR) should return 4 values, not 3
- fixed compilation problem on Solaris7/x86 (bug 536406)
- fixed prefetch bug in 3DNow! code (Felix Kuhling)
- fixed NeXT build problem (FABSF macro)
- glDrawPixels Z values when glPixelZoom!=1 were invalid (bug 687811)
- zoomed glDraw/CopyPixels with clipping sometimes failed (bug 689964)
- AA line and triangle Z values are now rounded, not truncated
- fixed color interpolation bug when GLchan==GLfloat (bug 694461)
- glArePrograms/TexturesResident() wasn't 100% correct (Jose Fonseca)
- fixed a minor GL_COLOR_MATERIAL bug
- NV vertex program EXP instruction was broken
- glColorMask misbehaved with X window / pixmap rendering
- fix autoconf/libtool GLU C++ linker problem on Linux (a total hack)
- attempt to fix GGI compilation problem when MesaDemos not present
- NV vertex program ARL-relative fetches didn't work
Changes:
- use glPolygonOffset in gloss demo to avoid z-fighting artifacts
- updated winpos and pointblast demos to use ARB extensions
- disable SPARC normal transformation code (bug 673938)
- GLU fixes for OS/2 (Evgeny Kotsuba)
5.0.2 September 5, 2003
Bug fixes:
- fixed texgen problem causing texcoord's Q to be zero (stex3d)
- default GL_TEXTURE_COMPARE_MODE_ARB was wrong
- GL_CURRENT_MATRIX_NV query was wrong
- GL_CURRENT_MATRIX_STACK_DEPTH_NV query was off by one
- GL_LIST_MODE query wasn't correct
- GL_FOG_COORDINATE_SOURCE_EXT query wasn't supported
- GL_SECONDARY_COLOR_ARRAY_SIZE_EXT query returned wrong value
- blended, wide lines didn't always work correctly (bug 711595)
- glVertexAttrib4svNV w component was always 1
- fixed bug in GL_IBM_rasterpos_clip (missing return)
- GL_DEPTH_TEXTURE_MODE = GL_ALPHA didn't work correctly
- a few Solaris compilation fixes
- fixed glClear() problem for DRI drivers (non-existant stencil, etc)
- fixed int/REAL mixup in GLU NURBS curve evaluator (Eric Cazeaux)
- fixed delete [] bug in SI GLU (bug 721765) (Diego Santa Cruz)
- glFog() didn't clamp fog colors
- fixed bad float/int conversion for GL_TEXTURE_PRIORITY in the
gl[Get]TexParameteri[v] functions
- fixed invalid memory references in glTexGen functions (bug 781602)
- integer-valued color arrays weren't handled correctly
- glDrawPixels(GL_DEPTH_COMPONENT) with glPixelZoom didn't work
- GL_EXT_texture_lod_bias is part of 1.4, overlooked in 5.0.1
Changes:
- build GLUT with -fexceptions so C++ apps propogate exceptions
5.1 December 17, 2003
New:
- reorganized directory tree
- GL_ARB_vertex/fragment_program extensions (Michal Krol & Karl Rasche)
- GL_ATI_texture_env_combine3 extension (Ian Romanick)
- GL_SGI_texture_color_table extension (Eric Plante)
- GL_NV_fragment_program extension
- GL_NV_light_max_exponent extension
- GL_EXT_texture_rectangle (identical to GL_NV_texture_rectangle)
- GL_ARB_occlusion_query extension
- GL_ARB_point_sprite extension
- GL_ARB_texture_non_power_of_two extension
- GL_IBM_multimode_draw_arrays extension
- GL_EXT_texture_mirror_clamp extension (Ian Romanick)
- GL_ARB_vertex_buffer_object extension
- new X86 feature detection code (Petr Sebor)
- less memory used for display lists and vertex buffers
- demo of per-pixel lighting with a fragment program (demos/fplight.c)
- new version (18) of glext.h header
- new spriteblast.c demo of GL_ARB_point_sprite
- faster glDrawPixels in X11 driver in some cases (see RELNOTES-5.1)
- faster glCopyPixels in X11 driver in some cases (see RELNOTES-5.1)
Bug fixes:
- really enable OpenGL 1.4 features in DOS driver.
- fixed issues in glDrawPixels and glCopyPixels for very wide images
- glPixelMapf/ui/usv()'s size parameter is GLsizei, not GLint
- fixed some texgen bugs reported by Daniel Borca
- fixed wglMakeCurrent(NULL, NULL) bug (#835861)
- fixed glTexSubImage3D z-offset bug (Cedric Gautier)
- fixed RGBA blend enable bug (Ville Syrjala)
- glAccum is supposed to be a no-op in selection/feedback mode
- fixed texgen bug #597589 (John Popplewell)
Changes:
- dropped API trace feature (src/Trace/)
- documentation overhaul. merged with website content. more html.
- glxgears.c demo updated to use GLX swap rate extensions
- glTexImage1/2/3D now allows width/height/depth = 0
- disable SPARC asm code on Linux (bug 852204)
6.0 January 16, 2004
New:
- full OpenGL 1.5 support
- updated GL/glext.h file to version 21
Changes:
- changed max framebuffer size to 4Kx4K (MAX_WIDTH/HEIGHT in config.h)
Bug fixes:
- fixed bug in UNCLAMPED_FLOAT_TO_UBYTE macro; solves a color
clamping issue
- updated suno5-gcc configs
- glColor3 functions sometimes resulted in undefined alpha values
- fixed FP divide by zero error seen on VMS with xlockmore, others
- fixed vertex/fragment program debug problem (bug 873011)
- building on AIX with gcc works now
- glDeleteProgramsARB failed for ARB fragment programs (bug 876160)
- glDrawRangeElements tried to modify potentially read-only storage
- updated files for building on Windows
6.0.1 April 2, 2004
New:
- upgraded glext.h to version 22
- new build targets (Dan Schikore)
- new linux-x86-opteron build target (Heath Feather)
Bug fixes:
- glBindProgramARB didn't update all necessary state
- fixed build problems on OpenBSD
- omit CVS directories from tarballs
- glGetTexImage(GL_COLOR_INDEX) was broken
- fixed an infinite loop in t&l module
- silenced some valgrind warnings about using unitialized memory
- fixed some compilation/link glitches on IRIX (Mike Stephens)
- glBindProgram wasn't getting compiled into display lists
- GLX_FBCONFIG_ID wasn't recognized in glXChooseFBConfig() (bug 888079)
- two-sided lighting and vertex program didn't work (bug 887330)
- stores to program parameter registers in vertex state programs
didn't work.
- fixed glOrtho bug found with gcc 3.2.2 (RH9)
- glXCreateWindow() wasn't fully implemented (bug 890894)
- generic vertex attribute arrays didn't work in display lists
- vertex buffer objects' default usage and access fields were wrong
- glDrawArrays with start!=0 was broken
- fragment program PK2H, UP2H, UP4B and UP4UB instructions were broken
- linux-osmesa16-static config didn't work
- fixed a few color index rendering problems (bug 910687)
- glInterleavedArrays didn't respect GL_CLIENT_ACTIVE_TEXTURE
- OSMesa RGB and BGR modes were broken
- glProgramStringARB mistakenly required a null-terminated string
- fragment program XPD instruction was incorrect
- glGetMaterial() didn't work reliably
- ARB_fragment_program KIL instruction was incorrect
6.1 August 18, 2004
New:
- Revamped Makefile system
- glXUseRotatedXFont() utility (see xdemos/xuserotfont.c)
- internal driver interface changes related to texture object
allocation, vertex/fragment programs, BlendEquationSeparate, etc.
- option to walk triangle edges with double-precision floats
(Justin Novosad of Discreet) (see config.h file)
- support for AUX buffers in software GLX driver
- updated glext.h to version 24 and glxext.h to version 6
- new MESA_GLX_FORCE_ALPHA and MESA_GLX_DEPTH_BITS env vars
- updated BeOS support (Philippe Houdoin)
Changes:
- fragment fog interpolation is perspective corrected now
- new glTexImage code, much cleaner, may be a bit faster
Bug fixes:
- glArrayElement in display lists didn't handle generic vertex attribs
- glFogCoord didn't always work properly
- ARB_fragment_program fog options didn't work
- frag prog TEX instruction no longer incorrectly divides s,t,r by q
- ARB frag prog TEX and TEXP instructions now use LOD=0
- glTexEnviv in display lists didn't work
- glRasterPos didn't do texgen or apply texture matrix
- GL_DOUBLE-valued vertex arrays were broken in some cases
- fixed texture rectangle edge/border sampling bugs
- sampling an incomplete texture in a fragment program would segfault
- glTexImage was missing a few error checks
- fixed some minor glGetTexParameter glitches
- GL_INTENSITY was mistakenly accepted as a <format> to glTexImage
- fragment program writes to RC/HC register were broken
- fixed a few glitches in GL_HP_occlusion_test extension
- glBeginQueryARB and glEndQueryARB didn't work inside display lists
- vertex program state references were broken
- fixed triangle color interpolation bug on AIX (Shane Blackett)
- fixed a number of minor memory leaks (bug #1002030)
6.2 October 2, 2004
New:
- enabled GL_ARB_texture_rectangle (same as GL_NV_texture_rectangle)
- updated Doxygen support (Jose Fonseca)
Changes:
- some GGI driver updates (Christoph Egger, bug 1025977)
Bug fixes:
- Omit GL_ARB_texture_non_power_of_two from list of OpenGL 1.5 features
- fixed a few compilation issues on IRIX
- fixed a matrix classification bug (reported by Wes Bethel)
- we weren't reseting the vertex/fragment program error state
before parsing (Dave Reveman)
- adjust texcoords for sampling texture rectangles (Dave Reveman)
- glGet*(GL_MAX_VERTEX_ATTRIBS_ARB) wasn't implemented
- repeated calls to glDeleteTexture(t) could lead to a crash
- fixed potential ref count bugs in VBOs and vertex/fragment programs
- spriteblast demo didn't handle window size changes correctly
- glTexSubImage didn't handle pixels=NULL correctly for PBOs
- fixed color index mode glDrawPixels bug (Karl Schultz)
6.2.1 December 9, 2004
Bug fixes:
- don't apply regular fog or color sum when using a fragment program
- glProgramEnvParameter4fARB always generated an error on
GL_FRAGMENT_PROGRAM_ARB (fdo bug 1645)
- glVertexAttrib3svNV and glVertexAttrib3svARB were broken
- fixed width/height mix-up in glSeparableFilter2D()
- fixed regression in glCopyPixels + convolution
- glReadPixels from a clipped front color buffer didn't always work
- glTexImage didn't accept GL_RED/GREEN/BLUE as the format
- Attempting queries/accesses of VBO 0 weren't detected as errors
- paletted textures failed if the palette had fewer than 256 entries
Changes:
- fixed a bunch of compiler warnings found with gcc 3.4
- bug reports should to go bugzilla.freedesktop.org
6.3 July 20, 2005
New:
- GL_EXT_framebuffer_object extension
- GL_ARB_draw_buffers extension
- GL_ARB_pixel_buffer_object extension
- GL_OES_read_format extension (Ian Romanick)
- DirectFB driver (Claudio Ciccani)
- x86_64 vertex transformation code (Mikko T.)
- Updated GL/glext.h to version 29
Changes:
- added -stereo option for glxgears demo (Jacek Rosik)
- updated the PBuffer demo code in xdemos/ directory
- glDeleteTextures/Programs/Buffers() now makes the object ID
available for immediate re-use
- assorted 64-bit clean-ups fixes (x86_64 and Win64)
- lots of internal changes for GL_EXT_framebuffer_object
Bug fixes:
- some functions didn't support PBO functionality
- glGetTexImage didn't convert color index images to RGBA as required
- fragment program texcoords were sometimes wrong for points and lines
- fixed problem with negative dot product in arbfplight, fplight demos
- fixed bug in perspective correction of antialiased, textured lines
- querying GL_POST_CONVOLUTION_ALPHA_BIAS_EXT returned wrong value
- fixed a couple per-pixel fog bugs (Soju Matsumoto)
- glGetBooleanv(GL_FRAGMENT_PROGRAM_BINDING_NV) was broken
- fixed float parsing bug in ARB frag/vert programs (bug 2520)
- XMesaGetDepthBuffer() returned incorrect value for bytesPerValue
- GL_COLOR_MATERIAL with glColor3 didn't properly set diffuse alpha
- glXChooseFBConfig() crashed if attribList pointer was NULL
- program state.light[n].spot.direction.w was wrong value (bug 3083)
- fragment program fog option required glEnable(GL_FOG) - wrong.
- glColorTable() could produce a Mesa implementation error (bug 3135)
- RasterPos could get corrupted by color index rendering path
- Removed bad XTranslateCoordinates call when rendering to Pixmaps
- glPopAttrib() didn't properly restore GL_TEXTURE_GEN enable state
- fixed a few Darwin compilation problems
6.3.1
This was an intermediate release for X.org which wasn't otherwise released.
6.3.2 August 19, 2005
New:
- The distribution now includes the DRI drivers and GLX code
Changes:
- Made the DRI "new" driver interface standard, remove old code
Bug fixes:
- GL_ARB_vertex/fragment_shader were mistakenly listed in the
extensions string
- negative relative addressing in vertex programs was broken
- update/fix SPARC assembly code for vertex transformation
- fixed memory leak when freeing GLX drawables/renderbuffers
- fixed display list memory leak
- the GL_PIXEL_MAP_I_TO_I table is now floating point, not integer
- wglGetProcAddress() didn't handle wgl-functions
- fixed glxext.h cross-compile issue (Colin Harrison)
- assorted DRI driver fixes
6.4 October 24, 2005
New:
- Added a fast XOR line drawing function in Xlib driver
- Added support for GL_ARB_texture_mirrored_repeat to savage
driver (supported only on Savage4 hardware).
Changes:
- Mesa now packaged in three parts: Library, Demos and GLUT
Bug fixes:
- GLX_X_RENDERABLE token wasn't accepted by glXChooseFBConfig
- Some files were present multiple times in the 6.3.2 tarballs
- r200_vtxtmp_x86.S file was missing from 6.3.2 tarball (bug 4207)
- glxgears_fbconfig demo didn't work (bug 4237)
- fixed bug when bilinear sampling 2d textures with borders
- glXCreatePbuffer() could segfault instead of returning 0 (bug 4235)
- fixed undefined frexp and rand in X.org libGLcore.a (bug 4242)
- fixed a few problems with proxy color tables (bug 4270)
- fixed precision problem in Z clearing (bug 4395)
- glBitmap, glDraw/CopyPixels mistakenly generated selection hits
- fixed potential segfault caused by reading pixels outside
of renderbuffer bounds
- glGetTexLevelParameter didn't accept GL_TEXTURE_DEPTH_SIZE_ARB
- fixed memory corruption bug involving software alpha buffers
- glReadPixels clipped by window bounds was sometimes broken
- glDraw/CopyPixels of stencil data ignored the stencil write mask
- glReadPixels from a texture bound to a framebuffer object didn't work
- glIsRender/FramebufferEXT weren't totally correct
- fixed a number of point size attenuation/fade bugs
- fixed glFogCoord bug 4729
- GLX encoding for transpose matrix functions was broken
- fixed broken fragment program KIL and SWZ instructions
- fragment programs that wrote result.depth.z didn't work
6.4.1 November 30, 2005
Bug fixes:
- redefining a vertex program string didn't take effect in TNL module
- fixed occasional segfault upon vertex/fragment parsing error
- vertex program LIT instruction didn't handle 0^0=1 correctly
- fragment program fog option didn't work with glDrawPixels, glBitmap
- USE_MGL_NAMESPACE didn't work for x86-64
- OSMesa demos were missing from previous release tarballs
- fixed problem with float->ushort conversion in glClear (bug 4992)
- popping of GL_EYE_PLANE texgen state was broken (bug 4996)
- popping of GL_SPOT_DIRECTION light state was broken (bug 5005)
- fixed occasional triangle color interpolation problem on VMS
- work around invalid free() call (bug 5131)
- fixed BSD X server compilation problem by including stdint.h
6.4.2 February 2, 2006
New:
- added OSMesaColorClamp() function/feature
- added wglGetExtensionStringARB() function
Bug fixes:
- fixed some problems when building on Windows
- GLw header files weren't installed by installmesa script (bug 5396)
- GL/glfbdev.h file was missing from tarballs
- fixed TNL initialization bug which could lead to crash (bug 5791)
6.5 March 31, 2006
New:
- OpenGL Shading Language support through GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_vertex_shader and
GL_ARB_fragment_shader (done by Michal Krol)
- GL_EXT_packed_depth_stencil extension
- GL_EXT_timer_query extension
- GL_EXT_framebuffer_blit extension
- GL_ARB_half_float_pixel
- reflect demo improved to support multiple windows
- singlebuffer demo (shows no/little-flicker single-buffered rendering)
- r200: enable GL_ARB_texture_env_crossbar, separate the texture
sampling unit bits from the texture env combine enable bits
- r200: add support for GL_ATI_fragment_shader
- added fast XOR-mode line drawing optimization
- radeon: add support for all 3 tmus, GL_ARB_texture_cube_map
and GL_EXT_fog_coord
- MESA_GLX_ALPHA_BITS env var for xlib driver
- many DRI driver updates (including screen rotation support
for the Intel DRI driver)
Changes:
- removed GL_HP_occlusion_test (use GL_ARB_occlusion_query instead)
- removed GL_SGIX/SGIS_pixel_texture extensions
Bug fixes:
- fixed glxcontextmodes.c datatype problem (bug 5835)
- fixed aix-gcc build/install bugs (bug 5874)
- fixed some bugs in texture env program generation
- glXCopyContext() didn't handle texture object bindings properly
- glXCopyContext() didn't copy all lighting state
- fixed FreeBSD config (Pedro Giffuni)
- fixed some minor framebuffer object bugs
- replaced dprintf() with _glu_printf() in GLU (bug 6244)
- fixed a number of thread safety bugs/regressions
- fixed a number of GLU tesselator bugs (John Shell, bug 6339)
- paletted texturing was broken w/ floating point palettes (K. Schultz)
- lots of assorted framebuffer object bug fixes
6.5.1 August 31, 2006
New:
- Intel i965 DRI driver
- GL_APPLE_vertex_array_object extension (Ian Romanick)
- GL_EXT_texture_sRGB extension
- GL_EXT_gpu_program_parameters (Ian Romanick)
- "engine" demo
- updated fbdev driver and GLUT for fbdev (Sean D'Epagnier)
- many updates to the DRI drivers
Changes:
- The glVertexAttribARB functions no longer alias the conventional
vertex attributes.
- glxinfo program prints more info with -l option
- GL_FRAGMENT_PROGRAM_NV and GL_FRAGMENT_PROGRAM_ARB are now
compatible, in terms of glBindProgramARB()
Bug fixes:
- fixed broken texture border handling for depth textures (bug 6498)
- removed the test for duplicated framebuffer attachments, per
version 117 of the GL_EXT_framebuffer_object specification
- fixed a few render-to-texture bugs, including render to depth texture
- clipping of lines against user-defined clip planes was broken (6512)
- assembly language dispatch for SPARC was broken (bug 6484)
- assorted compilation fixes on various Unix platforms (Dan Schikore)
- glPopAttrib could restore an invalid value for GL_DRAW_BUFFER
- assorted minor fixes for 16 and 32 bit/channel modes
- fixed assorted bugs in texture compression paths
- fixed indirect rendering vertex array crashes (bug 6863)
- glDrawPixels GL_INDEX_OFFSET didn't always work
- fixed convolution memory leak (bug 7077)
- rectangular depth textures didn't work
- invalid mode to glBegin didn't generate an error (bug 7142)
- 'normalized' parameter to glVertexAttribPointerARB didn't work
- disable bogus GLX_SGI_video_sync extension in xlib driver
- fixed R128 driver locking bug (Martijn van Oosterhout)
- using evaluators with vertex programs caused crashes (bug 7564)
- fragment.position wasn't set correctly for point/line primitives
- fixed parser bug for scalar sources for GL_NV_fragment_program
- max fragment program length was incorrectly 128, now 1024
- writes to result.depth in fragment programs weren't clamped to [0,1]
- fixed potential dangling pointer bug in glBindProgram()
- fixed some memory leaks (and potential crashes) in Xlib driver

View File

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

View File

@@ -1,255 +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 and the debug/optimisation
level is left unchanged.</p>
</dd>
<dt><code>LDFLAGS</code></dt>
<dd><p>An environment variable specifying flags to
pass when linking programs. These should be empty and
<code>PKG_CONFIG_PATH</code> is recommended to be used instead. If needed
it 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>The
<code>pkg-config</code> utility is a hard requirement for cofiguring and
building mesa. It 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>--build=</code></dt>
<dt><code>--host=</code></dt>
<dd><p>By default, the build will compile code for the architecture that
it's running on. In order to build cross-compile Mesa on a x86-64 machine
that is to run on a i686, one would need to set the options to:</p>
<p><code>--build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu</code></p>
Note that these can vary from distribution to distribution. For more
information check with the
<a href="https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html">
autoconf manual</a>.
Note that you will need to correctly set <code>PKG_CONFIG_PATH</code> as well.
<p>In some cases a single compiler is capable of handling both architectures
(multilib) in that case one would need to set the <code>CC,CXX</code> variables
appending the correct machine options. Seek your compiler documentation for
further information -
<a href="https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html"> gcc
machine dependent options</a></p>
<p>In addition to specifying correct <code>PKG_CONFIG_PATH</code> for the target
architecture, the following should be sufficient to configure multilib Mesa</p>
<code>./configure CC="gcc -m32" CXX="g++ -m32" --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu ...</code>
</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><p><strong>DEPRECATED</strong>, use <code>PKG_CONFIG_PATH</code> instead.</p>
<p>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>

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@@ -1,712 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Development Notes</title>
<link rel="stylesheet" type="text/css" href="mesa.css">
</head>
<body>
<div class="header">
<h1>The Mesa 3D Graphics Library</h1>
</div>
<iframe src="contents.html"></iframe>
<div class="content">
<h1>Development Notes</h1>
<ul>
<li><a href="#style">Coding Style</a>
<li><a href="#submitting">Submitting Patches</a>
<li><a href="#release">Making a New Mesa Release</a>
<li><a href="#extensions">Adding Extensions</a>
</ul>
<h2 id="style">Coding Style</h2>
<p>
Mesa is over 20 years old and the coding style has evolved over time.
Some old parts use a style that's a bit out of date.
If the guidelines below don't cover something, try following the format of
existing, neighboring code.
</p>
<p>
Basic formatting guidelines
</p>
<ul>
<li>3-space indentation, no tabs.
<li>Limit lines to 78 or fewer characters. The idea is to prevent line
wrapping in 80-column editors and terminals. There are exceptions, such
as if you're defining a large, static table of information.
<li>Opening braces go on the same line as the if/for/while statement.
For example:
<pre>
if (condition) {
foo;
} else {
bar;
}
</pre>
<li>Put a space before/after operators. For example, <tt>a = b + c;</tt>
and not <tt>a=b+c;</tt>
<li>This GNU indent command generally does the right thing for formatting:
<pre>
indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
</pre>
<li>Use comments wherever you think it would be helpful for other developers.
Several specific cases and style examples follow. Note that we roughly
follow <a href="http://www.stack.nl/~dimitri/doxygen/">Doxygen</a> conventions.
<br>
<br>
Single-line comments:
<pre>
/* null-out pointer to prevent dangling reference below */
bufferObj = NULL;
</pre>
Or,
<pre>
bufferObj = NULL; /* prevent dangling reference below */
</pre>
Multi-line comment:
<pre>
/* If this is a new buffer object id, or one which was generated but
* never used before, allocate a buffer object now.
*/
</pre>
We try to quote the OpenGL specification where prudent:
<pre>
/* Page 38 of the PDF of the OpenGL ES 3.0 spec says:
*
* "An INVALID_OPERATION error is generated for any of the following
* conditions:
*
* * <length> is zero."
*
* Additionally, page 94 of the PDF of the OpenGL 4.5 core spec
* (30.10.2014) also says this, so it's no longer allowed for desktop GL,
* either.
*/
</pre>
Function comment example:
<pre>
/**
* Create and initialize a new buffer object. Called via the
* ctx->Driver.CreateObject() driver callback function.
* \param name integer name of the object
* \param type one of GL_FOO, GL_BAR, etc.
* \return pointer to new object or NULL if error
*/
struct gl_object *
_mesa_create_object(GLuint name, GLenum type)
{
/* function body */
}
</pre>
<li>Put the function return type and qualifiers on one line and the function
name and parameters on the next, as seen above. This makes it easy to use
<code>grep ^function_name dir/*</code> to find function definitions. Also,
the opening brace goes on the next line by itself (see above.)
<li>Function names follow various conventions depending on the type of function:
<pre>
glFooBar() - a public GL entry point (in glapi_dispatch.c)
_mesa_FooBar() - the internal immediate mode function
save_FooBar() - retained mode (display list) function in dlist.c
foo_bar() - a static (private) function
_mesa_foo_bar() - an internal non-static Mesa function
</pre>
<li>Constants, macros and enumerant names are ALL_UPPERCASE, with _ between
words.
<li>Mesa usually uses camel case for local variables (Ex: "localVarname")
while gallium typically uses underscores (Ex: "local_var_name").
<li>Global variables are almost never used because Mesa should be thread-safe.
<li>Booleans. 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.
</ul>
<h2 id="submitting">Submitting patches</h2>
<p>
The basic guidelines for submitting patches are:
</p>
<ul>
<li>Patches should be sufficiently tested before submitting.
<li>Code patches should follow Mesa coding conventions.
<li>Whenever possible, patches should only effect individual Mesa/Gallium
components.
<li>Patches should never introduce build breaks and should be bisectable (see
<code>git bisect</code>.)
<li>Patches should be properly formatted (see below).
<li>Patches should be submitted to mesa-dev for review using
<code>git send-email</code>.
<li>Patches should not mix code changes with code formatting changes (except,
perhaps, in very trivial cases.)
</ul>
<h3>Patch formatting</h3>
<p>
The basic rules for patch formatting are:
</p>
<ul>
<li>Lines should be limited to 75 characters or less so that git logs
displayed in 80-column terminals avoid line wrapping. Note that git
log uses 4 spaces of indentation (4 + 75 &lt; 80).
<li>The first line should be a short, concise summary of the change prefixed
with a module name. Examples:
<pre>
mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY
i965: Fix missing type in local variable declaration.
</pre>
<li>Subsequent patch comments should describe the change in more detail,
if needed. For example:
<pre>
i965: Remove end-of-thread SEND alignment code.
This was present in Eric's initial implementation of the compaction code
for Sandybridge (commit 077d01b6). There is no documentation saying this
is necessary, and removing it causes no regressions in piglit on any
platform.
</pre>
<li>A "Signed-off-by:" line is not required, but not discouraged either.
<li>If a patch address a bugzilla issue, that should be noted in the
patch comment. For example:
<pre>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
</pre>
<li>If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
<pre>
st/mesa: add ARB_texture_stencil8 support (v4)
if we support stencil texturing, enable texture_stencil8
there is no requirement to support native S8 for this,
the texture can be converted to x24s8 fine.
v2: fold fixes from Marek in:
a) put S8 last in the list
b) fix renderable to always test for d/s renderable
fixup the texture case to use a stencil only format
for picking the format for the texture view.
v3: hit fallback for getteximage
v4: put s8 back in front, it shouldn't get picked now (Ilia)
</pre>
<li>If someone tested your patch, document it with a line like this:
<pre>
Tested-by: Joe Hacker &lt;jhacker@foo.com&gt;
</pre>
<li>If the patch was reviewed (usually the case) or acked by someone,
that should be documented with:
<pre>
Reviewed-by: Joe Hacker &lt;jhacker@foo.com&gt;
Acked-by: Joe Hacker &lt;jhacker@foo.com&gt;
</pre>
</ul>
<h3>Testing Patches</h3>
<p>
It should go without saying that patches must be tested. In general,
do whatever testing is prudent.
</p>
<p>
You should always run the Mesa test suite before submitting patches.
The test suite 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>
Whenever possible and applicable, test the patch with
<a href="http://piglit.freedesktop.org">Piglit</a> to
check for regressions.
</p>
<h3>Mailing Patches</h3>
<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>
<p>
When submitting follow-up patches you should also login to
<a href="https://patchwork.freedesktop.org">patchwork</a> and change the
state of your old patches to Superseded.
</p>
<h3>Reviewing Patches</h3>
<p>
When you've reviewed a patch on the mailing list, please be unambiguous
about your review. That is, state either
<pre>
Reviewed-by: Joe Hacker &lt;jhacker@foo.com&gt;
</pre>
or
<pre>
Acked-by: Joe Hacker &lt;jhacker@foo.com&gt;
</pre>
Rather than saying just "LGTM" or "Seems OK".
</p>
<p>
If small changes are suggested, it's OK to say something like:
<pre>
With the above fixes, Reviewed-by: Joe Hacker &lt;jhacker@foo.com&gt;
</pre>
which tells the patch author that the patch can be committed, as long
as the issues are resolved first.
</p>
<h3>Marking a commit as a candidate for a stable branch</h3>
<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.
<h3>Criteria for accepting patches to the stable branch</h3>
Mesa has a designated release manager for each stable branch, and the release
manager is the only developer that should be pushing changes to these
branches. Everyone else should simply nominate patches using the mechanism
described above.
The stable-release manager will work with the list of nominated patches, and
for each patch that meets the crtieria below will cherry-pick the patch with:
<code>git cherry-pick -x &lt;commit&gt;</code>. The <code>-x</code> option is
important so that the picked patch references the comit ID of the original
patch.
The stable-release manager may at times need to force-push changes to the
stable branches, for example, to drop a previously-picked patch that was later
identified as causing a regression). These force-pushes may cause changes to
be lost from the stable branch if developers push things directly. Consider
yourself warned.
The stable-release manager is also given broad discretion in rejecting patches
that have been nominated for the stable branch. The most basic rule is that
the stable branch is for bug fixes only, (no new features, no
regressions). Here is a non-exhaustive list of some reasons that a patch may
be rejected:
<ul>
<li>Patch introduces a regression. Any reported build breakage or other
regression caused by a particular patch, (game no longer work, piglit test
changes from PASS to FAIL), is justification for rejecting a patch.</li>
<li>Patch is too large, (say, larger than 100 lines)</li>
<li>Patch is not a fix. For example, a commit that moves code around with no
functional change should be rejected.</li>
<li>Patch fix is not clearly described. For example, a commit message
of only a single line, no description of the bug, no mention of bugzilla,
etc.</li>
<li>Patch has not obviously been reviewed, For example, the commit message
has no Reviewed-by, Signed-off-by, nor Tested-by tags from anyone but the
author.</li>
<li>Patch has not already been merged to the master branch. As a rule, bug
fixes should never be applied first to a stable branch. Patches should land
first on the master branch and then be cherry-picked to a stable
branch. (This is to avoid future releases causing regressions if the patch
is not also applied to master.) The only things that might look like
exceptions would be backports of patches from master that happen to look
significantly different.</li>
<li>Patch depends on too many other patches. Ideally, all stable-branch
patches should be self-contained. It sometimes occurs that a single, logical
bug-fix occurs as two separate patches on master, (such as an original
patch, then a subsequent fix-up to that patch). In such a case, these two
patches should be squashed into a single, self-contained patch for the
stable branch. (Of course, if the squashing makes the patch too large, then
that could be a reason to reject the patch.)</li>
<li>Patch includes new feature development, not bug fixes. New OpenGL
features, extensions, etc. should be applied to Mesa master and included in
the next major release. Stable releases are intended only for bug fixes.
Note: As an exception to this rule, the stable-release manager may accept
hardware-enabling "features". For example, backports of new code to support
a newly-developed hardware product can be accepted if they can be reasonably
determined to not have effects on other hardware.</li>
<li>Patch is a performance optimization. As a rule, performance patches are
not candidates for the stable branch. The only exception might be a case
where an application's performance was recently severely impacted so as to
become unusable. The fix for this performance regression could then be
considered for a stable branch. The optimization must also be
non-controversial and the patches still need to meet the other criteria of
being simple and self-contained</li>
<li>Patch introduces a new failure mode (such as an assert). While the new
assert might technically be correct, for example to make Mesa more
conformant, this is not the kind of "bug fix" we want in a stable
release. The potential problem here is that an OpenGL program that was
previously working, (even if technically non-compliant with the
specification), could stop working after this patch. So that would be a
regression that is unaacceptable for the stable branch.</li>
</ul>
<h2 id="release">Making a New Mesa Release</h2>
<p>
These are the instructions for making a new Mesa release.
</p>
<h3>Get latest source files</h3>
<p>
Use git to get the latest Mesa files from the git repository, from whatever
branch is relevant. This document uses the convention X.Y.Z for the release
being created, which should be created from a branch named X.Y.
</p>
<h3>Perform basic testing</h3>
<p>
The release manager should, at the very least, test the code by compiling it,
installing it, and running the latest piglit to ensure that no piglit tests
have regressed since the previous release.
</p>
<p>
The release manager should do this testing with at least one hardware driver,
(say, whatever is contained in the local development machine), as well as on
both Gallium and non-Gallium software drivers. The software testing can be
performed by running piglit with the following environment-variable set:
</p>
<pre>
LIBGL_ALWAYS_SOFTWARE=1
</pre>
And Gallium vs. non-Gallium software drivers can be obtained by using the
following configure flags on separate builds:
<pre>
--with-dri-drivers=swrast
--with-gallium-drivers=swrast
</pre>
<p>
Note: If both options are given in one build, both swrast_dri.so drivers will
be compiled, but only one will be installed. The following command can be used
to ensure the correct driver is being tested:
</p>
<pre>
LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep "renderer string"
</pre>
If any regressions are found in this testing with piglit, stop here, and do
not perform a release until regressions are fixed.
<h3>Update version in file VERSION</h3>
<p>
Increment the version contained in the file VERSION at Mesa's top-level, then
commit this change.
</p>
<h3>Create release notes for the new release</h3>
<p>
Create a new file docs/relnotes/X.Y.Z.html, (follow the style of the previous
release notes). Note that the sha256sums section of the release notes should
be empty at this point.
</p>
<p>
Two scripts are available to help generate portions of the release notes:
<pre>
./bin/bugzilla_mesa.sh
./bin/shortlog_mesa.sh
</pre>
<p>
The first script identifies commits that reference bugzilla bugs and obtains
the descriptions of those bugs from bugzilla. The second script generates a
log of all commits. In both cases, HTML-formatted lists are printed to stdout
to be included in the release notes.
</p>
<p>
Commit these changes
</p>
<h3>Make the release archives, signatures, and the release tag</h3>
<p>
From inside the Mesa directory:
<pre>
./autogen.sh
make -j1 tarballs
</pre>
<p>
After the tarballs are created, the sha256 checksums for the files will
be computed and printed. These will be used in a step below.
</p>
<p>
It's important at this point to also verify that the constructed tar file
actually builds:
</p>
<pre>
tar xjf MesaLib-X.Y.Z.tar.bz2
cd Mesa-X.Y.Z
./configure --enable-gallium-llvm
make -j6
make install
</pre>
<p>
Some touch testing should also be performed at this point, (run glxgears or
more involved OpenGL programs against the installed Mesa).
</p>
<p>
Create detached GPG signatures for each of the archive files created above:
</p>
<pre>
gpg --sign --detach MesaLib-X.Y.Z.tar.gz
gpg --sign --detach MesaLib-X.Y.Z.tar.bz2
gpg --sign --detach MesaLib-X.Y.Z.zip
</pre>
<p>
Tag the commit used for the build:
</p>
<pre>
git tag -s mesa-X.Y.X -m "Mesa X.Y.Z release"
</pre>
<p>
Note: It would be nice to investigate and fix the issue that causes the
tarballs target to fail with multiple build process, such as with "-j4". It
would also be nice to incorporate all of the above commands into a single
makefile target. And instead of a custom "tarballs" target, we should
incorporate things into the standard "make dist" and "make distcheck" targets.
</p>
<h3>Add the sha256sums to the release notes</h3>
<p>
Edit docs/relnotes/X.Y.Z.html to add the sha256sums printed as part of "make
tarballs" in the previous step. Commit this change.
</p>
<h3>Push all commits and the tag created above</h3>
<p>
This is the first step that cannot easily be undone. The release is going
forward from this point:
</p>
<pre>
git push origin X.Y --tags
</pre>
<h3>Install the release files and signatures on the distribution server</h3>
<p>
The following commands can be used to copy the release archive files and
signatures to the freedesktop.org server:
</p>
<pre>
scp MesaLib-X.Y.Z* people.freedesktop.org:
ssh people.freedesktop.org
cd /srv/ftp.freedesktop.org/pub/mesa
mkdir X.Y.Z
cd X.Y.Z
mv ~/MesaLib-X.Y.Z* .
</pre>
<h3>Back on mesa master, add the new release notes into the tree</h3>
<p>
Something like the following steps will do the trick:
</p>
<pre>
cp docs/relnotes/X.Y.Z.html /tmp
git checkout master
cp /tmp/X.Y.Z.html docs/relnotes
git add docs/relnotes/X.Y.Z.html
</pre>
<p>
Also, edit docs/relnotes.html to add a link to the new release notes, and edit
docs/index.html to add a news entry. Then commit and push:
</p>
<pre>
git commit -a -m "docs: Import X.Y.Z release notes, add news item."
git push origin
</pre>
<h3>Update the mesa3d.org website</h3>
<p>
NOTE: The recent release managers have not been performing this step
themselves, but leaving this to Brian Paul, (who has access to the
sourceforge.net hosting for mesa3d.org). Brian is more than willing to grant
the permission necessary to future release managers to do this step on their
own.
</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>
<h3>Announce the release</h3>
<p>
Make an announcement on the mailing lists:
<em>mesa-dev@lists.freedesktop.org</em>,
and
<em>mesa-announce@lists.freedesktop.org</em>
Follow the template of previously-sent release announcements. The following
command can be used to generate the log of changes to be included in the
release announcement:
<pre>
git shortlog mesa-X.Y.Z-1..mesa-X.Y.Z
</pre>
</p>
<h2 id="extensions">Adding Extensions</h2>
<p>
To add a new GL extension to Mesa you have to do at least the following.
<ul>
<li>
If glext.h doesn't define the extension, edit include/GL/gl.h and add
code like this:
<pre>
#ifndef GL_EXT_the_extension_name
#define GL_EXT_the_extension_name 1
/* declare the new enum tokens */
/* prototype the new functions */
/* TYPEDEFS for the new functions */
#endif
</pre>
</li>
<li>
In the src/mapi/glapi/gen/ directory, add the new extension functions and
enums to the gl_API.xml file.
Then, a bunch of source files must be regenerated by executing the
corresponding Python scripts.
</li>
<li>
Add a new entry to the <code>gl_extensions</code> struct in mtypes.h
</li>
<li>
Update the <code>extensions.c</code> file.
</li>
<li>
From this point, the best way to proceed is to find another extension,
similar to the new one, that's already implemented in Mesa and use it
as an example.
</li>
<li>
If the new extension adds new GL state, the functions in get.c, enable.c
and attrib.c will most likely require new code.
</li>
<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>
</div>
</body>
</html>

View File

@@ -1,278 +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 #3 is used.</li>
<li>If <tt>HAVE_PTHREAD</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>

View File

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

View File

@@ -1,289 +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>--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>wayland</code>, <code>null</code>, <code>android</code>,
<code>haiku</code>, and <code>gdi</code>. The <code>android</code> platform
can only be built as a system component, part of AOSP, while the
<code>haiku</code> and <code>gdi</code> platforms 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>
</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>
</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>
<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.</p>
<h2>Developers</h2>
<p>The sources of the main library and drivers can be found at
<code>src/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>

View File

@@ -1,239 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Environment Variables</title>
<link rel="stylesheet" type="text/css" href="mesa.css">
</head>
<body>
<div class="header">
<h1>The Mesa 3D Graphics Library</h1>
</div>
<iframe src="contents.html"></iframe>
<div class="content">
<h1>Environment Variables</h1>
<p>
Normally, no environment variables need to be set. Most of the environment
variables used by Mesa/Gallium are for debugging purposes, but they can
sometimes be useful for debugging end-user issues.
</p>
<h2>LibGL environment variables</h2>
<ul>
<li>LIBGL_DEBUG - If defined debug information will be printed to stderr.
If set to 'verbose' additional information will be printed.
<li>LIBGL_DRIVERS_PATH - colon-separated list of paths to search for DRI drivers
<li>LIBGL_ALWAYS_INDIRECT - forces an indirect rendering context/connection.
<li>LIBGL_ALWAYS_SOFTWARE - if set, always use software rendering
<li>LIBGL_NO_DRAWARRAYS - if set do not use DrawArrays GLX protocol (for debugging)
<li>LIBGL_SHOW_FPS - print framerate to stdout based on the number of glXSwapBuffers
calls per second.
<li>LIBGL_DRI3_DISABLE - disable DRI3 if set (the value does not matter)
</ul>
<h2>Core Mesa environment variables</h2>
<ul>
<li>MESA_NO_ASM - if set, disables all assembly language optimizations
<li>MESA_NO_MMX - if set, disables Intel MMX optimizations
<li>MESA_NO_3DNOW - if set, disables AMD 3DNow! optimizations
<li>MESA_NO_SSE - if set, disables Intel SSE optimizations
<li>MESA_DEBUG - if set, error messages are printed to stderr. For example,
if the application generates a GL_INVALID_ENUM error, a corresponding error
message indicating where the error occurred, and possibly why, will be
printed to stderr.<br>
If the value of MESA_DEBUG is 'FP' floating point arithmetic errors will
generate exceptions.
<li>MESA_LOG_FILE - specifies a file name for logging all errors, warnings,
etc., rather than stderr
<li>MESA_TEX_PROG - if set, implement conventional texture env modes with
fragment programs (intended for developers only)
<li>MESA_TNL_PROG - if set, implement conventional vertex transformation
operations with vertex programs (intended for developers only).
Setting this variable automatically sets the MESA_TEX_PROG variable as well.
<li>MESA_EXTENSION_OVERRIDE - can be used to enable/disable extensions.
A value such as "GL_EXT_foo -GL_EXT_bar" will enable the GL_EXT_foo extension
and disable the GL_EXT_bar extension.
<li>MESA_EXTENSION_MAX_YEAR - The GL_EXTENSIONS string returned by Mesa is sorted
by extension year.
If this variable is set to year X, only extensions defined on or before year
X will be reported.
This is to work-around a bug in some games where the extension string is
copied into a fixed-size buffer without truncating.
If the extension string is too long, the buffer overrun can cause the game
to crash.
This is a work-around for that.
<li>MESA_GL_VERSION_OVERRIDE - changes the value returned by
glGetString(GL_VERSION) and possibly the GL API type.
<ul>
<li> The format should be MAJOR.MINOR[FC]
<li> FC is an optional suffix that indicates a forward compatible context.
This is only valid for versions &gt;= 3.0.
<li> GL versions &lt; 3.0 are set to a compatibility (non-Core) profile
<li> GL versions = 3.0, see below
<li> GL versions &gt; 3.0 are set to a Core profile
<li> Examples: 2.1, 3.0, 3.0FC, 3.1, 3.1FC
<ul>
<li> 2.1 - select a compatibility (non-Core) profile with GL version 2.1
<li> 3.0 - select a compatibility (non-Core) profile with GL version 3.0
<li> 3.0FC - select a Core+Forward Compatible profile with GL version 3.0
<li> 3.1 - select a Core profile with GL version 3.1
<li> 3.1FC - select a Core+Forward Compatible profile with GL version 3.1
</ul>
<li> Mesa may not really implement all the features of the given version.
(for developers only)
</ul>
<li>MESA_GLSL_VERSION_OVERRIDE - changes the value returned by
glGetString(GL_SHADING_LANGUAGE_VERSION). Valid values are integers, such as
"130". Mesa will not really implement all the features of the given language version
if it's higher than what's normally reported. (for developers only)
<li>MESA_GLSL - <a href="shading.html#envvars">shading language compiler options</a>
</ul>
<h2>Mesa Xlib driver environment variables</h2>
<p>
The following are only applicable to the Mesa Xlib software driver.
See the <a href="xlibdriver.html">Xlib software driver page</a> for details.
</p>
<ul>
<li>MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode
<li>MESA_CI_VISUAL - specifies the X visual and depth for CI mode
<li>MESA_BACK_BUFFER - specifies how to implement the back color buffer,
either "pixmap" or "ximage"
<li>MESA_GAMMA - gamma correction coefficients for red, green, blue channels
<li>MESA_XSYNC - enable synchronous X behavior (for debugging only)
<li>MESA_GLX_FORCE_CI - if set, force GLX to treat 8bpp visuals as CI visuals
<li>MESA_GLX_FORCE_ALPHA - if set, forces RGB windows to have an alpha channel.
<li>MESA_GLX_DEPTH_BITS - specifies default number of bits for depth buffer.
<li>MESA_GLX_ALPHA_BITS - specifies default number of bits for alpha channel.
</ul>
<h2>i945/i965 driver environment variables (non-Gallium)</h2>
<ul>
<li>INTEL_NO_HW - if set to 1, prevents batches from being submitted to the hardware.
This is useful for debugging hangs, etc.</li>
<li>INTEL_DEBUG - a comma-separated list of named flags, which do various things:
<ul>
<li>tex - emit messages about textures.</li>
<li>state - emit messages about state flag tracking</li>
<li>blit - emit messages about blit operations</li>
<li>miptree - emit messages about miptrees</li>
<li>perf - emit messages about performance issues</li>
<li>perfmon - emit messages about AMD_performance_monitor</li>
<li>bat - emit batch information</li>
<li>pix - emit messages about pixel operations</li>
<li>buf - emit messages about buffer objects</li>
<li>reg - emit messages about regions</li>
<li>fbo - emit messages about framebuffers</li>
<li>fs - dump shader assembly for fragment shaders</li>
<li>gs - dump shader assembly for geometry shaders</li>
<li>sync - emit messages about synchronization</li>
<li>prim - emit messages about drawing primitives</li>
<li>vert - emit messages about vertex assembly</li>
<li>dri - emit messages about the DRI interface</li>
<li>sf - emit messages about the strips &amp; fans unit (for old gens, includes the SF program)</li>
<li>stats - enable statistics counters. you probably actually want perfmon or intel_gpu_top instead.</li>
<li>urb - emit messages about URB setup</li>
<li>vs - dump shader assembly for vertex shaders</li>
<li>clip - emit messages about the clip unit (for old gens, includes the CLIP program)</li>
<li>aub - dump batches into an AUB trace for use with simulation tools</li>
<li>shader_time - record how much GPU time is spent in each shader</li>
<li>no16 - suppress generation of 16-wide fragment shaders. useful for debugging broken shaders</li>
<li>blorp - emit messages about the blorp operations (blits &amp; clears)</li>
<li>nodualobj - suppress generation of dual-object geometry shader code</li>
</ul>
</ul>
<h2>Radeon driver environment variables (radeon, r200, and r300g)</h2>
<ul>
<li>RADEON_NO_TCL - if set, disable hardware-accelerated Transform/Clip/Lighting.
</ul>
<h2>EGL environment variables</h2>
<p>
Mesa EGL supports different sets of environment variables. See the
<a href="egl.html">Mesa EGL</a> page for the details.
</p>
<h2>Gallium environment variables</h2>
<ul>
<li>GALLIUM_HUD - draws various information on the screen, like framerate,
cpu load, driver statistics, performance counters, etc.
Set GALLIUM_HUD=help and run e.g. glxgears for more info.
<li>GALLIUM_LOG_FILE - specifies a file for logging all errors, warnings, etc.
rather than stderr.
<li>GALLIUM_PRINT_OPTIONS - if non-zero, print all the Gallium environment
variables which are used, and their current values.
<li>GALLIUM_DUMP_CPU - if non-zero, print information about the CPU on start-up
<li>TGSI_PRINT_SANITY - if set, do extra sanity checking on TGSI shaders and
print any errors to stderr.
<LI>DRAW_FSE - ???
<LI>DRAW_NO_FSE - ???
<li>DRAW_USE_LLVM - if set to zero, the draw module will not use LLVM to execute
shaders, vertex fetch, etc.
<li>ST_DEBUG - controls debug output from the Mesa/Gallium state tracker.
Setting to "tgsi", for example, will print all the TGSI shaders.
See src/mesa/state_tracker/st_debug.c for other options.
</ul>
<h3>Softpipe driver environment variables</h3>
<ul>
<li>SOFTPIPE_DUMP_FS - if set, the softpipe driver will print fragment shaders
to stderr
<li>SOFTPIPE_DUMP_GS - if set, the softpipe driver will print geometry shaders
to stderr
<li>SOFTPIPE_NO_RAST - if set, rasterization is no-op'd. For profiling purposes.
<li>SOFTPIPE_USE_LLVM - if set, the softpipe driver will try to use LLVM JIT for
vertex shading processing.
</ul>
<h3>LLVMpipe driver environment variables</h3>
<ul>
<li>LP_NO_RAST - if set LLVMpipe will no-op rasterization
<li>LP_DEBUG - a comma-separated list of debug options is accepted. See the
source code for details.
<li>LP_PERF - a comma-separated list of options to selectively no-op various
parts of the driver. See the source code for details.
<li>LP_NUM_THREADS - an integer indicating how many threads to use for rendering.
Zero turns of threading completely. The default value is the number of CPU
cores present.
</ul>
<h3>VMware SVGA driver environment variables</h3>
<ul>
<li>SVGA_FORCE_SWTNL - force use of software vertex transformation
<li>SVGA_NO_SWTNL - don't allow software vertex transformation fallbacks
(will often result in incorrect rendering).
<li>SVGA_DEBUG - for dumping shaders, constant buffers, etc. See the code
for details.
<li>See the driver code for other, lesser-used variables.
</ul>
<p>
Other Gallium drivers have their own environment variables. These may change
frequently so the source code should be consulted for details.
</p>
</div>
</body>
</html>

View File

@@ -1,51 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Mesa Extensions</title>
<link rel="stylesheet" type="text/css" href="mesa.css">
</head>
<body>
<div class="header">
<h1>The Mesa 3D Graphics Library</h1>
</div>
<iframe src="contents.html"></iframe>
<div class="content">
<h1>Mesa Extensions</h1>
<p>
A number of extensions have been developed especially for Mesa.
The specifications follow.
</p>
<ul>
<li><a href="specs/MESA_agp_offset.spec">MESA_agp_offset.spec</a>
<li><a href="specs/MESA_copy_sub_buffer.spec">MESA_copy_sub_buffer.spec</a>
<li><a href="specs/MESA_drm_image.spec">MESA_drm_image.spec</a>
<li><a href="specs/MESA_multithread_makecurrent.spec">MESA_multithread_makecurrent.spec</a>
<li><a href="specs/OLD/MESA_packed_depth_stencil.spec">MESA_packed_depth_stencil.spec</a> (obsolete)
<li><a href="specs/MESA_pack_invert.spec">MESA_pack_invert.spec</a>
<li><a href="specs/MESA_pixmap_colormap.spec">MESA_pixmap_colormap.spec</a>
<li><a href="specs/OLD/MESA_program_debug.spec">MESA_program_debug.spec</a> (obsolete)
<li><a href="specs/MESA_release_buffers.spec">MESA_release_buffers.spec</a>
<li><a href="specs/OLD/MESA_resize_buffers.spec">MESA_resize_buffers.spec</a> (obsolete)
<li><a href="specs/MESA_set_3dfx_mode.spec">MESA_set_3dfx_mode.spec</a>
<li><a href="specs/MESA_shader_debug.spec">MESA_shader_debug.spec</a>
<li><a href="specs/OLD/MESA_sprite_point.spec">MESA_sprite_point.spec</a> (obsolete)
<li><a href="specs/MESA_swap_control.spec">MESA_swap_control.spec</a>
<li><a href="specs/MESA_swap_frame_usage.spec">MESA_swap_frame_usage.spec</a>
<li><a href="specs/MESA_texture_array.spec">MESA_texture_array.spec</a>
<li><a href="specs/MESA_texture_signed_rgba.spec">MESA_texture_signed_rgba.spec</a>
<li><a href="specs/OLD/MESA_trace.spec">MESA_trace.spec</a> (obsolete)
<li><a href="specs/MESA_window_pos.spec">MESA_window_pos.spec</a>
<li><a href="specs/MESA_ycbcr_texture.spec">MESA_ycbcr_texture.spec</a>
<li><a href="specs/WL_bind_wayland_display.spec">WL_bind_wayland_display.spec</a>
</ul>
</div>
</body>
</html>

View File

@@ -1,392 +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 FAQ</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">
<center>
<h1>Mesa Frequently Asked Questions</h1>
Last updated: 9 October 2012
</center>
<br>
<br>
<h2>Index</h2>
<a href="#part1">1. High-level Questions and Answers</a>
<br>
<a href="#part2">2. Compilation and Installation Problems</a>
<br>
<a href="#part3">3. Runtime / Rendering Problems</a>
<br>
<a href="#part4">4. Developer Questions</a>
<br>
<br>
<br>
<h1 id="part1">1. High-level Questions and Answers</h1>
<h2>1.1 What is Mesa?</h2>
<p>
Mesa is an open-source implementation of the OpenGL specification.
OpenGL is a programming library for writing interactive 3D applications.
See the <a href="http://www.opengl.org/">OpenGL website</a> for more
information.
</p>
<p>
Mesa 9.x supports the OpenGL 3.1 specification.
</p>
<h2>1.2 Does Mesa support/use graphics hardware?</h2>
<p>
Yes. Specifically, Mesa serves as the OpenGL core for the open-source DRI
drivers for X.org.
</p>
<ul>
<li>See the <a href="http://dri.freedesktop.org/">DRI website</a>
for more information.</li>
<li>See <a href="http://intellinuxgraphics.org">intellinuxgraphics.org</a>
for more information about Intel drivers.</li>
<li>See <a href="http://nouveau.freedesktop.org">nouveau.freedesktop.org</a>
for more information about Nouveau drivers.</li>
<li>See <a href="http://www.x.org/wiki/RadeonFeature">www.x.org/wiki/RadeonFeature</a>
for more information about Radeon drivers.</li>
</ul>
<h2>1.3 What purpose does Mesa serve today?</h2>
<p>
Hardware-accelerated OpenGL implementations are available for most popular
operating systems today.
Still, Mesa serves at least these purposes:
</p>
<ul>
<li>Mesa is used as the core of the open-source X.org DRI
hardware drivers.
</li>
<li>Mesa is quite portable and allows OpenGL to be used on systems
that have no other OpenGL solution.
</li>
<li>Software rendering with Mesa serves as a reference for validating the
hardware drivers.
</li>
<li>A software implementation of OpenGL is useful for experimentation,
such as testing new rendering techniques.
</li>
<li>Mesa can render images with deep color channels: 16-bit integer
and 32-bit floating point color channels are supported.
This capability is only now appearing in hardware.
</li>
<li>Mesa's internal limits (max lights, clip planes, texture size, etc) can be
changed for special needs (hardware limits are hard to overcome).
</li>
</ul>
<h2>1.4 What's the difference between "Stand-Alone" Mesa and the DRI drivers?</h2>
<p>
<em>Stand-alone Mesa</em> is the original incarnation of Mesa.
On systems running the X Window System it does all its rendering through
the Xlib API:
</p>
<ul>
<li>The GLX API is supported, but it's really just an emulation of the
real thing.
<li>The GLX wire protocol is not supported and there's no OpenGL extension
loaded by the X server.
<li>There is no hardware acceleration.
<li>The OpenGL library, libGL.so, contains everything (the programming API,
the GLX functions and all the rendering code).
</ul>
<p>
Alternately, Mesa acts as the core for a number of OpenGL hardware drivers
within the DRI (Direct Rendering Infrastructure):
<ul>
<li>The libGL.so library provides the GL and GLX API functions, a GLX
protocol encoder, and a device driver loader.
<li>The device driver modules (such as r200_dri.so) contain a built-in
copy of the core Mesa code.
<li>The X server loads the GLX module.
The GLX module decodes incoming GLX protocol and dispatches the commands
to a rendering module.
For the DRI, this module is basically a software Mesa renderer.
</ul>
<h2>1.5 How do I upgrade my DRI installation to use a new Mesa release?</h2>
<p>
This wasn't easy in the past.
Now, the DRI drivers are included in the Mesa tree and can be compiled
separately from the X server.
Just follow the Mesa <a href="install.html">compilation instructions</a>.
</p>
<h2>1.6 Are there other open-source implementations of OpenGL?</h2>
<p>
Yes, SGI's <a href="http://oss.sgi.com/projects/ogl-sample/index.html">
OpenGL Sample Implementation (SI)</a> is available.
The SI was written during the time that OpenGL was originally designed.
Unfortunately, development of the SI has stagnated.
Mesa is much more up to date with modern features and extensions.
</p>
<p>
<a href="http://sourceforge.net/projects/ogl-es/">Vincent</a> is
an open-source implementation of OpenGL ES for mobile devices.
<p>
<a href="http://www.dsbox.com/minigl.html">miniGL</a>
is a subset of OpenGL for PalmOS devices.
<p>
<a href="http://bellard.org/TinyGL/">TinyGL</a>
is a subset of OpenGL.
</p>
<p>
<a href="http://sourceforge.net/projects/softgl/">SoftGL</a>
is an OpenGL subset for mobile devices.
</p>
<p>
<a href="http://chromium.sourceforge.net/">Chromium</a>
isn't a conventional OpenGL implementation (it's layered upon OpenGL),
but it does export the OpenGL API. It allows tiled rendering, sort-last
rendering, etc.
</p>
<p>
<a href="http://www.ticalc.org/archives/files/fileinfo/361/36173.html">ClosedGL</a>
is an OpenGL subset library for TI graphing calculators.
</p>
<p>
There may be other open OpenGL implementations, but Mesa is the most
popular and feature-complete.
</p>
<br>
<br>
<h1 id="part2">2. Compilation and Installation Problems</h1>
<h2>2.1 What's the easiest way to install Mesa?</h2>
<p>
If you're using a Linux-based system, your distro CD most likely already
has Mesa packages (like RPM or DEB) which you can easily install.
</p>
<h2>2.2 I get undefined symbols such as bgnpolygon, v3f, etc...</h2>
<p>
You're application is written in IRIS GL, not OpenGL.
IRIS GL was the predecessor to OpenGL and is a different thing (almost)
entirely.
Mesa's not the solution.
</p>
<h2>2.3 Where is the GLUT library?</h2>
<p>
GLUT (OpenGL Utility Toolkit) is no longer in the separate MesaGLUT-x.y.z.tar.gz file.
If you don't already have GLUT installed, you should grab
<a href="http://freeglut.sourceforge.net/">freeglut</a>.
</p>
<h2>2.4 Where is the GLw library?</h2>
<p>
GLw (OpenGL widget library) is now available from a separate <a href="http://cgit.freedesktop.org/mesa/glw/">git repository</a>. Unless you're using very old Xt/Motif applications with OpenGL, you shouldn't need it.
</p>
<h2>2.5 What's the proper place for the libraries and headers?</h2>
<p>
On Linux-based systems you'll want to follow the
<a href="http://oss.sgi.com/projects/ogl-sample/ABI/index.html">Linux ABI</a> standard.
Basically you'll want the following:
</p>
<ul>
<li>/usr/include/GL/gl.h - the main OpenGL header
</li><li>/usr/include/GL/glu.h - the OpenGL GLU (utility) header
</li><li>/usr/include/GL/glx.h - the OpenGL GLX header
</li><li>/usr/include/GL/glext.h - the OpenGL extensions header
</li><li>/usr/include/GL/glxext.h - the OpenGL GLX extensions header
</li><li>/usr/include/GL/osmesa.h - the Mesa off-screen rendering header
</li><li>/usr/lib/libGL.so - a symlink to libGL.so.1
</li><li>/usr/lib/libGL.so.1 - a symlink to libGL.so.1.xyz
</li><li>/usr/lib/libGL.so.xyz - the actual OpenGL/Mesa library. xyz denotes the
Mesa version number.
</li></ul>
<p>
When configuring Mesa, there are three autoconf options that affect the install
location that you should take care with: <code>--prefix</code>,
<code>--libdir</code>, and <code>--with-dri-driverdir</code>. To install Mesa
into the system location where it will be available for all programs to use, set
<code>--prefix=/usr</code>. Set <code>--libdir</code> to where your Linux
distribution installs system libraries, usually either <code>/usr/lib</code> or
<code>/usr/lib64</code>. Set <code>--with-dri-driverdir</code> to the directory
where your Linux distribution installs DRI drivers. To find your system's DRI
driver directory, try executing <code>find /usr -type d -name dri</code>. For
example, if the <code>find</code> command listed <code>/usr/lib64/dri</code>,
then set <code>--with-dri-driverdir=/usr/lib64/dri</code>.
</p>
<p>
After determining the correct values for the install location, configure Mesa
with <code>./configure --prefix=/usr --libdir=xxx --with-dri-driverdir=xxx</code>
and then install with <code>sudo make install</code>.
</p>
<br>
<br>
<h1 id="part3">3. Runtime / Rendering Problems</h1>
<h2>3.1 Rendering is slow / why isn't my graphics hardware being used?</h2>
<p>
If Mesa can't use its hardware accelerated drivers it falls back on one of its software renderers.
(eg. classic swrast, softpipe or llvmpipe)
</p>
<p>
You can run the <code>glxinfo</code> program to learn about your OpenGL
library.
Look for the <code>OpenGL vendor</code> and <code>OpenGL renderer</code> values.
That will identify who's OpenGL library with which driver you're using and what sort of
hardware it has detected.
</p>
<p>
If you're using a hardware accelerated driver you want <code>direct rendering: Yes</code>.
</p>
<p>
If your DRI-based driver isn't working, go to the
<a href="http://dri.freedesktop.org/">DRI website</a> for trouble-shooting information.
</p>
<h2>3.2 I'm seeing errors in depth (Z) buffering. Why?</h2>
<p>
Make sure the ratio of the far to near clipping planes isn't too great.
Look
<a href="http://www.opengl.org/resources/faq/technical/depthbuffer.htm#0040">here</a>
for details.
</p>
<p>
Mesa uses a 16-bit depth buffer by default which is smaller and faster
to clear than a 32-bit buffer but not as accurate.
If you need a deeper you can modify the parameters to
<code> glXChooseVisual</code> in your code.
</p>
<h2>3.3 Why Isn't depth buffering working at all?</h2>
<p>
Be sure you're requesting a depth buffered-visual. If you set the MESA_DEBUG
environment variable it will warn you about trying to enable depth testing
when you don't have a depth buffer.
</p>
<p>Specifically, make sure <code>glutInitDisplayMode</code> is being called
with <code>GLUT_DEPTH</code> or <code>glXChooseVisual</code> is being
called with a non-zero value for GLX_DEPTH_SIZE.
</p>
<p>This discussion applies to stencil buffers, accumulation buffers and
alpha channels too.
</p>
<h2>3.4 Why does glGetString() always return NULL?</h2>
<p>
Be sure you have an active/current OpenGL rendering context before
calling glGetString.
</p>
<h2>3.5 GL_POINTS and GL_LINES don't touch the right pixels</h2>
<p>
If you're trying to draw a filled region by using GL_POINTS or GL_LINES
and seeing holes or gaps it's because of a float-to-int rounding problem.
But this is not a bug.
See Appendix H of the OpenGL Programming Guide - "OpenGL Correctness Tips".
Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates
will fix the problem.
</p>
<br>
<br>
<h1 id="part4">4. Developer Questions</h1>
<h2>4.1 How can I contribute?</h2>
<p>
First, join the <a href="lists.html">mesa-dev mailing list</a>.
That's where Mesa development is discussed.
</p>
<p>
The <a href="http://www.opengl.org/documentation">
OpenGL Specification</a> is the bible for OpenGL implementation work.
You should read it.
</p>
<p>Most of the Mesa development work involves implementing new OpenGL
extensions, writing hardware drivers (for the DRI), and code optimization.
</p>
<h2>4.2 How do I write a new device driver?</h2>
<p>
Unfortunately, writing a device driver isn't easy.
It requires detailed understanding of OpenGL, the Mesa code, and your
target hardware/operating system.
3D graphics are not simple.
</p>
<p>
The best way to get started is to use an existing driver as your starting
point.
For a classic hardware driver, the i965 driver is a good example.
For a Gallium3D hardware driver, the r300g, r600g and the i915g are good examples.
</p>
<p>The DRI website has more information about writing hardware drivers.
The process isn't well document because the Mesa driver interface changes
over time, and we seldom have spare time for writing documentation.
That being said, many people have managed to figure out the process.
</p>
<p>
Joining the appropriate mailing lists and asking questions (and searching
the archives) is a good way to get information.
</p>
<h2>4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?</h2>
<p>
The <a href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt">specification for the extension</a>
indicates that there are intellectual property (IP) and/or patent issues
to be dealt with.
</p>
<p>We've been unsuccessful in getting a response from S3 (or whoever owns
the IP nowadays) to indicate whether or not an open source project can
implement the extension (specifically the compression/decompression
algorithms).
</p>
<p>
In the mean time, a 3rd party <a href="http://dri.freedesktop.org/wiki/S3TC">
plug-in library</a> is available.
</p>
</div>
</body>
</html>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.4 KiB

View File

@@ -1,105 +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>Help Wanted</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>Help Wanted / To-Do List</h1>
<p>
We can always use more help with the Mesa project.
Here are some specific ideas and areas where help would be appreciated:
</p>
<ol>
<li>
<b>Driver patching and testing.</b>
Patches are often posted to the <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">mesa-dev mailing list</a>, but aren't
immediately checked into git because not enough people are testing them.
Just applying patches, testing and reporting back is helpful.
<li>
<b>Driver debugging.</b>
There are plenty of open bugs in the <a href="https://bugs.freedesktop.org/describecomponents.cgi?product=Mesa">bug database</a>.
<li>
<b>Remove aliasing warnings.</b>
Enable gcc -Wstrict-aliasing=2 -fstrict-aliasing and track down aliasing
issues in the code.
<li>
<b>Windows driver building, testing and maintenance.</b>
Fixing MSVC builds.
<li>
<b>Contribute more tests to
<a href="http://piglit.freedesktop.org/">Piglit</a>.</b>
<li>
<b>Automatic testing.
</b>
It would be great if someone would set up an automated system for grabbing
the latest Mesa code and run tests (such as piglit) then report issues to
the mailing list.
</ol>
<p>
You can find some further To-do lists here:
</p>
<p>
<b>Common To-Do lists:</b>
</p>
<ul>
<li><a href="http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt">
<b>GL3.txt</b></a> - Status of OpenGL 3.x / 4.x features in Mesa.</li>
<li><a href="http://dri.freedesktop.org/wiki/MissingFunctionality">
<b>MissingFunctionality</b></a> - Detailed information about missing OpenGL features.</li>
</ul>
<p>
<b>Driver specific To-Do lists:</b>
</p>
<ul>
<li><a href="http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/docs/llvm-todo.txt">
<b>LLVMpipe</b></a> - Software driver using LLVM for runtime code generation.</li>
<li><a href="http://dri.freedesktop.org/wiki/RadeonsiToDo">
<b>radeonsi</b></a> - Driver for AMD Southern Island.</li>
<li><a href="http://dri.freedesktop.org/wiki/R600ToDo">
<b>r600g</b></a> - Driver for ATI/AMD R600 - Northern Island.</li>
<li><a href="http://dri.freedesktop.org/wiki/R300ToDo">
<b>r300g</b></a> - Driver for ATI R300 - R500.</li>
<li><a href="http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/i915/TODO">
<b>i915g</b></a> - Driver for Intel i915/i945.</li>
</ul>
<p>
If you want to do something new in Mesa, first join the Mesa developer's
mailing list.
Then post a message to propose what you want to do, just to make sure
there's no issues.
</p>
<p>
Anyone is welcome to contribute code to the Mesa project.
By doing so, it's assumed that you agree to the code's licensing terms.
</p>
<p>
Finally:
</p>
<ol>
<li>Try to write high-quality code that follows the existing style.
<li>Use uniform indentation, write comments, use meaningful identifiers, etc.
<li>Test your code thoroughly. Include test programs if appropriate.
</ol>
</div>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@@ -1,219 +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>Compiling and Installing</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>Compiling and Installing</h1>
<ol>
<li><a href="#prereq-general">Prerequisites for building</a>
<ul>
<li><a href="#prereq-general">General prerequisites</a>
<li><a href="#prereq-dri">For DRI and hardware acceleration</a>
</ul>
<li><a href="#autoconf">Building with autoconf (Linux/Unix/X11)</a>
<li><a href="#scons">Building with SCons (Windows/Linux)</a>
<li><a href="#other">Building for other systems</a>
<li><a href="#libs">Library Information</a>
<li><a href="#pkg-config">Building OpenGL programs with pkg-config</a>
</ol>
<h1 id="prereq-general">1. Prerequisites for building</h1>
<h2>1.1 General</h2>
<ul>
<li><a href="http://www.python.org/">Python</a> - Python is required.
Version 2.6.4 or later should work.
</li>
<br>
<li><a href="http://www.makotemplates.org/">Python Mako module</a> -
Python Mako module is required. Version 0.7.3 or later should work.
</li>
</br>
<li><a href="http://www.scons.org/">SCons</a> is required for building on
Windows and optional for Linux (it's an alternative to autoconf/automake.)
</li>
<br>
<li>lex / yacc - for building the GLSL compiler.
<br>
<br>
On Linux systems, flex and bison are used.
Versions 2.5.35 and 2.4.1, respectively, (or later) should work.
<br>
<br>
On Windows with MinGW, install flex and bison with:
<pre>mingw-get install msys-flex msys-bison</pre>
For MSVC on Windows, install
<a href="http://winflexbison.sourceforge.net/">Win flex-bison</a>.
</li>
</ul>
<h3 id="prereq-dri">1.2 For DRI and hardware acceleration</h3>
<p>
The following are required for DRI-based hardware acceleration with Mesa:
</p>
<ul>
<li><a href="http://xorg.freedesktop.org/releases/individual/proto/">
dri2proto</a> version 2.6 or later
<li><a href="http://dri.freedesktop.org/libdrm/">libDRM</a>
version 2.4.33 or later
<li>Xorg server version 1.5 or later
<li>Linux 2.6.28 or later
</ul>
<p>
If you're using a fedora distro the following command should install all
the needed dependencies:
</p>
<pre>
sudo yum install flex bison imake libtool xorg-x11-proto-devel libdrm-devel \
gcc-c++ xorg-x11-server-devel libXi-devel libXmu-devel libXdamage-devel git \
expat-devel llvm-devel python-mako
</pre>
<h1 id="autoconf">2. Building with autoconf (Linux/Unix/X11)</h1>
<p>
The primary method to build Mesa on Unix systems is with autoconf.
</p>
<p>
The general approach is the standard:
</p>
<pre>
./configure
make
sudo make install
</pre>
<p>
But please read the <a href="autoconf.html">detailed autoconf instructions</a>
for more details.
</p>
<h1 id="scons">3. Building with SCons (Windows/Linux)</h1>
<p>
To build Mesa with SCons on Linux or Windows do
</p>
<pre>
scons
</pre>
<p>
The build output will be placed in
build/<i>platform</i>-<i>machine</i>-<i>debug</i>/..., where <i>platform</i> is for
example linux or windows, <i>machine</i> is x86 or x86_64, optionally followed
by -debug for debug builds.
</p>
<p>
To build Mesa with SCons for Windows on Linux using the MinGW crosscompiler toolchain do
</p>
<pre>
scons platform=windows toolchain=crossmingw machine=x86 libgl-gdi
</pre>
<p>
This will create:
</p>
<ul>
<li>build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll &mdash; Mesa + Gallium + softpipe (or llvmpipe), binary compatible with Windows's opengl32.dll
</ul>
<p>
Put them all in the same directory to test them.
</p>
<h1 id="other">4. Building for other systems</h1>
<p>
Documentation for other environments (some may be very out of date):
</p>
<ul>
<li><a href="README.VMS">README.VMS</a> - VMS
<li><a href="README.CYGWIN">README.CYGWIN</a> - Cygwin
<li><a href="README.WIN32">README.WIN32</a> - Win32
</ul>
<h1 id="libs">5. Library Information</h1>
<p>
When compilation has finished, look in the top-level <code>lib/</code>
(or <code>lib64/</code>) directory.
You'll see a set of library files similar to this:
</p>
<pre>
lrwxrwxrwx 1 brian users 10 Mar 26 07:53 libGL.so -> libGL.so.1*
lrwxrwxrwx 1 brian users 19 Mar 26 07:53 libGL.so.1 -> libGL.so.1.5.060100*
-rwxr-xr-x 1 brian users 3375861 Mar 26 07:53 libGL.so.1.5.060100*
lrwxrwxrwx 1 brian users 14 Mar 26 07:53 libOSMesa.so -> libOSMesa.so.6*
lrwxrwxrwx 1 brian users 23 Mar 26 07:53 libOSMesa.so.6 -> libOSMesa.so.6.1.060100*
-rwxr-xr-x 1 brian users 23871 Mar 26 07:53 libOSMesa.so.6.1.060100*
</pre>
<p>
<b>libGL</b> is the main OpenGL library (i.e. Mesa).
<br>
<b>libOSMesa</b> is the OSMesa (Off-Screen) interface library.
</p>
<p>
If you built the DRI hardware drivers, you'll also see the DRI drivers:
</p>
<pre>
-rwxr-xr-x 1 brian users 16895413 Jul 21 12:11 i915_dri.so
-rwxr-xr-x 1 brian users 16895413 Jul 21 12:11 i965_dri.so
-rwxr-xr-x 1 brian users 11849858 Jul 21 12:12 r200_dri.so
-rwxr-xr-x 1 brian users 11757388 Jul 21 12:12 radeon_dri.so
</pre>
<p>
If you built with Gallium support, look in lib/gallium/ for Gallium-based
versions of libGL and device drivers.
</p>
<h1 id="pkg-config">6. Building OpenGL programs with pkg-config</h1>
<p>
Running <code>make install</code> will install package configuration files
for the pkg-config utility.
</p>
<p>
When compiling your OpenGL application you can use pkg-config to determine
the proper compiler and linker flags.
</p>
<p>
For example, compiling and linking a GLUT application can be done with:
</p>
<pre>
gcc `pkg-config --cflags --libs glut` mydemo.c -o mydemo
</pre>
<br>
</div>
</body>
</html>

View File

@@ -1,355 +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 Introduction</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>Introduction</h1>
<p>
Mesa is an open-source implementation of the
<a href="http://www.opengl.org/">OpenGL</a> specification -
a system for rendering interactive 3D graphics.
</p>
<p>
A variety of device drivers allows Mesa to be used in many different
environments ranging from software emulation to complete hardware acceleration
for modern GPUs.
</p>
<p>
Mesa ties into several other open-source projects: the
<a href="http://dri.freedesktop.org/">Direct Rendering
Infrastructure</a> and <a href="http://x.org">X.org</a> to
provide OpenGL support to users of X on Linux, FreeBSD and other operating
systems.
</p>
<h1>Project History</h1>
<p>
The Mesa project was originally started by Brian Paul.
Here's a short history of the project.
</p>
<p>
August, 1993: I begin working on Mesa in my spare time. The project
has no name at that point. I was simply interested in writing a simple
3D graphics library that used the then-new OpenGL API. I was partially
inspired by the <em>VOGL</em> library which emulated a subset of IRIS GL.
I had been programming with IRIS GL since 1991.
</p>
<p>
November 1994: I contact SGI to ask permission to distribute my OpenGL-like
graphics library on the internet. SGI was generally receptive to the
idea and after negotiations with SGI's legal department, I get permission
to release it.
</p>
<p>
February 1995: Mesa 1.0 is released on the internet. I expected that
a few people would be interested in it, but not thousands.
I was soon receiving patches, new features and thank-you notes on a
daily basis. That encouraged me to continue working on Mesa. The
name Mesa just popped into my head one day. SGI had asked me not to use
the terms <em>"Open"</em> or <em>"GL"</em> in the project name and I didn't
want to make up a new acronym. Later, I heard of the Mesa programming
language and the Mesa spreadsheet for NeXTStep.
</p>
<p>
In the early days, OpenGL wasn't available on too many systems.
It even took a while for SGI to support it across their product line.
Mesa filled a big hole during that time.
For a lot of people, Mesa was their first introduction to OpenGL.
I think SGI recognized that Mesa actually helped to promote
the OpenGL API, so they didn't feel threatened by the project.
</p>
<p>
1995-1996: I continue working on Mesa both during my spare time and during
my work hours at the Space Science and Engineering Center at the University
of Wisconsin in Madison. My supervisor, Bill Hibbard, lets me do this because
Mesa is now being using for the <a href="http://www.ssec.wisc.edu/%7Ebillh/vis.html">Vis5D</a> project.
</p><p>
October 1996: Mesa 2.0 is released. It implements the OpenGL 1.1 specification.
</p>
<p>
March 1997: Mesa 2.2 is released. It supports the new 3dfx Voodoo graphics
card via the Glide library. It's the first really popular hardware OpenGL
implementation for Linux.
</p>
<p>
September 1998: Mesa 3.0 is released. It's the first publicly-available
implementation of the OpenGL 1.2 API.
</p>
<p>
March 1999: I attend my first OpenGL ARB meeting. I contribute to the
development of several official OpenGL extensions over the years.
</p>
<p>
September 1999: I'm hired by Precision Insight, Inc. Mesa is a key
component of 3D hardware acceleration in the new DRI project for XFree86.
Drivers for 3dfx, 3dLabs, Intel, Matrox and ATI hardware soon follow.
</p>
<p>
October 2001: Mesa 4.0 is released.
It implements the OpenGL 1.3 specification.
</p>
<p>
November 2001: I cofounded Tungsten Graphics, Inc. with Keith Whitwell,
Jens Owen, David Dawes and Frank LaMonica.
Tungsten Graphics was acquired by VMware in December 2008.
</p>
<p>
November 2002: Mesa 5.0 is released.
It implements the OpenGL 1.4 specification.
</p>
<p>
January 2003: Mesa 6.0 is released. It implements the OpenGL 1.5
specification as well as the GL_ARB_vertex_program and
GL_ARB_fragment_program extensions.
</p>
<p>
June 2007: Mesa 7.0 is released, implementing the OpenGL 2.1 specification
and OpenGL Shading Language.
</p>
<p>
2008: Keith Whitwell and other Tungsten Graphics employees develop
<a href="http://en.wikipedia.org/wiki/Gallium3D">Gallium</a>
- a new GPU abstraction layer. The latest Mesa drivers are based on
Gallium and other APIs such as OpenVG are implemented on top of Gallium.
</p>
<p>
February 2012: Mesa 8.0 is released, implementing the OpenGL 3.0 specification
and version 1.30 of the OpenGL Shading Language.
</p>
<p>
Ongoing: Mesa is the OpenGL implementation for several types of hardware
made by Intel, AMD and NVIDIA, plus the VMware virtual GPU.
There's also several software-based renderers: swrast (the legacy
Mesa rasterizer), softpipe (a gallium reference driver) and llvmpipe
(LLVM/JIT-based high-speed rasterizer).
Work continues on the drivers and core Mesa to implement newer versions
of the OpenGL specification.
</p>
<h1>Major Versions</h1>
<p>
This is a summary of the major versions of Mesa.
Mesa's major version number has been incremented whenever a new version
of the OpenGL specification is implemented.
</p>
<h2>Version 9.x features</h2>
<p>
Version 9.x of Mesa implements the OpenGL 3.1 API.
While the driver for Intel Sandy Bridge and Ivy Bridge is the only
driver to support OpenGL 3.1, many developers across the open-source
community contributed features required for OpenGL 3.1. The primary
features added since the Mesa 8.0 release are
GL_ARB_texture_buffer_object and GL_ARB_uniform_buffer_object.
</p>
<h2>Version 8.x features</h2>
<p>
Version 8.x of Mesa implements the OpenGL 3.0 API.
The developers at Intel deserve a lot of credit for implementing most
of the OpenGL 3.0 features in core Mesa, the GLSL compiler as well as
the i965 driver.
</p>
<h2>Version 7.x features</h2>
<p>
Version 7.x of Mesa implements the OpenGL 2.1 API. The main feature
of OpenGL 2.x is the OpenGL Shading Language.
</p>
<h2>Version 6.x features</h2>
<p>
Version 6.x of Mesa implements the OpenGL 1.5 API with the following
extensions incorporated as standard features:
</p>
<ul>
<li>GL_ARB_occlusion_query
<li>GL_ARB_vertex_buffer_object
<li>GL_EXT_shadow_funcs
</ul>
<p>
Also note that several OpenGL tokens were renamed in OpenGL 1.5
for the sake of consistency.
The old tokens are still available.
</p>
<pre>
New Token Old Token
------------------------------------------------------------
GL_FOG_COORD_SRC GL_FOG_COORDINATE_SOURCE
GL_FOG_COORD GL_FOG_COORDINATE
GL_CURRENT_FOG_COORD GL_CURRENT_FOG_COORDINATE
GL_FOG_COORD_ARRAY_TYPE GL_FOG_COORDINATE_ARRAY_TYPE
GL_FOG_COORD_ARRAY_STRIDE GL_FOG_COORDINATE_ARRAY_STRIDE
GL_FOG_COORD_ARRAY_POINTER GL_FOG_COORDINATE_ARRAY_POINTER
GL_FOG_COORD_ARRAY GL_FOG_COORDINATE_ARRAY
GL_SRC0_RGB GL_SOURCE0_RGB
GL_SRC1_RGB GL_SOURCE1_RGB
GL_SRC2_RGB GL_SOURCE2_RGB
GL_SRC0_ALPHA GL_SOURCE0_ALPHA
GL_SRC1_ALPHA GL_SOURCE1_ALPHA
GL_SRC2_ALPHA GL_SOURCE2_ALPHA
</pre>
<p>
See the
<a href="http://www.opengl.org/documentation/spec.html">
OpenGL specification</a> for more details.
</p>
<h2>Version 5.x features</h2>
<p>
Version 5.x of Mesa implements the OpenGL 1.4 API with the following
extensions incorporated as standard features:
</p>
<ul>
<li>GL_ARB_depth_texture
<li>GL_ARB_shadow
<li>GL_ARB_texture_env_crossbar
<li>GL_ARB_texture_mirror_repeat
<li>GL_ARB_window_pos
<li>GL_EXT_blend_color
<li>GL_EXT_blend_func_separate
<li>GL_EXT_blend_logic_op
<li>GL_EXT_blend_minmax
<li>GL_EXT_blend_subtract
<li>GL_EXT_fog_coord
<li>GL_EXT_multi_draw_arrays
<li>GL_EXT_point_parameters
<li>GL_EXT_secondary_color
<li>GL_EXT_stencil_wrap
<li>GL_EXT_texture_lod_bias (plus, a per-texture LOD bias parameter)
<li>GL_SGIS_generate_mipmap
</ul>
<h2>Version 4.x features</h2>
<p>
Version 4.x of Mesa implements the OpenGL 1.3 API with the following
extensions incorporated as standard features:
</p>
<ul>
<li>GL_ARB_multisample
<li>GL_ARB_multitexture
<li>GL_ARB_texture_border_clamp
<li>GL_ARB_texture_compression
<li>GL_ARB_texture_cube_map
<li>GL_ARB_texture_env_add
<li>GL_ARB_texture_env_combine
<li>GL_ARB_texture_env_dot3
<li>GL_ARB_transpose_matrix
</ul>
<h2>Version 3.x features</h2>
<p>
Version 3.x of Mesa implements the OpenGL 1.2 API with the following
features:
</p>
<ul>
<li>BGR, BGRA and packed pixel formats
<li>New texture border clamp mode
<li>glDrawRangeElements()
<li>standard 3-D texturing
<li>advanced MIPMAP control
<li>separate specular color interpolation
</ul>
<h2>Version 2.x features</h2>
<p>
Version 2.x of Mesa implements the OpenGL 1.1 API with the following
features.
</p>
<ul>
<li>Texture mapping:
<ul>
<li>glAreTexturesResident
<li>glBindTexture
<li>glCopyTexImage1D
<li>glCopyTexImage2D
<li>glCopyTexSubImage1D
<li>glCopyTexSubImage2D
<li>glDeleteTextures
<li>glGenTextures
<li>glIsTexture
<li>glPrioritizeTextures
<li>glTexSubImage1D
<li>glTexSubImage2D
</ul>
<li>Vertex Arrays:
<ul>
<li>glArrayElement
<li>glColorPointer
<li>glDrawElements
<li>glEdgeFlagPointer
<li>glIndexPointer
<li>glInterleavedArrays
<li>glNormalPointer
<li>glTexCoordPointer
<li>glVertexPointer
</ul>
<li>Client state management:
<ul>
<li>glDisableClientState
<li>glEnableClientState
<li>glPopClientAttrib
<li>glPushClientAttrib
</ul>
<li>Misc:
<ul>
<li>glGetPointer
<li>glIndexub
<li>glIndexubv
<li>glPolygonOffset
</ul>
</ul>
</div>
</body>
</html>

View File

@@ -1,197 +0,0 @@
Introduction
------------
This document describes the implementation of the XFree86 4.0 libGL.so
library defined by the Linux/OpenGL Base specification found at
http://reality.sgi.com/opengl/linux/linuxbase.html.
The documentation is divided into two sections:
User's Guide
Driver Developer's Guide
Author: Brian Paul (brian@precisioninsight.com)
Date: February 2000
User's Guide
------------
Using libGL.so
The libGL.so library defines the gl- and glX-prefixed functions needed to
run OpenGL programs. OpenGL client applications should link with the
-lGL option to use it.
libGL.so serves two primary functions: GLX protocol generation for indirect
rendering and loading/management of hardware drivers for direct rendering.
When libGL.so initializes itself it uses the DRI to determine the
appropriate hardware driver for each screen on the local X display.
The hardware drivers are expected to be in the /usr/X11R6/lib/modules/dri/
directory. Drivers are named with the convention <name>_dri.so where
<name> is a driver such as "radeon", "i965", "nouveau", etc.
The LIBGL_DRIVERS_DIR environment variable may be used to specify a
different DRI modules directory, overriding /usr/X11R6/lib/modules/dri/.
This environment variable is ignored in setuid programs for security
reasons.
When libGL.so is unable to locate appropriate hardware drivers it will
fall back to using indirect GLX rendering.
To aid in solving problems, libGL.so will print diagnostic messages to
stderr if the LIBGL_DEBUG environment variable is defined.
libGL.so is thread safe. The overhead of thread safety for common,
single-thread clients is negligible. However, the overhead of thread
safety for multi-threaded clients is significant. Each GL API call
requires two calls to pthread_get_specific() which can noticeably
impact performance. Warning: libGL.so is thread safe but individual
DRI drivers may not be. Please consult the documentation for a driver
to learn if it is thread safe.
Indirect Rendering
You can force indirect rendering mode by setting the LIBGL_ALWAYS_INDIRECT
environment variable. Hardware acceleration will not be used.
libGL.so Extensibility
libGL.so is designed to be extended without upgrading. That is,
drivers may install new OpenGL extension functions into libGL.so
without requiring libGL.so to be replaced. Clients of libGL.so should
use the glXGetProcAddressEXT() function to obtain the address of
functions by name. For more details of GLX_ARB_get_proc_address see
http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.spec
libGL.so is also designed with flexibility such that it may be used
with many generations of hardware drivers to come.
Driver Developer's Guide
------------------------
This section describes the requirements to make an XFree86 4.0
libGL.so-compatible hardware driver. It is not intended for end
users of libGL.so.
XFree86 source files
libGL.so is built inside XFree86 with sources found in xc/lib/GL/.
Specifically, libGL.so is built from:
xc/lib/GL/glx/*.c
xc/lib/dri/XF86dri.c
xc/lib/dri/dri_glx.c
xc/lib/GL/mesa/src/glapi.c
xc/lib/GL/mesa/src/glapitemp.h
xc/lib/GL/mesa/src/glapitable.h
xc/lib/GL/mesa/src/glapioffsets.h
xc/lib/GL/mesa/src/glapinoop.c
xc/lib/GL/mesa/src/glheader.h
xc/lib/GL/mesa/src/glthread.c
xc/lib/GL/mesa/src/glthread.h
xc/lib/GL/mesa/src/X86/glapi_x86.S
xc/lib/GL/mesa/src/X86/assyntax.h
Understand that the mesa/src/gl*.[ch] files are not tied to Mesa. They
have no dependencies on the rest of Mesa and are designed to be reusable
in a number of projects.
The glapi_x86.X and assyntax.h files implement x86-optimized dispatch
of GL functions. They are not required; C-based dispatch can be used
instead, with a slight performance penalty.
Driver loading and binding
When libGL.so initializes itself (via the __glXInitialize function) a
call is made to driCreateDisplay(). This function uses DRI facilities
to determine the driver file appropriate for each screen on the local
display. Each screen's driver is then opened with dlopen() and asked
for its __driCreateScreen() function. The pointers to the __driCreateScreen()
functions are kept in an array, indexed by screen number, in the
__DRIdisplayRec struct.
When a driver's __driCreateScreen() function is called, it must initialize
a __DRIscreenRec struct. This struct acts as the root of a tree of
function pointers which are called to create and destroy contexts and
drawables and perform all the operations needed by the GLX interface.
See the xc/lib/GL/glx/glxclient.h file for details.
Dynamic Extension Function Registration
In order to provide forward compatibility with future drivers, libGL.so
allows drivers to register new OpenGL extension functions which weren't
known when libGL.so was built.
The register_extensions() function in xc/lib/GL/dri/dri_glx.c is called
as soon as libGL.so is loaded. This is done with gcc's constructor
attribute. This mechanism will likely have to be changed for other compilers.
register_extensions() loops over all local displays and screens, determines
the DRI driver for each, and calls the driver's __driRegisterExtensions()
function, if present.
The __driRegisterExtensions() function can add new entrypoints to libGL
by calling:
GLboolean _glapi_add_entrypoint(const char *funcName, GLuint offset)
The parameters are the name of the function (such as "glFoobarEXT") and the
offset of the dispatch slot in the API dispatch table. The return value
indicates success (GL_TRUE) or failure (GL_FALSE).
_glapi_add_entrypoint() will synthesize entrypoint code in assembly
language. Assembly languages is required since parameter passing
can't be handled correctly using a C-based solution.
The address of the new entrypoint is obtained by calling the
glXGetProcAddressARB() function.
The dispatch offset number MUST be a number allocated by SGI in the same
manner in which new GL_* constants are allocated. Using an arbitrary
offset number will result in many problems.
Dispatch Management
When a GL context is made current, the driver must install its dispatch
table as the current dispatch table. This is done by calling
void _glapi_set_dispatch(struct _glapi_table *dispatch);
This will install the named dispatch table for the calling thread.
The current dispatch table for a thread can be obtained by calling
struct _glapi_table *_glapi_get_dispatch(void);
For higher performance in the common single-thread case, the global
variable _glapi_Dispatch will point to the current dispatch table.
This variable will be NULL when in multi-thread mode.
Context Management
libGL.so uses the XFree86 xthreads package to manage a thread-specific
current context pointer. See __glXGet/SetCurrentContext() in glext.c
Drivers may use the _glapi_set/get_context() functions to maintain
a private thread-specific context pointer.

View File

@@ -1,117 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>License / Copyright Information</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>Disclaimer</h1>
<p>
Mesa is a 3-D graphics library with an API which is very similar to
that of <a href="http://www.opengl.org/">OpenGL</a>.*
To the extent that Mesa utilizes the OpenGL command syntax or state
machine, it is being used with authorization from <a
href="http://www.sgi.com/">Silicon Graphics,
Inc.</a>(SGI). However, the author does not possess an OpenGL license
from SGI, and makes no claim that Mesa is in any way a compatible
replacement for OpenGL or associated with SGI. Those who want a
licensed implementation of OpenGL should contact a licensed
vendor.
</p>
<p>
Please do not refer to the library as <em>MesaGL</em> (for legal
reasons). It's just <em>Mesa</em> or <em>The Mesa 3-D graphics
library</em>. <br>
</p>
<p>
* OpenGL is a trademark of <a href="http://www.sgi.com/"
>Silicon Graphics Incorporated</a>.
</p>
<h1>License / Copyright Information</h1>
<p>
The Mesa distribution consists of several components. Different copyrights
and licenses apply to different components. For example, some demo programs
are copyrighted by SGI, some of the Mesa device drivers are copyrighted by
their authors. See below for a list of Mesa's main components and the license
for each.
</p>
<p>
The core Mesa library is licensed according to the terms of the MIT license.
This allows integration with the XFree86, Xorg and DRI projects.
</p>
<p>
The default Mesa license is as follows:
</p>
<pre>
Copyright (C) 1999-2007 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
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.
</pre>
<h1>Attention, Contributors</h1>
<p>
When contributing to the Mesa project you must agree to the licensing terms
of the component to which you're contributing.
The following section lists the primary components of the Mesa distribution
and their respective licenses.
</p>
<h1>Mesa Component Licenses</h1>
<pre>
Component Location License
------------------------------------------------------------------
Main Mesa code src/mesa/ Mesa (MIT)
Device drivers src/mesa/drivers/* MIT, generally
Ext headers include/GL/glext.h Khronos
include/GL/glxext.h
C11 thread include/c11/threads*.h Boost (permissive)
emulation
</pre>
<p>
In general, consult the source files for license terms.
</p>
</div>
</body>
</html>

View File

@@ -1,97 +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 Mailing Lists</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>Mailing Lists</h1>
<p>There are four Mesa 3D / DRI mailing lists:
</p>
<ul>
<li><p><a href="http://lists.freedesktop.org/mailman/listinfo/mesa-users">mesa-users</a>
- intended for end-users of Mesa and DRI drivers. Newbie questions are OK,
but please try the general OpenGL resources and Mesa/DRI documentation first.</p>
</li>
<li><p><a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev">mesa-dev</a>
- for Mesa, Gallium and DRI development
discussion. Not for beginners.</p>
</li>
<li><p><a href="http://lists.freedesktop.org/mailman/listinfo/mesa-commit">mesa-commit</a>
- relays git check-in messages (for developers).
In general, people should not post to this list.</p>
</li>
<li><p><a href="http://lists.freedesktop.org/mailman/listinfo/mesa-announce">mesa-announce</a>
- announcements of new Mesa
versions are sent to this list. Very low traffic.</p>
</li>
<li><p><a href="http://lists.freedesktop.org/mailman/listinfo/piglit">piglit</a>
- for Piglit (OpenGL driver testing framework) discussion.</p>
</li>
</ul>
<p>
<b>NOTE</b>: You <b>must</b> subscribe to these lists in order to post to them.
If you try to post to a list and you're not a subscriber (or if you try to post
from a different email address than you subscribed with) your posting will be
held for an indefinite period or may be discarded entirely.
</p>
<p>
Follow the links above for list archives.
</p>
<p>
The old Mesa lists hosted at SourceForge are no longer in use.
The archives are still available, however:
<a href="http://sourceforge.net/mailarchive/forum.php?forum_name=mesa3d-announce">mesa3d-announce</a>,
<a href="http://sourceforge.net/mailarchive/forum.php?forum_name=mesa3d-users">mesa3d-users</a>,
<a href="http://sourceforge.net/mailarchive/forum.php?forum_name=mesa3d-dev">mesa3d-dev</a>.
</p>
<p>For mailing lists about Direct Rendering Modules (drm) in Linux/BSD
kernels, see the
<a href="http://dri.freedesktop.org/wiki/MailingLists">DRI wiki</a>.
</p>
<h1>IRC</h1>
<p>join <a href="irc://chat.freenode.net#dri-devel">#dri-devel channel</a>
on <a href="http://webchat.freenode.net/">irc.freenode.net</a>
</p>
<h1>OpenGL Forums</h1>
<p>
Here are some other OpenGL-related forums you might find useful:
</p>
<ul>
<li><a href="http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi">OpenGL discussion forums</a>
at www.opengl.org</li>
<li>Usenet newsgroups:
<ul>
<li>comp.graphics.algorithms</li>
<li>comp.graphics.api.opengl</li>
<li>comp.os.linux.x</li>
</ul>
</ul>
</div>
</body>
</html>

View File

@@ -1,318 +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>llvmpipe</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>Introduction</h1>
<p>
The Gallium llvmpipe driver is a software rasterizer that uses LLVM to
do runtime code generation.
Shaders, point/line/triangle rasterization and vertex processing are
implemented with LLVM IR which is translated to x86 or x86-64 machine
code.
Also, the driver is multithreaded to take advantage of multiple CPU cores
(up to 8 at this time).
It's the fastest software rasterizer for Mesa.
</p>
<h1>Requirements</h1>
<ul>
<li>
<p>An x86 or amd64 processor; 64-bit mode recommended.</p>
<p>
Support for SSE2 is strongly encouraged. Support for SSSE3 and SSE4.1 will
yield the most efficient code. The fewer features the CPU has the more
likely is that you run into underperforming, buggy, or incomplete code.
</p>
<p>
See /proc/cpuinfo to know what your CPU supports.
</p>
</li>
<li>
<p>LLVM: version 3.4 recommended; 3.3 or later required.</p>
<p>
For Linux, on a recent Debian based distribution do:
</p>
<pre>
aptitude install llvm-dev
</pre>
<p>
For a RPM-based distribution do:
</p>
<pre>
yum install llvm-devel
</pre>
<p>
For Windows you will need to build LLVM from source with MSVC or MINGW
(either natively or through cross compilers) and CMake, and set the LLVM
environment variable to the directory you installed it to.
LLVM will be statically linked, so when building on MSVC it needs to be
built with a matching CRT as Mesa, and you'll need to pass
<code>-DLLVM_USE_CRT_xxx=yyy</code> as described below.
</p>
<table border="1">
<tr>
<th rowspan="2">LLVM build-type</th>
<th colspan="2" align="center">Mesa build-type</th>
</tr>
<tr>
<th>debug,checked</th>
<th>release,profile</th>
</tr>
<tr>
<th>Debug</th>
<td><code>-DLLVM_USE_CRT_DEBUG=MTd</code></td>
<td><code>-DLLVM_USE_CRT_DEBUG=MT</code></td>
</tr>
<tr>
<th>Release</th>
<td><code>-DLLVM_USE_CRT_RELEASE=MTd</code></td>
<td><code>-DLLVM_USE_CRT_RELEASE=MT</code></td>
</tr>
</table>
<p>
You can build only the x86 target by passing -DLLVM_TARGETS_TO_BUILD=X86
to cmake.
</p>
</li>
<li>
<p>scons (optional)</p>
</li>
</ul>
<h1>Building</h1>
To build everything on Linux invoke scons as:
<pre>
scons build=debug libgl-xlib
</pre>
Alternatively, you can build it with GNU make, if you prefer, by invoking it as
<pre>
make linux-llvm
</pre>
but the rest of these instructions assume that scons is used.
For Windows the procedure is similar except the target:
<pre>
scons platform=windows build=debug libgl-gdi
</pre>
<h1>Using</h1>
<h2>Linux</h2>
<p>On Linux, building will create a drop-in alternative for libGL.so into</p>
<pre>
build/foo/gallium/targets/libgl-xlib/libGL.so
</pre>
or
<pre>
lib/gallium/libGL.so
</pre>
<p>To use it set the LD_LIBRARY_PATH environment variable accordingly.</p>
<p>For performance evaluation pass build=release to scons, and use the corresponding
lib directory without the "-debug" suffix.</p>
<h2>Windows</h2>
<p>
On Windows, building will create
<code>build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll</code>
which is a drop-in alternative for system's <code>opengl32.dll</code>. To use
it put it in the same directory as your application. It can also be used by
replacing the native ICD driver, but it's quite an advanced usage, so if you
need to ask, don't even try it.
</p>
<p>
There is however an easy way to replace the OpenGL software renderer that comes
with Microsoft Windows 7 (or later) with llvmpipe (that is, on systems without
any OpenGL drivers):
</p>
<ul>
<li><p>copy build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll to C:\Windows\SysWOW64\mesadrv.dll</p></li>
<li><p>load this registry settings:</p>
<pre>REGEDIT4
; http://technet.microsoft.com/en-us/library/cc749368.aspx
; http://www.msfn.org/board/topic/143241-portable-windows-7-build-from-winpe-30/page-5#entry942596
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\OpenGLDrivers\MSOGL]
"DLL"="mesadrv.dll"
"DriverVersion"=dword:00000001
"Flags"=dword:00000001
"Version"=dword:00000002
</pre>
</li>
<li>Ditto for 64 bits drivers if you need them.</li>
</ul>
<h1>Profiling</h1>
<p>
To profile llvmpipe you should build as
</p>
<pre>
scons build=profile &lt;same-as-before&gt;
</pre>
<p>
This will ensure that frame pointers are used both in C and JIT functions, and
that no tail call optimizations are done by gcc.
</p>
<h2>Linux perf integration</h2>
<p>
On Linux, it is possible to have symbol resolution of JIT code with <a href="http://perf.wiki.kernel.org/">Linux perf</a>:
</p>
<pre>
perf record -g /my/application
perf report
</pre>
<p>
When run inside Linux perf, llvmpipe will create a /tmp/perf-XXXXX.map file with
symbol address table. It also dumps assembly code to /tmp/perf-XXXXX.map.asm,
which can be used by the bin/perf-annotate-jit script to produce disassembly of
the generated code annotated with the samples.
</p>
<p>You can obtain a call graph via
<a href="http://code.google.com/p/jrfonseca/wiki/Gprof2Dot#linux_perf">Gprof2Dot</a>.</p>
<h1>Unit testing</h1>
<p>
Building will also create several unit tests in
build/linux-???-debug/gallium/drivers/llvmpipe:
</p>
<ul>
<li> lp_test_blend: blending
<li> lp_test_conv: SIMD vector conversion
<li> lp_test_format: pixel unpacking/packing
</ul>
<p>
Some of this tests can output results and benchmarks to a tab-separated-file
for posterior analysis, e.g.:
</p>
<pre>
build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
</pre>
<h1>Development Notes</h1>
<ul>
<li>
When looking to this code by the first time start in lp_state_fs.c, and
then skim through the lp_bld_* functions called in there, and the comments
at the top of the lp_bld_*.c functions.
</li>
<li>
The driver-independent parts of the LLVM / Gallium code are found in
src/gallium/auxiliary/gallivm/. The filenames and function prefixes
need to be renamed from "lp_bld_" to something else though.
</li>
<li>
We use LLVM-C bindings for now. They are not documented, but follow the C++
interfaces very closely, and appear to be complete enough for code
generation. See
<a href="http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html">
this stand-alone example</a>. See the llvm-c/Core.h file for reference.
</li>
</ul>
<h1 id="recommended_reading">Recommended Reading</h1>
<ul>
<li>
<p>Rasterization</p>
<ul>
<li><a href="http://www.cs.unc.edu/~olano/papers/2dh-tri/">Triangle Scan Conversion using 2D Homogeneous Coordinates</a></li>
<li><a href="http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602">Rasterization on Larrabee</a> (<a href="http://devmaster.net/posts/2887/rasterization-on-larrabee">DevMaster copy</a>)</li>
<li><a href="http://devmaster.net/posts/6133/rasterization-using-half-space-functions">Rasterization using half-space functions</a></li>
<li><a href="http://devmaster.net/posts/6145/advanced-rasterization">Advanced Rasterization</a></li>
<li><a href="http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/">Optimizing Software Occlusion Culling</a></li>
</ul>
</li>
<li>
<p>Texture sampling</p>
<ul>
<li><a href="http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping">Perspective Texture Mapping</a></li>
<li><a href="http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml">Texturing As In Unreal</a></li>
<li><a href="http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php">Run-Time MIP-Map Filtering</a></li>
<li><a href="http://alt.3dcenter.org/artikel/2003/10-26_a_english.php">Will "brilinear" filtering persist?</a></li>
<li><a href="http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html">Trilinear filtering</a></li>
<li><a href="http://devmaster.net/posts/12785/texture-swizzling">Texture Swizzling</a></li>
</ul>
</li>
<li>
<p>SIMD</p>
<ul>
<li><a href="http://www.cdl.uni-saarland.de/projects/wfv/#header4">Whole-Function Vectorization</a></li>
</ul>
</li>
<li>
<p>Optimization</p>
<ul>
<li><a href="http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807">Optimizing Pixomatic For Modern x86 Processors</a></li>
<li><a href="http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html">Intel 64 and IA-32 Architectures Optimization Reference Manual</a></li>
<li><a href="http://www.agner.org/optimize/">Software optimization resources</a></li>
<li><a href="http://software.intel.com/en-us/articles/intel-intrinsics-guide">Intel Intrinsics Guide</a><li>
</ul>
</li>
<li>
<p>LLVM</p>
<ul>
<li><a href="http://llvm.org/docs/LangRef.html">LLVM Language Reference Manual</a></li>
<li><a href="http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html">The secret of LLVM C bindings</a></li>
</ul>
</li>
<li>
<p>General</p>
<ul>
<li><a href="http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/">A trip through the Graphics Pipeline</a></li>
<li><a href="http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture">WARP Architecture and Performance</a></li>
</ul>
</li>
</ul>
</div>
</body>
</html>

View File

@@ -1,38 +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>Function Name Mangling</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>Function Name Mangling</h1>
<p>
If you want to use both Mesa and another OpenGL library in the same
application at the same time you may find it useful to compile Mesa with
<i>name mangling</i>.
This results in all the Mesa functions being prefixed with
<b>mgl</b> instead of <b>gl</b>.
</p>
<p>
To do this, recompile Mesa with the compiler flag -DUSE_MGL_NAMESPACE.
Add the flag to CFLAGS in the configuration file which you want to use.
For example:
</p>
<pre>
CFLAGS += -DUSE_MGL_NAMESPACE
</pre>
</div>
</body>
</html>

View File

@@ -1,63 +0,0 @@
/* Mesa CSS */
body {
background-color: #ffffff;
font: 14px 'Lucida Grande', Geneva, Arial, Verdana, sans-serif;
color: black;
link: #111188;
}
h1 {
font: 24px 'Lucida Grande', Geneva, Arial, Verdana, sans-serif;
font-weight: bold;
color: black;
}
h2 {
font: 18px 'Lucida Grande', Geneva, Arial, Verdana, sans-serif, bold;
font-weight: bold;
color: black;
}
code {
font-family: monospace;
font-size: 10pt;
color: black;
}
pre {
/*font-family: monospace;*/
font-size: 10pt;
/*color: black;*/
}
iframe {
width: 19em;
height: 80em;
border: none;
float: left;
}
.content {
position: absolute;
left: 20em;
right: 10px;
overflow: hidden
}
.header {
background: black url('gears.png') 15px no-repeat;
margin:0;
padding: 5px;
clear:both;
}
.header h1 {
background: url('gears.png') right no-repeat;
color: white;
font: x-large sans-serif;
text-align: center;
height: 50px;
margin: 0;
padding-top: 30px;
}

View File

@@ -1,70 +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>OpenGL ES</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>OpenGL ES</h1>
<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More information about
OpenGL ES can be found at <a href="http://www.khronos.org/opengles/">
http://www.khronos.org/opengles/</a>.</p>
<p>OpenGL ES depends on a working EGL implementation. Please refer to
<a href="egl.html">Mesa EGL</a> for more information about EGL.</p>
<h2>Build the Libraries</h2>
<ol>
<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code> and enable the Gallium driver for your hardware.</li>
<li>Build and install Mesa as usual.</li>
</ol>
Alternatively, if XCB-DRI2 is installed on the system, one can use
<code>egl_dri2</code> EGL driver with OpenGL|ES-enabled DRI drivers
<ol>
<li>Run <code>configure</code> with <code>--enable-gles1 --enable-gles2</code>.</li>
<li>Build and install Mesa as usual.</li>
</ol>
<p>Both methods will install libGLESv1_CM, libGLESv2, libEGL, and one or more
EGL drivers for your hardware.</p>
<h2>Run the Demos</h2>
<p>There are some demos in <code>mesa/demos</code> repository.</p>
<h2>Developers</h2>
<h3>Dispatch Table</h3>
<p>OpenGL ES has an additional indirection when dispatching functions</p>
<pre>
Mesa: glFoo() --&gt; _mesa_Foo()
OpenGL ES: glFoo() --&gt; _es_Foo() --&gt; _mesa_Foo()
</pre>
<p>The indirection serves several purposes</p>
<ul>
<li>When a function is in Mesa and the type matches, it checks the arguments and calls the Mesa function.</li>
<li>When a function is in Mesa but the type mismatches, it checks and converts the arguments before calling the Mesa function.</li>
<li>When a function is not available in Mesa, or accepts arguments that are not available in OpenGL, it provides its own implementation.</li>
</ul>
<p>Other than the last case, OpenGL ES uses <code>APIspec.xml</code> to generate functions to check and/or converts the arguments.</p>
</div>
</body>
</html>

View File

@@ -1,81 +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>Off-screen Rendering</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>Off-screen Rendering</h1>
<p>
Mesa's off-screen interface is used for rendering into user-allocated memory
without any sort of window system or operating system dependencies.
That is, the GL_FRONT colorbuffer is actually a buffer in main memory,
rather than a window on your display.
</p>
<p>
The OSMesa API provides three basic functions for making off-screen
renderings: OSMesaCreateContext(), OSMesaMakeCurrent(), and
OSMesaDestroyContext(). See the Mesa/include/GL/osmesa.h header for
more information about the API functions.
</p>
<p>
The OSMesa interface may be used with any of three software renderers:
</p>
<ol>
<li>llvmpipe - this is the high-performance Gallium LLVM driver
<li>softpipe - this it the reference Gallium software driver
<li>swrast - this is the legacy Mesa software rasterizer
</ol>
<p>
There are several examples of OSMesa in the mesa/demos repository.
</p>
<h1>Building OSMesa</h1>
<p>
Configure and build Mesa with something like:
<pre>
configure --enable-osmesa --disable-driglx-direct --disable-dri --with-gallium-drivers=swrast
make
</pre>
<p>
Make sure you have LLVM installed first if you want to use the llvmpipe driver.
</p>
<p>
When the build is complete you should find:
</p>
<pre>
lib/libOSMesa.so (swrast-based OSMesa)
lib/gallium/libOSMsea.so (gallium-based OSMesa)
</pre>
<p>
Set your LD_LIBRARY_PATH to point to one directory or the other to select
the library you want to use.
</p>
<p>
When you link your application, link with -lOSMesa
</p>
</div>
</body>
</html>

View File

@@ -1,31 +0,0 @@
ARB_texture_float:
Silicon Graphics, Inc. owns US Patent #6,650,327, issued November 18,
2003 [1].
SGI believes this patent contains necessary IP for graphics systems
implementing floating point rasterization and floating point
framebuffer capabilities described in ARB_texture_float extension, and
will discuss licensing on RAND terms, on an individual basis with
companies wishing to use this IP in the context of conformant OpenGL
implementations [2].
The source code to implement ARB_texture_float extension is included
and can be toggled on at compile time, for those who purchased a
license from SGI, or are in a country where the patent does not apply,
etc.
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.
You should contact a lawyer or SGI's legal department if you want to
enable this extension.
[1] http://www.google.com/patents/about?id=mIIOAAAAEBAJ&dq=6650327
[2] http://www.opengl.org/registry/specs/ARB/texture_float.txt

Some files were not shown because too many files have changed in this diff Show More