<head><title>Mesa FAQ</title></head>
-<BODY text="#000000" bgcolor="#55bbff" link="#111188">
+<link rel="stylesheet" type="text/css" href="mesa.css"></head>
+
+<BODY>
<center>
<h1>Mesa Frequently Asked Questions</h1>
-Last updated: 26 November 2003
+Last updated: 21 August 2006
</center>
<br>
information.
</p>
<p>
-Mesa 5.x supports the OpenGL 1.4 specification.
+Mesa 6.x supports the OpenGL 1.5 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
-XFree86/DRI OpenGL drivers. See the <a href="http://dri.sf.net/">DRI
+Yes. Specifically, Mesa serves as the OpenGL core for the open-source DRI
+drivers for XFree86/X.org. See the <a href="http://dri.freedesktop.org/">DRI
website</a> for more information.
</p>
<p>
are the modern ones.
</p>
-<h2>1.3 What purpose does Mesa (software-based rendering) serve today?</h2>
+<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 XFree86/DRI hardware drivers.
+<li>Mesa is used as the core of the open-source XFree86/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>
</ul>
-<h2>1.4 How do I upgrade my DRI installation to use a new Mesa release?</h2>
+
+<h2>1.4 What's the difference between"Stand-Alone" Mesa and the DRI drivers?</h2>
<p>
-You don't! A copy of the Mesa source code lives inside the XFree86/DRI source
-tree and gets compiled into the individual DRI driver modules.
-If you try to install Mesa over an XFree86/DRI installation, you'll lose
-hardware rendering (because stand-alone Mesa's libGL.so is different than
-the XFree86 libGL.so).
+<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:
+<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>
<p>
-The DRI developers will incorporate the latest release of Mesa into the
-DRI drivers when the time is right.
-</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>
-To upgrade, either look for a new release of <a href="http://www.xfree86.org"
-target="_parent">XFree86</a> or visit the
-<a href="http://dri.sf.net" target="_parent">DRI website</a> to see
-if there's newer drivers.
+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.5 Are there other open-source implementations of OpenGL?</h2>
+<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"
target="_parent">
Unfortunately, development of the SI has stagnated.
Mesa is much more up to date with modern features and extensions.
</p>
+
+<p>
+<a href="http://ogl-es.sourceforge.net" target="_parent">Vincent</a> is
+an open-source implementation of OpenGL ES for mobile devices.
+
<p>
<a href="http://www.dsbox.com/minigl.html" target="_parent">miniGL</a>
is a subset of OpenGL for PalmOS devices.
rendering, etc.
</p>
+<p>
+<a href="http://www.ticalc.org/archives/files/fileinfo/361/36173.html"
+target="_parent">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>
</a></p>
-<h2><a name="part2">2.2 Running <code>configure; make</code> Doesn't Work</a></h2>
-<p>
-<a name="part2">Unfortunately, the GNU autoconf/automake/libtool system doesn't seem to work
-too well on non GNU/Linux systems, even after installing gmake, gcc, etc.
-For that reason, Mesa's <b>old-style</b> makefile system is still included.
-The old-style system uses good old traditional Makefiles. Try the following:
-</a></p><pre><a name="part2"> cd Mesa-x.y.z
- cp Makefile.X11 Makefile
- make
-</a></pre>
-<a name="part2">You'll see a list of system configurations from which to choose.
-For example:
-</a><pre><a name="part2"> make linux-x86
-</a></pre>
-<p>
-<a name="part2">If you're experienced with GNU autoconf/automake/libtool and think you can help
-with maintence, contact the Mesa developers.
-FYI, the Mesa developers generally don't use the autoconf/automake system.
-We're especially annoyed with the fact that a +5000-line script (libtool)
-is needed to make shared libraries (ugh).
-</a></p>
-
-<h2><a name="part2">2.3 Mesa still doesn't compile</a></h2>
-<p>
-<a name="part2">If the old-style Makefile system doesn't work either, make sure you have
-the most recent version of Mesa.
-Otherwise, file a bug report or post to the Mesa3d-users mailing list.
-Give as much info as possible when describing your problem.
-</a></p>
-
-
-<h2><a name="part2">2.4 I get undefined symbols such as bgnpolygon, v3f, etc...</a></h2>
+<h2><a name="part2">2.2 I get undefined symbols such as bgnpolygon, v3f, etc...</a></h2>
<p>
<a name="part2">You're application is written in IRIS GL, not OpenGL.
IRIS GL was the predecessor to OpenGL and is a different thing (almost)
</a></p>
-<h2><a name="part2">2.5 Where is the GLUT library?</a></h2>
+<h2><a name="part2">2.3 Where is the GLUT library?</a></h2>
<p>
-<a name="part2">GLUT (OpenGL Utility Toolkit) is in the separate MesaDemos-x.y.z.tar.gz file.
-If you don't already have GLUT installed, you should grab the MesaDemos
-package and unpack it before compiling Mesa.
+<a name="part2">GLUT (OpenGL Utility Toolkit) is in the separate MesaGLUT-x.y.z.tar.gz file.
+If you don't already have GLUT installed, you should grab the MesaGLUT
+package and compile it with the rest of Mesa.
</a></p>
-<h2><a name="part2">2.6 What's the proper place for the libraries and headers?</a></h2>
+<h2><a name="part2">2.4 What's the proper place for the libraries and headers?</a></h2>
<p>
<a name="part2">On Linux-based systems you'll want to follow the
-</a><a href="http://oss.sgi.com/projects/ogl-sample/ABI/index.html">Linux ABI</a>
-standard.
+</a><a href="http://oss.sgi.com/projects/ogl-sample/ABI/index.html"
+target="_parent">Linux ABI</a> standard.
Basically you'll want the following:
</p>
<ul>
version number.
</li></ul>
<p>
-After installing XFree86 and the DRI drivers, some of these files
+After installing XFree86/X.org and the DRI drivers, some of these files
may be symlinks into the /usr/X11R6/ tree.
</p>
<p>
</a></p>
<p>
<a name="part3">If your DRI-based driver isn't working, go to the
-</a><a href="http://dri.sf.net/">DRI website</a> for trouble-shooting information.
+</a><a href="http://dri.sf.net/" target="_parent">DRI website</a> for trouble-shooting information.
</p>
<p>
Make sure the ratio of the far to near clipping planes isn't too great.
Look
-<a href="http://www.sgi.com/software/opengl/advanced97/notes/node18.html">
-here</a> for details.
+<a href="http://www.opengl.org/resources/faq/technical/depthbuffer.htm#0040"
+target="_parent"> here</a> for details.
</p>
<p>
Mesa uses a 16-bit depth buffer by default which is smaller and faster
will fix the problem.
</p>
+<h2>3.6 How can I change the maximum framebuffer size in Mesa's
+<tt>swrast</tt> backend?</h2>
+<p>
+These can be overridden by using the <tt>--with-max-width</tt> and
+<tt>--with-max-height</tt> options. The two need not be equal.
+</p><p>
+Do note that Mesa uses these values to size some internal buffers,
+so increasing these sizes will cause Mesa to require additional
+memory. Furthermore, increasing these limits beyond <tt>4096</tt>
+may introduce rasterization artifacts; see the leading comments in
+<tt>src/mesa/swrast/s_tritemp.h</tt>.
+</p>
+
<br>
<br>
<a name="part4">
</a><h1><a name="part4">4. Developer Questions</a></h1>
-<h2><a name="part4">4.1 How can I contribute?</a></h2>
+<h2>4.1 How can I contribute?</a></h2>
<p>
-<a name="part4">First, join the Mesa3d-dev mailing list. That's where Mesa development
-is discussed.
-</a></p>
+First, join the <a href="http://www.mesa3d.org/lists.html">Mesa3d-dev
+mailing list</a>.
+That's where Mesa development is discussed.
+</p>
<p>
-<a name="part4">The </a><a href="http://www.opengl.org/developers/documentation/specs.html">
+The <a href="http://www.opengl.org/documentation" target="_parent">
OpenGL Specification</a> is the bible for OpenGL implemention work.
You should read it.
</p>
</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" target="_parent">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 unsucessful 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://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html"
+target="_parent">plug-in library</a> is available.
+</p>
+
+
</body>
</html>