3 ms·

I think the counter-argument to "but WASM?!" is that on the Web you still can use text to describe the behavior. WASM is optional. At the same time, if WebGPU p

by kvark 7y ago

I think the counter-argument to "but WASM?!" is that on the Web you still can use text to describe the behavior. WASM is optional. At the same time, if WebGPU picked SPIR-V binary, it wouldn't have a built-in way of programming without dependencies inside a browser.

klodolph 7y ago
I'm not quite sure what you're saying. WASM is optional in the same way that WebGPU is optional. They both allow you to invoke code written in another language. There's not really a good way of writing WASM without dependencies inside a browser.
- kvark 7y ago
  What I wanted to say is that we as a group want people to be able to use the browser and nothing else to develop WebGPU if they want. WASM by itself doesn't provide new APIs, it's still just a different way to expose the Web platform. So WASM being optional doesn't limit anybody in what they can do. Having WebGPU optional does limit what you can do on the web. We want WebGPU to be available in a wide sense (accessibility, dependencies, portability, everthing).
  - jfkebwjsbx 7y ago
    Being able to develop with the browser has nothing to do with WebGPU being binary or text. It seems you speak with "we", as if you were part of the committee? If that is a yes: how can we become part of that committee to amend this mistake? Who has voting rights?
    - kvark 7y ago
      How are you suggesting to write shaders in the browser if they are expected to be in a binary form? WebGPU community group is open to anyone interested: https://www.w3.org/community/gpu/ https://www.w3.org/community/gpu/
      - jcelerier 7y ago
        We can compile and run c++ code in a browser with WASM versions of clang, why would it be any issue to compile glsl / any other language to spir-v ? That's already what almost everyone is doing with spirv-cross / shaderconductor on the desktop
  - klodolph 7y ago
    WebGPU doesn’t provide new APIs in the same sense that WASM doesn’t provide new APIs, they just provide alternative APIs to accomplish the same tasks, but faster. Anything you can do with WebGPU you could do in JavaScript, in the same sense that anything you can do with WASM you can do in JavaScript. The only difference is performance.

by kvark 7y ago

klodolph 7y ago

I'm not quite sure what you're saying. WASM is optional in the same way that WebGPU is optional. They both allow you to invoke code written in another language. There's not really a good way of writing WASM without dependencies inside a browser.

kvark 7y ago
What I wanted to say is that we as a group want people to be able to use the browser and nothing else to develop WebGPU if they want. WASM by itself doesn't provide new APIs, it's still just a different way to expose the Web platform. So WASM being optional doesn't limit anybody in what they can do. Having WebGPU optional does limit what you can do on the web. We want WebGPU to be available in a wide sense (accessibility, dependencies, portability, everthing).
- jfkebwjsbx 7y ago
  Being able to develop with the browser has nothing to do with WebGPU being binary or text. It seems you speak with "we", as if you were part of the committee? If that is a yes: how can we become part of that committee to amend this mistake? Who has voting rights?
  - kvark 7y ago
    How are you suggesting to write shaders in the browser if they are expected to be in a binary form? WebGPU community group is open to anyone interested: https://www.w3.org/community/gpu/ https://www.w3.org/community/gpu/
    - jcelerier 7y ago
      We can compile and run c++ code in a browser with WASM versions of clang, why would it be any issue to compile glsl / any other language to spir-v ? That's already what almost everyone is doing with spirv-cross / shaderconductor on the desktop
- klodolph 7y ago
  WebGPU doesn’t provide new APIs in the same sense that WASM doesn’t provide new APIs, they just provide alternative APIs to accomplish the same tasks, but faster. Anything you can do with WebGPU you could do in JavaScript, in the same sense that anything you can do with WASM you can do in JavaScript. The only difference is performance.