On Mon, Jun 3, 2013 at 10:41 AM, Jose Fonseca <jfons...@vmware.com> wrote: > ----- Original Message ----- >> On Fri, May 31, 2013 at 10:18 AM, José Fonseca <jose.r.fons...@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.. 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 BR, -R > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev