Registry update for 3.0 APIglext.h / .spec files

Sorry I can’t quickly find the spot in the SDK thread in which this came up, but I’ve just updated the public Registry with a glext.h and accompanying gl.spec / enumext.spec files defining the 3.0 APIs (as well as the enum assignments which were already out there).

The ARB extensions introduced along with 3.0 share the same entry points (e.g. no ARB suffixes), which is largely unprecedented. I’m not entirely set yet on how to present those, but the current scheme (define the entry points in the extension #ifdef block, not the VERSION_3_0 #ifdef block) seems acceptable.

There is a small chance that the ClearBuffer APIs might be tweaked a bit, but this should be very close to final. We’re still working with Mesa and NVIDIA folks on defining all the GLX protocol for the new commands, but that will come along fairly soon as well.

There are also updates for a bunch of NV and EXT extensions.

Thanks. Can you tell us whether the .spec files will be kept in the future? (see also)

CatDog

I’m not sure how you mean “kept”. The spec files are the actual registry for GL commands and tokens, and they get updated when there’s something new to put in them. Usually updates will lag new core API or extension specification documents by a bit.

I have some desire to move them to an XML format, as noted in the thread you pointed to - but all the existing tools and scripts use the existing text format, at least one major IHV has that format wired into their internal driver build system, and designing a good schema that accomodates all the same information is a bigger job than I’ve had spare time for yet.

Well, I’m pretty shure that this IHV is not the only one. For instance I’ve got my private spec parser, too. What I really wanted to know was, whether there are concrete plans to kick the spec files in favour of some XML format. If I got your answer right, this will not happen in the near future. Fine!

I just don’t want to waste time on the new 3.0 spec files and two weeks later you come up with an XML version. That’s all.

CatDog

I’m not entirely set yet on how to present those, but the current scheme (define the entry points in the extension #ifdef block, not the VERSION_3_0 #ifdef block) seems acceptable.

That’s a good compromise.

Quick question: I noticed that WGL and GLX functions and enums are not listed in the .spec files. Do they have .spec files of their own, and if so, where can we get them?

GLEE http://elf-stone.com/glee.php contains an XML file http://elf-stone.com/getfile.php?title=GLeeExtensionsXML for the spec files, so this maybe a good start to create a more current one. One could then create the spec files from the XML file for those who need it.

Q: what do the '’ resperesent in the gl.tm file (e.g. AccumOp,,*,) ?

The first field is for the parameter “direction” (in, out, in/out) and the second the “transfer type” (array, reference, value). This could potentially be used together with parameter type information in the .spec file when constructing type mappings to sufficiently weird languages. We just generate C bindings, for which the type information in the .spec file itself is sufficient, and so wildcards are used in the C typemap files.

The .spec mechanism is a ca. 20 year old SGI concept originally developed for other purposes and applied to OpenGL later, so there are capabilities like this in them we don’t really care about. I think at one point they were used for stuff like generating IrisGL bindings to Ada and FORTRAN, for example - before my time there so I’m not certain.

There are a bunch of hideous Perl scripts of similar ancient lineage (started as awk scripts) to massage the .spec files into headers, generate GLX rendering protocol, generate wrapper libraries, and such.

They do. Same mechanism although the APIs are partitioned a bit differently with just the original core API entry points in glx.spec/wgl.spec and the extensions in {glx,wgl}ext.spec.

I set things up so the public registry should show these, but tonight it looks like the auto-updates from our internal Subversion to the webserver are not running for some reason, so they probably won’t be visible until the webmaster fixes the problem.

It’s up now, Jon. And thanks for the specs.