Trace file splitting / frame indexing method

[Zack Rusin]

On Tuesday, August 23, 2011 08:20:59 PM Jeremy Main wrote:
> José, Zack
> And all other mailing list lurkers.

Hi, Jeremy.

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

That's great to hear.

> 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.

While Jose is the file format master I have to say that I'm not sure if there's 
benefit to doing it like this. 
One of the issues is that GL doesn't have clear frame markers. The gui looks 
for glFrameTerminatorGREMEDY, CGLFlushDrawable, any SwapBuffers, but it also 
allows things like glFlush, glFinish or glClear to be used. So detecting it at 
trace time is error prone.

> 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.

We're pretty good at producing and parsing traces that were constructed by an 
app that crashed. In fact in the compression branch we should be able to 
produce traces valid all the way until the very last call and for the call 
which is broken we'll actually print out that it's broken. So we should be 
already dealing with this scenario.

> 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.

Yea, it's really the main reason why we haven't yet implemented a feature that 
we'd both love to see which is exporting a single frame from a trace as a 
standalone trace. It's certainly on our list though.

> 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.

Well, the issue as I see it is that every file besides the first wouldn't be 
standalone, the frame detection in many would be broken and we wouldn't be any 
better at handling broken apps so I'm not sure what the benefit of file 
splitting would be. Of course if I'm missing something and there's some benefit 
to it we should consider it. Every feature that would make this tool better is 
worth considering.

z