**apitrace** consists of a set of tools to:
-* trace OpenGL, D3D9, D3D8, D3D7, and DDRAW APIs calls to a file;
+* trace OpenGL, OpenGL ES, Direct3D, and DirectDraw APIs calls to a file;
-* retrace OpenGL calls from a file;
+* retrace OpenGL and OpenGL ES calls from a file;
-* visualize trace files, and inspect state.
+* inspect OpenGL state at any call while retracing;
+* visualize and edit trace files.
-Building from source
-====================
+See the [apitrace homepage](http://apitrace.github.com/) for more details.
-Requirements common for all platforms:
+Obtaining **apitrace**
+======================
-* Python (requires version 2.6)
+To obtain apitrace either [download the latest
+binaries](https://github.com/apitrace/apitrace/downloads) for your platform if
+available, or follow the instructions in INSTALL.markdown to build it yourself.
+On 64bits Linux and Windows platforms you'll need apitrace binaries that match
+the architecture (32bits or 64bits) of the application being traced.
-* CMake (tested with version 2.8)
-Requirements to build the GUI (optional):
+Basic usage
+===========
-* Qt (tested with version 4.7)
+Run the application you want to trace as
-* QJSON (tested with version 0.7.1)
+ apitrace trace --api API /path/to/application [args...]
+and it will generate a trace named `application.trace` in the current
+directory. You can specify the written trace filename by passing the
+`--output` command line option.
-Linux / Mac OS X
-----------------
+Problems while tracing (e.g, if the application uses calls/parameters
+unsupported by apitrace) will be reported via stderr output on Unices. On
+Windows you'll need to run
+[DebugView](http://technet.microsoft.com/en-us/sysinternals/bb896647) to view
+these messages.
-Build as:
+Follow the "Tracing manually" instructions below if you cannot obtain a trace.
- cmake -H. -Bbuild
- make -C build
+View the trace with
-You can also build the 32bit GL wrapper on 64bit distro with a multilib gcc by
-doing:
+ apitrace dump application.trace
- cmake -H. -Bbuild32 -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_EXE_LINKER_FLAGS=-m32
- make -C build32 glxtrace
+Replay an OpenGL trace with
+ glretrace application.trace
-Windows
--------
+Pass the `--sb` option to use a single buffered visual. Pass `--help` to
+`glretrace` for more options.
-Additional requirements:
+EGL traces must be replayed with `eglretrace` instead of `glretrace`.
-* Microsoft Visual Studio (tested with 2008 version) or MinGW (tested with gcc version 4.4)
-* Microsoft DirectX SDK (tested with August 2007 release)
+Basic GUI usage
+===============
-To build with Visual Studio first invoke CMake GUI as:
+Start the GUI as
- cmake-gui -H. -B%cd%\build
+ qapitrace application.trace
-and press the _Configure_ button.
+You can also tell the GUI to go directly to a specific call
-It will try to detect most required/optional dependencies automatically. When
-not found automatically, you can manually specify the location of the
-dependencies from the GUI.
+ qapitrace application.trace 12345
-If you are building with GUI support (i.e, with QT and QJSON), it should detect
-the official QT sdk automatically, but you will need to build QJSON yourself
-and also set the `QJSON_INCLUDE_DIR` and `QJSON_LIBRARIES` variables in the
-generated `CMakeCache.txt` when building apitrace and repeat the above
-sequence.
-After you've succesfully configured, you can start the build by opening the
-generated `build\apitrace.sln` solution file, or invoking `cmake` as:
+Advanced command line usage
+===========================
- cmake --build build --config MinSizeRel
-The steps to build 64bit version are similar, but choosing _Visual Studio 9
-2008 Win64_ instead of _Visual Studio 9 2008_.
+Call sets
+---------
-It's also possible to instruct `cmake` build Windows binaries on Linux with
-[MinGW cross compilers](http://www.cmake.org/Wiki/CmakeMingw).
+Several tools take `CALLSET` arguments, e.g:
+ apitrace dump --calls CALLSET foo.trace
+ glretrace -S CALLSET foo.trace
-Usage
-=====
+The call syntax is very flexible. Here are a few examples:
+ * `4` one call
-Linux
------
+ * `0,2,4,5` set of calls
-Run the application you want to trace as
+ * `"0 2 4 5"` set of calls (commas are optional and can be replaced with whitespace)
- LD_PRELOAD=/path/to/glxtrace.so /path/to/application
+ * `0-100/2` calls 1, 3, 5, ..., 99
-and it will generate a trace named `application.trace` in the current
-directory. You can specify the written trace filename by setting the
-`TRACE_FILE` environment variable before running.
+ * `0-1000/draw` all draw calls between 0 and 1000
-View the trace with
+ * `0-1000/fbo` all fbo changes between calls 0 and 1000
- /path/to/tracedump application.trace | less -R
+ * `frame` all calls at end of frames
-Replay the trace with
+ * `@foo.txt` read call numbers from `foo.txt`, using the same syntax as above
- /path/to/glretrace application.trace
-Pass the `-sb` option to use a single buffered visual. Pass `--help` to
-glretrace for more options.
-Start the GUI as
+Tracing manually
+----------------
+
+### Linux ###
- /path/to/qapitrace application.trace
+On 64 bits systems, you'll need to determine ether the application is 64 bits
+or 32 bits. This can be done by doing
+ file /path/to/application
-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`:
+But beware of wrapper shell scripts -- what matters is the architecture of the
+main process.
- ln -s glxtrace.so libGL.so
- ln -s glxtrace.so libGL.so.1
- ln -s glxtrace.so libGL.so.1.2
- export LD_LIBRARY_PATH=/path/to/directory/where/glxtrace/is:$LD_LIBRARY_PATH
+Run the GLX application you want to trace as
+
+ LD_PRELOAD=/path/to/apitrace/wrappers/glxtrace.so /path/to/application
+
+and it will generate a trace named `application.trace` in the current
+directory. You can specify the written trace filename by setting the
+`TRACE_FILE` environment variable before running.
+
+For EGL applications you will need to use `egltrace.so` instead of
+`glxtrace.so`.
+
+The `LD_PRELOAD` mechanism should work with the majority applications. There
+are some applications (e.g., Unigine Heaven, Android GPU emulator, etc.), that
+have 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 it via `LD_LIBRARY_PATH`:
+
+ ln -s glxtrace.so wrappers/libGL.so
+ ln -s glxtrace.so wrappers/libGL.so.1
+ ln -s glxtrace.so wrappers/libGL.so.1.2
+ export LD_LIBRARY_PATH=/path/to/apitrace/wrappers:$LD_LIBRARY_PATH
export TRACE_LIBGL=/path/to/real/libGL.so.1
/path/to/application
-See the 'ld.so' man page for more information about `LD_PRELOAD` and
+If you are an application developer, you can avoid this either by linking with
+`-Bsymbolic` flag, or by using some unique prefix for your function pointers.
+
+See the `ld.so` man page for more information about `LD_PRELOAD` and
`LD_LIBRARY_PATH` environment flags.
-You can make a video of the output by doing
+To trace the application inside gdb, invoke gdb as:
- /path/to/glretrace -s - application.trace \
- | ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y output.mp4
+ gdb --ex 'set exec-wrapper env LD_PRELOAD=/path/to/glxtrace.so' --args /path/to/application
+
+### Android ###
+
+The following instructions should work at least for Android Ice Scream
+Sandwitch:
+
+For standalone applications the instructions above for Linux should
+work. To trace applications started from within the Android VM process
+(`app_process` aka zygote) you'll have to wrap this process and enable
+tracing dynamically for the application to be traced.
+- Wrapping the android main VM process:
+ In the Android root /init.rc add the `LD_PRELOAD` setting to zygote's
+ environment in the 'service zygote' section:
-Mac OS X
---------
+ service zygote ...
+ setenv LD_PRELOAD /data/egltrace.so
+ ...
-Usage on Mac OS X is similar to Linux above, except for the tracing procedure,
-which is instead:
+ Note that ICS will overwrite the /init.rc during each boot with the
+ version in the recovery image. So you'll have to change the file in
+ your ICS source tree, rebuild and reflash the device.
+ Rebuilding/reflashing only the recovery image should be sufficient.
+
+- Copy egltrace.so to /data
+
+ On the host:
+
+ adb push /path/to/apitrace/build/wrappers/egltrace.so /data
+
+- Adjust file permissions to store the trace file:
+
+ By default egltrace.so will store the trace in
+ `/data/app_process.trace`. For this to work for applications running
+ with a uid other than 0, you have to allow writes to the `/data`
+ directory on the device:
+
+ chmod 0777 /data
+
+- Enable tracing for a specific process name:
+
+ To trace for example the Settings application:
+
+ setprop debug.apitrace.procname com.android.settings
+
+ In general this name will match what `ps` reports.
+
+- Start the application:
+
+ If the application was already running, for example due to ICS's way
+ of pre-starting the apps, you might have to kill the application
+ first:
+
+ kill <pid of app>
+
+ Launch the application for example from the application menu.
+
+### Mac OS X ###
+
+Run the application you want to trace as
DYLD_LIBRARY_PATH=/path/to/apitrace/wrappers /path/to/application
`DYLD_FORCE_FLAT_NAMESPACE=1` which breaks most applications. See the `dyld` man
page for more details about these environment flags.
+### Windows ###
+
+When tracing third-party applications, you can identify the target
+application's main executable, either by:
+
+* right clicking on the application's icon in the _Start Menu_, choose
+ _Properties_, and see the _Target_ field;
+
+* or by starting the application, run Windows Task Manager (taskmgr.exe), right
+ click on the application name in the _Applications_ tab, choose _Go To Process_,
+ note the highlighted _Image Name_, and search it on `C:\Program Files` or
+ `C:\Program Files (x86)`.
+
+On 64 bits Windows, you'll need to determine ether the application is a 64 bits
+or 32 bits. 32 bits applications will have a `*32` suffix in the _Image Name_
+column of the _Processes_ tab of _Windows Task Manager_ window.
+
+Copy the appropriate `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from the
+wrappers directory to the directory with the application you want to trace.
+Then run the application as usual.
+
+You can specify the written trace filename by setting the `TRACE_FILE`
+environment variable before running.
+
+
+Emitting annotations to the trace
+---------------------------------
+
+From OpenGL applications you can embed annotations in the trace file 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.
+
+
+From OpenGL ES applications you can embed annotations in the trace file through the
+[`GL_EXT_debug_marker`](http://www.khronos.org/registry/gles/extensions/EXT/EXT_debug_marker.txt)
+extension.
+
+
+For Direct3D applications you can follow the standard procedure for
+[adding user defined events to Visual Studio Graphics Debugger / PIX](http://msdn.microsoft.com/en-us/library/vstudio/hh873200.aspx):
+
+- `D3DPERF_BeginEvent`, `D3DPERF_EndEvent`, and `D3DPERF_SetMarker` for D3D9 applications.
+
+- `ID3DUserDefinedAnnotation::BeginEvent`,
+ `ID3DUserDefinedAnnotation::EndEvent`, and
+ `ID3DUserDefinedAnnotation::SetMarker` for D3D11.1 applications.
+
+
+Dump GL state at a particular call
+----------------------------------
+
+You can get a dump of the bound GL state at call 12345 by doing:
+
+ glretrace -D 12345 application.trace > 12345.json
+
+This is precisely the mechanism the GUI obtains its own state.
+
+You can compare two state dumps by doing:
+
+ apitrace diff-state 12345.json 67890.json
+
+
+Comparing two traces side by side
+---------------------------------
+
+ apitrace diff trace1.trace trace2.trace
+
+This works only on Unices, and it will truncate the traces due to performance
+limitations.
+
+
+Recording a video with FFmpeg
+-----------------------------
+
+You can make a video of the output by doing
+
+ glretrace -s - application.trace \
+ | ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y output.mp4
+
+
+Trimming a trace
+----------------
+
+You can make a smaller trace by doing:
+
+ apitrace trim --callset 100-1000 -o trimed.trace applicated.trace
+
+If you need precise control over which calls to trim you can specify the
+individual call numbers a plaintext file, as described in the 'Call sets'
+section above.
+
+
+Profiling a trace
+-----------------
+
+You can perform gpu and cpu profiling with the command line options:
+
+ * `--pgpu` record gpu times for frames and draw calls.
+
+ * `--pcpu` record cpu times for frames and draw calls.
+
+ * `--ppd` record pixels drawn for each draw call.
+
+The results from this can then be read by hand or analysed with a script.
+
+`scripts/profileshader.py` will read the profile results and format them into a
+table which displays profiling results per shader.
+
+For example, to record all profiling data and utilise the per shader script:
+
+ ./glretrace --pgpu --pcpu --ppd foo.trace | ./scripts/profileshader.py
+
+
+Advanced usage for OpenGL implementors
+======================================
+
+There are several advanced usage examples meant for OpenGL implementors.
-Windows
--------
-* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory
- to the directory with the application you want to trace.
+Regression testing
+------------------
-* Run the application.
+These are the steps to create a regression test-suite around **apitrace**:
-* View the trace with
+* obtain a trace
- /path/to/tracedump application.trace
+* obtain reference snapshots, by doing on a reference system:
-* Replay the trace with
+ mkdir /path/to/reference/snapshots/
+ glretrace -s /path/to/reference/snapshots/ application.trace
- /path/to/glretrace application.trace
+* prune the snapshots which are not interesting
+* to do a regression test, do:
-Links
-=====
+ glretrace -c /path/to/reference/snapshots/ application.trace
-About **apitrace**:
+ Alternatively, for a HTML summary, use `apitrace diff-images`:
-* [Zack Rusin's blog introducing the GUI](http://zrusin.blogspot.com/2011/04/apitrace.html)
+ glretrace -s /path/to/test/snapshots/ application.trace
+ apitrace diff-images --output summary.html /path/to/reference/snapshots/ /path/to/test/snapshots/
-* [Jose's Fonseca blog introducing the tool](http://jrfonseca.blogspot.com/2008/07/tracing-d3d-applications.html)
+Automated git-bisection
+-----------------------
-Direct3D
---------
+With tracecheck.py it is possible to automate git bisect and pinpoint the
+commit responsible for a regression.
-Open-source:
+Below is an example of using tracecheck.py to bisect a regression in the
+Mesa-based Intel 965 driver. But the procedure could be applied to any GL
+driver hosted on a git repository.
-* [Proxy DLL](http://www.mikoweb.eu/index.php?node=21)
+First, create a build script, named build-script.sh, containing:
- * [Intercept Calls to DirectX with a Proxy DLL](http://www.codeguru.com/cpp/g-m/directx/directx8/article.php/c11453/)
+ #!/bin/sh
+ set -e
+ export PATH=/usr/lib/ccache:$PATH
+ export CFLAGS='-g'
+ export CXXFLAGS='-g'
+ ./autogen.sh --disable-egl --disable-gallium --disable-glut --disable-glu --disable-glw --with-dri-drivers=i965
+ make clean
+ make "$@"
-* [Direct3D 9 API Interceptor](http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html)
+It is important that builds are both robust, and efficient. Due to broken
+dependency discovery in Mesa's makefile system, it was necessary invoke `make
+clean` in every iteration step. `ccache` should be installed to avoid
+recompiling unchanged source files.
-Closed-source:
+Then do:
-* [Microsoft PIX](http://msdn.microsoft.com/en-us/library/ee417062.aspx)
+ cd /path/to/mesa
+ export LIBGL_DEBUG=verbose
+ export LD_LIBRARY_PATH=$PWD/lib
+ export LIBGL_DRIVERS_DIR=$PWD/lib
+ git bisect start \
+ 6491e9593d5cbc5644eb02593a2f562447efdcbb 71acbb54f49089b03d3498b6f88c1681d3f649ac \
+ -- src/mesa/drivers/dri/intel src/mesa/drivers/dri/i965/
+ git bisect run /path/to/tracecheck.py \
+ --precision-threshold 8.0 \
+ --build /path/to/build-script.sh \
+ --gl-renderer '.*Mesa.*Intel.*' \
+ --retrace=/path/to/glretrace \
+ -c /path/to/reference/snapshots/ \
+ topogun-1.06-orc-84k.trace
- * [D3DSpy](http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/programmingguide/TutorialsAndSamplesAndToolsAndTips/Tools/D3DSpy.htm): the predecessor of PIX
+The trace-check.py script will skip automatically when there are build
+failures.
-* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
+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 unintentionally loaded due to missing symbol in the DRI driver, or
+another runtime fault).
-OpenGL
-------
+Side by side retracing
+----------------------
-Open-source:
+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,
+very inefficient for big traces with many draw calls.
-* [BuGLe](http://www.opengl.org/sdk/tools/BuGLe/)
+A faster approach is to run both the bad and a good GL driver side-by-side.
+The latter can be either a previously known good build of the GL driver, or a
+reference software renderer.
-* [GLIntercept](http://code.google.com/p/glintercept/)
+This can be achieved with retracediff.py script, which invokes glretrace with
+different environments, allowing to choose the desired GL driver by
+manipulating variables such as `LD_LIBRARY_PATH`, `LIBGL_DRIVERS_DIR`, or
+`TRACE_LIBGL`.
-* [tracy](https://gitorious.org/tracy): OpenGL ES and OpenVG trace, retrace, and state inspection
+For example, on Linux:
-Closed-source:
+ ./scripts/retracediff.py \
+ --ref-env LD_LIBRARY_PATH=/path/to/reference/GL/implementation \
+ --retrace /path/to/glretrace \
+ --diff-prefix=/path/to/output/diffs \
+ application.trace
-* [gDEBugger](http://www.gremedy.com/products.php)
+Or on Windows:
-* [glslDevil](http://cumbia.informatik.uni-stuttgart.de/glsldevil/index.html)
+ python scripts\retracediff.py --retrace \path\to\glretrace.exe --ref-env TRACE_LIBGL=\path\to\reference\opengl32.dll application.trace
-* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
+[![githalytics.com alpha](https://cruel-carlota.pagodabox.com/c1062ad633aa7a458e9d7520021307e4 "githalytics.com")](http://githalytics.com/apitrace/apitrace)