I cannot wait for WebCL to be released as well, in the mean time how would you suggest using the image buffer in WebGL to help simulate many complicated particles?
One issue with WebCL is the device support. WebGL is capable of running of pretty much anything but WebCL (unless they decide to make a fake software version for system who don't support it in hardware) is going to be limited to a small subset of clients for a while.
I don't know if you've noticed, but most WebGL users are on personal computers and not mobile devices. The only mobile implementation I've seen is FF4Mobile and it's quite inadequate for all but the simplest WebGL programs. Most PC GPUs have had floating point readback for a few years now. Additionally, the irony of the situation is that ALL of JS numbers are doubles and ALL OpenGL ES 2 GPUs use floating point internally. It is really only the standards that have not caught up and force devs to do int-float conversion across the GPU boundary. Add to this the performance constraints of 3d rendering and any sane dev will want to do as little in JS and as much in GLSL (on GPU) as possible.
I asked Kenneth Russell, the Chrome WebGL lead, about floating point readback support at GDC and I was told that I'd "just have to do the pee-pee dance".
With this single capability, many tasks "needing" WebCL become possible with WebGL. OES_texture_float (according to WG members) only allows loading float textures, not reading out of them.
I wonder if Adobe and Microsoft know to use floating point for GPU computing? Here's hoping that a little competition fixes this blatant oversight.
This is after all version 1.0 of the standard. I don't see why 1.1 can't include optional support for OES_texture_float.
Does the iPad support it? I know a lot of android phones do too. So no reason it should be barred.
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!