5 ms·

On the one hand it's very cool to have this kind of access to the GPU from javascript, and I'm always impressed to see how creative people can be with these kin

On the one hand it's very cool to have this kind of access to the GPU from javascript, and I'm always impressed to see how creative people can be with these kinds of tools. 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.

pjmlp 11y ago
It is the second coming of VRML and if it continues doing that, it will join it. So far I haven't seen anything useful other than a quick way to prototype ES2 shaders or doing cool demos.
- Kristine1975 11y ago
  This strikes me as somewhat useful: https://googleblog.blogspot.de/2012/08/a-new-way-to-visualize-global-arms-trade.html https://googleblog.blogspot.de/2012/08/a-new-way-to-visualiz...
- bla2 11y ago
  The 3d stuff on maps.google.com is somewhat useful.
- pcwalton 11y ago
  You've complained a lot in the past that the Web lacks in hardware functionality compared to native. Now that such hardware functionality is exposed to the Web, you call it useless. Be fair. The fact is that access to OpenGL is basic functionality that any platform needs.
  - pjmlp 11y ago
    I would be fair if WebGL exposed what my GPUs are capable of.
    - pcwalton 11y ago
      WebGL 2 does. (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.)
      - pjmlp 11y ago
        Which no browser has currently. Yes I know FF has prototype of it. 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.
leohutson 11y ago
I'm actually more concerned by how easy it is to peg the GPU. The operating system does a pretty good job in controlling errant processes in general, but with GPU stuff it's easy to get your computer completely unresponsive. My android phone rebooted while trying to load one of these demos. The GPU APIs and drivers are two raw to expose to the web directly,especially compared to the way threading, networking and storage have been abstracted. Hopefully vulkan will allow for a more web suitable api to be built on top of it.
- greggman 11y ago
  I don't see how Vulkan will solve this. The problem has nothing to do with software. It has to do with the issue that GPUs are not preemptable. If you ask them to draw 100000000 fullscreen polygons they are stuck drawing 100000000 fullscreen polygons even if that will take it 30 minutes. 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
  - leohutson 11y ago
    I agree that to do it properly requires driver and hardware support. 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.
    - kig 11y ago
      The ANGLE shader compiler used in most WebGL implementations already does enforce that loops terminate. The problem is that GPUs don't / didn't have HW interrupts to allow switching between tasks. 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.)
jameshart 11y ago
Keep in mind these are generally demos that are designed to push the capabilities of shaders to the limit. Many of these things could be done more efficiently using other techniques but they're building the entire scene in a vertex shader.
- Kristine1975 11y ago
  These techniques (and others) can still be used by malicious web pages to hang browsers and possibly even crash computers if the OS reacts badly to a hanging GPU. 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.
  - greggman 11y ago
    There's absolutely no incentive to do that though. If you crash my computer you haven't stolen my passwords or got my browser history or installed a virus. All you've done is make sure I don't visit your webpage again. 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.
    - Kristine1975 11y ago
      >There's absolutely no incentive to do that though 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 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.
- radarsat1 11y ago

pjmlp 11y ago

It is the second coming of VRML and if it continues doing that, it will join it. So far I haven't seen anything useful other than a quick way to prototype ES2 shaders or doing cool demos.

Kristine1975 11y ago
This strikes me as somewhat useful: https://googleblog.blogspot.de/2012/08/a-new-way-to-visualize-global-arms-trade.html https://googleblog.blogspot.de/2012/08/a-new-way-to-visualiz...
bla2 11y ago
The 3d stuff on maps.google.com is somewhat useful.
pcwalton 11y ago
You've complained a lot in the past that the Web lacks in hardware functionality compared to native. Now that such hardware functionality is exposed to the Web, you call it useless. Be fair. The fact is that access to OpenGL is basic functionality that any platform needs.
- pjmlp 11y ago
  I would be fair if WebGL exposed what my GPUs are capable of.
  - pcwalton 11y ago
    WebGL 2 does. (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.)
    - pjmlp 11y ago
      Which no browser has currently. Yes I know FF has prototype of it. 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.

leohutson 11y ago

I'm actually more concerned by how easy it is to peg the GPU. The operating system does a pretty good job in controlling errant processes in general, but with GPU stuff it's easy to get your computer completely unresponsive. My android phone rebooted while trying to load one of these demos. The GPU APIs and drivers are two raw to expose to the web directly,especially compared to the way threading, networking and storage have been abstracted. Hopefully vulkan will allow for a more web suitable api to be built on top of it.

greggman 11y ago
I don't see how Vulkan will solve this. The problem has nothing to do with software. It has to do with the issue that GPUs are not preemptable. If you ask them to draw 100000000 fullscreen polygons they are stuck drawing 100000000 fullscreen polygons even if that will take it 30 minutes. 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
- leohutson 11y ago
  I agree that to do it properly requires driver and hardware support. 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.
  - kig 11y ago
    The ANGLE shader compiler used in most WebGL implementations already does enforce that loops terminate. The problem is that GPUs don't / didn't have HW interrupts to allow switching between tasks. 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.)

jameshart 11y ago

Keep in mind these are generally demos that are designed to push the capabilities of shaders to the limit. Many of these things could be done more efficiently using other techniques but they're building the entire scene in a vertex shader.

Kristine1975 11y ago
These techniques (and others) can still be used by malicious web pages to hang browsers and possibly even crash computers if the OS reacts badly to a hanging GPU. 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.
- greggman 11y ago
  There's absolutely no incentive to do that though. If you crash my computer you haven't stolen my passwords or got my browser history or installed a virus. All you've done is make sure I don't visit your webpage again. 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.
  - Kristine1975 11y ago
    >There's absolutely no incentive to do that though 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 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.
radarsat1 11y ago