Removing `apitrace trim-auto`

[José Fonseca]

>  But I'm afraid any sort of algorithm

Forgot to finish this sentence.  What I meant is that I'm afraid that any
sort of algorithm to trim that relies on state tracking is dead in the
water IMO.

Jose

On Tue, Apr 11, 2017 at 9:36 PM, José Fonseca <jose.r.fonseca at gmail.com>
wrote:

> 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/35327312/attachment-0001.html>