X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=README.markdown;h=7d858371ca4e9ea0552a619b45ac97ec7207b94b;hb=977400f966549e14f02ecdd7eb93830beee18f7d;hp=9702ba0739294d14c41c8c7eb1264c3491d1391a;hpb=ba3756bb4b57746e6c811e4194504e4aae004e3e;p=apitrace diff --git a/README.markdown b/README.markdown index 9702ba0..7d85837 100644 --- a/README.markdown +++ b/README.markdown @@ -118,14 +118,14 @@ 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`: +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 @@ -134,6 +134,9 @@ 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. @@ -148,49 +151,45 @@ 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 +(`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: @@ -198,7 +197,7 @@ tracing dynamically for the application to be traced. of pre-starting the apps, you might have to kill the application first: - # kill + kill Launch the application for example from the application menu. @@ -312,8 +311,8 @@ You can make a video of the output by doing | 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: @@ -324,6 +323,27 @@ 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 ====================================== @@ -486,9 +506,11 @@ Open-source: 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) -