[Mesa-dev] and a random apitrace/gallium question..

[José Fonseca]

Thanks.  That sounds handy.

Another potentially very useful improvement along those lines, would be for
apitrace to replay GL_KHR_debug's glObjectLabel() 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.

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.

Jose

On Mon, Jun 3, 2013 at 5:29 PM, Peter Lohrmann <peterl at valvesoftware.com>wrote:

> 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.
>
> 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.
>
> I'll try to isolate that change and create a branch today to make it more
> widely available.
>  - Peter
>
> -----Original Message-----
> From: apitrace-bounces+peterl=valvesoftware.com at lists.freedesktop.org[mailto:
> apitrace-bounces+peterl=valvesoftware.com at lists.freedesktop.org] On
> Behalf Of Rob Clark
> Sent: Monday, June 03, 2013 8:59 AM
> To: Jose Fonseca
> Cc: mesa-dev at lists.freedesktop.org; apitrace at lists.freedesktop.org
> Subject: Re: [Mesa-dev] and a random apitrace/gallium question..
>
> On Mon, Jun 3, 2013 at 11:56 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
> >
> >
> > ----- Original Message -----
> >> On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca <jfonseca at vmware.com>
> wrote:
> >> > ----- Original Message -----
> >> >> On Fri, May 31, 2013 at 10:18 AM, José Fonseca
> >> >> <jose.r.fonseca at gmail.com>
> >> >> wrote:
> >> >> > I'd support such change. Be it through GL_GREMEDY_string_marker,
> >> >> > or ARB_debug_output's
> >> >> > glDebugMessageInsertARB(DEBUG_SOURCE_THIRD_PARTY_ARB,
> >> >> > ...), or KHR_debug's glPushDebugGroup(). A Gallium interface
> >> >> > change would be necessary to pass these annotations to the
> >> >> > drivers. This discussion would be more appropriate in Mesa-dev
> >> >> > mailing list though.
> >> >
> >> > I looked at the relevant specs (KHR_debug, ARB_debug_output), and I
> >> > believe the most natural / standard-compliant way of implementing
> >> > this would be to rely on
> glDebugMessageInsertARB(GL_DEBUG_SOURCE_THIRD_PARTY_ARB).
> >>
> >> hmm, these look more about letting the gl driver send log msgs to the
> >> app..
> >
> > Far from it. The spec is crystal clear on that regard, from
> http://www.opengl.org/registry/specs/KHR/debug.txt :
> >
> >     [...]
> >
> >     This extension also defines debug markers, a mechanism for the OpenGL
> >     application to annotate the command stream with markers for discrete
> >     events.
>
> ahh, my bad.. I stopped reading too soon :-P
>
> yeah, then it sounds like a good fit
>
> BR,
> -R
>
> >     [...]
> >
> >     5.5.1 - Debug Messages
> >
> >     A debug message is uniquely identified by the source that generated
> >     it, a type within that source, and an unsigned integer ID
> >     identifying the message within that type.  The message source is
> >     one of the symbolic constants listed in Table 5.3.  The message
> >     type is one of the symbolic constants listed in Table 5.4.
> >
> >     Debug Output Message Source           Messages Generated by
> >     ---------------------------           ---------------------
> >     DEBUG_SOURCE_API_ARB                  The GL
> >
> >     DEBUG_SOURCE_SHADER_COMPILER_ARB      The GLSL shader compiler or
> compilers for
> >                                           other extension-provided
> > languages
> >
> >     DEBUG_SOURCE_WINDOW_SYSTEM_ARB        The window system, such as WGL
> or GLX
> >
> >     DEBUG_SOURCE_THIRD_PARTY_ARB          External debuggers or
> third-party middleware
> >                                           libraries
> >
> >     DEBUG_SOURCE_APPLICATION_ARB          The application
> >
> >     DEBUG_SOURCE_OTHER_ARB                Sources that do not fit to any
> of the ones listed above
> >
> ----------------------------------------------------------------------------
> >     Table 5.3: Sources of debug output messages.  Each message must
> originate
> >     from a source listed in this table.
> >
> >
> >> although maybe it is the best extension we have?
> >
> > 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"...
> >
> > Jose
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130603/b173441d/attachment-0001.html>