tracing on demand

[Jordan Justen]

Peter,

Hi. I was wondering if your start-stop-trace3 branch had your latest
efforts on this feature?

I was also what your future plans are on this branch. Is it still
something you plan to push forward for inclusion in upstream apitrace?

Thanks,

-Jordan

On Mon, Mar 25, 2013 at 3:49 PM, Peter Lohrmann
<peterl at valvesoftware.com> wrote:
> I've spent the past week getting up to speed on apitrace, mostly looking
> into the trace implementation and getting it to trace API calls for a single
> frame, specified by frame number on the CLI. On its own I don't think this
> is particularly interesting (and the same result can already be obtained by
> a full trace & trim to single frame), but there were some bugs in the code
> generation that I had to fix if tracing is not enabled (look at
> wglGetProcAddress not exposing the GREMEDY entrypoints and glGetStringi not
> callling glGetStringi_override(), as two examples).
>
>
>
> I'm now planning to implement the tracing on demand, which I saw requested
> here: https://github.com/apitrace/apitrace/issues/31 My ultimate goal is to
> allow for a keypress to snapshot the state at the start of the next frame,
> and then record that frame's API calls. Initially this is just to capture a
> single frame which can then be replayed, but that can easily be extended to
> multiple frames in the future. I have implemented similar functionality in
> the past, so it won't be a difficult feat, but will take time. I don't plan
> to track state throughout the applications execution, which you have
> suggested would be a hard task (and I agree), but instead to take a thorough
> snapshot of all state and buffers and then generate API calls to reproduce
> that state.
>
>
>
> As part of this implementation, distinguishing between real calls and fake
> ones to replay correctly (https://github.com/apitrace/apitrace/issues/59 )
> can be resolved by wrapping the fake calls in a documented string marker. I
> don't know how many of those calls exist currently, but there will
> definitely be some to replicate the state snapshot at the start of a
> single-frame  trace.
>
>
>
> Let me know if you have any suggestions or concerns based on the above,
>
>    Peter
>
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>