tracing on demand

[Peter Lohrmann]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20130325/43b48bc8/attachment.html>