[gl.xml] Functions using raw GLenum without group

[tsuoranta]

Functions which use raw GLenum directly, without enum group:

Introduced in GL_VERSION_3_1:

• glGetIntegeri_v()

Introduced in GL_VERSION_3_2:

• glGetInteger64i_v()

Introduced in GL_VERSION_4_1:

• glGetDoublei_v()
• glGetFloati_v()
• glGetProgramBinary()
• glProgramBinary()
• glShaderBinary()

Introduced in GL_ES_VERSION_2_0:

• glShaderBinary()

Introduced in GL_ES_VERSION_3_0:

• glGetInteger64i_v()
• glGetIntegeri_v()
• glGetProgramBinary()
• glProgramBinary()

Introduced in GL_OES_texture_3D:

• glCopyTexSubImage3DOES()

Introduced in GL_OES_get_program_binary:

• glGetProgramBinaryOES()

Introduced in GL_EXT_debug_label:

• glLabelObjectEXT()

Introduced in GL_OES_get_program_binary:

• glProgramBinaryOES()

Introduced in GL_EXT_debug_label:

• glGetObjectLabelEXT()

I might create pull requests to fix at least some of these, either by applying existing enum group, or creating new enum groups.

[Perksey]

This will probably need to be done by members of the community, as the groupings are essentially "deprecated" and aren't maintained by Khronos as much as they used to.

[frederikja163]

might be relevant to #335,

[Perksey]

Discard the file that Fred previously attached as there was a bug in GLSpecTools. Here's an updated copy:
ungrouped_enums.master.txt

[pdaniell-nv]

Is this issue still relevant now that #335 is being addressed?

[SunSerega]

I think commands of non-depricated features and extensions should all have group for every GLenum and GLbitfield.
This fact isn't affected by how group are specified.

[Perksey]

There isn't a lot of engineering effort going into the groups due to them not being used at all for Khronos purposes, bar Google's ANGLE project which is the only usage I've seen by a member of Khronos. As such, all group improvements need to be done by community members. I am currently the volunteering group maintainer as it were, and I do intend to improve the groupings as part of my Silk.NET project (dotnet/Silk.NET#106), but I don't have a lot of time right now.

Improvements to the groups will happen over time - the way I see it now that all the big modifications are done you just need to give it some time to heal. If what you're after is some sort of requirement for groupings, I'm sorry but that will just never happen as there are no benefits for Khronos.

[SunSerega]

Strong requirement isn't really possible, at least because there are some extensions which aren't even properly documented, so no one can know which enums can be passed in that extension's commands.

I'm only talking about keeping this issue open until someone like you and me would find time to create groups for all non-deprecated commands.

[Perksey]

There is little to no chance that anyone will be able to create groups for a 27 year old monolithic spec such as this, so I wouldn’t count on it and I’m having a hard time not being pessimistic about the groups. Im sure it’s fine leaving the issue open but the problem is it may never get closed.

…

On Fri, 31 Jan 2020 at 00:08, Sun Serega ***@***.***> wrote: Strong requirement isn't really possible, at least because there are some extensions which aren't even properly documented, so no one can know which enums can be passed in that extension's commands. I'm only talking about keeping this issue open until someone like you and me would find time to create groups for all non-deprecated commands. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#318?email_source=notifications&email_token=ACVEYI5JS2W3HR47MU2OWYTRANTX5A5CNFSM4JACWC2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKNAV2Y#issuecomment-580520683>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVEYI6MFV5M4AJUHGHPHR3RANTX5ANCNFSM4JACWC2A> .