Efficient vendor-supplied implementations of OpenGL (making use of graphics acceleration hardware to a greater or lesser extent) exist for Mac OS, Microsoft Windows, Linux and many Unix platforms. Various software implementations exist, bringing OpenGL to a variety of platforms that do not have vendor support. Notably, the free software/open source library Mesa 3D is a fully software-based graphics API which is code-compatible with OpenGL. However to avoid licensing costs associated with formally calling itself an OpenGL implementation, it claims merely to be a "very similar" API. On some platforms, notably mobile phones, handhelds and game consoles, a reduced API OpenGL ES is often used.
The OpenGL specification was revised by OpenGL Architecture Review Board (ARB) founded in 1992. The ARB was formed by a set of companies interested in the creation of a consistent and widely available API. Microsoft, one of the founding members, left the project in 2003.
On 21 September 2006, control of OpenGL passed to the Khronos Group. This was done in order to improve the marketing of OpenGL, and to remove barriers between the development of OpenGL and OpenGL ES. The subgroup of Khronos that manages OpenGL was called the OpenGL ARB Working Group, for historical reasons. There is a list of members which make up the OpenGL ARB Working Group at section Members of Khronos Group. OpenGL is a general purpose API with lots of different possibilities because of the great number of companies with different interests which have made up the old ARB as well the current group.
Mark Segal and Kurt Akeley authored the original OpenGL specification. Chris Frazier edited version 1.1. Jon Leech edited versions 1.2 through the present version 3.0. Jon Leech has retired as secretary of the old ARB, and Barthold Lichtenbelt has taken his place as Khronos OpenGL ARB Steering Group Chair .
OpenGL's basic operation is to accept primitives such as points, lines and polygons, and convert them into pixels. This is done by a graphics pipeline known as the OpenGL state machine Most OpenGL commands either issue primitives to the graphics pipeline, or configure how the pipeline processes these primitives. Prior to the introduction of OpenGL 2.0, each stage of the pipeline performed a fixed function and was configurable only within tight limits. OpenGL 2.0 offers several stages that are fully programmable using GLSL.
OpenGL is a low-level, procedural API, requiring the programmer to dictate the exact steps required to render a scene. This contrasts with descriptive (aka scene graph or retained mode) APIs, where a programmer only needs to describe a scene and can let the library manage the details of rendering it. OpenGL's low-level design requires programmers to have a good knowledge of the graphics pipeline, but also gives a certain amount of freedom to implement novel rendering algorithms.
OpenGL has historically been influential on the development of 3D accelerators, promoting a base level of functionality that is now common in consumer-level hardware:
A brief description of the process in the graphics pipeline could be:
Many modern 3D accelerators provide functionality far above this baseline, but these new features are generally enhancements of this basic pipeline rather than radical revisions of it.
Then, for OpenGL 2.0 and beyond:
glCombinerParameterfvNV()and their constant
It may happen that more than one vendor agrees to implement the same extended functionality. In that case, the abbreviation EXT is used. It may further happen that the Architecture Review Board "blesses" the extension. It then becomes known as a standard extension, and the abbreviation ARB is used. The first ARB extension was
GL_ARB_multitexture, introduced in version 1.2.1. Following the official extension promotion path, multitexturing is no longer an optionally implemented ARB extension, but has been a part of the OpenGL core API since version 1.3.
Before using an extension a program must first determine its availability, and then obtain pointers to any new functions the extension defines. The mechanism for doing this is platform-specific and libraries such as GLEW and GLEE exist to simplify the process.
Specifications for nearly all extensions can be found at the official extension registry.
In addition to the aforementioned simple libraries, other higher level object oriented scene graph retained mode libraries exist such as PLIB, OpenSG, OpenSceneGraph, and OpenGL Performer. These are available as cross platform free/open source or proprietary programming interfaces written on top of OpenGL and systems libraries to enable the creation of real-time visual simulation applications. Other solutions support parallel OpenGL programs for Virtual Reality, scalability or graphics clusters usage, either transparently like Chromium or through a programming interface like Equalizer
Mesa 3D is a free/open source implementation of OpenGL. It supports pure software rendering as well as providing hardware acceleration for several 3D graphics cards under Linux. As of June 22 2007 it implements the 2.1 standard, and provides some of its own extensions for some platforms.
For more information on OpenGL Language bindings, see opengl.org's Wiki
Additionally, GLUT, SDL and the GLFW libraries provide functionality for basic windowing using OpenGL, in a portable manner. More some opensource crossplatform toolkit like GTK+, QT and WxWidgets, include a widget to embed OpenGL contents.
By the early 1990s, Silicon Graphics (SGI) was a leader in 3D graphics for workstations. Their IRIS GL API was considered the state of the art and became the de facto industry standard, overshadowing the open standards-based PHIGS. This was because IRIS GL was considered easier to use, and because it supported immediate mode rendering. By contrast, PHIGS was considered difficult to use and outdated in terms of functionality.
SGI's competitors (including Sun Microsystems, Hewlett-Packard and IBM) were also able to bring to market 3D hardware, supported by extensions made to the PHIGS standard. This in turn caused SGI market share to weaken as more 3D graphics hardware suppliers entered the market. In an effort to influence the market, SGI decided to turn the IrisGL API into an open standard.
SGI considered that the IrisGL API itself wasn't suitable for opening due to licensing and patent issues. Also, the IrisGL had API functions that were not relevant to 3D graphics. For example, it included a windowing, keyboard and mouse API, in part because it was developed before the X Window System and Sun's NeWS systems were developed.
In addition, SGI had a large number of software customers; by changing to the OpenGL API they planned to keep their customers locked onto SGI (and IBM) hardware for a few years while market support for OpenGL matured. Meanwhile, SGI would continue to try to maintain their customers tied to SGI hardware by developing the advanced and proprietary Iris Inventor and Iris Performer programming APIs.
As a result, SGI released the OpenGL standard.
The OpenGL standardised access to hardware, and pushed the development responsibility of hardware interface programs, sometimes called device drivers, to hardware manufacturers and delegated windowing functions to the underlying operating system. With so many different kinds of graphic hardware, getting them all to speak the same language in this way had a remarkable impact by giving software developers a higher level platform for 3D-software development.
In 1992, SGI led the creation of the OpenGL architectural review board (OpenGL ARB), the group of companies that would maintain and expand the OpenGL specification for years to come. OpenGL evolved from (and is very similar in style to) SGI's earlier 3D interface, IrisGL. One of the restrictions of IrisGL was that it only provided access to features supported by the underlying hardware. If the graphics hardware did not support a feature, then the application could not use it. OpenGL overcame this problem by providing support in software for features unsupported by hardware, allowing applications to use advanced graphics on relatively low-powered systems.
In 1994 SGI played with the idea of releasing something called "OpenGL++" which included elements such as a scene-graph API (presumably based around their Performer technology). The specification was circulated among a few interested parties – but never turned into a product.
Microsoft released Direct3D in 1995, which would become the main competitor of OpenGL. On 17 December, 1997, Microsoft and SGI initiated the Fahrenheit project, which was a joint effort with the goal of unifying the OpenGL and Direct3D interfaces (and adding a scene-graph API too). In 1998 Hewlett-Packard joined the project. It initially showed some promise of bringing order to the world of interactive 3D computer graphics APIs, but on account of financial constraints at SGI, strategic reasons at Microsoft, and general lack of industry support, it was abandoned in 1999.
The design of GLSL was notable for making relatively few concessions to the limitations of the hardware then available; this hearkened back to the earlier tradition of OpenGL setting an ambitious, forward-looking target for 3D accelerators rather than merely tracking the state of currently available hardware. The final OpenGL 2.0 specification includes support for GLSL.
Full use of OpenGL 3.0 is only available on DirectX 10 level hardware
The draft introduced a change to object management. The GL 2.1 object model was built upon the state-based design of OpenGL. That is, in order to modify an object or to use it, one needs to bind the object to the state system, then make modifications to the state or perform function calls that use the bound object.
Because of OpenGL's use of a state system, objects must be mutable. That is, the basic structure of an object can change at any time, even if the rendering pipeline is asynchronously using that object. A texture object can be redefined from 2D to 3D. This requires any OpenGL implementations to add a degree of complexity to internal object management.
Under the Longs Peak API object creation would become atomic, using templates to define the properties of an object which would be created with a single function call. The object could then be used immediately across multiple threads. Objects would also be immutable; however, they could have their contents changed and updated. For example, a texture could change its image, but its size and format could not be changed.
To support backwards compatibility the old state based API would still be available, but no new functionality would be exposed via the old API in later versions of OpenGL. This would have allowed legacy code bases, such as the majority of CAD products, to continue to run while other software could be written against or ported to the new API.
Longs Peak was initially due to be finalized in September 2007 under the name OpenGL 3.0, but the Khronos group announced October 30 that it had run into several issues that it wished to address before releasing the specification. As a result the spec was delayed, and the Khronos group went into a media blackout until the release of the final OpenGL 3.0 spec.
The final specification proved far less revolutionary than the Longs Peak proposal. Instead of removing all immediate mode and fixed functionality (non-shader mode), the spec included them as deprecated features. The proposed object model was not included, and no plans have been announced to include it in any future revisions. As a result the API remained largely the same with a few existing extensions being promoted to core functionality.
Amongst some developer groups this decision caused something of an uproar , with many developers professing that they would switch to DirectX in protest. Most complaints revolved around the lack of communication by Khronos to the development community and multiple features being discarded that were viewed favorably by many. Other frustrations included the requirement of DirectX 10 level hardware in order to use OpenGL 3.0 and the absence of geometry shaders and instanced rendering as a core features.
Other sources reported that the community reaction wasn't quite as severe as originally presented , with many vendors showing support for the update.
Prior to the release of OpenGL 3.0 plans were discussed to add more functionality to OpenGL beyond 3.0. However, since much of this discussion took place in the context of a redesigned API, and some of the features planned for the future releases are already in the final 3.0 spec, it is presently unclear what role (if any) the planned extensions will play moving forward.
This revision, which was due to be released 2-3 months after 3.0, would have entailed adding smaller features to 3.0 that could not be added in the timeframe for its release. It was mostly ease-of-use features to make the API more convenient to use, in addition to a few features for performance purposes.
This revision, which was due to be released 3-5 months after 3.0, would bring OpenGL 3.0 up-to-date with more modern hardware features. These included geometry shaders, integers in shaders, texture arrays, and instanced rendering. However, it is worth noting that both the use of integers in shaders and texture arrays are already part of the final 3.0 spec.
Some notable games that include an OpenGL renderer:
Some notable opensource crossplatform applications that include an OpenGL renderer:
Some notable applications that include an OpenGL renderer:
All can incorporate OpenGL 3D object. Cairo can use OpenGL as backend.