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

Nvidia announces native GPU programming in Rust

developer.nvidia.com

Post reply on HN
Print view View original

311–320 of 349 posts

Re: Nvidia announces native GPU programming in Rust

#311

Post by miki123211 »

rfgplk wrote: post #281
josephg wrote: post #132

Earlier quoted context omitted.

If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.

> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with…

The problem is much deeper than that. Most OSes' syscall ABIs are not stable and could change without warning. What is stable is the dynamically-loaded libraries, shipped as part of the system. Linux is the notable exception here; the Linux kernel project doesn't ship a libc, and Linus is very famously opposed to "breaking userspace."

There's nothing that can stop you from using syscalls in theory, but if you want your app to be portable across different OS versions, past and future, you'd better not.

Incidentally, syscalls would also break Wine. The way Wine works is basically by shipping their own versions of Windows DLLs, which express their operations in terms of Linux APIs. Because Windows programs don't rely on syscalls, and call all system functions via the system-provided libraries, the Wine loader can just link Wine's version and let the program work normally.

Re: Nvidia announces native GPU programming in Rust

#313

Post by lenkite »

tombert wrote: post #45
jacobgorm wrote: post #12

I strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both. The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, e…

> I strongly dislike CUDA. Once you have allowed that proprietary cr*p Genuine question...why not just type "crap"? It's not even that much of a curse, but I've never really understood the point of self-censorship. If you don't want to curse then you could just use a non-curse word.

Because nanny states are tracking your keyboard nowadays.

Re: Nvidia announces native GPU programming in Rust

#314

Post by loup-vaillant »

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 send to & get from the GPU, the ISA of the cores we have access to, the relevant performance characteristics…

In other words, enough information to write a state-of-the-art driver for any OS. That would be cool.

Re: Nvidia announces native GPU programming in Rust

#315

Post by da_chicken »

Hendrikto wrote: post #257
fg137 wrote: post #28

Earlier quoted context omitted.

> Once you have allowed that proprietary cr*p into your C++ codebase People have been doing that all the time for every kind of codebase. It's just part of the business. I don't see how it's worth having any emotions or opinions about it. Seems like you are wasting your energy. Are win32 APIs proprietary? So you decide to use them, use a wrapper/UI framework, or don't develop for Windows. Easy choice. Developing for…

> I don't see how it's worth having any emotions or opinions about it. Ironic, seeing as that is an opinion about it. Also weird telling people in an online discussion forum not to have opinions.

Oh, does that mean I get to say you're ironic because, literally, they didn't tell anyone to do anything. They said they didn't understand the worth of the opinion. You're interpretation is selectively literal in order to be rhetorical.

Does that mean someone else gets say I'm being ironic because I'm selectively literal in order to be rhetorical? Well, okay, I guess it's harder now.

Re: Nvidia announces native GPU programming in Rust

#316

Post by fc417fc802 »

pjmlp wrote: post #310
dev_hugepages wrote: post #256

Earlier quoted context omitted.

If i'm not mistaken, this already exists, and the assembly language here is called PTX https://llvm.org/docs/NVPTXUsage.html

PTX is a bytecode format, the CUDA driver JIT compiles it when uploading into the cards.

Can't the same also be said of much of the x86 vocabulary at this point?

I appreciate that we can upload SPIR-V directly. The API still feels overly obtuse but it's not so bad.

SYCL gets close but is language specific.

Re: Nvidia announces native GPU programming in Rust

#317

Post by vhiremath4 »

rfgplk wrote: post #281
josephg wrote: post #132

Earlier quoted context omitted.

If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.

> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with…

> This isn’t even close to being true. Here’s a thing I did that made things way more complicated than is worth it for 99% of developers when there is a proprietary solution made so I do not need to worry about these things. Because it is so hard to work around it, it is entirely pointless to develop for one of the most used operating systems in the world.

Just being totally honest this is how I read this comment when I insert context that seems important to me. I respect having principles but at some point there needs to be more value in practicality over your codebase not being locked into a proprietary framework at all.

Re: Nvidia announces native GPU programming in Rust

#318

Post by eggy »

adgjlsfhk1 wrote: post #62
melodyogonna wrote: post #18

Earlier quoted context omitted.

You could also use Mojo, one language for all targets.

Or julia if you want a much more mature ecosystem.

Julia has had a great CUDA story for a few years now, and this about 9 days old. Rust rejects buffer aliasing at compile time using Rust's borrow checker, but shared memory in cuda-oxide currently requires unsafe, but then there's HuggingFace's Grout and mistral.rs, so yeah, Rust is picking up ground here on Julia. How is OpenCL's performance these days?

Re: Nvidia announces native GPU programming in Rust

#319

Post by mschuetz »

david-gpu wrote: post #307
mschuetz wrote: post #298

Earlier quoted context omitted.

> The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, Yes, I also prefer doing it that way, but in Cuda with the driver API. Allows you to handle kernels like shaders, including editing and hot-reloading at runtime. The reason I'm sticking with CUDA is because it's by far the most convenient API to use, w…

> The reason I'm sticking with CUDA is because it's by far the most convenient API to use, without nonsense like 50-liners to alloc memory or the need to manage descriptors, bindings, queue families, etc. I was there when the OpenCL committee was deciding on that sort of stuff. As I recall, and it's been two decades and a lot of sleepless nights since then, there was real pushback at the time against OpenGL-style def…

That's unfortunate. Cuda has shown that, when done right, defaults and a convenience layer can make for a well received API without sacrificing performance.
Post reply on HN