7 ms·

Web Shading Language is a non-starter. I looked quite closely at the specification. Apple has argued in the WebGPU WG that SPIR-V is not defined enough, semanti

Web Shading Language is a non-starter. I looked quite closely at the specification. Apple has argued in the WebGPU WG that SPIR-V is not defined enough, semantically, to be meaningful, but WSL is even worse. Sometimes, it's even explained in terms of SPIR-V, like in the case of discard, where it was hastily explained in terms of SPIR-V's OpKill after we identified it was completely missing. Apple has blocked any possibility of using a SPIR-V profile, sometimes with bad-faith arguments, despite it being the suggestion of all other vendors and the graphics community participating in the WG. The team working on the WSL compiler had to have dominator analysis patiently explained to them, and then told us it was too complex of a concept, despite being something learned about in Compilers 101.

magicalist 7y ago
The wire size comparison is also weird. Are they comparing serving WSL directly (depending on a WSL compiler they went ahead and built into the Safari preview) vs GLSL plus a compiler to convert to SPIR-V because that's not built into any browser (yet)? Why would that be an interesting comparison?
- Jasper_ 7y ago
  GLSL+glslang+SPIR-V was one of the suggested approaches for developers that want to compile GLSL at runtime on the web. Google has been working on getting a minimal form of glslang out the door, but they're having trouble because glslang is a pretty big beast.
  - magicalist 7y ago
    But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it. It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
    - kvark 7y ago
      well, one of the points to go with SPIR-V is to not standardize higher level languages that translate into it
    - om2 7y ago
      The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.
      - saurik 7y ago
        Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I really really wanted a compiler at runtime, maybe I want a different one, and I can then use differently models like F# or a Lisp variant... things that are much harder if someone insists I translate everything into some silly specific language :/.
        pjmlp 7y ago
        What you are describing is exactly shipping a compiler, the JIT compiler bundled in the .NET Framework and Core runtimes. You cannot do that in .NET Native, for example.
        om2 7y ago
        Shipping support for both a text format and a binary format directly in the browser is in some ways the worst of both worlds. If both are implemented natively, you get double the attack surface at the ingestion layer. If the text format is supported by compiling to the binary format (or vice versa) using WASM that happens to ship with the browser, it will probably be slow (whereas ingesting a text format directly seems pretty fast).
- om2 7y ago
  Others have explained why it's relevant (this is the recommended solution for online shader generation from SPIR-V advocates.) But there's also a direct comparison of WSL vs SPIR-V wire size in he same graph, for cases where SPIR-V would be generated in advance.
  - xigency 7y ago
    It seems like there would be alternate ways to do online shader generation than concatenating strings and compiling if there were a well-formed binary standard. Maybe it is the easiest conceptually, but I don't see that as being a performance target in that case. Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.
    - om2 7y ago
      Our collaboration with Babylon.js happened after most of the spec proposal work. It was inspired by Google’s similar collaboration with Babylon.js prompting Google’s own SPIR-V based implementation of WebGL. This makes the comparison more apples-to-apples. WebGPU itself is guided by input from many framework and engine developers.
      - xigency 7y ago
        Sure. I would just consider that the working group keep a broad perspective on the issue. There are developers who use graphics frameworks bare-metal, and there are also a number of frameworks that haven't been mentioned and don't seem to be cooperating, for instance, Pixi.js and Three.js. I think the WG has a responsibility to represent their interests as well, whether or not they are actively participating. I also don't think that the technology has to match the existing architecture of engines. Instead, we should be looking at find the best technology for a long-term solution. Many developers already know that they will have to make significant overhauls to upgrade to WebGPU. "If WebGPU turns out to be as powerful as we all hope it to be libraries like Three.js will likely have to be rewritten from scratch in order to take full advantage of it." [0] [0] https://github.com/mrdoob/three.js/issues/15936#issuecomment-471162081 https://github.com/mrdoob/three.js/issues/15936#issuecomment...
pizlonator 7y ago
The WSL specification is a single document that tells you how the language executed and how it ensures security. SPIR-V simply does not have this. I don’t get your argument here. It’s really funny to say that we had to have dominator analysis patiently explained to them. I don’t have a clue what you are talking about there. In one meeting I remember having to explain dominator analysis to SPIR-V folks. (I am both a member of the WSL team and an expert on dominator analysis.)
- Jasper_ 7y ago
  WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. Simple branching in shaders is notoriously under-defined as well because of complications related to divergence/convergence and the SIMT model. re: dominator analysis, it was brought up by an Apple WebGPU developer (Myles C. Maxfield) as a complexity of parsing SPIR-V. David Neto had to explain it to Myles. https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTWaNnuaahtA0VBIvHdA5c/edit# https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTW...
  - om2 7y ago
    I was there for one of the times that Phil (from Apple) explained dominator analysis and why it's an added complexity of a binary language. Phil is the architect of our JS VM and one of the main designers of WSL so I think he knows! Your claim that the WSL spec tells you very little seems off to me. The spec includes formal semantics for everything. If some things aren't in the spec yet they can be added. There is also a pretty extensive test suite. To me the level of specification rigor is considerably higher than SPIR-V, which has an informal spec with separate documents for adding web safety.
  - pizlonator 7y ago
    > WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. The spec has a semantics that describes that the language does when executed in great detail. It seems that your complaint is that there is some thing that you think that SPIR-V describes better than WSL - waves and quads in this case. I was there when we brought up dominators. You are right that we brought it up as a complexity of SPIR-V, but not because we didn't know what dominators are. We do know what they are, and because we do know, we know that it's complex. We're not saying "it's so complex that we don't understand it". We are saying "we understand it and we know it's complex". In particular, an early argument against text-based languages is that you have to specify and then validate variable scoping. Dominator analysis is a variable scoping rule, just a very complicated one for a wire format to have.
om2 7y ago
You may not like it but it's pretty clear that WSL is at least a starter. It has a spec, a test suite, and an implementation (which fully implements safety). And the implementation is pretty fast, and should at least dispel WSL vs SPIR-V performance concerns. This is arguably ahead of the proposed web dialect of SPIR-V (which needs to subset the language, add validation steps, and insert safety checks).
- kangz 7y ago
  The SPIR-V for WebGPU has the subsetting of the language at [1], validation is fully implemented in spirv-val and as are the safety checks in spirv-opt. SPIR-V is also proven to compile to all the target APIs for WebGPU, while WSL only has a MSL transpiler right now. [1] https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md https://github.com/gpuweb/spirv-execution-env/blob/master/ex...
TazeTSchnitzel 7y ago
If we can compile GLSL, GLSL ES, HLSL and OpenCL C to SPIR-V, and we can use SPIR-V in OpenGL, Vulkan and OpenCL, then why on earth can't WebGPU just use SPIR-V? If it's not safe enough, then define a safe subset or safety extensions with strict validation. If it's not Appley enough, then write a Metal Shading Language to SPIR-V compiler (the reverse has already been done). Hell, if SPIR-V really is too low-level, GLSL ES already exists in WebGL and is plenty friendly and capable. But surely the graphics world doesn't need yet another GPU language?
- ericflo 7y ago
  Because Apple hates Khronos
  - saagarjha 7y ago
    Considering that Apple is a Promoter Member of the Khronos Group, I doubt this.
    - TazeTSchnitzel 7y ago
      They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.
      - pjmlp 7y ago
        Actually they created Quickdraw 3D, and only adopted OpenGL as the NeXT team came onboard. Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0. As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscript, which isn't compatible with OpenCL. As for OpenGL ES, I bet they only did it, as they were trying to "play pretend" being another kind of Apple as survival mechanism, nowadays they don't need it any longer. Finally, Metal is one year older than Vulkan, offers a modern API instead of plain old C, and contrary to Khronos, just like other platform vendors, Apple understands the value of providing nice frameworks and debugging tools to go along an API.

magicalist 7y ago

The wire size comparison is also weird. Are they comparing serving WSL directly (depending on a WSL compiler they went ahead and built into the Safari preview) vs GLSL plus a compiler to convert to SPIR-V because that's not built into any browser (yet)? Why would that be an interesting comparison?

Jasper_ 7y ago
GLSL+glslang+SPIR-V was one of the suggested approaches for developers that want to compile GLSL at runtime on the web. Google has been working on getting a minimal form of glslang out the door, but they're having trouble because glslang is a pretty big beast.
- magicalist 7y ago
  But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it. It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
  - kvark 7y ago
    well, one of the points to go with SPIR-V is to not standardize higher level languages that translate into it
  - om2 7y ago
    The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.
    - saurik 7y ago
      Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I really really wanted a compiler at runtime, maybe I want a different one, and I can then use differently models like F# or a Lisp variant... things that are much harder if someone insists I translate everything into some silly specific language :/.
      - pjmlp 7y ago
        What you are describing is exactly shipping a compiler, the JIT compiler bundled in the .NET Framework and Core runtimes. You cannot do that in .NET Native, for example.
      - om2 7y ago
        Shipping support for both a text format and a binary format directly in the browser is in some ways the worst of both worlds. If both are implemented natively, you get double the attack surface at the ingestion layer. If the text format is supported by compiling to the binary format (or vice versa) using WASM that happens to ship with the browser, it will probably be slow (whereas ingesting a text format directly seems pretty fast).
om2 7y ago
Others have explained why it's relevant (this is the recommended solution for online shader generation from SPIR-V advocates.) But there's also a direct comparison of WSL vs SPIR-V wire size in he same graph, for cases where SPIR-V would be generated in advance.
- xigency 7y ago
  It seems like there would be alternate ways to do online shader generation than concatenating strings and compiling if there were a well-formed binary standard. Maybe it is the easiest conceptually, but I don't see that as being a performance target in that case. Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.
  - om2 7y ago
    Our collaboration with Babylon.js happened after most of the spec proposal work. It was inspired by Google’s similar collaboration with Babylon.js prompting Google’s own SPIR-V based implementation of WebGL. This makes the comparison more apples-to-apples. WebGPU itself is guided by input from many framework and engine developers.
    - xigency 7y ago
      Sure. I would just consider that the working group keep a broad perspective on the issue. There are developers who use graphics frameworks bare-metal, and there are also a number of frameworks that haven't been mentioned and don't seem to be cooperating, for instance, Pixi.js and Three.js. I think the WG has a responsibility to represent their interests as well, whether or not they are actively participating. I also don't think that the technology has to match the existing architecture of engines. Instead, we should be looking at find the best technology for a long-term solution. Many developers already know that they will have to make significant overhauls to upgrade to WebGPU. "If WebGPU turns out to be as powerful as we all hope it to be libraries like Three.js will likely have to be rewritten from scratch in order to take full advantage of it." [0] [0] https://github.com/mrdoob/three.js/issues/15936#issuecomment-471162081 https://github.com/mrdoob/three.js/issues/15936#issuecomment...

pizlonator 7y ago

The WSL specification is a single document that tells you how the language executed and how it ensures security. SPIR-V simply does not have this. I don’t get your argument here. It’s really funny to say that we had to have dominator analysis patiently explained to them. I don’t have a clue what you are talking about there. In one meeting I remember having to explain dominator analysis to SPIR-V folks. (I am both a member of the WSL team and an expert on dominator analysis.)

Jasper_ 7y ago
WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. Simple branching in shaders is notoriously under-defined as well because of complications related to divergence/convergence and the SIMT model. re: dominator analysis, it was brought up by an Apple WebGPU developer (Myles C. Maxfield) as a complexity of parsing SPIR-V. David Neto had to explain it to Myles. https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTWaNnuaahtA0VBIvHdA5c/edit# https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTW...
- om2 7y ago
  I was there for one of the times that Phil (from Apple) explained dominator analysis and why it's an added complexity of a binary language. Phil is the architect of our JS VM and one of the main designers of WSL so I think he knows! Your claim that the WSL spec tells you very little seems off to me. The spec includes formal semantics for everything. If some things aren't in the spec yet they can be added. There is also a pretty extensive test suite. To me the level of specification rigor is considerably higher than SPIR-V, which has an informal spec with separate documents for adding web safety.
- pizlonator 7y ago
  > WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. The spec has a semantics that describes that the language does when executed in great detail. It seems that your complaint is that there is some thing that you think that SPIR-V describes better than WSL - waves and quads in this case. I was there when we brought up dominators. You are right that we brought it up as a complexity of SPIR-V, but not because we didn't know what dominators are. We do know what they are, and because we do know, we know that it's complex. We're not saying "it's so complex that we don't understand it". We are saying "we understand it and we know it's complex". In particular, an early argument against text-based languages is that you have to specify and then validate variable scoping. Dominator analysis is a variable scoping rule, just a very complicated one for a wire format to have.

om2 7y ago

You may not like it but it's pretty clear that WSL is at least a starter. It has a spec, a test suite, and an implementation (which fully implements safety). And the implementation is pretty fast, and should at least dispel WSL vs SPIR-V performance concerns. This is arguably ahead of the proposed web dialect of SPIR-V (which needs to subset the language, add validation steps, and insert safety checks).

kangz 7y ago
The SPIR-V for WebGPU has the subsetting of the language at [1], validation is fully implemented in spirv-val and as are the safety checks in spirv-opt. SPIR-V is also proven to compile to all the target APIs for WebGPU, while WSL only has a MSL transpiler right now. [1] https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md https://github.com/gpuweb/spirv-execution-env/blob/master/ex...

TazeTSchnitzel 7y ago

If we can compile GLSL, GLSL ES, HLSL and OpenCL C to SPIR-V, and we can use SPIR-V in OpenGL, Vulkan and OpenCL, then why on earth can't WebGPU just use SPIR-V? If it's not safe enough, then define a safe subset or safety extensions with strict validation. If it's not Appley enough, then write a Metal Shading Language to SPIR-V compiler (the reverse has already been done). Hell, if SPIR-V really is too low-level, GLSL ES already exists in WebGL and is plenty friendly and capable. But surely the graphics world doesn't need yet another GPU language?

ericflo 7y ago
Because Apple hates Khronos
- saagarjha 7y ago
  Considering that Apple is a Promoter Member of the Khronos Group, I doubt this.
  - TazeTSchnitzel 7y ago
    They created OpenCL and supported OpenGL (ES) as the only graphics API on their platforms for years, but now they have dumped both open standards in favour of their own proprietary ones.
    - pjmlp 7y ago
      Actually they created Quickdraw 3D, and only adopted OpenGL as the NeXT team came onboard. Although they created and gave OpenCL 1.0 to Khronos, they were not happy with the path that Khronos was taking it and their support basically stagnated on OpenCL 1.0. As side note Google is yet to support OpenCL on Android, instead just like they did with their Android Java, they decided to create their own flavour, Renderscript, which isn't compatible with OpenCL. As for OpenGL ES, I bet they only did it, as they were trying to "play pretend" being another kind of Apple as survival mechanism, nowadays they don't need it any longer. Finally, Metal is one year older than Vulkan, offers a modern API instead of plain old C, and contrary to Khronos, just like other platform vendors, Apple understands the value of providing nice frameworks and debugging tools to go along an API.