Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: GL_EXTENSIONS replacement

  1. #1
    Junior Member Newbie
    Join Date
    Dec 2007
    Posts
    16

    GL_EXTENSIONS replacement

    In the GL 3.0 spec it says that GL_EXTENSIONS is deprecated as an argument to glGetString which I guess means you just try to get a function pointer and if it's NULL then it's not supported.

    However, if you wanted to get a list of all supported extensions without using deprecated functionality, how would you do it?

  2. #2
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: GL_EXTENSIONS replacement

    GLint n, i;
    glGetIntegerv(GL_NUM_EXTENSIONS, &n);
    for (i = 0; i < n; i++) {
    printf("%s\n", glGetStringi(GL_EXTENSIONS, i);
    }

    glGetString() is not deprecated, only the GL_EXTENSIONS argument to it is. There's a lot of history with people using fixed-size buffers to copy the merged extension string into and having that break when someone releases a new driver, which is what we're hoping to alleviate in the long term here.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  3. #3
    Junior Member Newbie
    Join Date
    Dec 2007
    Posts
    16

    Re: GL_EXTENSIONS replacement

    Thanks! I didn't know glGetStringi existed! I must read the spec more carefully

  4. #4
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    450

    Re: GL_EXTENSIONS replacement

    I don't suppose it's possible to get an extension that can be used to retrieve the capabilities of OpenGL?

    Preferably with some way of linking the capabilities with the extension they belong to.

    eg. Querying

    GetIntegeri_v(GL_EXTENSION_CAPABILITIES, extensionIndex, &capabilities)

    would return a list of all the capabilities of that extension

    ie. When glGetStringi(GL_EXTENSIONS, i) returns "GL_ARB_draw_buffers"
    then
    GetIntegeri_v(GL_EXTENSION_CAPABILITIES, i, &capabilities) returns
    [GL_MAX_DRAW_BUFFERS_ARB]

    And when glGetStringi(GL_EXTENSIONS, i) returns "GL_ARB_geometry_shader4" then
    GetIntegeri_v(GL_EXTENSION_CAPABILITIES, i, &capabilities) returns

    [GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS_ARB, GL_MAX_GEOMETRY_VARYING_COMPONENTS_ARB, GL_MAX_VERTEX_VARYING_COMPONENTS_ARB, GL_MAX_GEOMETRY_UNIFORM_COMPONENTS_ARB, GL_MAX_GEOMETRY_OUTPUT_VERTICES_ARB,
    GL_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS_ARB]

    These values could then be plugged into glGetInteger to get the actual values.

    A way of retrieving core capabilities as well as extensions would be nice too, so each time a driver supports a new version of OpenGL, or changes extensions supported, then existing programs that display capabilities will just work without needing to be re-compiled.

    Thanks.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: GL_EXTENSIONS replacement

    Why would you ever need that? You're talking about things that you can already retrieve with the appropriate enums. There's no need for an ill-defined operation like GL_EXTENSION_CAPABILITIES when you can do that yourself.

  6. #6
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    450

    Re: GL_EXTENSIONS replacement

    sure, if you want to have to update your application every time a new extension comes out.

    This new functional would mean that you won't need to re-write code to allow users to see new capabilities of their graphics cards, that have been added since you wrote the program.

    Currently, you need to wait for makers of programs like:

    http://www.realtech-vr.com/glview/

    to update their database before being able to see limitations of your hardware.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: GL_EXTENSIONS replacement

    sure, if you want to have to update your application every time a new extension comes out.
    You'd have to do it with your suggestion anyway. In the example you game, GL_ARB_draw_buffers has 1 integer worth of data, while GL_ARB_geometry_shader4 has 6 integers of data. There is no theroetical maximum size of data.

    Furthermore, let's say you do this:

    Code :
    int iSize = 0;
    GetIntegeri_v(GL_EXTENSION_CAPABILITIES_SIZE, i, &amp;iSize );
     
    if(iSize)
    {
      int *pDataArray = new int[iSize];
      GetIntegeri_v(GL_EXTENSION_CAPABILITIES, i, pDataArray);
    }

    The size getting lets you get past the problem I mentioned. However, for any extension "i", do you have any idea what pDataArray[0] actually means? Without having intimate knowledge of what extension "i" is (ie, needing to "update your application every time a new extension comes out"), you have no idea what any of the data in the array means.

    In short, the entire exercise is fundamentally meaningless.

  8. #8
    Junior Member Regular Contributor
    Join Date
    Aug 2007
    Location
    Adelaide, South Australia
    Posts
    206

    Re: GL_EXTENSIONS replacement

    This is the one depreciation i really dont agree with.

    In every other case you are removing functionality that could be helpfull for beginner programmers to write simple programs with, and only keeping the fast path.
    In this case you are replacing the current fastest path with a function designed for students still learning basic programming.

    I honestly cant imagine why anyone would want to make a copy of the entire extensions string before scanning it, and if they did then why not just use the standard string-copy routines.

    glGetStringi(GL_EXTENSIONS, i); can be taught to beginners in SDK tutorials as the way to access extensions so they dont get it wrong, but the existing string should remain for professional programmers.
    Or The planned SDK could provide the source code for a simple routine to scan the extensions string, that they could just copy into their own code.

    The extension string also doesn't need to be as long as it is at the moment because the program will tell the driver which version of OpenGL it understands when it creates the context.
    The driver only needs to return a list of extensions that are not core in that version.

    If you really want to return extensions in a form useful to professionals and easy for beginners to use then just return two sets (bit arrays), one for "ARB Extensions by number" and one for "Vendor and EXT Extensions by number".
    Then you dont need to read extension names at all, just check if a bit is set (unless you want to use an experimental extension that has not been assigned an extension number yet).
    The problem of buffer size differences is solved by telling OpenGL how big your buffer is, or the highest extension number you know or care about, so if your program only understands 353 vendor extensions then it creates a 45 byte bit array and asks the driver to copy to it the 45 bytes of its internal bit array that corresponds to extension 1 to 353.

  9. #9
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    450

    Re: GL_EXTENSIONS replacement

    Yeah, it's unusable in a program for checking against anything, since as you said, the data is meaningless unless you know what it means.

    It isn't intended for use within normal program code, but it allows you to write a program that displays extensions and their limits that will still be up-to-date if you run it in 10+ years time. This is my main motivation, since I'm going to need to update an OpenGL info screen soon (for GLScene - OpenGL solution for Delphi) that hasn't been updated for a few years, and hence doesn't have any of the GLSL info displayed on it. However, after re-writing it will quickly get out of date again, missing important information, as new shader types become available (or maybe "break" as core functionality gets deprecated).

    I forgot something, and that would be to also return a string of the capability name (either "GL_MAX_DRAW_BUFFERS", or a more friendly "Maximum draw buffers"), and may be better to return the whole lot as strings, rather than integers.

    eg.
    "Maximum 3D texture size", "2048 x 2048 x 2048"
    "Line width range", "0.5 to 10.0"
    "Recursive tesselation limit", "8"
    "Ray-trace bounces allowed", "8"

  10. #10
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    450

    Re: GL_EXTENSIONS replacement

    Quote Originally Posted by Simon Arbon
    This is the one depreciation i really dont agree with.

    In every other case you are removing functionality that could be helpfull for beginner programmers to write simple programs with, and only keeping the fast path.
    In this case you are replacing the current fastest path with a function designed for students still learning basic programming.
    glGetString(GL_EXTENSIONS) returning
    "GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_framebuffer_object GL_ARB_geometry_shader4 etc etc x 10 times the size"

    Returning a massive list of extensions like this kinda offends me!

    How is this meant to scale up in a parallel way in a many-core environment? splitting the string up into several chunks + processing it this way? seems clumsy.

    Whereas, you can have much easier parallel handling of:
    (pseudocode)
    ParallelFor(i, min=0, max=NUM_EXTENSIONS, stride=1)
    Process(glGetString(GL_EXTENSIONS, i));

    ps. Actually performance concerns are probably irrelevant, since you're only likely to look these up once (per RC).
    But having them indexed does allow for the possiblity to look up extra information about the extension using the same number. Max capabilities, whether extension is marked as deprecated, or anything else that may be useful.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •