codedivine
Regular
Any speculation about schedule and features for GL ES 3.0?
OpenGL ES 3.0?
- Thread starter codedivine
- Start date
I don't think there's anything concrete to find anywhere on the internet yet, but I'd say that OGL_ES3.0/Halti could be give or take on DX10 level.
Sadly yes, nothing concrete. ES 2.0 is getting really old, and that's starting to hamper game development in mobile space. ES 2.0 was introduced before the first iPhone got out, and a lot has happened since. If you compare mobile GPU development to the early PC GPU development, the biggest difference is that mobile GPU development just focuses on performance, while PC GPU development mainly focused on feature set (new GPU architectures always supported new DirectX version). The new features were the key in selling new GPUs to consumers. In contrast, nobody markets mobile GPUs by their feature sets. We still have lots of missing DX9 features that are very important for high quality game development. Tegra has the best extensions, but for example nobody else supports MRT rendering, so it's impossible to implement efficient deferred shading that works on all phones currently. Texture compression support is an even bigger problem (no standard texture compression at all).
Some might say that deferred rendering is free on a rather popular phone. So no need to quibble over it. 
But with phone makers fighting over everything with everything, feature sets will arguably become a selling point. But then, they will advance only when the last gen has been saturated.
But with phone makers fighting over everything with everything, feature sets will arguably become a selling point. But then, they will advance only when the last gen has been saturated.
Is it now? I'm not aware of any shipping OpenGL ES 2.0-based end-device being available before 2009. R300 was released in August 2002 and G80 was released in November 2006 (with DX9 & DX10 drivers not being available at launch in both cases). It's been a very long time since OpenGL ES 2.0 has been announced but I'm not convinced that's a good metric.
NV40 and R520 did add some important features compared to NV30 and R300 but the same is true of some of the newer DX9.3-level handheld GPUs from Imagination, Vivante, and NVIDIA although (except for Tegra 3) these are not publicly available yet.
Mobile GPUs are also massively slower than PC GPUs were back when they had the same level of features. This was originally compensated by much lower resolutions but that's no longer true. So it makes sense to spend more transistors on performance first before increasing feature sets. We are thankfully finally getting to the point where ultra-high-end mobile GPUs will match early high-end DX10 GPUs in performance.
A fair bit of marketing for video & imaging features though. I'd argue a lot of the PC GPU marketing in the last 10 years was trying to make consumers think their overall experience will be better even outside of gaming with a better GPU - the same is true for handhelds but with a variety of SoC subsystems rather than just the GPU.
The various DX9.3-level GPUs coming up shortly will all fix these issues. The gap between early OpenGL ES 2.0 GPUs and them will be somewhat longer than it was between SM2.0 and SM3.0 DX9 GPUs on the desktop but the gap between them and DX10/DX11-level GPUs will be much much shorter so I don't think there's much to complain about here. And before that we missed the (rather silly in retrospect) DX8 generation completely as well.
So while I understand your point and agree there are still a few missing bits, I still think it's mostly a perception issue.
Well deferred *renderers* aren't a good idea at all on PowerVR with the public extensions - you need programmable blending to make it bandwidth efficient. It's probably a different story on PS Vita though, it will be very interesting to see how engines evolve on that platform in the coming years.Some might say that deferred rendering is free on a rather popular phone. So no need to quibble over it.
BTW, in addition to the obvious there's one more obscure but very interesting benefit to deferred renderers which does come absolutely for free on PowerVR: no quad-based inefficiency for ALUs (obviously still necessary for derivatives/TMUs). And amusingly enough this is completely orthogonal to it being a TBDR!
ltcommander.data
Regular
http://www.anandtech.com/show/5243/rightware-announces-halti-an-opengl-es-30-benchmark
Benchmark developers must know something, as RightWare already announced their OpenGL ES 3.0 benchmark is due in 2012. In this age of rumours and leaks, Khronos seems quite adept at keeping a lid on details reaching the public before its officially approved.
The gap between DX9.0 and DX10.0 was long, but the gap between DX9.0 and DX9.0c was 2 years as was the gap between OpenGL 2.0 and OpenGL 2.1. I wonder why there wasn't any interest in releasing an interim OpenGL ES 2.1 spec that can standardize these DX9.3 features GPU makers are adding. Since OpenGL ES is largely based on established desktop specs it shouldn't be as difficult as starting from scratch. With OpenGL ES 2.0 being based on OpenGL 2.0, an OpenGL ES 2.1 based on OpenGL 2.1 + selected OpenGL 3.x extensions that work on DX9 generation hardware would make sense. It would certainly buy them more time to haggle over the more substantial leap OpenGL ES 3.0 implies.
Really? That would be quite amazing if it's true. But to be honest, with ultra-high-end mobile GPUs you mean something like the IMG Rogue series of GPUs right? I mean, I'm not aware of the GPU in the PSP Vita being close in performance to an NVIDIA G80 or something. Although to be honest, I've never really looked at how these ultra-mobile GPUs compare to desktop (and laptop) GPUs.
Arun is right - growing performance needs have been getting addressed. But also, judging by the recent extension trends in ES2 (and EGL), a major effort has gone towards the optimal integration of the ES pipeline with the host-platform painting systems - people need to get UI canvases in-and-out of the ES pipeline real quick. And lately they've been able to, which has made ES-based WM acceleration backends quite viable. Of course, that latter part has little to do with HW featureset advancements, but it comes to show that, not unlike on the desktop, games have been slowly stepping down from being the leading driving force of GPU progress.
ST-Ericsson's A9600 nearly certainly has 8 TMUs and ~128 ALUs at 667MHz. It's still a lot slower than G80 (especially for TMUs and memory bandwidth) but when you take into account the higher number of ALUs and the efficiency benefits of TBDR it's probably/hopefully faster (without anisotropic filtering) than G84 and RV630 which were the original DX10 mid-range cards (GeForce 8600 and Radeon HD 2600).
Raw performance is really important, but a robust feature set is even more so, as it allows more efficient rendering techniques to be implemented on mobile hardware. With a better feature set, you can both increase the image quality and reduce the battery usage.
I am not talking about some high end stuff like tessellation, geometry shaders, 32 bit floating point texture filtering or robust anisotropic filtering. I am talking about basic feature set that allows us to create efficient rendering engines. There's a lot of problems with basic features in OpenGL ES 2.0. The standard doesn't even support basic 8888 uncompressed textures without an extension, as many mobile devices at that time didn't even support true color (565 and 4444 were popular display front buffer formats). iPhone and Android changed all that, and now the mobile hardware is advancing at very rapid pace (iPhone 4 -> 4GS had 7x GPU performance improvement).
Here's some things that I would personally like to see in the new GLES version (all features that improve performance and efficiency):
1. There's no official texture compression format in OpenGL ES 2.0 standard. PowerVR chips use PVRTC, NVidia Tegra supports DXT and ARM Mali supports ETC. If you want to develop an Android game, you basically have to use uncompressed textures (a huge waste of bandwidth & performance), unless you want to include 3 separate versions of textures to the game package (not a good option since that kills you sales, as it makes the download much bigger). So you likely end up with a bad compromise (for example 565 textures) that both look worse and perform worse than compressed textures.
2. Limited vertex formats. 16 bit formats (both integer and float), 8888 formats and 10-10-10-2 formats need to be officially supported by the API (not just by some vendors specific extensions). Currently you need to use fat vertices on mobile devices, and that feels really ackward since you have no extra memory bandwidth to waste. You can use much more efficient vertex layouts on PC / console hardware.
3. Multi render target (MRT) rendering support. Almost all AAA games are currently using deferred rendering, and it's used because it improves performance (less shader combinations, less GPU state changes, less GPU constant changes, less vertex interpolants, no need to spend CPU cycles to find affecting lights for each rendered object, better scaling when there's lot of overdraw, etc, etc). Tegra is the only hardware with an GLES extension for MRT, and PowerVR guys have said (long time ago) that MRT rendering is possible with their hardware, but there's no API support yet. Official API support is desperately needed, and would enable many more efficient rendering techniques to be used on mobile hardware as well.
4. Efficient way to (partially) modify GPU resources (especially compressed textures) and retrieve GPU rendered data. Current API does format conversion under the hood (cache tiling, etc) and that consumes a lot of CPU resources. We need to have a more straightforward and efficient way to update GPU resources with CPU. Extra API overhead is fine for a PC graphics API (lots of extra headroom), but for mobile devices API overhead both kills your performance and degrades your battery life. As the mobile GPUs and CPUs are using the same memory (unified memory), it would be most efficient if both could simply access the same data directly (DX map/lock style API could be used for synchronization).
I am not talking about some high end stuff like tessellation, geometry shaders, 32 bit floating point texture filtering or robust anisotropic filtering. I am talking about basic feature set that allows us to create efficient rendering engines. There's a lot of problems with basic features in OpenGL ES 2.0. The standard doesn't even support basic 8888 uncompressed textures without an extension, as many mobile devices at that time didn't even support true color (565 and 4444 were popular display front buffer formats). iPhone and Android changed all that, and now the mobile hardware is advancing at very rapid pace (iPhone 4 -> 4GS had 7x GPU performance improvement).
Here's some things that I would personally like to see in the new GLES version (all features that improve performance and efficiency):
1. There's no official texture compression format in OpenGL ES 2.0 standard. PowerVR chips use PVRTC, NVidia Tegra supports DXT and ARM Mali supports ETC. If you want to develop an Android game, you basically have to use uncompressed textures (a huge waste of bandwidth & performance), unless you want to include 3 separate versions of textures to the game package (not a good option since that kills you sales, as it makes the download much bigger). So you likely end up with a bad compromise (for example 565 textures) that both look worse and perform worse than compressed textures.
2. Limited vertex formats. 16 bit formats (both integer and float), 8888 formats and 10-10-10-2 formats need to be officially supported by the API (not just by some vendors specific extensions). Currently you need to use fat vertices on mobile devices, and that feels really ackward since you have no extra memory bandwidth to waste. You can use much more efficient vertex layouts on PC / console hardware.
3. Multi render target (MRT) rendering support. Almost all AAA games are currently using deferred rendering, and it's used because it improves performance (less shader combinations, less GPU state changes, less GPU constant changes, less vertex interpolants, no need to spend CPU cycles to find affecting lights for each rendered object, better scaling when there's lot of overdraw, etc, etc). Tegra is the only hardware with an GLES extension for MRT, and PowerVR guys have said (long time ago) that MRT rendering is possible with their hardware, but there's no API support yet. Official API support is desperately needed, and would enable many more efficient rendering techniques to be used on mobile hardware as well.
4. Efficient way to (partially) modify GPU resources (especially compressed textures) and retrieve GPU rendered data. Current API does format conversion under the hood (cache tiling, etc) and that consumes a lot of CPU resources. We need to have a more straightforward and efficient way to update GPU resources with CPU. Extra API overhead is fine for a PC graphics API (lots of extra headroom), but for mobile devices API overhead both kills your performance and degrades your battery life. As the mobile GPUs and CPUs are using the same memory (unified memory), it would be most efficient if both could simply access the same data directly (DX map/lock style API could be used for synchronization).
Yes, DirectX did it again. Manufacturerers require hardware standards that dictate the feature set. No manufacturer is willing to develop features that are not commonly used, and no game developer is willing to use features that are not widely supported by their target hardware. Chicken and egg problem really. If DirectX is again required to drive the OpenGL development, so be it
Last edited by a moderator:
F16 and 10-10-10-2 are indeed not part of he ES2.0 spec, but 8 bit and 16 bit integers are supported, both signed/unsigned as well as normalised/full range.
I suggest you check out GL_OES_EGL_image, GL_OES_EGL_image_external and GL_OES_EGL_sync (superseding GL_NV_fence).
Although it's by extension, ETC1 support is a Khronos standard and therefore official. GL_OES_compressed_ETC1_RGB8_texture is supported by SGX, Tegra, Adreno, Mali, and Vivante cores. Or in other words, any phone or tablet worth supporting. It doesn't support alpha, but for textures that don't need alpha it makes sense to use as the lowest common denominator.
If including three different sets of compressed textures kills your sales then surely including uncompressed textures hurts sales even more since that'll usually take up even more space.
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).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.
Even ETC2 (or the two PVRTC variants) do not solve the issue of storing normal maps (or anything else than color data) efficiently. These formats are purely designed for storing color data. Even in DirectX 8 you could use a pair of DXT5 textures and store two channel normal map to the DXT (independent) alpha blocks (while using the RGB blocks for color data). Separate single and two channel alpha blocks formats have been introduced since (ATI 3dc -> BC4 and BC5 standards), and these are especially useful for storing any kind of compressed continuous data (normals, per pixel material properties, height for parallax mapping, etc, etc).
GL_OES_vertex_half_float is supported by PowerVR SGX hardware (some Android devices have it), but again not supported by iOS devices and not supported by all Android devices. PowerVR optimization guide recommends using 32 bit floats in vertex data. All integer formats (32, 16 and 8 bit) incur a conversion cost, since the shader cores process everything in floating point format (both 16 bit mediump and 32 bit highp are supported). Since 16 bit floating point input is identical to the internal 16 bit mediump format, using it would be very efficient... but with no extension to support it on iOS that's not possible (hardware would support it fine, if the API allowed it).
Most of these issues are purely software issues (hardware support is already there), and would be solved by an evolving API with a strictly defined minimum feature set (that would gradually be improved every year by new API revisions).
How does that solve your iDevices issues where Apple expose whatever they decide to expose from the standards and/or hw featurset?iPhone, iPad and iPod do not support GL_OES_compressed_ETC1_RGB8_texture. I think these devices are pretty much worth supporting
I do expect new compression standards to make it into the upcoming ES core.
You can use GL_OES_compressed_paletted_texture to a similar if not better effect (when storing normal maps).
3DC has been around in Adrendo/z4xx, but I concur it's not universally supported by the vendors.
Not all mobile cores do half-floats arithmetics natively (many do for-free conversions from half-float in the tex/vert fetches, though). Basically, there's no guaranteed-performance-gain sub-SP format that is also universally supported. Just like on the desktop, DX or otherwise.
ES does strictly define a minimal featureset. Whether that meets some party's proprietary 'minimal featureset' is another matter.
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 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.
Paletted textures are only supported by old hardware. New hardware such as SGX, Mali and Adreno do not support paletted texture extensions at all. Check here: http://stackoverflow.com/questions/3881197/opengl-es-2-0-extensions-on-android-devices (only two devices in the list support paletted texture extensions). Some brand new graphics chips such as Mali 400 (used in Galaxy Note and S2) only support very few extensions at all (Mali 400 has only 9 supported extensions). This limits a lot (all Android games must work on Galaxy S2, since it's one of the most popular devices currently).
Last edited by a moderator:
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 because that, even 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.
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.
Similar threads
