gl.spec and gl.tm

Seems that all the Uniform pointer commands are using a wrong array size calculation. Any hope this get fixed?

For instance:


UniformMatrix4fv(location, count, transpose, value)
	return		void
	param		location	Int32 in value
	param		count		SizeI in value
	param		transpose	Boolean in value
	param		value		Float32 in array [count]
	category	VERSION_2_0
	version		2.0
	...

The value parameter should actually be:

param value Float32 in array [16*count]

I’m generating a wrapper for a checked language directly from the spec and tm files… and this is utterly annoying.

Also it seems, that sometimes real GL types are used in gl.spec instead of mappings from gl.tm - and some types are missing in gl.tm like (U)Int64 (only (U)Int64EXT contained) and the sync object is missing too…

Cheers,
E1

Also it seems, that sometimes real GL types are used in gl.spec instead of mappings from gl.tm

If there’s no entry in the .tm, just use it as is.

To tell you the truth, i dont think gl.spec/gl.tm files are maintained with correctness in mind, but rather in a way that keeps internal parsers generating header files happy.

IOW, i wouldnt count on having elegant parser without host of specialcases for reading spec files anytime soon, i even seen a solution depending on header files instead (these have to compile, so some degree of correctness is enforced) to get similar info (but this isnt the right way for you it appears).

Personally, I have given up on getting the [array size] parameters working. I am only checking whether the spec defines something inane like “value Float32 in array [1]” (1-sized array instead of reference, nice!) and map this to a pointer/reference instead of a full-blown array (C#/.Net).

Moreover, I am using XML files to override various problems/issues/missing information from the headers and add strongly-typed enumerations. You can find up to date latest versions in the SVN server for OpenTK.

If you are interested in this, I can detail a number of rules that are necessary to parse the spec files correctly.

Well, I’d be interested in that :slight_smile:

I’ve got my own crude GL debugger that currently parses the header files to generate an OpenGL wrapper that one LD_PRELOADs. My code for parsing the header files has been a bit error-prone though. I had figured the better approach would be to write a parser for the spec files and generate code from there rather than fixing the header file parser. I, of course, haven’t gotten around to doing that yet. So any tips about how to go about doing that correctly would be appreciated :slight_smile:

So you with to create a wrapper .so. Suggestion: for this use, ignore the .specs completely. They are inconsistent and rather difficult to parse.

What is the alternative you ask? Mesa3d of course!

Not only do they maintain the specs in XML (you want “gl_API.xml”), they also have ready-made parsers/code generators written in Python (gl_XML.py).

Unless you want to go closed-source, it doesn’t get any better than that. You can use/modify the generator to create your wrapper .so and focus on the debugging part (which is far more interesting - and not to mention useful!)

Please keep us updated on your progress, the community is sorely missing a free, up-to-date OpenGL debugger.

As inconsistent and “difficult to parse” they may be, the Mesa3d ones are missing information. I saw nothing on uniform buffers, basic GL 3.0 stuff (glGetStringi, for example).

And of course, it doesn’t cover WGL.

Also, you should probably look into glIntercept. It is open-source, and it does most of what you’re talking about. It hasn’t been updated in 4 years, so it’s sorely in need of modernizing.

Indeed, mesa doesn’t ship its own WGL headers as far as I know.

Regarding the .spec files, Haskell OpenGL has a good writeup with instructions on parsing. It’s a great starting point.

The specs are difficult to parse. They are quite inconsistent and buggy and while most bugs don’t appear when you create simple C headers, they will bite you as soon as you try anything more advanced. The OP provides a good example. Other issues: duplicate enums (merge them), duplicate tokens (ignore the duplicate), missing tokens (patch by hand), invalid token/enum references (guess), invalid enum parameter types (guess using the function category or version name).

Finally, you are in for a world of fun if you wish to provide overloads instead of distinct “[234][fdui]v?” suffixes. These regexes might be of use:


Regex endingsToTrim = new Regex(@"((((d|f|fi)|u?[isb])_?v?)|v)", RegexOptions.Compiled | RegexOptions.RightToLeft);
Regex endingsNotToTrim = new Regex("(ib|[tdrey]s|[eE]n[vd]|bled|Flag|Tess|Status|Pixels|Instanced|Indexed|Varyings|Boolean|IDs)", RegexOptions.Compiled | RegexOptions.RightToLeft);

while most bugs don’t appear when you create simple C headers, they will bite you as soon as you try anything more advanced.

But of course, that’s what the spec files are for :wink:

This may also be one of the reasons they still use that spec format. Anytime they want to change it, they’ll try to invent the perfect spec format. And that’s generally more trouble than it’s worth.

Not exactly.

The specs contain much more information than what is (or can be) used in the C headers. Some of it is said to be used as part of the build process for various drivers. Other parts can be used to create strongly-typed enumerations (unfortunately, functions defined after OpenGL 1.4 use generic GLenum types instead of exact enums - in OpenTK, we’ve fixed this by hand for every single function up to 3.2). Finally, there’s stuff like glx protocol information, display-list compatibility that is simply not exposed in the C headers.

The main issue is that the .spec files change over time. New directives are being added, old ones fall in disuse or start being used inconsistently… Fortunately, things have gotten better after the 3.0 release - several long-standing bugs have been fixed and the editors seem to have gotten much more aggressive. I think the new deprecation directives have played a large part in this.

FYI, there is no problem defining the “perfect spec format” to capture all .spec information (porting everything to XML is less than a day’s worth of work). The issue is that drivers have come to rely on the .spec files to build and the IHVs (rightly or not) resist any change to their build process. (No, I’m not making this up - you can search these forums for the exact quote if you wish. It was made by Jon Leech around the 3.0 release, if I remember correctly.)

The irony on the matter is this quote on the registry, added around 2007: “Yes, these databases should be moved to a modern XML-based format. Patience.” :stuck_out_tongue:

The issue is that drivers have come to rely on the .spec files to build and the IHVs (rightly or not) resist any change to their build process.

But you can use the XML to generate the .spec files…