Nvidia announces native GPU programming in Rust • Hacker News Board

Re: Nvidia announces native GPU programming in Rust

#401

Post by preg_match » Thu, Sep 17, 2026, 9:34 PM UTC

Asmod4n wrote: post #215

preg_match wrote: post #173

Earlier quoted context omitted.

Yes but there are business costs to using high-level proprietary tools and libraries. If you write your app using win32, you won’t be able to port is very easily. You’re also stuck with whatever bad or bizarre decisions Microsoft made. It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gaug…

Win32 is the most stable abi on the Linux desktop.

Correct, most of Linux user land targets API stability, not ABI stability. Windows targets ABI stability because applications are typically distributed as binary blobs. Most applications on Linux are open-source and built per each distro, so it’s a non-issue, just recompile.

This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows.

Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in.

And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.

Re: Nvidia announces native GPU programming in Rust

#402

Post by loup-vaillant » Thu, Sep 17, 2026, 9:37 PM UTC

surajrmal wrote: post #338

loup-vaillant wrote: post #314

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

They don't need to do that to sell their hardware so why would they do that? On the other hand, they have strong incentives to not give you that level of access and information. The only way this will change is by having some disruption by way of a competitor who sells hardware with that feature as being a major reason why it takes off.

Or we could regulate. One hammer I'm tempted to use is to simply forbid sales and importation of hardware made by companies that also distribute software. That way the only way to sell you hardware is to make sure its interfaces are both simple and thoroughly documented.

We could possibly make an exception for open source software, or only forbid the distribution of the relevant drivers, or limit the applicability of that law to specific hardware: hard drives, mice, printers, web cams... or GPUs.

Anyway, that should be disruption enough.

Re: Nvidia announces native GPU programming in Rust

#403

Post by apitman » Thu, Sep 17, 2026, 9:43 PM UTC

loup-vaillant wrote: post #314

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

And

https://www.sebastianaaltonen.com/blog/no-graphics-api

Re: Nvidia announces native GPU programming in Rust

#404

Post by loup-vaillant » Thu, Sep 17, 2026, 9:48 PM UTC

floil wrote: post #359

loup-vaillant wrote: post #314

Okay, so, GPUs are taking one more step towards being general purpose massively parallel machines. That's cool. What would be even cooler though would be for GPU vendors to start giving us the user manual. An I mean the real user manual, that explains how to use their piece of metal when all you have is that piece of metal . That means a precise description of the wire protocols, the data format of the buffers we sen…

They don't release it because exposing a stable instruction set would kill their ability to quickly iterate, to release silicon with bugs that can be papered over with software fixes, as fixing bugs in chips is very expensive in terms of time to market, and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature. It's been this way for 25 years and I don't see it changing.

> exposing a stable instruction set would kill their ability to quickly iterate

I believe the need to quickly iterate dropped significantly since we got shaders. I would bet in fact there was few such iterations in the last 10 years. Crazy increases in computing power of course, but big breaking changes in the actual ISA? I'd be surprised.

> to release silicon with bugs that can be papered over with software fixes

Yeah that's actually one of my goals. Only ship stuff that works on pain of embarrassment and prohibitive recall costs. It's crazy hard. It's how CPUs are shipped.

> and undoubtedly to charge more for what looks like a hardware feature but actually is a software feature.

Again, that's good. Such pricing tactics are scummy, I want to end them.

---

Now of course, those reasons you cited are reasons for the vendor not to do what I'm pretty sure is very good for the consumer. I propose we force them. We could start small. Mice and keyboards first. Then printers. Then webcams, wifi modules... until we get to GPUs themselves.

Re: Nvidia announces native GPU programming in Rust

#405

Post by mathisfun123 » Thu, Sep 17, 2026, 10:18 PM UTC

loup-vaillant wrote: post #399

mathisfun123 wrote: post #368

Earlier quoted context omitted.

> GPUs are taking one more step towards being general purpose massively parallel machines this has nothing to do with becoming more general purpose (GPUs will never be general purpose - it's literally physically impossible).

> GPUs will never be general purpose Well in that sense, neither will CPUs. Just like GPUs, some workloads are better left to other kinds of hardware.

i really don't think you know what you're talking about. this isn't about better or worse. there are many many many workloads a GPU cannot at all implement (hint: anything with branches).

Re: Nvidia announces native GPU programming in Rust

#406

Post by Ericson2314 » Thu, Sep 17, 2026, 11:39 PM UTC

To everyone skeptical of people saying that it's better to separate CPU and GPU code into separate files, riddle me this:

With this system, how do we specify whether dependencies are needed to be compiled for the CPU, GPU, or both?

----

Technically I don't know really care whether it's multiple files or one, I just want to make sure we are not reinventing a shittier version of CFG. What they are providing looks to me like:

1. explicitly annotate some things as `cfg(GPU)` or ungated (both)

2. unlabeled means annotated `cfg(not(GPU))` by definitely

Put this way, this has nothing to do with GPUs, and just has to do with creating some crate-local CFG shorthanded. Great! Let's do that first, get a solid foundation, and then come back to whatever is remaining for CUDA Rust.