Generic target for runtime is not generic

[shoaibkamil]

I have been working on a branch (shoaibkamil/webgpu_update_mini_webgpu) that is updating WebGPU support, starting first with updating to the latest version of Dawn. Using the instructions in doc/WebGPU.md results in a crash when executing any Native Dawn WebGPU test in JIT mode on my arm64 macOS machine. After much debugging/tracing, I believe the issue boils down to an ABI mismatch: Halide appears to pass a parameter in a register, while the loaded Dawn dylib expects the function to be passed on the stack, resulting in a memory access violation.

I believe this is because our "generic" compilation for the runtime uses x86_64 and either Apple's Darwin ABI or the arm64 base ABI have different rules for when structs get passed on the stack vs in registers. However, I haven't yet created a minimal case.

The easiest repro is to build Dawn (following instructions in doc/WebGPU.md on macOS ARM, and then to checkout my branch, build Halide, and try to execute correctness_hello_gpu or any other GPU pipeline.

[shoaibkamil]

CC: @alexreinking who also encountered this issue when trying to update WebGPU.

[shoaibkamil]

What did work, just to unstuck me, but not as a general solution, is to change our "generic" ABI from x86_64 to arm64 to match my local environment, in case anyone also gets stuck with inexplicable memory access violations from within GPU libraries.

[abadams]

Our generic ABI is supposed to be generic by virtue of never doing anything that might behave differently under different ABIs (e.g. always using padding-free struct field ordering, never passing structs by value). Would be nice if we could enforce this statically somehow. Unfortunately GPU APIs sometimes demand code that wouldn't pass such a check. We probably need a shim runtime module compiled with a specific ABI to wrap the problematic functions.

[mcourteaux]

I believe this is because our "generic" compilation for the runtime uses x86_64 and either Apple's Darwin ABI or the arm64 base ABI have different rules for when structs get passed on the stack vs in registers.

What did work, just to unstuck me, but not as a general solution, is to change our "generic" ABI from x86_64 to arm64 to match my local environment

What does this mean exactly? Can you elaborate? What is the "generic compilation" and "generic ABI" you refer to?

Are you talking about HL_TARGET=wasm-32-wasmrt-webgpu ? What about HL_TARGET=host-webgpu?

[shoaibkamil]

What does this mean exactly? Can you elaborate? What is the "generic compilation" and "generic ABI" you refer to?

If you look at src/runtime/CMakeLists.txt, you'll see that we compile the runtime into as-generic-as-possible IR using the LLVM target (I believe around line 245-248) i386-unknown-unknown-unknown and x86_64-unknown-unknown-unknown. This is what I'm referring to.

I'm specifically talking about HL_TARGET=host-webgpu on an M1 running macOS. In this case, there is a mismatch between the expectation of libwebgpu_dawn.dylib and the Halide runtime in terms of how the parameters need to be passed.