[Mesa-dev] and a random apitrace/gallium question..
peterl at valvesoftware.com
Mon Jun 3 09:29:02 PDT 2013
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.
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
> 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
ahh, my bad.. I stopped reading too soon :-P
yeah, then it sounds like a good fit
> 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
> DEBUG_SOURCE_WINDOW_SYSTEM_ARB The window system, such as WGL or GLX
> DEBUG_SOURCE_THIRD_PARTY_ARB External debuggers or third-party middleware
> 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"...
apitrace mailing list
apitrace at lists.freedesktop.org
More information about the mesa-dev