#40 glewInit does not enable all available functions

[Anonymous]

Some video drivers report an OpenGL version number below their actual capability.

Example: Intel 3150 Integrated Adapter

This adapter reports OpenGL version 1.4. GLEW uses this detected version number and decides NOT to enable core functions for opengl > 1.4 However:

wglGetProcAddress( "glGenBuffers") returns a valid function pointer, that if I call, functions normally.

Using the glewinfo tool, this graphics card supports all core functions up to OpenGL 2.0, but GLEW does not actually enable these functions.

Workaround:

After calling glewInit(), if I do:

glGenBuffers = wglGetProcAddress("glGenBuffers")

for each function I need, everything works just fine. These functions are 'there' the driver just returns an inappropriate version number.

Suggested Fix:

Try wglGetProcAddress even for functions that shouldn't be available for a given version.

[Sirow]

Same issue on ATI Radeon Mobility X2300 using

• Driver: xorg-x11-drv-ati 6.13 (Catalyst doesn't support the X2300 mobility), Mesa 7.8.1
• Kernel: 2.6.34.7-61.fc13.i686.PAE (32Bit Linux on 64Bit Intel Core 2 Duo)
• Fedora 13
• GLEW version 1.5.4
• OpenGL context via freeGlut 2.6.0

Some notes:

• GLU version string returns 1.3 (visualinfo)
• GLX version string returns 1.4 / OpenGL version string returns 1.5 (glxinfo)
• Using glewinfo all functions up-to version 2.1 are available.
• Testing GL_VERSION_2_0 is positive, but attempting to call eg. glCreateProgram()/glCreateProgramObjectARB() causes segmentation fault because both are NULL. (Despite glewIsSupported("GL_ARB_fragment_program")/glewIsSupported("GL_ARB_vertex_program") beeing positive)
• GLee seems to have the same problem (a bit worse since GLEE_VERSION_2_0 is negative), BUT using GLeeForceLink("GL_VERSION_2_0") works just fine.

[Sirow]

glewinfo: http://pastebin.com/gAWazQj6
visualinfo: http://pastebin.com/sMKDSNZS

[Nigel Stewart]

For what it's worth...

I think GLEW is doing the correct thing by trusting the version reported by the OpenGL implementation. Being able to load the 2.0 entry points isn't sufficient to consider 2.0 completely available, in my opinion.

So a couple of suggestions -

1. Go upstream and report a bug about the driver reporting the "wrong" version of OpenGL. I guess the response would be that the version is actually correct in some stricter sense than matters to you in this case.

2. Propose an addition to GLEW to allow the application to specify the version and extension strings GLEW ought to use, rather than those detected from the OpenGL implementation. This way, those that know what they're doing can force whatever they like without risking the stability of other apps that have always relied on the information from the OpenGL implementation.

Feel welcome to raise this issue on the mail list too.

• Nigel

[Nigel Stewart]

One other comment I'd make about GLEW. One limitation of GLEW is that each entry point can belong to only one category (GL version or extension). There is an assumption that an OpenGL implementation will support all the ARB extensions, so the entry points tend to be loaded via those, rather than the GL version, to maximize portability. I don't regard this as strictly correct, but it seems to be good enough in practice.

This point weakens the argument that if glewinfo reports all the OpenGL 2.0 entry points as being available - then that is sufficient to make use of OpenGL 2.0. In my opinion.

• Nigel

[Nigel Stewart]

Closing this as a "won't fix" for reasons mentioned previously. Comment posting is still enabled, and I'll monitor it for further updates. Otherwise, taking it off the radar.