Trace file splitting / frame indexing method

Jeremy Main jeremy.main at jp.fujitsu.com
Tue Aug 23 17:20:59 PDT 2011


José, Zack
And all other mailing list lurkers.

I have just recently discovered your tool and find it very useful.

Having done something similar to apitrace (without the visual playback
functionality) as a testing / verification tool, I found it useful to split
the trace file into a user defined number of frames. 
For example 600 frames per trace (60FPS * 10sec) file split.
That would log the trace file like this:

FooGL.001.trace (frames 1 - 600)
FooGL.002.trace (frames 601 - 1200)
FooGL.003.trace (frames 1201 - 1800)

Within each of in the file headers, the frame start indexes could be stored
allowing for quick indexing of the frame start locations within each trace
file. Glretrace and qapitrace would both load the initial trace file and any
other trace files in the numbered sequence.
If the application is terminated before the context is destroyed and the
wrapper does not terminate normally, the final frame and any data that it
may have can be found by starting from the last known frame index location
until the end of the file. It could parse in a more conservative mode
knowing that the trace data may be abnormal at some point due to the lack of
a proper frame terminator.

I understand the OpenGL state machine and the requirements for playback to
be functional, a text dump or analysis of one frame could be quickly
performed using this frame indexing method, but playback would require all
state commands to be performed beforehand.

Let it be said I would love to see the state serialized at the start of each
trace chunk, but complete serialization of the OpenGL state would be a tall
task. Sure the actual state variables and stack could be serialized without
much trouble, but vertex arrays, display lists, textures, shaders, etc.
complicate that effort.

I am not sure if trace file splitting/indexing functionality would be
desirable, but I have found it useful to reign in large trace files in the
past.

Note, I have not looked into the code yet (except for building it), I hope
to contribute to your effort when possible.
Thank you both and to all other contributors for making the effort to bring
this tool to its current state.

Best regards,
Jeremy
(Yokohama, Japan)




More information about the apitrace mailing list