6 ms·

For folks curious about WebGL in a Vulkan world, there's https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/Khr

For folks curious about WebGL in a Vulkan world, there's https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... .

kllrnohj 9y ago
Not to be overly harsh about their work but that just screams "me too!" instead of solving an actual problem. Vulkan is a low-level, highly verbose API designed to extract maximum performance and leverage multiple threads to deal with slower aspects of rendering. Then you chuck that into a single-threaded, slow (relatively) runtime where method calls to the actual implementation are particularly expensive (JavaScript -> native transitions ain't cheap), and that's supposed to be a good idea? Why? Who is supposed to use this for anything useful? Instead of just porting native features to the web for the sake of porting them make it easier to make use of the hardware's capabilities. Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. That'd be cool and potentially useful instead of a system where you can port some game to the web for the sake of porting it to the web where nobody will ever use it because it sucks compared to the vastly superior native version of the game.
- pshc 9y ago
  I imagine the next step is to provide a WebAssembly binding. edit: "The API has to execute efficiently on WebAssembly and in multi-threaded environment. That means no GC allocations during the rendering loop in order to avoid the garbage collection pauses."
  - kllrnohj 9y ago
    Well WebAssembly is another thing I'd question the usefulness of. It's going to result in threading finally coming to JS which is nice, but the rest of it is more like a showing of of technical infrastructure for the sake of it instead of helping apps with problems they have.
    - pshc 9y ago
      I would argue that having to write apps in JS, or transpiling to the JS runtime, is a problem for many people.
      - kllrnohj 9y ago
        Sure but you could imagine something more like a .NET or JVM bytecode instead, which would be a more practical target for transpiled web apps instead of webasm. Instead we ended up with a stack machine & sbrk.
        pshc 9y ago
        But in what sense would an extra VM layer be more practical? Maybe this is where we disagree. I'm not fond of VMs, especially those two. C++ or Rust -> wasm bytecode is great. Soon we'll be writing directly to command buffers, no fuss.
        kllrnohj 9y ago
        If you want to do C++/Rust direct to command buffers why on earth would you bother with the pile of overhead that is a modern web browser? But ~nobody wants to build UIs like that anyway, so what's your target audience?
        pshc 9y ago
        Games and other 3D applications? Getting people in-game (say a lazily loaded demo with slightly less perf) with one click is huge.
        kllrnohj 9y ago
        No, it isn't. Games are already served by consoles first (which obviously won't run webasm), and steam second. There's no market there, and it's already one-click to launch steam to the game in question. Where it will then download in a medium suitable to handling the downloading & updating of a game's assets instead (which, even for a demo, is in the gigabyte range - you aren't lazy loading this). As for 3D applications what 3D applications? Do you really think Maya is going to be ported to a browser? Why would they bother? Why would they restrict themselves like that? The web has no advantages in this space, and the needs of those markets is already being served with superior technology and infrastructure.
- pcwalton 9y ago
  > Then you chuck that into a single-threaded, slow (relatively) runtime Slow relative to C++, sure. But JS is very fast relative to pretty much any other widely used dynamic language. If we should expose Vulkan bindings to dynamic languages (and why not?) JS is the obvious first choice for a target, given its speed and popularity. > JavaScript -> native transitions ain't cheap They're actually very cheap nowadays, because so many benchmarks stress the DOM and C++-implemented builtins. Driver calls, even with Vulkan, far exceed the cost of JS-to-native transitions. glDrawElements() is probably at least 100x slower than a JS-to-native call, the latter of which has latencies measured in nanoseconds. > Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. Please, let's not. This will neither be good for designers (modern GPU programming has an enormous learning curve compared to CSS) nor browser developers (shaders would break batching and would expose too many engine-specific internal details).
  - pandaman 9y ago
    I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a command buffer at the end of frame). Nevertheless, even if some implementations actually do call driver, the GP's point is that the whole point of Vulkan is getting rid of global state to allow parallel command buffer creation. JS is single threaded so, no matter how cheap or expensive the calls are, you won't be able to take advantage of Vulkan since you are running just one thread.
    - nhaehnle 9y ago
      Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...

kllrnohj 9y ago

Not to be overly harsh about their work but that just screams "me too!" instead of solving an actual problem. Vulkan is a low-level, highly verbose API designed to extract maximum performance and leverage multiple threads to deal with slower aspects of rendering. Then you chuck that into a single-threaded, slow (relatively) runtime where method calls to the actual implementation are particularly expensive (JavaScript -> native transitions ain't cheap), and that's supposed to be a good idea? Why? Who is supposed to use this for anything useful? Instead of just porting native features to the web for the sake of porting them make it easier to make use of the hardware's capabilities. Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. That'd be cool and potentially useful instead of a system where you can port some game to the web for the sake of porting it to the web where nobody will ever use it because it sucks compared to the vastly superior native version of the game.

pshc 9y ago
I imagine the next step is to provide a WebAssembly binding. edit: "The API has to execute efficiently on WebAssembly and in multi-threaded environment. That means no GC allocations during the rendering loop in order to avoid the garbage collection pauses."
- kllrnohj 9y ago
  Well WebAssembly is another thing I'd question the usefulness of. It's going to result in threading finally coming to JS which is nice, but the rest of it is more like a showing of of technical infrastructure for the sake of it instead of helping apps with problems they have.
  - pshc 9y ago
    I would argue that having to write apps in JS, or transpiling to the JS runtime, is a problem for many people.
    - kllrnohj 9y ago
      Sure but you could imagine something more like a .NET or JVM bytecode instead, which would be a more practical target for transpiled web apps instead of webasm. Instead we ended up with a stack machine & sbrk.
      - pshc 9y ago
        But in what sense would an extra VM layer be more practical? Maybe this is where we disagree. I'm not fond of VMs, especially those two. C++ or Rust -> wasm bytecode is great. Soon we'll be writing directly to command buffers, no fuss.
        kllrnohj 9y ago
        If you want to do C++/Rust direct to command buffers why on earth would you bother with the pile of overhead that is a modern web browser? But ~nobody wants to build UIs like that anyway, so what's your target audience?
        pshc 9y ago
        Games and other 3D applications? Getting people in-game (say a lazily loaded demo with slightly less perf) with one click is huge.
        kllrnohj 9y ago
        No, it isn't. Games are already served by consoles first (which obviously won't run webasm), and steam second. There's no market there, and it's already one-click to launch steam to the game in question. Where it will then download in a medium suitable to handling the downloading & updating of a game's assets instead (which, even for a demo, is in the gigabyte range - you aren't lazy loading this). As for 3D applications what 3D applications? Do you really think Maya is going to be ported to a browser? Why would they bother? Why would they restrict themselves like that? The web has no advantages in this space, and the needs of those markets is already being served with superior technology and infrastructure.
pcwalton 9y ago
> Then you chuck that into a single-threaded, slow (relatively) runtime Slow relative to C++, sure. But JS is very fast relative to pretty much any other widely used dynamic language. If we should expose Vulkan bindings to dynamic languages (and why not?) JS is the obvious first choice for a target, given its speed and popularity. > JavaScript -> native transitions ain't cheap They're actually very cheap nowadays, because so many benchmarks stress the DOM and C++-implemented builtins. Driver calls, even with Vulkan, far exceed the cost of JS-to-native transitions. glDrawElements() is probably at least 100x slower than a JS-to-native call, the latter of which has latencies measured in nanoseconds. > Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. Please, let's not. This will neither be good for designers (modern GPU programming has an enormous learning curve compared to CSS) nor browser developers (shaders would break batching and would expose too many engine-specific internal details).
- pandaman 9y ago
  I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a command buffer at the end of frame). Nevertheless, even if some implementations actually do call driver, the GP's point is that the whole point of Vulkan is getting rid of global state to allow parallel command buffer creation. JS is single threaded so, no matter how cheap or expensive the calls are, you won't be able to take advantage of Vulkan since you are running just one thread.
  - nhaehnle 9y ago
    Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...