tracing on demand

[Eugene Velesevich]

2013/3/27 José Fonseca <jose.r.fonseca at gmail.com>

> On Tue, Mar 26, 2013 at 4:48 PM, Peter Lohrmann
> <peterl at valvesoftware.com> wrote:
>
> > 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.


The Enter() section and the Leave() one uses a recursive mutex, therefore
even if the "real" GLcall calls another one, deadlock will not occur. Am I
missing something here?

> 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.


 Incidentally, I think such organization have resulted in a qapitrace bug.
Example:
 We are tracing a multithreaded application. The first thread calls some GL
function and writes the Enter() section into the trace file. At the same
moment, the second thread makes swapbuffers call and writes into the trace
file. Then the first writes the Leave() section.

Open the tracefile. Qapitrace passes the trace file and creates the list of
frames. The traceloader makes a frame boundary bookmark on the second part
of the first thread's call (the first part is present in the parser
buffer). But when we open this frame, the buffer will not keep the first
part and qapitrace will crash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20130327/91cbbb21/attachment.html>