[Mesa-dev] features.txt & EXT_debug_label extension

[Eero Tamminen]

Hi,

On 14.02.2017 21:06, Ian Romanick wrote:
> On 02/10/2017 02:56 AM, Eero Tamminen wrote:
>> On 09.02.2017 19:30, Ian Romanick wrote:
>>> On 02/09/2017 05:19 PM, Eero Tamminen wrote:
>>>> When checking GL errors for "Unturned" (Steam top-20 Unity3D based
>>>> game), I noticed that it uses functions from extension unsupported by
>>>> Mesa, and missing from "features.txt":
>>>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_debug_label.txt
>>>>
>>
>> ---------------------------------
>> New Procedures and Functions
>>
>>     void LabelObjectEXT(enum type, uint object, sizei length,
>>         const char *label);
>>     void GetObjectLabelEXT(enum type, uint object, sizei bufSize,
>>         sizei *length, char *label);
>> ---------------------------------
>>
>>>> Could it be added to "features.txt" file?
>>>
>>> I thought the functionality of that extension was folded into some other
>>> ARB (or KHR) extension... GL_KHR_debug, maybe?
>>
>> Yes, that has similar functionality, and Mesa already supports it:
>> https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_debug.txt
>>
>> Just with different function names:
>>
>>     void ObjectLabel(enum identifier, uint name, sizei length,
>>         const char *label);
>>
>>     void GetObjectLabel(enum identifier, uint name, sizei bufSize,
>>         sizei *length, char *label);
>>
>> As fairly new & commonly used Unity3D game and Apitrace both support the
>> EXT versions, I think it makes sense add aliases also for the EXT variants.
>
> I checked both extensions, and they're not "just" aliases.  The EXT adds
> a single function with an enum to select the kind of object.  The KHR
> adds a function per kind of object.  It would be easy enough to add, but
> it seems more valuable to suggest the developer use the more broadly
> supported extension. :)

Reading the apitrace source, it was actually apitrace, that added
that extension for application:
------------------------------------------------------
// Additional extensions to be advertised
static const char *
extraExtension_stringsFull[] = {
     "GL_GREMEDY_string_marker",
     "GL_GREMEDY_frame_terminator",
     "GL_ARB_debug_output",
     "GL_AMD_debug_output",
     "GL_KHR_debug",
     "GL_EXT_debug_marker",
     "GL_EXT_debug_label",
     "GL_VMWX_map_buffer_debug",
};

static const char *
extraExtension_stringsES[] = {
     "GL_KHR_debug",
     "GL_EXT_debug_marker",
     "GL_EXT_debug_label",
};
------------------------------------------------------

Then in the apitrace documentation:
------------------------------------------------------
**apitrace** will advertise and intercept these OpenGL extensions regardless
of whether the OpenGL implementation supports them or not.  So all you have
to do is to use these extensions when available, and you can be sure they
will be available when tracing inside **apitrace**.
...
Also, provided that the OpenGL implementation supports `GL_KHR_debug`, 
labels
defined via glObjectLabel() , and the labels of several objects (textures,
framebuffers, samplers, etc. ) will appear in the GUI state dumps, in the
parameters tab.
------------------------------------------------------

I.e. KHR_debug appears to be better support by apitrace.

Googling a bit more on which one seems more commonly in use, I would 
guess that it was the game itself, not Unity3D which chose to use 
GL_EXT_debug_label instead of KHR_debug.  One reason for choosing that 
might be OSX, as I saw this in apitrace sources:
------------------------------------------------------
         # Fallback to EXT_debug_label on MacOSX, some enums need to be 
translated.
------------------------------------------------------

(And knowing that KHR_DEBUG is in GLES 3.2 & GL 4.3, which OSX AFAIK 
doesn't yet support.)


	- Eero