Live data from Hacker News

Rust running on every GPU

rust-gpu.github.io

91–100 of 211 posts

Re: Rust running on every GPU

#91

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…

> 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

Re: Rust running on every GPU

#92

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…

[deleted]

Re: Rust running on every GPU

#93

Earlier quoted context omitted.

Genuine question since you seem to care about the performance: As an outsider, where we are with GPUs looks a lot like where we were with CPUs many years ago. And (AFAIK), the solution there was three-part compilers where optimizations happen on a middle layer and the third layer transforms the optimized code to run directly on the hardware. A major upside is that the compilers get smarter over time because the abstr…

The status quo in GPU-land seems to be that the compiler lives in the GPU driver and is largely opaque to everyone other than the OS/GPU vendors. Sometimes there is an additional layer of compiler in user land that compilers into the language that the driver-compiler understands. I think a lot of people would love to move to the CPU model where the actual hardware instructions are documented and relatively stable bet…

i think intel and amd provide ISA docs for their hw. not sure about nvidia didnt check it in forever

Re: Rust running on every GPU

#94

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…

Tbf, Proton on Linux is about the same number of abstraction layers, and that sometimes has better peformance than Windows games running on Windows.

Re: Rust running on every GPU

#95

Earlier quoted context omitted.

I think you are very experienced in this subject. Can you explain what's wrong with WebGPU? Doesn't it utilize like 80% of the cool features of the modern GPUs? Games and ambitious graphics-hungry applications aside, why aren't we seeing more tech built on top of WebGPU like GUI stacks? Why aren't we seeing browsers and web apps using it? Do you recommended learning it (considering all the things worth learning nowad…

First of all WebGPU has only been supported in Chrome for a few months and Firefox in the next release. And that's just Windows. We haven't had enough time to develop anything really. Secondly, the WebGPU standard is like Vulkan 1.0 and is cumbersome to work with. But that part is hearsay, I don't have much experience with it.

gpu is often cumbesome tho. i mean, openGL, Vulkan, they are not really trivial?

Re: Rust running on every GPU

#96

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…

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.

Re: Rust running on every GPU

#97

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…

That looks like the graphics stack of a modern game engine. Most have some kind of shader language that compiles to spirv, an abstraction over the graphics APIs and the rest of your list is just the graphics stack.

Re: Rust running on every GPU

#98

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.

You posted this comment in a browser on an operating system running on at least one CPU using microcode. There are more layers inside those (the OS alone contains a laundry list of abstractions). Three levels of abstractions can be fine.

Re: Rust running on every GPU

#99
post #79

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…

In fairness, the ability to restructure at will probably does make it easier to improve things.

Re: Rust running on every GPU

#100
post #61

Earlier quoted context omitted.

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

Complexity is not inherently bad. Browsers are more or less exactly as complex as they need to be in order to allow users to browse the web with modern features while remaining competitive with other browsers. This is Tesler's Law [0] at work. If you want to fully abstract away GPU compilation, it probably won't get dramatically simpler than this project. [0]: https://en.wikipedia.org/wiki/Law_of_conservation_of_comp…

I swear, if I had 2c for every supposed "law", I would be a millionaire now. Slogans make no law, but programmers sure love "naming things." In all fairness, the obsessive elevating of good-sounding slogans into colloquial "laws" is a uniquely American phenomenon. My pet-theory is that this goes back to old days when computer science wasn't considered a "real" science. That is, in "real" sciences there are laws, so the American computer science guys felt like inventing "laws" to be taken seriously.
Post reply on HN