apitrace trim misbehaviour

[Peter Lohrmann]

I have a cleaned up version of my on-demand tracing code that i've been meaning to push back onto my repo and then hopefully get pulled into apitrace, although its fallen a bit out of date as of late. I am planning to get it merged with latest tree in December and make the cleaner version available.

- Peter

Sent from my iPhone

On Nov 12, 2013, at 3:11 PM, "José Fonseca" <jose.r.fonseca at gmail.com<mailto:jose.r.fonseca at gmail.com>> wrote:




On Tue, Nov 12, 2013 at 3:18 PM, Carl Worth <cworth at cworth.org<mailto:cworth at cworth.org>> wrote:
Andre Heider <a.heider at gmail.com<mailto: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



_______________________________________________
apitrace mailing list
apitrace at lists.freedesktop.org<mailto:apitrace at lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/apitrace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20131120/2d45eb49/attachment.html>