X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=README.markdown;h=cdd5dd8ac8f92a47a3c5d755eb880db40f425778;hb=6a31906d3b2d87ecbc4144c11479abba18bede41;hp=790407d4793c552f08e6acad961d2455ffee9ee6;hpb=7cca1d73cdfe0d9dc3a149b01467e33cf220b8e3;p=apitrace diff --git a/README.markdown b/README.markdown index 790407d..cdd5dd8 100644 --- a/README.markdown +++ b/README.markdown @@ -3,112 +3,120 @@ 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, 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 -==================== +Obtaining **apitrace** +====================== -Requirements common for all platforms: +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. -* Python (requires version 2.6) -* CMake (tested with version 2.8) +Basic usage +=========== -Requirements to build the GUI (optional): +Run the application you want to trace as -* Qt (tested with version 4.7) + apitrace trace --api API /path/to/application [args...] -* QJSON (tested with version 0.7.1) +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. +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. -Linux / Mac OS X ----------------- +Follow the "Tracing manually" instructions below if you cannot obtain a trace. -Build as: +View the trace with - cmake -H. -Bbuild - make -C build + apitrace dump application.trace -You can also build the 32bit GL wrapper on 64bit distro with a multilib gcc by -doing: +Replay an OpenGL trace with - cmake -H. -Bbuild32 -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_EXE_LINKER_FLAGS=-m32 - make -C build32 glxtrace + glretrace application.trace +Pass the `-sb` option to use a single buffered visual. Pass `--help` to +glretrace for more options. -Windows -------- -Additional requirements: +Basic GUI usage +=============== -* Microsoft Visual Studio (tested with 2008 version) or MinGW (tested with gcc version 4.4) +Start the GUI as -* Microsoft DirectX SDK (tested with August 2007 release) + qapitrace application.trace -To build with Visual Studio first invoke CMake GUI as: +You can also tell the GUI to go directly to a specific call - cmake-gui -H. -B%cd%\build + qapitrace application.trace 12345 -and press the _Configure_ button. -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. +Advanced command line usage +=========================== -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: +Call sets +--------- - cmake --build build --config MinSizeRel +Several tools take `CALLSET` arguments, e.g: -The steps to build 64bit version are similar, but choosing _Visual Studio 9 -2008 Win64_ instead of _Visual Studio 9 2008_. + apitrace dump --calls CALLSET foo.trace + glretrace -S CALLSET foo.trace -It's also possible to instruct `cmake` build Windows binaries on Linux with -[MinGW cross compilers](http://www.cmake.org/Wiki/CmakeMingw). +The call syntax is very flexible. Here are a few examples: + * `4` one call -Usage -===== + * `1,2,4,5` set of calls + * `"1 2 4 5"` set of calls (commas are optional and can be replaced with whitespace) -Linux ------ + * `1-100/2` calls 1, 3, 5, ..., 99 -Run the application you want to trace as + * `1-1000/draw` all draw calls between 1 and 1000 - LD_PRELOAD=/path/to/glxtrace.so /path/to/application + * `1-1000/fbo` all fbo changes between calls 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. + * `frame` all calls at end of frames -View the trace with + * `@foo.txt` read call numbers from `foo.txt`, using the same syntax as above - /path/to/tracedump application.trace | less -R -Replay the trace with - /path/to/glretrace application.trace +Tracing manually +---------------- -Pass the `-sb` option to use a single buffered visual. Pass `--help` to -glretrace for more options. +### Linux ### -Start the GUI as +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 + +But beware of wrapper shell scripts -- what matters is the architecture of the +main process. + +Run the application you want to trace as - /path/to/qapitrace application.trace + 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 +127,84 @@ 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 + +### 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: + + """ + service zygote ... + setenv LD_PRELOAD /data/egltrace.so + ... + """ + + 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. -Usage on Mac OS X is similar to Linux above, except for the tracing procedure, -which is instead: + +- 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 + + 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 @@ -143,22 +213,246 @@ Note that although Mac OS X has an `LD_PRELOAD` equivalent, `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. + -Windows -------- +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. -* Copy `opengl32.dll`, `d3d8.dll`, or `d3d9.dll` from build/wrappers directory - to the directory with the application you want to trace. -* Run the application. +For Direct3D applications you can follow the same procedure used for +[instrumenting an application for PIX](http://technet.microsoft.com/en-us/query/ee417250) -* View the trace with - /path/to/tracedump application.trace +Dump GL state at a particular call +---------------------------------- -* Replay the trace with +You can get a dump of the bound GL state at call 12345 by doing: - /path/to/glretrace application.trace + 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. + + +Regression testing +------------------ + +These are the steps to create a regression test-suite around **apitrace**: + +* obtain a trace + +* obtain reference snapshots, by doing on a reference system: + + mkdir /path/to/reference/snapshots/ + glretrace -s /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`: + + glretrace -s /path/to/test/snapshots/ application.trace + apitrace diff-images --output summary.html /path/to/reference/snapshots/ /path/to/test/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`, `LIBGL_DRIVERS_DIR`, or +`TRACE_LIBGL`. + +For example, on Linux: + + ./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 + +Or on Windows: + + python scripts\retracediff.py --retrace \path\to\glretrace.exe --ref-env TRACE_LIBGL=\path\to\reference\opengl32.dll application.trace Links @@ -166,6 +460,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) @@ -188,8 +484,12 @@ Closed-source: * [D3DSpy](http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/programmingguide/TutorialsAndSamplesAndToolsAndTips/Tools/D3DSpy.htm): the predecessor of PIX +* [NVIDIA PerfKit](http://developer.nvidia.com/nvidia-perfkit) + * [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx) +* [Intel Graphics Performance Analyzers](http://www.intel.com/software/gpa/) + OpenGL ------ @@ -202,9 +502,11 @@ Open-source: * [tracy](https://gitorious.org/tracy): OpenGL ES and OpenVG trace, retrace, and state inspection +* [WebGL-Inspector](http://benvanik.github.com/WebGL-Inspector/) + Closed-source: -* [gDEBugger](http://www.gremedy.com/products.php) +* [gDEBugger](http://www.gremedy.com/products.php) and [AMD gDEBugger](http://developer.amd.com/tools/gDEBugger/Pages/default.aspx) * [glslDevil](http://cumbia.informatik.uni-stuttgart.de/glsldevil/index.html)