An OpenGL context represents many things. A context stores all of the state associated with this instance of OpenGL. It represents the (potentially visible) default framebuffer that rendering commands will draw to when not drawing to a framebuffer object. Think of a context as an object that holds all of OpenGL; when a context is destroyed, OpenGL is destroyed.
Contexts are localized within a particular process of execution (an application, more or less) on an operating system. A process can create multiple OpenGL contexts. Each context can represent a separate viewable surface, like a window in an application.
Each context has its own set of OpenGL Objects, which are independent of those from other contexts. A context's objects can be shared with other contexts. Any OpenGL object types which are not containers are sharable, as well as Sync Objects and GLSL Objects (excluding program pipeline objects). All container objects are not shared between contexts.
Any object sharing must be made explicitly, either as the context is created or before a newly created context creates any objects. However, contexts do not have to share objects; they can remain completely separate from one another.
In order for any OpenGL commands to work, a context must be current; all OpenGL commands affect the state of whichever context is current. The current context is a thread-local variable, so a single process can have several threads, each of which has its own current context. However, a single context cannot be current in multiple threads at the same time.
Until version 3.0, all versions of OpenGL were fully backwards compatibile with earlier ones. Code written against OpenGL 1.1 could execute just fine on OpenGL 2.1 implementations.
OpenGL version 3.0 introduced the idea of deprecating functionality. Many OpenGL functions were declared deprecated, which means that users should avoid using them because they may be removed from later API versions. OpenGL 3.1 removed almost all of the functionality deprecated in OpenGL 3.0. This includes the Fixed Function Pipeline.
However, since many implementations support the deprecated and removed features anyway, some implementations want to be able to provide a way for users of higher GL versions to gain access to the old APIs. Several techniques were tried, and it has settled down into a division between Core and Compatibility contexts.
There are other context variations as well.
OpenGL 3.1 and ARB_compatibility
A new extension, ARB_compatibility, was introduced when OpenGL 3.1 was revealed. The presence of this extension is a signal to the user that deprecated or removed features are still available through the original entrypoints and enumerations. The behavior of such implementations is defined with a separate, much larger, OpenGL Specification. Thus, there was a backwards-compatible specification and a non-backwards compatible specification.
OpenGL 3.2 and Profiles
When OpenGL 3.0 was introduced, a new context creation mechanism was introduced as well. Since later versions could remove functionality, it was important that the user be able to ask for a specific version of OpenGL, one that they had written their code against.
However, the ARB_compatibility extension posed a problem: the implementation decided whether to define it or not. A user could not request to deactivate ARB_compatibility; it was forced on them. This also meant that the core specification had to be a proper subset of the compatibility specification; the core specification couldn't provide functionality that the compatibility one did not provide.
Thus, another change was made to context creation.
The 3.0 form of context creation did not have the concept of profiles. There was only one form of OpenGL: the core specification. In 3.2, OpenGL was effectively split into two profiles, core and compatibility. An implementation was only required to define core, so compatibility is not guaranteed to be available. However, on most implementations, the compatibility profile will be available.
The 3.2 wording also changed what kind of contexts can be returned, allowing 3.0 and higher versions to be given when not directly asked so long as they support ARB_compatibility or are the compatibility profile of that version of OpenGL. So if you ask for 2.1, the implementation is free to give you 3.2 compatibility; it was not previously free to do this.
Because of the change in wording, the way to detect the changed functionality is to check the extension string. If WGL_ARB_create_context_profile is present, then it uses the 3.2 wording. Otherwise it uses the 3.0/3.1 wording.
A context, of version 3.0 or greater, can be created with the "forward compatibility" bit set. This will cause, for the given profile, all functionality marked "deprecated" to be removed. You can combine the forward compatibility bit with core and compatibility contexts.
For 3.0, this means that all deprecated functionality will no longer be available. This simulates the 3.1 experience.
For 3.1, this means that any remaining deprecated functionality (things deprecated in 3.0 but not removed in 3.1) will be removed. Basically, wide-lines. Also, you're not likely to see implementations offer ARB_compatibility if you pass forward compatibility.
For 3.2+ compatibility, it should mean nothing at all. Since no functionality is marked deprecated in the compatibility profile, the forward compatibility bit removes nothing.
For 3.2+ core, it again means that all functionality that is still deprecated (wide-lines) will be removed.
A context can be created in debug mode. This allows, among other things, debug output functionality to work more effectively.
No error contexts
These contexts do not report OpenGL errors, except for GL_OUT_OF_MEMORY. This cannot be combined with debug contexts, for obvious reasons.
Robust access context
Normally, many buffer memory access operations that access data outside of the bound range of storage have undefined results (potentially including program termination). However, if the program doesn't crash, this can lead to being able to read values that were written by other applications, which is a security concern.
Robust access means that out-of-bounds reads will provide well-defined results (usually zero). And such accesses will never cause program termination. It provides better process isolation.
Context information queries
There is a lot of information about an OpenGL context can be queried.
OpenGL version number
To get the OpenGL major and minor version numbers, you can call these functions:
glGetIntegerv(GL_MAJOR_VERSION, *); glGetIntegerv(GL_MINOR_VERSION, *);
These are available on OpenGL version 3.0 and above contexts. If those are not available, you can use this instead:
The string returned starts with "<major version>.<minor version>". Following the minor version, there can be another '.', then a vendor-specific build number. The string may have more content, which is completely vendor-specific (thus not a part of the OpenGL standard).
For example, the returned string may be like "2.0.6914 WinXP SSE/SSE2/SSE3/3DNow!". 2.0 is the actual version number of GL supported. 6914 is a driver build number. WinXP is the OS. SSE/SSE2/SSE3/3DNow! are CPU features that the driver can use.
Sometimes glGetString(GL_VERSION) also returns also the bus type used, such as AGP or PCI or PCIEx.
The OpenGL implementations have a vendor string associated with it that is used for identifying the maker of the implementation.
It could be "ATI Technologies", "NVIDIA Corporation", "INTEL" and so on. Note that there's no guarantee that the string for a specific vendor will remain the same in future implementations. On Windows, if it says "Microsoft" then you are using the Windows software renderer or the Windows Direct3D wrapper. You probably haven't installed the graphics drivers yet in that case.
This names the renderer used by the implementation.
This string is often the name of the GPU. In the case of Mesa3d, it would be i.e "Gallium 0.4 on NVA8". It might even say "Direct3D" if the Windows Direct3D wrapper is being used.
Extensions can be queried one by one. To do this, first use glGetIntegerv(GL_NUM_EXTENSIONS, *) to get the number of extensions supported by the implementation. Then iterate over each one with this:
Where k is less than the GL_NUM_EXTENSIONS value.
Legacy extension list
|Warning: This section describes legacy OpenGL APIs that have been removed from core OpenGL 3.1 and above (they are only deprecated in OpenGL 3.0). It is recommended that you not use this functionality in your programs.|
A string containing a space-separated list of extension names can be queried as follows:
There are multiple kinds of OpenGL contexts.
You can detect which profile the context supports with this query:
This can contain the bits GL_CONTEXT_CORE_PROFILE_BIT or GL_CONTEXT_COMPATIBILITY_PROFILE_BIT, but not both at the same time.
Other features of contexts can be detected via context flags:
The available context flags are:
- The context is a forward compatible context.
- The context is a debug context.
- The context supports robust memory access functionality.
- The context does not report OpenGL errors.
Shading language version
The primary version of GLSL supported by the implementation can be queried:
The version string has almost the same format as the context version string. The difference is that the minor version always has two digits.
Supported GLSL versions
|Core in version||4.6|
|Core since version||4.3|
Support for specific versions of GLSL can be queried via an indexed get. The number of supported GLSL versions is queried with glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, *). Each individual version can be queried from an indexed string:
Where k is on the range 0 to GL_NUM_SHADING_LANGUAGE_VERSIONS - 1.
These strings use the formatting of GLSL's #version declaration. This has the following forms:
The profile is only present for versions of GLSL that have this distinction.
Note that GLSL only gained the #version declaration in version 1.10; if an implementation exposes support for GLSL 1.00 (through ARB_shading_language_100), then it will return an empty string ("").
Versions of the GLSL for OpenGL ES can also be supported. If an implementation returns "100", this does not refer to GLSL 1.00. It instead refers to support for OpenGL ES's 2.0's GLSL ES version 1.00. The profile can also be "es", which represents a version of OpenGL ES's shading language. So version "300 es" represents GLSL ES 3.00. GLSL ES 1.00 does not use the "es" profile name.