OpenGL ES 3.0?

Remembering where this discussion began - asking whether OpenGL ES would start to adopt features now standard in desktop graphics - has Khronos screwed pooch in failing to move OpenGL ES onward fast enough?

Taken from the Anadtech liveblog of GoogleIO:

09:46AM PDT - Now talking about Graphics in L
09:47AM PDT - Android Extension Pack defined with Google, Qualcomm, ARM and NVIDIA
09:47AM PDT - adds support for tessellation, geometry shaders, compute shaders and ASTC
09:47AM PDT - Unreal Engine 4 running on Android L with NVIDIA tablet hardware
09:47AM PDT - This sounds like Google's solution to the OpenGL/OpenGL ES gap


PowerVR producing GPU's with full DX11 compliance
Qualcomm producing SoC's with full DX11 compliance
Nvidia producing SoC's with full DX11 compliance
Are ARM also producing GPU's with full DX11 compliance?


And where is OpenGL ES in all those...


Did they mess up, or will this Android Extension Pack be rapidly be rolled back into what will shortly be announced as OpenGL ES 4.0?
 
Remembering where this discussion began - asking whether OpenGL ES would start to adopt features now standard in desktop graphics - has Khronos screwed pooch in failing to move OpenGL ES onward fast enough?

Taken from the Anadtech liveblog of GoogleIO:

09:46AM PDT - Now talking about Graphics in L
09:47AM PDT - Android Extension Pack defined with Google, Qualcomm, ARM and NVIDIA
09:47AM PDT - adds support for tessellation, geometry shaders, compute shaders and ASTC
09:47AM PDT - Unreal Engine 4 running on Android L with NVIDIA tablet hardware
09:47AM PDT - This sounds like Google's solution to the OpenGL/OpenGL ES gap


PowerVR producing GPU's with full DX11 compliance
Qualcomm producing SoC's with full DX11 compliance
Nvidia producing SoC's with full DX11 compliance
Are ARM also producing GPU's with full DX11 compliance?


And where is OpenGL ES in all those...


Did they mess up, or will this Android Extension Pack be rapidly be rolled back into what will shortly be announced as OpenGL ES 4.0?



The specs for OpenGL ES 3.1 were released just 3 months ago so no, I don't think an OpenGL ES 4.0 will be released in the near future.
In their slides, they made special attention to the fact that Tesselation and Geometry Shaders wouldn't be supported and some of the forum experts argued that it wasn't needed anyways.

But now, google comes in and announces support for tesselation and geometry by themselves. Quite a bitch-slap to Khronos' incompetence for at least not being able to predict how fast the GPU performance of android embedded devices would climb through the years (effectively making tesselation a requirement for visual "parity" between android consoles and xbone/ps4 in a rather near future).
 
Last edited by a moderator:
Quite a bitch-slap to Khronos' incompetence for at least not being able to predict how fast the GPU performance of android embedded devices would climb through the years (effectively making tesselation a requirement for visual "parity" between android consoles and xbone/ps4 in a rather near future).

agreed, it is not qas if we didn't know that DX11 was coming to mobile SoC's at least two years ago.
 
For the record neither ARM nor IMG have announced yet feature level DX11.x GPU IP. No idea for Vivante and their newest IP to be honest.
 
agreed, it is not qas if we didn't know that DX11 was coming to mobile SoC's at least two years ago.

You guys are acting like OpenGL extensions are something new and shocking. Even in the mobile world they've been plentiful. I would have been much more surprised had no one stepped up to provide extensions for major features in some mobile GPU hardware.
 
You guys are acting like OpenGL extensions are something new and shocking. Even in the mobile world they've been plentiful. I would have been much more surprised had no one stepped up to provide extensions for major features in some mobile GPU hardware.

Does anyone actually use them on Android?
 
agreed, it is not qas if we didn't know that DX11 was coming to mobile SoC's at least two years ago.
But Khronos already has an API equivalent to DX11 and that's OpenGL 4.x. The goal of OpenGL ES is not directly to provide desktop graphics on mobile, but to provide advancing graphics while maintaining a small footprint and low power consumption. Khronos being selective in what they include in OpenGL ES is not them mismanaging it, but them doing what they said they would do. The issue is that current mobile GPUs are increasingly desktop GPUs placed in a mobile SoC in the case of nVidia or mobile GPUs beefed up to usable in desktops in the case of other vendors like Qualcomm which blurs the line between mobile and desktop GPUs on a hardware feature level. Using an embedded focused API will leave the hardware underutilized while desktop API may include unneeded legacy cruft. The solution may be for Khronos to just combine the mobile and desktop audience using a single API based on the OpenGL core profile, incorporating ADZO and some streamlining from OpenGL ES and returning OpenGL ES to focus on more basic embedded applications.
 
Does anyone actually use them on Android?
I am.
Though wether or not its being obeyed by the device is a different story

I was also using ogles extensions on IOS, just had a look at one of my iphone games http://auzed.com/ I was using these extensions
IMG_texture_compression_pvrtc_supported
GL_OES_depth_texture_supported
GL_OES_vertex_array_object_supported
 
I am.
Though wether or not its being obeyed by the device is a different story

I was also using ogles extensions on IOS, just had a look at one of my iphone games http://auzed.com/ I was using these extensions
IMG_texture_compression_pvrtc_supported
GL_OES_depth_texture_supported
GL_OES_vertex_array_object_supported

It makes sense on iOS where you have a pretty good idea of what you can expect from the GPUs that will run your software, but on Android, given the amount of fragmentation, is it really worth it?
 
but on Android, given the amount of fragmentation, is it really worth it?
Sure, the latest galaxy flagship sells about whatever apples flagship sells add in all the other highend android phones and theres more 'capable' android phones out there than apple phones
 
Sure, the latest galaxy flagship sells about whatever apples flagship sells add in all the other highend android phones and theres more 'capable' android phones out there than apple phones

The problem comes in that once you start using extensions, what runs on one Android phone may not run on another Android phone. That isn't the case "usually" with iPhones as there is usually just one set of hardware using only one set of common CPU/GPU features per generation. Whereas even within a single generation of Android devices you can have a relatively large variety of CPUs and GPUs all with varying feature levels and support (or lack of support) for extensions.

Regards,
SB
 
I suppose there probably are more Qualcomm S800 phones than, say, Apple A7 ones. I'm not sure those S800 phones necessarily run the same version of Android and support the same OGL extensions, however.

But the point is taken that in spite of fragmentation, sheer volume may justify the use of such extensions.
 
You could argue the same with opengl es 3.0 support.
Is it worth worrying about opengl es 3.0 with apple devices? the android ogles3.0 market certainly outnumbers the IOS market

android
Nexus 7 (2013)
Nexus 4
Nexus 5
Nexus 10
HTC Butterfly S
HTC One/One Max
LG G2
LG G Pad 8.3
Samsung Galaxy S4 (Snapdragon version)
Samsung Galaxy Note 3
Samsung Galaxy Note 10.1 (2014 Edition)
Sony Xperia Z/ZL
Sony Xperia Z1
Sony Xperia Z Ultra
Sony Xperia Tablet Z
etc

IOS
iphone 5s
ipad 5, ipad5 mini

thats it! no iphone 5c, iphone 4s,4 etc
Personally I say yes, the iphone 6/ipad6 etc will support ogles 3.0
 
Yeah but there's still a lot of OpenGL ES 2.0 devices. One big problem is the etc1 texture format is essentially worthless. So unless if you want bad textures, you have to make a pvr build, qualcomm build, nv build, etc..

On iOS (pvr) and WP (dx9) it's just one build.
 
So [strike]unless[/strike] if you want bad textures, you have to make a pvr build

we've been waiting forever for decent pvr textures
 
It doesn't support alpha. And the only fool proof way to include alpha with ETC1 is to put it in a separate uncompressed texture. This is problematic for us since it's already quite difficult to stay within memory budget on 512mb devices (on any platform). Adding separate textures just for alpha isn't always feasible. I should have been clearer in my previous post: etc1, in various situations, is worthless. :p

Ultimately this isn't a huge issue. It's not very difficult to write an automated build process to crank out multiple builds at once. It was just one example of how extensions are used in the mobile arena. Obviously there are other examples (depth textures being a big one), but this example had the added benefit of showing the effects of android's fragmentation and the potential drawbacks of using extensions.
 
Back
Top