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

Marek Olšák maraeo at gmail.com
Sat Sep 10 05:28:55 PDT 2011


I have rebased the branch and added a few commits.

Most notably, ARB_debug_output is now always enabled. I had to change
the GLDEBUGPROCARB type in the glapi xml file to void*, otherwise the
generator couldn't parse it. After that I regenerated the glapi API
files, so that the extension can actually be used.

I took a quick look at the patches, but didn't read the spec and
didn't do any testing.

It's here, ready to be tested with any driver:
git://people.freedesktop.org/~mareko/mesa debug-output


On Thu, May 5, 2011 at 2:33 AM, nobled <nobled at dreamwidth.org> wrote:
> 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
>>> 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:
>>>                          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).
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list