The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

OpenGL ES API Profiles and Versions at a Glance

OpenGL ES 3.X

OpenGL ES 2.X - for Programmable Hardware

For programmable hardware: OpenGL ES 2.0 is defined relative to the
OpenGL 2.0 specification and emphasizes a programmable 3D graphics
pipeline with the ability to create shader and program objects and the
ability to write vertex and fragment shaders in the OpenGL ES Shading
Language. OpenGL ES 2.0 does not support the fixed function
transformation and fragment pipeline of OpenGL ES 1.x.
Learn More...

OpenGL ES 1.X

For fixed function hardware: OpenGL ES 1.1 is defined relative to the
OpenGL 1.5 specification and emphasizes hardware acceleration of the API, but is fully backwards compatible with 1.0. It provides enhanced functionality, improved image quality and optimizations to increase performance while reducing memory bandwidth usage to save power. The OpenGL ES 1.1 Extension Pack is a collection of optional extensions added to OpenGL ES 1.1 that reduced variability and bring significant improvements in image quality and performance. Learn More...

This standard 3D graphics API for embedded systems makes it easy and affordable to offer a variety of advanced 3D graphics and games across all major mobile and embedded platforms. Since OpenGL ES (OpenGL for Embedded Systems) is based on OpenGL, no new technologies are needed. This ensures synergy with, and a migration path to and from desktop OpenGL -- the most widely adopted cross-platform graphics API.

Developer Advantages

Industry Standard and Royalty FreeAnyone can download the OpenGL ES specification and implement and ship products based on OpenGL ES. With broad industry support, OpenGL ES is the only truly open, vendor-neutral, multi-platform embedded graphics standard. The standardized higher level of abstraction that it offers means developers can concentrate more on content and less on the minor code and platform details.

Small footprint & low power consumptionThe embedded space varies widely, ranging from 400Mhz PDAs with 64MB RAM to 50MHz mobile phones with 1 MB RAM. OpenGL ES is designed to accommodate these differences by requiring a minimum footprint with minimum data storage requirements, minimized instruction/data traffic, and is both integer and floating point friendly. For users this means smaller binaries to download that take up less storage on the device.

Seamless transition from software to hardware renderingAlthough the OpenGL ES specification defines a particular graphics processing pipeline, individual calls can be executed on dedicated hardware, run as software routines on the system CPU, or implemented as a combination of both dedicated hardware and software routines. This means that software developers can ship a conformant software 3D engine today, that lets applications and tools seamlessly transition over to using OpenGL ES hardware-acceleration in higher powered devices.

Extensible & EvolvingOpenGL ES allows new hardware innovations to be accessible through the API via the OpenGL extension mechanism and for the API to be easily updated. As extensions become widely accepted, they are considered for inclusion into the core OpenGL ES standard. This process allows OpenGL ES to evolve in a controlled yet innovative manner.

Easy to use
Based on OpenGL, OpenGL ES is well structured with an intuitive design and logical commands.

Well-documentedBecause OpenGL ES is based on OpenGL, there are numerous relevant books, and a great deal of relevant sample code, making information about OpenGL ES inexpensive and easy to find. With the introduction of OpenGL ES, a developer can now write basically the same code for cell phones to supercomputers.

Conformance Testing

Specifications are reviewed and revised on a yearly basis. To label an implementation as an OpenGL ES compliant implementation, the implementation must pass a set of conformance tests. The conformance test definitions are maintained as a separate part of the OpenGL ES documentation.

The OpenGL ES Two Track Roadmap

The OpenGL ES roadmap has been tailored to the diverse needs of the embedded industry and contains two tracks with "1.X" and "2.X" specification roadmaps that will evolve in parallel. The 1.X roadmap will continue to be developed for new-generation fixed function 3D accelerators while the 2.X roadmap will enable emerging programmable 3D pipelines. This dual-track roadmap enables OpenGL ES to meet the graphics requirements of a huge range of 3D enabled device and platforms in embedded markets - from low-end cell-phones to high-end gaming consoles. Khronos is committed to providing backwards compatibility between successive versions of the APIs in each of the 1.X and 2.X tracks to ensure that applications can be trivially ported from one version to the next.

The OpenGL ES Framework

Profiles:
The OpenGL ES specification includes the definition of several profiles. Each profile is a subset of a version of the desktop OpenGL specification plus some additional OpenGL ES-specific extensions. The OpenGL ES profiles are part of a wider family of OpenGL-derived application programming
interfaces. As such, the profiles share a similar processing pipeline, command structure, and the
same OpenGL name space. Where necessary, extensions are created to augment the existing
desktop OpenGL functionality. OpenGL ES-specific extensions play a role in OpenGL ES profiles similar
to that played by OpenGL ARB extensions relative to the OpenGL specification. OpenGL ES-specific
extensions are either precursors of functionality destined for inclusion in future core profile revisions,
or formalization of important but non-mainstream functionality. Each profile definition implies a distinct header file and link/runtime library defining the commands and tokens in the profile. To simplify maintenance a single superset header can be defined with appropriate conditional preprocessing directives to control the visibility of tokens and command prototypes. At run-time an application can determine which profile is running using the OpenGL version string query.

The Common Profile is intended for consumer entertainment and related devices such as telephone handsets, PDAs, set-top boxes, game consoles, etc. It addresses the broadest range of the market including support for platforms with varying capability.

Minimum footprint full function 3D with texture-mapping

Good gaming platform

Implementable on cell phones

The Safety Critical Profile is intended for consumer and industrial applications where reliability and certifiability are the primary constraints.

Absolute minimum 3D to ease safety certifications

Used in avionics and automotive displays

Extensions:
OpenGL ES implementations may include extensions that add new features to the implementation. An OpenGL ES profile consists of two parts: a subset of the full OpenGL pipeline, and some extended
functionality that is drawn from a set of OpenGL ES-specific extensions to the full OpenGL specification.
Each extension is pruned to match the profile's command subset and added to the profile as either a core addition or a profile extension. Core additions differ from profile extensions in that the commands and tokens do not include extension suffixes in their names. Profile extensions are further divided into required (mandatory) and optional extensions. Required extensions
must be implemented as part of a conforming implementation, whereas the implementation of optional extensions is left to the discretion of the implementor.

Native Platform Graphics Interface Layer - EGL:
OpenGL ES also includes a specification of a common platform interface layer, called EGL. This layer is platform independent and may optionally be included as part of a vendor's OpenGL ES distribution. The platform binding also has an associated conformance test. Alternatively, a vendor may choose to define their own platform-specific embedding layer.