Performance advantages using OpenGL Loader Generator over GLEW?

Question

Title pretty much explains it all. I first heard of the OpenGL Loader Generator project yesterday while browsing Stack and I checked it out to investigate what advantages it presents over GLEW. On the project website they state that:

This loader generation system is used to create OpenGL headers and loading code for your specific needs. Rather than getting every extension and core enumerator/function all in one massive header, you get only what you actually want and ask for.

While I understand that this approach is definitely more succinct than GLEW, I do not understand how this approach improves compilation time, application performance, or interaction with OpenGL drivers. Furthermore, it seems that the process of using it requires more maintenance as you have to regenerate the extension source every time you need to utilize an additional extension. I have never noticed any performance hit when using GLEW (compared to not using it) so I am curious as to why the developers of this project feel they had a problem to address. Am I missing something?

Answer 1

In the interest of full disclosure, I wrote the OpenGL Loader Generator.

While I understand that this approach is definitely more succinct than GLEW, I do not understand how this approach improves compilation time, application performance, or interaction with OpenGL drivers.

It's an OpenGL function loading library. With the possible exception of the inline forwarding functions in the "Function CPP" style, it's just calling function pointers. Just like GLEW.

The only possible performance difference between the two is in the time it takes to load those functions (ie: the initialization routine). And since that's an initialization function, its one-time performance is irrelevant unless it's decidedly slow.

In short, it is not the tool's purpose to improve "application performance, or interaction with OpenGL drivers". It exists to have clean headers that contain exactly and only the parts of OpenGL you intend to use. Also, it lets you easily use GLEW or GLee-style function initialization, as you see fit.

As for "compilation time" performance, I imagine that it's cheaper to compile a 100KB header than an 800KB one. But since neither GLEW nor my tool use advanced C++ techniques like metaprogramming or templates, odds are pretty good that any compile-time savings will be minimal.

Furthermore, it seems that the process of using it requires more maintenance as you have to regenerate the extension source every time you need to utilize an additional extension.

That's certainly one way to use the tool. Another way to use the tool is to figure out ahead of time what extensions are appropriate for you and just use them.

Generally speaking, when you write real OpenGL applications, you write that code against a specific OpenGL version. This version is dictated to you by the minimum hardware you want to support. If you want to support everything from outdated Intel 945 "GPUs" to the latest high-end stuff from AMD and NVIDIA, you have to write against GL 1.4 (maybe 2.1, if you're feeling really brave and are willing to do lots of testing against Intel drivers). If you want to support more recent hardware, you would write your code against one of the OpenGL 3.x versions, 3.1 depending on how much support you want to give Intel GPUs.

From there, you decide which optional features of later versions, or just hardware-specific features, you intend to support. You have a list of stuff that you intend to use, so you check those extensions and conditionally use or not use it as needed.

That's what this tool is for: when you have settled on a specific set of extensions and OpenGL version. If you want to be more flexible, you could just generate a header that includes more extensions, even if you don't use them. Or you can use GLEW; my tool is an option, not a requirement.

The tool is not meant to be everything for everyone. It's meant to be for people who know what they want, who want to have headers that don't include kilobytes of crap extensions that they will never use.

It's also good for auto-completion and the like. With a clean header, you have to sift through far less junk you have no intention of ever calling. Oh, and it helps prevent you from accidentally using something from an extension you forgot to check for. Because it's not in your header, any attempts to call such functions or use those enums will result in a compiler error.

The other thing that this is good for is ease of use. Just look at how many questions there are on this site about GLEW and "unresolved externals". This comes up, in part, because GLEW can be compiled as a static or dynamic library. So you have to use a #define in your code to switch between them (on Windows). That's bad.

With the generator, you just stick the header and source in your regular build. No library to build or link with. Just a couple extra headers and source files.

Those are the reasons why I wrote the tool.

Answer 2

I think there is no visible performance gain, but you simply get a lot smaller header/source file with OpenGL function declarations.

GLEW/GLEE has all version combination + extensions in the library - that makes it quite large. For instance GLEW 1.7 has 834kb for its header file.

OpenGL Loader makes customized files for desired OpenGL version. Those are much smaller (for instance (around 120kb header + 130kb source file for core opengl 4.2). This will compile much faster that the GLEW library and of course its output code is smaller.