3 ms·

I don't quite understand what you mean. WASM modules don't have direct access to anything. They have to be granted capabilities from by the host. Are you referr

I don't quite understand what you mean. WASM modules don't have direct access to anything. They have to be granted capabilities from by the host. Are you referring to optimizations that various engines do where they recognize well-known imports like Math.sin and compile things such that they don't invoke JS at all?

pjmlp 3y ago
Exactly, hence it is currently impossible to use WebGPU without JavaScript's help. There are some proposals regarding exposing the browser IDL to WASM via reference types, but it is far from happening.
- davexunit 3y ago
  You need the host (whatever it is) to provide the capabilities to WASM. On the web, the host environment is JS. Browser engines are free to optimize well-known imports with or without any new proposals. I guess I just don't really see the issue...
  - pjmlp 3y ago
    The issue is that currently this is impossible "Now how do I call this API from WASM without any intervening JavaScript?". Now the Web IDL bindings have evolved to some kind of reference types, and that is what I was talking about, not GC reference types. https://www.w3.org/2018/12/games-workshop/slides/08-web-idl-bindings.pdf https://www.w3.org/2018/12/games-workshop/slides/08-web-idl-... https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... https://component-model.bytecodealliance.org/introduction.html https://component-model.bytecodealliance.org/introduction.ht... However I did the mistake to keep calling them reference types, when in reality they are now called component model. As for the browser, yeah that is what matters for WebGPU, outside of the browser there are so many middleware options with much better tooling (GPU debuggers for Web 3D still aren't a thing 10 years later, besides poor SpectorJS), and access to latest hardware features, instead of what was the state of the art in 2015.

pjmlp 3y ago

Exactly, hence it is currently impossible to use WebGPU without JavaScript's help. There are some proposals regarding exposing the browser IDL to WASM via reference types, but it is far from happening.

davexunit 3y ago
You need the host (whatever it is) to provide the capabilities to WASM. On the web, the host environment is JS. Browser engines are free to optimize well-known imports with or without any new proposals. I guess I just don't really see the issue...
- pjmlp 3y ago
  The issue is that currently this is impossible "Now how do I call this API from WASM without any intervening JavaScript?". Now the Web IDL bindings have evolved to some kind of reference types, and that is what I was talking about, not GC reference types. https://www.w3.org/2018/12/games-workshop/slides/08-web-idl-bindings.pdf https://www.w3.org/2018/12/games-workshop/slides/08-web-idl-... https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type... https://component-model.bytecodealliance.org/introduction.html https://component-model.bytecodealliance.org/introduction.ht... However I did the mistake to keep calling them reference types, when in reality they are now called component model. As for the browser, yeah that is what matters for WebGPU, outside of the browser there are so many middleware options with much better tooling (GPU debuggers for Web 3D still aren't a thing 10 years later, besides poor SpectorJS), and access to latest hardware features, instead of what was the state of the art in 2015.