In GL 3.3 Core specification, Appendix E, it is said that a GL context that doesn’t support deprecated features is called a forward compatible context, but the Core profile also disallow the use of deprecated features. So what is the difference between the two of them?
This question is somehow related to my understanding of the deprecated model and profiles. As far as I understand the spec, the deprecation model defines which functions are available in the context, while the profiles defines which of these functions are usable (creating a subset of the available functions). Am I right? If I’m, then it’s impossible to have a forward compatible context with a compatibility profile?
In GL 3.3 Core specification, Appendix E, it is said that a GL context that doesn’t support deprecated features is called a forward compatible context, but the Core profile also disallow the use of deprecated features.
This is something that a lot of people don’t really understand, even though any software dictionary on the subject is quite clear. To mark something as “deprecated” means that you are saying, “You may still use this, but I, as the maker of the software, am reserving the right to yank this from any future version.” It is a strong hint that you should stop using it; nothing more.
OpenGL 3.0 deprecated a lot of functionality, but that functionality was still available. OpenGL version 3.1 removed most of the deprecated functionality; at that point, it was no longer available. 3.2 instituted the core/compatibility distinction, where the spec was divided into two separate specifications, one with the removed functionality restored, and one without the removed functionality.
A forward compatibility context (which you should not be using) removes all deprecated functionality from the context. What deprecated functionality remains from core if it was removed? Notice that I said that 3.1 removed “most” of the deprecated functionality, not “all”. There was some functionality from 3.0 that was marked deprecated but never actually removed (wide lines). That is still perfectly legal in core OpenGL, even though it is marked deprecated. Because remember: deprecation is a hint, nothing more.
Therefore, if you create a forward compatibility context, it will remove all deprecated functionality remaining in the core. Namely, wide lines. Again, you shouldn’t be using this.
Sorry for being slow, but I also have problems to understand. Well, I think I understand the concept of “deprecated”.
So core functionality restored the deprecated functions, and the compatibility was without the deprecated functions? Not what you would expect from the word “compatibility” or “backward compatible”, but maybe what you would expected from the word “forward compatible”?
A forward compatibility context (which you should not be using) removes all deprecated functionality from the context.
Now I am lost again. To me, it sounds as a good thing if the deprecated functionality is removed (to minimize the risk that you use things that may go away in the future), and so the forward compatible context would be a good thing?
What deprecated functionality remains from core if it was removed? Notice that I said that 3.1 removed “most” of the deprecated functionality, not “all”. There was some functionality from 3.0 that was marked deprecated but never actually removed (wide lines). That is still perfectly legal in core OpenGL, even though it is marked deprecated. Because remember: deprecation is a hint, nothing more.
So the only difference between the core context and the forward compatible context is the availability of a few deprecated functions (wide lines) that were not removed in 3.1?
So core functionality restored the deprecated functions, and the compatibility was without the deprecated functions?
That’s not what I said. I didn’t put the description of core and compatibility in the same order as the words. Compatibility has the removed functionality restored.
Now I am lost again. To me, it sounds as a good thing if the deprecated functionality is removed (to minimize the risk that you use things that may go away in the future), and so the forward compatible context would be a good thing?
Why bother? Deprecation and removal is basically meaningless at this point, since you can always just create a compatibility profile and everything will be available again.
And I would bet you anything that the ARB never deprecates or removes any functionality again, especially considering how poorly this has worked thus far.
So the only difference between the core context and the forward compatible context is the availability of a few deprecated functions (wide lines) that were not removed in 3.1?
Sorry for interfering, but I don’t understand what is so peculiar in the forward compatibility. The specification is very clear. Forward compatible contexts don’t support deprecated functionality in that profile.
There is no deprecated functions in the compatibility profile, so a forward-compatible compatibility profile has exactly the same functionality as a non-forward-compatible compatibility profile. On the other hand, the core profile still contains some features that are deprecated in the core profile (like wide lines and some global component limit queries(MAX_VARYING_COMPONENTS and MAX_VARYING_FLOATS) ). A forward-compatible core profile removes those functions. Think of forward compatible profile as a pure profile, a profile that has been purified from the deprecated functionality.
On the contrary! I don’t find anything wrong in using forward compatible core profile. Furthermore, that the only type of context I’ve been using since the announcement of GL 3.2 in my research projects.
There’s no point in doing it in core either. I guarantee you that the ARB will not remove a single feature from any future specification unless they do a complete page 1 rewrite. All you’re doing is denying yourself wide lines.
There’s another big difference between Core Profile and Forward Compatible contexts which hasn’t been mentioned here: GLSL.
A Core Profile context (lets say for illustration, GL3.2 with GLSL 1.50) should allow using deprecated functions that have not been removed from the specification. That includes all of the GLSL 1.50 built-ins such as texture2D() and gl_FragColor.
On the other hand, a Forward Compatible context will remove all deprecated functions, so texture2D() etc will not parse.
I believe I got it. The forward compatible bit indicates which functionalities are implemented (AKA removed or not) in the context, while the profile bit indicates which functionalities are usable (AKA deprecated or not) read by the context.
Then NV’s drivers are broken. See the “Deprecation” section of the GLSL spec:
"The OpenGL API has a forward compatibility mode that will disallow use of deprecated features. If compiling in a mode where use of deprecated features is disallowed, their use causes compile time errors. "
Maybe that is the reason that people (like me) have difficulties understanding this. Usually features have a purpose, and you should make sure you understand them so you can decide if you are going to use them or not.
No, they are just too permissive.
It was elaborated a long time ago that NV GLSL compiler ignores #version directive, so that we can mix up different versions, as well as Cg with GLSL.
I don’t ask for the spec interpretation, but if AMD’s GLSL compiler makes difference whether the forward compatible bit is set or not.
Everything has its purpose! But before understanding the purpose of deprecation, you should understand why OpenGL is not radically changed 4-5 years ago.
Maybe that is the reason that people (like me) have difficulties understanding this. Usually features have a purpose, and you should make sure you understand them so you can decide if you are going to use them or not.
It did have a purpose. In OpenGL 3.0, it was a way to simulate working in later versions where the deprecated functionality was removed. Now, it doesn’t have a purpose anymore.
