<div dir="ltr">> <span style="font-size:12.8px"> But I'm afraid any sort of algorithm</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Jose</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 9:36 PM, José Fonseca <span dir="ltr"><<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm only removing <i>trim-auto</i> (the state tracking command), not plain <i>trim</i> (the Swiss knife tool).   And I've actually removed the former earlier today already...<div><div><br></div><div>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</div><div><br></div><div>BTW, I forgot to mention another potential solution for this sort of problems which doesn't rely on state tracking, suggested on <a href="https://github.com/apitrace/apitrace/issues/433" target="_blank">https://github.com/<wbr>apitrace/apitrace/issues/433</a> . 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.</div><div><br></div><div>Jose<div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 7:47 PM, Mark Janes <span dir="ltr"><<a href="mailto:mark.a.janes@intel.com" target="_blank">mark.a.janes@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Yesterday Curro described to me a novel approach he used to trim a<br>
Kerbal Space Program trace.  I think it's worth hearing what he came up<br>
with before removing trim.<br>
<br>
Curro, can you describe your method of working backwards through the<br>
trace file to resolve dependencies, rather than tracking everything from<br>
the start?  What was the improvement in memory consumption during trim,<br>
and how much could you reduce a trace by when trimming to a single frame?<br>
<span class="m_3891098662610657661gmail-HOEnZb"><font color="#888888"><br>
-Mark<br>
</font></span><div class="m_3891098662610657661gmail-HOEnZb"><div class="m_3891098662610657661gmail-h5"><br>
José Fonseca <<a href="mailto:jose.r.fonseca@gmail.com" target="_blank">jose.r.fonseca@gmail.com</a>> writes:<br>
<br>
> Hi,<br>
><br>
> In sake of shrinking apitrace code base and keeping things maintainable I<br>
> plan to remove the `apitrace trim-auto` functionality.<br>
><br>
> trim-auto was added in 2013 by Carl Worth, and is capable of trimming<br>
> frames for simple traces, but it hasn't been maintained since, and<br>
> generalising to complex traces is IMO an almost vertical uphill battle.<br>
> From what I gather from several bug reports, I'm personally not aware of<br>
> users being actually able to use this in practice as it stands.<br>
><br>
> Furthermore, I think that any attempt to "state tracking" in apitrace is<br>
> doomed to failure, particularly with the OpenGL API.  This is because<br>
> OpenGL API is mish mash of inconsistent extensions and it would require an<br>
> army of developers to pull it off, and neither will change in the<br>
> foreseeable future.  In fact, there are good chances that OpenGL is<br>
> destined to be a legacy API and attracts less and less mind share.<br>
><br>
> So, yes, while having Apitrace recording/replaying the all calls from the<br>
> very start is admittedly very dumb and slow, it's something that is both<br>
> *reliable* and *simple*.  And that's good enough for me, and for a lot of<br>
> people I suspect.  At any rate, it trumps complex and unreliable all the<br>
> time.<br>
><br>
> That said, if watching glretrace to replay every call from scratch for<br>
> every state lookup is too much to bear, then the suggestion of<br>
> <a href="https://github.com/janesma/apitrace/wiki/frameretrace-branch" rel="noreferrer" target="_blank">https://github.com/janesma/api<wbr>trace/wiki/frameretrace-branch</a> of making<br>
> glretrace sort of a daemon that keeps looping the calls withing a frame of<br>
> interest seems a much better compromise.  That should work a lot of the<br>
> time, and it's not really that complex, since there's no need for tracking<br>
> any state other than the frame boundaries.<br>
><br>
> So I'll yank this out.  If anybody has any concern or has been using this<br>
> functionality with success please do let me know.<br>
><br>
> Jose<br>
</div></div><div class="m_3891098662610657661gmail-HOEnZb"><div class="m_3891098662610657661gmail-h5">> ______________________________<wbr>_________________<br>
> apitrace mailing list<br>
> <a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/apitrace" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/apitrace</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div>