Live data from Hacker News

Rust running on every GPU

rust-gpu.github.io

131–140 of 211 posts

Re: Rust running on every GPU

#131
post #51

I write native audio apps, where every cycle matters. I also need the full compute API instead of graphics shaders. Is the "Rust -> WebGPU -> SPIR-V -> MSL -> Metal" pipeline robust when it come to performance? To me, it seems brittle and hard to reason about all these translation stages. Ditto for "... -> Vulkan -> MoltenVk -> ...". Contrast with "Julia -> Metal", which notably bypasses MSL, and can use native optim…

I must agree that for numerical computation (and downstream optimisation thereof) Julia is much better suited than ostensibly "systems" language such as Rust. Moreover, the compatibility matrix[1] for Rust-CUDA tells a story: there's seemingly very little demand for CUDA programming in Rust, and most parts that people love about CUDA are notably missing. If there was demand, surely it would get more traction, alas, i…

It's not just that. See CUDA EULA at https://docs.nvidia.com/cuda/eula/index.html

Section 1.2 Limitations:

     You may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to **target a non-NVIDIA platform**.
Emphasis mine.

Re: Rust running on every GPU

#132
post #127

Earlier quoted context omitted.

Regardless if the game is using Wine or not, when the exceedingly growing Linux customerbase start complaining about bugs while running the game on their Steam Decks, the developers will notice. It doesn't matter if the game was supposed to be running on Microsoft Windows ™ with Bill Gate's blessings. If this is how a significant number of customers want to run the game, the developers should listen. If the devs then…

Valve will notice, devs couldn't care less.

I'll hold on to my optimism.

Re: Rust running on every GPU

#133
post #130
post #126

Earlier quoted context omitted.

Hears an idea, Get Nvidia, AMD, Intel and whoever else you can get into a room. Get LLVMs boys into the same room. Compile LLVMIR directly into hardware instructions fed into the GPU, get them to open up. Having to target an API is part of the problem, get them to allow you to write Rust that directly compiles into the code that will run on the GPU, not something that becomes something else, that becomes spirv that c…

Hell will freeze over, then go into negative Kelvin temperatures before you see nVidia agreeing in earnest to do so. They make too much money on NOT GETTING COMMODITIZED. nVidia even changed CUDA to make API not compatible with interpreters. It's the same reason Safari is in such a sorry state. Why make web browser better, when it could cannibalize your app store?

Somehow I want to believe if you get everyone else in the room, and it becomes enough of a market force that nvidia stops selling GPUs because of it, they will change. Cough linux gpu drivers

Re: Rust running on every GPU

#134

Earlier quoted context omitted.

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 at least you have the tools to do so. That's one of the nice things about the rust ecosystem, you can drill down and do what you want. There is std::arch, which is platform specific, th…

> but that's because this was the first time it is possible Using SPIRV as abstraction layer for GPU code across all 3D APIs is hardly a new thing (via SPIRVCross, Naga or Tint), and the LLVM SPIRV backend is also well established by now.

LLVM SPIR-V's backend is a bit... questionable when it comes to code generation.

Re: Rust running on every GPU

#135

Earlier quoted context omitted.

> but that's because this was the first time it is possible Using SPIRV as abstraction layer for GPU code across all 3D APIs is hardly a new thing (via SPIRVCross, Naga or Tint), and the LLVM SPIRV backend is also well established by now.

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 device apis. You could make an argument that CubeCL enabled something similar first, but it is more a DSL that looks like Rust rather than the Rust language proper(but still cool).

> This is the first time it is possible for Rust host + device across all these platforms and OSes and device apis.

I thought wgpu already did that. The new thing here is you code shaders in rust, not WGSL like you do with wgpu

Re: Rust running on every GPU

#136

Earlier quoted context omitted.

> I suppose GPUs are slowly going through a similar process now that they're useful in many more domains than just graphics. I've been waiting for the G in GPU to be replaced with something else since the first CUDA releases. I honestly think that once we rename this tech, more people will learn to use it.

MPU - Matrix Processing Unit LAPU - Linear Algebra Processing Unit

PPU - Parallel processing unit

Re: Rust running on every GPU

#137
Very interesting. I wonder about the model of storing the GPU IR in binary for a real-world project; it seems like that could bloat the binary size a lot.

I also wonder about the performance of just compiling for a target GPU AOT. These GPUs can be very different even if they come from the same vendor. This seems like it would compile to the lowest common denominator for each vendor, leaving performance on the table. For example, Nvidia H-100s and Nvidia Blackwell GPUs are different beasts, with specialised intrinsics that are not shared, and to generate a PTX that would work on both would require not using specialised features in one or both of these GPUs.

Mojo solves these problems by JIT compiling GPU kernels at the point where they're launched.

Re: Rust running on every GPU

#138
post #126

Earlier quoted context omitted.

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 think we'd ever pull in things like wgpu, but we might create APIs or traits wgpu could use to improve perf/safety/ergonomics/interoperability.

Hears an idea, Get Nvidia, AMD, Intel and whoever else you can get into a room. Get LLVMs boys into the same room. Compile LLVMIR directly into hardware instructions fed into the GPU, get them to open up. Having to target an API is part of the problem, get them to allow you to write Rust that directly compiles into the code that will run on the GPU, not something that becomes something else, that becomes spirv that c…

Sounds sort of like the idea behind MLIR and it's GPU dialects.

* https://mlir.llvm.org/docs/Dialects/NVGPU/

* https://mlir.llvm.org/docs/Dialects/AMDGPU/

* https://mlir.llvm.org/docs/Dialects/XeGPU/

Re: Rust running on every GPU

#139

Earlier quoted context omitted.

Realistically though, a user can only hope to operate at (3) or maybe (4). So not as much of an add. (Abstraction layers do not stop at 6, by the way, they keep going with firmware and microarchitecture implementing what you think of as the instruction set.)

Don't know about you, but I consider 3 levels of abstraction a lot, especially when it comes to such black-boxy tech like GPUs. I suspect debugging this Rust code is impossible.

Debugging the Rust is the easy part. I write vanilla CUDA code that integrates with Rust and that one is the hard part. Abstracting over the GPU backend w/ more Rust isn't a big deal, most of it's SPIR-V anyway. I'm planning to stick with vanilla CUDA integrating with Rust via FFI for now but I'm eyeing this project as it could give me some options for a more maintainable and testable stack.

Re: Rust running on every GPU

#140

Earlier quoted context omitted.

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 device apis. You could make an argument that CubeCL enabled something similar first, but it is more a DSL that looks like Rust rather than the Rust language proper(but still cool).

> This is the first time it is possible for Rust host + device across all these platforms and OSes and device apis. I thought wgpu already did that. The new thing here is you code shaders in rust, not WGSL like you do with wgpu

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 your code in a shader lang it wouldn't run on the CPU (as they are made for GPU only) or via CUDA.
Post reply on HN