Hello guys. I've been working on the scrypt WebGL miner, and in this thread I want to describe what I've achieved and what are actual problems.
First of all, check the Demo:
http://kukunin.github.io/webgl-scrypt/. Open the browser's Console to see the output. If you see all sections matched - it works for you fine.
The code is open-sourced, under GPLv2 license. You can play with it, improve, distribute etc. Just keep sources opened.
Source code:
https://github.com/Kukunin/webgl-scryptThe short status project:- it works
- it is slow (20 hashes per second)
- it is totally unoptimized (there is big field of optimizations available).
- works good in Google Chrome only (yet)
Tested on:- AMD 7970 - fine
- Intel HD 4400 - some weird lines every ~30pixels
How it works?It uses common GPGPU principles to calculate the hash. Textures are used as input data, as intermediate data and as result data. Due the GPU limitation to read/write to the same texture at the same time, I use textures ping-pong technique. Swapping textures is the most expensive operation (due the JS profiler). There are about 150,000 of swap texture operations per one hash round.
Each hash requires 33012 pixels (~128kB of memory), 1024x1024 texture can contain 31 hashes, but 4096x4096 texture can contain up to 508 hashes.
My AMD 7970 renders 4096x4096 (508 hashes) texture for about 30 seconds (so, speed is ~17h/s), while Intel HD 4400 does for about 300 seconds.
What to expect?It seems, that it is impossible to achieve real good speed with WebGL at this time, due to limitation of specification (OpenGL ES 2.0). The maximum, I think, is tens of kilohashes on top AMD cards.
Shader programs too small, it is necessary to do a lot of render rounds (and texture swaps), there isn't native bit operations etc.
Next WebGL2
http://www.khronos.org/registry/webgl/specs/latest/2.0 specification, it seems, willn't provide too more possibilities to speed up the hashes. The best solution is arb_compute_shader extensions, which is available in OpenGL ES 3.1 specification (I don't know when it will be implement in browsers).
Another possible way is to use WebCL
https://www.khronos.org/webcl/, but it is supported only in Firefox with Nokia WebCL extensions.
Optimizations (*updated 08/20/2014*)I've tried to play with different optimizations - framebufferTexture2D vs bindFramebuffer, avoid unnecessary calls etc, but it doesn't affects much. There are 156927 texture swaps per round and 155649 from them is to calculate salsa8. So, it is needed to drop support for weak cards (as my Intel HD 4400), and reduce texture swap and render rounds by increasing the complexity of shaders itself.
Please, test the stuff, review the code, advice me about OpenGL optimizations etc, fork, send patches, pull requests etc.
Donations are appreciated: LQ9tgNSH6DD65YNyFmaYCALLiCiD9CsuUf, 1CxH5stQmg3Lbw1fFyb88UbxLd54unH7Hu
