4 ms·

Seems quite Vulkan-y. I'm interested to see how far the support with this one gets. Also, I'm not really pleased with the Apple-platform and Metal choices.

favorited 10y ago
For the record, they said in their announcement[0] that they "expect the discussions around the shading language to be one of the most fun parts of the standardization process, and look forward to hearing community opinions. For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now." Since this is a prototype, they're just going with the shader language they prefer for now. [0]https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...
- nice_byte 10y ago
  I hope they won't do something daft like turning javascript into a shading language or something
  - om2 10y ago
    We'll probably look at existing cross-platform binary shader formats like SPIR-V, or alternately consider something based on Web Assembly.
    - nice_byte 10y ago
      The first option sounds great, it lets you potentially re-use the same shader binary. Out of curiosity, what benefit does the webassembly approach have? Wouldn't have to be translated by the runtime into something the driver supports (i.e. spir-v) anyway? I realize you probably want to abstract away the differences between Metal's shader IR and SPIR-V, but i think you could realistically translate from SPIR-V to metal IR, while letting other platforms use SPIR-V directly.
      - om2 10y ago
        WebAssembly has solved the problem of validating for memory-safety and other requirements of web safety and security. SPIR-V has not. SPIR-V is known usable as a shader format and can be used directly with some APIs (which then translate into the native format for the GPU at some level), but WebAssembly has no such proof of concept. So on these two paths, the big challenges would be: - For WebAssembly: translate into an underlying format understood by the driver (could be SPIR-V or directly to something closer to the metal); and possibly add some primitives, e.g. for SIMD - For SPIR-V: invent a set of restrictions plus an efficient runtime validation mechanism to guarantee memory safety, plus translators on systems that don't natively support SPIR-V. (Even Web-safe SPIR-V to Vulkan-native SPIR-V might need translation, e.g. to remove bounds checks that have to be there to pass validation but that can be proven to be safely removable for efficiency.) Either way you need to produce a toolchain to produce the special format as well, a vanilla SPIR-V toolchain won't necessarily guarantee you can output web-safe SPIR-V. So in fact you won't be able to just use the same shader binary. An additional consideration: given the approach of modern GPU APIs, you're very likely to want to deal with the same data structures in the same memory layout from both your CPU code and your GPU code. It could be convenient to arrange this by targeting WebAssembly for both your CPU code and your GPU code. That said, we're very very early in exploring this question.
        nice_byte 10y ago
        Thanks for the explanation!
Teknoman117 10y ago
The API appears to be a near clone of the Metal API.
- johncolanduoni 10y ago
  Metal on iOS is pretty Vulkan-y, somewhat less so on desktop. I don't love that Apple won't implement Vulkan on their platforms, but I think if you take the Vulkan API and make it object oriented (which is IMHO a good approach for JavaScript) you're going to get something that is reminiscent of Metal anyway.
  - kvark 10y ago
    Vulkan IS object-oriented, it's just specified as C API.
    - johncolanduoni 10y ago
      By "make object oriented" I mean converting functions that return VkResult to functions that throw exceptions, returning instead of using out pointers, converting vkCreate* to constructors, automating destruction, etc. You're absolutely right that there's no heavy lifting or abstraction involved, like there is when you want to make an object oriented OpenGL wrapper.

favorited 10y ago

For the record, they said in their announcement[0] that they "expect the discussions around the shading language to be one of the most fun parts of the standardization process, and look forward to hearing community opinions. For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now." Since this is a prototype, they're just going with the shader language they prefer for now. [0]https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/ https://webkit.org/blog/7380/next-generation-3d-graphics-on-...

nice_byte 10y ago
I hope they won't do something daft like turning javascript into a shading language or something
- om2 10y ago
  We'll probably look at existing cross-platform binary shader formats like SPIR-V, or alternately consider something based on Web Assembly.
  - nice_byte 10y ago
    The first option sounds great, it lets you potentially re-use the same shader binary. Out of curiosity, what benefit does the webassembly approach have? Wouldn't have to be translated by the runtime into something the driver supports (i.e. spir-v) anyway? I realize you probably want to abstract away the differences between Metal's shader IR and SPIR-V, but i think you could realistically translate from SPIR-V to metal IR, while letting other platforms use SPIR-V directly.
    - om2 10y ago
      WebAssembly has solved the problem of validating for memory-safety and other requirements of web safety and security. SPIR-V has not. SPIR-V is known usable as a shader format and can be used directly with some APIs (which then translate into the native format for the GPU at some level), but WebAssembly has no such proof of concept. So on these two paths, the big challenges would be: - For WebAssembly: translate into an underlying format understood by the driver (could be SPIR-V or directly to something closer to the metal); and possibly add some primitives, e.g. for SIMD - For SPIR-V: invent a set of restrictions plus an efficient runtime validation mechanism to guarantee memory safety, plus translators on systems that don't natively support SPIR-V. (Even Web-safe SPIR-V to Vulkan-native SPIR-V might need translation, e.g. to remove bounds checks that have to be there to pass validation but that can be proven to be safely removable for efficiency.) Either way you need to produce a toolchain to produce the special format as well, a vanilla SPIR-V toolchain won't necessarily guarantee you can output web-safe SPIR-V. So in fact you won't be able to just use the same shader binary. An additional consideration: given the approach of modern GPU APIs, you're very likely to want to deal with the same data structures in the same memory layout from both your CPU code and your GPU code. It could be convenient to arrange this by targeting WebAssembly for both your CPU code and your GPU code. That said, we're very very early in exploring this question.
      - nice_byte 10y ago
        Thanks for the explanation!

Teknoman117 10y ago

The API appears to be a near clone of the Metal API.

johncolanduoni 10y ago
Metal on iOS is pretty Vulkan-y, somewhat less so on desktop. I don't love that Apple won't implement Vulkan on their platforms, but I think if you take the Vulkan API and make it object oriented (which is IMHO a good approach for JavaScript) you're going to get something that is reminiscent of Metal anyway.
- kvark 10y ago
  Vulkan IS object-oriented, it's just specified as C API.
  - johncolanduoni 10y ago
    By "make object oriented" I mean converting functions that return VkResult to functions that throw exceptions, returning instead of using out pointers, converting vkCreate* to constructors, automating destruction, etc. You're absolutely right that there's no heavy lifting or abstraction involved, like there is when you want to make an object oriented OpenGL wrapper.