[Mesa-dev] [PATCH 0/11] implement GL_ARB_debug_output

[nobled]

On Tue, May 3, 2011 at 7:33 PM, Brian Paul <brianp at vmware.com> wrote:
> On 05/02/2011 04:59 PM, nobled wrote:
>>
>> git repo:
>> https://github.com/nobled/mesa.git
>> (branch: arb_debug_output, rebased on
>> bd661a933b18fccd7102d05932774ee61a90ec9e)
>>
>> web interface:
>> https://github.com/nobled/mesa/commits/arb_debug_output
>>
>> spec:
>> http://www.opengl.org/registry/specs/ARB/debug_output.txt
>>
>> This series adds almost everything needed to advertise the extension
>> GL_ARB_debug_output. The only thing missing is the ability to pass an
>> array of IDs to glDebugMessageControlARB with the parameter 'source'
>> having the value GL_DEBUG_SOURCE_APPLICATION_ARB or
>> GL_DEBUG_SOURCE_THIRD_PARTY_ARB.
>>
>> Since the *ControlARB stuff was the part I was least certain about, I
>> also broke it up into even smaller patches. What I think is needed to
>> fill in the missing functionality is a structure that works like C++'s
>> std::map, with a GLuint/GLboolean key/value pair. There would also
>> need to be, for each map, three std::set-like structures that record
>> the HIGH, MEDIUM, and LOW-severity message IDs. Otherwise it wouldn't
>> be possible for clients to make calls like this that impact all
>> messages of a certain severity level:
>>
>> glDebugMessageControlARB(GL_DEBUG_SOURCE_APPLICATION_ARB, GL_DONT_CARE,
>>                          GL_DEBUG_SEVERITY_LOW_ARB, 0, NULL, GL_TRUE);
>>
>> Does mesa have structures like those in the auxiliary code somewhere?
>> Or is there a way to wrap the C++ STL in C code?
>
> To map GLuint to 'something' we typically use the hash table in hash.c
>  Otherwise, you could make something based on simple_list.h.  I believe
> we're talking about a pretty small set of GLuints, right?  So linear search
> wouldn't be a big deal?
>
>
>> Open question: The app might pass 'implementation-dependent' message
>> IDs to glDebugMessageControlARB that don't actually exist in mesa. The
>> spec doesn't say whether we should give an error or silently ignore
>> IDs like that.
>>
>> Also an open question: what to do when apps misbehave and send the
>> same source/type/message ID tuple to glDebugMessageInsertARB twice or
>> more, but with different severity levels each time, and then they call
>> glDebugMessageControlARB on all messages with a certain severity.
>> Should mesa use the latest-specified severity as the canonical one, or
>> the first?
>
> I haven't even read the spec for this extension yet so I don't have any
> answers for you.
>
> I did a quick review of your patches and they mostly look OK.  I'll post
> specific comments in a bit.
>
> It looks like almost all the changes are confined to errors.c and mtypes.h
> so I'm not too worried about regressions or a big impact on the rest of the
> code.
>
> I'm OK with you committing what you have and following up with changes
> if/when the above questions get answered.
>
> -Brian
>
>

Okay, I revised and rebased the branch on github based on your
comments. Now there are several new patches implementing the final
pieces and enabling the extension by default when the environment
variable MESA_DEBUG is set (the same way it enables the current stderr
debug messages).