X-Git-Url: https://git.notmuchmail.org/git?a=blobdiff_plain;f=README.markdown;h=497351abe99697dc285e2c0607aaa48da2267f0e;hb=b25c4b9fccc76976d633bc5b183a84553ab01998;hp=e57d0b7ff69bbd98dfd7062e1153e3409fb8f53c;hpb=ed348d58b69b7bdb03f8d5576c4ba5fc3f6c90f1;p=apitrace diff --git a/README.markdown b/README.markdown index e57d0b7..497351a 100644 --- a/README.markdown +++ b/README.markdown @@ -7,109 +7,76 @@ About **apitrace** * 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. -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): + /path/to/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 + /path/to/apitrace dump --color application.trace | less -R -Linux / Mac OS X ----------------- +Replay the trace with -Build as: + /path/to/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 + /path/to/qapitrace application.trace Windows ------- -Additional requirements: - -* Microsoft Visual Studio (tested with 2008 version) or MinGW (tested with gcc version 4.4) - -* Microsoft DirectX SDK (tested with August 2007 release) - -To build with Visual Studio first invoke CMake GUI as: - - cmake-gui -H. -B%cd%\build - -and press the _Configure_ button. +* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory + to the directory with the application you want to 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. +* Run the application. -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. +* View the trace with -After you've succesfully configured, you can start the build by opening the -generated `build\apitrace.sln` solution file, or invoking `cmake` as: + \path\to\apitrace dump application.trace - cmake --build build --config MinSizeRel +* Replay the trace with -The steps to build 64bit version are similar, but choosing _Visual Studio 9 -2008 Win64_ instead of _Visual Studio 9 2008_. + \path\to\glretrace application.trace -It's also possible to instruct `cmake` build Windows binaries on Linux with -[MinGW cross compilers](http://www.cmake.org/Wiki/CmakeMingw). +Advanced command line usage +=========================== -Usage -===== +Tracing manually +---------------- -Linux ------ +### Linux ### Run the application you want to trace as - LD_PRELOAD=/path/to/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. -View the trace with - - /path/to/tracedump application.trace | less -R - -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. - -Start the GUI as - - /path/to/qapitrace application.trace - - 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 @@ -119,52 +86,200 @@ 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 `LD_LIBRARY_PATH` environment flags. +### Mac OS X ### + +Run the application you want to trace as + + DYLD_LIBRARY_PATH=/path/to/apitrace/wrappers /path/to/application + +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. + + +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 +---------------------------------- + +You can get a dump of the bound GL state at call 12345 by doing: + + /path/to/glretrace -D 12345 application.trace > 12345.json + +This is precisely the mechanism the GUI obtains its own state. + +You can compare two state dumps with the jsondiff.py script: + + ./scripts/jsondiff.py 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 /path/to/glretrace -s - application.trace \ | ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y output.mp4 +Advanced usage for OpenGL implementors +====================================== -Mac OS X --------- +There are several advanced usage examples meant for OpenGL implementors. -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 +Regression testing +------------------ -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. +These are the steps to create a regression test-suite around **apitrace**: +* obtain a trace -Windows -------- +* obtain reference snapshots, by doing: -* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory - to the directory with the application you want to trace. + mkdir /path/to/snapshots/ + /path/to/glretrace -s /path/to/reference/snapshots/ application.trace -* Run the application. + on reference system. -* View the trace with +* prune the snapshots which are not interesting - \path\to\tracedump application.trace +* to do a regression test, do: -* Replay the trace with + /path/to/glretrace -c /path/to/reference/snapshots/ application.trace + + Alternatively, for a HTML summary, use the snapdiff script: + + /path/to/glretrace -s /path/to/current/snapshots/ application.trace + ./scripts/snapdiff.py --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 - \path\to\glretrace application.trace Links @@ -172,6 +287,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)