[WebGPU] Unify Emscripten and dawn-native paths in the runtime #7248
Comments
|
Is there any plan as to when/if this will get resolved? |
|
One comment in #6492 suggests that the lack of support for |
Yeah, this is the expected name for the solution for the
We're focusing on getting V1 of WebGPU shipped in Chrome really soon [1], and then we expect to have a renewed focus on making the native vs web story better. So yes, these things will get resolved, but I can't give an exact timeframe right now. |
|
Ah, gotcha, thanks. FYI, googling for |
It's in the header (which I think is just a copy of Dawn's header), but the implementation is still absent: |
Halide promises that you can crosscompile to *any* supported target from a 'stock' build of libHalide. Unfortunately, the initial landing of WebGPU support breaks that promise: we compile the webgpu runtime support (webgpu.cpp) with code that is predicated on `WITH_DAWN_NATIVE` (for Dawn vs Emscripten, respectively). This means that if you build Halide with `WITH_DAWN_NATIVE` defined, you can *only* target Dawn with that build of Halide; similarly, if you build with `WITH_DAWN_NATIVE` not-defined, you can only target Emscripten. (Trying to use the 'wrong' version will produce link-time errors.) For people who build everything from source, this isn't a big deal, but for people who just pull binary builds, this is a big problem. This PR proposes a temporary workaround until the API discrepancies are resolved: - Compile the existing webgpu.cpp runtime *both* ways - in LLVM_Runtime_Linker.cpp, select the correct variant based on whether the Target is targeting wasm or not - Profit! This is a rather ugly hack, but it should hopefully be (relatively) temporary.
* Split WebGPU runtime into two variants (#7248 workaround) Halide promises that you can crosscompile to *any* supported target from a 'stock' build of libHalide. Unfortunately, the initial landing of WebGPU support breaks that promise: we compile the webgpu runtime support (webgpu.cpp) with code that is predicated on `WITH_DAWN_NATIVE` (for Dawn vs Emscripten, respectively). This means that if you build Halide with `WITH_DAWN_NATIVE` defined, you can *only* target Dawn with that build of Halide; similarly, if you build with `WITH_DAWN_NATIVE` not-defined, you can only target Emscripten. (Trying to use the 'wrong' version will produce link-time errors.) For people who build everything from source, this isn't a big deal, but for people who just pull binary builds, this is a big problem. This PR proposes a temporary workaround until the API discrepancies are resolved: - Compile the existing webgpu.cpp runtime *both* ways - in LLVM_Runtime_Linker.cpp, select the correct variant based on whether the Target is targeting wasm or not - Profit! This is a rather ugly hack, but it should hopefully be (relatively) temporary. * A few more fixes * Update HalideGeneratorHelpers.cmake * Update interpreter.cpp * Update interpreter.cpp
|
As of Aug 2023, Emscripten/Dawn now support (and require) wgpuCreateInstance() and wgpuInstanceRelease() in non-native code, so I updated those in #7804. (wgpuInstanceProcessEvents() and wgpuAdapterGetLimits() are still unimplemented.) |
|
As of now, wgpuInstanceProcessEvents() and wgpuAdapterGetLimits() are both present in webgpu.h -- are they still nonfunctional? |
|
For future reference the Emscripten implementation is here, and it's usually easy to search for these functions since they are present but both just |
|
...sigh. Is there any path or plan for them to implement them? |
|
Since WebGPU API issues have come up again, I see these are still unimplemented; is there any likely path to them getting there, or should we assume this is just a long-term API divergence? |
|
I've asked the folks closer to this, and the response is still that we should eventually get to a world where you can target both native and Emscripten without any |
…de#7419) * Split WebGPU runtime into two variants (halide#7248 workaround) Halide promises that you can crosscompile to *any* supported target from a 'stock' build of libHalide. Unfortunately, the initial landing of WebGPU support breaks that promise: we compile the webgpu runtime support (webgpu.cpp) with code that is predicated on `WITH_DAWN_NATIVE` (for Dawn vs Emscripten, respectively). This means that if you build Halide with `WITH_DAWN_NATIVE` defined, you can *only* target Dawn with that build of Halide; similarly, if you build with `WITH_DAWN_NATIVE` not-defined, you can only target Emscripten. (Trying to use the 'wrong' version will produce link-time errors.) For people who build everything from source, this isn't a big deal, but for people who just pull binary builds, this is a big problem. This PR proposes a temporary workaround until the API discrepancies are resolved: - Compile the existing webgpu.cpp runtime *both* ways - in LLVM_Runtime_Linker.cpp, select the correct variant based on whether the Target is targeting wasm or not - Profit! This is a rather ugly hack, but it should hopefully be (relatively) temporary. * A few more fixes * Update HalideGeneratorHelpers.cmake * Update interpreter.cpp * Update interpreter.cpp
There are a few differences in the native APIs implemented by Emscripten and Dawn that mean Halide's WebGPU backend currently requires a build-time switch to select between the two. Once these differences are resolved, we should be able to remove this conditional logic and the build-time switch.
The differences are:
wgpuCreateInstanceandwgpuReleaseInstancewgpuAdapterGetLimitsemscripten_sleep()vsusleep()(e.g.wgpuInstanceProcessEvents())emscripten_sleep()vswgpuDeviceTick()(e.g.wgpuInstanceProcessEvents())The text was updated successfully, but these errors were encountered: