<div dir="ltr">Thanks.  That sounds handy.<div><br></div><div>Another potentially very useful improvement along those lines, would be for apitrace to replay <span style="color:rgb(0,0,0);white-space:pre-wrap">GL_KHR_debug's</span> gl<span style="color:rgb(0,0,0);white-space:pre-wrap">ObjectLabel() calls, and then use those application supplied labels instead of numbers when dumping state (in qapitrace).  This would enable the app developer (or gl implementer) to see e.g. "rock texture" instead "texture 99". And it would be relatively easy to implement on top of what you probably have.</span></div>
<div><font color="#000000"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">Of course, this would require GL apps and vendors to use/implement GL_KHR_debug. But given that it is part of OpenGL 4.3 standard, and is a small superset of ARB_debug_output, that shouldn't be an obstacle.<br>
</span></font><div class="gmail_extra"><br></div><div class="gmail_extra">Jose<br><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 5:29 PM, Peter Lohrmann <span dir="ltr"><<a href="mailto:peterl@valvesoftware.com" target="_blank">peterl@valvesoftware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I have a local change which extends ApiTrace to better support the various debug extensions, and have used it to mark up my traces. I don't track the whole log or handle the registering of callback functions, but do allow glDebugMessageInsertARB(..) and a few others to be included in the trace (and will get replayed if the host driver supports the extension). This allows those messages to also be used by other 3rd party debugging tools.<br>

<br>
At some point I hope to extend qapitrace to utilize these markers in the list of api calls to give a hierarchical view, but that's a ways off.<br>
<br>
I'll try to isolate that change and create a branch today to make it more widely available.<br>
<span class=""><font color="#888888"> - Peter<br>
</font></span><div class=""><div class="h5"><br>
-----Original Message-----<br>
From: apitrace-bounces+peterl=<a href="mailto:valvesoftware.com@lists.freedesktop.org">valvesoftware.com@lists.freedesktop.org</a> [mailto:<a href="mailto:apitrace-bounces%2Bpeterl">apitrace-bounces+peterl</a>=<a href="mailto:valvesoftware.com@lists.freedesktop.org">valvesoftware.com@lists.freedesktop.org</a>] On Behalf Of Rob Clark<br>

Sent: Monday, June 03, 2013 8:59 AM<br>
To: Jose Fonseca<br>
Cc: <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>; <a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
Subject: Re: [Mesa-dev] and a random apitrace/gallium question..<br>
<br>
On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote:<br>
><br>
><br>
> ----- Original Message -----<br>
>> On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote:<br>
>> > ----- Original Message -----<br>
>> >> On Fri, May 31, 2013 at 10:18 AM, José Fonseca<br>
>> >> <<a href="mailto:jose.r.fonseca@gmail.com">jose.r.fonseca@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > I'd support such change. Be it through GL_GREMEDY_string_marker,<br>
>> >> > or ARB_debug_output's<br>
>> >> > glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB,<br>
>> >> > ...), or KHR_debug's glPushDebugGroup(). A Gallium interface<br>
>> >> > change would be necessary to pass these annotations to the<br>
>> >> > drivers. This discussion would be more appropriate in Mesa-dev<br>
>> >> > mailing list though.<br>
>> ><br>
>> > I looked at the relevant specs (KHR_debug, ARB_debug_output), and I<br>
>> > believe the most natural / standard-compliant way of implementing<br>
>> > this would be to rely on glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB).<br>
>><br>
>> hmm, these look more about letting the gl driver send log msgs to the<br>
>> app..<br>
><br>
> Far from it. The spec is crystal clear on that regard, from <a href="http://www.opengl.org/registry/specs/KHR/debug.txt" target="_blank">http://www.opengl.org/registry/specs/KHR/debug.txt</a> :<br>
><br>
>     [...]<br>
><br>
>     This extension also defines debug markers, a mechanism for the OpenGL<br>
>     application to annotate the command stream with markers for discrete<br>
>     events.<br>
<br>
ahh, my bad.. I stopped reading too soon :-P<br>
<br>
yeah, then it sounds like a good fit<br>
<br>
BR,<br>
-R<br>
<br>
>     [...]<br>
><br>
>     5.5.1 - Debug Messages<br>
><br>
>     A debug message is uniquely identified by the source that generated<br>
>     it, a type within that source, and an unsigned integer ID<br>
>     identifying the message within that type.  The message source is<br>
>     one of the symbolic constants listed in Table 5.3.  The message<br>
>     type is one of the symbolic constants listed in Table 5.4.<br>
><br>
>     Debug Output Message Source           Messages Generated by<br>
>     ---------------------------           ---------------------<br>
>     DEBUG_SOURCE_API_ARB                  The GL<br>
><br>
>     DEBUG_SOURCE_SHADER_COMPILER_ARB      The GLSL shader compiler or compilers for<br>
>                                           other extension-provided<br>
> languages<br>
><br>
>     DEBUG_SOURCE_WINDOW_SYSTEM_ARB        The window system, such as WGL or GLX<br>
><br>
>     DEBUG_SOURCE_THIRD_PARTY_ARB          External debuggers or third-party middleware<br>
>                                           libraries<br>
><br>
>     DEBUG_SOURCE_APPLICATION_ARB          The application<br>
><br>
>     DEBUG_SOURCE_OTHER_ARB                Sources that do not fit to any of the ones listed above<br>
>     ----------------------------------------------------------------------------<br>
>     Table 5.3: Sources of debug output messages.  Each message must originate<br>
>     from a source listed in this table.<br>
><br>
><br>
>> although maybe it is the best extension we have?<br>
><br>
> It seems to fit our needs quite well AFAICT.  KHR_debug is pretty much a superset of everything out there, plus it is part of core OpenGL 4.3.  And there is even a source for our needs -- DEBUG_SOURCE_THIRD_PARTY_ARB -- "External debuggers"...<br>

><br>
> Jose<br>
_______________________________________________<br>
apitrace mailing list<br>
<a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
_______________________________________________<br>
apitrace mailing list<br>
<a href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
</div></div></blockquote></div><br></div></div></div>