Removing `apitrace trim-auto`

[Mark Janes]

Yesterday Curro described to me a novel approach he used to trim a
Kerbal Space Program trace.  I think it's worth hearing what he came up
with before removing trim.

Curro, can you describe your method of working backwards through the
trace file to resolve dependencies, rather than tracking everything from
the start?  What was the improvement in memory consumption during trim,
and how much could you reduce a trace by when trimming to a single frame?

-Mark

José Fonseca <jose.r.fonseca at gmail.com> writes:

> Hi,
>
> In sake of shrinking apitrace code base and keeping things maintainable I
> plan to remove the `apitrace trim-auto` functionality.
>
> trim-auto was added in 2013 by Carl Worth, and is capable of trimming
> frames for simple traces, but it hasn't been maintained since, and
> generalising to complex traces is IMO an almost vertical uphill battle.
> From what I gather from several bug reports, I'm personally not aware of
> users being actually able to use this in practice as it stands.
>
> Furthermore, I think that any attempt to "state tracking" in apitrace is
> doomed to failure, particularly with the OpenGL API.  This is because
> OpenGL API is mish mash of inconsistent extensions and it would require an
> army of developers to pull it off, and neither will change in the
> foreseeable future.  In fact, there are good chances that OpenGL is
> destined to be a legacy API and attracts less and less mind share.
>
> So, yes, while having Apitrace recording/replaying the all calls from the
> very start is admittedly very dumb and slow, it's something that is both
> *reliable* and *simple*.  And that's good enough for me, and for a lot of
> people I suspect.  At any rate, it trumps complex and unreliable all the
> time.
>
> That said, if watching glretrace to replay every call from scratch for
> every state lookup is too much to bear, then the suggestion of
> https://github.com/janesma/apitrace/wiki/frameretrace-branch of making
> glretrace sort of a daemon that keeps looping the calls withing a frame of
> interest seems a much better compromise.  That should work a lot of the
> time, and it's not really that complex, since there's no need for tracking
> any state other than the frame boundaries.
>
> So I'll yank this out.  If anybody has any concern or has been using this
> functionality with success please do let me know.
>
> Jose
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/apitrace