I’m writing my own opengl extensions wrapper for private use.
Initially I’ve tried to parse system’s GL/gl{x,}{,ext}.h files to obtain information about extensions, as I believed that it would be much easier to parse code with known rules that specs from opengl.org without public syntax. However, after some work, I realized that too much information is simply missing from headers files and I was forced to hack upon spec “format”.
Well. I really don’t believe that specs should be in XML, they should be in RDB (database) instead, as keeping consistency with so much intersecting data in text files is, obviously, not an easy task, while database restrictions will keep this consistency for you. Anyway, I’m writing here to post a few discovered inconsistencies in spec files, that may or may not be bugs and a few obvious bugs.
As specs are essential for any opengl support on non C/C++ languages (opengl.org doesn’t provide files for other languages), they should be consistent and relatively easy to parse. At least, they should follow same conventions from one part to another.
There is my changes to specs that I’ve made to make my parser work (in fake diff format):
enumext.spec/ARB_gpu_shader5:
- use ARB_texture_multisample MAX_VERTEX_STREAMS
+ use ARB_transform_feedback3 MAX_VERTEX_STREAMS
enumext.spec/VERSION_4_0:
- passthru: /* Reuse tokens from ARB_transform_feedback2 */
- use ARB_tessellation_shader TRANSFORM_FEEDBACK
- use ARB_tessellation_shader TRANSFORM_FEEDBACK_BUFFER_PAUSED
- use ARB_tessellation_shader TRANSFORM_FEEDBACK_BUFFER_ACTIVE
- use ARB_tessellation_shader TRANSFORM_FEEDBACK_BINDING
- passthru: /* Reuse tokens from ARB_transform_feedback3 */
- use ARB_tessellation_shader MAX_TRANSFORM_FEEDBACK_BUFFERS
- use ARB_tessellation_shader MAX_VERTEX_STREAMS
+ passthru: /* Reuse tokens from ARB_transform_feedback2 */
+ use ARB_transform_feedback2 TRANSFORM_FEEDBACK
+ use ARB_transform_feedback2 TRANSFORM_FEEDBACK_BUFFER_PAUSED
+ use ARB_transform_feedback2 TRANSFORM_FEEDBACK_BUFFER_ACTIVE
+ use ARB_transform_feedback2 TRANSFORM_FEEDBACK_BINDING
+ passthru: /* Reuse tokens from ARB_transform_feedback3 */
+ use ARB_transform_feedback3 MAX_TRANSFORM_FEEDBACK_BUFFERS
+ use ARB_transform_feedback3 MAX_VERTEX_STREAMS
reason:
There is no MAX_VERTEX_STREAMS in ARB_texture_multisample
(and enum.spec -> enumext.spec converter seems to ignore extensions with digits)
enumext.spec/NV_fog_distance:
- use TextureGenParameter EYE_PLANE
+ use VERSION_1_1_DEPRECATED EYE_PLANE
enumext.spec/NV_register_combiners:
- use BlendingFactorDest ZERO
- use DrawBufferMode NONE
- use GetPName FOG
+ use VERSION_1_1 ZERO
+ use VERSION_1_1 NONE
+ use VERSION_1_1_DEPRECATED FOG
reason:
There is no such extensions, this is a categories in original
enum.spec (which is one big inconsistency at the first place.
No doubt there is a problem to properly convert it).
enumext.spec/ARB_tessellation_shader:
- use VERSION_1_1 QUADS
+ use VERSION_1_1_DEPRECATED QUADS
enumext.spec/VERSION_3_0:
- use ARB_framebuffer_object INDEX
+ use ARB_framebuffer_object_DEPRECATED INDEX
enumext.spec/VERSION_3_0_DEPRECATED:
- use ARB_framebuffer_object TEXTURE_LUMINANCE_TYPE
- use ARB_framebuffer_object TEXTURE_INTENSITY_TYPE
+ use ARB_framebuffer_object_DEPRECATED TEXTURE_LUMINANCE_TYPE
+ use ARB_framebuffer_object_DEPRECATED TEXTURE_INTENSITY_TYPE
reason:
Let's mark deprecated stuff as DEPRECATED explicitly. While
it's possible to look for _DEPRECATED suffix while resolving
links, specs are already hard to parse properly enough.
enumext.spec/SGIX_polynomial_ffd:
- FfdMaskSGIX enum:
- TEXTURE_DEFORMATION_BIT_SGIX = 0x00000001
- GEOMETRY_DEFORMATION_BIT_SGIX = 0x00000002
-
- SGIX_polynomial_ffd enum:
- GEOMETRY_DEFORMATION_SGIX = 0x8194
+ SGIX_polynomial_ffd enum:
+ TEXTURE_DEFORMATION_BIT_SGIX = 0x00000001
+ GEOMETRY_DEFORMATION_BIT_SGIX = 0x00000002
+ GEOMETRY_DEFORMATION_SGIX = 0x8194
reason:
There is no such extension in OpenGL Registry, and it seems
to be another bug of enum.spec->enumext.spec converter
enumext.spec/SGIX_ycrcb_subsample:
- PACK_SUBSAMPLE_RATE_SGIX = 0x85A0
- UNPACK_SUBSAMPLE_RATE_SGIX = 0x85A1
- PIXEL_SUBSAMPLE_4444_SGIX = 0x85A2
- PIXEL_SUBSAMPLE_2424_SGIX = 0x85A3
- PIXEL_SUBSAMPLE_4242_SGIX = 0x85A4
+ use SGIX_subsample PACK_SUBSAMPLE_RATE_SGIX
+ use SGIX_subsample UNPACK_SUBSAMPLE_RATE_SGIX
+ use SGIX_subsample PIXEL_SUBSAMPLE_4444_SGIX
+ use SGIX_subsample PIXEL_SUBSAMPLE_2424_SGIX
+ use SGIX_subsample PIXEL_SUBSAMPLE_4242_SGIX
reason:
Conflicting enums, later extension should reuse enums
from prior one.
glx.spec/SGIX_hyperpipe:
- passthru: typedef struct {
- passthru: char pipeName[GLX_HYPERPIPE_PIPE_NAME_LENGTH_SGIX];
- passthru: int channel;
- passthru: unsigned int
- passthru: participationType;
- passthru: int timeSlice;
- passthru: } GLXHyperpipeConfigSGIX;
- passthru:
+ passthru: typedef struct {
+ passthru: char pipeName[GLX_HYPERPIPE_PIPE_NAME_LENGTH_SGIX];
+ passthru: int channel;
+ passthru: unsigned int participationType;
+ passthru: int timeSlice;
+ passthru: } GLXHyperpipeConfigSGIX;
+ passthru:
reason:
Despite being unformatted passthru, it's even not consistent
with previous usages. That's not funny - situation is bad
enough already.
enumext.spec/VERSION_4_0:
- use ARB_gpu_shader5 MAX_VERTEX_STREAMS
+ use ARB_transform_feedback3 MAX_VERTEX_STREAMS
reason:
Let's import from some one place
Maybe it would be better to post it on bugzilla?
And a few thoughts about specs themselfs.
-
Passthru. Is. Evil. Really. There is another languages, not only C/C++, you know - and you are hiding important information (like typedefs or #ifdef protections against external headers) within non-formatted passthru. All vital information should be marked explicitly. Types, probably, should be in another spec.
-
Enumext.spec is ext-grouped, but function-specs (gl.spec, glxext.spec) are ext-grouped only partially (via bad-named tags newcategory:, endcategory: (later only in glxext.spec))
-
Typedefs (in passthru’s) are protected by #ifndef’s only partially, SGIX_hyperpipe struct’s are non-protected and protected magically by internal script logics (probably by using newcategory:, endcategory:).
-
enum.spec is… well… strange. Not sure that it’s usable outside Khronos Group in any way - there is groups-by-ext and groups-by-logic.
-
Having significantly different syntax for function-specs and enum-specs is really frustrating.
-
If you really like text-files so much, IMO it would be better to use YAML instead of XML for future use, as it’s much more readable by humans (and easier to parse).
-
There is enum “use”'s and “alias”'es (sharing same enum value by different names). Some aliases are resolved during enum.spec->enumext.spec conversion, but others are left as-is. That’s strange.
BTW, I’ve managed to import almost every bit of information from specs files into internal perl structures, so it should be relatively straightforward to push this information into other format, XML, YAML or RDB…