X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=README.markdown;h=a80c9bec6dcfb05d4c3a0f16ad3a09cc9c2b98aa;hb=refs%2Fheads%2Fglx-copy-sub-buffer;hp=4c1828bf5f078a4277a0bc42404649084b7179c5;hpb=a4f17e79c837971f258213e0c45a9efe7183341e;p=apitrace diff --git a/README.markdown b/README.markdown index 4c1828b..a80c9be 100644 --- a/README.markdown +++ b/README.markdown @@ -3,23 +3,29 @@ About **apitrace** **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 @@ -43,15 +49,23 @@ View the trace with 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 =========================== @@ -62,22 +76,22 @@ Call sets 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 @@ -90,7 +104,7 @@ Tracing manually ### 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 @@ -98,22 +112,25 @@ or 32 bits. This can be done by doing 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 @@ -122,12 +139,17 @@ 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: +### 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 ### @@ -164,57 +186,91 @@ 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) -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 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. -For Direct3D applications you can follow the same procedure used for -[instrumenting an application for PIX](http://technet.microsoft.com/en-us/query/ee417250) +- `ID3DUserDefinedAnnotation::BeginEvent`, + `ID3DUserDefinedAnnotation::EndEvent`, and + `ID3DUserDefinedAnnotation::SetMarker` for D3D11.1 applications. -Dump GL state at a particular call +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: @@ -230,26 +286,66 @@ This works only on Unices, and it will truncate the traces due to performance 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 -Triming a trace ---------------- + apitrace dump-images -o - application.trace \ + | avconv -r 30 -f image2pipe -vcodec ppm -i - -vcodec mpeg4 -y output.mp4 -You can make a smaller trace by doing: +Recording a video with gstreamer +-------------------------------------- - apitrace trim --callset 100-1000 -o trimed.trace applicated.trace +You can make a video of the output with gstreamer by doing + + 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 ====================================== @@ -267,17 +363,13 @@ These are the steps to create a regression test-suite around **apitrace**: * 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 +* to do a regression test, use `apitrace diff-images`: - Alternatively, for a HTML summary, 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/ @@ -288,7 +380,7 @@ 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 +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: @@ -303,7 +395,7 @@ 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. @@ -328,8 +420,8 @@ 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 +`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). @@ -340,72 +432,79 @@ 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 +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) +Advanced GUI usage +================== - * [Intercept Calls to DirectX with a Proxy DLL](http://www.codeguru.com/cpp/g-m/directx/directx8/article.php/c11453/) +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. -* [Direct3D 9 API Interceptor](http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html) +In order to target a remote device, use the command-line: -Closed-source: + qapitrace --remote-target -* [Microsoft PIX](http://msdn.microsoft.com/en-us/library/ee417062.aspx) +In order for this to work, the following must be available in the +system configuration: - * [D3DSpy](http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/programmingguide/TutorialsAndSamplesAndToolsAndTips/Tools/D3DSpy.htm): the predecessor of PIX +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: -* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx) + ssh glretrace + 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: -OpenGL ------- + ssh xdpyinfo -Open-source: + 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). -* [BuGLe](http://www.opengl.org/sdk/tools/BuGLe/) + 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. -* [GLIntercept](http://code.google.com/p/glintercept/) + 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: -* [tracy](https://gitorious.org/tracy): OpenGL ES and OpenVG trace, retrace, and state inspection + 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 at the same path + in the filesystem as the path on the host system being + passed to the qapitrace command line. -* [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)