Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I recently became aware of a high-level language called Futhark [1] that fits well in that space. It is statically-typed and functional.
Maybe some other array languages work in the GPU as well, I don't know.
[1] https://futhark-lang.org/
With reference to the section on how difficult it is to build wpgu-native and how you basically have to use a precompiled binary, there appears to be an easier way to integrate a Cargo library into a CMake project: https://github.com/corrosion-rs/corrosion
Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.
WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.
[1] https://github.com/hexops/mach-examples
[2] https://github.com/hexops/mach#supported-zig-version
Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.
WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.
[1] https://github.com/hexops/mach-examples
[2] https://github.com/hexops/mach#supported-zig-version
Loads of people have stated why easy GPU interfaces are difficult to create, but we solve many difficult things all the time.
Ultimately I think CPUs are just satisfactory for the vast vast majority of workloads. Servers rarely come with any GPUs to speak of. The ecosystem around GPUs is unattractive. CPUs have SIMD instructions that can help. There are so many reasons not to use GPUs. By the time anyone seriously considers using GPUs they're, in my imagination, typically seriously starved for performance, and looking to control as much of the execution details as possible. GPU programmers don't want an automagic solution.
So I think the demand for easy GPU interfaces is just very weak, and therefore no effort has taken off. The amount of work needed to make it as easy to use as CPUs is massive, and the only reason anyone would even attempt to take this on is to lock you in to expensive hardware (see CUDA).
For a practical suggestion, have you taken a look at https://arrayfire.com/ ? It can run on both CUDA and OpenCL, and it has C++, Rust and Python bindings.
BTW. For the last 15 years, all web browsers on Windows do WebGL on top of DirectX (using the Angle library https://github.com/google/angle).
PS: also if shader functions could be directly defined "inline" in regular CPU code (and behind a special function pointer type), there would be no need for string literal shenanigans like this:
https://github.com/floooh/sokol-samples/blob/3f10c1a0620cec9...
(and shader compilation would happen during the regular build and would also generate regular compiler errors - with current toolchains that's only possible with a lot of build system magic)