Hi, 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 Marek On Thu, May 5, 2011 at 2:33 AM, nobled <nob...@dreamwidth.org> wrote: > On Tue, May 3, 2011 at 7:33 PM, Brian Paul <bri...@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). > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev