tracing on demand

[Mark Janes]

Hi Peter,

I am also interested in this capability.

thanks,

Mark Janes

On 10/14/2013 3:13 PM, Jordan Justen wrote:
> 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
>>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>