What’s New in OpenGL ES 3.0

In conjunction with next-generation GPUs, OpenGL ES 3.0 will make a number of new features available to mobile and embedded devices. In terms of functionality, OpenGL ES 3.0 is largely a mobile implementation of the OpenGL 3.3 feature set, with a couple notable features missing and a few additional features plucked from later revisions of OpenGL. In terms of backwards compatibility only OpenGL 4.3 is a complete superset of OpenGL ES 3.0, but for most purposes OpenGL 3.1 is probably the closest desktop OpenGL specification.

On that note, though drawing a comparison to Direct3D isn’t particularly straightforward, since we get asked about it so much we’ll try to answer it. Direct3D of course had a major reachitecting with Direct3D 10 back in 2007, which added a number of features to the API  while giving Microsoft a chance to clean out a great deal of fixed-function legacy cruft. From a major feature perspective OpenGL did not reach parity with Direct3D 10 until OpenGL 3.2, which among other things introduced geometry shader support.

So if we had to place OpenGL ES 3.0 along a Direct3D continuum, as it’s primarily based on OpenGL 3.1, it would be somewhere between Direct3D feature level 9_3 and feature level 10_0, again primarily due to a lack of geometry shaders. Consequently, this is why some mobile GPUs like Adreno 320 can support OpenGL ES 3.0, but not D3D feature level 10_0. If you only implement the baseline OpenGL ES 3.0 feature set, then it won’t be enough for D3D 10_0 compliance.

Strictly Defined Pixel/Uniform/Frame Buffer Objects

The first major addition to OpenGL ES 3.0 is support for a number of buffer formats, alongside a general tightening up of the buffer format specifications. OpenGL ES 2.0’s buffer format specification had some ambiguity, which lead to GPU vendors sometimes implementing the same buffer format in slightly different ways, which in turn could lead to problems for developers.

OpenGL ES 3.0 also adds support for Uniform Buffer Objects, which is a useful and efficient data buffer type for use with shaders.

GLSL ES 3.0

As is common with most OpenGL releases, OpenGL ES 3.0 includes a new version of the GL ES Shading Langauge, used to program shader effects. The primary addition for GLSL ES 3.0 is full support for 32bit integer and 32bit floating point (i.e. full precision) data types and operations.  Previously only lower precisions were supported, which are easier to compute (it takes less hardware and less memory), but as shader complexity increases the relatively large precision errors become even larger.

GLSL ES 3.0 has also seen some syntax and feature tweaks to make it more like desktop OpenGL. This doesn’t change the fact that only OpenGL 4.3 is a complete superset of OpenGL ES 3.0, but it makes it easier for developers used to desktop GLSL to work on GLSL ES and vice versa.

Occlusion Queries and Geometry Instancing

While OpenGL ES 3.0 doesn’t get geometry shaders, it does get several features to help with geometry in general. Chief among these are the addition of occlusion queries and geometry instancing. Occlusion queries allows for fast hardware testing of whether an object’s pixels are blocking (occluding) another object, which is helpful for quickly figuring out whether something can be skipped because it’s occluded. Meanwhile geometry instancing allows the hardware to draw the same object multiple times while only requiring the complete object to be submitted to the rendering pipeline once. This makes trees and other common objects easier for the CPU to set up as it doesn’t need to keep resubmitting the entire object in different locations.

Numerous Texture Features

OpenGL ES 3.0 adds support for a number of texture features; in fact it’s far too many to break down. The big additions are support for floating point textures (to go with the aforementioned FP32 support), 3D textures, depth textures, non-power-of-two textures, and 1 & 2 channel textures (R & R/G).

Multiple Render Targets

Multiple Render Target support allows the GPU to render to multiple textures at once. Simply put, the significance of this feature is that it’s necessary for practical real-time deferred rendering.

MSAA Render To Texture

When rendering to a texture, special consideration must be taken for anti-aliasing, which on earlier hardware generations is only available when run against the framebuffer. OpenGL ES 3.0 will add support for MSAA’d rendering to a texture.

Standardized Texture Compression Format: ETC

Wrapping up our look at OpenGL ES 3.0’s features, we have texture compression. One of the big problems for OpenGL for a number of years was that it didn’t have a standardized texture compression format. In the desktop space the earliest and most common texture compression format is S3TC, which is not available royalty-free, and as such cannot be a part of the core standard (instead only available as an extension). This is a problem that carried over to OpenGL ES, which led to vendors implementing their own incompatible texture compression standards. Among the major OpenGL ES GPUs, S3TC, PVRTC, ETC, and ATITC are the most common texture compression formats.

Because there isn’t a standard texture compression format in OpenGL ES 2.0, developers have to pack their textures multiple times for different hardware, which takes up time and more importantly space. This is a particular problem for Android developers since the platform supports multiple GPUs (versus the PowerVR-only iOS).

For OpenGL ES 3.0, Ericsson has offered up their ETC family of texture compression algorithms on a royalty free basis, allowing Khronos to implement a standard texture compression format and thereby over time resolving the issue of having multiple texture compression formats. Compared to where Khronos eventually wants to go ETC is somewhat dated at this point in time – it only offers 6:1 compression for RGB and 4:1 compression for RGBA – but it will get the job done for now.

For Khronos this is a huge breakthrough since texture compression is even more important on mobile devices than it is desktops, due to the much tighter memory bandwidth requirements. This also allows Khronos to evangelize texture compression to developers who had previously been shying away from using texture compression because of the aforementioned issues.

At the same time it will be interesting to see how developers adopt ETC. Just because it’s a standard doesn’t mean it has to be used, and while we can’t imagine Android developers not using it once OpenGL ES 3.0 is the baseline for applications, Apple bears keeping an eye on. As a PowerVR-only shop they have used PVRTC since day one, and so long as they don’t change to another brand of GPUs they wouldn’t need to actually back ETC.

Of course ETC isn’t the only texture compression format in the pipeline. Khronos is also working on the very interesting ASTC, which we’ll get to in a bit.

Introduction OpenGL 4.3 Specification Also Released
POST A COMMENT

46 Comments

View All Comments

  • Wreckage - Monday, August 06, 2012 - link

    Hopefully OpenGL can return to prominence again. There needs to be competition against the closed proprietary DirectX, which has stagnated lately.

    Valve's move to Linux and the rise of Android as a gaming platform should provide additional support for more games to use alternatives to DirectX.
    Reply
  • Flunk - Monday, August 06, 2012 - link

    You forgot Macs, those things are pretty hot right now too. Blizzard has made a load of cash off the Mac versions of their popular games. Reply
  • KoolAidMan1 - Tuesday, August 07, 2012 - link

    And iOS, arguably the fastest growing segment in the gaming market right now.

    There is TONS using OpenGL right now, hopefully it keeps improving thanks to its resurgence.
    Reply
  • bobvodka - Tuesday, August 07, 2012 - link

    OpenGL|ES is not OpenGL, they are two seperate specs - iOS and Android can grow all they like, they still aren't using OpenGL. Reply
  • djgandy - Monday, August 06, 2012 - link

    Please explain how DX has stagnated? Reply
  • nevertell - Monday, August 06, 2012 - link

    Well, tessellation was supported by OpenGL years before DX11 was released. Reply
  • B3an - Monday, August 06, 2012 - link

    Even John Carmack admitted recently at the Quakecon 2012 event that DirectX is now overall better than OpenGL, and Carmack has always used OpenGL. So i dont think Microsoft have anything to worry about.

    With DX11.1 Microsoft have also rewritten and optimised much of it for better performance, efficiency and mobile GPU support. So MS now basically have a single fully featured API for both desktop and mobile GPU's that can do everything. DX11.1 also introduced Target Independent Rasterization which i don't think OpenGL has.
    Reply
  • PrinceGaz - Monday, August 06, 2012 - link

    The problem with DirectX is it is not royalty-free and supported across all platforms. The days of game development being led by Windows PCs is over; it is now all about convergence and supporting as many target markets as possible from mobile-phones (Android, iOS mainly at the moment) as well as game consoles, plus PCs and Macs as well with one common language.

    It will mean compromises at the high-end, but graphics are so good these days it hardly matters. We want better games, not better graphics, so the less developers need to worry about the graphics and the more time they can spend on making a good game which will run on a wide range of devices, the better in my opinion.
    Reply
  • inighthawki - Monday, August 06, 2012 - link

    Since when has DirectX not been royalty free? Reply
  • Ryan Smith - Monday, August 06, 2012 - link

    I'd have to double-check, but since at least DX6, when Microsoft included S3TC as part of the standard. You can't be DX compliant without S3TC, and you have to pay to license S3TC. Reply

Log in

Don't have an account? Sign up now