OpenGL ES 3.0?

That would just lead to huge fragmentation of the market which would not be good for devs, less regular step changes work better for everyone.
Agreed although to minimise fragmentation you also want there to be a single clear standard for every 'step change' which there arguably wasn't for OpenGL ES 2.0. In that sense it's good that handheld chips are now also aligning with DirectX (DX9.3 for SGX5x4/Adreno 225/Tegra 3/Vivante and DX10/11 for Rogue/Mali-T600).
 
If you want to store better quality normal maps with PVRTC, one thing you can try is to just store the X(red) and Y(green) channels in the texture and zero the Z (blue), compress these, and then use the fragment shader to derive Z. The reason for this choice is that R&G have the highest precisions of the channels and that, though Z is related to X and Y, it is not related in a linear way and hence messes up the compression if all are done at the same time.
Sounds very similar to the old school DXT5 normal compression trick (green + alpha + sphere decode) used in older PC games. However green and alpha are completely separate in DXT5, so the quality of the PVRTC trick shouldn't be as good (but then again, PVRTC takes only half the space).

The bad thing is that similar trick wouldn't work at all with ETC, since it has 2x4 blocks of constant chroma and luminance only varies from pixel to pixel. Using it to compress normals would result in very bad quality (specular highlights would have very bad visible blockiness). As I have played a lot with virtual texturing during the last two years, texture compression has also been one of the areas we have focused on. Beating the quality of two independent DXT alpha channels in normal map compression is a pretty hard thing to reach (for fast runtime decompression of course). DXT compression is very flexible (lots of different formats that combine the same decompression block hardware in a different way), and it's simple to partially update and to compress in runtime (GPU pixel shaders can compress it on fly very quickly by a relatively simple shader). These are all very good qualities (especially for a game/engine that uses virtual texturing -- I am a bit biased towards it, I must admit :) ).

So the problem remains that there's no good standard way to compress normal maps in OpenGL ES 2.0. And normal maps have been available since DirectX 7 (dot3 combiner). Basically if you want to use normal maps in your game, you have to use uncompressed formats (= big hit to performance and battery life).
That would just lead to huge fragmentation of the market which would not be good for devs, less regular step changes work better for everyone.
A major version update every other year would be much better than the current situation (five years without a new version). In comparison a new major DirectX version was released once a year, and that worked very well. It was a key factor why DirectX beat OpenGL in desktop computers (common feature set made developers life so much easier compared to programming a separate render path for every GPU). Things of course are a bit better now, since basic stuff such as vertex buffers have proper API support in OpenGL ES (and do not require extensions).
 
Last edited by a moderator:
Sounds very similar to the old school DXT5 normal compression trick (green + alpha + sphere decode) used in older PC games. However green and alpha are completely separate in DXT5, so the quality of the PVRTC trick shouldn't be as good (but then again, PVRTC takes only half the space).
The non-separation seems to be far less of an issue with PVRTC due to it not being block-based, but of course there are cases where it would be better to have the two channels completely independent.
The bad thing is that similar trick wouldn't work at all with ETC, since it has 2x4 blocks of constant chroma and luminance only varies from pixel to pixel.
Yes, with ETC the two channels would have to be done with two independent textures (note that both should encoded as grey scale).
 
That's where marketing steps in. Let's imagine for a while that DirectX instead was the leading mobile graphics standard, and we got a new DirectX version every year. Competition in the Android hardware is fierce, and all the leading manufacturers would start supporting the new DirectX version in their new phones as soon as possible. And they would use lots of money marketing that their new phone has the newest DirectX version. Apple wouldn't be late to the party, no, they would be the first manufacturer to support the new DirectX stardard every time (just like they are always first in row in supporting new Intel CPUs for their ultralight laptops. I am sure they will have the first Ivy Bridge ULP laptops out as well). They know marketing, they know timing, and they know how to manage business deals. Currently there's no value in marketing the mobile GPU feature set, as customers do not understand about 16 bit floats, 10 bit packet formats or MRTs, they care about DirectX 7 compatible, DirectX 8 compatible, DirectX 9 compatible, etc. Try selling a DirectX 7 compatible device when all your competitors are touting how good their DirectX 8 compatible devices are. Not going to be easy, and definitely not something Apple would do.
I understand your marketing angle there but I think you overestimate customers' keeping up with tech buzzwords (which is more or less what DX# and GLES# speak to them). Customers care about whether their 'UI experience is snappy' and whether they can play Raging Flamingos 5 on their new mobiles. And Apple are perfectly aware of that, which is why they could afford to ship one of the most broken ES stacks out there, deeply into their product cycle. To those few customers who actually understand the significance of graphics API versions, the mere API ordinals are not so important as actual featuresets. And GPUs' pros and cons will never be exhausted by a core standard featureset, no matter how lavish or frugal that might be.

I do also expect new features and new compression standards. However mobile GPUs are advancing in a really fast pace, and the ES 2.0 standard is still from 2007. Five years is an eternity in this business. We need at least biannual version updates that gradually improve the minumum feature set.

This is how often DirectX was updated when PC GPUs were young:
DirectX 1.0 - 1995
DirectX 2.0 - 1996
DirectX 3.0 - 1996
DirectX 5.0 - 1997
DirectX 6.0 - 1998
DirectX 7.0 - 1999
DirectX 8.0 - 2000 (8.1 in 2001)
DirectX 9.0 - 2002

A brand new version every year. All manufacturers (3dFX, ATI, NVidia, PowerVR, S3) supported the new standard as soon as they could. Without supporting the new standard, you would be toast.
No wonder, DX was a bloody boiling mess up until version 7. While I agree biannual standard updates would be nice to have, I care much more about what the API extension propagation mechanism brings to the table: frequent advancements which steer the core standard one way or another based on developers' and market's response.

Paletted textures are only supported by old hardware. New hardware such as SGX, Mali and Adreno do not support paletted texture extensions at all.
No modern hw supports it directly in the TMUs as it is trivial to implement shader-side, texture_external-style. Yet the OES compression extension is even more trivial to implement in the software stack, decompressing assets on the fly; all modern implementations of the extension that I've seen do exactly that. Those vendors who don't bother implementing it usually have better compression alternatives. Or just wouldn't bother with something that can be left to the client.
 
Last edited by a moderator:
Some modern embedded graphics hardware does support palette textures in the TMU. It's more a specific implementation detail though, as you've mentioned, because it's doable in the shader.

Without my ImgTec hat on, mobile embedded graphics isn't a mess just because of the extension mechanism, but also because embedded graphics is still taking some fairly baby steps and there are many more players in the market.

Khronos doesn't have the ability to force all of those vendors to spend area on features, so chances are anything expensive isn't mandatory in core, but is optional via extension. Unless the market gets smaller, getting a concensus on core features is going to be difficult, and the Khronos voting mechanism has some inherent problems when trying to achieve that.

sebbbi's concerns are almost completely valid, when it comes to having to add branches to your code to support myriad different HW platforms because of that.

It's just because the market is immature and filled with players. FWIW (ImgTec hat back on), we put emphasis on shipping a stable, compliant driver with support for lots of extensions that are helpful for developers. However, we can't force our customers to ship the extensions.

There's no easy way for sebbbi to get what he wants. The best place to start is Apple, though, to get them to ship more extensions for GLES2. Drop our devtech team a line and we can pass things on to Apple, or you can get in touch with them directly and make the case. Good luck getting ETC though :runaway:
 
Agreed although to minimise fragmentation you also want there to be a single clear standard for every 'step change' which there arguably wasn't for OpenGL ES 2.0. In that sense it's good that handheld chips are now also aligning with DirectX (DX9.3 for SGX5x4/Adreno 225/Tegra 3/Vivante and DX10/11 for Rogue/Mali-T600).

You really don't think ES2.0 was a clear step change over ES1.1? I'd agree there's a couple of key items missing in ES2.0 but it was a step change over 1.1.
 
A major version update every other year would be much better than the current situation (five years without a new version). In comparison a new major DirectX version was released once a year, and that worked very well. It was a key factor why DirectX beat OpenGL in desktop computers (common feature set made developers life so much easier compared to programming a separate render path for every GPU). Things of course are a bit better now, since basic stuff such as vertex buffers have proper API support in OpenGL ES (and do not require extensions).

Two years is better but still too short, three years should be the minimum imo. Don't forget that OGLES isn't being designed in a vacuum, it can draw on the previous API work done on desktop, it doesn't need baby steps we've had previously. In my opinion DirectX only "beat" OpenGL as it wasn't being designed by open committee, MS dictated what made the bar, the sort of crap that continues block forward progress in OGL has never been an issue for it.
 
You really don't think ES2.0 was a clear step change over ES1.1? I'd agree there's a couple of key items missing in ES2.0 but it was a step change over 1.1.
Oh absolutely, what I said (perhaps not very clearly) is that there wasn't a clear standard for what that step change was - in other words, the minimum specification was arguably a bit too low and there were too many optional features. So I don't think we disagree in any way :)
 
Oh absolutely, what I said (perhaps not very clearly) is that there wasn't a clear standard for what that step change was - in other words, the minimum specification was arguably a bit too low and there were too many optional features. So I don't think we disagree in any way :)
I still find it curious that no incremental OpenGL ES 2.1 was ever done. The evolution from OpenGL ES 1.0 to 1.1 was 1-2 years I believe. I suppose it's as Rys said that getting the many vendors to agree on a core spec is difficult. At the very least, an official extension pack for OpenGL ES 2.0 as OpenGL ES 1.1 had would be useful in consolidating the popular/useful extensions. That way there would be less of a marketing stigma for those who choose not to implement the Extension Pack compared incrementing the OpenGL ES number and developers get a grab bag of common additional extensions to use without having to worry about and check extensions 1 by 1.
 
iPhone, iPad and iPod do not support GL_OES_compressed_ETC1_RGB8_texture. I think these devices are pretty much worth supporting :) . And there's some Android phones that do not expose it either (for example Samsung Galaxy Spica with Android 2.1). The SGX graphics chip in iOS devices surely has hardware support for ETC1 (as most Android phones with same SGX chips do support it), but there's no extensions available. It's purely an API issue. As a game developer, I like the Microsoft style better (forcing all manufacturers to meet the same minimum requirements and gradually rising the minimum requirements with each API release).

I think iOS support is moot. Your argument was that a lack of standard forced people to use uncompressed textures or include multiple compressed textures in their apps. For iOS support you must provide iOS unique packages and there's no real point including anything but PVRTC textures (which were never a candidate for OpenGL ES standardization). It's not like supporting the PVRTC on an iOS port is a huge work effort compared to the other portability concerns.

I actually think in this case Apple is better off not giving people an inferior option.

ETC1 isn't that good compression to begin with. It stores croma in 8 pixel (2x4) blocks. Only luminance can be controlled per pixel. The chroma isn't even interpolated between adjacent blocks. ETC2 improves the quality drastically (and finally introduces the long waited alpha channel support). ETC2 was introduced in 2007, but there still isn't a single hardware out with ETC2 extension support. That tells a lot. Evolving standards that dictate minimum requirements are badly needed.

Yeah it sucks, but it's better than using uncompressed textures like you were saying.. Lack of chroma control beyond 2x4 doesn't seem like a huge deal to me - how many videos are output to better than 4:2:2 (okay granted that's 4 pixels).

I guess vendors would rather focus on their proprietary standards since they see it as giving them competitive differentiation (except Mali which is just left in the dust here..). In this case it's not much of an instance of the software lagging..
 
I guess vendors would rather focus on their proprietary standards since they see it as giving them competitive differentiation (except Mali which is just left in the dust here..). In this case it's not much of an instance of the software lagging..
I wonder if the licensing situation for texture formats is complicated. For example, Apple was sued over S3TC patents on iOS, even though Apple doesn't use S3TC there, before the judge restricted the case to Macs. Licensing issues could encourage vendors to only support a limited number of texture formats, preferably proprietary.
 
Yes, with ETC the two channels would have to be done with two independent textures (note that both should encoded as grey scale).
That should work pretty well, but would require two texture sampling instructions, and thus run slower and consume more battery than a single texture fetch. Not an ideal situation for a hardware that has limited performance and battery life to begin with.
It's not like supporting the PVRTC on an iOS port is a huge work effort compared to the other portability concerns.

I actually think in this case Apple is better off not giving people an inferior option.
PVRTC algorithm doesn't support subrectangle updates (CompressedTexSubImage2D), since the blocks have dependencies to neighbour data.

GL_EXT_texture_compression_s3tc and GL_EXT_texture_compression_dxt1 both support CompressedTexSubImage2D (with 4x4 rectangle alignment), and ETC should support it also (as the ETC blocks are self contained like S3TC blocks). However the current ETC extension states that INVALID_OPERATION will be returned if this operation is used. Basically I would like to have a compressed texture format available that supports CompressedTexSubImage2D. Without it you cannot basically implement dynamic texture atlases (unless you use uncompressed texture formats on all your atlases and this again is slow and eats lots of battery).

PVRTC is actually a very good algorithm for color data compression. I wouldn't mind at all if it became the standard for color compression. However it doesn't cover all the use cases (subrectangle updates and compressing of non-color data), and thus we need to use uncompressed textures for these reasons (= a bad thing for perf & battery life).
Lack of chroma control beyond 2x4 doesn't seem like a huge deal to me - how many videos are output to better than 4:2:2 (okay granted that's 4 pixels).
Agreed, 2x4 lower chroma resolution isn't that bad (esp with DPIs such as iPhone 4 and Galaxy Nexus/Note have). But if you use ETC to something else than UI, it's likely that the textures will be regularly scaled up (there's never enough texture resolution to keep them 1:1 all the time), and that's when the quality difference becomes really noticeable. And of course again ETC cannot be efficiently used to compress normal maps, so it's not enough (in comparison DXT compression solves all use cases).
I wonder if the licensing situation for texture formats is complicated. For example, Apple was sued over S3TC patents on iOS
Compression algorithms have always been plagued with patent issues. Even simple compression algorithms such as RLE (run length encoding) were patented. There's over ten different patents for arithmetic coding (all expired now), and the situation is similar for LZW and many other general purpose lossless compression algorithms. Most currently used video, audio and image compression algorithms all are under heavy patent barrier.
 
That should work pretty well, but would require two texture sampling instructions, and thus run slower and consume more battery than a single texture fetch. Not an ideal situation for a hardware that has limited performance and battery life to begin with.
I suppose it depends on how well a particular harware system handles multitextures <shrug>
PVRTC algorithm doesn't support subrectangle updates (CompressedTexSubImage2D), since the blocks have dependencies to neighbour data.
I was contemplating writing some code or a white paper that explained how to do it manually with some minor limitations. As a quick summary, assuming you are using 4bpp and that your sub images are multiples of 4x4 pixels, if you avoid using the top two rows, the bottom row, the left most two columns and the right most column in each texture, then you can join the subimages together with no "effective" interference. (A corresponding restriction can be used for 2bpp as well). However, this is likely to become redundant in the near future.
 
I was contemplating writing some code or a white paper that explained how to do it manually with some minor limitations. As a quick summary, assuming you are using 4bpp and that your sub images are multiples of 4x4 pixels, if you avoid using the top two rows, the bottom row, the left most two columns and the right most column in each texture, then you can join the subimages together with no "effective" interference.
Heh, I was actually thinking about the possibility to "hack" it that way... But without CompressedTexSubImage2D support, updating the modified PVRTC data partially to the GPU is impossible (so this technique cannot be used in practice). 4x4 borders around the atlas textures are very much acceptable (compressed textures are so much more memory efficient than uncompressed).
 
Last edited by a moderator:

No idea about Adreno3xx but IMG has publicly claimed that according to market demands Rogue will scale in between DX10 and DX11. If my speculation should be true that Halti is roughly below or at DX10 level, all next generation GPU cores shouldn't have a problem covering Halti's requirements.
 
This is how often DirectX was updated when PC GPUs were young:
DirectX 1.0 - 1995
DirectX 2.0 - 1996
DirectX 3.0 - 1996
DirectX 5.0 - 1997
DirectX 6.0 - 1998
DirectX 7.0 - 1999
DirectX 8.0 - 2000 (8.1 in 2001)
DirectX 9.0 - 2002

A brand new version every year. All manufacturers (3dFX, ATI, NVidia, PowerVR, S3) supported the new standard as soon as they could. Without supporting the new standard, you would be toast.
I think you're giving DirectX way too much credit here, since a _ton_ of features were completely optional (before dx10). Unless I'm mistaken ALL surface formats (and the specific capabilities of these, e.g. texturing, render target, ...) are completely optional for instance (which is after all how ATI got away being vs3.0 compliant despite not supporting vertex texturing - they supported it of course just not a single format...).
So being DX 9.0 compliant tells you almost nothing about hw capabilities in fact, and I can't see what's the difference to code depending on dx caps bits or depending on gles extensions instead. Most likely just all the hw you cared about in dx supported the features you needed anyway (well except some well known exceptions) but this got little to do with the API itself. Only DX10 changed that.
 
So being DX 9.0 compliant tells you almost nothing about hw capabilities in fact, and I can't see what's the difference to code depending on dx caps bits or depending on gles extensions instead. --- Most likely just all the hw you cared about in dx supported the features you needed anyway (well except some well known exceptions) but this got little to do with the API itself. Only DX10 changed that.
Many texture and vertex formats were optional, but features such as vertex buffers, index buffers, rendering to a texture, all multitexture/blend modes (except for a few optional ones), etc, were all introduced as part of the DirectX standard. For a long time all those required separate vendor specific extensions in OpenGL. There were many games that required NVidia specific extensions (for vertex/index data), and wouldn't run on other hardware.

I must agree that early DirectX wasn't nowhere as nice as the current one, but it allowed efficient programs without vendor specific extensions (compared to early OpenGL). Things have improved a lot since (on both fronts). I remember coding some Voodoo 2 specific DirectX 5 stuff. It had separate memories for render targets, texture layer 0 and texture layer 1. DirectX had a specific memory index parameter just for Voodoo 2, so that you could create the textures to the proper memory space :)
 
Many texture and vertex formats were optional, but features such as vertex buffers, index buffers, rendering to a texture, all multitexture/blend modes (except for a few optional ones), etc, were all introduced as part of the DirectX standard. For a long time all those required separate vendor specific extensions in OpenGL. There were many games that required NVidia specific extensions (for vertex/index data), and wouldn't run on other hardware.
Well ALL texture blend ops were optional too in d3d9 (you've got D3DTEXOPCAPS_ADD, D3DTEXOPCAPS_MODULATE, ...), same for things like alpha blend. Frankly I don't believe for a second any app out there actually checks for all bits it requires (ok probably DCT does). That said, you've got a point it was at least part of the standard, so at least you don't have to deal with multiple extensions achieving the same thing as you can stick to supported/not supported (but of course the combinatorial explosion of all caps bits is staggering).
 
I agree that the DX caps were annoying, but at least you got a single official way to implement each feature. Every existing card that supported that feature worked with the same implementation, and more importantly all future hardware (from all vendors) worked with the same code. In comparison, with OpenGL you had several extensions to implement simple things like drawing geometry using a vertex/index buffer. NVidia had at least two extensions for this (older extension was slightly less efficient). ATI/S3/PVR/3DFX had of course their own extensions that weren't fully compatible with each other. It was a mess.
 
Back
Top