tracing on demand

José Fonseca jose.r.fonseca at gmail.com
Wed Mar 27 03:04:09 PDT 2013


On Tue, Mar 26, 2013 at 4:48 PM, Peter Lohrmann
<peterl at valvesoftware.com> wrote:
> glCreateShaderProgramv - ah, thanks for the warning. I knew you could query shader source, but didn't realize you could compile sources directly into a program object.
>
> Unconditionally tracing some of the calls could definitely be a useful.
>
> I guess I meant that I wouldn't be tracking ALL the state throughout the start of the trace, but will track the few cases which can't be queried.  OpenGLES may need more tracking than desktop GL. Once I get there, I'll figure out the best approach. I did see the retrace/state* classes, and will probably want to utilize those classes. I haven't fully investigated how the retrace captures the state, but I'll be digging into that in the next day or so.
>
> Another question: is there a particular reason the _gl* api call is made between Begin\EndEnter() and Begin\EndLeave() calls to the localWriter?

A lock is held between inside the Begin/EndEnter()  pair, and the
Begin/EndLeave().  It's better to call the real GL call without the
lock held, or it could potentially deadlock.

> Do the Enter and Leave sections get utilized in the retrace to help with profiling? or is it primarily for organization of the trace file?

It is for organization of the trace file, particular in respect to
multithreaded calls (where you can have two calls in two threads that
overlap in time) , or reentrant calls (e.g, wglSetPixelFormat
typically ends causing other wgl calls before returning, which could
be quite confusing).

So although the dumps attempt to show calls as a linear and ordered
sequence, reality could be much more complicated, but no matter how
complex reality is, trace binary representation can handle all weird
cases.

> I may have to have to reorganize the wgltrace.cpp file so that I can take advantage of the trace file writing without having duplicated code in various places, and don't want to break anything that I'm not yet aware of.

wgltrace.cpp is code generated, so any changes there should be done in
wgltrace.py, the script that generates it.


apitrace was a one man project for a very long time, so unfortunately
some parts are poorly documentated. If you find that a particular
piece of code would benefit from more comments please do not hesitate
sending some patches. It'd be highly appreciated.


Jose


More information about the apitrace mailing list