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.
>> 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. 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
