Example using wasm

[VarLad]

Are there any examples which combine WGPUNative.jl and julia to produce wasm? Perhaps using https://github.com/arhik/WASMCompiler.jl or StaticCompiler.jl?

[arhik]

Hi.

No. Priority was on cross platform GPU compute. WASMCompiler and WASMTools.jl are an attempt towards combining them primarily but didn't manage to bridge them yet.

[VarLad]

Ok, thanks!
I'll try reviving WebAssemblyCompiler this week.
More generally I am working on a KA --> WGSL pipeline, and would really like to see it working on a browser 🙂
Perhaps WgpuCompute.jl can reuse that as well.

[arhik]

I appreciate that.

[arhik]

Just to clear things up: You won't need WGPUNative.jl. Mostly KA->WGSL involves transpilation and browser functionality requires glue code to load compute shader and Array interface in js/wasm.

[VarLad]

@arhik I was looking into that, but I have a lot of julia code to go along with KA code (as KA is typically used), and I'm currently not sure how to handle this.
Maybe julia wasm (after performing some array transformations) --> js --> webgpu (using webgpu js api)?

[arhik]

Design space is huge here. If you are not attached to KA and wasm compilation, it would be simpler. You may not like my suggestion and understand that it is just one way among other possibilities. But if i were you; I would start from the browser end. Take a sample WGSL compute kernel that works on array input and outputs array (basic elementwise operation would be sufficient). Slowly work towards making julia to emit WGSL (Not thinking WASM compilation at this stage. I would also suggest to leave KA part out. Its not the major hurdle here since DSL to DSL transformation is just an abstraction layer you can skip). Major hurdles are how to design array interface and WebIO like interaction (only if you want this. I would prefer repl and browser interaction initially [headless] so I am giving pointers in this direction). There must be many projects that does array operation which you can borrow. We might also need to think about custom allocator for linear memory (supporting stack and heap allocations). I am not upto date with current WASM progress and improvements. I am using my old memory right now. Once simple kernel is working and array interface looks generic for all kernels definitions you can do KA->WGSL generation that matches expected array interface. KA-WGSL should not be main focus for initial project stages. Not sure if this is what you are expecting, but you can take AI thinking models suggestions. They could be better at ideation than I am.

After making this work, It would give us ample idea to push everything to frontend slowly including JuliaWGPU aspects using WASM instead of js code.

Like I said, Design space is huge and it depends on how you want it. if you want everything to be in browser then its more involved and time taking. You can compromise and take shortcuts like webserver interaction for short timelines you can invest.

If you want to continue working in this space you can work all the way to developing compute pipeline frameworks like other DL frameworks do. etc ...

Or, You can go other way and skip browser parts. Stick to KA-WGSL project and work on Native GPU compute instead (with or without wasm). See them as separate projects and prioritize. Tweaking them simultaneously is third option, which you might be more interesting is to take is touch both julia wasm compilation end and browser end. Then you will enter this explicit array allocation, gpu buffer lifetime management and data movement for array interface. (GC or use Bump allocator for array interface etc ...).

its upto you to jump directly to third option as long as you know what you are doing. Thats what I did actually. I had pointer type issues in wasm code generation if I remember correctly. I see julia has a new typed pointer type. It could be right time to look into this again.

[arhik]

I am extremely sleep. Sorry If I am incoherent. Just want to respond right away before I forget.