[Taichi.js] JavaScript Backend via Emscripten

[yuanming-hu]

Is your feature request related to a problem? Please describe.
Allowing Taichi to generate JavaScript code will enable many more people to play with state-of-the-art computer graphics in their browsers.

Describe the solution you'd like
More investigation is needed. Emscripten or WASM seem good ways to go.

The kernel code will still be written in Python, yet a ti.export function will be added to dump a kernel into compiled JavaScript. Then users can load these js and run it in HTML5.

The JavaScript backend does not have to support full Taichi functionality. For example, we can omit some sparse data structure support.

Discussions on/contributions to this are warmly welcome! :-)

[r03ert0]

I'd be happy to help!
Do you think something like gpu.js could be used to accelerate some computations?

[yuanming-hu]

Good question. I guess one thing to discuss here is "should we do pure JavaScript or leverage WebGL (fragment/compute shaders)?"

If we go WebGL, we get higher performance, but the computational pattern also gets restricted to pure array operations (e.g. a[i, j] = ti.sqrt(b[i, j])). This means we need some language restriction on the frontend and not every Taichi program gets compiled to WebGL. Not sure how compute shaders (see https://github.com/9ballsyndrome/WebGL_Compute_shader and https://www.khronos.org/registry/webgl/specs/latest/2.0-compute/) help with this.

If we go JavaScript, then it will run slower but we can support much more computational patterns. It's also easier since we can probably directly translate the generated LLVM IR into Javascript. I would suggest starting with this path.

[yuanming-hu]

Let's narrow down the range to generating Javascript via Emscripten until WebGL compute shader is mature.

[yuanming-hu]

It seems that Emscripten itself is switching to the LLVM WASM backend.
https://v8.dev/blog/emscripten-llvm-wasm

So one decision to be made: do we directly generate WASM via LLVM or go through Emscripten?

The former saves us from adding the dependency on Emscripten.
The latter can generate Javascript as well, which has better compatibility. Emscripten also seems better documented than LLVM WASM backend.

A question to Web experts: how well supported is WASM on current browsers? If everyone's browser already supports WASM (https://caniuse.com/#feat=wasm) then maybe we should directly use the LLVM WASM backend?

An old Rust thread on WASM: rust-lang/rust#33205

Inputs are welcome!

[github-actions]

Warning: The issue has been out-of-update for 50 days, marking stale.

[WenheLI]

It seems that Emscripten itself is switching to the LLVM WASM backend.
https://v8.dev/blog/emscripten-llvm-wasm

So one decision to be made: do we directly generate WASM via LLVM or go through Emscripten?

The former saves us from adding the dependency on Emscripten.
The latter can generate Javascript as well, which has better compatibility. Emscripten also seems better documented than LLVM WASM backend.

A question to Web experts: how well supported is WASM on current browsers? If everyone's browser already supports WASM (https://caniuse.com/#feat=wasm) then maybe we should directly use the LLVM WASM backend?

An old Rust thread on WASM: rust-lang/rust#33205

Inputs are welcome!

@yuanming-hu
I think directly export taichi to wasm should be fine. The majority of browsers have supported this feature. And, asm.js could be used as a fallback to wasm. Therefore, it should be fine to use WASM in most cases.