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 30

Thread: Interest in specialized GL function loader.

Hybrid View

  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
    319
    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
    319
    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 Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    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.

  8. #8
    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.

  9. #9
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by thokra View Post
    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.
    Do you think 90% of people trying to use OpenGL know what extensions they need? I wouldn't bet on it.

    Quote Originally Posted by thokra View Post
    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?
    Yes, it requires a code. A new project does not have any GL calls so there is no need for the extensions either. Only oglext.h, for example, should be included, and before compilation that function loader should be called (and it would fill oglext.h/.cpp). It could be some kind of plugin for VS, but it is better having a platform independent tool.

    Quote Originally Posted by thokra View Post
    I guess you mean a native executable.
    Yes, I still think it is a better solution. Alfonse would probably provide both code and executable for Windows. Knowing myself and many programmers around me, a executable is much better solution (if it works correctly), than having a code that have to be compiled, or script that requires its on environment.

  10. #10
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.
    There are two major problems my tool is intended to solve:

    1: Less-than-helpful IDE code completion. Using an all-in-one solution means that typing "gl" or "GL_" will cause your IDE to suggest everything. With this tool as I defined it, you can at least restrict it to a specific subset that you consider valuable, thus getting rid of 90+% of the IDE suggestions you won't be using.

    2: Preventing you from accidentally using something you don't want to. If you forget that most 3.x hardware doesn't support ARB_draw_buffers_blend, and you use it, an all-in-one solution will just assume you know what you're doing.

    The tool as you want it will undermine both of these. Your parse-generated header is based on existing functions/enums. OK, but that doesn't solve the problem of using a function I've never used before. The IDE will be massively unhelpful until I type the name and run the parse-generator again. If you already have a codebase that uses all of the functions you intend to use, then you're OK, but if you're trying to get to that point, it's all a big pain.

    Further, your tool has no provisions to prevent you from accidentally using functions you don't want to use. Indeed, it will "helpfully" generate functions/enums for anything you ask of it. Thus it acts exactly like the all-in-one tool.

    It's just not solving the problems of interest.

    Do you think 90% of people trying to use OpenGL know what extensions they need? I wouldn't bet on it.
    True. But I bet that those 90% also don't care. They're probably happy with a "give me all of OpenGL" loader. They also wouldn't want to set up an automated code-generator that they have to run every time they use a new OpenGL function. Nor would they likely be willing to install a plugin into their IDE of choice (assuming that their IDE supported such a plugin).

    The people who don't know what they want already have a tool. This tool is for the people who do know what they want.

    Could you make command prompt applications instead of scripts? Some of us are allergic on LUA/PHP/Ruby solutions.
    There are limits to how much I'm willing to accommodate people's eccentricities. Small applications are already being written entirely in scripting languages. A major distributed VCS is mostly written in Python, and the main GUI for it is almost 100% Python. So the sooner they get over this nonsense the better.

    I'm not going to take my perfectly functioning code generation Lua code and port it all to C++ just because some people want to write "ExeName -options" instead of "lua LuaName.lua -options". And if someone is really that lazy (yet is somehow perfectly willing to build such an application), then I'm fine with them not using my code.

Posting Permissions

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