''''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.

+

'''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.

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.

Line 7:

Line 7:

== Extension Registry ==

== Extension Registry ==

−

The OpenGL Extension Registry is maintained by the ARB and contains the technical specifications of all known OpenGL extensions.

+

The OpenGL Extension Registry is maintained by the [[OpenGL Architectural Review Board|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 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.

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.

+

+

=== Extension Support ===

+

+

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 [[Get Context Info]].

+

+

== Extensions Loading ==

+

{{main|Load OpenGL Functions}}

+

+

OpenGL extensions must be loaded dynamically at runtime. There are [[Extension Loading Library|many automatic tools]] for loading them.

== Extension Types ==

== Extension Types ==

Line 23:

Line 38:

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.

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.

−

{| border="1" cellpadding="5"

+

{| class = "wikitable"

|-

|-

! Extension Prefix

! Extension Prefix

Line 95:

Line 110:

|-

|-

| GLX_EXT, GLX_ARB, GLX_ATI, GLX_NV

| GLX_EXT, GLX_ARB, GLX_ATI, GLX_NV

−

| Linux platforms.

+

| X-Window-based platforms.

|-

|-

| AGL

| AGL

Line 107:

Line 122:

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.

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.

−

When a proprietary extension becomes an ARB approved core extension, the vendor will rarely &ndash; if ever &ndash; remove it from their extension implementation. This is done to ensure backwards compatibility with software which implements older extensions.

+

In some cases, there are differences between extension and the core function. GLSL's extension version (ARB_shader_objects) was rather different from the core 2.0 functionality.

−

+

−

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 ([http://www.opengl.org/registry/ OpenGL Extension Registry]) are deprecated, make sure deprecated extensions are not used.

+

=== Extension Development ===

=== Extension Development ===

Line 116:

Line 129:

=== Core Extensions ===

=== Core Extensions ===

−

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.

+

OpenGL version 3.0 added a 4th general group of extension: core extensions. Their purpose is to expose core features from higher versions in lower versions, which is particularly useful 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.

+

Core extensions all have the GL_ARB prefix, but their functions and enumerations do not end with 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 the corresponding core functionality.

−

The behavior of core extensions is exactly the same as their core functionality.

+

=== Ubiquitous extensions ===

+

{{main|Ubiquitous Extensions}}

−

== Specific Extension Usage ==

+

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.

−

=== Vertex submission extensions ===

+

== External Links ==

+

* [http://www.opengl.org/registry/ OpenGL Extension Registry]

−

* Please read http://www.opengl.org/wiki/VBO

+

== Extensions of Interest ==

−

* Please read http://www.opengl.org/wiki/VBO_-_more

+

−

=== Texturing related extensions ===

+

If you are new to OpenGL programming, you may find the large list in the [http://www.opengl.org/registry 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.

−

* Please read http://www.opengl.org/wiki/Texture_Combiners

+

=== Common extensions ===

−

* 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

+

−

=== Programmability extensions ===

+

These are available and useful for all versions of OpenGL (assuming the implementation developer still supports the hardware):

−

* Please read http://www.opengl.org/wiki/Shading_languages

+

* [http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt WGL_ARB_extensions_string] (and the WGL extensions you can get with this extension)

** {{extref|texture_sRGB|EXT}} While sRGB textures are core in 3.0+, this extension also [[S3_Texture_Compression#sRGB_and_S3TC|exposes s3tc sRGB formats]]. So you still need to use the extension to access these formats.

+

* [http://www.opengl.org/registry/specs/ARB/debug_output.txt GL_ARB_debug_output]: Only available if you create a debug context.

+

* [http://www.opengl.org/registry/specs/KHR/debug.txt GL_KHR_debug]: replaces ARB_debug_output, and is always available, but it is depending on the implementation how much information, if any, is provided if used with a non-debug context.

−

=== Framebuffer related extensions ===

+

=== Targeting OpenGL 3.3 ===

−

* [[GL_ARB_draw_buffers]] Core in GL 2.0

+

These are useful extensions when targeting GL 3.3. These are either non-hardware extensions introduced after 3.3, or hardware features not exposed by 3.3's API. Most 3.3 hardware will provide these, given recent drivers.

These are useful extensions when targeting GL 2.1 hardware. Note that many of the above extensions are ''also'' available, if the hardware is still being supported. These represent non-hardware extensions introduced after 2.1, or hardware features not exposed by 2.1's API. Most 2.1 hardware that is still being supported by its maker will provide these, given recent drivers.

* GL_EXT_bindable_uniform (similar to [[Uniform Buffer Objects]], but not as cleanly specified.)

+

* GL_EXT_draw_buffers2

+

* GL_EXT_geometry_shader4

+

* GL_EXT_gpu_shader4

+

* GL_EXT_framebuffer_sRGB

+

+

== How to read ==

+

+

Reading an OpenGL extension is somewhat complicated. Extensions have many sections, and these sections have different meanings. Some sections are descriptive while others are normative. A descriptive section does not represent the actual functionality of the extension; it either explains some facet of the extension or offers other useful information. Normative sections are those that actually specify the behavior of the OpenGL graphics system.

+

+

=== Preamble sections ===

+

+

There are a number of sections in an extension that serve as simple introductory material. The ''Name'', ''Name String'', etc. These all have information that's fairly obvious to understand.

+

+

==== Dependencies ====

+

+

The ''Dependencies'' section is a bit more complicated. OpenGL extensions are sort of like .diff files. They specify changes to the OpenGL specification. A .diff file is useless without the file that it is to be applied to. And just as with .diff files, OpenGL extensions are written against a specific version of the OpenGL specification.

+

+

The version that the extension is written against is specified by the "This extension is written against..." text. If the extension extends GLSL, there will be a second version for the GLSL specification.

+

+

Extensions may be written against a particular specification version, but it is possible to implement them that extension on older OpenGL versions. Some extensions can be implemented even on OpenGL 1.1, while others have a higher base version. The minimum version that the extension can appear in is specified with the text, "X are required," where ''X'' is the minimum OpenGL and/or GLSL version required.

+

+

Extensions can also have a number of dependencies on either other extensions or higher version numbers. The idea is pretty simple, in general. If extension X changes its behavior in some way in the presence of extension Y, then extension X has a dependency on extension Y. This is stated with the text "This extension interacts with...". The specific interactions are specified in the main body of the extension.

+

+

The text "This extension interacts trivially with..." means that the interaction is fairly obvious. For example, the ARB_shader_image_load_store extension interacts "trivially" with ARB_tessellation_shader and/or OpenGL 4.0. The interaction is obvious: ignore references to the tessellation shader stages. This is a trivial interaction. Other interactions are not as trivial.

+

+

==== Overview ====

+

+

The ''Overview'' section is the heart of the descriptive text. It provides a plain-text explanation of what the extension does. This is descriptive text, so it is non-binding; the specific functionality is provided elsewhere. But the overview provides a good start in understanding what the extension actually does.

+

+

=== Normative text ===

+

+

The main body of the normative text, the actual text that says how the extension works, is provided after the overview. It is broken down into two basic sections: a list of the new functions/enums, and a list of the spec additions/dependency descriptions. These sections comprise the main body of the extension.

+

+

==== Functions and enumerators ====

+

+

The ''New Procedures and Functions'' section is a list of all of the functions the extension provides, if any. The ''New Tokens'' section is a list of all of the enumerators provided, their values, and what functions accept them, if any.

+

+

==== Additions and Dependencies ====

+

+

After the tokens and functions, there will be several sections titled ''Additions to Chapter X of the...'', where X is some chapter number in the OpenGL specification that the extension is written against. Within each addition section, there is a list of blocks of text, where the original text in the spec is either removed, added, or changed as outlined in the extension.

+

+

Following these can be a section titled ''Errors''. This explains any possible errors rising from functions described or modified in this extension.

+

+

After this is a list of ''Dependencies'' sections. For every dependency listed in the first dependencies section at the beginning of the extension, there will be a block of text explaining how the spec changes in the presence of the extension or OpenGL version.

+

+

=== Footer ===

+

+

After the main body, we have various other descriptive information.

+

+

==== Issues ====

+

+

The ''Issues'' section is a list of design questions that the people working on the extension were asked and answer, informing how the extension came to be. This descriptive info is often handy in getting an idea how an extension works without having to read the specific details. The ''Overview'' can give a general idea of how it works, but the ''Issues'' section can give insight into what the details are.

+

+

{{note|In many older extension specifications, the ''Issues'' section directly followed the ''Overview'' section. Newer ones move ''Issues'' below the main body, because there were a ''lot'' of issues in some extensions.}}

+

+

==== Revision History ====

+

+

The history of revisions of the extension. Most of these happen before it is first published, but some (rarely) happen later.

−

== 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<br>

−

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.<br>

−

<br>

−

GL_ARB_texture_rectangle<br>

−

GL_ARB_color_buffer_float<br>

−

GL_ARB_half_float_pixel<br>

−

GL_ARB_texture_float<br>

−

WGL_EXT_extensions_string (and the WGL extensions you can get with this extension)<br>

GL_GREMEDY_string_marker, GL_GREMEDY_frame_terminator (Special. Available in GLintercept which is a debugging tool)<br>

−

GL_EXT_framebuffer_object<br>

−

GL_EXT_framebuffer_blit<br>

−

GL_EXT_framebuffer_multisample<br>

−

GL_NV_framebuffer_multisample_coverage<br>

−

GL_EXT_timer_query<br>

−

GL_EXT_gpu_program_parameters<br>

−

GL_NV_gpu_program4<br>

−

GL_EXT_geometry_shader4<br>

−

GL_EXT_gpu_shader4<br>

−

GL_EXT_draw_instanced<br>

−

GL_EXT_packed_float<br>

−

GL_EXT_texture_array<br>

−

GL_EXT_texture_buffer_object<br>

−

GL_EXT_texture_compression_latc<br>

−

GL_EXT_texture_compression_rgtc<br>

−

GL_EXT_texture_shared_exponent<br>

−

GL_NV_depth_buffer_float<br>

−

GL_EXT_framebuffer_sRGB<br>

−

WGL_EXT_framebuffer_sRGB<br>

−

GL_NV_parameter_buffer_object<br>

−

GL_EXT_draw_buffers2<br>

−

GL_EXT_bindable_uniform<br>

−

GL_EXT_texture_integer<br>

−

GL_NV_conditional_render<br>

−

GL_EXT_transform_feedback<br>

−

<br>

[[Category:General OpenGL]]

[[Category:General OpenGL]]

Revision as of 19:09, 15 November 2012

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.

Extension Registry

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.

Extension Support

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 Get Context Info.

Extensions Loading

OpenGL extensions must be loaded dynamically at runtime. There are many automatic tools for loading them.

Extension Types

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.

1, Experimental extensions should not be used in a production environment as they are subject to removal from implementation.

ARB Approval

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 cases, there are differences between extension and the core function. GLSL's extension version (ARB_shader_objects) was rather different from the core 2.0 functionality.

Extension Development

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.

Core Extensions

OpenGL version 3.0 added a 4th general group of extension: core extensions. Their purpose is to expose core features from higher versions in lower versions, which is particularly useful if those core features are hardware-based.

Core extensions all have the GL_ARB prefix, but their functions and enumerations do not end with 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 the corresponding core functionality.

Ubiquitous extensions

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.

External Links

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.

Common extensions

These are available and useful for all versions of OpenGL (assuming the implementation developer still supports the hardware):

GL_KHR_debug: replaces ARB_debug_output, and is always available, but it is depending on the implementation how much information, if any, is provided if used with a non-debug context.

Targeting OpenGL 3.3

These are useful extensions when targeting GL 3.3. These are either non-hardware extensions introduced after 3.3, or hardware features not exposed by 3.3's API. Most 3.3 hardware will provide these, given recent drivers.

Targeting OpenGL 2.1

These are useful extensions when targeting GL 2.1 hardware. Note that many of the above extensions are also available, if the hardware is still being supported. These represent non-hardware extensions introduced after 2.1, or hardware features not exposed by 2.1's API. Most 2.1 hardware that is still being supported by its maker will provide these, given recent drivers.

How to read

Reading an OpenGL extension is somewhat complicated. Extensions have many sections, and these sections have different meanings. Some sections are descriptive while others are normative. A descriptive section does not represent the actual functionality of the extension; it either explains some facet of the extension or offers other useful information. Normative sections are those that actually specify the behavior of the OpenGL graphics system.

Preamble sections

There are a number of sections in an extension that serve as simple introductory material. The Name, Name String, etc. These all have information that's fairly obvious to understand.

Dependencies

The Dependencies section is a bit more complicated. OpenGL extensions are sort of like .diff files. They specify changes to the OpenGL specification. A .diff file is useless without the file that it is to be applied to. And just as with .diff files, OpenGL extensions are written against a specific version of the OpenGL specification.

The version that the extension is written against is specified by the "This extension is written against..." text. If the extension extends GLSL, there will be a second version for the GLSL specification.

Extensions may be written against a particular specification version, but it is possible to implement them that extension on older OpenGL versions. Some extensions can be implemented even on OpenGL 1.1, while others have a higher base version. The minimum version that the extension can appear in is specified with the text, "X are required," where X is the minimum OpenGL and/or GLSL version required.

Extensions can also have a number of dependencies on either other extensions or higher version numbers. The idea is pretty simple, in general. If extension X changes its behavior in some way in the presence of extension Y, then extension X has a dependency on extension Y. This is stated with the text "This extension interacts with...". The specific interactions are specified in the main body of the extension.

The text "This extension interacts trivially with..." means that the interaction is fairly obvious. For example, the ARB_shader_image_load_store extension interacts "trivially" with ARB_tessellation_shader and/or OpenGL 4.0. The interaction is obvious: ignore references to the tessellation shader stages. This is a trivial interaction. Other interactions are not as trivial.

Overview

The Overview section is the heart of the descriptive text. It provides a plain-text explanation of what the extension does. This is descriptive text, so it is non-binding; the specific functionality is provided elsewhere. But the overview provides a good start in understanding what the extension actually does.

Normative text

The main body of the normative text, the actual text that says how the extension works, is provided after the overview. It is broken down into two basic sections: a list of the new functions/enums, and a list of the spec additions/dependency descriptions. These sections comprise the main body of the extension.

Functions and enumerators

The New Procedures and Functions section is a list of all of the functions the extension provides, if any. The New Tokens section is a list of all of the enumerators provided, their values, and what functions accept them, if any.

Additions and Dependencies

After the tokens and functions, there will be several sections titled Additions to Chapter X of the..., where X is some chapter number in the OpenGL specification that the extension is written against. Within each addition section, there is a list of blocks of text, where the original text in the spec is either removed, added, or changed as outlined in the extension.

Following these can be a section titled Errors. This explains any possible errors rising from functions described or modified in this extension.

After this is a list of Dependencies sections. For every dependency listed in the first dependencies section at the beginning of the extension, there will be a block of text explaining how the spec changes in the presence of the extension or OpenGL version.

Footer

After the main body, we have various other descriptive information.

Issues

The Issues section is a list of design questions that the people working on the extension were asked and answer, informing how the extension came to be. This descriptive info is often handy in getting an idea how an extension works without having to read the specific details. The Overview can give a general idea of how it works, but the Issues section can give insight into what the details are.

Note: In many older extension specifications, the Issues section directly followed the Overview section. Newer ones move Issues below the main body, because there were a lot of issues in some extensions.

Revision History

The history of revisions of the extension. Most of these happen before it is first published, but some (rarely) happen later.