Using HTML5 WebGL Shaders for Computation

skeggse picture skeggse · Sep 14, 2011 · Viewed 11.2k times · Source

It seems to me like one could theoretically use WebGL for computation--such as computing primes or π or something along those lines. However, from what little I've seen, the shader itself isn't written in Javascript, so I have a few questions:

  1. What language are the shaders written in?
  2. Would it even be worthwhile to attempt to do such a thing, taking into account how shaders work?
  3. How does one pass variables back and forth during runtime? Or if not possible, how does one pass information back after the shader finishes executing?
  4. Since it isn't Javascript, how would one handle very large integers (BigInteger in Java or a ported version in Javascript)?
  5. I would assume this automatically compiles the script so that it runs across all the cores in the graphics card, can I get a confirmation?

If relevant, in this specific case, I'm trying to factor fairly large numbers as part of a [very] extended compsci project.

EDIT:

  1. WebGL shaders are written in GLSL.

Answer

Adrian Seeley picture Adrian Seeley · Mar 12, 2014

I've used compute shaders from JavaScript in Chrome using WebGL to solve the travelling salesman problem as a distributed set of smaller optimization problems solved in the fragment shader, and in a few other genetic optimization problems.

Problems:

  1. You can put floats in (r: 1.00, g: 234.24234, b: -22.0) but you can only get integers out (r: 255, g: 255, b: 0). This can be overcome by encoding a single float into 4 integers as an output per fragment. This is actually so heavy an operation that it almost defeats the purpose for 99% of problems. Your better to solve problems with simple integer or boolean sub-solutions.

  2. Debugging is a nightmare of epic proportions and the community is at the time of writing this actively.

  3. Injecting data into the shader as pixel data is VERY slow, reading it out is even slower. To give you an example, reading and writing the data to solve a TSP problem takes 200 and 400 ms respectively, the actual 'draw' or 'compute' time of that data is 14 ms. In order to be usable your data set has to be large enough in the right way.

  4. JavaScript is weakly typed (on the surface...), whereas OpenGL ES is strongly typed. In order to interoperate we have to use things like Int32Array or Float32Array in JavaScript, which feels awkward and constraining in a language normally touted for it's freedoms.

  5. Big number support comes down to using 5 or 6 textures of input data, combining all that pixel data into a single number structure (somehow...), then operating on that big number in a meaningful way. Very hacky, not at all recommended.