facebook rss twitter

OpenGL 4.3, OpenGL ES 3.0 and ASTC Compression

by Alistair Lowe on 7 August 2012, 11:45

Tags: Khronos Group, ARM

Quick Link: HEXUS.net/qabkmf

Add to My Vault: x

When we spoke of Steam for Linux yesterday, many of our readers were wondering just how competitive OpenGL is these days when compared against Direct3D. This can be quite the tricky question as, when it came to Direct3D 9 and 10, the two standards were pretty-much aligned, with the only major differences forming around the general structure of the API and not its functionality. OpenGL often lagged behind Direct3D, however was capable of utilising extensions to provide missing functionality in the meantime.

As for performance, this primarily comes down to the individual driver implementations of GPU makers, which in NVIDIA's case, we've seen it's possible to achieve OpenGL performance in-line with and, even superior to that, of Direct3D, once the firm had enough incentive to optimise its drivers and remove pesky bugs. Direct3D 11 was a tricky one, however, with Microsoft adding significant new functionality, providing two new shader stages; the Hull Shader and the Domain Shader, along with offering an optional graphics-oriented Compute Shader for more flexible workloads.

This much functionality was a lot for OpenGL standards organisation, the Khronos Group, to integrate and, there were some differences in philosophy when it came to compute. Khronos wished to push OpenCL, a full ANSI-C compliant compute standard, which offered far greater flexibility, at the cost of increased implementation complexity and overheads due to its weaker pairing with the graphics pipeline; meanwhile, Microsoft offered an integrated shader stage, with a small subset of commands. This difference meant that for the past three years, OpenGL has been playing catch-up, with an easy-to-use compute shader stage out-of-reach for game developers.

OpenGL 4.3 CS

This is all about to change, however, as the Khronos Group has just ratified OpenGL 4.3, which brings closely paired compute shading to the graphics party and, with this release, OpenGL has essentially realigned itself with the Direct3D standard; what can be achieved in Direct3D 11 can be achieved in OpenGL 4.3. It's worth noting that, like Direct3D 11, compute shaders in OpenGL 4.3 are a subset of shader commands, as opposed to a full ANSI-C implementation like OpenCL.

Supporting the new Compute Shader, all other shader stages have been granted the ability to directly access large buffers, allowing for the easier passing of data between the two shaders. Texture 'Views' have also been added to the spec, allowing texture fetch results to be interpreted in different formats without needing to duplicate the original texture.

What's more, OpenGL 4.3 has been designed to align with newly announced OpenGL ES 3.0 standard, meaning that, unlike OpenGL ES 2.0, which took several years for desktop integration, code written for OpenGL ES 3.0 will be directly portable to the desktop from day one, allowing developers of mobile and console games to port code to the PC with far less effort. Even compression formats have been standardised across the two specs, further improving portability.

OpenGL ES 3.0 example

This brings us onto the newly ratified OpenGL ES 3.0 standard, which essentially looks to bring appropriate functionality from OpenGL 3.0 and 4.0 into the mobile standard. Features that can now be found in the mobile spec include; occlusion queries, geometry instancing, support for a wider range of texture formats - including floating-point, multiple render targets, MSAA-friendly render-to-texture and, most importantly, new texture compression format standardisations.

Whilst it's nice to see all this extra functionality in the mobile standard, the real point of interest is in texture compression standardisation. Despite being well established, the S3TC texture format is not free to licence and so, currently there are many texture compression formats in the mobile segment, each attached to specific mobile GPUs. This places a heavy burden on developers to repackage textures and boosts the size of games on App Stores. OpenGL ES 3.0 now makes support for Ericsson's free-to-use ETC texture compression mandatory, which offers 6:1 and 4:1 RGB and RGBA compression respectively, essentially providing one compression format for all.

Taking matters a step further, the Khronos group also hopes to add NVIDIA and ARM co-developed ASTC compression to future standards, with the format currently available as an extension. ASTC, Adaptive Scalable Texture Compression, is a royalty-free standard that offers greater performance than S3TC (more quality at the same compression ratio - thanks to ARM technology), along with incredible scalability, with compression ratios ranging from 4:1 right up to 36:1, with fine-grain control of the texture block-size. The standard is also capable of supporting normal maps and other formats with unique requirements. In essence, ASTC has the potential to become the new de facto compression standard across both OpenGL and OpenGL ES, with it possibly seeing adoption in future Direct3D standards, unless Microsoft finds itself something better in the meantime.

So jumping back to our readers' earlier talks on OpenGL vs DirectX, we're now seeing OpenGL 4.3 on-par with DirectX 11 when it comes to functionality. With increased use of much of the subset in the mobile segment and with a Steam port to Linux, driver performance is starting to shape-up. We're even seeing the Khronos group trail-blaze with ASTC compression. In conclusion, the future for OpenGL is looking promising and right now, the standard is in a strong position to compete with DirectX.

HEXUS Forums :: 5 Comments

Login with Forum Account

Don't have an account? Register today!
ASTC, not to be confused with ATSC, the american digital broadcast standard. Yikes.
Kudos to Alistair! Comprehensibly written and with just about right amount of comments. What didn't go amiss is it's also a rather good news for us SW developers. I must admit I wasn't following much where OpenGL was going (I was rather busy adopting OpenCL lately), but it looks like I'll be able to port most OpenGL apps directly to 4.3 and start using advantages it brings without much fiddling with library incompatibilities. Once it works it's a lot easier to adopt parts of the code to new and faster routines 4.3 brings to the table, rather than wonder what all changed and for what purpose even before first private builds. Better portability is a nice boon too :)
Opengl needs some work still so that gaming can evolve on Linux!
Opengl needs some work still so that gaming can evolve on Linux!

Worry not, for Valve is seemingly working on that very issue!
Worry not, for Valve is seemingly working on that very issue!

And not a moment too soon!