OpenGL extensions are a means for OpenGL implementations to provide new or expanded functionality that the core of OpenGL does not provide. Using extensions should not be looked on as something to be avoided; it should be accepted as standard practice for the OpenGL user.
Some extensions expose features that only one particular hardware vendor exposes, but many extensions are implemented by multiple implementations. There is a mechanism for determining which extensions are available from a particular implementation.
- 1 Extension Registry
- 2 Content of an Extension
- 3 Extensions Loading
- 4 Extension Types
- 5 External Links
- 6 Extensions of Interest
- 7 How to read
The OpenGL Extension Registry is maintained by the ARB and contains the technical specifications of all known OpenGL extensions. The registry also contains guidelines for creating new extensions and has example C/C++ header files containing function entry points and token enums.
The extension registry has over 300 extensions listed. Many of these extensions are old and obsolete in modern programming practice; they are listed for the sake of completeness. Quite a few of these extensions have been folded into the OpenGL core.
Content of an Extension
An extension always contains at least one enum token, or one function. They mostly contain more. If an extension is supported on a specific computer, it means those tokens and/or functions can be used there. The name of the tokens and functions ends with the prefix of the extension. For example, the extension GL_ARB_multitexture (which has been adapted into the core) contains the function glActiveTextureARB and the token GL_TEXTURE0_ARB. The exception to this is core extensions, which is explained below.
All extensions are written against a version of OpenGL. The extension spec. specifies a modification to that core version's spec. That version is often (but not always) the minimum version that the extension can be used together with.
It is possible to check at run-time whether an extension is supported or not. For more information, see Get Context Info.
OpenGL extensions must be loaded dynamically at runtime. There are many automatic tools for loading them.
Extensions fall into 3 broad categories: vendor-specific, generic, and ARB-approved. The name of each extension starts with a prefix, specifying what type it is.
Extensions that start with GL_EXT are generic extensions. They can be implemented by any implementation. This does not ensure that they are implemented by all IHVs, but it means that the extension is available to be implemented by multiple vendors. It is also a signal to the user of OpenGL that this extension may find its way into other implementations.
There is a higher level of EXT extensions, called GL_ARB. These extensions are multi-vendor as well, but they are specifically approved by the OpenGL ARB. These are extensions that are most likely to enter later versions of the core OpenGL, and if they do, there will likely be few changes made to them.
All other prefixes are vendor-specific. GL_NV means that only NVIDIA hardware will implement this extension. GL_APPLE means that this extension will only be found on implementations that are on Macintoshes. And so forth.
Regardless of the vendor prefix, vendor-specific OpenGL extensions may be implemented an/or licensed by multiple hardware vendors to ensure compatibility. This is very rare in practice.
|Extension Prefix||Extension Vendor|
|ARB||OpenGL® ARB approved extensions.|
|NVX||NVIDIA Corporation. Experimental extension.1|
|ATI||ATI Technologies, Inc.|
|SUN||Sun Microsystems, Inc.|
|SGI||Silicon Graphics, Inc.|
|SGIX||Silicon Graphics, Inc. Experimental extension.1|
|SGIS||Silicon Graphics, Inc. Experimental extension.1|
|IBM||International Business Machines Corporation, or simply IBM.|
|MESA||The Mesa 3D Graphics Library.|
|GREMEDY||Graphic Remedy, Ltd.|
|OML||Khronos Group, Inc. API: OpenML®|
|OES||Khronos Group, Inc. API: OpenGL® ES|
|PGI||Portland Group Inc.|
|I3D||Intense3D, now 3DLABS Inc.|
|MTX||Matrox Electronic Systems Ltd.|
|Extension Prefix||Extension Platform|
|WGL_EXT, WGL_ARB, WGL_ATI, WGL_NV||Microsoft Corporation. WGL = Windows OpenGL|
|GLX_EXT, GLX_ARB, GLX_ATI, GLX_NV||X-Window-based platforms.|
|AGL||Apple Inc. AGL = Apple OpenGL|
1, Experimental extensions should not be used in a production environment as they are subject to removal from implementation.
Proprietary extensions which prove their worth can become ARB approved (such as GL_ARB_multitexture) and shortly after become core. Most likely, an extension is already of type EXT, then becomes ARB, then core. In some cases, but not many, a proprietary extension becomes ARB, then core. Often, the original extension's developer allows other companies to also code it into their drivers without royalty requirements.
In some cases, there are differences between extension and the core function. GLSL's extension version (ARB_shader_objects) was rather different from the core 2.0 functionality.
Anyone may develop extensions for the OpenGL® API; the community gives feedback. An example case would be the GL_GREMEDY_string_marker extension, which was initially a private extension, is now included in the OpenGL Extension Registry.
OpenGL version 3.0 added a 4th general group of extension: core extensions. Their purpose is to expose core features from higher versions in lower versions, which is particularly useful if those core features are hardware-based.
Core extensions all have the GL_ARB prefix, but their functions and enumerations do not end with ARB. This way, they exactly mimic the way the core functions and enumerations look; this allows code written to use them to be updated to higher GL versions without modifications. The behavior of core extensions is exactly the same as the corresponding core functionality.
There are some extensions that have been implemented for so long and so broadly that they are considered part of the basic structure of OpenGL. They are not core but this is mainly a technicality. The user should feel free to expect these extensions to be present.
Extensions of Interest
If you are new to OpenGL programming, you may find the large list in the OpenGL Registry too long and intimidating to sift through. This is a list of commonly useful extensions. They are grouped based on the OpenGL version you are targeting.
These are available and useful for all versions of OpenGL (assuming the implementation developer still supports the hardware):
- WGL_ARB_extensions_string (and the WGL extensions you can get with this extension)
- GL_ARB_debug_output: Only available if you create a debug context.
- GL_KHR_debug: replaces ARB_debug_output, and is always available, but it is depending on the implementation how much information, if any, is provided if used with a non-debug context.
Targeting OpenGL 3.3
These are useful extensions when targeting GL 3.3. These are either non-hardware extensions introduced after 3.3, or hardware features not exposed by 3.3's API. Most 3.3 hardware will provide these, given recent drivers.
- GL_NV_texture_barrier (implemented widely on AMD hardware)
AMD's 3.x-class hardware has features that are commonly 4.x-level features. These are exposed through these extensions:
Targeting OpenGL 2.1
These are useful extensions when targeting GL 2.1 hardware. Note that many of the above extensions are also available, if the hardware is still being supported. These represent non-hardware extensions introduced after 2.1, or hardware features not exposed by 2.1's API. Most 2.1 hardware that is still being supported by its maker will provide these, given recent drivers.
- Most of the previous list
Targeting GL 2.1, but on GL 3-class hardware (mainly for Mac OSX versions without GL 3.x support):
- GL_EXT_bindable_uniform (similar to Uniform Buffer Objects, but not as cleanly specified.)
How to read
Reading an OpenGL extension is somewhat complicated. Extensions have many sections, and these sections have different meanings. Some sections are descriptive while others are normative. A descriptive section does not represent the actual functionality of the extension; it either explains some facet of the extension or offers other useful information. Normative sections are those that actually specify the behavior of the OpenGL graphics system.
There are a number of sections in an extension that serve as simple introductory material. The Name, Name String, etc. These all have information that's fairly obvious to understand.
The Dependencies section is a bit more complicated. OpenGL extensions are sort of like .diff files. They specify changes to the OpenGL specification. A .diff file is useless without the file that it is to be applied to. And just as with .diff files, OpenGL extensions are written against a specific version of the OpenGL specification.
The version that the extension is written against is specified by the "This extension is written against..." text. If the extension extends GLSL, there will be a second version for the GLSL specification.
Extensions may be written against a particular specification version, but it is possible to implement them that extension on older OpenGL versions. Some extensions can be implemented even on OpenGL 1.1, while others have a higher base version. The minimum version that the extension can appear in is specified with the text, "X are required," where X is the minimum OpenGL and/or GLSL version required.
Extensions can also have a number of dependencies on either other extensions or higher version numbers. The idea is pretty simple, in general. If extension X changes its behavior in some way in the presence of extension Y, then extension X has a dependency on extension Y. This is stated with the text "This extension interacts with...". The specific interactions are specified in the main body of the extension.
The text "This extension interacts trivially with..." means that the interaction is fairly obvious. For example, the ARB_shader_image_load_store extension interacts "trivially" with ARB_tessellation_shader and/or OpenGL 4.0. The interaction is obvious: ignore references to the tessellation shader stages. This is a trivial interaction. Other interactions are not as trivial.
The Overview section is the heart of the descriptive text. It provides a plain-text explanation of what the extension does. This is descriptive text, so it is non-binding; the specific functionality is provided elsewhere. But the overview provides a good start in understanding what the extension actually does.
The main body of the normative text, the actual text that says how the extension works, is provided after the overview. It is broken down into two basic sections: a list of the new functions/enums, and a list of the spec additions/dependency descriptions. These sections comprise the main body of the extension.
Functions and enumerators
The New Procedures and Functions section is a list of all of the functions the extension provides, if any. The New Tokens section is a list of all of the enumerators provided, their values, and what functions accept them, if any.
Additions and Dependencies
After the tokens and functions, there will be several sections titled Additions to Chapter X of the..., where X is some chapter number in the OpenGL specification that the extension is written against. Within each addition section, there is a list of blocks of text, where the original text in the spec is either removed, added, or changed as outlined in the extension.
Following these can be a section titled Errors. This explains any possible errors rising from functions described or modified in this extension.
After this is a list of Dependencies sections. For every dependency listed in the first dependencies section at the beginning of the extension, there will be a block of text explaining how the spec changes in the presence of the extension or OpenGL version.
After the main body, we have various other descriptive information.
The Issues section is a list of design questions that the people working on the extension were asked and answered, informing how the extension came to its current form. This descriptive info is often handy in getting an idea how an extension works without having to read the specific details. The Overview can give a general idea of how it works, but the Issues section can give insight into what the details are.
The history of revisions of the extension. Most of these happen before it is first published, but some (rarely) happen later.