Khronos Announces OpenGL ES 3.0, OpenGL 4.3, ASTC Texture Compression, & CLU
by Ryan Smith on August 6, 2012 9:00 AM ESTAdaptive Scalable Texture Compression
As we’ve noted in our rundowns of OpenGL and OpenGL ES, the inclusion of ETC texture compression support as part of the core OpenGL standards has finally given OpenGL a standard texture compression format after a number of years. At the same time however, the ETC format itself is approaching several years old, and not unlike S3TC it’s only designed for a limited number of cases. So while Khronos has ETC right now, in the future they want better texture compression and are now taking the first steps to make that happen.
The reward at the end of that quest is Adaptive Scalable Texture Compression (ASTC), a new texture compression format first introduced by ARM in late in 2011. ASTC was the winning proposal in Khronos's search for a next-generation texture compression format, with the ARM/AMD bloc beating out NVIDIA and their ZIL proposal.
As the winning proposal in that search, if all goes according to plan ASTC will eventually become OpenGL and OpenGL ES’s mandatory next generation texture compression algorithm. In the meantime Khronos is introducing it as an optional feature of OpenGL ES 3.0 and OpenGL 4.3 in order to solicit feedback from hardware and software developers. Only once all parties are satisfied with ASTC to the point that it’s ready to be implemented into hardware can it meaningfully be moved into the core OpenGL specifications.
So what makes ASTC next-generation anyhow? Since the introduction of S3TC in the 90s, various parties have been attempting to improve on texture compression with limited results. In the Direct3D world where S3TC is standard, we’ve seen Microsoft add specialized formats for normal maps and other texture types that are not color maps, but only relatively recently did they add another color map compression method with BC7. BC7 in turn is a high quality but lower compression ratio algorithm that solves the gradient issues S3TC faces, but for a 24bit RGB texture it’s only a 3:1 compression ratio versus 6:1 for S3TC (32bit RGBA fares better; both are 4:1).
ASTC Image Quality Comparison: Original, 4x4 (8bpp), 6x6 (3.56bpp), & 8x8 (2bpp) block size
Meanwhile in the mobile space we’ve seen the industry’s respective GPU manufacturers create their own texture compression formats to get around the fact that S3TC is not royalty free (and as such can’t be included in OpenGL). And while Imagination Technologies in particular has an interesting method in PVRTC that unlike the other formats is not block based – and thereby can offer a 2bpp (16:1) compression ratio – it has its own pros and cons. Then of course there’s the matter trying to convince holders of these compression methods to freely license them for inclusion in OpenGL, when S3/VIA has over the years made a tidy profit off of S3TC’s inclusion in Direct3D.
The end result is that the industry is ripe for a royalty free next generation texture compression format, and ARM + NVIDIA intend to deliver on that with the backing of Khronos.
While ASTC is another block based texture compression format, it does have some very interesting functionality that pushes it beyond S3TC or any other previous texture compression format. ASTC’s primary trick is that unlike other block based texture compression formats, it is not based around a fixed size 4x4 texel block. Rather ASTC has a fixed size of 128bits (16 bytes) with a variable size block ranging from 4x4 to 12x12, in effect offering RGBA compression ratios from 8bpp (4:1) all the way up to an incredible 0.89bpp (36:1). The larger block size not only allows for higher compression ratios, but it also offers developers a much finer grained range of compression ratios to work with compared to previous texture compression formats.
| Block Size | Bits Per Px | Comp. Ratio |
| 4x4 | 8.00 | 4:1 |
| 5x4 | 6.40 | 5:1 |
| 5x5 | 5.12 | 6.25:1 |
| 6x5 | 4.27 | 7.5:1 |
| 6x6 | 3.56 | 9:1 |
| 8x5 | 3.20 | 10:1 |
| 8x6 | 2.67 | 12:1 |
| 10x5 | 2.56 | 12.5:1 |
| 10x6 | 2.13 | 15:1 |
| 8x8 | 2.00 | 16:1 |
| 10x8 | 1.60 | 20:1 |
| 10x10 | 1.28 | 25:1 |
| 12x10 | 1.07 | 30:1 |
| 12x12 | 0.89 | 36:1 |
Alongside a wide range of compression ratios for traditional color maps, ASTC would also support additional types of textures. With support for normal maps ASTC would also replace other texture compression formats as the preferred format for normal maps, and it would also be the first texture compression format with support for 3D textures. Even HDR textures are on the table, though for the time being Khronos is starting with only support for regular (LDR) textures. With any luck, ASTC will become the all-uses texture compression format for OpenGL.
As you can imagine, Khronos is rather excited about the potential for ASTC. With their strong position in the mobile graphics space they need to provide paths to improving mobile graphics quality and performance amidst the reality of Moore’s Law and the other realities of SoC manufacturing. Specifically, mobile GPU bandwidth isn’t expected to grow by leaps and bounds like shading performance, meaning Khronos and its members need to do more with what amounts to less memory bandwidth. For Khronos texture compression is key, as ASTC will allow developers to pack in smaller textures and/or improve their texture quality without using larger textures, thereby making the most of the limited memory bandwidth available.
Of course the desktop world also stands to benefit. ARM’s objective PSNR data for ASTC has it performing far better than S3TC at the same compression ratio, which would bring higher quality texture compression to the desktop at the same texture size. And since ASTC is being developed by Khronos members and released royalty free, at this point there’s no reason to believe that Direct3D couldn’t adopt it in the future, especially since all major Direct3D GPUs also support OpenGL in the first place, so the requisite hardware would already be in place.
With all of that said, there’s still quite a bit of a distance to go between where ASTC is at today and where Khronos would like it to end up. For the time being ASTC needs to prove itself as an optional extension, so that GPU vendors are willing to implement it in hardware. It’s only after it becomes a hardware feature that ASTC can be widely adopted by developers.
Facebook
Twitter
RSS
46 Comments
View All Comments
BenchPress - Monday, August 6, 2012 - link
S3TC support is not demanded. You can query which formats are supported, and trying to create unsupported ones will fail.Of course texture compression is important so the major hardware manufacturers implemented it and pay for it. But this is equally true for OpenGL. They all implement the extension.
Core Direct3D functionality is royalty free, just like OpenGL. After all, they are just APIs.
mczak - Monday, August 6, 2012 - link
That isn't quite true for DX10 and up. There's very few optional formats, almost everything is mandatory (including the s3tc formats).That said, IIRC hw manufacturers did NOT have to pay s3tc license fees due to some licensing deal of MS (if they implemented s3tc for d3d, they still had to pay for OGL).
StevoLincolnite - Monday, August 6, 2012 - link
Direct X is also used on the Xbox 360 which is a games console, the PS3 even has Direct X 9 hardware, albeit without the API. (It uses OpenGL)Android, iOS and other mobile OS's can't play AAA games like a PC or Console can, in-fact most games are incredibly simple with decade old level of graphics.
Steam has what, 30-40 million users? Origin is picking up steam (Pun intended), Ubisoft uPlay probably has a few users.
So lets go with 40 million PC gamers (Which is probably lower than the true number.) which in turn use Direct X.
Then add on the Xbox console numbers which makes it 110 million gamers that use Direct X in one form of another.
Suddenly Direct X doesn't look insignificant.
If you go back almost a couple decades during the Era of 3dfx, Allot of games actually used multiple API's that you could choose depending on your hardware.
I remember Unreal Tournament for instance coming with 3dfx Glide, OpenGL, Software Rendering and Direct 3D, so it's not like you can't support multiple API's in a game engine using some wrappers, which may be the path developers may take in the future again.
BiggieShady - Monday, August 6, 2012 - link
Saying things like "PS3 has DX9 hardware but it uses OpenGL" is wrong on so many levels. DirectX and OpenGL are API-s designed to work with different types of hardware with one thing in common - they expose the same hardware functionality. So PS3 and Xbox have different GPU-s that both expose same functionality either for OpenGL or DirectX.wicketr - Monday, August 6, 2012 - link
There are over 500 Million Mac/Linux/Smartphone/Tablet users that DirectX isn't on. Meaning that a developer using DirectX would miss out on those users.....Or they could use OpenGL and cover 100% of the user base. Currently, it'd be asinine to develop a mobile only game in DirectX, because they'd only reach about 5% of the market.
The question on the desktop is if DirectX's feature set is THAT much better than OpenGL to warrant it's use. As OpenGL catches up in parity and as more users abandon Windows, the reasoning for using DirectX gets smaller and smaller, especially as developers get more and more comfortable in OpenGL (due to mobile programming).
The only way DirectX can really survive over the long term (10+ years out), is if Microsoft develops engines compatible for iPhone and Android. Those ecosystems are just WAY to large for Microsoft to use their proprietary engine to push users (and developers) to MS Phones.
bobvodka - Monday, August 6, 2012 - link
DX will survive as long as there is a Windows or XBox market for it to survive in.Beyond that developers, like myself, will do what we've always done and use the best API for the target platform.
Amusingly the only people who really seem to care about which API 'wins' are OS Zealots who want their OS to dominate the world... which, you know, works so well...
The rest of us doing the real work day in-day out will just use the best tools for the job and won't care who they come from.
Unfortunately, right now, the ARB doesn't have a track record of 'the best tools' having dropped the ball with the Longs Peak/OGL3.0 debarcle which was, at the time, OpenGL's best chance of 'making a come back' on Windows (this was around the time of Vista/DX10 and the wailing of XP gamers who wanted DX10 features in their games) - when it comes to OpenGL I wouldn't trust the ARB to find their own arses if handed a map.
Now, OpenGL|ES is another matter, they have handle that well and its a good thing BUT OpenGL|ES is NOT OpenGL (yay marketing!); you do not program these APIs the same way and doing so is going to hurt you which brings us back around to 'the right tools for the job'.
OpenGL is not, for the majority of the home computer market, the right tool yet.
ananduser - Tuesday, August 7, 2012 - link
The user to which you replied presented some vague numbers representing dedicated gamers and not the install base. You counter that with the totality of non-Win devices ?You seem bent on people "abandoning" Windows like it's the plague and it's the right thing to do. You also seem to go to sleep at night wishing DirectX was dead so that EA would develop BF4 for your mac(I presume).
DX will still be the dominant gaming industry API even 10 years out. Even more so than today.
SleepyFE - Monday, August 6, 2012 - link
DirectX is being used because people think like you (and so far it was better). Most people use Windows so why not use DirectX. NOW you have 110 mill gamers using DirectX because developers used it. If they decided to use OpenGL which also works on Windows and Xbox you would have 110 mill gamers using OpenGL and a few million using DirectX because Microsoft was the developer's partner and they forced them to use it.So far using OpenGL was a problem since it had less features and was harder to learn (deep end of the pool). Now is the time to make the switch.
Also, i do not use Windows because i like it, i like the games that are made for it. If i want to play a game, i am FORCED to have Windows because of DirectX only running on Windows. Using OpenGL does not yet mean it will run everywhere, but it does mean a lot less work to get it working elsewhere. Right now so many people are on Windows that developing the game in both DirectX and OpenGL just doesn't pay. Using only one is the way to go. An OpenGL title right now has a slightly wider audience (a very very very very small increase). But if they keep using DirectX we have to keep using Windows (even if we don't like it).
Games are the reason most of us use Windows, but with good OpanGL that might change. Ouya is a gaming console with Android and as phones become more and more powerful we might only need a phone some day. A phone with a super fast USB 5.0 that is plugged in to a monitor with more USB ports for a keyboard, mouse, controller... And that phone will probably have Android on it. And to play games you will need OpanGL. At that point it would be good to have a huge selection of games (even if they are old and outdated, nostalgia never goes out of fashion).
bobvodka - Monday, August 6, 2012 - link
The PS3 does not use OpenGL.There is a PSGL implimentation but no one who wants any speed out of the thing uses it; GCM is the PS3 API of choice.
Linux and OSX are the only OSes which use OpenGL exclusively.
Mobile devices use OpenGL|ES which is a different API completely and, more importantly, can not be used in the same manner as OpenGL. They are moving closer in feature parity however even then I would call anyone who treated a mobile device like a desktop insane.
Developers also regularly support multi rendering APIs when they produce 360, PS3 and PC titles; right now we (where I work) are producing a game which has support for X360, PS3, D3D11 and early WiiU support.
In the future, for a short while at least until we can drop it for the older platforms anyway, I suspect we'll have X360, PS3, D3D11, XBox720, PS4, WiiU and iOS support in the renderer (maybe Android too, although I know of no plans personally) - as always we will pick the best API for the platform.
wicketr - Monday, August 6, 2012 - link
The question is what API are you using for Mac users? They are 10% of desktop users, and significantly more than that if you discount the business segment of computers. Surely you're not ignoring a fourth (and growing) of the consumer desktop/laptop market by not even writing your game for Macs.If it's OpenGL, then wouldn't it be a greater benefit to "write once, deploy twice" on both OSes? Or are the graphical benefits of DirectX really that much better to write it twice?