On the other hand it's a little disappointing to see WebGL completely peg the CPU running stuff that wouldn't cause it to break a sweat running native.
Most modern OSes monitor the GPU and if it doesn't return in a few seconds they reboot the GPU. Windows started doing that in Windows 7. OSX not until recently. Not sure if Linux does it.
The only real solution is someone making preemptable GPUs
However, it's already possible to have fairly granular control over compute resources with CUDA for example, and also to run streams of commands concurrently, so that would solve part of the problem.
The other part of the problem that could be solved by vulkan is the browser taking control of compilation, which allows for more static checking and refusal of possibly unterminated loops.
It's not easily solvable by a super-powered compiler either. Sure, you could write your own compute-driven preemptive graphics pipeline and break execution after every X billion simulated instructions & random memory accesses. You'd have to do reanalysis on every frame too, due to changing shader inputs.
The computation done is roughly (number of vertices * vertex shader compute time) + (number of pixels falling under the vertex primitives * fragment shader compute time). The shader compute times are the sums of instruction execution times + data fetch times. Then take into account early exits, data access patterns and cache sizes (otherwise the compiler'll think that e.g. a simple greyscaling fragment shader is going to cause a random memory access for every pixel and take forever to run, causing the compiler to spread the shader execution across multiple frames and kill performance dead.)
I recall people discussing Bitcoin miners implemented in Javascript and executed on the machines of unsuspecting visitors of a web page. Maybe WebGL could be used for something similar?
And of course there's the fact that suddendly GPU drivers are exposed to untrusted input from the internet via GLSL shaders.
As for GPU drivers being exposed WebGL is designed to cover that. Every input is checked, every bounds checked, shaders are re-written and drivers with bugs either worked around or banned.
But there is: Lulz.
>Every input is checked, every bounds checked
That would require solving the Halting Problem. The WebGL spec even says: https://www.khronos.org/registry/webgl/specs/latest/1.0/#4.4
>In the general case it is not possible to impose limits on the structure of incoming shaders to guard against this problem. Experimentation has shown that even very strict structural limits are insufficient to prevent long rendering times, and such limits would prevent shader authors from implementing common algorithms.
So far I haven't seen anything useful other than a quick way to prototype ES2 shaders or doing cool demos.
The fact is that access to OpenGL is basic functionality that any platform needs.
(Also, the state of graphics drivers is extremely bad; even if your GPU claims to be capable of OpenGL 3+, it may crash the entire OS when you attempt to use it. Rollout of new GL features in a secure, sandboxed environment is quite tough and takes time.)
And on mobile, I am yet to have WebGL working properly without transforming it into a cook plate, when I don't get a black screen.
Meanwhile they do OpenGL ES 3.x without any issues while keeping a reasonable temperature.
And when WebGL 2.0 finally gets out across all devices, we will be doing Metal, Vulkan and DX12 already.