Questions about how OGL specs are created.

  1. Is there somewhere a list of opengl extensions that compose given OGL version?
  2. Is there any algorythm for name conversions when extensions get included?
  3. Is there any guarantee, that all functionality for OGL vX.Y will be publicated as extensions before publicating OGL X.Y spec itself?
  4. Is there any guarantee, that all functionality of extension will get included? (eg. all defined functions?)
  5. Is there any guarantee, that all or non functionality of extension fall under core profile?

I have code that generate bindings for extensions from repository and want to reuse it for generating opengl bindings. (If possibly by importing this list of extensions, and fiddling with names, only).

  1. Is there somewhere a list of opengl extensions that compose given OGL version?

The first approach is to use Appendices F through K for GL3.0+ in GL Spec 4.1 (Core), althoughit is propbalbly not what you are asking for.

Another approach is to track #define GL_VERSION_X_X in glext.h.

  1. Is there any algorythm for name conversions when extensions get included?

They loose ARB or vendor specific prefix or sufix.

  1. Is there any guarantee, that all functionality for OGL vX.Y will be publicated as extensions before publicating OGL X.Y spec itself?

No

  1. Is there any guarantee, that all functionality of extension will get included? (eg. all defined functions?)

No

  1. Is there any guarantee, that all or non functionality of extension fall under core profile?

No (although I didn’t quite understand what you wanted to ask)

Imagin one extension, that get included in OGL, some functions get included to core profile, some only to compatibility.

This glext.h define extensions that got included but also new functions, right?

  1. Is there any guarantee that glext.h will reflects newest OGL spec?

I have code that generate bindings for extensions from repository and want to reuse it for generating opengl bindings.

You will have to parse through the .spec files then. glext.h is for extensions; the core is not necessarily just a bunch of extensions that were directly promoted to core.

  1. Is there any guarantee that glext.h will reflects newest OGL spec?

Define “guarantee”. They intend for it to reflect recent specifications, but there’s always the chance for bugs.

I do not mean bugs free, but just practice that glext.h will be updated every time there is new OGL spec. in timly manier.

Hmm, if they would get updated “before” publicating new OGL version, it could be possible to add auto generating capability to my code. So even if some imaginary programmer wrote his code the day new OGL come out, my “gen” code could download nad parse required function definitions (so only drivers would hold back early adopters).

I would like to reuse code that generate bindings for every extension, as much as possible.

No i know that i can not simply download list of extensions for OGL X.Y, and load corresponding extensions with just “ARB” “NV” and “AMD” removed from names.

BTW that means that you can not get newest OGLs just by loading extensions or am I wrong? (just because you will miss few functions defined outside of extensions)

Where is specs syntax and repository layout explained?

BTW that means that you can not get newest OGLs just by loading extensions or am I wrong?

You have never been able to get “newest OGLs” by loading extensions. We call “extension loading libraries” by that name as a convenience, but they also load core functions too.

In any case, why don’t you just use GL3W and save yourself some trouble. It seems to be what you want.

Where is specs syntax and repository layout explained?

Nowhere. I wrote some Lua scripts to parse it, and I keep a Bitbucket repo of them in case someone wants to use them. You could read through how I parse them into an XML-based format. But that’s about as close as there will ever be to any documentation for the format.

What you want to build requires significant amount of artificial intelligence, and even with that it will fail. You are talking about core and compatibility profile, because that’s only what you know. But what if in the future there will be dozen or even hundreds of profiles? What if every hardware vendor will have it own profile? Maybe each game developing team will have it own profile. Core and compatibility profiles were incarnated in OpenGL 3.2 after an year of struggle to define main courses of OpenGL behavior. But it was planned to be much more. What if OpenGL ES become just a profile of OpenGL? Do you remember March 11 2010? In the same day we got two versions of OpenGL (3.3 and 4.0). It was hard to believe that something like that can happen. And four months later we got OpenGL 4.1, which was in fact OpenGL 3.4, because all extensions require SM4 hardware (while OpenGL 4.0 requires SM5 HW). The development of OpenGL is so unpredictable that it is unwise to bother with what will happen.

glext.h is probably the best source of information you can get, but it doesn’t reflects the current state of the drivers. For example, there are many new NV extensions that are in the drivers for several months, but there is no trace of them in any specification. Another example: NV_DX_interop is included in wglext in April this year, but was presented in the drivers several years ago (of course as experimental extension). Generally, glext.h is usually late from several days to several months. It is pretty naive to ask to be updated before the next revision of OpenGL. But, on the other hand, what can you do with the signatures of the functions without knowing the purpose?

@Aleksandar

Well, if someone thought about defining spec syntax and layout, putting all new definitions in separate extension, and defining which extensions go to which profiles and OGL versions. Our (programmers) lives would be easier.

And after writing once binding generator, there would be no need for any modifications.

But before someone would have to think a bit, and commit resourced to specification process.

Well, if someone thought about defining spec syntax and layout, putting all new definitions in separate extension, and defining which extensions go to which profiles and OGL versions.

First, all of that information exists. The spec files do have a consistent syntax and layout; there just isn’t documentation on what it is. And I just linked you to a Lua parser that can process this syntax; it turns it into a perfectly readable XML format.

What more do you want?