On 09/04/2013 03:43 PM, Timothy Arceri wrote: > Hi Ian, > > Thanks for the review. An let me say I'm here to learn so sorry if my > questions/comments are something that should be obvious.
I wish I hadn't been so busy with the 9.2 release over the last couple weeks... and then took a couple much needed vacation days. I had wanted to review these patches before they landed, but I just never got to it. That's my fault. :( >>> Remap any type or severity exclusive to KHR_debug to >>> something suitable for ARB_debug_output > >> There is no need for any of this remapping. The only way the new enums >> can be passed back to the application is if the application specifically >> requests them by using functionality added by this extension. > >> This whole patch should be removed. > > I listed this as an assumption in my cover letter: > > * As both arb_debug_output and khr_debug have the same message log the > messages returned by the arb_debug_output functions need to be filtered > to return types/severitys that the caller expects (rather than new type > introduced byt khr_debug). To work around this just the types are just > remap them to types arb_debug_output understands. Even if an application gets a value they don't expect, it shouldn't be a problem. Release builds of apps should use this functionality. It's also fairly common for "layered" extensions to return new values, etc. that an application coded to the older extension may not expect. What I would be more worried about is an application using middleware that's coded to ARB_debug_output while the core of the application is coded to KHR_debug. The middleware calls glDebugMessageInsertARB, and the app never gets the message. The other experiment we could do is poke at the NVIDIA or AMD closed-source drivers to see what they do. I suspect they alias all the functions. It would be easy enough to put together a test case: call glDebugMessageInsert, call glGetDebugMessageLogARB, verify that the data came through with the type and severity unmodified. > Both the callbacks and GetDebugMessage just return what ever is in the log. > If for whatever reason > a developer was to mix and match the the functions (which I assume is > perfectly valid although obviously not the best idea) from the two extensions > then invalid types could be returned to the ARB functions. > I was just trying to handle all possible scenarios eligantly. Also I'm not > sure if its likely of not but couldnt the drivers acctaully want to use > GL_DEBUG_SEVERITY_NOTIFICATION for some messages say for example outputing > performance information rather than GL_DEBUG_SEVERITY_LOW. > It's fine by me if you want to leave all this up to the developers to handle > I was just trying to avoid any possible strange behaviours. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
