apitrace trim misbehaviour

[José Fonseca]

On Tue, Nov 12, 2013 at 3:18 PM, Carl Worth <cworth at cworth.org> wrote:

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

This slightly overlaps with the start-stop work that Peter Lohrmann did:

  https://github.com/apitrace/apitrace/issues/31
  https://github.com/PeterLValve/apitrace/tree/start-stop-trace3

But I have to confess that I'm still a bit skeptical of the feasibility of
accurately (de)serializing all OpenGL state from a live, arbitrary
application.  The OpenGL state machine is so huge and complex.  Take
glretrace dumping: spite the enormous amount of state and parameters, we
only dump a fraction of newer OpenGL 4.x state.  Furthermore, a lot of
state can't be fetched from.

Personally, I still believe that most reliable method for obtaining small
traces is starting with a full trace, then trimming a subset.  But with a
single forward trim pass, that accumulates call dependency chains as it
traverses the call list:

  https://github.com/apitrace/apitrace/issues/142#issuecomment-19431077
  http://lists.freedesktop.org/archives/apitrace/2012-April/000264.html

But I admit, whatever approach chosen, they are all slight variations of
"extremely hard".


There is another, radically different, approach: we could design an OpenGL
extension where apitrace would send to the application an event "please
destroy and recreate all you OpenGL state from scratch", and apitrace would
start recording from that point onward. Applications such as game engines
which maintain their own version of state, could probably support this
without much effort.   But for many arbitrary apps, refactoring their code
to support this would be unfeasible.


Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20131112/892e8795/attachment.html>