LegNeato

5 ms·

31.
by LegNeato 8mo ago
Yes, that's the idea. GPU-wide memory is not quite as scarce on datacenter cards or systems with unified memory. One could also have local executors with local futures that are `!Send` and place in a faster address space.
32.
by LegNeato 9mo ago
We use the cuda device allocator for allocations on the GPU via Rust's default allocator.
33.
by LegNeato 9mo ago
Flip on the pedantic switch. We have std::fs, std::time, some of std::io, and std::net(!). While the `libc` calls go to the host, all the `std` code in-between runs on the GPU.
34.
by LegNeato 9mo ago
Author here! Flip on the pedantic switch, we agree ;-)
35.
by LegNeato 1y ago
1. The GPU owns the control loop And the only sparingly kicks to the CPU when it can't do something. 2. Yes 3. We're still investigating the limitations. A lot of them are hardware dependent, obviously data center cards have highe
36.
by LegNeato 1y ago
You might be interested in a previous blog post where we showed one codebase running on many types of GPUs: https://rust-gpu.github.io/blog/2025/07/25/rust-on-every-gpu...
37.
by LegNeato 1y ago
No worries, just wanted to correct it for folks. Thanks for posting!
38.
by LegNeato 1y ago
One of the founders here, feel free to ask whatever. We purposefully didn't put much technical detail in the post as it is an announcement post (other people posted it here, we didn't).
39.
by LegNeato 1y ago
Pedantic note: rust-cuda was created by https://github.com/RDambrosio016 and he is not currently involved in VectorWare. rust-gpu was created by the folks at embark software. We are the current maintainers of both. We didn&
40.
by LegNeato 1y ago
Yes, it is all these folks getting together and getting resources to push those projects to the next level: https://www.vectorware.com/team/ wgpu, ash, and cudarc are great. We're focusing on the actual code that
41.
by LegNeato 1y ago
We are investing in them and they form the basis of what we are doing. That being said, we are also exploring other technical avenues with different tradeoffs...we don't want to assume a solution merely because we are familiar with the
42.
by LegNeato 1y ago
More software than you think can run fully on the GPU, especially with datacenter cards. We'll be sharing some demos in the coming weeks.
43.
by LegNeato 1y ago
We have some demos coming in the next couple weeks. The hardware is there, the software isn't!
44.
by LegNeato 1y ago
Yeah, there is way more prior art. We were doing this at FB early (here is a talk from 2014 mentioning it but it was much earlier: https://www.infoq.com/presentations/facebook-release-process... ) and we definitely did
45.
by LegNeato 1y ago
FYI, you can drop down into ptx if need be: https://github.com/Rust-GPU/Rust-CUDA/blob/aa7e61512788cc702...
46.
by LegNeato 1y ago
I have not, it is easy to get in touch with me though.
47.
by LegNeato 1y ago
Yes, see the proposed WG link I posted above. When I say GPU I'm using it as shorthand...indeed, I think the "graphics" part is on borrowed time and will just become fully software. It is already happening.
48.
by LegNeato 1y ago
https://github.com/Rust-GPU/Rust-CUDA/tree/main/crates/cudnn and the parent dir has more.
49.
by LegNeato 1y ago
Thanks! I'm personally focused on compute, while other contributors are focused on graphics. I believe GPUs are the future of computing. I think the tooling, languages, and ecosystems of GPUs are very bad compared to CPUs. Partially be
50.
by LegNeato 1y ago
The underlying projects support loading at runtime, so you could have as many AOT compiled kernel variants and load the one you want. Disk is cheap. You could even ship rustc if you really wanted for "JIT" (lol), but maybe not sup
51.
by LegNeato 1y ago
Correct. The new thing is those shaders/kernel also run via CUDA and on CPU unchanged. You could not do that with only wgpu...there is no rust shader input, (and the thing that enables it rust-gpu which is used here) and if you wrote
52.
by LegNeato 1y ago
Can you file a bug on rust-gpu? I'd love to look into it (I am unfamiliar with this area).
53.
by LegNeato 1y ago
Those don't include CUDA and don't include the CPU host side AFAIK. SPIR-V isn't the main abstraction layer here, Rust is. This is the first time it is possible for Rust host + device across all these platforms and OSes and d
54.
by LegNeato 1y ago
You can check out https://rust-gpu.github.io/ecosystem/ as well, which mentions CubeCL.
55.
by LegNeato 1y ago
FYI, rust-cuda outputs nvvm so it can integrate with the existing cuda ecosystem. We aren't suggesting rewriting everything in Rust. Check the repo for crates that allow using existing stuff like cudnn and cuBLAS.
56.
by LegNeato 1y ago
And it uses 3rd party deps from crates.io that are completely GPU unaware.
57.
by LegNeato 1y ago
Many of us working on Rust + GPUs in various projects have discussed starting a GPU working group to explore some of these questions: https://gist.github.com/LegNeato/a1fb3e3a9795af05f22920709d9... Agreed, I don't
58.
by LegNeato 1y ago
The demo is admittedly a rube goldberg machine, but that's because this was the first time it is possible. It will get more integrated over time. And just like normal rust code, you can make it as abstract or concrete as you want. But
59.
by LegNeato 1y ago
To be more technically correct, we compile to NVVM IR and then use NVIDIA's NVVM to convert it to PTX.
60.
by LegNeato 1y ago
Rust is a system language, so you should have the control you need. We intend to bring GPU details and APIs into the language and core / std lib, and expose GPU and driver stuff to the `cfg()` system. (Author here)

More ›