What is all-core? When should I use it?

[jrefior]

Thanks for this repo, I've used it several times, always importing v3.3+. Today I came upon someone else's work which imported all-core. That raised some questions for me:

1. What is all-core and where does it come from?

I tried to do a little research to find out the answer. I came upon this in the Khronos wiki and wondered if it was related:

Until version 3.0, all versions of OpenGL were fully backwards compatible with earlier ones. Code written against OpenGL 1.1 could execute just fine on OpenGL 2.1 implementations.

So I wondered if it was sort of "representative" of early versions (e.g. from the OpenGL Registry).

From issue #104 I learned it's not appropriate to import all-core alongside another version's gl import (makes sense when one looks at the code).

Then in generate.go I found this line:

//go:generate glow generate -out=./all-core/gl/ -api=gl -version=all -profile=core -lenientInit -xml=../glow/xml/

So now I know where it comes from. In the Glow readme I found:

version: The API version to generate. The all pseudo-version includes all functions and enumerations for the specified API.

I think that means it includes every function from every version. So say if your video card only supported 3.3 and you used all-core, you could end up calling a gl function that wouldn't work? So I guess this first question might be more appropriate in the Glow repo. Which brings me to my second question, which I think belongs here:

2. When is it appropriate to import all-core?

When is it appropriate or advantageous to import all-core instead of one of the versioned gl packages (e.g. 3.3)?

[Shakeskeyboarde]

Also wondering about this. What I've found that's interesting is that on my macbook, I can use v4.1-core, or all-core, and both work. But if I try to use v4.6-core (osx doesn't support >4.1), I get init errors due to missing function pointers. Is all-core just silently skipping functions it can't bind on the platform's opengl version?

[dertseha]

Hello there! To jump in about the various open questions: The go:generate call for glow does include the flag -lenientInit which causes the silent skip in case a function cannot be loaded. This is the reason why even bleeding-edge functions could be "known" by all-core, but won't cause an error in case the system it is used in does not provide the functions.

This behaviour is in part a possible answer to the core question: Why does this exist? A generic answer could be: To have the option "in case you need this kind of setup". While this does not answer the question in a satisfying way, it at least means that there is no definitive answer.

However I do have a practical answer by example: Sometimes, various graphics card drivers do not implement the complete set of features of a particular version. I've had a laptop once that would support all of OpenGL 4.1, and a few functions of 4.2. (Numbers might not be exact, you get the idea.) Luckily the application I was writing needed only a subset of those supported from 4.2. If I were using a "strict" loader that would require "all" of 4.2, I would not be able to run the app on that machine - Although it would be capable of doing so. When using this particular library here, there is no "lenient 4.2" variant, so I would turn to the "all-core" variant.

Such a lenient approach is a case-by-case approach and a special circumstance. I guess it would be too much to create all permutations for all versions (main, compatible, lenient) - In such a special case I'd probably use glow to create my own lenient 4.2 bindings instead of this pre-generated library. Yet with the "all-core" variant provided here, I have the option to quickly prototype.

[jrefior]

Thanks for your answer!

I didn't know whether more people would chime in, but given there's been no further activity/interest, I'm going to close the issue at this point.