Issue #6 open

Load everything that exists

Jason McKesson
created an issue

While it is nice to be able to ask to load specific entrypoints, it would also nice to be able to load everything that the current OpenGL implementation does. You can get the current version and load function pointers based on that, then iterate over the extensions and load those functions too.

Comments (4)

  1. yotis repo owner

    Since commit 20f7d0f4ca0a brings in major API changes, I will put this issue on hold and we will talk about it after the API is stable again. My first thought is that a feature like this is against C++'s nature of "only pay for what you use", but if you insist, I will include this functionality.

  2. Jason McKesson reporter

    I appreciate the sentiment. But consider this.

    It is often the case that one is forced to use GL 2.1, due to having to support older hardware. That's just a fact of life for application developers. This means that they will include 2.1 support, but not everything that 2.1 hardware can do is core 2.1 functionality. Floating-point textures and FBOs are the simplest examples. So, given this, a typical .cpp file that supports GL 2.1 might look like this:

    using namespace gl_version_2_1
    using namespace gl_EXT_framebuffer_object
    using namespace gl_ARB_half_float_pixel
    using namespace gl_EXT_framebuffer_blit
    using namespace gl_EXT_framebuffer_multisample
    using namespace gl_EXT_texture_sRGB
    using namespace gl_EXT_packed_depth_stencil
    using namespace gl_EXT_framebuffer_sRGB 

    You would be surprised how much farther I could continue this. That doesn't get into any of the core 3.0+ extensions which can be implemented on 2.1 hardware (VAOs, explicit_attrib_location, etc). Now, if you think that the madness ends just at 2.1, think again. Even for 3.3 core profile, there are quite a few extensions that you could still ask for:

    using namespace gl_version_3_0
    using namespace gl_ARB_shading_language_include
    using namespace gl_ARB_draw_buffers_blend
    using namespace gl_ARB_texture_gather
    using namespace gl_ARB_texture_cube_map_array
    using namespace gl_ARB_texture_compression_bptc
    using namespace gl_ARB_get_program_binary
    using namespace gl_ARB_separate_shader_objects
    using namespace gl_ARB_debug_output
    using namespace gl_ARB_base_instance
    using namespace gl_ARB_shading_language_420pack
    using namespace gl_ARB_internalformat_query
    using namespace gl_ARB_map_buffer_alignment
    using namespace gl_ARB_shading_language_packing
    using namespace gl_ARB_texture_storage

    And that doesn't include proprietary extensions that one may need to use. Even if a user only uses 5% of the 500+ extensions, that's still 25 separate using declarations. At some point, it because easier to just say, "give me everything and I'll sort it out."

    In general, the problem is this: OpenGL is a runtime system. What is available is determined at runtime, not compile-time. And while it is great to be able to "pay only for what you use", the cost of having to basically go through and figure out ahead of time everything you might want to use can be painful.

    Also, there's no particular cost associated with these using directives. The user still has to compile the header that includes all of the entry-points, even if they don't use them. The inclusion or not inclusion of the specific functions is more or less academic. The cost of loading function pointers is a one-time expense.

    Basically, what people will do is just make a header that includes your header, which includes a bunch of extensions that they will add to as they use them. If that's what everyone is doing, then it probably would be best to just have a way to include everything at once.

  3. yotis repo owner
    • changed status to open

    I also myself have a GL 2.1 path. As I started updating the code trying to add core-only functionality and adding more extensions, my main problem with other loading libraries was that I couldn't figure out which functions should I use without reading the specs. Reading pdf's and googling around when trying to figure out which functions belongs to which version or extension was very time consuming for me. Now, when I want to explore the GL API (version or extension), I add a using declaration, then I type gl, press ctrl+space and I get an autocomplete list that contains only the functions that I am interested in.

    Also, considering that even the simplest gl programs are a few hundreds lines of code, I don't think that writing 25 using statements is that big of a deal. Actually in a real program, that uses thousands of gl.. calls, 25 lines is actually a very small percentage of code.

    Now glxx contains all function pointers in a big fat struct (glxx::Loader). It also has a 'current loader' concept. You GenLoader(), then BindLoader(), then you can load what you need. What I agree to do is to have a way to load all the pointers with a single call instead of calling load_gl_3_3(); load_arb_get_program_binary(); .. etc ..., but having a single namespace that contains all symbols is really against my intentions. I agree to include a function that queries the current context and loads whatever version there is available, as well as all available extensions, so you don't have to call many different loading functions.

    There are other libraries out there that bring in the global namespace all availble symbols, but glxx was designed specifically for not having all the symbols in the global namespace. If someone wants all symbols at once he/she should use another library.

    Furthermore, when reading code, if there are (let's say 25) using statements, one can understand immediately what version and what extensions the code targets, so if the code is read after a lot of time, it will be actually easier to understand and to update. For me this is exactly the case, I have code that after a year I don't remember what I was targeting at the time and glxx helped me to control the different rendering paths more easily.

    I am reopening the issue now, so we can discuss this further.

  4. Log in to comment