4 ms·

So what are you saying here? WebGPU should have been just Apple Metal?

masklinn 6y ago
> we've all been here before and it's very very hard, at the very least, get some IHVs or at least a team that does port work / emulation tech on board
kevingadd 6y ago
There were working SPIR-V+WebGPU prototypes quite a while ago, and plenty of people would've been happy with SPIR-V+WebGPU. But a particular big company's petty fights with Khronos derailed that.
- cogman10 6y ago
  Why not call them out? It was Apple that decided that standards weren't for them. Sure, it might be more of an Apple legal team problem vs programmer problem. None-the-less they are the ones that decided to derail the standard.
  - om2 6y ago
    SPIR-V by itself does not have the needed safety or interoperability properties for the web, or the advantages of text formats that the web has benefitted from. These are the more important factors, not IPR considerations. Fortunately, we landed on a good compromise with a textual language that maps closely onto SPIR-V semantics. A lot of the hard work remaining is to achieve the level of safety and interoperability required for the web. Even in an approach of using SPIR-V as the syntax, a similar level of effort would have been required on safety and interop aspects.
    - Jasper_ 6y ago
      > SPIR-V by itself does not have the needed safety or interoperability properties for the web Safety, maybe not 100%, but this could be fixed with extensions, and transformations. The same transformations that WGSL compilers will apply. I'm unsure of what you mean by "interoperability". > or the advantages of text formats that the web has benefitted from. ??? Nobody has ever enumerated these to me. Or told me why if these advantages are so great, why Apple has not advocated for a text-based formats for <audio> and <video>. Binary formats are widely becoming more standard on the web for all sorts of reasons (images, fonts, video, audio, even code in the form of WebAssembly, and Bloomberg/Facebook's JS AST proposal improved performance by removing parsing cost. MapBox ships its vectors in binary format. glTF is a binary format.), and even in the graphics space, the release of the new SPIR-V format over having to ingest GLSL is seen as one of the greatest advantages of Vulkan over OpenGL. If you want a text format, take the text serialization of SPIR-V. It's there, it's standard, it exists. But you won't bother answering me, because every time you bring this up, we ask the same questions, repeat the same evidence, and you ignore us, preferring just to reply "text is more webby". Not to mention that you're currently pressuring the WG to add new APIs to avoid the heavy front-end cost of Apple's own MSL shader compiler. https://github.com/gpuweb/gpuweb/issues/1064 https://github.com/gpuweb/gpuweb/issues/1064
      - auggierose 6y ago
        Looking at that issue, seems perfectly fine to raise it to me. That's exactly the kind of input I would expect from a member of the working group, and it just increases the quality of the end product. Let's face it, Metal is nicer than Vulkan. And I bet there are more Metal programmers out there by now than there are Vulkan programmers.
      - flohofwoe 6y ago
        > "text is more webby". TBF, having to include a binary shader blob in a small WebGL-style demo (e.g. some interactive math visualization embedded in a blog post) would suck compared to just adding a few lines of text. It would be possible to load a WASM module with a text-to-SPIRV compiler, but that would most likely be a few megabytes. IMHO one shouldn't discard those small shadertoy-style demos, this is what made WebGL popular, not the "AAA games on the web" pipe dream.
        atq2119 6y ago
        It would be possible to load a WASM module with a text-to-SPIRV compiler, but that would most likely be a few megabytes. My understanding is that this was discussed, and the answer is: glslang is much smaller than this. (Glslang now has a bunch of #ifndef WEB to facilitate precisely this.)
        om2 6y ago
        I don’t think anyone exhibited a version that got to acceptable binary size and startup/execution time. Might be that it would have been possible with way more effort.
        Jasper_ 6y ago
        Going from "a few megabytes I'd rather not include, for a simple use case" to "let's design our own shading language, derail the project for three years, and discover from first principles all the reasons that this is actually a hard problem, while telling everyone else it's actually easy!" is quite the leap. I sympathize with people who believe that page sizes are getting larger and we should do something to prevent it, but the latter is not a worthwhile solution that meets the tradeoffs IMO.

> we've all been here before and it's very very hard, at the very least, get some IHVs or at least a team that does port work / emulation tech on board

kevingadd 6y ago

There were working SPIR-V+WebGPU prototypes quite a while ago, and plenty of people would've been happy with SPIR-V+WebGPU. But a particular big company's petty fights with Khronos derailed that.

cogman10 6y ago
Why not call them out? It was Apple that decided that standards weren't for them. Sure, it might be more of an Apple legal team problem vs programmer problem. None-the-less they are the ones that decided to derail the standard.
- om2 6y ago
  SPIR-V by itself does not have the needed safety or interoperability properties for the web, or the advantages of text formats that the web has benefitted from. These are the more important factors, not IPR considerations. Fortunately, we landed on a good compromise with a textual language that maps closely onto SPIR-V semantics. A lot of the hard work remaining is to achieve the level of safety and interoperability required for the web. Even in an approach of using SPIR-V as the syntax, a similar level of effort would have been required on safety and interop aspects.
  - Jasper_ 6y ago
    > SPIR-V by itself does not have the needed safety or interoperability properties for the web Safety, maybe not 100%, but this could be fixed with extensions, and transformations. The same transformations that WGSL compilers will apply. I'm unsure of what you mean by "interoperability". > or the advantages of text formats that the web has benefitted from. ??? Nobody has ever enumerated these to me. Or told me why if these advantages are so great, why Apple has not advocated for a text-based formats for <audio> and <video>. Binary formats are widely becoming more standard on the web for all sorts of reasons (images, fonts, video, audio, even code in the form of WebAssembly, and Bloomberg/Facebook's JS AST proposal improved performance by removing parsing cost. MapBox ships its vectors in binary format. glTF is a binary format.), and even in the graphics space, the release of the new SPIR-V format over having to ingest GLSL is seen as one of the greatest advantages of Vulkan over OpenGL. If you want a text format, take the text serialization of SPIR-V. It's there, it's standard, it exists. But you won't bother answering me, because every time you bring this up, we ask the same questions, repeat the same evidence, and you ignore us, preferring just to reply "text is more webby". Not to mention that you're currently pressuring the WG to add new APIs to avoid the heavy front-end cost of Apple's own MSL shader compiler. https://github.com/gpuweb/gpuweb/issues/1064 https://github.com/gpuweb/gpuweb/issues/1064
    - auggierose 6y ago
      Looking at that issue, seems perfectly fine to raise it to me. That's exactly the kind of input I would expect from a member of the working group, and it just increases the quality of the end product. Let's face it, Metal is nicer than Vulkan. And I bet there are more Metal programmers out there by now than there are Vulkan programmers.
    - flohofwoe 6y ago
      > "text is more webby". TBF, having to include a binary shader blob in a small WebGL-style demo (e.g. some interactive math visualization embedded in a blog post) would suck compared to just adding a few lines of text. It would be possible to load a WASM module with a text-to-SPIRV compiler, but that would most likely be a few megabytes. IMHO one shouldn't discard those small shadertoy-style demos, this is what made WebGL popular, not the "AAA games on the web" pipe dream.
      - atq2119 6y ago
        It would be possible to load a WASM module with a text-to-SPIRV compiler, but that would most likely be a few megabytes. My understanding is that this was discussed, and the answer is: glslang is much smaller than this. (Glslang now has a bunch of #ifndef WEB to facilitate precisely this.)
        om2 6y ago
        I don’t think anyone exhibited a version that got to acceptable binary size and startup/execution time. Might be that it would have been possible with way more effort.
      - Jasper_ 6y ago
        Going from "a few megabytes I'd rather not include, for a simple use case" to "let's design our own shading language, derail the project for three years, and discover from first principles all the reasons that this is actually a hard problem, while telling everyone else it's actually easy!" is quite the leap. I sympathize with people who believe that page sizes are getting larger and we should do something to prevent it, but the latter is not a worthwhile solution that meets the tradeoffs IMO.