Testing And Debugging
How do you put a breakpoint in the dynamically loaded modules?
You need xfree86-gdb -- a version of gdb modified to understand the module binary format that XFree86 uses in addition to the standard elf/coff binary formats.
Type:
module mach64_drv.o mach64_dri.o
after starting the debugger to load symbols, etc.
How do I do benchmarking with Unreal Tournament?
Start a practice level. Type timedemo 1 in the console or in alternative select the Tools > TimeDemo Statistic menu entry.
You should see two numbers in white text on the right side of the screen showing the average framerate (Avg) and the number of frame rates in the last second (Last Sec). If this doesn't work check whether the stats get reported in your ~/.loki/ut/System/UnrealTournament.log file.
Is there any way for us to detect which features are implemented with hardware support for a given driver?
OpenGL doesn't have such a query. This is a potential problem with any OpenGL implementation. The real question one wants answered is "is this feature or GL state combination fast enough for my needs?". Whether a feature is implemented in hardware or software isn't always consistent with that question.
You might consider implementing a benchmark function to test the speed during start-up and making a decision depending on the result. The info could be cached in a file keyed by GL_RENDERER.
Check isfast
Which OpenGL benchmarking program can I use to test and compare various facets of the performance of graphics cards?
- Games. You can use OpenGL games such as Quake 3, Unreal Tournament, etc.
SPECviewperf is a portable OpenGL performance benchmark program written in C providing a vast amount of flexibility in benchmarking OpenGL performance.
SPECglperf is an executable toolkit that measures the performance of OpenGL 2D and 3D graphics operations. These operations are low-level primitives (points, lines, triangles, pixels, etc.) rather than entire models.
glean is a suite of tools for evaluating the quality of an OpenGL implementation and diagnosing any problems that are discovered. It also has the ability to compare two OpenGL implementations and highlight the differences between them.
machtest is a thorough benchmark for graphics cards. It has literally thousands of command line options, is easily extensible and it can produce machine readable output.
Mesa demos.
Nate Robins' OpenGL Tutors are a set of tutorial programs that demonstrate basic OpenGL functionality by allowing the user to modify the parameters of a function and see the effect on the scene.
Frustum has some demos to some >= 1.2 GL extensions, including shaders
Humus also has some demos to GL extensions, including shaders and ATI specific extensions
GPU Shader Demo Programs using nVidia (NV) and/or ARB shader extensions, featured at opengl.org.
What environment variables affect libGL behavior?
LIBGL_DEBUG |
If defined debug information will be printed to stderr. If set to verbose additional information will be printed. |
LIBGL_DRIVERS_PATH |
Path were to search for 3D DRI drivers. |
LIBGL_MULTIHEAD |
Define to specify the presence of more than one display. |
LIBGL_ALWAYS_INDIRECT |
Assures that no direct rendering will take place. See also here. |
LIBGL_DRI_AUTOFULLSCREEN |
If set to enable, 1, on, true, t, yes or y the driver it will check for the potential to enter an automatic full-screen mode. |
LIBGL_SOFTWARE_RENDERING |
If set it will force software rendering. |
LIBGL_NO_MULTITEXTURE |
If set it will disable the GL_ARB_multitexture extension. |
LIBGL_PERFORMANCE_BOXES |
If set the r128 driver, when built with ENABLE_PERF_BOXES will draw performance boxes. |
LIBGL_THROTTLE_REFRESH |
Throttle the framerate to the refresh rate on radeon, r200, and possibly other drivers. |
Due to their specificity and volatility is not worth to have all driver specific environment variables here. An interesting way to list them is to do: strings /usr/X11R6/lib/modules/dri/<driver>_dri.so | grep DEBUG
How should I report bugs?
Please submit bugs to BugZilla. It's best if you can create a small example that shows what you think is the problem.
For those who really want to be Open Source heroes -- you can create a test for the bug under glean. The intention would be to run glean quite often, so any functionality you can verify there, is much less likely to reappear in a broken form at some random time in the future.
Capturing debugging info without networking
Here is a sort of simple shell script that I just thought of that might make people's lives a little easier. Cut & paste this into a file (maybe /usr/local/bin/dri_debug.sh) and then add this line to your equivalent of /etc/rc.local:
/bin/sh /usr/local/bin/dri_debug.sh
to have it run at boot time to save info from the last crash. Otherwise, just run it any old time to get a snapshot of log data.
If there's interest, I'll put together a nice rc script that should work on most distros for distribution with the testing binaries. This is just a "mock up" (I haven't even run it - I hate dog food 
of what should be a bit more complicated and grab a few more things, but you get the idea.
DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T` mkdir $DRI_DEBUG_DIR cp /var/log/XFree86.0.log $DRI_DEBUG_DIR # this should work, but a grep might be better ... tail -5000 /var/log/messages >$DRI_DEBUG_DIR/syslog.log cp /etc/X11/XF86Config* $DRI_DEBUG_DIR ls -l /usr/lib/libGL* >>$DRI_DEBUG_DIR/usr_GLFiles.txt ls -l /usr/X11R6/lib >>$DRI_DEBUG_DIR/X11R6_libFiles.txt ldd /usr/X11R6/bin/glxgears >>$DRI_DEBUG_DIR/ldd_glxgears.txt # any other files ... tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR #rm -rf $DRI_DEBUG_DIR
It might be nice to patch xinitrc to do this:
glxinfo >>/var/tmp/glxinfo.txt
every time so it can be bundled up, too.
Then when people start having problems, the list can expect (somewhat) consistent reports. Lemme know what you think.
I take no responsibility for the meltdown of your system
-- AlTobey
How to get a backtrace on the core dump?
- If core dumps aren't turned on in your shell, turn them on.
For tcsh it's a command like limit coredumpsize 200000 For bash it is ulimit -c unlimited. See the man page. Start the server startx from the same shell.
When the server crashes and you get a core file, run gdb on it. The core file might be in /etc/X11 if it's not in the current directory.
gdb -c core /usr/X11R6/bin/XFree86
From the gdb prompt type bt to get a backtrace. Hopefully you have symbols and it will give us an idea where it actually segfaulted.