mesa/src/gallium/drivers/trace
Marek Olšák 4445e170be gallium: adapt to get_query_result interface change
Reviewed-by: Brian Paul <brianp@vmware.com>
2012-03-30 17:12:51 +02:00
..
Makefile gallium/drivers: Use automake to generate makefile 2012-03-14 10:25:59 -04:00
README st/python: Remove bindings, and all its dependencies. 2011-04-06 08:26:04 +01:00
SConscript scons: Add aliases for several pipe drivers. 2010-11-02 12:35:52 +00:00
tr_context.c gallium: adapt to get_query_result interface change 2012-03-30 17:12:51 +02:00
tr_context.h trace: Remove rbug from trace 2010-05-12 20:15:23 +01:00
tr_dump.c gallium/auxiliary: Remove os_stream. 2011-11-29 17:34:30 +00:00
tr_dump.h trace: Use pipe_static_mutex. 2011-03-06 09:11:13 +00:00
tr_dump_state.c gallium: improve the pipe_stream_output_info struct (v2) 2012-01-15 07:28:35 +01:00
tr_dump_state.h trace: Correct/cleanup. 2011-04-06 08:26:44 +01:00
tr_public.h rbug: Add to all targets that link against trace 2010-05-12 20:15:23 +01:00
tr_screen.c gallium: remove unused winsys pointers in pipe_screen and pipe_context 2012-02-21 21:09:16 +01:00
tr_screen.h rbug: Add to all targets that link against trace 2010-05-12 20:15:23 +01:00
tr_texture.c trace: Correct/cleanup. 2011-04-06 08:26:44 +01:00
tr_texture.h trace: Correct/cleanup. 2011-04-06 08:26:44 +01:00
trace.xsl trace: Number calls. 2009-03-25 21:04:05 +00:00

                             TRACE PIPE DRIVER


= About =

This directory contains a Gallium3D trace debugger pipe driver.
It can traces all incoming calls.


= Usage =

== Tracing ==

For tracing then do

 GALLIUM_TRACE=tri.trace trivial/tri

which should create a tri.trace file, which is an XML file. You can view copying 
trace.xsl to the same directory, and opening with a XSLT capable browser such as 
Firefox or Internet Explorer.

For long traces you can use the

  src/gallium/tools/trace/dump.py tri.trace | less -R


== Remote debugging ==

For remote debugging see:

  src/gallium/drivers/rbug/README


= Integrating =

You can integrate the trace pipe driver either inside the state tracker or the 
target. The procedure on both cases is the same. Let's assume you have a 
pipe_screen obtained by the usual means (variable and function names are just
for illustration purposes):

  real_screen = real_screen_create(...);
  
The trace screen is then created by doing

  trace_screen = trace_screen_create(real_screen);

You can then simply use trace_screen instead of real_screen.

You can create as many contexts you wish from trace_screen::context_create they
are automatically wrapped by trace_screen.


--
Jose Fonseca <jfonseca@vmware.com>
Jakob Bornecrantz <jakob@vmware.com>