From 01df5d59e56a1b060568f8cad2e89f7eea22fc70 Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 29 Aug 2011 08:51:20 +0200 Subject: xwininfo libX11 libXmu libxcb mesa xserver xkeyboard-config git update 29 aug 2011 --- mesalib/docs/GL3.txt | 2 +- mesalib/docs/README.BEOS | 136 -------------- mesalib/docs/autoconf.html | 7 - mesalib/docs/contents.html | 211 +++++++++++---------- mesalib/docs/devinfo.html | 33 ++++ mesalib/docs/dispatch.html | 4 +- mesalib/docs/download.html | 1 - mesalib/docs/faq.html | 7 +- mesalib/docs/fbdev-dri.html | 343 ---------------------------------- mesalib/docs/glfbdev-driver.html | 111 ----------- mesalib/docs/install.html | 18 -- mesalib/docs/libGL.txt | 394 +++++++++++++++++++-------------------- mesalib/docs/postprocess.html | 56 ++++++ mesalib/docs/sourcetree.html | 2 - mesalib/docs/subset.html | 2 +- mesalib/docs/systems.html | 8 +- 16 files changed, 403 insertions(+), 932 deletions(-) delete mode 100644 mesalib/docs/README.BEOS delete mode 100644 mesalib/docs/fbdev-dri.html delete mode 100644 mesalib/docs/glfbdev-driver.html create mode 100644 mesalib/docs/postprocess.html (limited to 'mesalib/docs') diff --git a/mesalib/docs/GL3.txt b/mesalib/docs/GL3.txt index c0cc4d172..ff1f5020a 100644 --- a/mesalib/docs/GL3.txt +++ b/mesalib/docs/GL3.txt @@ -123,7 +123,7 @@ GL_ARB_texture_storage not started GL_ARB_transform_feedback_instanced not started GL_ARB_base_instance not started GL_ARB_shader_image_load_store not started -GL_ARB_conservative_depth not started (may be close to AMD_conservative_depth though) +GL_ARB_conservative_depth DONE (compiler) GL_ARB_shading_language_420pack not started GL_ARB_internalformat_query not started GL_ARB_map_buffer_alignment not started diff --git a/mesalib/docs/README.BEOS b/mesalib/docs/README.BEOS deleted file mode 100644 index efd84e888..000000000 --- a/mesalib/docs/README.BEOS +++ /dev/null @@ -1,136 +0,0 @@ - - Mesa / BeOS Information - - - -* Introduction - -Brian Paul added in Mesa 3.1 a driver for BeOS R4.5 operating system. -This driver implements a clone of the BGLView class. This class, -derived from BView, allows OpenGL rendering into any BeOS window. His -driver was updated in Mesa 4.1 and again in version 6.1 by Philippe -Houdoin, who's maintaining this driver since. - -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 src/mesa/drivers/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 - -Since Mesa 6.x, it can be build under BeOS with both the R5 builtin gcc version -or more recent gcc versions available for BeOS, like this gcc version 2.95.3 for BeOS -you can find at http://www.bebits.com/app/2157. -Anyway, keep in mind that to take full advantage of Mesa x86 optimizations, you better -want to use gcc 2.95.3 or sooner versions... - -To build Mesa-powered BeOS libGL.so version, open an Terminal window, -move to Mesa root folder and type this command: - -$ make beos - -Note that the "beos" argument is only needed the first time to setup build config. -Next times, typing "make" will be enough. - -When it finishes the Mesa based libGL.so library for -BeOS will be in the lib/ directory, along libglut.so library. -Several demo/test programs should have been build too under progs/* folders. -If it stop when building one of the progs/* programs, you may want to ignore it -and force make to move on next target by adding the -k make option: - -$ cd progs -$ make -k - -To install it as Be's default libGL.so replacement, put it in your -/boot/home/config/lib/ directory. All your GL/GLUT apps 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. -For PowerPC BeOS flavor, sorry, Mesa don't have ppc (Altivec) optimizations -yet. - -To build a DEBUG version, type instead this : - -$ DEBUG=1 make - - -* Example Programs - -Look under progs/beos/ for some BGLView-based programs. -You should find under progs/samples and progs/redbook directories GLUT-based programs too. -They all should have been compiled along with the Mesa library. - - -* GLUT - -A beta version of GLUT 3.7 port for BeOS, made by Jake Hamby, can be found at -http://anobject.com/jehamby/Code/Glut-3.7-x86.zip. -This is the version currently included in Mesa source code, and -build in lib/libglut.so. - -A previous 3.5 version of this GLUT BeOS port used to be available at -http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip. - -They're special versions of GLUT for the BeOS platform. 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. -- Multiple renderers add-ons support, first step toward hardware acceleration - support. - -* Other contributors to this BeOS port - -Jake Hamby jhamby anobject com -Marcin Konicki ahwayakchih neoni net -Francois Revol revol free fr -Nathan Whitehorn nathanw uchicago edu - - -* Older 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 and newer, to my knowledge, -as of February, 1999. - - ----------------------------------------------------------------------- diff --git a/mesalib/docs/autoconf.html b/mesalib/docs/autoconf.html index 64bcbd48a..895cf665c 100644 --- a/mesalib/docs/autoconf.html +++ b/mesalib/docs/autoconf.html @@ -20,7 +20,6 @@
  • Library Options
  • Demo Program Options
    • @@ -245,12 +244,6 @@ instructions. on all drivers. This can be disable with the option --disable-glu. - - -
  • GLw - The libGLw library will be built by default -if libGLU has been enabled. This can be disable with the option ---disable-glw. -

    • diff --git a/mesalib/docs/contents.html b/mesalib/docs/contents.html index bf5e9aa09..df0fb6474 100644 --- a/mesalib/docs/contents.html +++ b/mesalib/docs/contents.html @@ -1,106 +1,105 @@ - - -Contents - - - - - - - -Documentation -     - -Download / Install - - -Resources - - -User Topics - - -Developer Topics - - -Links - - -Hosted by: -
    -
    -Sourceforge.net -
    - - - + + +Contents + + + + + + + +Documentation + + +Download / Install + + +Resources + + +User Topics + + +Developer Topics + + +Links + + +Hosted by: +
    +
    +Sourceforge.net +
    + + + diff --git a/mesalib/docs/devinfo.html b/mesalib/docs/devinfo.html index 8887dd026..d9e82e29d 100644 --- a/mesalib/docs/devinfo.html +++ b/mesalib/docs/devinfo.html @@ -71,6 +71,13 @@ well documented. Also, strive to write clean, easily understandable code. If you use tabs, set them to 8 columns

    +

    +Line width: the preferred width to fill comments and code in Mesa is 78 +columns. Exceptions are sometimes made for clarity (e.g. tabular data is +sometimes filled to a much larger width so that extraneous carriage returns +don't obscure the table). +

    +

    Brace example:

    @@ -81,10 +88,26 @@ Brace example: else { bar; } + + switch (condition) { + case 0: + foo(); + break; + + case 1: { + ... + break; + } + + default: + ... + break; + }

    Here's the GNU indent command which will best approximate my preferred style: +(Note that it won't format switch statements in the preferred way) 

     	indent -br -i3 -npcs --no-tabs infile.c -o outfile.c
@@ -114,6 +137,16 @@ Function name examples:
 	_mesa_foo_bar()  - an internal non-static Mesa function
    +

    +Places that are not directly visible to the GL API should prefer the use +of bool, true, and +false over GLboolean, GL_TRUE, and +GL_FALSE. In C code, this may mean that +#include <stdbool.h> need to be added. The +try_emit_* methods in src/mesa/program/ir_to_mesa.cpp and +src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as an example. +

    +

    Making a New Mesa Release

    diff --git a/mesalib/docs/dispatch.html b/mesalib/docs/dispatch.html index e5587c1a2..c3a33b90b 100644 --- a/mesalib/docs/dispatch.html +++ b/mesalib/docs/dispatch.html @@ -198,9 +198,7 @@ few preprocessor defines.

    • If GLX_USE_TLS is defined, method #4 is used.
    • If PTHREADS is defined, method #3 is used.
      • -
    • If any of PTHREADS, -WIN32_THREADS, or BEOS_THREADS -is defined, method #2 is used.
      • +
    • If WIN32_THREADS is defined, method #2 is used.
    • If none of the preceeding are defined, method #1 is used.
    diff --git a/mesalib/docs/download.html b/mesalib/docs/download.html index 3c4d5976c..4e8fc2f02 100644 --- a/mesalib/docs/download.html +++ b/mesalib/docs/download.html @@ -84,7 +84,6 @@ src/mesa - sources for the main Mesa library and device drivers src/gallium - sources for Gallium and Gallium drivers src/glu - libGLU source code src/glx - sources for building libGL with full GLX and DRI support -src/glw - Xt/Motif/OpenGL widget code If you downloaded and unpacked the MesaGLUT.x.y.z package: diff --git a/mesalib/docs/faq.html b/mesalib/docs/faq.html index 071381c5a..bf6545fd5 100644 --- a/mesalib/docs/faq.html +++ b/mesalib/docs/faq.html @@ -204,8 +204,13 @@ If you don't already have GLUT installed, you should grab

    +

    2.4 Where is the GLw library?

    +

    +GLw (OpenGL widget library) is now available from a separate git repository. Unless you're using very old Xt/Motif applications with OpenGL, you shouldn't need it. +

    + -

    2.4 What's the proper place for the libraries and headers?

    +

    2.5 What's the proper place for the libraries and headers?

    On Linux-based systems you'll want to follow the Mesa fbdev/DRI Environment - - - - - - - -

    Mesa fbdev/DRI Drivers

    -
    - -

    NOTE: this information is obsolete and will be removed at -a future date

    - -

    1. Introduction

    - -

    -The fbdev/DRI environment supports hardware-accelerated 3D rendering without -the X window system. This is typically used for embedded applications. -

    - -

    -Contributors to this project include Jon Smirl, Keith Whitwell and Dave Airlie. -

    - -

    -Applications in the fbdev/DRI environment use -the MiniGLX interface to choose pixel -formats, create rendering contexts, etc. It's a subset of the GLX and -Xlib interfaces allowing some degree of application portability between -the X and X-less environments. -

    - -

    -Note that this environment is not well-supported and these instructions -may not be completely up to date. -

    -
    - - - -

    2. Compilation

    -

    - -

    2.1 glxproto

    - -Get     glxproto.h. Copy it to the /mesa/include/GL/ directory. -

    - -

    2.2 libpciaccess

    -

    -Check if you have libpciaccess installed: -

    - -
    pkg-config --modversion pciaccess
-
    -

    -If not you can download the latest code from: -

    -
       git clone git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
-
    -

    -Run autogen.sh to generate a configure file. autogen.sh uses autoconf -utility. This utility may not be installed with your linux distro, -check if it is available. if not you can use your package manager or -type: -

    -
    sudo apt-get install autoconf
-
    -The next step is to install the libpciaccess library. -
    make
-make install
-
    -

    Now your libpciaccess.a file is saved into /usr/local/lib -directory. If you have a libpciaccess.a in /usr/lib you may simply copy -and overwrite these files. Don't forget to copy libpciaccess.pc file to -/usr/lib/pkgconfig, which is also located in /usr/local/lib/pkgconfig/. -Or you may use the following system variables: -

    -
    export LD_LIBRARY_PATH=/usr/local/lib
-export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
-
    - -

    2.3 drm

    - -

    The next step is to compile the drm. DRM consists of two seperate parts, -the DRM client library(lindrm.so) and kernel device module(such as -radeon.ko). We need to make a small change in kernel device module. So -you need to download the kernel source. You may choose the nearest -mirror from www.kernel.org, or you are using Fedora Core 5, for -example, you may need to install RPMs such as: -kernel-smp-devel-2.16.15-1.2054_FC5.i686.rpm -kernel-devel-2.6.15-1.2054_FC5.i686.rpm -etc. You can find a detailed information here. -

    - -

    You will find drm_drv.c at /usr/src/LINUX-VERSION/drivers/char/drm/. Edit this code and comment out the following part: -

    - -
    -   /* ||
-   ((ioctl->flags & DRM_MASTER) && !priv->master)*/
-
    -Now you are ready to compile your kernel. If your kernel version is -identical to the version you have compiled, you can simply over write -your new "ko" files over older ones. If you have compiled a different -kernel, you must configure your grub or lilo to be able to boot your -new kernel.

    -You'll need fbdev header files. Check with: -

    -
    -   ls -l /usr/include/linux/fb.
-
    -

    This file may be missing if you have not installed linux header files. - - -

    2.4 Mesa

    - -

    Get latest development Mesa sources from git repository -(currently 7.1-prerelease) -

    -
    -   git clone git://anongit.freedesktop.org/git/mesa/mesa
-
    - -

    You will need the makedepend utility which is a part of mesa project -to build your linux-solo. You probably wont have this utility. You can -download its source from following git repulsitory: -

    -
    -   git clone git://anongit.freedesktop.org/git/xorg/util/makedepend
-
    - -

    Get the latest stable mesa version from SourceForge (currently 7.0.3) -http://sourceforge.net/project/showfiles.php?group_id=3 -

    - -

    Copy the miniglx folder from 7.1-prerelease to 7.0.3. -You may also extract GLUT to 7.0.3 version at this step. -

    - -

    Edit linux-solo.conf at /conf directory, just only compile the -graphics driver you need, delete the unwanted drivers names from the -list(some drivers are causing problems...) -

    -
    -   while(build==0)
-   {
-     make linux-solo
-
-     There will be some missing header files, copy them from 7.1-prerelease
-   }
-
    - -

    -When complete you should have the following: -

    -
      -
    • lib/libGL.so - the GL library which applications link with -
    • lib/*_dri_so - DRI drivers -
    • lib/miniglx.conf - sample MiniGLX config file -
    • progs/miniglx/* - several MiniGLX sample programs -
    - -To install these files into appropriate locations in system: -
    -   make install
-
    - -Now your openGL libraries are copied to /usr/local/lib and -miniglx.conf is copied to /etc. You may copy them to /usr/lib and -overwrite your old GL libraries. Or you may export following variable: - -
    -   export LIBGL_DRIVERS_PATH=/usr/local/lib
-
    -
    - - -

    3. Using fbdev/DRI

    - -

    -If an X server currently running, exit/stop it so you're working from -the console. Following command shuts down the x window and also the multi user support. -

    -
    -   init 1
-
    - -

    Also you may define the runlevel as 1 in "/etc/inittab". Your system -will always start in single user mode and without x-window with this -option set. -

    3.1 Load Kernel Modules

    - -

    -You'll need to load the kernel modules specific to your graphics hardware. -Typically, this consists of the agpgart module, an fbdev driver module -and the DRM kernel module. -

    -

    -As root, the kernel modules can be loaded as follows: -

    - -

    -If you have Intel i915/i945 hardware: -

    -
       modprobe agpgart            # the AGP GART module
-   modprobe intelfb            # the Intel fbdev driver
-   modprobe i915               # the i915/945 DRI kernel module
-
    - -

    -If you have ATI Radeon/R200 hardware: -

    -
       modprobe agpgart            # the AGP GART module
-   modprobe radeonfb           # the Radeon fbdev driver
-   modprobe radeon             # the Radeon DRI kernel module
-
    - -

    -If you have ATI Rage 128 hardware: -

    -
       modprobe agpgart            # the AGP GART module
-   modprobe aty128fb           # the Rage 128 fbdev driver
-   modprobe r128               # the Rage 128 DRI kernel module
-
    - -

    -If you have Matrox G200/G400 hardware: -

    -
       modprobe agpgart            # the AGP GART module
-   modprobe mgafb              # the Matrox fbdev driver
-   modprobe mga                # the Matrox DRI kernel module
-
    - -

    -To verify that the agpgart, fbdev and drm modules are loaded: -

    -
       ls -l /dev/agpgart /dev/fb* /dev/dri
-
    -

    -Alternately, use lsmod to inspect the currently installed modules. -If you have problems, look at the output of dmesg. -

    - - -

    3.2 Configuration File

    - -

    -review/edit /etc/miniglx.conf. -Alternately, the MINIGLX_CONF environment variable can be used to -indicate the location of miniglx.conf -

    - -To determine the pciBusID value, run lspci and examine the output. -For example: -

    -
       /sbin/lspci:
-   00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04)
-
    -

    -00:02.0 indicates that pciBusID should be PCI:0:2:0 -

    - - - - -

    3.3 Running fbdev/DRI Programs

    - -

    -Make sure your LD_LIBRARY_PATH environment variable is set to the -location of the libGL.so library. You may need to append other paths -to LD_LIBRARY_PATH if libpciaccess.so is in a non-standard location, -for example. -

    - -

    -Change to the Mesa/progs/miniglx/ directory and -start the sample_server program in the background: -

    -
       ./sample_server &
-
    - -

    -Then try running the miniglxtest program: -

    -
       ./miniglxtest
-
    -

    -You should see a rotating quadrilateral which changes color as it rotates. -It will exit automatically after a bit. -

    - -

    -If you run other tests in the miniglx/ directory, you may want to run -them from a remote shell so that you can stop them with ctrl-C. -

    -
    - - -

    4.0 Troubleshooting

    - -
      -
    1. -If you try to run miniglxtest and get the following: -
      -
         [miniglx] failed to probe chipset
-   connect: Connection refused
-   server connection lost
-
      -It means that the sample_server process is not running. -
      -
      -
      2. -
    - - -

    5.0 Programming Information

    - -

    -OpenGL/Mesa is interfaced to fbdev via the MiniGLX interface. -MiniGLX is a subset of Xlib and GLX API functions which provides just -enough functionality to setup OpenGL rendering and respond to simple -input events. -

    - -

    -Since MiniGLX is a subset of the usual Xlib and GLX APIs, programs written -to the MiniGLX API can also be run on full Xlib/GLX implementations. -This allows some degree of flexibility for software development and testing. -

    - -

    -However, the MiniGLX API is not binary-compatible with full Xlib/GLX. -Some of the structures are different and some macros/functions work -differently. -See the GL/miniglx.h header file for details. -

    - - - - - diff --git a/mesalib/docs/glfbdev-driver.html b/mesalib/docs/glfbdev-driver.html deleted file mode 100644 index 981df7c08..000000000 --- a/mesalib/docs/glfbdev-driver.html +++ /dev/null @@ -1,111 +0,0 @@ - - -Mesa glFBDev Driver - - - - - -

    Mesa glFBDev Driver

    - - -

    1. Introduction

    - -

    -The GLFBDev driver interface allows one to do OpenGL rendering into a -framebuffer managed with the Linux's fbdev interface. -

    - -

    -Basically, the programmer uses the fbdev functions to initialize the -graphics hardware and setup the framebuffer. -Then, using a calls to Mesa's glFBDev API functions, one can render -into the framebuffer with the OpenGL API functions. -

    - -

    -Note, only software rendering is supported; there is no hardware -acceleration. -

    - - -

    -The GL/glfbdev.h header file defines the glFBDev interface. -

    - -

    -The progs/fbdev/glfbdevtest.c demonstrates how to use the glFBDev interface. -

    - - -

    -For more information about fbdev, see the - -Framebuffer Howto -

    -

    -You will need at minimum, a framebuffer device, check /dev/fb0 -

    - -

    2. Compilation

    - -

    -To compile Mesa with support for the glFBDev interface: -

    -      make realclean
-      make linux-fbdev
-
    - -

    -When compilation is finished look in progs/glfbdev/ for the glfbdevtest demo. -

    -

    3. Permissions

    - -

    -Typically /dev/fb/0 is grouped to the video group. It may be useful to add -your user to the video group so the demos will not have to be run as root. -To use fbdevglut with the prefered tty input, you should add the user to the -tty group as well -

    - -

    4. Using fbdevglut

    -Almost all of the programs in the progs directory use glut, and they compile with fbdevglut. - -

    -To compile the redbook sample programs: -

    -       cd progs/redbook
-       make
-
    -

    -

    glut features not supported: -

  • Overlays -
  • Subwindows -
  • Input devices other than Keyboard/Mouse -
  • No support for GLUT_MULTISAMPLE, GLUT_STEREO, or GLUT_LUMINANCE -
  • Cursor and Menu Support will flicker in GLUT_SINGLE mode - -

    Keyboard input is read by opening /dev/tty and reading keycodes in medium raw mode. -

    Mouse input is read from env var MOUSE, or /dev/gpmdata and should be in ms3 format. -To forward data in this format to /dev/gpmdata, run gpm with the -Rms3 option. -

    glutInit allows glut programs to pass parameters to the glut library, currently the -following options are supported for fbdevglut: -

  • -geometry widthxheight -- This will force the resolution to be widthxheight instead of autodetecting. -The modes are read from /etc/fb.modes -

  • -bpp -- This will force the bitdepth to the one specified -

  • -vt -- This allows you to specify the virtual terminal to attach keyboard input to. It is useful to specify when running inside screen. -

  • -mousespeed -- A floating point multiplication factor to increase mouse speed -

  • -nomouse -- Disable mouse support -

  • -nokeyboard -- Disable keyboard support (this will probably break mouse support as well) -

  • -stdin -- Use stdin for input instead of attaching to kbd in medium-raw mode. -This will make it impossible to detect keypresses like Shift+Tab, you will also need to specify -gpmmouse for mouse support. This option can be used with a debugger, and it is possible to single step a program with gdb and set the FRAMEBUFFER environment variable to a different framebuffer for display. The program will not be able to handle vt switching on it's own, so it will always display. -

  • -gpmmouse -- This will attempt to connect to the /dev/gpmctl socket using liblow -for mouse data. Gpm does not provide this data when in graphics mode, so vt switching -will briefly display text. This mode typically has no initial mouse delay. -

  • -- Ignore any additional arguments -

    Notes: -

    -1. The mouse pointer flickers in single buffering mode, as it must be rendered in software. Hopefully in the future there will be a way to access hardware cursors in fbdev devices. -

    - - diff --git a/mesalib/docs/install.html b/mesalib/docs/install.html index e1018119a..228100ec7 100644 --- a/mesalib/docs/install.html +++ b/mesalib/docs/install.html @@ -157,9 +157,6 @@ lrwxrwxrwx 1 brian users 20 Mar 26 07:53 libGLU.so.1 -> libGLU.so lrwxrwxrwx 1 brian users 12 Mar 26 07:53 libglut.so -> libglut.so.3* lrwxrwxrwx 1 brian users 16 Mar 26 07:53 libglut.so.3 -> libglut.so.3.7.1* -rwxr-xr-x 1 brian users 597754 Mar 26 07:53 libglut.so.3.7.1* -lrwxrwxrwx 1 brian users 11 Mar 26 08:04 libGLw.so -> libGLw.so.1* -lrwxrwxrwx 1 brian users 15 Mar 26 08:04 libGLw.so.1 -> libGLw.so.1.0.0* --rwxr-xr-x 1 brian users 20750 Mar 26 08:04 libGLw.so.1.0.0* 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* @@ -172,8 +169,6 @@ lrwxrwxrwx 1 brian users 23 Mar 26 07:53 libOSMesa.so.6 -> libOSM
    libglut is the GLUT library.
    -libGLw is the Xt/Motif OpenGL drawing area widget library. -
    libOSMesa is the OSMesa (Off-Screen) interface library.

    @@ -181,22 +176,10 @@ lrwxrwxrwx 1 brian users 23 Mar 26 07:53 libOSMesa.so.6 -> libOSM If you built the DRI hardware drivers, you'll also see the DRI drivers: 

    --rwxr-xr-x   1 brian users 15607851 Jul 21 12:11 ffb_dri.so
--rwxr-xr-x   1 brian users 15148747 Jul 21 12:11 i810_dri.so
--rwxr-xr-x   1 brian users 14497814 Jul 21 12:11 i830_dri.so
 -rwxr-xr-x   1 brian users 16895413 Jul 21 12:11 i915_dri.so
--rwxr-xr-x   1 brian users 11320803 Jul 21 12:11 mach64_dri.so
--rwxr-xr-x   1 brian users 11418014 Jul 21 12:12 mga_dri.so
--rwxr-xr-x   1 brian users 11064426 Jul 21 12:12 r128_dri.so
 -rwxr-xr-x   1 brian users 11849858 Jul 21 12:12 r200_dri.so
 -rwxr-xr-x   1 brian users 16050488 Jul 21 12:11 r300_dri.so
 -rwxr-xr-x   1 brian users 11757388 Jul 21 12:12 radeon_dri.so
--rwxr-xr-x   1 brian users 11232304 Jul 21 12:13 s3v_dri.so
--rwxr-xr-x   1 brian users 11062970 Jul 21 12:13 savage_dri.so
--rwxr-xr-x   1 brian users 11214212 Jul 21 12:13 sis_dri.so
--rwxr-xr-x   1 brian users 11368736 Jul 21 12:13 tdfx_dri.so
--rwxr-xr-x   1 brian users 10598868 Jul 21 12:13 trident_dri.so
--rwxr-xr-x   1 brian users 10997120 Jul 21 12:13 unichrome_dri.so

    @@ -327,7 +310,6 @@ Documentation for other environments (some may be very out of date):

  • README.GGI - GGI
  • README.3DFX - 3Dfx/Glide driver
  • README.AMIWIN - Amiga Amiwin -
  • README.BEOS - BeOS
  • README.D3D - Direct3D driver
  • README.DJ - DJGPP
  • README.LYNXOS - LynxOS diff --git a/mesalib/docs/libGL.txt b/mesalib/docs/libGL.txt index 750917d10..d06b4e62a 100644 --- a/mesalib/docs/libGL.txt +++ b/mesalib/docs/libGL.txt @@ -1,197 +1,197 @@ - - - -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 _dri.so where - is a driver such as "tdfx", "i810", "gamma", 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 noticably -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. - + + + +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 _dri.so where + 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 noticably +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. + diff --git a/mesalib/docs/postprocess.html b/mesalib/docs/postprocess.html new file mode 100644 index 000000000..2a3796942 --- /dev/null +++ b/mesalib/docs/postprocess.html @@ -0,0 +1,56 @@ + + +Gallium Post-processing + + + + + +

    Gallium Post-processing

    + +

    +The Gallium drivers support user-defined image post-processing. +At the end of drawing a frame a post-processing filter can be applied to +the rendered image. +Example filters include morphological antialiasing and cell shading. +

    + +

    +The filters can be toggled per-app via driconf, or per-session via the +corresponding environment variables. +

    + +

    +Multiple filters can be used together. +

    + + +

    PP environment variables

    + +
      +
    • PP_DEBUG - If defined debug information will be printed to stderr. +
    + +

    Current filters

    + +
      +
    • pp_nored, pp_nogreen, pp_noblue - set to 1 to remove the corresponding color channel. +These are basic filters for easy testing of the PP queue. +
    • pp_jimenezmlaa, pp_jimenezmlaa_color - +Jimenez's MLAA +is a morphological antialiasing filter. +The two versions use depth and color data, respectively. +Which works better depends on the app - depth will not blur text, but it will +miss transparent textures for example. +Set to a number from 2 to 32, roughly corresponding to quality. +Numbers higher than 8 see minimizing gains. +
    • pp_celshade - set to 1 to enable cell shading (a more complex color filter). +
    + + +
    +
    + + + + diff --git a/mesalib/docs/sourcetree.html b/mesalib/docs/sourcetree.html index 2e2d1d3f2..713e25b01 100644 --- a/mesalib/docs/sourcetree.html +++ b/mesalib/docs/sourcetree.html @@ -153,8 +153,6 @@ each directory.
  • glx - The GLX library code for building libGL. This is used for direct rendering drivers. It will dynamically load one of the xxx_dri.so drivers. -
  • glw - Widgets for Xt/Motif. -
  • glew - OpenGL Extension Wrangler library (used by demo programs)
  • progs - OpenGL test and demonstration programs
  • lib - where the GL libraries are placed diff --git a/mesalib/docs/subset.html b/mesalib/docs/subset.html index 4ac2eadff..c706381e3 100644 --- a/mesalib/docs/subset.html +++ b/mesalib/docs/subset.html @@ -12,7 +12,7 @@ In 2002/2003 Tungsten Graphics was contracted to develop a subset Mesa/Radeon driver for an embedded environment. The result is a reduced-size DRI driver for the ATI R200 chip, for use with -fbdev/DRI environment. +fbdev/DRI environment.

    diff --git a/mesalib/docs/systems.html b/mesalib/docs/systems.html index 5137b074e..03db779a1 100644 --- a/mesalib/docs/systems.html +++ b/mesalib/docs/systems.html @@ -16,14 +16,13 @@ X development environment to use Mesa.

    The DRI hardware drivers for the X.org server and XFree86 provide -hardware accelerated rendering for chips from ATI, Intel, Matrox, 3dfx -and others on Linux and FreeBSD. +hardware accelerated rendering for chips from ATI, Intel, and NVIDIA +on Linux and FreeBSD.

    Drivers for other assorted platforms include: -the Amiga, Apple Macintosh, BeOS, NeXT, OS/2, MS-DOS, VMS, Windows -9x/NT, and Direct3D. +the Apple Macintosh and Windows.

    @@ -51,7 +50,6 @@ They can be saved if someone steps up to help.

  • 3dfx/Glide (README.3DFX)
  • GGI (README.GGI)
  • Amiga Amiwin (README.AMIWIN) -
  • BeOS (README.BEOS)
  • Direct3D driver (README.D3D)
  • DJGPP (README.DJ)
  • LynxOS (README.LYNXOS) -- cgit v1.2.3