apitrace trim misbehaviour

[Carl Worth]

Andre Heider <a.heider at gmail.com> writes:
> apitrace trim told me to write this ;)

Hi, Andre. Thanks for following those instructions.

> That took >2.5h at 100% load on tmpfs on a i5-3570K and gave me a
> trace that fails to replay.

That certainly must be frustrating. It's bad enough that it takes that
long, but then to have it not work after all that is pretty bad.

My current plan is actually to throw away the current trim
implementation after writing something new that replays the trace up
until the first frame of interest, then reads out all the OpenGL state
necessary from the OpenGL implementation, and then finally copies the
original trace data. That should be much, much faster than the current
trim time, (basically, no longer than it takes to replay the trace).

We've talked about experimenting with an implementation along those
lines for a long time. But I'm now getting to the point where I've got a
lot of motivation to sit down and actually do that soon. So I'm hoping
that will happen soon and that it will help with things like this.

At the same time, it would also be nice to have the current trim code
functioning. It's easy to imagine cases where a bug in an OpenGL
implementation causes the above-described replay-based trimming to
introduce a bug into the trimmed trace. (And this is perhaps not
unlikely when a trace is being used to demonstrate a bug in the OpenGL
implementation.)

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20131112/e48beab9/attachment.pgp>