2006-11-25 11:49:17 -07:00
|
|
|
<html>
|
|
|
|
|
|
|
|
|
|
<head><title>Mesa FAQ</title></head>
|
|
|
|
|
|
|
|
|
|
<link rel="stylesheet" type="text/css" href="mesa.css"></head>
|
|
|
|
|
|
|
|
|
|
<BODY>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<center>
|
|
|
|
|
<h1>Mesa Frequently Asked Questions</h1>
|
|
|
|
|
Last updated: 21 August 2006
|
|
|
|
|
</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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<a name="part1">
|
|
|
|
|
</a><h1><a name="part1">1. High-level Questions and Answers</a></h1>
|
|
|
|
|
|
|
|
|
|
<h2><a name="part1">1.1 What is Mesa?</a></h2>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part1">Mesa is an open-source implementation of the OpenGL specification.
|
|
|
|
|
OpenGL is a programming library for writing interactive 3D applications.
|
|
|
|
|
See the </a><a href="http://www.opengl.org/">OpenGL website</a> for more
|
|
|
|
|
information.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
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 DRI
|
|
|
|
|
drivers for XFree86/X.org. See the <a href="http://dri.freedesktop.org/">DRI
|
|
|
|
|
website</a> for more information.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
There have been other hardware drivers for Mesa over the years (such as
|
|
|
|
|
the 3Dfx Glide/Voodoo driver, an old S3 driver, etc) but the DRI drivers
|
|
|
|
|
are the modern ones.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<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/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:
|
|
|
|
|
<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>
|
|
|
|
|
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"
|
|
|
|
|
target="_parent">
|
|
|
|
|
OpenGL Sample Implemenation (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://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.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://fabrice.bellard.free.fr/TinyGL/"
|
|
|
|
|
target="_parent">TinyGL</a> is a subset of OpenGL.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://softgl.studierstube.org/" target="_parent">SoftGL</a>
|
|
|
|
|
is an OpenGL subset for mobile devices.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://chromium.sourceforge.net/" target="_parent">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"
|
|
|
|
|
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 name="part2">
|
|
|
|
|
</a><h1><a name="part2">2. Compilation and Installation Problems</a></h1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h2><a name="part2">2.1 What's the easiest way to install Mesa?</a></h2>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part2">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.
|
|
|
|
|
</a></p>
|
|
|
|
|
|
|
|
|
|
|
2008-11-02 07:58:06 -07:00
|
|
|
<h2><a name="part2">2.2 I get undefined symbols such as bgnpolygon, v3f, etc...</a></h2>
|
2006-11-25 11:49:17 -07:00
|
|
|
<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)
|
|
|
|
|
entirely.
|
|
|
|
|
Mesa's not the solution.
|
|
|
|
|
</a></p>
|
|
|
|
|
|
|
|
|
|
|
2008-11-02 07:58:06 -07:00
|
|
|
<h2><a name="part2">2.3 Where is the GLUT library?</a></h2>
|
2006-11-25 11:49:17 -07:00
|
|
|
<p>
|
|
|
|
|
<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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-02 07:58:06 -07:00
|
|
|
<h2><a name="part2">2.4 What's the proper place for the libraries and headers?</a></h2>
|
2006-11-25 11:49:17 -07:00
|
|
|
<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"
|
|
|
|
|
target="_parent">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><li>/usr/lib/libGLU.so - a symlink to libGLU.so.1
|
|
|
|
|
</li><li>/usr/lib/libGLU.so.1 - a symlink to libGLU.so.1.3.xyz
|
|
|
|
|
</li><li>/usr/lib/libGLU.so.xyz - the OpenGL Utility library. xyz denotes the Mesa
|
|
|
|
|
version number.
|
|
|
|
|
</li></ul>
|
|
|
|
|
<p>
|
|
|
|
|
After installing XFree86/X.org and the DRI drivers, some of these files
|
|
|
|
|
may be symlinks into the /usr/X11R6/ tree.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
The old-style Makefile system doesn't install the Mesa libraries; it's
|
|
|
|
|
up to you to copy them (and the headers) to the right place.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
The GLUT header and library should go in the same directories.
|
|
|
|
|
</p>
|
|
|
|
|
<br>
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<a name="part3">
|
|
|
|
|
</a><h1><a name="part3">3. Runtime / Rendering Problems</a></h1>
|
|
|
|
|
|
|
|
|
|
<h2><a name="part3">3.1 Rendering is slow / why isn't my graphics hardware being used?</a></h2>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part3">Stand-alone Mesa (downloaded as MesaLib-x.y.z.tar.gz) doesn't have any
|
|
|
|
|
support for hardware acceleration (with the exception of the 3DFX Voodoo
|
|
|
|
|
driver).
|
|
|
|
|
</a></p>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part3">What you really want is a DRI or NVIDIA (or another vendor's OpenGL) driver
|
|
|
|
|
for your particular hardware.
|
|
|
|
|
</a></p>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part3">You can run the <code>glxinfo</code> program to learn about your OpenGL
|
|
|
|
|
library.
|
|
|
|
|
Look for the GL_VENDOR and GL_RENDERER values.
|
|
|
|
|
That will identify who's OpenGL library you're using and what sort of
|
|
|
|
|
hardware it has detected.
|
|
|
|
|
</a></p>
|
|
|
|
|
<p>
|
|
|
|
|
<a name="part3">If your DRI-based driver isn't working, go to the
|
|
|
|
|
</a><a href="http://dri.sf.net/" target="_parent">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"
|
|
|
|
|
target="_parent"> 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>
|
|
|
|
|
|
2010-05-22 14:05:42 -06:00
|
|
|
<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>
|
|
|
|
|
|
2006-11-25 11:49:17 -07:00
|
|
|
<br>
|
|
|
|
|
<br>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<a name="part4">
|
|
|
|
|
</a><h1><a name="part4">4. Developer Questions</a></h1>
|
|
|
|
|
|
|
|
|
|
<h2>4.1 How can I contribute?</a></h2>
|
|
|
|
|
<p>
|
2008-05-31 10:36:47 -06:00
|
|
|
First, join the <a href="http://www.mesa3d.org/lists.html">Mesa3d-dev
|
2006-11-25 11:49:17 -07:00
|
|
|
mailing list</a>.
|
|
|
|
|
That's where Mesa development is discussed.
|
2008-11-02 07:58:06 -07:00
|
|
|
</p>
|
2006-11-25 11:49:17 -07:00
|
|
|
<p>
|
2008-11-02 07:58:06 -07:00
|
|
|
The <a href="http://www.opengl.org/documentation" target="_parent">
|
2006-11-25 11:49:17 -07:00
|
|
|
OpenGL Specification</a> is the bible for OpenGL implemention 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 software driver, the X11 and OSMesa drivers are good examples.
|
|
|
|
|
For a hardware driver, the Radeon and R200 DRI drivers 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 seldome 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" 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>
|
