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 3 123 LastLast
Results 1 to 10 of 30

Thread: Interest in specialized GL function loader.

  1. #1
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Interest in specialized GL function loader.

    I'm interested in gauging the general interest in a specialized OpenGL function loader. What I mean is this.

    Everyone has their own parts of OpenGL that they use. Everything else is superfluous.

    Yet common loaders like GLEW and even my own GL Load will dump everything at you. If you're using core OpenGL 3.x+, there aren't a whole lot of extensions that interest you. Some of the non-hardware 4.x extensions are useful of course. But you don't need stuff like GL_EXT_shadow_funcs cluttering up your headers. If you're not using EXT_direct_state_access, do you really need it's 1001 functions clogging up your header?

    And while one could create a core GL-only set of headers and loaders, there are extensions that people use that aren't core. Everyone has their own set.

    Rather than trying to write a one-size-fits-all solution, what about a simple script, where you provide a basic version (with compatibility/core selection of course) and a list of extensions, and it creates a header and a .c or .cpp file for you to add to your project? The header imports everything you asked for. Something similar can be provided for WGL/GLX extensions.

    Is that something that people might want? I've got most of the code-generation system working from my work with GL Load, which already knows how to break out functions by version and so forth. From there, it's simply a matter of modifying the front-end of the code generation system.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Something like

    Code :
    genGLLoad [-core][-compat] [-extensions EXT, {EXT}]

    ?

    Would be cool. One thing that annoys me constantly is that several IDEs I use aren't able to correctly parse glew.h and determine the function signature due to the indirections incurred by the #defines. Of course, this is basically the IDEs' fault but to help them provide accurate information, is there a simpler way of declaring stuff?

    Also, if you're going to write that script, it's a perfect opportunity to provide a very basic GUI which lets you select the extension you need. I'd be willing to write that one up quickly if desired.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    153
    It would be very useful. Currently I am loading manually only the commands I need.

  4. #4
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    320
    That'd be useful. Currently for each new extension we decided to support, we copy the defines and function pointers from glext.h into our own header. For some extensions this is trivial, for others it's pretty tedious. Having a script that extracts these would be nice.

    Could there be a flag to specify whether the function or function pointer declarations are output?
    Last edited by malexander; 10-04-2012 at 08:27 AM. Reason: sp.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Could there be a flag to specify whether the function or function pointer declarations are output?
    What do you mean by that exactly? Are you talking about doing static linking vs. dynamic or something?

  6. #6
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    320
    Quote Originally Posted by Alfonse Reinheart View Post
    What do you mean by that exactly? Are you talking about doing static linking vs. dynamic or something?
    Perhaps I've misunderstood what your script will be producing, but essentially the glext.h file has two ways to get at the underlying function (using GL_ARB_instanced_arrays as a simple example):
    Code :
    GLAPI void APIENTRY glVertexAttribDivisorARB (GLuint index, GLuint divisor);
    typedef void (APIENTRYP PFNGLVERTEXATTRIBDIVISORARBPROC) (GLuint index, GLuint divisor);

    A few ways to access this function come to mind:

    1. Declare glVertexAttribDivisorARB() as a function in the header. Including a header with this file, without an underlying implementation in a GL lib, will fail to link (static) or fail at runtime (dynamic)
    2. Declare a PFNGLVERTEXATTRIBDIVISORARBPROC glVertexAttribDivisorARB function pointer variable in the header, assigned by the .cpp file in an initialization routine. If the core feature / extension is not supported, it is NULL - no linker issues. Onus is on the developer to do proper checking before calling it.
    3. Declare a wrapper function in the header, arglVertexAttribDivisorARB() (or some variant), which is defined in the .cpp file. This function asserts if the PFN variable in NULL (also implemented as a variable and initialized in the .cpp file), and calls it.

    I'd prefer #2 for how we have things set up here, but I can see the value of the other two as well for other projects. So, a command line option to specify this behaviour.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I see what you're getting at now. #2 is the one that most widely actually works, so it's generally what I go with. I could implement the others, but as I work mostly on Windows, I wouldn't really know how to test it.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    I could implement the others, but as I work mostly on Windows, I wouldn't really know how to test it.
    Since we have a pretty diverse here this shouldn't be a problem.

  9. #9
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,146
    Quote Originally Posted by Alfonse Reinheart View Post
    Rather than trying to write a one-size-fits-all solution, what about a simple script, where you provide a basic version (with compatibility/core selection of course) and a list of extensions, and it creates a header and a .c or .cpp file for you to add to your project? The header imports everything you asked for. Something similar can be provided for WGL/GLX extensions.
    I'm not sure what parameters your script will use as an input, but it is much better to parse all files in the project searching for the GL calls and generate two files (.h/.cpp or .c) with appropriate pointers. That's the way I make the work done. I'm also keeping glext.h and wglext.h in the project. You could make the solution even more compact excluding those files, but it requires extracting appropriate enumerations and constant which requires additional work.


    Having additional options, like: /V:GL3.3 /C, is welcome, if the project is targeting a concrete GL version. But the basic usage should be "give me all functions I use in the project".

    Could you make command prompt applications instead of scripts? Some of us are allergic on LUA/PHP/Ruby solutions.

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    I'm not sure what parameters your script will use as an input, but it is much better to parse all files in the project searching for the GL calls and generate two files (.h/.cpp or .c) with appropriate pointers.
    He said quite clearly, provide a basic version(core or compat) which would be a mutual exclusive switch and perhaps default to core if not specified and a list of extension.

    The problem with your suggestion is that code needs to exist so you can run the script. What if you start a new project and you know you're gonna need a GL4.3 core header? What code is there to parse?

    Could you make command prompt applications instead of scripts? Some of us are allergic on LUA/PHP/Ruby solutions.
    I guess you mean a native executable. The thing is, at least for Python I can say that the wealth of the functionality and its ease of use is alleviating a lot of stuff when doing text processing or text generation. Not having to install an intrepreter is a reasonable suggestion, but it pales in comparison to 3rd party dependencies you need to get and maybe compile and general project prerequisites we OpenGL devs need on a regular basis. By excluding scripting languages you take many good development options away. I recently wrote a code generation script at work in Python - I cannot imagine how long this would have taken me in C++ so I'd advocate for Python.

Posting Permissions

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