OES extensions in NVIDIA 280.xx Beta

The 280.xx beta release lists a number of OES extensions, the ones I am staring at are: GL_OES_texture_float and
GL_OES_texture_half_float. The question I have is that in OpenGL ES2, the “type storage” of a texture (i.e. uint8, float, etc) is determined by the format in which the texture data is specified [i.e. the 8th and 8th arguments of glTexImage2D(GLenum target, GLint level, GLint internalformat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, const GLvoid * data) ] where as in OpenGL the “type storage” is determined by the 3 parameter, internalformat. What is the expected interaction behavior of the floating point OES extensions in non-ES OpenGL? [Also note that GL_HALF_FLOAT_OES is 0x8D61 where as GL_HALF_FLOAT is 0x140B].

Actually, that’s not quite true (even though it’s what most implementations do):

True, very true. Also horribly in GLES2 internalFormat and format must be identical and one of GL_RGBA, GL_RGB, GL_LUMINANCE, GL_ALPHA or GL_LUMINANCE_ALPHA. However there is this little nugget from the man pages of glTexImage2D [http://www.khronos.org/opengles/sdk/docs/man/]:

so basically, a GLES2 implementation deserves to be frowned upon deeply if it chooses an internal format that does not match type. Oh well, though back to my question of GL_OES_texture_float and GL_OES_texture_half_float in the NVIDIA driver: if one passes GL_FLOAT or GL_OES_HALF_FLOAT for the type parameter and GL_RGBA for both internalFormat and format, does that make the texture a floating point (respectively half-floating point) texture?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.