Steven Johnson

Nope, OSX should be fine. I assume that both x86 and arm variants should work?

Hi there -- I'm (finally) looking at getting testing in place, so we can land this, and some of the comments from your original post may or may not be...

FYI: I took the liberty of adding 'support' for isinf(), isnan(), and isfinite(), so that Halide code that uses these won't fail to compile outright. (I realize the spec explicitly...

As of now, running the tests with Dawn-native (ie host-webgpu), the only tests failing are: ``` 234 - correctness_multi_way_select (Subprocess aborted) 518 - performance_async_gpu (Failed) 520 - performance_boundary_conditions (Failed) 588...

~~So it looks to me like this backend isn't currently safe to use from multiple threads -- we store device (etc) in a global, but competing threads can overwrite this...

Please take a look at https://github.com/jrprice/Halide/pull/1 at your convenience.

What's the technical reason that we can't support WebGPU under the JIT? EDIT: I assume that at least part of the reason is that we'd need to add callback bindings...

> The WebGPU runtime code requires Emscripten when targeting WASM in order to translate calls to the native WebGPU runtime API into the Javascript API. Wait, so the WebGPU runtime...

~~OK, now I'm testing the AOT tests using Emscripten/Node (building with HL_TARGET=wasm-32-wasmrt-webgpu and WEBGPU_NODE_BINDINGS set to the right path), and some (but not all) of the tests fail with `ReferenceError:...

So, running the generator tests under Node, most of them pass, but these three fail: 548 - generator_aot_acquire_release (Failed) 549 - generator_aot_alias (Failed) 565 - generator_aot_gpu_only (Failed) In all cases,...