[PATCH 0/3][RFC] Support for single frame capture
Juha-Pekka Heikkila
juhapekka.heikkila at gmail.com
Mon Mar 23 01:51:03 PDT 2015
Hi José,
thanks for your comments. I had not noticed start-stop version of Apitrace.
I mostly agree with your points but there are some issues which I
suspect we think different. When people said trimming does not work I
don't see this idea as replacement for trimming but instead
complementary. Start/Stop tracing in any situation will never be 100%
perfect for recreating the state but skilled user can be able to
overcome this limitation. I've been using different applications to let
them create their state and then go rebuild it with help from gl spec,
this will never yield 100% coverage but builds umbrella of
regenerateable states for features people seem to have been using. As
you mention not all state variables can be queried with glGet*, I
already early hit those but my solution is just to let these be written
to trace regardless if they're needed or no.
Where having possibility to start/stop tracing really helps is if one
know there will show a rendering bug but it takes time to reach that
point there will not be generated throwaway GBs of trace thus result
easier final trimming. As you pictured the idea of annotate frame of
interest while doing full tracing it will also have hard limit with disk
space usage even if trimming would be 1:1 time wise on playback.
While is was profiling trimming I notice most of the time is spent in
disk I/O. I was thinking about optimizing this with memory resident tree
structures but didn't come up with any workable idea (yet at least).
This was one of the possibilities I was thinking for start/stop tracing
- make the trimming fast enough to run while tracing is happening but
all solutions I found would consume too much memory. Have you come up
with ideas how to help trimming or you think it should be completely
rewritten?
In any case, I did continue on top of my rfc set. You can see current
state here: https://github.com/juhapekka/apitrace-1/tree/single_frame_writer
It now can regenerate state for Open Arena in my tests. Next I will take
some more challenging piece to work on, something with shaders.
/Juha-Pekka
On 11.03.2015 23:12, José Fonseca wrote:
> This seems to be along the lines of
>
> https://github.com/PeterLValve/apitrace/tree/start-stop-trace2
>
> which sort of was a prototype for VOGL.
>
> 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.
>
> 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.
>
> 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.
>
> The advantages of this is that:
>
> - 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
>
> - 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.
>
> 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.
>
> Jose
>
> [1] https://twitter.com/g_truc/status/536988569597140993
>
> On Mon, Mar 2, 2015 at 12:13 PM, Juha-Pekka Heikkila
> <juhapekka.heikkila at gmail.com <mailto:juhapekka.heikkila at gmail.com>> wrote:
>
> This is a bit rfc'y set of what I've been toying with recently, for
> commenting
> round for now. Idea for single frame capture is coming from people
> claiming
> trimming of traces not working or being too slow.
>
> What this set does is allow glxtrace.so run in the background but not
> necessarily writing everything into trace file. Setting environment
> variable
> APITRACE_SINGLE_FRAME_CAPTURE_MODE to 1 causes alternative tracing
> mode to
> be active. Once number is written to /tmp/apitrace_capture_frame_now.txt
> glxtrace.so wakes up to writing everything into trace file, number
> written
> into the file indicate how many following frames will be recorded.
> What I am
> currently poking at to make better is gl state rebuilding code which
> can be
> seen at end of glxtrace.py. Currently glxgears works for me when enable
> tracing from the middle of glxgears execution.
>
> Anyhow, if someone see something funny, weird or just plain wrong
> I'll be happy
> to see the comments. Implementation for enable/disable writing of
> trace file
> in trace writer class is a bit hackish' but it was least amount of
> changes I
> thought of thus its the way it is. I had only glx in mind for now with
> highlighting places for changes needed for egl and adroid later.
>
> Simple steps to try this out would go as:
>
> APITRACE_SINGLE_FRAME_CAPTURE_MODE=1 LD_PRELOAD=./glxtrace.so glxgears &
> echo 3 > /tmp/apitrace_capture_frame_now.txt
>
> After closing glxgears one should see three frames written into
> glxgears.trace file.
>
> /Juha-Pekka
>
> Juha-Pekka Heikkila (3):
> Support single frame capture with glx
> Add support for display lists for single frame capture
> Add gl state rebuilding code for single frame capture
>
> common/trace_writer.cpp | 29 ++++++---
> common/trace_writer.hpp | 14 +++++
> common/trace_writer_local.cpp | 138
> ++++++++++++++++++++++++++++++++++++++++--
> common/trace_writer_local.hpp | 10 +++
> wrappers/egltrace.py | 8 +++
> wrappers/glxtrace.py | 124
> +++++++++++++++++++++++++++++++++++++
> 6 files changed, 312 insertions(+), 11 deletions(-)
>
> --
> 1.8.5.1
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org <mailto:apitrace at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>
More information about the apitrace
mailing list