Removing `apitrace trim-auto`

[José Fonseca]

I'm only removing *trim-auto* (the state tracking command), not plain *trim*
(the Swiss knife tool).   And I've actually removed the former earlier
today already...

The old trim-auto did recursive passes over the trace to figure out
dependencies.  I always said that doing one single forward pass,
accumulating all dependencies between all state objects in memory would
probably be more effective.  Anyway, the algorithmic complexity is
fixable.  But I'm afraid any sort of algorithm

BTW, I forgot to mention another potential solution for this sort of
problems which doesn't rely on state tracking, suggested on
https://github.com/apitrace/apitrace/issues/433 . One might be able to
driver DD.py to automatically extract a minimum trace by setting the goal
matching the exact rendering done at draw call XYZ.

Jose

On Tue, Apr 11, 2017 at 7:47 PM, Mark Janes <mark.a.janes at intel.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/apitrace/attachments/20170411/f001be01/attachment.html>