Removing `apitrace trim-auto`

Tue Apr 11 21:40:39 UTC 2017

Mark Janes <mark.a.janes at intel.com> writes:

> 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?
>

I've been doing a bunch of hacking on the auto-trim dependency tracking
code during the last couple of weeks in order to trim down some traces
that were getting annoyingly large and were unnecessarily time-consuming
to replay for benchmarking purposes.  First off I'd like to make it
clear that I generally agree with José's point here -- Due to the nature
of the GL API getting 100% accurate dependency tracking is an
overwhelming amount of work, because most state is global and any single
command can potentially affect and be affected by an unbounded (and at
times rather vaguely defined) set of state.  That said, facing the
reality that I had to deal with the GL API want it or not, I felt like
fixing an automated tool to do the work for me (at least to the point
that it would suit my immediate needs) would be significantly less
painful than trimming the traces manually, so I decided to give it a
shot.

In order to get it to work satisfactorily for my purposes I had to teach
it about some not-so-recent GL features like buffer objects, vertex
arrays, memory mappings, renderbuffer and texture framebuffer
dependencies, etc.  The result seemed considerably more accurate (in the
sense of lower trimmed trace size and no more misrendering) but I hit a
serious performance problem of the current dependency tracking
mechanism.  Apparently the current algorithm uses a huge amount of
memory that grows combinatorially with the size of the trace because at
every draw call it needs to resolve and re-insert any dependency edges
transitively involved in the current draw call, so it would end up using
large amounts of memory and getting OOM-killed even on the Xeon server
under my desk for moderately-sized traces.  I came up with a workaround
that substantially improves the situation by representing the dependency
graph as an immutable data structure (somewhat abusing
std::shared_ptr<const T> for structural sharing) that uses a roughly
linear amount of memory on the trace size, which might be acceptable in
many cases but may still run out of memory while trying to trim large
enough traces on a laptop.  I think it should be possible to improve
things substantially beyond that if we're able to parse the trace file
backwards, because we would be able to determine at the point we reach a
GL call whether the state it modifies is going to be used later on or
not with a basically constant amount of storage (though of course still
linear on the amount of GL state in flight).  Implementing this in
practice didn't seem quite as straightforward though, because of the way
the parser and file handling code currently works, and because the
tracefile format doesn't seem particularly well-suited for being parsed
in reverse.  It seems like it should be doable anyway, but it's likely
to get somewhat invasive and I'm unlikely to have the time in the
short-term, so I wouldn't mind somebody else picking this up.

In any case I have a feeling that getting this feature to a usable state
will involve a near full rewrite of the dependency analysis code, so I
don't think there would be any damage from pulling off the feature in
the meantime particularly if it would decrease your maintenance
burden -- Feel free to count my ACK.

For the curious here's my current proof-of-concept (ignore the unrelated
and rather experimental changes at the top of the branch intended to
improve the CPU utilization of glretrace):

https://cgit.freedesktop.org/~currojerez/apitrace/log/

> -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
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/apitrace
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/apitrace/attachments/20170411/12ff08b6/attachment.sig>