4 ms·

As the draft says [1]: > Trivially convertable to SPIR-V > Constructs are defined as normative references to their [SPIR-V] counterparts > All features in WG

As the draft says [1]: > Trivially convertable to SPIR-V > Constructs are defined as normative references to their [SPIR-V] counterparts > All features in WGSL are directly translatable to [SPIR-V] > Features and semantics are exactly the ones of [SPIR-V] > Each item in this spec must provide the mapping to [SPIR-V] for the construct So WGSL is essentially just an alternative representation for SPIR-V. But I don't see how this compromises the viability of webgpu. [1] https://www.w3.org/TR/WGSL https://www.w3.org/TR/WGSL

kaba0 5y ago
Without much experience in the topic, why was the “de facto standard” SPIR-V was not chosen then instead? If they are so similar, is there any advantage of a new format?
- codeflo 5y ago
  Here’s a comment summarizing the official rationale: https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... TBH, I don’t find those arguments convincing, but then, WebGPU is largely a political compromise, not a technical one. In a politics-free zone, they’d have standardized a “WebVulkan”, not made an entirely new thing. That would have been on the table, but Apple vetoed it. The same for a “Web-SPIR-V”. However, I also don’t think it’s that big of a deal in the grand scheme of things. I’m glad we have a viable standard at all.
j-pb 5y ago
That was the original sales pitch which has been abandoned in favour of "Lets make a Rust-like language for shaders!". It's a textbook case of: Embrace, Extend, Extinguish Google tried to save it, but that proposal was rejected: https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDUNqkkMo3a2N7wR4Z04SQinPg/edit#slide=id.g6176d1223e_0_0 https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU... The Proposal to work with both WGSL, was also not accepted because it would "weaken the position of WGSL". "But think of the children/open web!" Apple knows how to push the right buttons on the Mozilla folks so that they tag along: Rust, wEB-StAnDARds, not invented here. - SPIRV was done by an evil technological group, not an open and inclusive standard body. We would tie our standard to whatever the SPRIV says, that's not open web. The open web can only flourish if everything is text based! cough WASM cough Rust ist such a modern language! - It's similar to what happened to WebSQL, except this time it's much worse as it also ruins any hope that WASM might be able to replace all the other technological cruft. Playing the old guessing game of how the transpiler will mangle your SPIRV is simply not something that people want to go back to.
- the_duke 5y ago
  I'm a bit confused. The draft was just updated two days ago. Are you saying that the direct mapping requirements I quoted above have been abandoned?
  - j-pb 5y ago
    > Are you saying that the direct mapping requirements I quoted above have been abandoned? Yes. See these quotes: Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too" ... Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point" ... Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime." From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4... See also: https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/566 https://github.com/gpuweb/gpuweb/issues/566 http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... https://news.ycombinator.com/item?id=24858172 https://news.ycombinator.com/item?id=24858172 The process has been very implementation driven, with Naga, the Rust tooling that does the whole conversion shenanigans, growing and changing its IR and semantics steadily. It's ironic that a group that is usually very adverse to having a single implementation of things is now pointing to Naga and arguing that we don't need an easy conversion step because we have all the compiler infrastructure build already. The group has slowly redefined "bijective" to mean "easily compilable", which would be pretty hilarious, if it weren't so sad.
    - codeflo 5y ago
      I agree Apple is the bad guy here and even the public discussions were a clown show, who knows how much worse it was behind closed doors. But I’d rather have an inelegant standard than none at all, and I think the problems with WGSL can be worked around.

kaba0 5y ago

Without much experience in the topic, why was the “de facto standard” SPIR-V was not chosen then instead? If they are so similar, is there any advantage of a new format?

codeflo 5y ago
Here’s a comment summarizing the official rationale: https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... TBH, I don’t find those arguments convincing, but then, WebGPU is largely a political compromise, not a technical one. In a politics-free zone, they’d have standardized a “WebVulkan”, not made an entirely new thing. That would have been on the table, but Apple vetoed it. The same for a “Web-SPIR-V”. However, I also don’t think it’s that big of a deal in the grand scheme of things. I’m glad we have a viable standard at all.

j-pb 5y ago

That was the original sales pitch which has been abandoned in favour of "Lets make a Rust-like language for shaders!". It's a textbook case of: Embrace, Extend, Extinguish Google tried to save it, but that proposal was rejected: https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDUNqkkMo3a2N7wR4Z04SQinPg/edit#slide=id.g6176d1223e_0_0 https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU... The Proposal to work with both WGSL, was also not accepted because it would "weaken the position of WGSL". "But think of the children/open web!" Apple knows how to push the right buttons on the Mozilla folks so that they tag along: Rust, wEB-StAnDARds, not invented here. - SPIRV was done by an evil technological group, not an open and inclusive standard body. We would tie our standard to whatever the SPRIV says, that's not open web. The open web can only flourish if everything is text based! cough WASM cough Rust ist such a modern language! - It's similar to what happened to WebSQL, except this time it's much worse as it also ruins any hope that WASM might be able to replace all the other technological cruft. Playing the old guessing game of how the transpiler will mangle your SPIRV is simply not something that people want to go back to.

the_duke 5y ago
I'm a bit confused. The draft was just updated two days ago. Are you saying that the direct mapping requirements I quoted above have been abandoned?
- j-pb 5y ago
  > Are you saying that the direct mapping requirements I quoted above have been abandoned? Yes. See these quotes: Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too" ... Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point" ... Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime." From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4... See also: https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/pull/599 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/582 https://github.com/gpuweb/gpuweb/issues/566 https://github.com/gpuweb/gpuweb/issues/566 http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642... https://news.ycombinator.com/item?id=24858172 https://news.ycombinator.com/item?id=24858172 The process has been very implementation driven, with Naga, the Rust tooling that does the whole conversion shenanigans, growing and changing its IR and semantics steadily. It's ironic that a group that is usually very adverse to having a single implementation of things is now pointing to Naga and arguing that we don't need an easy conversion step because we have all the compiler infrastructure build already. The group has slowly redefined "bijective" to mean "easily compilable", which would be pretty hilarious, if it weren't so sad.
  - codeflo 5y ago
    I agree Apple is the bad guy here and even the public discussions were a clown show, who knows how much worse it was behind closed doors. But I’d rather have an inelegant standard than none at all, and I think the problems with WGSL can be worked around.