X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=README.markdown;h=5fa3ab96089b002e13a11e0cb07a35a2c8a9eea0;hb=7a9fb5103e052150232b64cb5d99374cda3f1234;hp=497351abe99697dc285e2c0607aaa48da2267f0e;hpb=73694fa14967ad586b5116c49665fb7884de68b8;p=apitrace diff --git a/README.markdown b/README.markdown index 497351a..5fa3ab9 100644 --- a/README.markdown +++ b/README.markdown @@ -3,65 +3,100 @@ 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; +* 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.com/) for more details. -Basic usage -=========== +Obtaining **apitrace** +====================== + +To obtain apitrace either [download the latest +binaries](http://apitrace.github.com/#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. -Linux and Mac OS X ------------------- + +Basic usage +=========== Run the application you want to trace as - /path/to/apitrace trace /path/to/application [args...] + 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 setting the -`TRACE_FILE` environment variable before running. +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. + +Follow the "Tracing manually" instructions below if you cannot obtain a trace. View the trace with - /path/to/apitrace dump --color application.trace | less -R + apitrace dump application.trace + +Replay an OpenGL trace with -Replay the trace with + apitrace replay application.trace - /path/to/glretrace application.trace +Pass the `--sb` option to use a single buffered visual. Pass `--help` to +`apitrace replay` for more options. -Pass the `-sb` option to use a single buffered visual. Pass `--help` to -glretrace for more options. + +Basic GUI usage +=============== Start the GUI as - /path/to/qapitrace application.trace + qapitrace application.trace +You can also tell the GUI to go directly to a specific call -Windows -------- + qapitrace application.trace 12345 -* 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. +Advanced command line usage +=========================== -* View the trace with - \path\to\apitrace dump application.trace +Call sets +--------- -* Replay the trace with +Several tools take `CALLSET` arguments, e.g: - \path\to\glretrace application.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 + + * `0,2,4,5` set of calls + + * `"0 2 4 5"` set of calls (commas are optional and can be replaced with whitespace) + + * `0-100/2` calls 1, 3, 5, ..., 99 + + * `0-1000/draw` all draw calls between 0 and 1000 + + * `0-1000/fbo` all fbo changes between calls 0 and 1000 + + * `frame` all calls at end of frames + + * `@foo.txt` read call numbers from `foo.txt`, using the same syntax as above -Advanced command line usage -=========================== Tracing manually @@ -69,22 +104,33 @@ Tracing manually ### Linux ### -Run the application you want to trace 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 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 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 @@ -93,9 +139,81 @@ to trace by using `glxtrace.so` as an ordinary `libGL.so` and injecting into 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: + + 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. + +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. + +- 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. + +To trace standalone applications do: + + adb push /path/to/apitrace/build/wrappers/egltrace.so /data + adb shell + # cd /data/local/tmp + # LD_PRELOAD=/data/egltrace.so test-opengl-gl2_basic + adb pull /data/local/tmp/test-opengl-gl2_basic.trace + apitrace replay test-opengl-gl2_basic.trace + ### Mac OS X ### Run the application you want to trace as @@ -107,11 +225,42 @@ 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: -Emitting annotations to the trace from GL applications ------------------------------------------------------- +* right clicking on the application's icon in the _Start Menu_, choose + _Properties_, and see the _Target_ field; -You can emit string and frame annotations through the +* 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. + +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) @@ -141,18 +290,33 @@ detect and use GL extensions, you could easily accomplish this by doing: 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: - /path/to/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. -You can compare two state dumps with the jsondiff.py script: +You can compare two state dumps by doing: - ./scripts/jsondiff.py 12345.json 67890.json + apitrace diff-state 12345.json 67890.json Comparing two traces side by side @@ -169,10 +333,43 @@ Recording a video with FFmpeg You can make a video of the output by doing - /path/to/glretrace -s - application.trace \ + apitrace dump-images -o - 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: + + apitrace replay --pgpu --pcpu --ppd foo.trace | ./scripts/profileshader.py + + Advanced usage for OpenGL implementors ====================================== @@ -186,23 +383,17 @@ These are the steps to create a regression test-suite around **apitrace**: * obtain a trace -* obtain reference snapshots, by doing: - - mkdir /path/to/snapshots/ - /path/to/glretrace -s /path/to/reference/snapshots/ application.trace +* obtain reference snapshots, by doing on a reference system: - on reference system. + mkdir /path/to/reference/snapshots/ + apitrace dump-images -o /path/to/reference/snapshots/ application.trace * prune the snapshots which are not interesting -* to do a regression test, do: - - /path/to/glretrace -c /path/to/reference/snapshots/ application.trace - - Alternatively, for a HTML summary, use the snapdiff script: +* to do a regression test, use `apitrace diff-images`: - /path/to/glretrace -s /path/to/current/snapshots/ application.trace - ./scripts/snapdiff.py --output summary.html /path/to/reference/snapshots/ /path/to/current/snapshots/ + apitrace dump-images -o /path/to/test/snapshots/ application.trace + apitrace diff-images --output summary.html /path/to/reference/snapshots/ /path/to/test/snapshots/ Automated git-bisection @@ -270,66 +461,20 @@ 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`. +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 \ + --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/) - -* [Direct3D 9 API Interceptor](http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html) - -Closed-source: - -* [Microsoft PIX](http://msdn.microsoft.com/en-us/library/ee417062.aspx) - - * [D3DSpy](http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/programmingguide/TutorialsAndSamplesAndToolsAndTips/Tools/D3DSpy.htm): the predecessor of PIX - -* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx) - - -OpenGL ------- - -Open-source: - -* [BuGLe](http://www.opengl.org/sdk/tools/BuGLe/) - -* [GLIntercept](http://code.google.com/p/glintercept/) - -* [tracy](https://gitorious.org/tracy): OpenGL ES and OpenVG trace, retrace, and state inspection - -Closed-source: - -* [gDEBugger](http://www.gremedy.com/products.php) - -* [glslDevil](http://cumbia.informatik.uni-stuttgart.de/glsldevil/index.html) - -* [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)