GLEW: The OpenGL Extension Wrangler Library

# The OpenGL Extension Wrangler Library

Introduction
Obtaining GLEW
Supported Extensions
How to Build Your Project with GLEW
How to Install GLEW
How to Use GLEW
Utilities
Automatic Code Generation
Separate Namespace
Multiple Rendering Contexts (GLEW MX)
Known Issues
Credits, Copyright
Change Log

## Introduction

The goal of the OpenGL Extension Wrangler Library (GLEW) is to assist C/C++ OpenGL developers with two tedious tasks: initializing and using extensions and writing portable applications. GLEW provides an efficient run-time mechanism to determine whether a certain extension is supported by the driver or not. OpenGL core and extension functionality is exposed via a single header file. GLEW currently supports a variety of platforms and operating systems, including Windows, Linux, Darwin, Irix, and Solaris.

## Obtaining GLEW

Source and precompiled binaries are available at the project website.

## Supported Extensions

GLEW currently supports the following extensions:

- OpenGL extensions
- WGL extensions
- GLX extensions

Useful links about OpenGL extensions:

- All About OpenGL Extensions
- OpenGL Extension Registry
- ATI OpenGL Extension Specifications
- NVIDIA OpenGL Extension Specifications
- APPLE OpenGL Extensions Guide

## How to Build Your Project with GLEW

There are two ways to build your project with GLEW.

### Including the source files / project file

The simpler but less flexible way is to include `glew.h` and `glew.c` into your project and define the `GLEW_STATIC` preprocessor constant for the static library or executable you are building together with GLEW (Windows only). You also need to replace `<GL/gl.h>` and `<GL/glu.h>` with `<glew.h>` in your code and set the appropriate include flag (`-I`) to tell the compiler where to look for it. For example:

>     #include <glew.h>
>     #include <GL/glut.h>
>     <gl, glu, and glut functionality is available here>

Depending on where you put `glew.h` you may also need to change the include directives in `glew.c`. Note that if you are using GLEW together with GLUT, you have to include `glew.h` first. In addition, `glew.h` includes `glu.h`, so you don't need to include it separately.

On Windows you also have the option of adding the supplied project file `glew_static.dsp` to your workspace (solution) and compile it together with your other projects. In this case you need to change the `GLEW_BUILD` preprocessor constant to `GLEW_STATIC`, otherwise you get build errors. Note that GLEW does not use the C runtime library, so it does not matter which version (single-threaded, multi-threaded or multi-threaded DLL) it is linked with (without debugging information). It is, however, always a good idea to compile all your projects including GLEW with the same C runtime settings.

### Using GLEW as a shared library

Alternatively, you can use the provided project files / makefile to build a separate shared library you can link your projects with later. In this case the best practice is to install `glew.h`, `glew32.lib`, and `glew32.dll` / `libGLEW.so` to where the OpenGL equivalents `gl.h`, `opengl32.lib`, and `opengl32.dll` / `libGL.so` are located. Note that you need administrative privileges to do this. If you do not have administrator access and your system administrator will not do it for you, you can install GLEW into your own lib and include subdirectories and tell the compiler where to find it. Then you can just replace `<GL/gl.h>` with `<GL/glew.h>` in your program:

>     #include <GL/glew.h>
>     #include <GL/glut.h>
>     <gl, glu, and glut functionality is available here>

or:

>     #include <GL/glew.h>
>     <gl and glu functionality is available here>

Don't forget to link your project with `glew32.lib`, `glu32.lib`, and `opengl32.lib` on Windows and `libGLEW.so`, `libGLU.so`, and `libGL.so` on Linux and IRIX (`-lGLEW -lGLU -lGL`).

It is important to keep in mind that `glew.h` includes neither `windows.h` nor `gl.h`. Also, GLEW will warn you by issuing a preprocessor error in case you have included `gl.h`, `glext.h`, or `glATI.h` before `glew.h`.

## How to Install GLEW

To install the shared library version of GLEW you need to copy the headers and libraries into their destination directories. On Windows this boils down to copying (no, we will not write a Windows installer for you).

`lib/glew32.dll` | to | `%SystemRoot%/system32`
`lib/glew32.lib` | to | `{VC Root}/Lib`
`include/GL/glew.h` | to | `{VC Root}/Include/GL`
`include/GL/wglew.h` | to | `{VC Root}/Include/GL`

where `{VC Root}` is your Visual C++ directory, typically `C:/Program Files/Microsoft Visual Studio/VC98` for Visual Studio 6.0 or `C:/Program Files/Microsoft Visual Studio/Vc7/PlatformSDK` for Visual Studio .NET.

On Linux and IRIX, typing `"make install"` will attempt to install GLEW into `/usr/include/GL` and `/usr/lib`. You can customize the installation target via the `GLEW_DEST` environment variable if you do not have write access to these directories.

## How to Use GLEW

### Initializing GLEW

First you need to create a valid OpenGL rendering context and call `glewInit()` to initialize the extension entry points. If `glewInit()` returns `GLEW_OK`, the initialization succeeded and you can use the available extensions as well as core OpenGL functionality. For example:

>     #include <GL/glew.h>
>     #include <GL/glut.h>
>     ...
>     glutInit(&argc, argv);
>     glutCreateWindow("GLEW Test");
>     GLenum err = glewInit();
>     if (GLEW_OK != err)
>     {
>       /* problem: glewInit failed, something is seriously wrong */
>       fprintf(stderr, "Error: %s\n", glewGetErrorString(err));
>       ...
>     }
>     fprintf(stdout, "Status: Using GLEW %s\n", glewGetString(GLEW_VERSION));

### Querying the available OpenGL extensions

Starting from GLEW 1.1.0, you can find out if a particular extension is available on your platform by querying globally defined variables of the form `GLEW_{extension_name}`:

>     if (GLEW_ARB_vertex_program)
>     {
>       /* it is safe to use the ARB_vertex_program extension here */
>       glGenProgramsARB(...);
>     }

In GLEW 1.0.x, a global structure was used for this task. To ensure binary compatibility between releases, the struct was replaced with a set of variables.

You can also check for core OpenGL functionality. For example, to see if OpenGL 1.3 is supported:

>     if (GLEW_VERSION_1_3)
>     {
>       /* Yay! OpenGL 1.3 is supported! */
>     }

In general, you can check if `GLEW_{extension_name}` or `GLEW_VERSION_{version}` is set or not.

For extensions `glewGetExtension` provides a slower alternative:

>     if (GL_TRUE == glewGetExtension("GL_ARB_fragment_program"))
>     {
>       /* Looks like ARB_fragment_program is supported. */
>     }

### Experimental drivers

GLEW works by querying the supported extensions from the graphics driver. Experimental drivers, however, might not report every available extension through the standard mechanism, in which case GLEW will report it unsupported. To circumvent this situation, the `glewExperimental` global switch can be turned on by setting it to `GL_TRUE` before calling `glewInit()`. This makes sure that all extensions with valid entry points will be exposed.

### Platform specific extensions

Platform specific extensions are separated into two header files: `wglew.h` and `glxew.h`, which define the available `WGL` and `GLX` extensions. To determine if a certain extension is supported, query `WGLEW_{extension name}` or `GLXEW_{extension_name}`. For example:

>     #include <GL/wglew.h>

>     if (WGLEW_ARB_pbuffer)
>     {
>       /* OK, we can use pbuffers */
>     }
>     else
>     {
>       /* Sorry, pbuffers will not work on this platform */
>     }

## Utilities

GLEW provides two command line tools: one for creating a list of available extensions and visuals; and another for verifying extension entry points.

### wglinfo: extensions and visuals on Windows

`wglinfo` is the Windows version of `glxinfo`. By default it creates a file called `wglinfo.txt` that contains a list of available OpenGL, WGL, and GLU extensions as well as a table of visuals aka. pixel formats. Pbuffer and multiple output capable visuals are also included. The format of the table is described here. For additional usage information, type `wglinfo -h`.

### glewinfo: extension verification utility

`glewinfo` allows you to verify the entry points for the extensions supported on your platform. It uses GLEW to find out which extensions and entry points are available. On Windows it reports the results to a text file called `glewinfo.txt`, on Unix it prints them to `stdout`.

Windows Usage:

>     glewinfo [-pf <id>]

where `<id>` is the pixelformat id for which the capabilities are displayed.

Unix Usage:

>     glewinfo [-display <dpy>] [-visual <id>]

where `<dpy>` is the X11 display and `<id>` is the visual id for which the capabilities are displayed.

## Automatic Code Generation

Starting with release 1.1.0, the source code and parts of the documentation are automatically generated from the extension specifications via a two-step process. In the first step, specification files from the OpenGL registry are parsed and skeleton descriptors are created for each extension. These descriptors contain all necessary information for creating the source code and documentation in a simple and compact format, including the name of the extension, url, tokens, function declarations, typedefs and struct definitions. In the second step, the header files as well as the library and glewinfo source are generated from the descriptor files. The code generation scripts are located in the `auto` subdirectory.

## Separate Namespace

To avoid name clashes when linking with libraries that include the same symbol, extension entry points are declared in a separate namespace (release 1.1.0 and up). This is achieved by aliasing OpenGL function names to their GLEW equivalents. For instance, `glFancyFunction` is simply an alias to `glewFancyFunction`. Note that the separate namespace doesn't effect token and function pointer definitions.

## Multiple Rendering Contexts (GLEW MX)

Starting with release 1.2.0, thread-safe support for multiple rendering contexts (possibly with different capabilities) is available. Since this is not required by most users, it is not added to the binary releases to maintain compatibility between different versions. To include multi-context support, you have to do the following:

1. Compile and use GLEW with the `GLEW_MX` preprocessor token defined.
2. For each rendering context, create a `GLEWContext` object that will be available as long as the rendering context exists.
3. Define a macro or function called `glewGetContext()` that returns a pointer to the `GLEWContext` object associated with the rendering context from which OpenGL/WGL/GLX calls are issued. (This dispatch mechanism is primitive, but generic.)
4. Replace the global `glewInit()` call with `glewContextInit(glewGetContext())`. Note, that the `GLEWContext` pointer returned by `glewGetContext()` has to reside in global or thread-local memory. Also, remember to call `glewContextInit` after creating the `GLEWContext` object in each rendering context.

Note that according to WGL documentation, you have to initialize the entry points for every rendering context you create that use pixel formats with different capabilities (for example the pixel formats provided by the generic software OpenGL implementation by Microsoft vs. the hardware accelerated pixel formats). GLEW by default ignores this requirement, and does not define per-context entry points (you can however do this using the steps described above). Assuming a global namespace for the entry points works in most situations, because typically all hardware accelerated pixel formats provide the same entry points and capabilities (and why would anyone want to use the software renderer when hardware acceleration is available?). This means that unless you use the multi-context version of GLEW, you need to call `glewInit()` only once in your program, or more precisely, once per process.

## Known Issues

GLEW requires GLX 1.2 to assure compatibility with GLUT. Also, the SGI GLX video extensions are currently not supported.

## Credits, Copyright

GLEW was developed by Milan Ikits and Marcelo Magallon. They also perform occasional maintainance to make sure that GLEW stays in mint condition. Aaron Lefohn, Joe Kniss, and Chris Wyman were the first users and also assisted with the design and debugging process. The acronym GLEW originates from Aaron Lefohn. Pasi Kärkkäinen identified and fixed several problems with GLX and SDL. The RPM packages are maintained by Karol Pietrzak. Nate Robins created the `wglinfo` utility, to which modifications were added by Michael Wimmer.

GLEW is originally derived from the EXTGL project by Lev Povalahev. The source code is licensed under the modified BSD license, the SGI Free Software License B, and the GLX Public License. The automatic code generation scripts are released under the GPL.

## Change Log

- 1.2.3 [06-10-04]
  - Added NV_fragment_program2, NV_fragment_program_option, NV_vertex_program2_option, NV_vertex_program3
  - Bug fix in GL_ARB_vertex_blend

- 1.2.2 [05-08-04]
  - Added GL_EXT_pixel_buffer_object, removed GL_NV_element_array
  - Fixed GLEW_MX problems
  - Bug fix in GL_EXT_texture_rectangle and `wglinfo`

- 1.2.1 [03-18-04]
  - Bug fix in OpenGL version query (early release of 1.2.0 contained this bug)
  - Bug fix in GL_ARB_shader_objects and temporary bug fix in GL_ARB_vertex_shader
  - Added flags on GDI support and multisampling to `wglinfo`

- 1.2.0 [02-19-04]
  - Added full OpenGL 1.5 support
  - Added support for multiple rendering contexts with different capabilities
  - Added command line flags to `glewinfo` for selecting displays and visuals
  - Added GLX_SGIS_multisample, GLX_SUN_video_resize, and GL_SUN_read_video_pixels
  - Added MinGW/MSYS support
  - Bug fixes in GL_ARB_shader_objects and the OS X build

- 1.1.4 [12-15-03]
  - Added GL_APPLE_float_pixels, GL_APPLE_texture_range, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GLX_ATI_pixel_format_float, and GLX_ATI_render_texture
  - Bug fixes in GL_ATI_map_object_buffer and GL_ATI_fragment_shader

- 1.1.3 [10-28-03]
  - Added Solaris and Darwin support
  - Added GL_ARB_fragment_shader, GL_ARB_shader_objects, and GL_ARB_vertex_shader
  - Fixed bug in GL_WIN_swap_hint
  - Removed `glewinfo`'s dependency on `GLUT`

- 1.1.2 [09-15-03]
  - Removed dependency on WGL_{ARB,EXT}_extensions_string
  - Added glewGetString for querying GLEW version string

- 1.1.1 [08-11-03]
  - Added GLX_NV_float_buffer
  - Fixed bug in GL_ARB_vertex_buffer_object
  - Minor updates in documentation

- 1.1.0 [07-08-03]
  - Added automatic code generation
  - Added almost every extension in the registry
  - Added separate namespace
  - Added IRIX support
  - Updated documentation

- 1.0.7 [06-29-03]
  - Added GL_EXT_depth_bounds_test
  - Fixed typos

- 1.0.6 [05-05-03]
  - Added ARB_vertex_buffer_object and NV_half_float
  - Updated `wglinfo`
  - Temporary Linux bug fixes (problems with SDL and MESA)

- 1.0.5 [02-17-03]
  - Bug fixes
  - Added `wglinfo`
  - Updated documentation

- 1.0.4 [02-02-03]
  - Added NV_texture_expand_normal
  - Added mingw support
  - Updated documentation

- 1.0.3 [01-09-03]
  - Cleaned up ATI extensions
  - Changed function prototypes to match glext.h
  - Added EXT_texture3D
  - Fixed typos in ATI_vertex_attrib_array_object and ATI_draw_buffers

- 1.0.2 [12-21-02]
  - Added list of supported extensions to documentation
  - Added NV_half_float and NV_texgen_emboss

- 1.0.1 [12-17-02]
  - Bug fixes
  - Added glewGetExtension

- 1.0.0 [12-12-02]
  - Initial release

Last update: 06-10-04