* retrace OpenGL calls from a file;
-* visualize trace files, and inspect state.
+* inspect OpenGL state at any call while retracing;
+
+* visualize and edit trace files.
Basic usage
===========
-Linux
------
+Linux and Mac OS X
+------------------
Run the application you want to trace as
- LD_PRELOAD=/path/to/glxtrace.so /path/to/application
+ apitrace trace application [args...]
and it will generate a trace named `application.trace` in the current
directory. You can specify the written trace filename by setting the
View the trace with
- /path/to/tracedump application.trace | less -R
+ /path/to/apitrace dump --color application.trace | less -R
Replay the trace with
/path/to/qapitrace application.trace
+Special notes on "apitrace trace" for Linux
+-------------------------------------------
+The "apitrace trace" command uses the `LD_PRELOAD` mechanism which
+should work with most applications. There are some applications,
+e.g., Unigine Heaven, which global function pointers with the same
+name as GL entrypoints, living in a shared object that wasn't linked
+with `-Bsymbolic` flag, so relocations to those globals function
+pointers get overwritten with the address to our wrapper library, and
+the application will segfault when trying to write to them.
-The `LD_PRELOAD` mechanism should work with most applications. There are some
-applications, e.g., Unigine Heaven, which global function pointers with the
-same name as GL entrypoints, living in a shared object that wasn't linked with
-`-Bsymbolic` flag, so relocations to those globals function pointers get
-overwritten with the address to our wrapper library, and the application will
-segfault when trying to write to them. For these applications it is possible
-to trace by using `glxtrace.so` as an ordinary `libGL.so` and injecting into
-`LD_LIBRARY_PATH`:
+For these applications it is possible to trace by using `glxtrace.so`
+as an ordinary `libGL.so` and injecting into `LD_LIBRARY_PATH`:
ln -s glxtrace.so libGL.so
ln -s glxtrace.so libGL.so.1
`LD_LIBRARY_PATH` environment flags.
+Special notes on "apitrace trace" for Mac OS X
+----------------------------------------------
+On Mac OS X the "apitrace trace" command sets the following
+environment variable before executing the program:
-Mac OS X
---------
-
-Usage on Mac OS X is similar to Linux above, except for the tracing procedure,
-which is instead:
-
- DYLD_LIBRARY_PATH=/path/to/apitrace/wrappers /path/to/application
+ DYLD_LIBRARY_PATH=/path/to/apitrace/wrappers
Note that although Mac OS X has an `LD_PRELOAD` equivalent,
-`DYLD_INSERT_LIBRARIES`, it is mostly useless because it only works with
-`DYLD_FORCE_FLAT_NAMESPACE=1` which breaks most applications. See the `dyld` man
-page for more details about these environment flags.
+`DYLD_INSERT_LIBRARIES`, it is mostly useless because it only works
+with `DYLD_FORCE_FLAT_NAMESPACE=1` which breaks most applications.
+See the `dyld` man page for more details about these environment
+flags.
Windows
* View the trace with
- \path\to\tracedump application.trace
+ \path\to\apitrace dump application.trace
* Replay the trace with
===========================
+Emitting annotations to the trace from GL applications
+------------------------------------------------------
+
+You can emit string and frame annotations through the
+[`GL_GREMEDY_string_marker`](http://www.opengl.org/registry/specs/GREMEDY/string_marker.txt)
+and
+[`GL_GREMEDY_frame_terminator`](http://www.opengl.org/registry/specs/GREMEDY/frame_terminator.txt)
+GL extensions.
+
+**apitrace** will advertise and intercept these GL extensions independently of
+the GL implementation. So all you have to do is to use these extensions when
+available.
+
+For example, if you use [GLEW](http://glew.sourceforge.net/) to dynamically
+detect and use GL extensions, you could easily accomplish this by doing:
+
+ void foo() {
+
+ if (GLEW_GREMEDY_string_marker) {
+ glStringMarkerGREMEDY(0, __FUNCTION__ ": enter");
+ }
+
+ ...
+
+ if (GLEW_GREMEDY_string_marker) {
+ glStringMarkerGREMEDY(0, __FUNCTION__ ": leave");
+ }
+
+ }
+
+This has the added advantage of working equally well with gDEBugger.
+
+
Dump GL state at a particular call
----------------------------------
Advanced usage for OpenGL implementors
======================================
-There are several avanced usage examples meant for OpenGL implementors.
+There are several advanced usage examples meant for OpenGL implementors.
Regression testing
------------------
-These are the steps to create a regression testsuite around apitrace:
+These are the steps to create a regression test-suite around **apitrace**:
* obtain a trace
The `--gl-renderer` option will also cause a commit to be skipped if the
`GL_RENDERER` is unexpected (e.g., when a software renderer or another GL
-driver is unintentianlly loaded due to missing symbol in the DRI driver, or
+driver is unintentionally loaded due to missing symbol in the DRI driver, or
another runtime fault).
----------------------
In order to determine which draw call a regression first manifests one could
-generate snapshots for every draw call, using the -S option. That is, however,
+generate snapshots for every draw call, using the `-S` option. That is, however,
very inefficient for big traces with many draw calls.
A faster approach is to run both the bad and a good GL driver side-by-side.
-The latter can be either a preivously known good build of the GL driver, or a
+The latter can be either a previously known good build of the GL driver, or a
reference software renderer.
This can be achieved with retracediff.py script, which invokes glretrace with
projects / apitrace / blobdiff