OpenGL practices - Running OpenGL with no core version

Question

I am not sure if it is a question or an opinion that needs to be shaped by the users here, But here we go.

The question : Should i run openGL in version 1.1 compatibility profile even if i want to support the latest version and extensions? More info ahead.

Some functions requires you to provide an openGL version that you may want to support, Most common usage if you want to support openGL core profile or version 3.0 and above. Examples :

SDL : SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR/MINOR_VERSION, major/minor version);

GLX : glXCreateContextAttribsARB, GLX_CONTEXT_MAJOR_VERSION_ARB, GLX_CONTEXT_MINOR_VERSION_ARB

I had some issues (a few actually) with openGL versioning and extension families.

Issue #1 - Query OpenGL version : It started with Mesa3D Mesa 7.11 if i recall correctly, Trying to query the GL_VERSION from it, I got :

"Mesa 7.11 OpenGL 2.1 Profile"

Knowing glew as well as other project parsers, They are only looking for the first dot in the string, And return the number that the dot is within, as a string (that you may choose to convert to a floating point)

From Glew 1.9.0 : Code snippet The example stated above did return "openGL" version 7.0 which was actually the MESA3D Driver version, Which made me consider it to be unreliable.

Issue #2 - Extensions (MISSING, OK?) with the same MESA3D driver as before : 7.11, Running Glewinfo (glew 1.9.0) gave me the following :

GL_ARB_texture_storage: MISSING OK

glTexStorage1D: OK

glTexStorage2D: OK

glTexStorage3D: OK

glTextureStorage1DEXT: OK

glTextureStorage2DEXT: OK

glTextureStorage3DEXT: OK

Please note that trying to retrieve (import) the functions address from the "GL_ARB_texture_storage" API resulted in a failure (NULL pointer).

My way to resolve the two issues stated above, is to initialize openGL as version 1.1 in compatibility mode, And just brute force my way by checking every API family that i may require, If openGL works as a set of API's that are standalone in their own way, yet working together, Shouldn't we treat them in such a way, code wise, instead of assuming they are there if you have a core version? Once again with MESA3D 7.11 openGL 2.1, I am still able to use openGL 3.0 functions such as "glGenerateMipmap"

**The way i am trying to avoid versions and extension strings is by : **

1.)initialize openGL 1.1 in compatibility mode.

2.)Scan for the API's you may need by importing the core functions.

3.)If you can't get the core functions, Try to get the functions by their extensions (if they exist) (No need for string comparison with an extension list "GL_EXTENSIONS")

4.)If you can't get the functions, Try to emulate them by writing your own.

5.)If none of the methods mentioned above work, Just give up.

6.)If anything from the methods mentioned above work, Run a sanity test and make sure the functions work correctly, Such as : glGetError and assertions for calls that should work.

Do you consider it be safe/efficient? Am i missing something by calling a minimal version and trying to brute force my way in? is there a way i can improve it? *Sidenote - I am aware that openGL core profile remove outdated functions, but you can just choose not to use them yourself, If your driver support the latest version. I am also aware that openGL may try to emulate functions that are outside of the current version, Depends on your driver, You may still be able to use glGenerateMipmap (openGL 3.0 function) with openGL 2.1

Issue #3 - naming conventions, Core, ARB and glew.** I am not sure yet how the name conventions work, For example : it seems that you have in "GL_ARB_debug_output" the function "glDebugMessageCallbackARB" and glDebugMessageCallback in GL version 4.3, Seems alright, But looking at the example above in issue #2, you may see inside "GL_ARB_texture_storage" the function : glTexStorage1D, No ARB suffix.

My question is, How do i know if the API is still waiting to be approved by the board, or if it is part of the core already, Judging by the headers and function names.

Sorry for the wall of text, Some input on the subjects will be appreciated.

Answer 1

The question : Should i run openGL in version 1.1 compatibility profile even if i want to support the latest version and extensions?

First of all: there is no 1.1 "compatibility profile". Profiles were introduced in GL 3.2. But putting that a side, the answer to your question is is clearly no. If you care about portability, at least. For claiming OpenGL conformance, an implementation has to support core profile, while compatibility is optional. And that is not some theoretical possibility, but actually implemented that way in the real world. On OSX, legacy GL contexts are limited to GL 2.1. If you want modern GL3.x/4.x features, you must use a core profile. The same goes for the mesa 3D open source implemetation on Linux: modern GL is only supported in core profile. On windows, a compaibility profile is typically supported, and also the proprietary AMD and Nvidia linux drivers support compatibilit profile, so you can use a "1.1"

Issue #1 - Query OpenGL version

If mesa ever reported "Mesa 7.11 OpenGL 2.1 Profile" as GL_VERSION, it was seriously broken (I never experienced mesa doing such a thing, though). The GL spec requires the version string to start with the numerical GL major.minor version. Modern GL also provides the GL_MAJOR_VERSION and GL_MINOR_VERSION integer queries, which make parsing that string obsolete.

Issue #2 - Extensions (MISSING, OK?)

glewinfos's output might be confusing. But what matters is the first thing it writes for each extension. That is what the GL implementation actually advertises as supported extension via the extension string. It clearly says "MISSING", hence trying to use that functionality is undefined behavior, no matter if the function pointers are NULL or not.

I don't know why you got a NULL pointer while GLEW didn't. Actually, mesa is a framework for a multitude of different drives, using the same frontend libGL.so for all. So it is a wonderful example of implementations where the functions might be there but must not be used, since not all of the mesa backend drivers will support it.

GLEW is broken in this regard, as it does only the use GL_EXTENSIONS string, which is not available in modern core porifle any more. The glewExperimental hack disables the string checking alltogether, and tries to use the pointers it gets. That's not really a good thing to do...

Issue #3 - naming conventions

The prototypical cycle of an extension would be

• vendor-specific (NV/AMD/APPLE/INTEL/...)
• multi-vendor (EXT)
• ARB-appoved (ARB)
• integration into core.

However, that is more or less just the usual case. Some extensions are directly promoted form EXT into core. Some ARB extensions are heavily modified when going into core. Sometimes, core features of later versions are also introduced as extensions (especially for lower versions).

In practice, vendor-specific and EXT extensions all use the suffix for function names and enums. ARB extensions might use it when they are first defined in that extension, only. The issues section of the GL_ARB_sync extension gives a good explanation for this:

13) Why don't the entry points/enums have ARB appended? This functionality is going directly into the OpenGL 3.2 core and also being defined as an extension for older platforms at the same time, so it does not use ARB suffixes, like other such new features going directly into the GL core.

I'm not 100% sure for ARB_texture stoarge, but I think it was intruduced alongside with GL 4.2, where this was a core feature. Those extensions allow implementors to support extensions even if they can not support the GL core verion the feature was originally introduced.

My question is, How do i know if the API is still waiting to be approved by the board, or if it is part of the core already, Judging by the headers and function names.

My question is: why would you want to do that? What would that be useful for? The general rule would be "If it doesn't have a suffix, it is a core feature in some GL version." But what would you actually do with that information?