Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jrefior opened this issue Feb 25, 2020 · 3 comments
Closed

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

jrefior opened this issue Feb 25, 2020 · 3 comments
Labels

Comments

@jrefior
Copy link

jrefior commented Feb 25, 2020

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:

  1. 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
Copy link

Shakeskeyboarde commented May 11, 2020

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
Copy link
Contributor

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
Copy link
Author

jrefior commented Mar 13, 2024

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.

@jrefior jrefior closed this as completed Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants