Home | History | Annotate | only in /external/mesa3d/docs
Up to higher level directory
NameDateSize
ARB_color_buffer_float.txt06-Dec-2013459
autoconf.html06-Dec-20139.4K
banner.html06-Dec-20131,004
bugs.html06-Dec-20131.6K
conform.html06-Dec-201318K
contents.html06-Dec-20134.1K
COPYING06-Dec-201324.9K
debugging.html06-Dec-20131.3K
developers.html06-Dec-20131.3K
devinfo.html06-Dec-20136.3K
dispatch.html06-Dec-201311.8K
download.html06-Dec-20132.5K
egl.html06-Dec-201311.6K
enums.txt06-Dec-20131.9K
envvars.html06-Dec-20136.8K
extensions.html06-Dec-20131.3K
faq.html06-Dec-201312.4K
games.html06-Dec-20133.3K
gears.png06-Dec-20131.6K
GL3.txt06-Dec-20138.6K
helpwanted.html06-Dec-20132.9K
index.html06-Dec-2013771
install.html06-Dec-20135.6K
intro.html06-Dec-20139.6K
libGL.txt06-Dec-20136.8K
libraries.html06-Dec-20134.6K
license.html06-Dec-20133.5K
lists.html06-Dec-20132.8K
llvmpipe.html06-Dec-20135.2K
mangling.html06-Dec-2013835
mesa.css06-Dec-2013516
MESA_agp_offset.spec06-Dec-20132K
MESA_copy_sub_buffer.spec06-Dec-20132.2K
MESA_drm_image.spec06-Dec-20135.2K
MESA_multithread_makecurrent.spec06-Dec-20134.8K
MESA_pack_invert.spec06-Dec-20133.6K
MESA_pixmap_colormap.spec06-Dec-20131.9K
MESA_release_buffers.spec06-Dec-20131.7K
MESA_resize_buffers.spec06-Dec-20131.8K
MESA_set_3dfx_mode.spec06-Dec-20131.7K
MESA_shader_debug.spec06-Dec-20136.8K
MESA_swap_control.spec06-Dec-20133.2K
MESA_swap_frame_usage.spec06-Dec-20136.6K
MESA_texture_array.spec06-Dec-201335.5K
MESA_texture_signed_rgba.spec06-Dec-20138K
MESA_window_pos.spec06-Dec-20133.7K
MESA_ycbcr_texture.spec06-Dec-20136.5K
modelers.html06-Dec-20133.3K
news.html06-Dec-201351.7K
OLD/06-Dec-2013
opengles.html06-Dec-20132.1K
openvg.html06-Dec-20131.4K
osmesa.html06-Dec-20132.5K
patents.txt06-Dec-20131.4K
perf.html06-Dec-20132.8K
postprocess.html06-Dec-20131.6K
precompiled.html06-Dec-2013570
README.CYGWIN06-Dec-20139.9K
README.MITS06-Dec-20133.2K
README.QUAKE06-Dec-20136.5K
README.THREADS06-Dec-20131.7K
README.VMS06-Dec-20131.6K
README.WIN3206-Dec-20131.3K
RELNOTES-3.106-Dec-20133.8K
RELNOTES-3.206-Dec-2013313
RELNOTES-3.2.106-Dec-2013802
RELNOTES-3.306-Dec-20137.6K
RELNOTES-3.406-Dec-2013546
RELNOTES-3.4.106-Dec-2013584
RELNOTES-3.4.206-Dec-2013584
RELNOTES-3.506-Dec-20136.7K
RELNOTES-4.006-Dec-20134.3K
RELNOTES-4.0.106-Dec-2013564
RELNOTES-4.0.206-Dec-20131.4K
RELNOTES-4.0.306-Dec-20131.5K
RELNOTES-4.106-Dec-201310.5K
RELNOTES-5.006-Dec-20132.1K
RELNOTES-5.0.106-Dec-20131.3K
RELNOTES-5.0.206-Dec-20131.3K
RELNOTES-5.106-Dec-20139.7K
RELNOTES-6.006-Dec-20132.3K
RELNOTES-6.0.106-Dec-20131.4K
RELNOTES-6.106-Dec-20133.4K
RELNOTES-6.206-Dec-20131.3K
RELNOTES-6.2.106-Dec-20131.3K
RELNOTES-6.306-Dec-20133.2K
RELNOTES-6.3.106-Dec-20131K
RELNOTES-6.3.206-Dec-2013903
RELNOTES-6.406-Dec-20131.2K
relnotes-6.4.1.html06-Dec-20132.1K
relnotes-6.4.2.html06-Dec-20132K
relnotes-6.4.html06-Dec-20133K
relnotes-6.5.1.html06-Dec-20134.8K
relnotes-6.5.2.html06-Dec-20134.1K
relnotes-6.5.3.html06-Dec-20133.9K
relnotes-6.5.html06-Dec-20133.7K
relnotes-7.0.1.html06-Dec-20133K
relnotes-7.0.2.html06-Dec-20132.9K
relnotes-7.0.3.html06-Dec-20132.8K
relnotes-7.0.4.html06-Dec-20132.5K
relnotes-7.0.html06-Dec-20132.6K
relnotes-7.1.html06-Dec-20132.7K
relnotes-7.10.1.html06-Dec-201317K
relnotes-7.10.2.html06-Dec-20137.4K
relnotes-7.10.3.html06-Dec-201313.3K
relnotes-7.10.html06-Dec-2013152.8K
relnotes-7.11.1.html06-Dec-201317K
relnotes-7.11.2.html06-Dec-20132.5K
relnotes-7.11.html06-Dec-201321.6K
relnotes-7.2.html06-Dec-20133K
relnotes-7.3.html06-Dec-20132.6K
relnotes-7.4.1.html06-Dec-20132.4K
relnotes-7.4.2.html06-Dec-20132.2K
relnotes-7.4.3.html06-Dec-20132.4K
relnotes-7.4.4.html06-Dec-20131.8K
relnotes-7.4.html06-Dec-20132.5K
relnotes-7.5.1.html06-Dec-20132.4K
relnotes-7.5.2.html06-Dec-20132.1K
relnotes-7.5.html06-Dec-20133.7K
relnotes-7.6.1.html06-Dec-20132.7K
relnotes-7.6.html06-Dec-20133.3K
relnotes-7.7.1.html06-Dec-20131.9K
relnotes-7.7.html06-Dec-20132.3K
relnotes-7.8.1.html06-Dec-20132K
relnotes-7.8.2.html06-Dec-20135.3K
relnotes-7.8.3.html06-Dec-20133.1K
relnotes-7.8.html06-Dec-20132.2K
relnotes-7.9.1.html06-Dec-201319.3K
relnotes-7.9.2.html06-Dec-201314.8K
relnotes-7.9.html06-Dec-20139.7K
relnotes-8.0.1.html06-Dec-20135K
relnotes-8.0.2.html06-Dec-20135K
relnotes-8.0.3.html06-Dec-201312K
relnotes-8.0.4.html06-Dec-20137.4K
relnotes-8.0.html06-Dec-20132.6K
relnotes-9.0.1.html06-Dec-20135.1K
relnotes-9.0.2.html06-Dec-20139.9K
relnotes-9.0.3.html06-Dec-20139.8K
relnotes-9.0.html06-Dec-20132.8K
relnotes.html06-Dec-20134.4K
repository.html06-Dec-20135.7K
science.html06-Dec-20133.6K
shading.html06-Dec-20136.7K
sourcedocs.html06-Dec-20131.2K
sourcetree.html06-Dec-20136.8K
subset-A.html06-Dec-2013138.6K
subset.html06-Dec-2013667
systems.html06-Dec-20132.2K
thanks.html06-Dec-20134K
utilities.html06-Dec-20131K
utility.html06-Dec-20131.2K
VERSIONS06-Dec-201365.3K
versions.html06-Dec-201361.8K
viewperf.html06-Dec-20136.3K
vmware-guest.html06-Dec-20136.2K
webmaster.html06-Dec-2013765
WL_bind_wayland_display.spec06-Dec-20136.3K
xlibdriver.html06-Dec-20138.8K

README.CYGWIN

      1 
      2                           Mesa Cygwin/X11 Information
      3 
      4 
      5 WARNING
      6 =======
      7 
      8 If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the 
      9 latest setup.exe from Cygwin the GL (Mesa) libraries and include are already 
     10 installed in /usr/X11R6. 
     11 
     12 The following will explain how to "replace" them.
     13 
     14 Installation
     15 ============
     16 
     17 How to compile Mesa on Cygwin/X11 systems:
     18 
     19 1. Shared libs:
     20     type 'make cygwin-sl'.
     21 
     22     When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and 
     23     Mesa-x.y/bin directories.
     24 
     25 
     26 2. Static libs:
     27     type 'make cygwin-static'.
     28     When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory.
     29 
     30 Header and library files:
     31    After you've compiled Mesa and tried the demos I recommend the following
     32    procedure for "installing" Mesa.
     33 
     34    Copy the Mesa include/GL directory to /usr/X11R6/include:
     35 	cp -a include/GL /usr/X11R6/include
     36 
     37    Copy the Mesa library files to /usr/X11R6/lib:
     38 	cp -a lib/* /usr/X11R6ocal/lib
     39 
     40    Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin:
     41 	cp -a lib/cyg* /usr/X11R6/bin
     42 
     43 Xt/Motif widgets:
     44    If you want to use Mesa or OpenGL in your Xt/Motif program you can build
     45    the widgets found in either the widgets-mesa or widgets-sgi directories.
     46    The former were written for Mesa and the later are the original SGI
     47    widgets.  Look in those directories for more information.
     48    For the Motif widgets you must have downloaded the lesstif package.
     49 
     50 
     51 Using the library
     52 =================
     53 
     54 Configuration options:
     55    The file src/mesa/main/config.h has many parameters which you can adjust
     56    such as maximum number of lights, clipping planes, maximum texture size,
     57    etc.  In particular, you may want to change DEPTH_BITS from 16 to 32
     58    if a 16-bit depth buffer isn't precise enough for your application.
     59 
     60 
     61 Shared libraries:
     62    If you compile shared libraries (Win32 DLLS) you may have to set an 
     63    environment variable to specify where the Mesa libraries are located.  
     64    Set the PATH variable to include /your-dir/Mesa-2.6/bin.   
     65    Otherwise, when you try to run a demo it may fail with a message saying 
     66    that one or more DLL couldn't be found.
     67 
     68 
     69 Xt/Motif Widgets:
     70    Two versions of the Xt/Motif OpenGL drawing area widgets are included:
     71 
     72       widgets-sgi/	SGI's stock widgets
     73       widgets-mesa/	Mesa-tuned widgets
     74 
     75    Look in those directories for details
     76 
     77 
     78 Togl:
     79    Togl is an OpenGL/Mesa widget for Tcl/Tk.
     80    See http://togl.sourceforge.net for more information.
     81 
     82 
     83 
     84 X Display Modes:
     85    Mesa supports RGB(A) rendering into almost any X visual type and depth.
     86 
     87    The glXChooseVisual function tries its best to pick an appropriate visual
     88    for the given attribute list.  However, if this doesn't suit your needs
     89    you can force Mesa to use any X visual you want (any supported by your
     90    X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL
     91    environment variables.  When an RGB visual is requested, glXChooseVisual
     92    will first look if the MESA_RGB_VISUAL variable is defined.  If so, it
     93    will try to use the specified visual.  Similarly, when a color index
     94    visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL
     95    variable.
     96 
     97    The format of accepted values is:  <visual-class> <depth>
     98    Here are some examples:
     99 
    100    using the C-shell:
    101 	% setenv MESA_RGB_VISUAL "TrueColor 8"		// 8-bit TrueColor
    102 	% setenv MESA_CI_VISUAL "PseudoColor 12"	// 12-bit PseudoColor
    103 	% setenv MESA_RGB_VISUAL "PseudoColor 8"	// 8-bit PseudoColor
    104 
    105    using the KornShell:
    106 	$ export MESA_RGB_VISUAL="TrueColor 8"
    107 	$ export MESA_CI_VISUAL="PseudoColor 12"
    108 	$ export MESA_RGB_VISUAL="PseudoColor 8"
    109 
    110 
    111 Double buffering:
    112    Mesa can use either an X Pixmap or XImage as the backbuffer when in
    113    double buffer mode.  Using GLX, the default is to use an XImage.  The
    114    MESA_BACK_BUFFER environment variable can override this.  The valid
    115    values for MESA_BACK_BUFFER are:  Pixmap and XImage (only the first
    116    letter is checked, case doesn't matter).
    117 
    118    A pixmap is faster when drawing simple lines and polygons while an
    119    XImage is faster when Mesa has to do pixel-by-pixel rendering.  If you
    120    need depth buffering the XImage will almost surely be faster.  Exper-
    121    iment with the MESA_BACK_BUFFER variable to see which is faster for
    122    your application.  
    123 
    124 
    125 Colormaps:
    126    When using Mesa directly or with GLX, it's up to the application writer
    127    to create a window with an appropriate colormap.  The aux, tk, and GLUT
    128    toolkits try to minimize colormap "flashing" by sharing colormaps when
    129    possible.  Specifically, if the visual and depth of the window matches
    130    that of the root window, the root window's colormap will be shared by
    131    the Mesa window.  Otherwise, a new, private colormap will be allocated.
    132 
    133    When sharing the root colormap, Mesa may be unable to allocate the colors
    134    it needs, resulting in poor color quality.  This can happen when a
    135    large number of colorcells in the root colormap are already allocated.
    136    To prevent colormap sharing in aux, tk and GLUT, define the environment
    137    variable MESA_PRIVATE_CMAP.  The value isn't significant.
    138 
    139 
    140 Gamma correction:
    141    To compensate for the nonlinear relationship between pixel values
    142    and displayed intensities, there is a gamma correction feature in
    143    Mesa.  Some systems, such as Silicon Graphics, support gamma
    144    correction in hardware (man gamma) so you won't need to use Mesa's
    145    gamma facility.  Other systems, however, may need gamma adjustment
    146    to produce images which look correct.  If in the past you thought
    147    Mesa's images were too dim, read on.
    148 
    149    Gamma correction is controlled with the MESA_GAMMA environment
    150    variable.  Its value is of the form "Gr Gg Gb" or just "G" where
    151    Gr is the red gamma value, Gg is the green gamma value, Gb is the
    152    blue gamma value and G is one gamma value to use for all three
    153    channels.  Each value is a positive real number typically in the
    154    range 1.0 to 2.5.  The defaults are all 1.0, effectively disabling
    155    gamma correction.  Examples using csh:
    156 
    157 	% setenv MESA_GAMMA "2.3 2.2 2.4"	// separate R,G,B values
    158 	% setenv MESA_GAMMA "2.0"		// same gamma for R,G,B
    159 
    160    The demos/gamma.c program may help you to determine reasonable gamma
    161    value for your display.  With correct gamma values, the color intensities
    162    displayed in the top row (drawn by dithering) should nearly match those
    163    in the bottom row (drawn as grays).
    164 
    165    Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well
    166    on HP displays using the HP-ColorRecovery technology.
    167 
    168    Mesa implements gamma correction with a lookup table which translates
    169    a "linear" pixel value to a gamma-corrected pixel value.  There is a
    170    small performance penalty.  Gamma correction only works in RGB mode.
    171    Also be aware that pixel values read back from the frame buffer will
    172    not be "un-corrected" so glReadPixels may not return the same data
    173    drawn with glDrawPixels.
    174 
    175    For more information about gamma correction see:
    176    http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html
    177 
    178 
    179 Overlay Planes
    180 
    181    Overlay planes in the frame buffer are supported by Mesa but require
    182    hardware and X server support.  To determine if your X server has
    183    overlay support you can test for the SERVER_OVERLAY_VISUALS property:
    184 
    185 	xprop -root | grep SERVER_OVERLAY_VISUALS
    186 
    187 
    188 HPCR glClear(GL_COLOR_BUFFER_BIT) dithering
    189 
    190    If you set the MESA_HPCR_CLEAR environment variable then dithering
    191    will be used when clearing the color buffer.  This is only applicable
    192    to HP systems with the HPCR (Color Recovery) system.
    193 
    194 
    195 Extensions
    196 ==========
    197    There are three Mesa-specific GLX extensions at this time.
    198 
    199    GLX_MESA_pixmap_colormap 
    200 
    201       This extension adds the GLX function:
    202 
    203          GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual,
    204                                            Pixmap pixmap, Colormap cmap )
    205 
    206       It is an alternative to the standard glXCreateGLXPixmap() function.
    207       Since Mesa supports RGB rendering into any X visual, not just True-
    208       Color or DirectColor, Mesa needs colormap information to convert RGB
    209       values into pixel values.  An X window carries this information but a
    210       pixmap does not.  This function associates a colormap to a GLX pixmap.
    211       See the xdemos/glxpixmap.c file for an example of how to use this
    212       extension.
    213 
    214    GLX_MESA_release_buffers
    215 
    216       Mesa associates a set of ancillary (depth, accumulation, stencil and
    217       alpha) buffers with each X window it draws into.  These ancillary
    218       buffers are allocated for each X window the first time the X window
    219       is passed to glXMakeCurrent().  Mesa, however, can't detect when an
    220       X window has been destroyed in order to free the ancillary buffers.
    221 
    222       The best it can do is to check for recently destroyed windows whenever
    223       the client calls the glXCreateContext() or glXDestroyContext()
    224       functions.  This may not be sufficient in all situations though.
    225 
    226       The GLX_MESA_release_buffers extension allows a client to explicitly
    227       deallocate the ancillary buffers by calling glxReleaseBuffersMESA()
    228       just before an X window is destroyed.  For example:
    229 
    230          #ifdef GLX_MESA_release_buffers
    231             glXReleaseBuffersMESA( dpy, window );
    232          #endif
    233          XDestroyWindow( dpy, window );
    234 
    235       This extension is new in Mesa 2.0.
    236 
    237    GLX_MESA_copy_sub_buffer
    238 
    239       This extension adds the glXCopySubBufferMESA() function.  It works
    240       like glXSwapBuffers() but only copies a sub-region of the window
    241       instead of the whole window.
    242 
    243       This extension is new in Mesa version 2.6
    244 
    245 
    246 
    247 Summary of X-related environment variables:
    248    MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only)
    249    MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only)
    250    MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only)
    251    MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only)
    252    MESA_GAMMA - gamma correction coefficients (X only)
    253 
    254 
    255 ----------------------------------------------------------------------
    256 README.CYGWIN - lassauge April 2004 - based on README.X11
    257 

README.MITS

      1 
      2 			Mesa 3.0 MITS Information
      3 
      4 
      5 This software is distributed under the terms of the GNU Library
      6 General Public License, see the LICENSE file for details.
      7 
      8 
      9 This document is a preliminary introduction to help you get
     10 started. For more detaile information consult the web page.
     11 
     12 http://10-dencies.zkm.de/~mesa/
     13 
     14 
     15 
     16 Version 0.1 (Yes it's very alpha code so be warned!)
     17 Contributors: 
     18   Emil Briggs    	(briggs (a] bucky.physics.ncsu.edu)
     19   David Bucciarelli 	(tech.hmw (a] plus.it)
     20   Andreas Schiffler 	(schiffler (a] zkm.de)
     21 
     22 
     23 
     24 1. Requirements:
     25      Mesa 3.0.
     26      An SMP capable machine running Linux 2.x
     27      libpthread installed on your machine.
     28 
     29 
     30 2. What does MITS stand for?
     31      MITS stands for Mesa Internal Threading System. By adding
     32      internal threading to Mesa it should be possible to improve
     33      performance of OpenGL applications on SMP machines.
     34 
     35 
     36 3. Do applications have to be recoded to take advantage of MITS?
     37      No. The threading is internal to Mesa and transparent to
     38      applications.
     39 
     40 
     41 4. Will all applications benefit from the current implementation of MITS?
     42      No. This implementation splits the processing of the vertex buffer
     43      over two threads. There is a certain amount of overhead involved
     44      with the thread synchronization and if there is not enough work
     45      to be done the extra overhead outweighs any speedup from using
     46      dual processors. You will not for example see any speedup when
     47      running Quake because it uses GL_POLYGON and there is only one
     48      polygon for each vertex buffer processed. Test results on a
     49      dual 200 Mhz. Pentium Pro system show that one needs around
     50      100-200 vertices in the vertex buffer before any there is any
     51      appreciable benefit from the threading.
     52 
     53 
     54 5. Are there any parameters that I can tune to try to improve performance.
     55      Yes. You can try to vary the size of the vertex buffer which is
     56      define in VB_MAX located in the file src/vb.h from your top level
     57      Mesa distribution. The number needs to be a multiple of 12 and
     58      the optimum value will probably depend on the capabilities of
     59      your machine and the particular application you are running.
     60 
     61 
     62 6. Are there any ways I can modify the application to improve its
     63    performance with the MITS?
     64      Yes. Try to use as many vertices between each Begin/End pair
     65      as possbile. This will reduce the thread synchronization
     66      overhead.
     67 
     68 
     69 7. What sort of speedups can I expect?
     70      On some benchmarks performance gains of up to 30% have been
     71      observerd. Others may see no gain at all and in a few rare
     72      cases even some degradation.
     73 
     74 
     75 8. What still needs to be done?
     76      Lots of testing and benchmarking.
     77      A portable implementation that works within the Mesa thread API.
     78      Threading of additional areas of Mesa to improve performance
     79      even more.
     80 
     81 
     82 
     83 Installation:
     84 
     85    1. This assumes that you already have a working Mesa 3.0 installation
     86       from source.
     87    2. Place the tarball MITS.tar.gz in your top level Mesa directory.
     88    3. Unzip it and untar it. It will replace the following files in
     89       your Mesa source tree so back them up if you want to save them.
     90 
     91 
     92 	 README.MITS
     93          Make-config
     94 	 Makefile
     95 	 mklib.glide
     96          src/vbxform.c
     97 	 src/vb.h
     98 
     99    4. Rebuild Mesa using the command
    100 
    101           make linux-386-glide-mits
    102 
    103 

README.QUAKE

      1 
      2              Info on using Mesa 3.0 with Linux Quake I and Quake II
      3 
      4 
      5 
      6 Disclaimer
      7 ----------
      8 
      9 I am _not_ a Quake expert by any means.  I pretty much only run it to
     10 test Mesa.  There have been a lot of questions about Linux Quake and
     11 Mesa so I'm trying to provide some useful info here.  If this file
     12 doesn't help you then you should look elsewhere for help.  The Mesa
     13 mailing list or the news://news.3dfx.com/3dfx.linux.glide newsgroup
     14 might be good.
     15 
     16 Again, all the information I have is in this file.  Please don't email
     17 me with questions.
     18 
     19 If you have information to contribute to this file please send it to
     20 me at brianp (a] elastic.avid.com
     21 
     22 
     23 
     24 Linux Quake
     25 -----------
     26 
     27 You can get Linux Quake from http://www.idsoftware.com/
     28 
     29 Quake I and II for Linux were tested with, and include, Mesa 2.6.  You
     30 shouldn't have too many problems if you simply follow the instructions
     31 in the Quake distribution.
     32 
     33 
     34 
     35 RedHat 5.0 Linux problems
     36 -------------------------
     37 
     38 RedHat Linux 5.x uses the GNU C library ("glibc" or "libc6") whereas
     39 previous RedHat and other Linux distributions use "libc5" for its
     40 runtime C library.
     41 
     42 Linux Quake I and II were compiled for libc5.  If you compile Mesa
     43 on a RedHat 5.x system the resulting libMesaGL.so file will not work
     44 with Linux Quake because of the different C runtime libraries.
     45 The symptom of this is a segmentation fault soon after starting Quake.
     46 
     47 If you want to use a newer version of Mesa (like 3.x) with Quake on
     48 RedHat 5.x then read on.
     49 
     50 The solution to the C library problem is to force Mesa to use libc5.
     51 libc5 is in /usr/i486-linux-libc5/lib on RedHat 5.x systems.
     52 
     53 Emil Briggs (briggs (a] tick.physics.ncsu.edu) nicely gave me the following
     54 info:
     55 
     56 >   I only know what works on a RedHat 5.0 distribution. RH5 includes
     57 > a full set of libraries for both libc5 and glibc. The loader ld.so
     58 > uses the libc5 libraries in /usr/i486-linux-libc5/lib for programs
     59 > linked against libc5 while it uses the glibc libraries in /lib and
     60 > /usr/lib for programs linked against glibc.
     61 > 
     62 > Anyway I changed line 41 of mklib.glide to
     63 >     GLIDELIBS="-L/usr/local/glide/lib -lglide2x -L/usr/i486-linux-libc5/lib"
     64 > 
     65 > And I started quake2 up with a script like this
     66 > #!/bin/csh
     67 > setenv LD_LIBRARY_PATH /usr/i486-linux-libc5/lib
     68 > setenv MESA_GLX_FX f
     69 > ./quake2 +set vid_ref gl
     70 > kbd_mode -a
     71 > reset
     72 
     73 
     74 I've already patched the mklib.glide file.  You'll have to start Quake
     75 with the script shown above though.
     76 
     77 
     78 
     79 **********************
     80 
     81 Daryll Strauss writes:
     82 
     83 Here's my thoughts on the problem. On a RH 5.x system, you can NOT build
     84 a libc5 executable or library. Red Hat just doesn't include the right
     85 stuff to do it.
     86 
     87 Since Quake is a libc5 based application, you are in trouble. You need
     88 libc5 libraries.
     89 
     90 What can you do about it? Well there's a package called gcc5 that does
     91 MOST of the right stuff to compile with libc5. (It brings back older
     92 header files, makes appropriate symbolic links for libraries, and sets
     93 up the compiler to use the correct directories) You can find gcc5 here: 
     94 ftp://ecg.mit.edu/pub/linux/gcc5-1.0-1.i386.rpm
     95 
     96 No, this isn't quite enough. There are still a few tricks to getting
     97 Mesa to compile as a libc5 application. First you have to make sure that
     98 every compile uses gcc5 instead of gcc. Second, in some cases the link
     99 line actually lists -L/usr/lib which breaks gcc5 (because it forces you
    100 to use the glibc version of things)
    101 
    102 If you get all the stuff correctly compiled with gcc5 it should work.
    103 I've run Mesa 3.0B6  and its demos in a window with my Rush on a Red Hat
    104 5.1 system. It is a big hassle, but it can be done. I've only made Quake
    105 segfault, but I think that's from my libRush using the wrong libc. 
    106 
    107 Yes, mixing libc5 and glibc is a major pain. I've been working to get
    108 all my libraries compiling correctly with this setup. Someone should
    109 make an RPM out of it and feed changes back to Brian once they get it
    110 all working. If no one else has done so by the time I get the rest of my
    111 stuff straightened out, I'll try to do it myself.
    112 
    113 							- |Daryll
    114 
    115 
    116 
    117 *********************
    118 
    119 David Bucciarelli (tech.hmw (a] plus.it) writes:
    120 
    121 I'm using the Mesa-3.0beta7 and the RedHat 5.1 and QuakeII is
    122 working fine for me.  I had only to make a small change to the
    123 Mesa-3.0/mklib.glide file, from:
    124 
    125 
    126     GLIDELIBS="-L/usr/local/glide/lib -lglide2x
    127 -L/usr/i486-linux-libc5/lib -lm"
    128 
    129 to:
    130 
    131     GLIDELIBS="-L/usr/i486-linux-libc5/lib -lglide2x"
    132 
    133 and to make two symbolic links:
    134 
    135 [david@localhost Mesa]$ ln -s libMesaGL.so libMesaGL.so.2
    136 [david@localhost Mesa]$ ln -s libMesaGLU.so libMesaGLU.so.2
    137 
    138 I'm using the Daryll's Linux glide rpm for the Voodoo2 and glibc (it
    139 includes also the Glide for the libc5). I'm not using the /dev/3Dfx and
    140 running QuakeII as root with the following env. var:
    141 
    142 export
    143 LD_LIBRARY_PATH=/dsk1/home/david/src/gl/Mesa/lib:/usr/i486-linux-libc5/lib
    144 
    145 I think that all problems are related to the glibc, Quake will never
    146 work if you get the following output:
    147 
    148 [david@localhost Mesa]$ ldd lib/libMesaGL.so
    149         libglide2x.so => /usr/lib/libglide2x.so (0x400f8000)
    150         libm.so.6 => /lib/libm.so.6 (0x40244000)
    151         libc.so.6 => /lib/libc.so.6 (0x4025d000)
    152         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
    153 
    154 You must get the following outputs:
    155 
    156 [david@localhost Mesa]# ldd lib/libMesaGL.so
    157         libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
    158 (0x400f3000)
    159 
    160 [root@localhost quake2]# ldd quake2
    161         libdl.so.1 => /lib/libdl.so.1 (0x40005000)
    162         libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x40008000)
    163         libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x40010000)
    164 
    165 [root@localhost quake2]# ldd ref_gl.so
    166         libMesaGL.so.2 =>
    167 /dsk1/home/david/src/gl/Mesa/lib/libMesaGL.so.2 (0x400eb000)
    168         libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so
    169 (0x401d9000)
    170         libX11.so.6 => /usr/i486-linux-libc5/lib/libX11.so.6
    171 (0x40324000)
    172         libXext.so.6 => /usr/i486-linux-libc5/lib/libXext.so.6
    173 (0x403b7000)
    174         libvga.so.1 => /usr/i486-linux-libc5/lib/libvga.so.1
    175 (0x403c1000)
    176         libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x403f5000)
    177         libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x403fd000)
    178 
    179 
    180 ***********************
    181 
    182 Steve Davies (steve (a] one47.demon.co.uk) writes:
    183 
    184 
    185 Try using:
    186 
    187     export LD_LIBRARY_PATH=/usr/i486-linux-libc5/lib
    188     ./quake2 +set vid_ref gl
    189 
    190 to start the game... Works for me, but assumes that you have the
    191 compatability libc5 RPMs installed.
    192 
    193 
    194 ***************************
    195 
    196 WWW resources - you may find additional Linux Quake help at these URLs:
    197 
    198 
    199 http://quake.medina.net/howto
    200 
    201 http://webpages.mr.net/bobz
    202 
    203 http://www.linuxgames.com/quake2/
    204 
    205 
    206 
    207 ----------------------------------------------------------------------
    208 

README.THREADS

      1 
      2 
      3 Mesa Threads README
      4 -------------------
      5 
      6 Thread safety was introduced in Mesa 2.6 by John Stone and
      7 Christoph Poliwoda.
      8 
      9 It was redesigned in Mesa 3.3 so that thread safety is
     10 supported by default (on systems which support threads,
     11 that is).  There is no measurable penalty on single
     12 threaded applications.
     13 
     14 NOTE that the only _driver_ which is thread safe at this time
     15 is the OS/Mesa driver!
     16 
     17 
     18 At present the mthreads code supports three thread APIS:
     19   1) POSIX threads (aka pthreads).
     20   2) Solaris / Unix International threads.
     21   3) Win32 threads (Win 95/NT).
     22 
     23 Support for other thread libraries can be added src/glthread.[ch]
     24 
     25 
     26 In order to guarantee proper operation, it is
     27 necessary for both Mesa and application code to use the same threads API.
     28 So, if your application uses Sun's thread API, then you should build Mesa
     29 using one of the targets for Sun threads.
     30 
     31 The mtdemos directory contains some example programs which use 
     32 multiple threads to render to osmesa rendering context(s).
     33 
     34 Linux users should be aware that there exist many different POSIX
     35 threads packages. The best solution is the linuxthreads package
     36 (http://pauillac.inria.fr/~xleroy/linuxthreads/) as this package is the
     37 only one that really supports multiprocessor machines (AFAIK). See
     38 http://pauillac.inria.fr/~xleroy/linuxthreads/README for further
     39 information about the usage of linuxthreads.
     40 
     41 If you are interested in helping with thread safety work in Mesa
     42 join the Mesa developers mailing list and post your proposal.
     43 
     44 
     45 Regards,
     46   John Stone           -- j.stone (a] acm.org  johns (a] cs.umr.edu
     47   Christoph Poliwoda   -- poliwoda (a] volumegraphics.com
     48 
     49 
     50 Version info:
     51    Mesa 2.6 - initial thread support.
     52    Mesa 3.3 - thread support mostly rewritten (Brian Paul)
     53 

README.VMS

      1 
      2 VMS support contributed by Jouk Jansen (joukj (a] hrem.stm.tudelft.nl)
      3 
      4 
      5 The latest version was tested on a VMSAlpha7.2 system using DECC6.0, but
      6 probably also works for other versions.
      7 
      8 At the moment only the libraries LIBMESGL.EXE/LIBMESGL.OLB,
      9 LIBMESAGLU.EXE/LIBMESAGLU.OLB and LIBGLUT.EXE/LIBGLUT.OLB and the demos of the
     10 directory [.DEMOS] can be build.
     11 However, feel free to create the missing "decrip.mms-files" in the other
     12 directories.
     13 
     14  The make files were tested
     15 using the DIGITAL make utility called MMS.  There is also a public domain
     16 clone available (MMK) and I  think, but it is not tested, that this
     17 utility will give (hardly) any problem.
     18 
     19 To make everything just type MMS (or MMK) in the main directory of
     20 mesagl.  For MMS the deafult makefile is called descrip.mms, and
     21 that is what I have called it.  I included alse some config files,
     22 all having mms somewhere in the name which all the makefiles need
     23 (just as your unix makefiles).
     24 
     25 On Alpha platforms at default a sharable images for the libraries are created.
     26 To get a static library make it by typing MMS/MACRO=(NOSHARE=1).
     27 On VAX platforms only static libraries can be build.
     28 
     29 23-sep-2005
     30 changed default compilation to use /float=ieee/ieee=denorm. The reason for 
     31 this is that it makes Mesa on OpenVMS better compatible with other platforms
     32 and other packages for VMS that I maintain.
     33 For more information see
     34       http://nchrem.tnw.tudelft.nl/openvms
     35       https://bugs.freedesktop.org/show_bug.cgi?id=4270
     36 You may want to compile Mesa to use VAX-floating point arithmetic, instead
     37 of IEEE floating point by removing the /float=IEEE/denorm flag from the
     38 compiler options in the descrip.mms files.
     39 

README.WIN32

      1 File: docs/README.WIN32
      2 
      3 Last updated: 23 April 2011
      4 
      5 
      6 Quick Start
      7 ----- -----
      8 
      9 Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
     10 no longer shipped or supported.
     11 
     12 Run
     13 
     14   scons osmesa mesagdi
     15 
     16 to build classic mesa Windows GDI drivers; or
     17 
     18   scons libgl-gdi
     19 
     20 to build gallium based GDI driver.
     21 
     22 This will work both with MSVS or Mingw.
     23 
     24 
     25 Windows Drivers
     26 ------- -------
     27 
     28 At this time, only the gallium GDI driver is known to work.
     29 
     30 Source code also exists in the tree for other drivers in
     31 src/mesa/drivers/windows, but the status of this code is unknown.
     32 
     33 
     34 General
     35 -------
     36 
     37 After building, you can copy the above DLL files to a place in your
     38 PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things
     39 in a system directory, place them in the same directory as the
     40 executable(s).  Be careful about accidentially overwriting files of
     41 the same name in the SYSTEM32 directory.
     42 
     43 The DLL files are built so that the external entry points use the
     44 stdcall calling convention.
     45 
     46 Static LIB files are not built.  The LIB files that are built with are
     47 the linker import files associated with the DLL files.
     48 
     49 The si-glu sources are used to build the GLU libs.  This was done
     50 mainly to get the better tessellator code.
     51 
     52 If you have a Windows-related build problem or question, please post
     53 to the mesa-dev or mesa-users list.
     54