| ▲ | GPU Offload in Rust: Portable, Safe, and Fast(arxiv.org) | |||||||||||||||||||||||||
| 107 points by linggen 4 hours ago | 17 comments | ||||||||||||||||||||||||||
| ▲ | YuechenLi 2 minutes ago | parent | next [-] | |||||||||||||||||||||||||
So... why go through LLVM at all instead of having the MIR target PTX/HIP C directly then? If they really wanted a vendor neutral solution for Rust GPU, that already exists: you write the CPU side code, including buffering, allocation, concurrency, etc through Vulkan binding and consume the compute kernel in SPIR-V from HLSL/GLSL/WGSL etc. As it stands, the way they use Rust here feels more like using it like TypeScript types/interfaces than anything else. Again, the size of most operations that should be done on the GPU is known ahead of time before compilation, so it's very much possible to statically allocate memory at compile time instead of going through all this trouble to write what's essentially a Rust shaped DSL for GPU compute. | ||||||||||||||||||||||||||
| ▲ | whateverboat 28 minutes ago | parent | prev | next [-] | |||||||||||||||||||||||||
> This module is under active development. Once upstream, it should allow Rust developers to run Rust code on GPUs. We aim to develop a rusty GPU programming interface, which is safe, convenient and sufficiently fast by default. This includes automatic data movement to and from the GPU, in a efficient way. We will (later) also offer more advanced, possibly unsafe, interfaces which allow a higher degree of control. I really appreciate the work and the effort that went into this. However, such an approach has previously not really worked for C++ with LLVM offload. Why would it work for Rust? | ||||||||||||||||||||||||||
| ▲ | boywitharupee 35 minutes ago | parent | prev | next [-] | |||||||||||||||||||||||||
is this mainly about making host binaries self-contained for heterogenous workloads? also, seems like this is mostly targeted towards HPC audience? | ||||||||||||||||||||||||||
| ▲ | Thomashuet 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||
That's promising but did they publish any code? I can't find anything in the abstract. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
| ▲ | maxchisto an hour ago | parent | prev | next [-] | |||||||||||||||||||||||||
does anyone know Mojo well enough to comment how Rust + gpu-offload compares to it? | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
| ▲ | jasonjmcghee 2 hours ago | parent | prev | next [-] | |||||||||||||||||||||||||
> the rust-gpu project has to emulate pointers[8], which we consider a blocking issue for most HPC benchmarks. Why is it a blocking issue? I feel like this is very aligned with the goals of rust-gpu. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
| ▲ | Alephinitesimal an hour ago | parent | prev | next [-] | |||||||||||||||||||||||||
The NVIDIA+AMD support is the part I find really interesting. I know OpenMP and SYCL can already target multiple GPU vendors, but doing this while keeping Rust's safety model seems pretty compelling. I'm curious how portable the performance is in practice. | ||||||||||||||||||||||||||
| ▲ | rfgplk 2 hours ago | parent | prev [-] | |||||||||||||||||||||||||
Fascinating how many people still overcomplicate offloading to GPUs. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||