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.
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.
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||Linux 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.
Specific Extension Usage
Vertex submission extensions
- Please read http://www.opengl.org/wiki/Texture_Combiners
- Please read http://www.opengl.org/wiki/Textures_-_compression
- Floating point and mipmapping and filtering Core in GL 3.0
- GL_EXT_texture_integer Core in GL 3.0
- Please read http://www.opengl.org/wiki/Shading_languages
- GL_ARB_draw_buffers Core in GL 2.0
- GL_EXT_framebuffer_object More about FBOs
Extensions of Interest for the GL 2 Programmer
Extensions that you might need if you are targeting systems with GL 2.0 or GL 2.1
Perhaps you are new to GL programming and you find the large list at http://www.opengl.org/registry much too long to sift through.
WGL_EXT_extensions_string (and the WGL extensions you can get with this extension)
GL_NV_vertex_program (Many versions. GL_NV_vertex_program2, GL_NV_vertex_program3)
GL_NV_fragment_program (Many versions. GL_NV_fragment_program2, GL_NV_fragment_program3)
GL_GREMEDY_string_marker, GL_GREMEDY_frame_terminator (Special. Available in GLintercept which is a debugging tool)