[Mesa-dev] and a random apitrace/gallium question..
robdclark at gmail.com
Mon Jun 3 08:11:39 PDT 2013
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>
>> > 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.. although maybe it is the best extension we have?
Anyways, I'll give a few days to see if anyone else has any opinions
and then try to figure out how to hook it up through gallium
> In particular:
> - 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.
> GL_DEBUG_TYPE_OTHER, 123456,
> -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