# Testing And Debugging


## 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|http://www.berkelium.com/OpenGL/isfast.html]]


## 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|http://www.specbench.org/gpc/opc.static/opcview.htm]] is a portable OpenGL performance benchmark program written in C providing a vast amount of flexibility in benchmarking OpenGL performance.
   * [[SPECglperf|http://www.specbench.org/gpc/opc.static/glperf.htm]] 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.
   * [[piglit|http://piglit.freedesktop.org]] 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|http://wwwvis.informatik.uni-stuttgart.de/machtest/intro.html]] 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|http://cgit.freedesktop.org/mesa/demos/]].
   * [[Nate Robins' OpenGL Tutors|http://www.xmission.com/~nate/tutors.html]] 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|http://frustum.org/3d/]] has some demos to some >= 1.2 GL extensions, including shaders
   * [[Humus|http://www.humus.ca/index.php?page=3D]] also has some demos to GL extensions, including shaders and ATI specific extensions
   * [[GPU Shader Demo Programs|http://cs.anu.edu.au/people/Hugh.Fisher/shaders/]] using nVidia (NV) and/or ARB shader extensions, featured at opengl.org.

## What environment variables affect libGL behavior?
[[!table header="no" class="mointable" data="""
 `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_ALWAYS_INDIRECT`  |   Assures that no direct rendering will take place. See also here.
 `LIBGL_ALWAYS_SOFTWARE`  |   If set it will force software rendering.
"""]]

* (!) 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|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 [[piglit|http://piglit.freedesktop.org]]. The intention would be to run piglit 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.


## How to get a backtrace on the core dump?

 1. 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.
 1. 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`
 1. 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. -- [[MarkVojkovich|MarkVojkovich]]
[[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]]


## How to dump video bios ?

Find the pci device associated to your gpu with lspci. If lspci report:

    01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200]

Then

    cd /sys/bus/pci/devices/0000:01:05.0
    sudo sh -c "echo 1 > rom"
    sudo sh -c "cat rom > ~/bios.rom"