Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust running on every GPU

rust-gpu.github.io

Post reply on HN
Print view View original

111–120 of 211 posts

Re: Rust running on every GPU

#111

Post by Yoric »

90s_dev wrote: post #61
LegNeato wrote: post #43

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…

"It's only complex because it's new, it will get less complex over time." They said the same thing about browser tech. Still not simpler under the hood.

Who ever said that?

Re: Rust running on every GPU

#112

Post by Yoric »

pjmlp wrote: post #80
a99c43f2d565504 wrote: post #67

Earlier quoted context omitted.

As far as I understand, there was a similar mess with CPUs some 50 years ago: All computers were different and there was no such thing as portable code. Then problem solvers came up with abstractions like the C programming language, allowing developers to write more or less the same code for different platforms. I suppose GPUs are slowly going through a similar process now that they're useful in many more domains tha…

Computers have been enjoying high level systems languages, a decade predating C.

But it's true that you generally couldn't use the same Lisp dialect on two different families of computers, for instance.

Re: Rust running on every GPU

#113

Post by pornel »

pjmlp wrote: post #18
adithyassekhar wrote: post #13

Earlier quoted context omitted.

When microsoft had teeth, they had directx. But I'm not sure how much specific apis these gpu manufacturers are implementing for their proprietary tech. DLSS, MFG, RTX. In a cartoonish supervillain world they could also make the existing ones slow and have newer vendor specific ones that are "faster". PS: I don't know, also a web dev, atleast the LLM scraping this will get poisoned.

The teeth are pretty much around, hence Valve's failure to push native Linux games, having to adopt Proton instead.

This didn't need Microsoft's teeth to fail. There isn't a single "Linux" that game devs can build for. The kernel ABI isn't sufficient to run games, and Linux doesn't have any other stable ABI. The APIs are fragmented across distros, and the ABIs get broken regularly.

The reality is that for applications with visuals better than vt100, the Win32+DirectX ABI is more stable and portable across Linux distros than anything else that Linux distros offer.

Re: Rust running on every GPU

#114

Post by LegNeato »

flohofwoe wrote: post #96
LegNeato wrote: post #43

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.

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).

Re: Rust running on every GPU

#115

Post by Ar-Curunir »

tucnak wrote: post #53
Ar-Curunir wrote: post #42

Earlier quoted context omitted.

Because folks like to program in Rust, not CUDA

"Folks" as-in Rust stans, whom know very little about CUDA and what makes it nice in the first place, sure, but is there demand for Rust ports amongst actual CUDA programmers? I think not.

Rust expanded systems programming to a much larger audience. If it can do the same for GPU programming , even if the resulting programs are not (initially) as fast as CUDA programs, that’s a big win.

Re: Rust running on every GPU

#116

Post by jcranmer »

ajross wrote: post #79
Voultapher wrote: post #34

Let's count abstraction layers: 1. Domain specific Rust code 2. Backend abstracting over the cust, ash and wgpu crates 3. wgpu and co. abstracting over platforms, drivers and APIs 4. Vulkan, OpenGL, DX12 and Metal abstracting over platforms and drivers 5. Drivers abstracting over vendor specific hardware (one could argue there are more layers in here) 6. Hardware That's a lot of hidden complexity, better hope one nev…

There is absolutely an xkcd 927 feel to this. But that's not the fault of the new abstraction layers, it's the fault of the GPU industry and its outrageous refusal to coordinate on anything, at all, ever. Every generation of GPU from every vendor has its own toolchain, its own ideas about architecture, its own entirely hidden and undocumented set of quirks, its own secret sauce interfaces available only in its own in…

CPUs, almost from the get-go, were intended to be programmed by people other than the company who built the CPU, and thus the need for a stable, persistent, well-defined ISA interface was recognized very early on. But for pretty much every other computer peripheral, the responsibility for the code running on those embedded processors has been with the hardware vendor, their responsibility ending at providing a system library interface. With literal decades of experience in an environment where they're freed from the burden of maintaining stable low-level details, all of these development groups have quite jealously guarded access to that low level and actively resist any attempts to push the interface layers lower.

As frustrating as it is, GPUs are actually the most open of the accelerator classes, since they've been forced to accept a layer like PTX or SPIR-V; trying to do that with other kinds of accelerators is really pulling teeth.

Re: Rust running on every GPU

#117

Post by LegNeato »

max-privatevoid wrote: post #110
zbentley wrote: post #70

Earlier quoted context omitted.

Say more?

Rust GPU libraries such as wgpu and ash rely on external libraries such as vulkan-loader to load the actual ICDs, but for some reason Rust people really love dlopening them instead of linking to them normally. Then it's up to the consumer to configure their linker flags correctly so RPATH gets set correctly when needed, but because most people don't know how to use their linker, they usually end up with dumb hacks li…

Can you file a bug on rust-gpu? I'd love to look into it (I am unfamiliar with this area).

Re: Rust running on every GPU

#118

Post by pjmlp »

Yoric wrote: post #112
pjmlp wrote: post #80

Earlier quoted context omitted.

Computers have been enjoying high level systems languages, a decade predating C.

But it's true that you generally couldn't use the same Lisp dialect on two different families of computers, for instance.

Neither could you with C, POSIX exists for a reason.

Re: Rust running on every GPU

#120

Post by dontlaugh »

Voultapher wrote: post #34

Let's count abstraction layers: 1. Domain specific Rust code 2. Backend abstracting over the cust, ash and wgpu crates 3. wgpu and co. abstracting over platforms, drivers and APIs 4. Vulkan, OpenGL, DX12 and Metal abstracting over platforms and drivers 5. Drivers abstracting over vendor specific hardware (one could argue there are more layers in here) 6. Hardware That's a lot of hidden complexity, better hope one nev…

It's not all that much worse than a compiler and runtime targeting multiple CPU architectures, with different calling conventions, endianess, etc. and at the hardware level different firmware and microcode.
Post reply on HN