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

Jose Fonseca 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>
> 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). 

In particular:

- apitrace's glretrace should be extended with an option (--insert-markers) that would annotated the GL command stream with calls like:

     glDebugMessageInsertARB(
         GL_DEBUG_SOURCE_THIRD_PARTY, // We still filter out these messages.
          GL_DEBUG_TYPE_OTHER, 123456,
          GL_DEBUG_SEVERITY_MEDIUM, 
          -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.

Jose


More information about the mesa-dev mailing list