**apitrace** consists of a set of tools to:
-* trace OpenGL, OpenGL ES, D3D9, D3D8, D3D7, and DDRAW APIs calls to a file;
+* trace OpenGL, OpenGL ES, Direct3D, and DirectDraw APIs calls to a file;
-* retrace OpenGL and OpenGL ES calls from a file;
+* replay OpenGL and OpenGL ES calls from a file;
* inspect OpenGL state at any call while retracing;
* visualize and edit trace files.
+See the [apitrace homepage](http://apitrace.github.io/) for more details.
-Basic usage
-===========
+
+Obtaining **apitrace**
+======================
To obtain apitrace either [download the latest
-binaries](https://github.com/apitrace/apitrace/downloads) for your platform if
-available, or follow the [build instructions](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.
+binaries](http://apitrace.github.io/#download) 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.
+
+
+Basic usage
+===========
Run the application you want to trace as
Replay an OpenGL trace with
- glretrace application.trace
+ apitrace replay application.trace
-Pass the `-sb` option to use a single buffered visual. Pass `--help` to
-glretrace for more options.
+Pass the `--sb` option to use a single buffered visual. Pass `--help` to
+`apitrace replay` for more options.
+
+
+Basic GUI usage
+===============
Start the GUI as
qapitrace application.trace
+You can also tell the GUI to go directly to a specific call
+
+ qapitrace application.trace 12345
+
Advanced command line usage
===========================
Several tools take `CALLSET` arguments, e.g:
- apitrace dump --calls CALLSET foo.trace
- glretrace -S CALLSET foo.trace
+ apitrace dump --calls=CALLSET foo.trace
+ apitrace dump-images --calls=CALLSET foo.trace
The call syntax is very flexible. Here are a few examples:
* `4` one call
- * `1,2,4,5` set of calls
+ * `0,2,4,5` set of calls
- * `"1 2 4 5"` set of calls (commas are optional and can be replaced with whitespace)
+ * `"0 2 4 5"` set of calls (commas are optional and can be replaced with whitespace)
- * `1-100/2` calls 1, 3, 5, ..., 99
+ * `0-100/2` calls 1, 3, 5, ..., 99
- * `1-1000/draw` all draw calls between 1 and 1000
+ * `0-1000/draw` all draw calls between 0 and 1000
- * `1-1000/fbo` all fbo changes between calls 1 and 1000
+ * `0-1000/fbo` all fbo changes between calls 0 and 1000
* `frame` all calls at end of frames
### Linux ###
-On 64 bits systems, you'll need to determine ether the application is 64 bits
+On 64 bits systems, you'll need to determine whether the application is 64 bits
or 32 bits. This can be done by doing
file /path/to/application
But beware of wrapper shell scripts -- what matters is the architecture of the
main process.
-Run the application you want to trace as
+Run the GLX application you want to trace as
- LD_PRELOAD=/path/to/apitrace/wrappers/glxtrace.so /path/to/application
+ 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.
-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 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 OpenGL entrypoints, living in a
+shared object that wasn't linked with `-Bsymbolic` flag, so relocations to
+those global 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
export TRACE_LIBGL=/path/to/real/libGL.so.1
/path/to/application
+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.
-To trace the application inside gdb, invoke gdb as:
+### Android ###
- gdb --ex 'set exec-wrapper env LD_PRELOAD=/path/to/glxtrace.so' --args /path/to/application
+To trace standalone native OpenGL ES applications, use
+`LD_PRELOAD=/path/to/egltrace.so /path/to/application` as described in the
+previous section. To trace Java applications, refer to Dalvik.markdown.
### Mac OS X ###
You can specify the written trace filename by setting the `TRACE_FILE`
environment variable before running.
+For D3D10 and higher you really must use `apitrace trace -a DXGI ...`. This is
+because D3D10-11 API span many DLLs which depend on each other, and once a DLL
+with a given name is loaded Windows will reuse it for LoadLibrary calls of the
+same name, causing internal calls to be traced erroneously. `apitrace trace`
+solves this issue by injecting a DLL `dxgitrace.dll` and patching all modules
+to hook only the APIs of interest.
+
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.
+From whitin OpenGL applications you can embed annotations in the trace file
+through the following extensions:
+
+* [`GL_KHR_debug`](http://www.opengl.org/registry/specs/KHR/debug.txt)
+
+* [`GL_ARB_debug_output`](http://www.opengl.org/registry/specs/ARB/debug_output.txt)
+
+* [`GL_AMD_debug_output`](http://www.opengl.org/registry/specs/AMD/debug_output.txt)
-**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.
+* [`GL_GREMEDY_string_marker`](http://www.opengl.org/registry/specs/GREMEDY/string_marker.txt)
+
+* [`GL_GREMEDY_frame_terminator`](http://www.opengl.org/registry/specs/GREMEDY/frame_terminator.txt)
+
+**apitrace** will advertise and intercept these OpenGL extensions regardless
+of whether the OpenGL implementation supports them or not. So all you have
+to do is to use these extensions when available, and you can be sure they
+will be available when tracing inside **apitrace**.
For example, if you use [GLEW](http://glew.sourceforge.net/) to dynamically
-detect and use GL extensions, you could easily accomplish this by doing:
+detect and use OpenGL extensions, you could easily accomplish this by doing:
void foo() {
- if (GLEW_GREMEDY_string_marker) {
- glStringMarkerGREMEDY(0, __FUNCTION__ ": enter");
+ if (GLEW_KHR_debug) {
+ glPushDebugGroup(GL_DEBUG_SOURCE_APPLICATION, 0, -1, __FUNCTION__);
}
...
- if (GLEW_GREMEDY_string_marker) {
- glStringMarkerGREMEDY(0, __FUNCTION__ ": leave");
+ if (GLEW_KHR_debug) {
+ glDebugMessageInsert(GL_DEBUG_SOURCE_APPLICATION, GL_DEBUG_TYPE_OTHER,
+ 0, GL_DEBUG_SEVERITY_MEDIUM, -1, "bla bla");
}
+ ...
+
+ if (GLEW_KHR_debug) {
+ glPopDebugGroup();
+ }
+
}
-This has the added advantage of working equally well with gDEBugger.
+This has the added advantage of working equally well with other OpenGL debugging tools.
+
+Also, provided that the OpenGL implementation supports `GL_KHR_debug`, labels
+defined via glObjectLabel() , and the labels of several objects (textures,
+framebuffers, samplers, etc. ) will appear in the GUI state dumps, in the
+parameters tab.
-From OpenGL ES applications you can embed annotations in the trace file through the
+For OpenGL ES applications you can embed annotations in the trace file through the
+[`GL_KHR_debug`](http://www.khronos.org/registry/gles/extensions/KHR/debug.txt) or
[`GL_EXT_debug_marker`](http://www.khronos.org/registry/gles/extensions/EXT/EXT_debug_marker.txt)
-extension.
+extensions.
-For Direct3D applications you can follow the same procedure used for
-[instrumenting an application for PIX](http://technet.microsoft.com/en-us/query/ee417250)
+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.
-Dump GL state at a particular call
+- `ID3DUserDefinedAnnotation::BeginEvent`,
+ `ID3DUserDefinedAnnotation::EndEvent`, and
+ `ID3DUserDefinedAnnotation::SetMarker` for D3D11.1 applications.
+
+
+Dump OpenGL state at a particular call
----------------------------------
-You can get a dump of the bound GL state at call 12345 by doing:
+You can get a dump of the bound OpenGL state at call 12345 by doing:
- glretrace -D 12345 application.trace > 12345.json
+ apitrace replay -D 12345 application.trace > 12345.json
-This is precisely the mechanism the GUI obtains its own state.
+This is precisely the mechanism the GUI uses to obtain its own state.
You can compare two state dumps by doing:
limitations.
-Recording a video with FFmpeg
------------------------------
+Recording a video with FFmpeg/Libav
+-----------------------------------
-You can make a video of the output by doing
+You can make a video of the output with FFmpeg by doing
- glretrace -s - application.trace \
+ apitrace dump-images -o - application.trace \
| ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y output.mp4
+or Libav (which replaces FFmpeg on recent Debian/Ubuntu distros) doing
+
+ apitrace dump-images -o - application.trace \
+ | avconv -r 30 -f image2pipe -vcodec ppm -i - -vcodec mpeg4 -y output.mp4
-Triming a trace
----------------
+Recording a video with gstreamer
+--------------------------------------
-You can make a smaller trace by doing:
+You can make a video of the output with gstreamer by doing
- apitrace trim --callset 100-1000 -o trimed.trace applicated.trace
+ glretrace --snapshot-format=RGB -s - smokinguns.trace | gst-launch-0.10 fdsrc blocksize=409600 ! queue \
+ ! videoparse format=rgb width=1920 height=1080 ! queue ! ffmpegcolorspace ! queue \
+ ! vaapiupload direct-rendering=0 ! queue ! vaapiencodeh264 ! filesink location=xxx.264
+
+Trimming a trace
+----------------
+
+You can truncate a trace by doing:
+
+ apitrace trim --exact --calls 0-12345 -o trimed.trace application.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'
+individual call numbers in a plain text file, as described in the 'Call sets'
section above.
+There is also experimental support for automatically trimming the calls
+necessary for a given frame or call:
+
+ apitrace trim --auto --calls=12345 -o trimed.trace application.trace
+ apitrace trim --auto --frames=12345 -o trimed.trace application.trace
+
+
+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 these can then be read by hand or analyzed 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:
+
+ apitrace replay --pgpu --pcpu --ppd foo.trace | ./scripts/profileshader.py
+
Advanced usage for OpenGL implementors
======================================
* obtain reference snapshots, by doing on a reference system:
mkdir /path/to/reference/snapshots/
- glretrace -s /path/to/reference/snapshots/ application.trace
+ apitrace dump-images -o /path/to/reference/snapshots/ application.trace
* prune the snapshots which are not interesting
-* to do a regression test, do:
-
- glretrace -c /path/to/reference/snapshots/ application.trace
-
- Alternatively, for a HTML summary, use `apitrace diff-images`:
+* to do a regression test, use `apitrace diff-images`:
- glretrace -s /path/to/test/snapshots/ application.trace
+ apitrace dump-images -o /path/to/test/snapshots/ application.trace
apitrace diff-images --output summary.html /path/to/reference/snapshots/ /path/to/test/snapshots/
commit responsible for a regression.
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
+Mesa-based Intel 965 driver. But the procedure could be applied to any OpenGL
driver hosted on a git repository.
First, create a build script, named build-script.sh, containing:
make "$@"
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
+dependency discovery in Mesa's makefile system, it was necessary to invoke `make
clean` in every iteration step. `ccache` should be installed to avoid
recompiling unchanged source files.
failures.
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
+`GL_RENDERER` is unexpected (e.g., when a software renderer or another OpenGL
+driver is unintentionally loaded due to a missing symbol in the DRI driver, or
another runtime fault).
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 previously known good build of the GL driver, or a
+A faster approach is to run both the bad and a good OpenGL driver side-by-side.
+The latter can be either a previously known good build of the OpenGL driver, or a
reference software renderer.
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` or `LIBGL_DRIVERS_DIR`.
+different environments, allowing to choose the desired OpenGL driver by
+manipulating variables such as `LD_LIBRARY_PATH`, `LIBGL_DRIVERS_DIR`, or
+`TRACE_LIBGL`.
-For example:
+For example, on Linux:
./scripts/retracediff.py \
- --ref-env LD_LIBRARY_PATH=/path/to/reference/GL/implementation \
- -r ./glretrace \
+ --ref-env LD_LIBRARY_PATH=/path/to/reference/OpenGL/implementation \
+ --retrace /path/to/glretrace \
--diff-prefix=/path/to/output/diffs \
application.trace
+Or on Windows:
+ python scripts\retracediff.py --retrace \path\to\glretrace.exe --ref-env TRACE_LIBGL=\path\to\reference\opengl32.dll application.trace
-Links
-=====
-
-About **apitrace**:
-
-* [Official mailing list](http://lists.freedesktop.org/mailman/listinfo/apitrace)
-
-* [Zack Rusin's blog introducing the GUI](http://zrusin.blogspot.com/2011/04/apitrace.html)
-* [Jose's Fonseca blog introducing the tool](http://jrfonseca.blogspot.com/2008/07/tracing-d3d-applications.html)
-
-
-Direct3D
---------
-
-Open-source:
-
-* [Proxy DLL](http://www.mikoweb.eu/index.php?node=21)
-
- * [Intercept Calls to DirectX with a Proxy DLL](http://www.codeguru.com/cpp/g-m/directx/directx8/article.php/c11453/)
+Advanced GUI usage
+==================
-* [Direct3D 9 API Interceptor](http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html)
+qapitrace has rudimentary support for replaying traces on a remote
+target device. This can be useful, for example, when developing for an
+embedded system. The primary GUI will run on the local host, while any
+replays will be performed on the target device.
-Closed-source:
+In order to target a remote device, use the command-line:
-* [Microsoft PIX](http://msdn.microsoft.com/en-us/library/ee417062.aspx)
+ qapitrace --remote-target <HOST> <trace-file>
- * [D3DSpy](http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/programmingguide/TutorialsAndSamplesAndToolsAndTips/Tools/D3DSpy.htm): the predecessor of PIX
+In order for this to work, the following must be available in the
+system configuration:
-* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
+1. It must be possible for the current user to initiate an ssh session
+ that has access to the target's window system. The command to be
+ exectuted by qapitrace will be:
+ ssh <HOST> glretrace
-OpenGL
-------
+ For example, if the target device is using the X window system, one
+ can test whether an ssh session has access to the target X server
+ with:
-Open-source:
+ ssh <HOST> xdpyinfo
-* [BuGLe](http://www.opengl.org/sdk/tools/BuGLe/)
+ If this command fails with something like "cannot open display"
+ then the user will have to configure the target to set the DISPLAY
+ environment variable, (for example, setting DISPLAY=:0 in the
+ .bashrc file on the target or similar).
-* [GLIntercept](http://code.google.com/p/glintercept/)
+ Also, note that if the ssh session requires a custom username, then
+ this must be configured on the host side so that ssh can be
+ initiated without a username.
-* [tracy](https://gitorious.org/tracy): OpenGL ES and OpenVG trace, retrace, and state inspection
+ For example, if you normally connect with `ssh user@192.168.0.2`
+ you could configure ~/.ssh/config on the host with a block such as:
-* [WebGL-Inspector](http://benvanik.github.com/WebGL-Inspector/)
+ Host target
+ HostName 192.168.0.2
+ User user
-Closed-source:
+ And after this you should be able to connect with `ssh target` so
+ that you can also use `qapitrace --remote-target target`.
-* [gDEBugger](http://www.gremedy.com/products.php)
+2. The target host must have a functional glretrace binary available
-* [glslDevil](http://cumbia.informatik.uni-stuttgart.de/glsldevil/index.html)
+3. The target host must have access to <trace-file> at the same path
+ in the filesystem as the <trace-file> path on the host system being
+ passed to the qapitrace command line.
-* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
+[](http://githalytics.com/apitrace/apitrace)
projects / apitrace / blobdiff