10 ms·

Show HN: Vulkan bindings for JavaScript

77 points by Schampu 8y ago

Yoric 8y ago
Pretty cool!
TekMol 8y ago
Is there a benefit of using Vulkan over WebGL? I would think you can achieve similar speed using WebGL in the browser and then have all the comfortable functionality of the browser for free.
- maeln 8y ago
  This is for Node.js, so it's for desktop app, not web app (it's not possible to use Vulkan on the Web). For the web, you have no choice but to use WebGL.
  - paraboul 8y ago
    The future is WebGPU. If you're interested on why a Vulkan binding for the web is not a good idea, I found this doc (from two engineers working at Google) quite interesting : https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGUWv_JrkpGizDN0bNq7wY/edit# https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU...
    - maeln 8y ago
      Thank you for the document ! Definitely, having some form of GPGPU on the web is the next step. It is currently one of my few complaint with WebGL: The lack of compute shader.
      - fulafel 8y ago
        You can do GPU compute without the OpenGL "compute shader" feature. WebGL 2 has much improved features for it vs WebGL 1. There are existing GPGPU things running on WebGL, see eg https://github.com/tensorflow/tfjs-core https://github.com/tensorflow/tfjs-core and https://magenta.tensorflow.org/demos/#web-apps https://magenta.tensorflow.org/demos/#web-apps
        maeln 8y ago
        But WebGL compute shader are under an extension which, as far as I know, doesn't have much support yet :/
      - bitwize 8y ago
        The next step in what, exactly? The major thing I see GPGPU being used for on the Web is to mine cryptocurrency using your viewers' hardware in lieu of (or, more likely, as a supplement to) ads.
        maeln 8y ago
        A lot of modern 3D engine use compute shader to do a lot of different things. For example, I use it to process millions of particles, which wouldn't be possible without it.
    - slavik81 8y ago
      > The future is WebGPU I hope not. The proposed standard was not even remotely vendor-neutral. I would love to have compute shaders in WebGL. All it would require is bumping the OpenGL version that WebGL is based on from ES 3.0 to ES 3.1 in the next revision. As far as I can tell, that will not happen because it would reduce the need for the WebGPU proposal. Needless to say, I find the situation very annoying.
      - Jasper_ 8y ago
        > I hope not. The proposed standard was not even remotely vendor-neutral. Why not? WebGPU work continues here, based on the work that Apple proposed. Google has a cross-platform prototype implementation. https://github.com/gpuweb/gpuweb https://github.com/gpuweb/gpuweb > I would love to have compute shaders in WebGL. All it would require is bumping the OpenGL version that WebGL is based on from ES 3.0 to ES 3.1 in the next revision. WebGL2 has very little vendor support already, and OpenGL is a dead end, from an API perspective. Something low-ish like Metal without being as absurd as Vulkan would be a great fit for the web.
        slavik81 8y ago
        There's room to develop a new API that's a lot better than WebGL. I just don't think we'll get the best result from a standards process driven by realpolitik.
AnonymousMouse 8y ago
What is the point of using a low overhead graphics API like Vulkan if you're just gonna crush performance with JavaScript?
- paraboul 8y ago
  The point of using APIs like WebGL or Vulkan is precisely to move work from the CPU (JavaScript) to the GPU. The call from JavaScript to native (the binding from v8 to C++), has itself a very low overhead
  - Narishma 8y ago
    That's not what the parent was asking.
    - paraboul 8y ago
      I'm saying that, I don't see how JavaScript could crush the performance of few native API calls. It's like saying "I don't see why WebGL exists because JavaScript is slow"
      - royjacobs 8y ago
        No, that's precisely what the original question is trying to address: Why not keep using WebGL since the bottleneck in a graphical application running in Javascript is likely NOT going to be WebGL, but Javascript itself.
        talldan 8y ago
        These bindings are for node.js, not for the web.
        hwillis 8y ago
        Because thats a totally arbitrary statement and it's also not really true. It's pretty trivial to swamp the GPU, even if you know what you're doing. If you want to show something big/complex or very pretty, or even just novel rendering that will stress the GPU (raymarching, scattering), the CPU will be waaaaay less burdened. CPU bottlenecking is an issue in videogames where the main loop is usually handling a massive amount of computation, doing its own intersection checks, etc. Etc. Plus any other processes queuing sounds, running physics etc. There are just a few cores doing a huge amount of work. Its still relatively easy to swamp the CPU in javascript (webworkers and async obviously help), but if youre just piping orders to the GPU then any CPU can easily max out the abilities even on high end cards. In most cases that's basically what webgl is used for, AFAIK. How many full on ai and physics heavy games are there? Webgl games tend to be lighter, and are very often accessible ways to play with interesting shaders. The use case tends towards GPU bound.

77 points by Schampu 8y ago

Pretty cool!

Is there a benefit of using Vulkan over WebGL? I would think you can achieve similar speed using WebGL in the browser and then have all the comfortable functionality of the browser for free.

maeln 8y ago
This is for Node.js, so it's for desktop app, not web app (it's not possible to use Vulkan on the Web). For the web, you have no choice but to use WebGL.
- paraboul 8y ago
  The future is WebGPU. If you're interested on why a Vulkan binding for the web is not a good idea, I found this doc (from two engineers working at Google) quite interesting : https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGUWv_JrkpGizDN0bNq7wY/edit# https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU...
  - maeln 8y ago
    Thank you for the document ! Definitely, having some form of GPGPU on the web is the next step. It is currently one of my few complaint with WebGL: The lack of compute shader.
    - fulafel 8y ago
      You can do GPU compute without the OpenGL "compute shader" feature. WebGL 2 has much improved features for it vs WebGL 1. There are existing GPGPU things running on WebGL, see eg https://github.com/tensorflow/tfjs-core https://github.com/tensorflow/tfjs-core and https://magenta.tensorflow.org/demos/#web-apps https://magenta.tensorflow.org/demos/#web-apps
      - maeln 8y ago
        But WebGL compute shader are under an extension which, as far as I know, doesn't have much support yet :/
    - bitwize 8y ago
      The next step in what, exactly? The major thing I see GPGPU being used for on the Web is to mine cryptocurrency using your viewers' hardware in lieu of (or, more likely, as a supplement to) ads.
      - maeln 8y ago
        A lot of modern 3D engine use compute shader to do a lot of different things. For example, I use it to process millions of particles, which wouldn't be possible without it.
  - slavik81 8y ago
    > The future is WebGPU I hope not. The proposed standard was not even remotely vendor-neutral. I would love to have compute shaders in WebGL. All it would require is bumping the OpenGL version that WebGL is based on from ES 3.0 to ES 3.1 in the next revision. As far as I can tell, that will not happen because it would reduce the need for the WebGPU proposal. Needless to say, I find the situation very annoying.
    - Jasper_ 8y ago
      > I hope not. The proposed standard was not even remotely vendor-neutral. Why not? WebGPU work continues here, based on the work that Apple proposed. Google has a cross-platform prototype implementation. https://github.com/gpuweb/gpuweb https://github.com/gpuweb/gpuweb > I would love to have compute shaders in WebGL. All it would require is bumping the OpenGL version that WebGL is based on from ES 3.0 to ES 3.1 in the next revision. WebGL2 has very little vendor support already, and OpenGL is a dead end, from an API perspective. Something low-ish like Metal without being as absurd as Vulkan would be a great fit for the web.
      - slavik81 8y ago
        There's room to develop a new API that's a lot better than WebGL. I just don't think we'll get the best result from a standards process driven by realpolitik.

AnonymousMouse 8y ago

What is the point of using a low overhead graphics API like Vulkan if you're just gonna crush performance with JavaScript?

paraboul 8y ago
The point of using APIs like WebGL or Vulkan is precisely to move work from the CPU (JavaScript) to the GPU. The call from JavaScript to native (the binding from v8 to C++), has itself a very low overhead
- Narishma 8y ago
  That's not what the parent was asking.
  - paraboul 8y ago
    I'm saying that, I don't see how JavaScript could crush the performance of few native API calls. It's like saying "I don't see why WebGL exists because JavaScript is slow"
    - royjacobs 8y ago
      No, that's precisely what the original question is trying to address: Why not keep using WebGL since the bottleneck in a graphical application running in Javascript is likely NOT going to be WebGL, but Javascript itself.
      - talldan 8y ago
        These bindings are for node.js, not for the web.
      - hwillis 8y ago
        Because thats a totally arbitrary statement and it's also not really true. It's pretty trivial to swamp the GPU, even if you know what you're doing. If you want to show something big/complex or very pretty, or even just novel rendering that will stress the GPU (raymarching, scattering), the CPU will be waaaaay less burdened. CPU bottlenecking is an issue in videogames where the main loop is usually handling a massive amount of computation, doing its own intersection checks, etc. Etc. Plus any other processes queuing sounds, running physics etc. There are just a few cores doing a huge amount of work. Its still relatively easy to swamp the CPU in javascript (webworkers and async obviously help), but if youre just piping orders to the GPU then any CPU can easily max out the abilities even on high end cards. In most cases that's basically what webgl is used for, AFAIK. How many full on ai and physics heavy games are there? Webgl games tend to be lighter, and are very often accessible ways to play with interesting shaders. The use case tends towards GPU bound.