Sorry if what I wrote was unclear. OES_texture_float is a current WebGL extension that is implemented by several browsers. The issue is that OES_texture_float

Sorry if what I wrote was unclear. OES_texture_float is a current WebGL extension that is implemented by several browsers. The issue is that OES_texture_float does not specify readPixels support. As far as I can tell, even with native OpenGL ES 2, there is no extension that specifies readPixels functionality for floating point textures. I believe this is a bug in the OES_texture_float specification as binding a texture format to a texture engine is entirely type-level and no types are required after the resource is bound. If there is a hardware limitation, you're doing it wrong. So the current state of support is: some browsers implement OES_texture_float and you can load floating point textures. Some browsers, when you have enabled OES_texture_float, also allow writing floating point textures. Unfortunately, the only thing you can do with a written floating point texture is re-read it in a later vertex (if you can get vertex texture fetch support which is still lacking for WebGL on Windows due to DirectX impedance mismatch) or fragment shader. If you want to read back the results of your float computations, you have to pack them into 4 x 1 byte pixel color channels and then unpack them on the javascript side back into floats. Of course, when converting the GPU native floating point values into color channel integers, implementations "helpfully" clamp to [0..1] and then multiply by 255 (!) so that 0 -> 0 and 1 -> 255. This plays havoc with floating point precision as 255 is not exactly representable. Complicating matters further, ES2 and its corresponding GLSL have no provision for integer or bitwise operations and so the implementor is reduced to using floating point operations to pack floating point values into 4 [0..1]-values that then get molested into 4 byte arrays which can then be read back into Javascript which can then waste browser/CPU time rebuilding floating point values from pixel byte channels with accompanying (technologically unnecessary) numeric noise. I've not seen any WebGL implementation running on the iPad and Apple won't say anything about it. If I had to guess, I'd say that WebGL is attractive to Apple in the HTML5 sense but not in protecting their native application advantage. The Steve will probably decree that native 3d apps have superior performance by virtue of not being written in a sloppy, GC'ed language and run in a giant sandbox. I don't think native iOS apps allow float texture read-back, either. The real question is: Is WebGL's lowest-common denominator (phones) approach to 3d a bug or a feature? On the bug side, it's absurd that I can't read float values off of my desktop GPU in 2011. On the feature side, it means that even your iPhone 3G will be able to poorly execute and render a WebGL application at an unbearably low framerate!