]> git.cworth.org Git - apitrace/blobdiff - README.markdown
Mention apitrace trim in the documentation.
[apitrace] / README.markdown
index 790407d4793c552f08e6acad961d2455ffee9ee6..732f93545adfa525c435bcfa8cb1eae968354dd3 100644 (file)
@@ -3,112 +3,107 @@ About **apitrace**
 
 **apitrace** consists of a set of tools to:
 
-* trace OpenGL, D3D9, D3D8, D3D7, and DDRAW APIs calls to a file;
+* trace OpenGL, OpenGL ES, D3D9, D3D8, D3D7, and DDRAW 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
-====================
 
+Basic usage
+===========
 
-Requirements common for all platforms:
 
-* Python (requires version 2.6)
+Linux and Mac OS X
+------------------
 
-* CMake (tested with version 2.8)
+Run the application you want to trace as
 
-Requirements to build the GUI (optional):
+    apitrace trace /path/to/application [args...]
 
-* Qt (tested with version 4.7)
+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.
 
-* QJSON (tested with version 0.7.1)
+View the trace with
 
+    apitrace dump --color application.trace
 
-Linux / Mac OS X
-----------------
+Replay an OpenGL trace with
 
-Build as:
+    glretrace application.trace
 
-    cmake -H. -Bbuild
-    make -C build
+Pass the `-sb` option to use a single buffered visual.  Pass `--help` to
+glretrace for more options.
 
-You can also build the 32bit GL wrapper on 64bit distro with a multilib gcc by
-doing:
+Start the GUI as
 
-    cmake -H. -Bbuild32 -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_EXE_LINKER_FLAGS=-m32
-    make -C build32 glxtrace
+    qapitrace application.trace
 
 
 Windows
 -------
 
-Additional requirements:
+* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory
+  to the directory with the application you want to trace.
 
-* Microsoft Visual Studio (tested with 2008 version) or MinGW (tested with gcc version 4.4)
+* Run the application.
 
-* Microsoft DirectX SDK (tested with August 2007 release)
+* View the trace with
 
-To build with Visual Studio first invoke CMake GUI as:
+        \path\to\apitrace dump application.trace
 
-    cmake-gui -H. -B%cd%\build
+* Replay the trace with
 
-and press the _Configure_ button.
+        \path\to\glretrace application.trace
 
-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.
 
-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.
+Advanced command line usage
+===========================
 
-After you've succesfully configured, you can start the build by opening the
-generated `build\apitrace.sln` solution file, or invoking `cmake` as:
 
-    cmake --build build --config MinSizeRel
+Call sets
+---------
 
-The steps to build 64bit version are similar, but choosing _Visual Studio 9
-2008 Win64_ instead of _Visual Studio 9 2008_.
+Several tools take `CALLSET` arguments, e.g:
 
-It's also possible to instruct `cmake` build Windows binaries on Linux with
-[MinGW cross compilers](http://www.cmake.org/Wiki/CmakeMingw).
+    apitrace dump --calls CALLSET foo.trace
+    glretrace -S CALLSET foo.trace
 
+The call syntax is very flexible. Here are a few examples:
 
-Usage
-=====
+ * `4`             one call
 
+ * `1,2,4,5`       set of calls
 
-Linux
------
+ * `"1 2 4 5"`     set of calls (commas are optional and can be replaced with whitespace)
 
-Run the application you want to trace as
+ * `1-100/2`       calls 1, 3, 5, ...,  99
 
-     LD_PRELOAD=/path/to/glxtrace.so /path/to/application
+ * `1-1000/draw`   all draw calls between 1 and 1000
 
-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.
+ * `1-1000/fbo`    all fbo changes between calls 1 and 1000
 
-View the trace with
+ * `frame`         all calls at end of frames
 
-    /path/to/tracedump application.trace | less -R
+ * `@foo.txt`      read call numbers from `foo.txt`, using the same syntax as above
 
-Replay the trace with
 
-    /path/to/glretrace application.trace
 
-Pass the `-sb` option to use a single buffered visual.  Pass `--help` to
-glretrace for more options.
+Tracing manually
+----------------
 
-Start the GUI as
+### Linux ###
 
-    /path/to/qapitrace application.trace
+Run the 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.
 
 The `LD_PRELOAD` mechanism should work with most applications.  There are some
 applications, e.g., Unigine Heaven, which global function pointers with the
@@ -119,22 +114,23 @@ 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`:
 
-    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
+    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
+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:
 
-Mac OS X
---------
+    gdb --ex 'set exec-wrapper env LD_PRELOAD=/path/to/glxtrace.so' --args /path/to/application
 
-Usage on Mac OS X is similar to Linux above, except for the tracing procedure,
-which is instead:
+### Mac OS X ###
+
+Run the application you want to trace as
 
     DYLD_LIBRARY_PATH=/path/to/apitrace/wrappers /path/to/application
 
@@ -144,21 +140,190 @@ Note that although Mac OS X has an `LD_PRELOAD` equivalent,
 page for more details about these environment flags.
 
 
-Windows
--------
+Emitting annotations to the trace from GL applications
+------------------------------------------------------
 
-* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory
-  to the directory with the application you want to trace.
+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.
 
-* Run the application.
+**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.
 
-* View the trace with
+For example, if you use [GLEW](http://glew.sourceforge.net/) to dynamically
+detect and use GL extensions, you could easily accomplish this by doing:
 
-        /path/to/tracedump application.trace
+    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
+----------------------------------
+
+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
 
-* Replay the trace with
 
-        /path/to/glretrace application.trace
+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
+
+
+Triming 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.
+
+
+Advanced usage for OpenGL implementors
+======================================
+
+There are several advanced usage examples meant for OpenGL implementors.
+
+
+Regression testing
+------------------
+
+These are the steps to create a regression test-suite around **apitrace**:
+
+* obtain a trace
+
+* obtain reference snapshots, by doing:
+
+        mkdir /path/to/snapshots/
+        glretrace -s /path/to/reference/snapshots/ application.trace
+
+  on reference system.
+
+* 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`:
+
+        glretrace -s /path/to/current/snapshots/ application.trace
+        apitrace diff-images --output summary.html /path/to/reference/snapshots/ /path/to/current/snapshots/
+
+
+Automated git-bisection
+-----------------------
+
+With tracecheck.py it is possible to automate git bisect and pinpoint the
+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
+driver hosted on a git repository.
+
+First, create a build script, named build-script.sh, containing:
+
+    #!/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 "$@"
+
+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.
+
+Then do:
+
+    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
+
+The trace-check.py script will skip automatically when there are build
+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
+another runtime fault).
+
+
+Side by side retracing
+----------------------
+
+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.
+
+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.
+
+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`.
+
+For example:
+
+    ./scripts/retracediff.py \
+        --ref-env LD_LIBRARY_PATH=/path/to/reference/GL/implementation \
+        -r ./glretrace \
+        --diff-prefix=/path/to/output/diffs \
+        application.trace
+
 
 
 Links
@@ -166,6 +331,8 @@ 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)