This is really nice! The same techniques can be used in WebGL 2.0 which is at ES 3.1 on canary versions of WebKit. I had a hell of a time using the experimental compute shader API to implement a cellular automata framework [1]
The big issue with using WebGL at the current moment, to do large scale sims, is that fragment shaders dont have an entire workload barrier capability - so you cant do interdependent work.
Compute shaders have full workload execution and memory barriers.
Just something to be aware of if you are trying to jerry rig fragment shaders to do more advanced things like HDR via min/max over all colors..there is no way to these kind of aggregates without calling the shader twice, unfortunately.
(I didn't know it was on the horizon until I saw your link). I wonder if getting to ES 3.2 is on the horizon as well? That would bring geometry and tessellation shader support.
> Using geometry shading will generally lead to worse performance, high memory bandwidth, and increased system power consumption. Assert if geometry shaders are used
Geometry shaders are not what you want. They should not have been included in GL ES, and I will fight their inclusion into WebGL 2.1.
Tessellation shaders are better, but still kinda ultimately useless.
Yes, I agree the performance is an issue in most use cases, but wouldn't you agree there is value in there being parity between WebGL and OpenGL ES? It's valuable for those of us who work with Emscripten to cross-compile apps for the web.
The big issue with using WebGL at the current moment, to do large scale sims, is that fragment shaders dont have an entire workload barrier capability - so you cant do interdependent work.
Compute shaders have full workload execution and memory barriers.
Just something to be aware of if you are trying to jerry rig fragment shaders to do more advanced things like HDR via min/max over all colors..there is no way to these kind of aggregates without calling the shader twice, unfortunately.
[1] https://github.com/churchofthought/Grautamaton