Compare commits
138 Commits
vulkan-hea
...
embedded-1
Author | SHA1 | Date | |
---|---|---|---|
|
2005348110 | ||
|
634a7b2f00 | ||
|
d73e21620a | ||
|
d5cfbef5ad | ||
|
1d08fddfe6 | ||
|
447ea351dd | ||
|
0ebc838481 | ||
|
14a7a05251 | ||
|
c2edc07196 | ||
|
222a212569 | ||
|
78469e6e3d | ||
|
63d0a9055c | ||
|
27834f06b8 | ||
|
c262531518 | ||
|
1b2c02ae98 | ||
|
fb5f90d71b | ||
|
4fb1eb7be2 | ||
|
cf119744c3 | ||
|
b07ed0113a | ||
|
d6d8d1dfce | ||
|
f483ebddeb | ||
|
35fe61ce7b | ||
|
c3b1d1e63c | ||
|
38bfead7d3 | ||
|
56f57500b9 | ||
|
2ce0615ef1 | ||
|
559af8ace4 | ||
|
f73e37e154 | ||
|
ec5b054b8f | ||
|
8a63d4bc99 | ||
|
f58e67787f | ||
|
deb4d4de47 | ||
|
1449a2f759 | ||
|
f0b66442e8 | ||
|
8830b0a941 | ||
|
deb5fe3b68 | ||
|
1e1e71e3a7 | ||
|
53362d8858 | ||
|
af82796ed1 | ||
|
6ded963ac6 | ||
|
b4f35d5191 | ||
|
0b9434aafd | ||
|
fb02d9f4eb | ||
|
2b83583994 | ||
|
76415ea859 | ||
|
10d05983ef | ||
|
7c35ac6e82 | ||
|
ca9cccd81c | ||
|
ea9f98b04b | ||
|
8b4a34dcdb | ||
|
267bc32309 | ||
|
8618425250 | ||
|
24259ec2d0 | ||
|
97aa6f3734 | ||
|
6b723c7720 | ||
|
211f26ca95 | ||
|
df7cbe873e | ||
|
da8a7e15a6 | ||
|
f6546f8384 | ||
|
cd22e4b78c | ||
|
5ff65a62df | ||
|
fd55975710 | ||
|
c83b869ed2 | ||
|
592250e9fc | ||
|
cdb267a918 | ||
|
2c2bcf8268 | ||
|
695b197cb2 | ||
|
e17d611067 | ||
|
9df9883a7a | ||
|
22477c050e | ||
|
39afeb7cf0 | ||
|
9363bd862f | ||
|
83b936adb3 | ||
|
5134d4a98b | ||
|
2481eda853 | ||
|
6b31afc236 | ||
|
8fd39b4e8c | ||
|
094eed79c2 | ||
|
d20f1768a6 | ||
|
3e06eed70a | ||
|
3e13551969 | ||
|
3af2be61fd | ||
|
eb7eb6e171 | ||
|
e931e819f9 | ||
|
95936ee9ba | ||
|
157d9a5ac6 | ||
|
134930b627 | ||
|
a97ce86232 | ||
|
5ca95653c4 | ||
|
1f01a4b3b6 | ||
|
8645472e00 | ||
|
1929cacdbf | ||
|
65e30ac06a | ||
|
941efe8eda | ||
|
ea4b887ef7 | ||
|
ba8e63f05b | ||
|
117a2d76b6 | ||
|
ce75913702 | ||
|
cbc41d4332 | ||
|
40af4d7662 | ||
|
702b2802a0 | ||
|
44e4e437a0 | ||
|
366ca58ea6 | ||
|
90925c9777 | ||
|
f6b40da9a7 | ||
|
80798c8eab | ||
|
65a7a3852d | ||
|
cf8aede714 | ||
|
1e27ca69f8 | ||
|
9fcd566e60 | ||
|
78b5f5f44f | ||
|
8a82d9db15 | ||
|
fa747cdb0a | ||
|
fa50fae202 | ||
|
0fb48dba7c | ||
|
2f3585d4f1 | ||
|
7c7789c029 | ||
|
56ad63958b | ||
|
aa0109bf96 | ||
|
0201db5a22 | ||
|
1a1069c7e9 | ||
|
fc88680a39 | ||
|
ff89f4b639 | ||
|
7d5b5c0438 | ||
|
6ccaeaaa16 | ||
|
e4e72da501 | ||
|
67f87d2463 | ||
|
431c1740d5 | ||
|
fa3f447234 | ||
|
3a08052714 | ||
|
424096d581 | ||
|
2e5a88ab6a | ||
|
d520ff08d0 | ||
|
ef0e1dcc2e | ||
|
6412641b19 | ||
|
3ee066b48f | ||
|
33c0b3e233 | ||
|
658145bd82 |
@@ -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
4
.gitattributes
vendored
@@ -1,4 +0,0 @@
|
||||
*.dsp -crlf
|
||||
*.dsw -crlf
|
||||
*.sln -crlf
|
||||
*.vcproj -crlf
|
48
.gitignore
vendored
48
.gitignore
vendored
@@ -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
|
@@ -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
|
104
Android.mk
104
Android.mk
@@ -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
|
16
CleanSpec.mk
16
CleanSpec.mk
@@ -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
1636
Make-config
Normal file
File diff suppressed because it is too large
Load Diff
765
Makefile.X11
Normal file
765
Makefile.X11
Normal 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) ; \
|
61
Makefile.am
61
Makefile.am
@@ -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) {} +
|
155
SConstruct
155
SConstruct
@@ -1,155 +0,0 @@
|
||||
#######################################################################
|
||||
# Top-level SConstruct
|
||||
#
|
||||
# For example, invoke scons as
|
||||
#
|
||||
# scons build=debug llvm=yes machine=x86
|
||||
#
|
||||
# to set configuration variables. Or you can write those options to a file
|
||||
# named config.py:
|
||||
#
|
||||
# # config.py
|
||||
# build='debug'
|
||||
# llvm=True
|
||||
# machine='x86'
|
||||
#
|
||||
# Invoke
|
||||
#
|
||||
# scons -h
|
||||
#
|
||||
# to get the full list of options. See scons manpage for more info.
|
||||
#
|
||||
|
||||
import os
|
||||
import os.path
|
||||
import sys
|
||||
import SCons.Util
|
||||
|
||||
import common
|
||||
|
||||
#######################################################################
|
||||
# Configuration options
|
||||
|
||||
opts = Variables('config.py')
|
||||
common.AddOptions(opts)
|
||||
|
||||
env = Environment(
|
||||
options = opts,
|
||||
tools = ['gallium'],
|
||||
toolpath = ['#scons'],
|
||||
ENV = os.environ,
|
||||
)
|
||||
|
||||
# XXX: This creates a many problems as it saves...
|
||||
#opts.Save('config.py', env)
|
||||
|
||||
# Backwards compatability with old target configuration variable
|
||||
try:
|
||||
targets = ARGUMENTS['targets']
|
||||
except KeyError:
|
||||
pass
|
||||
else:
|
||||
targets = targets.split(',')
|
||||
print 'scons: warning: targets option is deprecated; pass the targets on their own such as'
|
||||
print
|
||||
print ' scons %s' % ' '.join(targets)
|
||||
print
|
||||
COMMAND_LINE_TARGETS.append(targets)
|
||||
|
||||
|
||||
Help(opts.GenerateHelpText(env))
|
||||
|
||||
#######################################################################
|
||||
# Environment setup
|
||||
|
||||
with open("VERSION") as f:
|
||||
mesa_version = f.read().strip()
|
||||
env.Append(CPPDEFINES = [
|
||||
('PACKAGE_VERSION', '\\"%s\\"' % mesa_version),
|
||||
('PACKAGE_BUGREPORT', '\\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\\"'),
|
||||
])
|
||||
|
||||
# Includes
|
||||
env.Prepend(CPPPATH = [
|
||||
'#/include',
|
||||
])
|
||||
env.Append(CPPPATH = [
|
||||
'#/src/gallium/include',
|
||||
'#/src/gallium/auxiliary',
|
||||
'#/src/gallium/drivers',
|
||||
'#/src/gallium/winsys',
|
||||
])
|
||||
|
||||
# for debugging
|
||||
#print env.Dump()
|
||||
|
||||
|
||||
#######################################################################
|
||||
# Invoke host SConscripts
|
||||
#
|
||||
# For things that are meant to be run on the native host build machine, instead
|
||||
# of the target machine.
|
||||
#
|
||||
|
||||
# Create host environent
|
||||
if env['crosscompile'] and not env['embedded']:
|
||||
host_env = Environment(
|
||||
options = opts,
|
||||
# no tool used
|
||||
tools = [],
|
||||
toolpath = ['#scons'],
|
||||
ENV = os.environ,
|
||||
)
|
||||
|
||||
# Override options
|
||||
host_env['platform'] = common.host_platform
|
||||
host_env['machine'] = common.host_machine
|
||||
host_env['toolchain'] = 'default'
|
||||
host_env['llvm'] = False
|
||||
|
||||
host_env.Tool('gallium')
|
||||
|
||||
host_env['hostonly'] = True
|
||||
assert host_env['crosscompile'] == False
|
||||
|
||||
target_env = env
|
||||
env = host_env
|
||||
Export('env')
|
||||
|
||||
SConscript(
|
||||
'src/SConscript',
|
||||
variant_dir = host_env['build_dir'],
|
||||
duplicate = 0, # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
|
||||
)
|
||||
|
||||
env = target_env
|
||||
|
||||
Export('env')
|
||||
|
||||
#######################################################################
|
||||
# Invoke SConscripts
|
||||
|
||||
# TODO: Build several variants at the same time?
|
||||
# http://www.scons.org/wiki/SimultaneousVariantBuilds
|
||||
|
||||
SConscript(
|
||||
'src/SConscript',
|
||||
variant_dir = env['build_dir'],
|
||||
duplicate = 0 # http://www.scons.org/doc/0.97/HTML/scons-user/x2261.html
|
||||
)
|
||||
|
||||
|
||||
########################################################################
|
||||
# List all aliases
|
||||
|
||||
try:
|
||||
from SCons.Node.Alias import default_ans
|
||||
except ImportError:
|
||||
pass
|
||||
else:
|
||||
aliases = default_ans.keys()
|
||||
aliases.sort()
|
||||
env.Help('\n')
|
||||
env.Help('Recognized targets:\n')
|
||||
for alias in aliases:
|
||||
env.Help(' %s\n' % alias)
|
14
autogen.sh
14
autogen.sh
@@ -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
9
bin/.gitignore
vendored
@@ -1,9 +0,0 @@
|
||||
config.guess
|
||||
config.sub
|
||||
install-sh
|
||||
/depcomp
|
||||
/missing
|
||||
ylwrap
|
||||
compile
|
||||
ar-lib
|
||||
/test-driver
|
@@ -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]\+ – \(.*\)<\/title>/\1/')
|
||||
echo "<li><a href=\"$i\">Bug $id</a> - $summary</li>"
|
||||
echo ""
|
||||
done
|
||||
|
||||
echo "</ul>"
|
||||
fi
|
@@ -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
153
bin/mklib.aix
Executable 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
38
bin/mklib.ar-ruv
Executable 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
52
bin/mklib.solaris
Normal 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
|
||||
|
@@ -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:
|
@@ -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/\&/&/g;s/</\</g;s/>/\>/g')
|
||||
echo ' <li>'${mesg}'</li>'
|
||||
fi
|
||||
done
|
113
common.py
113
common.py
@@ -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')
|
2563
configure.ac
2563
configure.ac
File diff suppressed because it is too large
Load Diff
@@ -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)
|
||||
|
241
docs/GL3.txt
241
docs/GL3.txt
@@ -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
182
docs/INSTALL.GNU
Normal 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.
|
@@ -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
|
88
docs/MESA_copy_sub_buffer.spec
Normal file
88
docs/MESA_copy_sub_buffer.spec
Normal 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
|
||||
|
@@ -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
|
@@ -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
|
||||
|
@@ -8,7 +8,7 @@ Name Strings
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
Brian Paul (brian 'at' mesa3d.org)
|
||||
|
||||
Status
|
||||
|
@@ -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
|
@@ -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
|
@@ -8,7 +8,7 @@ Name Strings
|
||||
|
||||
Contact
|
||||
|
||||
Brian Paul (brian.paul 'at' tungstengraphics.com)
|
||||
Brian Paul (brian 'at' mesa3d.org)
|
||||
|
||||
Status
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
@@ -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
613
docs/README.3DFX
Normal 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
181
docs/README.AMIWIN
Normal 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
114
docs/README.BEOS
Normal 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
124
docs/README.D3D
Normal 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
209
docs/README.DJ
Normal 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
26
docs/README.GGI
Normal 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
64
docs/README.LYNXOS
Normal 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
53
docs/README.MINGW32
Normal 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
102
docs/README.MITS
Normal 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
6
docs/README.NeXT
Normal 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
96
docs/README.OS2
Normal 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
35
docs/README.OpenStep
Normal 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
208
docs/README.QUAKE
Normal 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
52
docs/README.THREADS
Normal 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)
|
@@ -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.
|
@@ -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
28
docs/README.VMS
Normal 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.
|
||||
|
@@ -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
146
docs/README.WINDML
Normal 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
320
docs/README.X11
Normal 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
146
docs/RELNOTES-3.1
Normal 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
12
docs/RELNOTES-3.2
Normal 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
32
docs/RELNOTES-3.2.1
Normal 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
271
docs/RELNOTES-3.3
Normal 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
22
docs/RELNOTES-3.4
Normal 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
22
docs/RELNOTES-3.4.1
Normal 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
22
docs/RELNOTES-3.4.2
Normal 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
228
docs/RELNOTES-3.5
Normal 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
163
docs/RELNOTES-4.0
Normal 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
22
docs/RELNOTES-4.0.1
Normal 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
50
docs/RELNOTES-4.0.2
Normal 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
52
docs/RELNOTES-4.0.3
Normal 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
308
docs/RELNOTES-4.1
Normal 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
85
docs/RELNOTES-5.0
Normal 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 $
|
438
docs/VERSIONS
438
docs/VERSIONS
@@ -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
|
||||
|
@@ -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>
|
@@ -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>
|
@@ -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>
|
@@ -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>
|
@@ -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 & 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&type=1"
|
||||
width="88" height="31" align="bottom" alt="Sourceforge.net" border="0"></a>
|
||||
</blockquote>
|
||||
|
||||
</body>
|
||||
</html>
|
@@ -1,47 +0,0 @@
|
||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||||
<title>Debugging Tips</title>
|
||||
<link rel="stylesheet" type="text/css" href="mesa.css">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div class="header">
|
||||
<h1>The Mesa 3D Graphics Library</h1>
|
||||
</div>
|
||||
|
||||
<iframe src="contents.html"></iframe>
|
||||
<div class="content">
|
||||
|
||||
<h1>Debugging Tips</h1>
|
||||
|
||||
<p>
|
||||
Normally Mesa (and OpenGL) records but does not notify the user of
|
||||
errors. It is up to the application to call
|
||||
<code>glGetError</code> to check for errors. Mesa supports an
|
||||
environment variable, MESA_DEBUG, to help with debugging. If
|
||||
MESA_DEBUG is defined, a message will be printed to stdout whenever
|
||||
an error occurs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
More extensive error checking is done when Mesa is compiled with the
|
||||
DEBUG symbol defined. You'll have to edit the Make-config file and
|
||||
add -DDEBUG to the CFLAGS line for your system configuration. You may
|
||||
also want to replace any optimization flags with the -g flag so you can
|
||||
use your debugger. After you've edited Make-config type 'make clean'
|
||||
before recompiling.
|
||||
</p>
|
||||
<p>
|
||||
In your debugger you can set a breakpoint in _mesa_error() to trap Mesa
|
||||
errors.
|
||||
</p>
|
||||
<p>
|
||||
There is a display list printing/debugging facility. See the end of
|
||||
src/dlist.c for details.
|
||||
</p>
|
||||
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
@@ -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>
|
@@ -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 <stdbool.h></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 < 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 <jhacker@foo.com>
|
||||
</pre>
|
||||
<li>If the patch was reviewed (usually the case) or acked by someone,
|
||||
that should be documented with:
|
||||
<pre>
|
||||
Reviewed-by: Joe Hacker <jhacker@foo.com>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
</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 <jhacker@foo.com>
|
||||
</pre>
|
||||
or
|
||||
<pre>
|
||||
Acked-by: Joe Hacker <jhacker@foo.com>
|
||||
</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 <jhacker@foo.com>
|
||||
</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: <mesa-stable@lists.freedesktop.org></li>
|
||||
<li>CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org></li>
|
||||
<li>CC: "10.0" <mesa-stable@lists.freedesktop.org></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 <commit></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>
|
@@ -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->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>
|
@@ -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>
|
289
docs/egl.html
289
docs/egl.html
@@ -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<Resource>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<Resource>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>
|
@@ -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 >= 3.0.
|
||||
<li> GL versions < 3.0 are set to a compatibility (non-Core) profile
|
||||
<li> GL versions = 3.0, see below
|
||||
<li> GL versions > 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 & 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 & 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>
|
@@ -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>
|
392
docs/faq.html
392
docs/faq.html
@@ -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>
|
BIN
docs/gears.png
BIN
docs/gears.png
Binary file not shown.
Before Width: | Height: | Size: 3.4 KiB |
@@ -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>
|
1905
docs/index.html
1905
docs/index.html
File diff suppressed because it is too large
Load Diff
@@ -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 — 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>
|
355
docs/intro.html
355
docs/intro.html
@@ -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>
|
197
docs/libGL.txt
197
docs/libGL.txt
@@ -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.
|
||||
|
@@ -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>
|
@@ -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>
|
@@ -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 <same-as-before>
|
||||
</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>
|
@@ -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>
|
@@ -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;
|
||||
}
|
@@ -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() --> _mesa_Foo()
|
||||
OpenGL ES: glFoo() --> _es_Foo() --> _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>
|
@@ -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>
|
@@ -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
Reference in New Issue
Block a user