4 ms·

That's quite interesting, but I wonder what Rust brings to the table here. From my understanding of GLSL, it seemed like the hardware was in control of schedul

That's quite interesting, but I wonder what Rust brings to the table here. From my understanding of GLSL, it seemed like the hardware was in control of scheduling, and the driver that compiled the shaders was the one inserting locks, fences, etc. GPUs seem like a bad fit for run-time exceptions and return value checking (? operator?) since they are so poor at branching, being SIMD. The more you can check ahead of time, the better, and Rust isn't such a bad fit there. But given that Rust's main advantages seem to be the ability to safely control multiple execution threads, and its handling of edge cases, I wonder if the first is going to be used at all, and if the second isn't going to lead to extra instructions?

adamnemecek 6y ago
I'm going to guess that it's a subset of Rust.
ironmagma 6y ago
Rust has hygienic macros and a package manager, at least. It'd also be nice to have a common language that you could run on the CPU for debugging purposes. I see this more as a moonshot type project though, where if you could accomplish it, it would mostly just speed up Rust's time to utility for other similar use cases like embedded development.
Impossible 6y ago
Another advantage (for Embark) is their main engine codebase is also in Rust. This allows for sharing of some code on GPU and CPU. This isn't uncommon in the game industry, for example header files that compile in both C++ and HLSL in order to share struct definitions for CPU code and GPU code, and CPU math libraries that use HLSL types and semantics. Rust is different enough from GLSL and HLSL (most game engines use HLSL as "native" and cross compile to GLSL, MSL or use header defines to build PSSL) that introducing a new shading language compatible with Rust is probably worth the effort for them.
flohofwoe 6y ago
The main benefit is that the GPU-side code can better integrate with the CPU-side code, and that you don't need separate tools and a complex build process integration. For instance it's possible to share data structure between the CPU and GPU side directly from the same source code, or you can run the same code on the CPU or GPU for whatever reason (debugging, unit testing etc...). The Metal API uses C++ (with some extensions) as shader language, which IMHO is complete overkill too, but one nice side effect is that you can put shared data structures into headers, and then include the same shared headers on the CPU and GPU side. Ideally it should be possible to mix GPU and CPU code in the same source file, and only (for instance) annotate GPU functions with an attribute which causes it to be compiled as shader code.

adamnemecek 6y ago

I'm going to guess that it's a subset of Rust.

ironmagma 6y ago

Rust has hygienic macros and a package manager, at least. It'd also be nice to have a common language that you could run on the CPU for debugging purposes. I see this more as a moonshot type project though, where if you could accomplish it, it would mostly just speed up Rust's time to utility for other similar use cases like embedded development.

Impossible 6y ago

Another advantage (for Embark) is their main engine codebase is also in Rust. This allows for sharing of some code on GPU and CPU. This isn't uncommon in the game industry, for example header files that compile in both C++ and HLSL in order to share struct definitions for CPU code and GPU code, and CPU math libraries that use HLSL types and semantics. Rust is different enough from GLSL and HLSL (most game engines use HLSL as "native" and cross compile to GLSL, MSL or use header defines to build PSSL) that introducing a new shading language compatible with Rust is probably worth the effort for them.

flohofwoe 6y ago

The main benefit is that the GPU-side code can better integrate with the CPU-side code, and that you don't need separate tools and a complex build process integration. For instance it's possible to share data structure between the CPU and GPU side directly from the same source code, or you can run the same code on the CPU or GPU for whatever reason (debugging, unit testing etc...). The Metal API uses C++ (with some extensions) as shader language, which IMHO is complete overkill too, but one nice side effect is that you can put shared data structures into headers, and then include the same shared headers on the CPU and GPU side. Ideally it should be possible to mix GPU and CPU code in the same source file, and only (for instance) annotate GPU functions with an attribute which causes it to be compiled as shader code.