<div dir="ltr">This seems to be along the lines of<div><br></div><div> <a href="https://github.com/PeterLValve/apitrace/tree/start-stop-trace2" target="_blank">https://github.com/PeterLValve/apitrace/tree/start-stop-trace2</a></div><div><div><br></div><div>which sort of was a prototype for VOGL.</div><div><br></div><div>But it looks like VOGL is loosing steam [1], and instead their efforts are being focused on Vulkan/Glave. I believe they got to a point where certain class of GL apps would work, but getting this to work with all apps easily becomes an herculian effort, no matter how many resources are put behind it.</div><div><br></div><div>With the VOGL experience I'm now convinced: the approach of trace start/stop by dumping state on start (ie, start-stop-trace2/VOGL) can only work with "concise" APIs like Direct3D (as proven by PIX/VisualStudioGraphicsDebugger/RenderDoc) or Vulkan (as proved with Glave), but it is unfeasible with OpenGL since it is _huge_, full of legacy state, not well defined capability/feature levels, and a lot of state can't be fetched with glGet* calls.</div><div> <br></div><div>I know `apitrace trim` has issues, but I'm now convinced that the only way we can ever have _robust_ single frame capture is indeed to record the whole thing from start, annotate the trace when the hot-key is pressed, then trim offline everything that's unnecessary for the desired frame.</div><div><br></div><div>The advantages of this is that:</div><div><br></div><div>- whereas with serializing current state any bug in the current state serialization will yield a buggy trace, which needs to be retraced; off-line triming preserves all information, so we can fix apitrace trimming without needing to get another trace from the app</div><div><br></div><div>- serializing current state will also serialize bugs in dynamically generated textures. For example, if a game generates textures at initialization time, and there's a bug (in the app or openlg implementation) at that time, if you just serialize that texture at the begingging of that frame you will not capture the calls that actually generated the error. Whereas with trimming all information should be preserved.</div><div><br></div><div>Unfortunately I don't have much time to improve trimming (in fact I believe we need a big refactor/rewrite so that it operates with a single pass.) but in my mind that's the only way forward.</div><div><br></div><div>Jose</div><div><br></div><div>[1] <a href="https://twitter.com/g_truc/status/536988569597140993" target="_blank">https://twitter.com/g_truc/status/536988569597140993</a><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 2, 2015 at 12:13 PM, Juha-Pekka Heikkila <span dir="ltr"><<a href="mailto:juhapekka.heikkila@gmail.com" target="_blank">juhapekka.heikkila@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is a bit rfc'y set of what I've been toying with recently, for commenting<br> round for now. Idea for single frame capture is coming from people claiming<br> trimming of traces not working or being too slow.<br> <br> What this set does is allow glxtrace.so run in the background but not<br> necessarily writing everything into trace file. Setting environment variable<br> APITRACE_SINGLE_FRAME_CAPTURE_MODE to 1 causes alternative tracing mode to<br> be active. Once number is written to /tmp/apitrace_capture_frame_now.txt<br> glxtrace.so wakes up to writing everything into trace file, number written<br> into the file indicate how many following frames will be recorded. What I am<br> currently poking at to make better is gl state rebuilding code which can be<br> seen at end of glxtrace.py. Currently glxgears works for me when enable<br> tracing from the middle of glxgears execution.<br> <br> Anyhow, if someone see something funny, weird or just plain wrong I'll be happy<br> to see the comments. Implementation for enable/disable writing of trace file<br> in trace writer class is a bit hackish' but it was least amount of changes I<br> thought of thus its the way it is. I had only glx in mind for now with<br> highlighting places for changes needed for egl and adroid later.<br> <br> Simple steps to try this out would go as:<br> <br> APITRACE_SINGLE_FRAME_CAPTURE_MODE=1 LD_PRELOAD=./glxtrace.so glxgears &<br> echo 3 > /tmp/apitrace_capture_frame_now.txt<br> <br> After closing glxgears one should see three frames written into<br> glxgears.trace file.<br> <br> /Juha-Pekka<br> <br> Juha-Pekka Heikkila (3):<br> Support single frame capture with glx<br> Add support for display lists for single frame capture<br> Add gl state rebuilding code for single frame capture<br> <br> common/trace_writer.cpp | 29 ++++++---<br> common/trace_writer.hpp | 14 +++++<br> common/trace_writer_local.cpp | 138 ++++++++++++++++++++++++++++++++++++++++--<br> common/trace_writer_local.hpp | 10 +++<br> wrappers/egltrace.py | 8 +++<br> wrappers/glxtrace.py | 124 +++++++++++++++++++++++++++++++++++++<br> 6 files changed, 312 insertions(+), 11 deletions(-)<br> <span><font color="#888888"><br> --<br> 1.8.5.1<br> <br> _______________________________________________<br> apitrace mailing list<br> <a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br> </font></span></blockquote></div><br></div></div></div></div>