I would imagine that Apple has announced OpenGL 3.2 support because that’s what the current 10.7 development seeds have support for. Apple isn’t known for releasing details of future products. I wouldn’t hold my breath for GL 3.3 though - besides GL features, they still have some catch-up to do regarding GL performance.
Apple’s aware of the fact that they’ve let up on OSX development in the past few years, as is evidenced by their Back to the Mac event last October. Hopefully they mean it.
Microsoft sets the standard for 3D graphics on the desktop/laptop. Once you set the standard (D3D10/11), copycats (OGL 3.X/4.X) will have to wait months, if not years, to catch up in terms of implementation quality.
And yet, that didn’t stop NVIDIA from shipping D3D-10-level extensions pretty much the day the GeForce 8000’s hit the market.
I was hoping for an announcement of an OpenGL ES 3.X spec at this year’s GDC, but doesn’t appear to be on anyone’s radar. Maybe we have to wait for Microsoft to bring such D3D10-features to the next version of Windows Phone before Khronos makes a move.
In the mobile space, there’s a general stagnation about hardware features. In desktops, performance generally pushed features; take the Radeon 9700. It sold well not because it ushered in the age of D3D9-class cards, but because it was so much faster than the competition at the time.
In the mobile space, power consumption rules all. Any new features you add take up die space and power, so unless new battery technology happens that suddenly gives you lots more power, you’re not going to see significant jumps in features happening that often. The mobile space favors slow evolution of hardware.
Combine this with the simple utility of extensions. The base ES 2.0 platform represents some core functionality, but most ES platforms also expose a number of extensions. This represents the ability to select features as needed, allowing your engine to be responsive to different featuresets on different hardware.
All an ES 3.0 would do is specify a new base featureset. Desktop OpenGL can get away with that because Microsoft is out there defining specific levels of hardware. But in the mobile space, you have PowerVR and… well, that’s it. NVIDIA’s trying to get involved with Tegra, but they’re still basically following PowerVR’s featureset.
Or, to put it another way, there’s really no need for ES 3.0. The most it might do is standardize existing practice (promoting to core a commonly used set of extensions, like FBO). This would have little effect on users.
When you set the standard (i.e. the first manufacturer with D3D10 hardware), you are able to do things like that. OpenGL 3 was based around D3D10, not the other way around. Thus, when NVIDIA exposed D3D10 functionality to OpenGL in 2006, Khronos simply had to say: that extension/functionality is required for OpenGL 3 (late 2007).
Actually, I’d like to see support for integer textures (EXT_texture_integer) in the mobile space. That is one OGL3/D3D10 feature that would be useful.
EDIT: I just noticed that the PowerVR’s SGX545 has support for OGL3.2/D3D10.1 on embedded chipsets. Until the iPhone/iPad starts using it, those features won’t migrate into the mobile space.
May i as whats so appealing in integer textures and which formats specifically?
I mean, [u]int32 variants are pretty much all useless since introduction of floatBitsToInt (which as far as i know can be implemented everywhere where true int’s are supported).
Of course extra sugar doesnt hurt, but doesnt really enable anything either.
When trying to retrieve the original integer value of a 16-bit texel in a shader whose value has been normalized as a float (via glTexImage*D), converting it back to an integer leads to rounding errors. The 16-bit format GL_R16UI/DXGI_FORMAT_R16_UINT prevents this issue.
When you set the standard (i.e. the first manufacturer with D3D10 hardware), you are able to do things like that. OpenGL 3 was based around D3D10, not the other way around.
And Apple helped set the OpenGL 3.3 standard (among others); they’re on the ARB. Therefore by your own logic, they should have been able to have a 3.3 implementation out there before now.
Actually, I’d like to see support for integer textures (EXT_texture_integer) in the mobile space. That is one OGL3/D3D10 feature that would be useful.
My point is that you don’t need a GL ES 3.0 specification for that. All you need is an ES version of EXT_texture_integer. Collecting functionality into an ES 3.0 doesn’t have any more meaning than just checking for EXT_texture_integer. Mobile hardware simply isn’t grouped into nice levels of functionality the way D3D provides for desktop hardware.
When trying to retrieve the original integer value of a 16-bit texel in a shader whose value has been normalized as a float (via glTexImage*D), converting it back to an integer leads to rounding errors. The 16-bit format GL_R16UI/DXGI_FORMAT_R16_UINT prevents this issue.
I think he’s wondering what you need integers for to begin with. That is, what you’re doing that you need integer lookup tables.
That is the problem. We’ve seen that Microsoft’s dictator-style approach has made them the current innovator of 3D graphics on the PC. If Apple were in Microsoft’s position, we would be having previews of OpenGL 5 in the latest preview of Lion.
Emulating old hardware.
The reason I refer to the mythical specification as OpenGL ES 3.X is because it would be a subset of OpenGL 3.X functionality, similar to how ES 2.0 is a subset of GL 2.0 functionality.
Subsuming an extension into a core specification is the only sure way that it will be supported by multiple manufacturers. It is easier to list OpenGL ES 3.X as requirement, rather than EXT_texture_integer.
The ironic bit about OSX OpenGL > 3.x support, is that the iPhone developer kit (and simulator) support OpenGL ES 2.0, which is 90% of the OpenGL 3.2 core profile. Snow Leopard already renders that in the iPhone simulator. So Apple have a running 3.x OpenGL stack on OS X Snow Leopard. But only for iOS software.
The ironic bit about OSX OpenGL > 3.x support, is that the iPhone developer kit (and simulator) support OpenGL ES 2.0, which is 90% of the OpenGL 3.2 core profile. Snow Leopard already renders that in the iPhone simulator. So Apple have a running 3.x OpenGL stack on OS X Snow Leopard. But only for iOS software.
Could not getting any wronger. OpenGL ES 2.0 is basically a stripped version of OpenGL 2.1 with limited FBO support. The following GL3 features are not in OpenGL ES2.0: integer texture support, native integers in shaders (including bit operations), texture buffer objects, uniform buffer objects, multiple render targets, floating point textures, transform feedback, instancing… actually what I am doing here is basically listing everything that is in GL3 that is not in GL2.
There is only one feature in GLES2.0 that is not in GL2.1: render to texture, and even at that, unextented GLES2 spec only allow one to render to mipmap level 0.
So just to repeat:
OpenGL ES 2.0= Limited FBO + GL2.1 - fixed function pipeline - complete_non-power_2_texture_support - most_read_back_from_GL
[in unextended GLES2 non-power-2 textures are supported with no mipmapping and limited texture wrap modes]
[GLES2 includes no public API points to read directly from a texture of a buffer object, in fact mapping a buffer object is an extension in GLES2 and it is write only for that matter. The only realistic way to read iamge data from a texture in GLES2 is via FBO’s+glREadPixels, but that only will work for RGB and RGBA textures]
What you can do with GLES2 (if you are into that kind of thing) is write a GLES2 application and it will mostly work in GL3 core profile… but that is not really true either as GLES2 allows one to source index and attribute data from client side memory (i.e. sourcing from buffer objects is not required).
The ironic bit about OSX OpenGL > 3.x support, is that the iPhone developer kit (and simulator) support OpenGL ES 2.0, which is 90% of the OpenGL 3.2 core profile. Snow Leopard already renders that in the iPhone simulator. So Apple have a running 3.x OpenGL stack on OS X Snow Leopard. But only for iOS software.
Could not getting any wronger. OpenGL ES 2.0 is basically a stripped version of OpenGL 2.1 with limited FBO support. The following GL3 features are not in OpenGL ES2.0: integer texture support, native integers in shaders (including bit operations), texture buffer objects, uniform buffer objects, multiple render targets, floating point textures, transform feedback, instancing… actually what I am doing here is basically listing everything that is in GL3 that is not in GL2.
There is only one feature in GLES2.0 that is not in GL2.1: render to texture, and even at that, unextented GLES2 spec only allow one to render to mipmap level 0.
So just to repeat:
OpenGL ES 2.0= Limited FBO + GL2.1 - fixed function pipeline - complete_non-power_2_texture_support - most_read_back_from_GL
[in unextended GLES2 non-power-2 textures are supported with no mipmapping and limited texture wrap modes]
[GLES2 includes no public API points to read directly from a texture of a buffer object, in fact mapping a buffer object is an extension in GLES2 and it is write only for that matter. The only realistic way to read iamge data from a texture in GLES2 is via FBO’s+glREadPixels, but that only will work for RGB and RGBA textures]
What you can do with GLES2 (if you are into that kind of thing) is write a GLES2 application and it will mostly work in GL3 core profile… but that is not really true either as GLES2 allows one to source index and attribute data from client side memory (i.e. sourcing from buffer objects is not required).
GL ES 2.0 is GL ES 1.1 + GLSL.
GL ES 1.1 is basically a striped out version of GL 1.5.
Even the GLSL part is stripped down. The built-in crap is gone. Simplifies the driver a lot.
That’s a pretty bad description as ES2.0 is not backwards compatible to ES1.1. The fixed function pipeline is gone, among other things, while more than GLSL was added.
Like I said,
OpenGL ES 2.0= OpenGL2.1 + LimitedFBO - FixedFunctionPipeline - MipmapSupportForNonPower2Textures - MostReadBackSupport