#174 glGetString( GL_EXTENSIONS ) is no more valid since opengl 3

2.0.0
closed
Nigel Stewart
API (59)
1
2 days ago
2011-09-01
MatRem
No

As this is the process to query extension in glew.c it does not work with an opengl 3 core/forward context.
glGetStringi must be used

See attached glew.c modified from 1.6.0

Discussion

  • MatRem
    MatRem
    2011-09-01

     
    Attachments
  • Nigel Stewart
    Nigel Stewart
    2011-09-01

    Duplicate of Bug 2927731: Calling glGetString(GL_EXTENSION) even in Core/FC context
    Closing.

     
  • Nigel Stewart
    Nigel Stewart
    2012-09-18

    • status: pending --> closed
    • assigned_to: Nigel Stewart
    • milestone: --> 1.9.0
     
  • Nigel Stewart
    Nigel Stewart
    2012-09-18

    Closing as duplicate.

    • status: closed --> open
    • milestone: 1.9.0 --> 1.9.1
     
  • Nigel Stewart
    Nigel Stewart
    2012-09-18

    Re-opening, since there is a patch attached.
    Will consider for GLEW 1.9.1.

     
  • Nigel Stewart
    Nigel Stewart
    2012-11-12

    • milestone: 1.9.1 --> 1.9.2
     
  • I'm attaching a patch against 41c1305a, that adjusts how glew.c is generated so that it does the right thing depending on the GL_VERSION reported by the context.
    One side effect is that glewGetExtension() makes a lot more GL calls (it iterates through all extension, calling glGetStringi for each, until it finds the one it is looking for).
    Tested on Fedora 17 x86_64, glewinfo output is unchanged before/after the patch.

     
  • Nigel Stewart
    Nigel Stewart
    2013-03-19

    • milestone: 1.9.2 --> 1.9.1
    • priority: 5 --> 2
     
  • Nigel Stewart
    Nigel Stewart
    2013-03-19

    Thanks for the patch! Appreciated.

     
  • Nigel Stewart
    Nigel Stewart
    2013-07-13

    • status: open --> pending
     
  • Nigel Stewart
    Nigel Stewart
    2013-07-13

    Patch applied to git TOT.
    GLEW 1.10.0 coming soon.
    Thanks for the patch!

    • Nigel
     
  • Nigel Stewart
    Nigel Stewart
    2013-07-22

    • status: pending --> accepted
    • Group: 1.9.1 --> 1.9.2
    • Priority: 2 --> 1
     
  • Nigel Stewart
    Nigel Stewart
    2013-07-22

    I observed issues on Windows with this patch, and reverted it at the last moment for the purpose of GLEW 1.10.0. (Argh!) Bumping this to the "1.9.2" category for a GLEW 1.10.1.

    • Nigel
     

  • Anonymous
    2013-07-22

    Can you post details about the issues? I may be able to take a look (no promises I'm afraid) later this week.

     
  • Nigel Stewart
    Nigel Stewart
    2013-07-22

    In a nushell - glGetStringi hasn't been loaded yet when we're in the process of looking at all the extensions, before we go ahead and init based on the version and extensions. On Windows GLEW seemed to be trying to link glGetStringi from opengl32.dll - a deal breaker.

    • Nigel
     
  • Hmm, weird, the split of glew_init_gl.c into two parts was supposed to avoid that, guess I missed a spot - I'll see if I can find it.

     
  • Nigel Stewart
    Nigel Stewart
    2013-08-23

    I'm thinking of revisiting this in September for the purpose of a 1.10 bugfix release. If you can spare any cycles, I'd like to put this one to rest.

     
  • Nuwen
    Nuwen
    2013-08-26

    How about the attached minimally invasive patch? (This is against 1.10.0's generated glew.c, since I'm on Windows and I haven't tried to regenerate glew, but it should be trivial to apply to the master sources.)

    Basically, there are only two calls (as far as I can see) to glGetString(GL_EXTENSIONS). This replaces them with calls to _glewGetExtensions(), a static helper function. This manually attempts to retrieve glGetStringi(), therefore it should not interfere with the "normal" retrieval and it should not be sensitive to when it is run during the glew initialization process. If it can retrieve glGetStringi(), it concatenates each extension into a static array, space-separated, and returns a pointer to that array. This avoids any CRT dependencies. If glGetStringi() returns a null pointer, the whole function returns null (as the callsites check for).

    On the other hand, if glGetStringi() cannot be retrieved, the helper falls back to the deprecated call to glGetString(GL_EXTENSIONS).

    On my machine, this returns identical strings (including the final space) for both the new-style and old-style codepaths for the compatibility profile (only the new-style works for core, of course, and it is the same except it lacks GL_ARB_compatibility), so the rest of glew should be oblivious as to which path was taken.

    The only squirrelly bit is choosing the size of the static array. My machine (GTX 680, latest drivers) returns a string about 7000 chars long, so I chose 16 KB - this is hopefully plenty for all machines but not unnecessarily bloated.

     
    Attachments

    • Anonymous
      2015-02-04

      Just tried the patch from Nuwen and it seems to work well. Not sure why this problem has required 5 years of deliberation without any official action.

       
  • Sorry for the delay. I'm not able to reproduce the problem (or I just don't understand it properly - I don't develop a lot under windows): I've copied the generated glew.{c,h}, glewinfo.c sources to a windows machine and built glew (shared/static), glewinfo using the vc10 project there. It compiles and links without problem. I've then run glewinfo under apitrace (trace attached) and verified it only makes calls to glGetStringi - I'm attaching the trace file.
    Could you give me some additional hints on how to reproduce the problem? Thanks!

     
    Attachments

  • Anonymous
    2013-10-13

    I had an issue related to this bug (with an OpenGL 4.4 context):

    The GL_EXTENSIONS causes an GL_INVALID_ENUM which is not handled by GLEW. Instead, I caught it at a different point in my code where I checked for a previous GL function's success. So independent of this error, it would be a good idea that GLEW clears all errors it may have produced by calling glGetError() once after initialization.

    Thank you.

     
  • Nigel Stewart
    Nigel Stewart
    2014-07-13

    • Group: 10.10.1 --> 1.11.0
     

  • Anonymous
    2014-07-23

    This bug is 3 years old and now causing serious problems on OS X :( Why the push out to 1.11.0? I'm going to take a look at it.

     

  • Anonymous
    2014-07-28

    I am also very confused why this hasn't been fixed yet.

     
  • Nigel Stewart
    Nigel Stewart
    2014-08-12

    • Group: 1.11.0 --> Future
     
  • Nigel Stewart
    Nigel Stewart
    2015-02-19

    • Group: Future --> 2.0.0
     
  • Nigel Stewart
    Nigel Stewart
    2 days ago

    • status: accepted --> closed
     


Anonymous


Cancel   Add attachments