8 ms·

We've been trying to design a safe and portable language in WebGPU (called WGSL), but it turns out to be really hard. For example, subgroup ops discussion [1] s

by kvark 6y ago

We've been trying to design a safe and portable language in WebGPU (called WGSL), but it turns out to be really hard. For example, subgroup ops discussion [1] so far concluded that even the most limited form still has portability concerns. Even things like texture sampling (that depend on control flow uniformity) could be tricky with regards to how the uniformity is defined. And at least in WGSL we can be conservative, but Rust-GPU does probably not have this luxury. Thus, I'm curious to see how Rust will tackle it. Will it try to enforce the portability and safety guarantees with a type system, or will it specifically lower the guarantees compared to native code (thus keeping the syntax of Rust but not the philosophy). Anyhow, amazing work by Embark, and a stellar example how to collaborate in open source! [1] https://github.com/gpuweb/gpuweb/pull/954 https://github.com/gpuweb/gpuweb/pull/954

deleted 6y ago
[deleted]
Jasper_ 6y ago
> it turns out to be really hard Everyone was yelling this at you since the beginning. Ever since Apple proposed "safe HLSL", and then it morphed into WHLSL and then WLSL and then the competing Tint proposal which is now WGSL, everyone (Adobe, Valve, Epic, Unity, NVIDIA) was saying "none of this will do what you think it does, 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". The committee chose not to listen, instead forcing WebGPU down this hell that nobody really wants or appreciates. The whole WebGPU is three years late and still has no users, despite being one of the most complicated specs to land in years. And yeah, I'm still a bit bitter about it. I am also skeptical of rust-gpu's approach, because I don't think it's possible to take a CPU-inspired language design and blindly adapt it to GPUs without some difficult questions to answer (they still don't have flow control, but I'm told that's coming). But at the very least, I think repi and Embark know what they're doing and know about the tough problems, rather than feigning being blindsighted.
- auggierose 6y ago
  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

by kvark 6y ago

deleted 6y ago

[deleted]

Jasper_ 6y ago

> it turns out to be really hard Everyone was yelling this at you since the beginning. Ever since Apple proposed "safe HLSL", and then it morphed into WHLSL and then WLSL and then the competing Tint proposal which is now WGSL, everyone (Adobe, Valve, Epic, Unity, NVIDIA) was saying "none of this will do what you think it does, 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". The committee chose not to listen, instead forcing WebGPU down this hell that nobody really wants or appreciates. The whole WebGPU is three years late and still has no users, despite being one of the most complicated specs to land in years. And yeah, I'm still a bit bitter about it. I am also skeptical of rust-gpu's approach, because I don't think it's possible to take a CPU-inspired language design and blindly adapt it to GPUs without some difficult questions to answer (they still don't have flow control, but I'm told that's coming). But at the very least, I think repi and Embark know what they're doing and know about the tough problems, rather than feigning being blindsighted.

auggierose 6y ago
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