DRI User Guide
: General Limitations and Known Bugs
Previous: Hardware-Specific Information and Troubleshooting
Next: Resources
11. General Limitations and Known Bugs
11.1. OpenGL
The following OpenGL features are not supported at this time:
overlays, stereo, hardware-accelerated indirect rendering.
OpenGL-like functionality is provided with the Mesa library.
XFree86 4.1.0 uses Mesa 3.4.2.
Subsequent releases of XFree86 will use newer versions of Mesa.
When newer versions of Mesa are available, the 3D drivers can
be updated without reinstalling XFree86 or libGL.so.
11.2. GLX
The GLX 1.3 API is exported but none of the new 1.3 functions
are operational.
The new glXGetProcAddressARB function is fully supported.
GLXPixmap rendering is only supported for indirect rendering
contexts. This is a common OpenGL limitation. Attempting
to use a direct rendering context with a GLXPixmap will result
in an X protocol error.
11.3. Debugging
Debugging DRI drivers with gdb can be difficult because of the
locking involved. When debugging OpenGL applications, you should
avoid stepping inside the GL functions. If you're trying to debug
a DRI driver it's recommended that you do so remotely, from a
second system.
11.4. Scheduling
When you run multiple GL applications at once you may notice poor
time slicing.
This is due to an interaction problem with the Linux scheduler
which will be addressed in the future.
11.5. libGL.so and dlopen()
A number of popular OpenGL applications on Linux (such as Quake3,
HereticII, Heavy Gear 2, etc) dynamically open the libGL.so
library at runtime with dlopen(), rather than linking with -lGL
at compile/link time.
If dynamic loading of libGL.so is not implemented carefully, there
can be a number of serious problems.
Here are the things to be careful of in your application:
- Specify the RTLD_GLOBAL flag to dlopen().
If you don't do this then you'll likely see a runtime error message
complaining that _glapi_Context is undefined when libGL.so
tries to open a hardware-specific driver.
Without this flag, nested opening of dynamic libraries
does not work.
- Do not close the library with dlclose() until after
XCloseDisplay() has been called.
When libGL.so initializes itself it registers several callbacks
functions with Xlib.
When XCloseDisplay() is called those callback functions are
called.
If libGL.so has already been unloaded with dlclose() this will
cause a segmentation fault.
- Your application should link with -lpthread.
On Linux, libGL.so uses the pthreads library in order to provide
thread safety.
There is apparently a bug in the dlopen()/dlclose() code which
causes crashes if the library uses pthreads but the parent
application doesn't.
The only known work-around is to link the application with
-lpthread.
Some applications don't yet incorporate these procedures and
may fail.
For example, changing the graphics settings in some video games
will expose this problem.
The DRI developers are working with game vendors to prevent this
problem in the future.
11.6. Bug Database
The DRI bug database which includes bugs related to specific
drivers is at the
SourceForge DRI Bug Database
Please scan both the open and closed bug lists to determine if your
problem has already been reported and perhaps fixed.
DRI User Guide
: General Limitations and Known Bugs
Previous: Hardware-Specific Information and Troubleshooting
Next: Resources
|
