X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=README.markdown;h=48748747dff85d2d914c87b1b4aa010db4995e2f;hb=0f48706319d715bea08cad23fc233a46b9f9f224;hp=2d37898f820bf88c2b42e68820f8abddee3928b1;hpb=5785b4f8e6bebc89c85316253ab4f763065a0264;p=apitrace

diff --git a/README.markdown b/README.markdown
index 2d37898..4874874 100644
--- a/README.markdown
+++ b/README.markdown
@@ -145,10 +145,6 @@ If you are an application developer, you can avoid this either by linking with
 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 ###
 
 To trace standalone native OpenGL ES applications, use
@@ -201,15 +197,23 @@ 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 GL extensions regardless the GL
+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:
@@ -230,8 +234,13 @@ detect and use GL extensions, you could easily accomplish this by doing:
 
 This has the added advantage of working equally well with gDEBugger.
 
+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_EXT_debug_marker`](http://www.khronos.org/registry/gles/extensions/EXT/EXT_debug_marker.txt)
 extension.
 
@@ -294,14 +303,20 @@ You can make a video of the output with gstreamer by doing
 Trimming a trace
 ----------------
 
-You can make a smaller trace by doing:
+You can truncate a trace by doing:
 
-    apitrace trim --callset 100-1000 -o trimed.trace applicated.trace
+    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'
 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
 -----------------