Original discussion on mailing list:
Essentially, for the purposes of testing code in an ES3 context as it would be run on an ES2 context (that is, taking the paths the code would take based on the extensions present on ES2), it would be nice if the ES3 context exposed OES_texture_float and OES_texture_half_float.
The current ES3 context on this hardware exposes GL_EXT_texture_rg and GL_EXT_color_buffer_float, and can therefore definitely support OES_texture_float and OES_texture_half_float. All that would (apparently) be required would be for floating point textures to be specified in an ES2 compatible manner (with format and internalformat set to GL_RED|GL_RG, and type set to GL_FLOAT).
Thread actually started here:
(In reply to comment #1)
> Thread actually started here:
You will need to patch the Mesa source code. It should be trivial though, because the functionality is already implemented.
The Mesa core support was added in this commit:
Author: Kalyan Kondapally <email@example.com>
Date: Wed Jan 7 20:30:25 2015 -0800
Mesa: Add support for GL_OES_texture_*float* extensions.
This patch series adds support for following GLES2 Texture Float extensions:
Gallium drivers just need to enable the extensions now.
Is anything holding off r600 from using it ? I was just trying to see http://madebyevan.com/webgl-water/ WebGL demo and was surprised that recent Mesa 10.6 doesn't have OES_texture_float while having GL_ARB_texture_float.
Added in 44dc1d307d7eacef0d6f1618ba0fb7f62e08f8. Closing.
on Feb 19, 2017 at 11:47:19.
(provided by the Example extension).