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 Extension Types
- 4 Specific Extension Usage
- 5 External Links
- 6 Extensions of Interest
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 glGetString.
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 rare occasions, there is a difference between extension and the core function, for example the case of GLSL in OpenGL 2.0 and the older extensions, and the case for environment textures. Many of the extensions in the OpenGL Extension Registry (OpenGL Extension Registry) are deprecated, make sure deprecated extensions are not used.
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. Normally, all extension functions and enumerations end in the type of their extension. So all GL_EXT functions end in EXT, all GL_ARB functions end in ARB, etc. However, it is often useful to expose core features from higher versions in lower versions, particularly if those core features are hardware-based.
Core extensions all have the GL_ARB prefix, but their functions and enumerations do not end in 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 their 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.
Specific Extension Usage
Vertex submission extensions
- Texture Combiners
- Floating point and mipmapping and filtering Core in GL 3.0
- GL_EXT_texture_integer Core in GL 3.0
- Framebuffer Objects Core extension, core in GL 3.0.
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.
For all versions:
- WGL_ARB_extensions_string (and the WGL extensions you can get with this extension)
Targeting GL 2.x: (extensions marked as [3.x] were adopted in some form in the 3.x line of OpenGL)
- GL_ARB_vertex_array_object [3.x]
- GL_ARB_framebuffer_object [3.x]
- If not this, you get very similar functionality from these:
- GL_ARB_texture_rectangle [3.x]
- GL_ARB_texture_float [3.x]
- GL_ARB_map_buffer_range [3.x]
- GL_ARB_copy_buffer [3.x]
- GL_ARB_occlusion_query [3.x]
- GL_ARB_color_buffer_float [3.x]
- GL_ARB_half_float_pixel [3.x]
- GL_ARB_sync [3.x]
- GL_EXT_transform_feedback [3.x]
- GL_NV_primitive_restart [3.x]
Targeting GL 2.x on 3.x hardware (mainly for Mac OSX, where GL 3.x is not yet available):
- GL_EXT_bindable_uniform (similar to Uniform Buffer Objects, but not as cleanly specified.)