sponsors gamedev.net search:

OpenGL Extensions As you're aware, the graphics industry has been moving at an alarmingly rapid pace for many years now. Today, consumer-level video cards include features that were only available on professional video cards (costing thousands of dollars) a few years ago. Any viable graphics API has to take these advances into account, and provide some means to keep up with them. OpenGL does this through extensions. If a graphics vendor adds a new hardware feature that they want OpenGL programmers to be able to take advantage of, they simply need to add support for it in their ICD, and then provide developers with documentation about how to use the extension. This is oversimplifying a bit, but it's close enough for our purposes. As an OpenGL programmer, you can then access the extension through a common interface shared by all extensions. You'll learn how to do that in the "Using Extensions" section, but for now, let's look at how extensions are identified, and what they consist of. Extension Names Every OpenGL extension has a name by which it can be precisely and uniquely identified. This is important, because hardware vendors will frequently introduce extensions with similar functionality but very different semantics and usage. You need to be able to distinguish between them. For example, both NVIDIA and ATI provide extensions for programmable vertex and pixel shaders, but they bear little resemblance to each other. So, if you wanted to use pixel shaders in your program, it wouldn't be enough to find out if the hardware supported pixel shaders. You'd have to be able to specifically ask whether NVIDIA's or ATI's version is supported, and handle each appropriately. All OpenGL extensions use the following naming convention: PREFIX_extension_name The "PREFIX" is there to help avoid naming conflicts. It also helps identify the developer of the extension or, as in the case of EXT and ARB, its level of promotion. Table 1 lists most of the prefixes currently in use. The "extension_name" identifies the extension. Note that the name cannot contain any spaces. Some example extension names are ARB_multitexture, EXT_bgra, NV_vertex_program, and ATI_fragment_shader. Table 1 - OpenGL Extension Prefixes Prefix    Meaning/Vendor ARB Extension approved by OpenGL's Architectural Review Board (first introduced with OpenGL 1.2) EXT Extension agreed upon by more than one OpenGL vendor 3DFX 3dfx Interactive APPLE Apple Computer ATI ATI Technologies ATIX ATI Technologies (experimental) HP Hewlett-Packard INTEL Intel Corporation IBM International Business Machines KTX Kinetix NV NVIDIA Corporation MESA http://www.mesa3d.org OML OpenML SGI Silicon Graphics SGIS Silicon Graphics (specialized) SGIX Silicon Graphics (experimental) SUN Sun Microsystems SUNX Sun Microsystems (experimental) WIN Microsoft Caution: Some extensions share a name, but have a different prefix. These extensions are generally not interchangeable, as they may use entirely different semantics. For example, ARB_texture_env_combine is not the same thing as EXT_texture_env_combine. Rather than making assumptions, be sure to consult the extension specifications when you're unsure. What an Extension Includes You now know what an extension is, and how extensions are named. Next, let's turn our attention to the relevant components of an extension. There are four parts of an extension that you need to deal with. Name Strings Each extension defines a name string, which you can use to determine whether or not the OpenGL implementation supports it. By passing GL_EXTENSIONS to the glGetString() method, you can get a space-delimited buffer containing all the extension name strings supported by the implementation. Name strings are generally the name of the extension preceded by another prefix. For core OpenGL name strings, this is always GL_ (e.g. GL_EXT_texture_compression). When the name string is tied to a particular windows system, the prefix will reflect which system that is (e.g. Win32 uses WGL_). Some extensions may define more than one name string. This would be the case if the extension provided both core OpenGL functionality and functionality specific to the windows system. Functions Many (but not all) extensions introduce one or more new functions to OpenGL. To use these functions, you'll have to obtain their entry point, which requires that you know the name of the function. This process is described in detail in the "Using Extensions" section. The functions defined by the extension follow the naming convention used by the rest of OpenGL, namely glFunctionName(), with the addition of a suffix using the same letters as the extension name's prefix. For example, the NV_fence extension includes the functions glGetFencesNV(), glSetFenceNV(), glTestFenceNV(), and so on. Enumerants An extension may define one or more enumerants. In some extensions, these enumerants are intended for use in the new functions defined by the extension (which may be able to use existing enumerants as well). In other cases, they are intended for use in standard OpenGL functions, thereby adding new options to them. For example, the ARB_texture_env_add extension defines a new enumerant, GL_ADD. This enumerant can be passed as the params parameter of the various glTexEnv() functions when the pname parameter is GL_TEXTURE_ENV_MODE. The new enumerants follow the normal OpenGL naming convention (i.e. GL_WHATEVER), except that they are suffixed by the letters used in the extension name's prefix, such as GL_VERTEX_SOURCE_ATI. Using new enumerants is much simpler than using new functions. Usually, you will just need to include a header defining the enumerant, which you can get from your hardware vendor or from SGI. Alternately, you can define the enumerant yourself if you know the integer value it uses. This value can be obtained from the extension's documentation. Extensions don't need to define both functions and enumerants (though many do), but they usually include at least one of the two. The few cases where that's not true is when existing functions or enumerants are combined in new ways. Dependencies Very few extensions stand completely alone. Some require the presence of other extensions, while others take this a step further and modify or extend the usage of other extensions. When you begin using a new extension, you need to be sure to read the specification and understand the extension's dependencies. Speaking of documentation, you're probably wondering where you can get it, so let's talk about that next. Extension Documentation Although vendors may (and usually do) provide documentation for their extensions in many forms, there is one piece of documentation that is absolutely essential-- the specification. These are generally written as plain text files, and include a broad range of information about the extension, such as its name, version, number, dependencies, new functions and enumerants, issues, and modifications/additions to the OpenGL specification. The specifications are intended for use by developers of OpenGL hardware or ICDs, and as such, are of limited use to game developers. They'll tell you what the extension does, but not why you'd want to use it, or how to use it. For that reason, I'm not going to go over the details of the specification format. If you're interested, Mark Kilgard has written an excellent article about it which you can read at OpenGL.org. [1] As new extensions are released, their specifications are listed in the OpenGL Extension Registry, which you can find at the following URL: http://oss.sgi.com/projects/ogl-sample/registry/ This registry is updated regularly, so it's a great way to keep up with the newest additions to OpenGL. For more detailed descriptions of new extensions, your best bet is the websites of the leading hardware vendors. In particular, NVIDIA [2] and ATI [3] both provide a wealth of information, including white papers, Power Point presentations, and demos. Extensions that are promoted to be a part of the core OpenGL specification may be removed from the extension registry. To obtain information about these, you'll have to refer to the latest OpenGL specification. [4] Using Extensions

Contents   Introduction   OpenGL Extensions   Using Extensions   OpenGL 1.2 and 1.3   Writing Well-Behaved Programs   Demo & Conclusion   Source code   Printable version   Discuss this article