Live data from Hacker News

Rust running on every GPU

rust-gpu.github.io

81–90 of 211 posts

Re: Rust running on every GPU

#81
post #71

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…

And yet, we are still using handwritten assembly for hot code paths. All these abstraction layers would need to be porous enough to allow per-device specific code.

> And yet, we are still using handwritten assembly for hot code paths

This is actually a win. It implies that abstractions have a negligible (that is, existing but so small that can be ignored) cost for anything other than small parts of the codebase.

Re: Rust running on every GPU

#82

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…

Though if the rust compiles to NVVM it’s exactly as bad as C++ CUDA, no?

Re: Rust running on every GPU

#84

Certainly impressive that this is possible! However, for my use cases (running on arbitrary client hardware) I generally distrust any abstractions over the GPU api, as the entire point is to leverage the low level details of the gpu. Treating those details as a nuisance leads to bugs and performance loss, because each target is meaningfully different. To overcome this, a similar system should be brought forward by th…

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 abstractions are more evergreen than the hardware targets.

Is that sort of thing possible for GPUs? Or is there too much diversity in GPUs to make it feasible/economical? Or is that obviously where we're going and we just don't have it working yet?

Re: Rust running on every GPU

#85
post #48

Earlier quoted context omitted.

Maybe the fact that we have all these games running on Linux now, and as a result more gamers running Linux, developers will be more incentivized to consider native support for Linux too. Regardless, "native" is not the end-goal here. Consider Wine/Proton as an implementation of Windows libraries on Linux. Even if all binaries are not ELF-binaries, it's still not emulation or anything like that. :)

Why should they be incentivized to do anything, Valve takes care of the work, they can keep targeting good old Windows/DirectX as always. OS/2 lesson has not yet been learnt.

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 choose to improve "Wine compatibility" or rebuild for Linux doesn't matter, as long as it's a working product on Linux.

Re: Rust running on every GPU

#86
post #52

Earlier quoted context omitted.

Khronos APIs are the C++ of graphics programming, there is a reason why professional game studios never do political wars on APIs. Decades of exerience building cross platform game engines since the days of raw assembly programming across heterogeneous computer architectures. What matters are game design and IP, that they eventually can turn into physical assets like toys, movies, collection assets. Hardware abstract…

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.

Re: Rust running on every GPU

#87
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.

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.

Re: Rust running on every GPU

#88
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.

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…

The first portable programming language was, uh, Fortran. Indeed, by the time the Unix developers are thinking about porting to different platforms, there are already open source Fortran libraries for math routines (the antecedents of LAPACK). And not long afterwards, the developers of those libraries are going to get together and work out the necessary low-level kernel routines to get good performance on the most powerful hardware of the day--i.e., the BLAS interface that is still the foundation of modern HPC software almost 50 years later.

(One of the problems of C is that people have effectively erased pre-C programming languages from history.)

Re: Rust running on every GPU

#89

Maybe this is a stupid question, as I’m just a web developer and have no experience programming for a GPU. Doesn’t WebGPU solve this entire problem by having a single API that’s compatible with every GPU backend? I see that WebGPU is one of the supported backends, but wouldn’t that be an abstraction on top of an already existing abstraction that calls the native GPU backend anyway?

Isn't webgpu 32-bit?

WebAssembly is 32bit. WebGPU uses 32bit floats like all graphics does. 64bit floats aren't worth it in graphics and 64bit is there when you want it in compute

Re: Rust running on every GPU

#90

Certainly impressive that this is possible! However, for my use cases (running on arbitrary client hardware) I generally distrust any abstractions over the GPU api, as the entire point is to leverage the low level details of the gpu. Treating those details as a nuisance leads to bugs and performance loss, because each target is meaningfully different. To overcome this, a similar system should be brought forward by th…

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 between different GPUs. But that's impossible to do unless the GPU vendors commit to it.

Post reply on HN