[Mesa-dev] and a random apitrace/gallium question..
jfonseca at vmware.com
Mon Jun 3 07:41:56 PDT 2013
----- Original Message -----
> On Fri, May 31, 2013 at 10:18 AM, José Fonseca <jose.r.fonseca at gmail.com>
> > 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).
- apitrace's glretrace should be extended with an option (--insert-markers) that would annotated the GL command stream with calls like:
GL_DEBUG_SOURCE_THIRD_PARTY, // We still filter out these messages.
-1, "Call 123456");
but only where there is a bound countext and (probably only outside glBegin/glEnd).
and it should call
glDebugMessageControlARB(GL_DEBUG_SOURCE_THIRD_PARTY, GL_DONT_CARE, GL_DONT_CARE, 0, NULL, GL_FALSE);
to prevent dumping its own messages.
- gallium interface should be extended with a new method
pipe_context::insert_marker(pipe_context *, const char *marker)
which would be called for at least GL_DEBUG_SOURCE_THIRD_PARTY (and potentially GL_DEBUG_SOURCE_APPLICATION), but only on debug builds.
This is for full GL. For GLES we could do the same via EXT_debug_marker.txt's glInsertEventMarkerEXT.
> I could probably handle the gallium bits to let the driver intercept
> the messages.
I'd appreciate that. As I'm afraid I don't have the time to do it myself, and it is probably better if this is done on a driver that actually cares about this.
I'd just wait a couple more days before start executing to give opportunity for others to voice any concerns/suggestions.
More information about the mesa-dev