How does this relate to tracel-ai/cubecl

[JackWolfard]

In the transition announcement, tracel-ai/cubecl was brought up as

Compute language extension for Rust. Enables annotated Rust code to run on the GPU.

What are / will be the key differences between the rust-gpu project and CubeCL?

[schell]

I can speak to this at least a bit, but I expect @eddyb and @LegNeato can elaborate. Having not used CubeCL myself I'm basing my comparison on their readme.

The big difference I see here is that rust-gpu compiles Rust code to SPIR-V. What this means is that it is runtime agnostic. If your runtime can interpret SPIR-V, then you can use rust-gpu to write your shaders/compute in Rust. Personally use wgpu for graphics work, but you can use Vulkan, Metal, DX - literally any "runtime" that accepts SPIR-V.

With rust-gpu you can use just about all the bells and whistles of no_std Rust (like importing external crates, defining types, traits, etc). rust-gpu accomplishes this by using a rustc compiler backend. So it really is a proper Rust development experience. You can even publish your shader crates to crates.io, and share code between GPU and CPU targets .

Now like I said earlier I've never used CubeCL, but it seems the project is using a proc macro that parses the contained Rust code using syn and then emits some other GPU code inline. This means your shader code must always be wrapped in this way with some adjoining code that orchestrates it. I wonder if you can import other modules?

That said I bet the barrier to entry for CubeCL is lower. Since the runtime is integrated, there's no GPU context to set up. With rust-gpu you definitely have to bring your own GPU context, be that from one of the graphics layers I mentioned earlier or from somewhere else.

Anyway - that's my interpretation of the situation.

[LegNeato]

Yep, basically it! They key difference to me is "annotated code". Which means you can only use code specifically written with CubeCL in mind. With rust-gpu, one can use existing rust code for the gpu (no_std and no alloc currently).

There are of course differences between CubeCL's parsing / proc macro implementation vs rust-gpu's compiler backend. The compiler back end is strictly more powerful, but it's also harder to use vs just slapping on a proc macro.