4 ms·

I hope they won't do something daft like turning javascript into a shading language or something

om2 9y 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 9y 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 9y 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 9y ago
      Thanks for the explanation!

om2 9y 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 9y 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 9y 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 9y ago
    Thanks for the explanation!