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`:
+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
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.
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
+(`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
+ 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
- ...
- """
+ 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
+ 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
+ `/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
-
+ 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.
+ setprop debug.apitrace.procname com.android.settings
+ In general this name will match what `ps` reports.
- Start the application:
of pre-starting the apps, you might have to kill the application
first:
- # kill <pid of app>
+ kill <pid of app>
Launch the application for example from the application menu.
| ffmpeg -r 30 -f image2pipe -vcodec ppm -i pipe: -vcodec mpeg4 -y output.mp4
-Triming a trace
----------------
+Trimming a trace
+----------------
You can make a smaller trace by doing:
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
======================================
Closed-source:
+* [AMD CodeXL](http://developer.amd.com/tools/hc/CodeXL/Pages/default.aspx)
+
+* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
+
* [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)
-* [AMD GPU PerfStudio](http://developer.amd.com/gpu/PerfStudio/pages/APITraceWindow.aspx)
-