All About OpenGL Extensions

Copyright 1998, 1999 by Mark J. Kilgard. Last Updated July 10, 2000 Commercial publication in written, electronic, or other forms without expressed written permission is prohibited. Electronic redistribution for educational or private use is permitted.

How OpenGL Extensions are Documented
An OpenGL extension is defined by its specification. These specifications are typically written as standard ASCII text files. OpenGL extension specifications are written by and for OpenGL implementers. A well-written OpenGL specification is documented to the level of detail needed for a hardware designer and/or OpenGL library engineer to unambiguously implement the extension. This means that OpenGL application programmers should not expect an extension’s specification to fully justify why the functionality exists or how an OpenGL application would go about using the functionality. An OpenGL extension is not a tutorial on how to use the particular extension. Still, being able to read and understand an OpenGL specification helps you, the application programmer, fully understand an OpenGL extension’s functionality.
Where to Find OpenGL Extension Specifications
The latest public OpenGL specifications can be found at the OpenGL Extension Registry. Note that extension specifications are updated from time to time based on reviews and implementation feedback.
How to Read an OpenGL Extension Specification
When reading an OpenGL extension specification, it helps to be familiar with the original OpenGL specification. The operation of an OpenGL extension is described as additions and changes to the core OpenGL specification. Having a copy of the core OpenGL specification handy is a good idea when reviewing an OpenGL specification.

OpenGL extension specifications consist of multiple sections. There is common form established by convention used by nearly all OpenGL extension specifications. Often within a specification, the gl and GL prefixes on routine names and tokens are assumed. The following describes the purpose of the most common sections in the order that they normally appear in extension specifications:

Name

Lists the official name of the extension. This name uses underscores instead of spaces between words. The name also begins with a prefix that indicates who developed the extension. This prefix helps to avoid naming conflicts if two independent groups implement a similar extension. It also helps identity who is promoting use of the extension. For example: SGIS_point_parameters was an extension proposed by Silicon Graphics. The SGIS prefix belongs to Silicon Graphics. SGI uses the SGIS prefix to indicate the extension is specialized and may not be available on all SGI hardware. Other prefixes in use are:
Note that the SGIS_point_parameters extension has since been standardized by other OpenGL vendors such as NVIDIA. So now there is also an EXT_point_parameters extension with the same basic functionality as the SGIS version. The EXT prefix indicates that multiple vendors have agreed to support the extension. Successful OpenGL extensions are often promoted to EXT or ARB extensions or made an official part of OpenGL in a future revision to the core OpenGL specification. Almost all of the new functionality in OpenGL 1.1 and 1.2 showed up first as OpenGL extensions.

Name Strings

The name string or strings is used to indicate that the extension is supported by a given OpenGL implementation. Applications can query the GL_EXTENSIONS string with OpenGL’s glGetString to determine what extensions are available. OpenGL also supports the idea of window system dependent extensions. Core OpenGL extension name strings are generally prefixed with GL while window system dependent extensions are prefixed with GLX for the X Window System or WGL for Win32 based on what window system the extension applies to. Note that there may be multiple strings if the extension provides both core OpenGL rendering functionality and window system dependent functionality.

Version

A source code control revision string to keep track of what version of the specification the given text file represents. It is important to make sure that you have the latest version of the extension specification in case there are any important changes. Normally the version string has the date the extension was last updated.

Number

Each OpenGL extension is assigned a unique number. Silicon Graphics allocates these numbers to ensure that OpenGL extensions do not overlap in their usage of enumerants or protocol tokens. This number is only important to extension implementers.

Dependencies

Often an extension specification builds on the functionality of pre-existing extensions. This section documents what extensions the specified extension depends on. Dependencies indicate that another extension "is required" to support the specified extension or that the specified extension "affects" the specification of another extension. When an extension affects the specification of another extension, the affecting extension is responsible for fully documenting the interactions between the two extensions.

The dependencies section often also indicates which version of the OpenGL core standard that the extension specification is based on. Later sections specify the extension based on updates to the relevant section of the particular OpenGL specification that the extension is based on.

You can often tell how important a given extension is to the evolution of OpenGL based on how many other extensions are listed that depend on or are affected by the given extension. The multitexture extension to be discussed later affects gobs of other extensions!

Overview

The section provides a description, often terse and without justification, for the extension’s specified functionality. If you are trying to figure out what the extension does, this is the most useful section of an OpenGL extension specification. Do not expect a tutorial though.

Issues

Often there are issues that need to be resolved in the specification of an extension. This section documents open issues and states the resolution to resolved issues. These issues are often things of interest to the extension implementer, but can also help a programmer understand how the extension really works.

New Procedures and Functions

This section lists the function prototypes for any new procedures and functions that the extension adds. Keep in mind that specifications often leave out the gl prefix when discussing routines. Also note that the extension’s new functions will be suffixed with the same letters used as the prefix for the extension name.

New Tokens

This section lists the tokens (also called enumerants) that the extension adds. The routines that accept each set of new enumerants are documented. The integer value of the enumerants is documented here. These values should be added to <GL/gl.h>. Keep in mind that specifications often leave out the GL prefix when discussing enumerants. Also note that the extension’s new enumerants will be suffixed with the same letters used as the prefix for the extension name.
Additions to Chapter XX of the 1.X Specification (XXX)
These sections document how the core OpenGL specification should be amended to add the extension’s functionality to the core OpenGL functionality. Notice that the exact version of the core OpenGL specification (such as 1.0, 1.1, or 1.2) is documented. The chapters typically amended by an extension specification are:
These sections are quite legalistic. They indicate precisely how the OpenGL specification wording should be amended or changed. Often tables within the specification are amended as well.

Additions to the GLX Specification

If an extension has any window system dependent functionality affecting the GLX interface to the X Window System, these issues would be documented here.

GLX Protocol

When implementing the extension for the X Window System, if any special X11 extension protocol for the GLX extension is required to support the extension, the protocol would be documented in this section.

Dependencies on XXX

These sections describe how the extension depends on some other extension that was listed in the Dependencies section. Usually the wording says that if the other extension is not supported, simply ignore the portion of this extension dealing with the dependent extension’s state and functionality.

Errors

If the extension introduces any new error conditions particular to the extension, they are documented here.

New State

Extensions typically add new state variables to OpenGL’s state machine. These new variables are documented in this section. The variable’s get enumerant, type, get command, initial value, description, section of the specification describing the state variable’s function, and the attribute group that the state belongs to are all documented in tables in this section.

New Implementation Dependent State

Extensions may add implementation dependent state. These are typically maximum and minimum supported ranges for the extension functionality. For example, what is the widest line size supported by the extension. These values can be queried through OpenGL’s glGet family of routines.

Backward Compatibility

If the extension supercedes an older extension, issues surrounding backward compatibility with the older extension are documented in this section.

Note that these sections are merely established by convention. While the conventions for OpenGL extension specifications are normally followed, extensions vary in how closely they stick to the conventions. Generally, the more preliminary an extension is, the more loosely specified it is. Hopefully after sufficient review and even implementation, the specification language and format is improved to provide an unambiguous final specification.
Portably Using OpenGL Extensions
The advantage of using OpenGL extensions is getting access to cutting edge rendering functionality so you application can achieve higher performance and higher quality rendering. OpenGL extensions give you access to the latest features of the hottest new graphics hardware. The problem with OpenGL extensions is that lots of OpenGL implementations, particularly older implementations, will not support the extensions that you would like to use. When you write an OpenGL application that uses extensions, you should make sure that your application still works when the extension is not supported. At the very least your program should report that it requires whatever extension is missing and exit without crashing.

The first step to using OpenGL extensions is to locate the copy of the <GL/gl.h> header file that advertises the API interfaces for the extensions that you plan to use. Typically you can get this from your OpenGL implementation vendor or OpenGL driver vendor. You could also get the API interface prototypes and macros directly from the extension specifications, but getting the right <GL/gl.h> from your OpenGL vendor is definitely the preferred way.

You will notice that <GL/gl.h> sets C preprocessor macros to indicate whether the header advertises the interface of a particular extension or not. For example, the basic <GL/gl.h> supplied with Visual C++ 4.2 has a section reading:

/* Extensions */
#define GL_EXT_vertex_array 1
#define GL_WIN_swap_hint 1
#define GL_EXT_bgra 1
#define GL_EXT_paletted_texture 1
#define GL_EXT_clip_disable 1

These macros indicate that the header file advertises the above five extensions. The EXT_bgra extension lets you read and draw pixels in the Blue, Green, Red, Alpha component order as opposed to OpenGL’s standard RGBA color component ordering. If you wanted to write a program to use the EXT_bgra extension, you could test that the extension is supported at compile time like this:

#ifdef GL_EXT_bgra
glDrawPixels(width, height, GL_BGRA_EXT, GL_UNSIGNED_BYTE, pixels);
#endif

When GL_EXT_bgra is defined, you can expect to find the GL_BGRA_EXT enumerant defined. Note that if the EXT_bgra extension were not supported, you would expect the glDrawPixels line above to generate a compiler error because the base OpenGL standard does not define the GL_BGRA_EXT enumerant.

So based on the extension name #defines in <GL/gl.h>, you can write your code so that it can compile in the extension functionality if your compiler environment supports the extension’s interfaces. The next problem is that even though your compiler environment may support the extension’s interface at compile-time, at run-time, the target system where you run your application may not support the extension. In the Win32 environment, different OpenGL ICD drivers can support different OpenGL extensions depending on what the hardware and the vendor’s ICD driver writers implement in the ICD driver.

Assuming that your application thread is made current to an OpenGL rendering context, the following routine can be used to determine at run-time if the OpenGL implementation really supports a particular extension:

#include <GL/gl.h>
#include <string.h>

int
isExtensionSupported(const char *extension)
{
const GLubyte *extensions = NULL;
const GLubyte *start;
GLubyte *where, *terminator;

/* Extension names should not have spaces. */
where = (GLubyte *) strchr(extension, ' ');
if (where || *extension == '\0')
    return 0;
extensions = glGetString(GL_EXTENSIONS);
/* It takes a bit of care to be fool-proof about parsing the
     OpenGL extensions string. Don't be fooled by sub-strings,
     etc. */
start = extensions;
for (;;) {
    where = (GLubyte *) strstr((const char *) start, extension);
    if (!where)
      break;
    terminator = where + strlen(extension);
    if (where == start || *(where - 1) == ' ')
      if (*terminator == ' ' || *terminator == '\0')
        return 1;
    start = terminator;
}
return 0;
}

With the isExtensionSupported routine, you can check if the current OpenGL rendering context supports a given OpenGL extension. To make sure that the EXT_bgra extension is supported before using it, you can do the following:

/* At context initialization. */
int hasBGRA = isExtensionSupported("GL_EXT_bgra");

/* When trying to use EXT_bgra extension. */
#ifdef GL_EXT_bgra
if (hasBGRA) {
    glDrawPixels(width, height, GL_BGRA_EXT, GL_UNSIGNED_BYTE, pixels);
} else
#endif
{
    /* No EXT_bgra so bail (or implement software workaround). */
    fprintf(stderr, "Needs EXT_bgra extension!\n");
    exit(1);
}

Notice that if the EXT_bgra extension is lacking at either run-time or compile-time, the code above will detect the lack of EXT_bgra support. Sure the code is a bit messy, but the code above works. You can skip the compile-time check if you know what development environment you are using and you do not expect to ever compile with a <GL/gl.h> that does not support the extensions that your application uses. But the run-time check really should be performed since who knows on what system your program ends up getting run on.
Win32’s Scheme for Getting Extension Function Pointers
The example above for safely detecting and using the EXT_bgra extension at run-time and compile-time is straightforward because the EXT_bgra simply adds two new enumerants (GL_BGRA_EXT and GL_BGR_EXT) and does not require any new function pointers.

Using an extension that includes new function call entry-points is harder in Win32 because you must first request the function pointer from the OpenGL ICD driver before you can call the OpenGL function.

The EXT_point_parameters extension provides eye-distance attenuation of OpenGL’s point primitive. This extension is used by Id Software in Quake 2 when the extension is present for rendering particle systems. With the extension, firing weapon and explosions are rendered as huge clusters of OpenGL point primitives with OpenGL automatically adjusting the point size based on the distance of the particles from the viewer. Closer particles appear bigger; particles in the distance appear smaller. A particle whose size would be smaller than a pixel is automatically faded based on its sub-pixel size. Anyone that wants to see the improvement this extension brings to a 3D game should play Quake 2 on a PC with NVIDIA’s RIVA 128 graphics processor. Start a gun battle and check out the particles!

The EXT_point_parameters extension adds two new OpenGL entry points called glPointParameterfEXT and glPointParameterfvEXT. These routines allow the application to specify the attenuation equation parameters and fade threshold. The problem is that because of the way Microsoft chose to support OpenGL extension functions, an OpenGL application cannot simply link with these functions. The application must first use the wglGetProcAddress routine to query the function address and then call through the returned address to call the extension function.

First, declare function prototype typedefs that match the extension’s entry points. For example:

#ifdef _WIN32
typedef void (APIENTRY * PFNGLPOINTPARAMETERFEXTPROC)(GLenum pname, GLfloat param);
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname, const GLfloat *params);
#endif

Your <GL/gl.h> header file may already have these typedefs declared if your <GL/gl.h> defines the GL_EXT_point_parameters macro. Now declare global variables of the type of these function prototype typedefs like this:

#ifdef _WIN32
PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT;
PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT;
#endif

The names above exactly match the extension’s function names. Once we use wglGetProcAddress to assign these function variables the address of the OpenGL driver’s extension functions, we can call glPointParameterfEXT and glPointParameterfvEXT as if they were normal functions. You pass wglGetProcAddress the name of the routine as an ASCII string. Verify that the extension is supported and, if so, initialize the function variables like this:

int hasPointParams = isExtensionSupported("GL_EXT_point_parameters");

#ifdef _WIN32
if (hasPointParams) {
    glPointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
    wglGetProcAddress("glPointParameterfEXT");
    glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
    wglGetProcAddress("glPointParameterfvEXT");
}
#endif

Note that before the code above is called, you should have a current OpenGL rendering context.

With the function variables properly initialized to the extension entry-points, you can use the extension like this:

if (hasPointParams) {
    static GLfloat quadratic[3] = { 0.25, 0.0, 1/60.0 };
    glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
    glPointParameterfEXT(GL_POINT_FADE_THRESHOLD_SIZE_EXT, 1.0);
}

Be careful because the function returned by wglGetProcAddress is only be guaranteed to work for the OpenGL rendering context that was current when wglGetProcAddress was called. If you have multiple contexts that return different extension function addresses, keeping the function addresses in global variables as shown above may create problems. You may need to maintain distinct function addresses on a per-context basis. Specifically, the Microsoft documentation for wglGetProcAddress warns:

The [Microsoft] OpenGL library supports multiple implementations of its functions. Extension functions supported in one rendering context are not necessarily available in a separate rendering context. Thus, for a given rendering context in an application, use the function addresses returned by the wglGetProcAddress function only.

The spelling and the case of the extension function pointed to by string must be identical to that of a function supported and implemented by OpenGL. Because extension functions are not exported by OpenGL, you must use wglGetProcAddress to get the addresses of vendor-specific extension functions.

The extension function addresses are unique for each pixel format. All rendering contexts of a given pixel format share the same extension function addresses.

Win32’s requirement that you use wglGetProcAddress is a real drag, but if you do everything right, using OpenGL extensions works and gives you access to amazing new OpenGL features.
Amazing New OpenGL Features
So what OpenGL extensions are in the works to help OpenGL programmers write better high-performance, high-quality games and other 3D applications?

Here we review seven OpenGL extensions that are certain to be useful for PC game and 3D application programmers. The functionality of each extension will be briefly described in this section, but the appendixes below provide the complete extension specifications for the seven extensions. This provides you the opportunity to learn how to read and understand OpenGL extension specifications for yourself.

The first three extensions represent already finalized, implemented, and available extensions. The next four extensions are nearing finalization with at least one of the four (the multitexture extension) being partially implemented today. Hardware support for all four of these preliminary extensions will be available by the end of 1998.
- The Point Parameters Extension
  
  The above discussion has already explained the basic functionality provided by the EXT_point_parameters extension. The extension was originally proposed by Silicon Graphics to address the needs of flight simulators for rendering point light sources such as landing lights that attenuate their brightness based on the distance from the viewer. Id Software also found the extension useful for rendering particle effects in Quake 2. In unextended OpenGL, the point primitive’s size is controlled with the glPointSize routine. The point size is specified as a constant number of pixels. Because glPointSize can not be called within glBegin and glEnd, it is difficult to render efficiently a batch of points of various sizes to simulate a particle system such as water drops or exploding shrapnel.
  
  What the extension provides is a means to attenuate the point size based on distance from the viewer. The further away the point primitive is from the viewer the smaller it should be rendered. If the point size becomes smaller than a pixel, the point’s alpha component is attenuated based on the sub-pixel size to dim the point.
  
  In addition to SGI’s implementation of the extension for InfiniteReality, the extension has also been implemented in NVIDIA’s OpenGL ICD driver for RIVA 128 and Brian Paul has implemented the extension in Mesa, the freeware implementation of the OpenGL programming interface. More implementations of the point parameters extension are expected. Figure 1 shows a snap shot of an OpenGL demo that uses the EXT_point_parameters extension. The source code for the point burst demo is at pointburst.c
  
  A pointer to the EXT_point_parameters specification.
  
  Figure 1 The pointburst demo uses the point parameters extension running on RIVA 128. The points have exploded outward in a circle from the center of the ground plane. The points closer to the viewer are large, while the far away points on the other side of the explosion source are small.
- The Paletted Texture Extension
  
  Textures are typically 2D arrays of RGB or RGBA color values. For colorful textures with 8 bits of precision per color component (3 or 4 bytes per texel), large textures can eat up quite a bit of texture memory. The EXT_paletted_texture enables a texture to be specified as a 2D array of indices into a texture palette. Generally the indices are 8 bits per texel, but the texture palette itself contains full 24-bit or 32-bit color values. For textures that use 256 or fewer unique colors, a paletted texture can take up a lot less texture memory. Of course, the texture palette takes up some space too though.
  
  Microsoft proposed the paletted texture extension to reduce the amount of texture memory needed by games and other 3D applications. Paletted textures also have the advantage that colors in the palette can be edited to change effectively the colors within the texture.
  
  A pointer to the EXT_paletted_texture specification.
- The Shared Texture Palette Extension
  
  The paletted texture extension provides a unique palette per texture, but this generality can make the management of texture palettes in hardware difficult. Since there may be just a single texture palette within the hardware rendering engine, the hardware may be continually loading the hardware texture palette on texture binds because each paletted texture maintains its own palette. By enabling the shared texture palette with glEnable, all the paletted textures of the rendering texture will share a single palette.
  
  A pointer to the EXT_shared_texture_palette specification.
- The Official Multitexture Extension
  
  The ARB_multitexture extension provides the capability to specify multiple sets of texture coordinates that look up into multiple textures. Multitexture support will redefine the performance and quality levels seen in tomorrow’s 3D games. Extra rendering passes to blend in lightmaps, as done by Quake 3 Arena, can be performed in a single rendering pass with the multitexture extension. Multitexture is useful for all manner of cool effects, not just lightmaps. Figure 2 shows how multitexturing can be used to simulate a dynamic underwater caustic effect. Download the underwater.zip source code distribution for the source files and texture images to build the underwater example. The ARB_multitexture functionality is fully orthogonal so texture features such as the texture matrix and texture coordinate generation modes are available and independently configurable for each texture unit.
  
  The ARB_multitexture extension is an official part of the OpenGL 1.2.1 specification. The ARB prefix indicates that the OpenGL Architecture Review Board, the governing body for OpenGL’s standardization and evolution, has formally approved the extension. Already, companies such as NVIDIA support the ARB_multitexture extension in their production OpenGL driver. Additionally, Mesa 3.1, the freeware implementation of the OpenGL API, includes full ARB_multitexture support. Software vendors such as Id Software have already transitioned their game engine to use ARB_multitexture.
  
  Before the ARB_multitexture, two extensions named SGIS_multitexture and EXT_multitexture were available. These extensions are deprecated in favor of the ARB_multitexture extension. The basic functionality is very similar, but the ARB_multitexture extension has cleaned up the interface.
  
  Consult Appendix F of the OpenGL 1.2.1 specification for the complete specification of the ARB_multitexture extension.
  
  Figure 2 The right image uses an second rendering pass to combine a second texture with the textured floor. The second textured rendering pass cycles through a set of shifting caustic patterns to simulate the effect of underwater lighting. The left image shows the scene without the underwater effect from the second texture pass. With unextended OpenGL, the underwater effect requires two textured rendering passes, but with the OpenGL multitexture extension on hardware such as NVIDIA’s multitexture-capable RIVA TNT graphics processor, the scene can be rendered with a single rendering pass.
- The Secondary Color Extension
  When texturing and lighting are both enabled, OpenGL performs per-vertex lighting calculations that are then combined with the filtered texture result based on the texture environment. Before OpenGL 1.2 introduced the ideal of a separate specular color, OpenGL, as originally specified, computed the post-lighting per-vertex color by simply adding in the specular contribution as part of the per-vertex lighting equation. The unfortunate result with this approach is that the specular lighting contribution is typically modulated with the texture color. This means a bright specular highlight can wind up blended into a dark surface texture. A bright specular highlight on a surface appears "on top of" the surface texture. This is not very realistic. A more plausible lighting equation would add the specular contribution after the texture environment. Think about a specular highlight on an eight ball on a pool table. Even though the ball’s surface texture is black, the highlight should still appear white.
  
  OpenGL 1.2 provides for a primary color and a secondary color. When both lighting and OpenGL 1.2’s new GL_SEPARATE_SPECULAR_COLOR state are enabled, the primary color is the result of the OpenGL’s lighting equation excluding the specular contribution while the secondary color is the equation’s specular contribution. Otherwise the secondary color is zero. The primary color is merged in the texture environment, and then the secondary color is added to the texture environment result. By adding the specular contribution after the texture environment, specular highlights appear "on top of" the surface texture.
  
  OpenGL 1.2 added support for a secondary color, but the secondary color is only updated through OpenGL’s lighting equations. The application programmer cannot directly assign the specular color. Programmers who implement their own per-vertex lighting calculations (a common requirement in game engines) have no easy way in the OpenGL 1.2 specification to supply their own pre-computed per-vertex specular color. The secondary color extension adds the capability to directly specify the secondary color on a per-vertex basis.
  
  A pointer to the EXT_secondary_color specification.
- The Fog Coordinate Extension
  OpenGL specifies that fogging should be computed based on eye distance but also allows implementations to use the fragment’s depth as an approximation of eye distance. The fog coordinate extension allows OpenGL applications to substitute OpenGL’s eye distance (or depth based approximation of eye distance) with an explicitly specified fog coordinate. The fog coordinate is a single coordinate that can be specified per-vertex. Game programmers often like to specify the fog coordinate explicitly, either because they want better control of the fog equation or they intend to use the hardware’s fog stage for some other devious purpose.
  
  Support for an application settable per-vertex secondary color and fog coordinate are responses from feedback from game developers. Because Direct3D Immediate Mode supported explicit control of these rasterization parameters and therefore hardware designed for Direct3D already had the fundamental support for specifying these parameters on a per-vertex basis, it made sense to expose explicit control of these rasterization parameters through OpenGL extensions.
  
  Both the fog coordinate and the secondary color can be passed both through immediate mode routines (glSecondaryColor3fEXT and glFogCoordfEXT) as well as through vertex arrays.
  
  A pointer to the EXT_fog_coord specification.
Conclusions
OpenGL continues to evolve its support for 3D game and applications programmers. OpenGL’s extension mechanism provides a way to keep the simplicity of OpenGL’s basic programming model while integrating innovative hardware capabilities into the API.

Compile-time and run-time checking for OpenGL extension support is necessary for robust OpenGL programs that use OpenGL extensions. Win32 makes accessing OpenGL extension functions more difficult because of the requirement to retrieve function pointers with wglGetProcAddress, but once the function entry-point addresses are retrieved, OpenGL extensions are easy to use with Win32.

The seven OpenGL extensions described above give OpenGL programmers new capabilities to control point size on a dynamic basis, to conserve texture memory usage, to utilize cutting-edge multitexture hardware, and gain explicit control over per-vertex parameters such as the specular color and fog coordinate.

The key to exploiting OpenGL extensions is reading and understanding the OpenGL extension specifications. An extension’s specification is the definitive word on how a given extension should work. Review the seven extension specifications cited above and look on the Web for the specifications to scores of other available OpenGL extensions.

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

All About OpenGL Extensions

Coding Resources