AMD Working To 'Push Rust Deep into the GPU Stack' (phoronix.com) 81
Phoronix reports:
AMD is building out what they are describing as an "elite" team of developers for driving Rust code "deep into the GPU stack" from firmware to drivers, shader compilers, and other GPU software in Rust. AMD Senior Fellow Harsh Meno posted this week to LinkedIn about this new effort...
And note this AMD job posting that's active for hiring a software development engineer to work on Rust code...
"We are building next-generation systems software for AMD GPUs with Rust as a core technical direction. The work spans compilers, runtimes, low-level GPU software, firmware, developer tooling, and methods for improving the safety and correctness of complex hardware-software systems.
"Rust is not incidental to this role. You will help establish how Rust is used in performance-sensitive and high-trust parts of the GPU stack, including the compiler and tooling support, system interfaces, engineering practices, and validation methods required for production deployment. You will have the opportunity to influence both near-term implementations and the longer-term architecture for using Rust across current and future AMD platforms."
"AMD also isn't alone," the article points out, "as NVIDIA has also been pursuing similar Rust-based initiatives for their GPU software too, including the development of the Nova Linux kernel driver written in Rust."
And note this AMD job posting that's active for hiring a software development engineer to work on Rust code...
"We are building next-generation systems software for AMD GPUs with Rust as a core technical direction. The work spans compilers, runtimes, low-level GPU software, firmware, developer tooling, and methods for improving the safety and correctness of complex hardware-software systems.
"Rust is not incidental to this role. You will help establish how Rust is used in performance-sensitive and high-trust parts of the GPU stack, including the compiler and tooling support, system interfaces, engineering practices, and validation methods required for production deployment. You will have the opportunity to influence both near-term implementations and the longer-term architecture for using Rust across current and future AMD platforms."
"AMD also isn't alone," the article points out, "as NVIDIA has also been pursuing similar Rust-based initiatives for their GPU software too, including the development of the Nova Linux kernel driver written in Rust."
Isn't rust bad for computers though? (Score:1)
Re: (Score:2)
Well technically speaking rust conducts reasonably well (much less than iron of course), but one of the problem is that rust is larger than iron. It pushes apart the material, creates tears, and that is what reduces conductivity.
History will remember 2026 (Score:2)
Not if you make it spin really fast. (Score:2)
Re: (Score:1)
Artificial Intelligence (Score:3)
How does AI do with Rust? It seems like most of the AI generated code is in HTML, Typescript, and Python. Is it capable of advanced work in Rust?
Re: (Score:3, Interesting)
LLMs focusing on code generation can generate code in nearly any language.
I for example use them sometimes for the initial "frame" of Dart/Flutter languages.
I worked a while with an unknown LLM (unknown, as it was a research project and the LLMs involved did not disclose their names), that LLM claimed it only needs to see the grammar or examples of a private language I use.
As I never bothered to write a formal grammar for it, I gave it a few thousand lines of code. Then it started asking a few questions, an
Re:Artificial Intelligence (Score:5, Informative)
I understand. It's true most AIs can generate code in virtually any language. But, my experience has been that the code quality drops precipitously if the language is not one of the ones I've mentioned and as the code base grows.
SQL is great. C and C# not so great. Powershell, surprisingly bad after about 50 or more lines.
Re: (Score:2)
python and js is great. I think rust is fine, because the language has some hard rules, which are easy to follow and in case the AI does not follow them the compiler gives a hard error. AIs can iterate quite well on hard errors, the weakness is subtle mistakes that can't be caught by compilers, linters, etc.
Re: Artificial Intelligence (Score:2)
Re: (Score:2)
Yeah, but why? A shell script is usually a grown command line, which first was a breve concatenation of a few commands. If you have a LLM to do it again from scratch, let it use a better programming language. Analyzing and maintaining existing shell scripts is fine, but why generate new ones?
Re: Artificial Intelligence (Score:2)
Re: (Score:2)
I usually use them until they are either slow because of spawning too many programs or become unreadable or fragile (escaping paths with special characters can become messy) and then rewrite in python.
Re: (Score:2)
Re: (Score:2)
Yes, I think I agree very much. And python is just a personal choice and not necessarily the best (it doesn't enforce type checks). The point is to have something that syntax checks, runs in a single process, has a reasonable standard library and a syntax that doesn't want to expand variables and macros everywhere. Look at how bad a for loop over file lists can break in bash. In python a list of strings doesn't care about spaces, in bash you can do for file in *.txt; but if you try for file in $MY_FILE_LIST
Re: (Score:2)
Your point about variables that contain lists is almost reason enough to avoid shell scripting altogether. The requirements and syntax for various forms of quoting (such as backticks and equivalents) can b
Re: (Score:2)
export HISTCONTROL=ignoreboth
export HISTSIZE=10000
export HISTFILESIZE=10000
HISTFILE="$HOME/.bash_history"
if [[ -z "$HISTFILE" || ! -f "$HISTFILE" ]]; then
echo "Error: HISTFILE is no
Re: (Score:2)
I'd say using shellscripting in a .bashrc kinda makes sense :D
Re: (Score:2)
maintaining existing shell scripts is fine, but why generate new ones?
Because they run on linux and on windows and Macs and other Unixes just fine?
The interpreter is preinstalled ... and frankly, I used Python only for "toys" so far, or gluing together some stuff.
So I would need to learn a lot of things ...
I find bash okay for scripting, and there is a "new shell" called Fish, which has a nicer language.
https://fishshell.com/ [fishshell.com]
Re: (Score:2)
You don't know how many /bin/sh scripts with bashisms I've seen. Shell scripts are a mess and you notice errors only when they arrive at the broken line. Use a scripting language that at least catches basic syntax errors.
Re: (Score:2)
For Linux/Unix scripting?
No thanx :P
Re: (Score:2)
For anything that was a shellscript and grew to more than 50 lines.
Re: (Score:2)
In general my scripts are pretty small, and call each other.
Aka a master script calling the other scripts.
In general via "sourcing" them.
Re: (Score:2)
Re: (Score:2)
Nice link!
Re:Artificial Intelligence (Score:5, Interesting)
We have used LLM's to generate a lot of Rust very successfully. I would rather trust AI generating Rust than almost any other language because the Rust compiler is so fussy about types and object lifetimes that it gives the LLM far less opportunity to sneaky silly, hard to find, errors in. Also Rust's error messages are very comprehensive and helpful, which LLM's make good use of.
Re: (Score:2)
Re: Artificial Intelligence (Score:2)
no choice (Score:1)
I hope they don't expect Rust to do magic (Score:5, Interesting)
Also, ROCm certainly is not in its pitiful state just because "the wrong programming language was used".
Re:I hope they don't expect Rust to do magic (Score:4, Insightful)
This is an incredibly frustrating time to try to use a GPU in general. On Windows, both drivers are shit. On Linux, the closed source drivers are all shit, but the AMD OSS driver is pretty good. And despite this, AMD won't open the floodgates and give away enough information to actually make it as good as it could be. They have absolute proof that they cannot do as well as the community, but they absolutely refuse to let the data flow. And yet, they are still multiple times as helpful as Nvidia.
Re: (Score:2)
They have absolute proof that they cannot do as well as the community, but they absolutely refuse to let the data flow.
I really wonder what they think they are hiding.
Re: I hope they don't expect Rust to do magic (Score:1)
Re: (Score:2)
Exceptionally unlikely. The NSA cannot do magic and such a backdoor would need to access hardware it has no business accessing. That is blatantly obvious. In addition, any such backdoors (which will NOT be generally distributed, far too much risk of them being found and hence worthless), will sit in the CPU "security" processors that can, for example, wait for certain patterns to show up.
That said, supply chain attacks on software and compromising developers (such as Microsoft...) are far easier.
Re: (Score:2)
Probably jus general no-clue management stupidity. I man, all other GPU makers can just invest a bit of time and money and find out everything anyways.
Re: (Score:2)
Re: (Score:2)
Yes. Or the design of a chip from the chip itself, although that is more expensive. But it is still peanuts compared to the effort that goes into GPUs.
Re: (Score:2)
Re: (Score:2)
Rust does help somewhat, but, as Linus put it "Rust can prevents some errors, but it does not prevent logic bugs". The biggest advantage of Rust is IMO that it is not easy to learn. That should keep most of the low-skill coders (which is most coders, sadly) out. Obviously, LLM used as fake coders can eliminate that advantage. Another reason why that is generally a bad idea, especially as LLMs are nowhere near reasonable reliability and cause technological debt by writing longer and more complex code than a
Re: (Score:2)
Re: (Score:2)
Ah, no. LLM hallucinations and LLM limitations will not go away. And LLM code is never easy to audit for people. In fact, there is mounting evidence that reviewing LLM code is hard, boring, unrewarding and comes with major burnout risks. Unlike a junior dev that eventually understands what they are doing wrong and gets better at things (or gets removed), LLMs are doing the same mistakes over and over again and do not learn. And they are doing is verbosely, which makes things worse.
Hence having an LLM create
Re: (Score:2)
But in general, memory errors are some of the most common causes of a large variety of issues - using vulnerabilities. If you're not carefully tracking lifetimes of memory allocations (and in a kernel where the code is re-entrant, this gets tricky fast) it's way too easy to have issues like a use-after-free or a memory leak.
At best, it's a kernel crash. At worst, it's a privilege escalation bug
The latest New Shiny Bandwagon ... (Score:2)
... has the full orchestra on it it seems. Reminds me of when every webdev was extolling the virtues of Ruby to whoever would listen. How often do you see any mention of it now?
Wtf is the point of Rust at the to-the-metal level when by definition most of what you do will be unsafe memory wise? Seems to me like some Rust shills have been evangelising to devs still at the age where they can't differentiate marketing BS from fact.
Re:The latest New Shiny Bandwagon ... (Score:5, Informative)
Not a Rust / GPU dev but what I got from some articles is it greatly reduces the surface area in which memory safety bugs can live, since only the to-the-metal areas are in unsafe blocks, plus Rust gives you synchronization support to avoid race conditions. The drawback is compile time and missing the newest parts of the ecosystem. Asahi Linux' Rust based Apple GPU driver has only 3% unsafe code so a lot less code can go wrong.
https://www.reddit.com/r/rust/... [reddit.com]
Re: (Score:3)
Reminds me of when every webdev was extolling the virtues of Ruby to whoever would listen.
Ruby on Rails is the best dynamically typed language available for Webdev. Python has more developers, so if you build on RoR, you might need to train some people. If you want a statically typed language for webdev (usually better on very large projects), C# as a language is great, but the ecosystem around Java is better.
Wtf is the point of Rust at the to-the-metal level when by definition most of what you do will be unsafe memory wise?
Rust is useful when you have to work with incompetent programmers, which is most of them these days, especially those who write kernel drivers. If you encapsulate the driver accesses in fun
Rust is FAST. Ruby is slow (Score:4, Interesting)
... has the full orchestra on it it seems. Reminds me of when every webdev was extolling the virtues of Ruby to whoever would listen. How often do you see any mention of it now?
Wtf is the point of Rust at the to-the-metal level when by definition most of what you do will be unsafe memory wise? Seems to me like some Rust shills have been evangelising to devs still at the age where they can't differentiate marketing BS from fact.
WTAF Dude? Have you been so burnt by the past that you can't see when the industry does something right for a change? Rust gives nearly indistinguishable performance from C with memory safety and nearly equal efficiency. Isn't that what greybeards have been clamoring for since Java arrived (PSA: Java is nearly as fast as C for long running processes, like servers, but a HOG for RAM)? While I am too new at it to find rust intuitive or pleasant (I still understand C more), you can't argue with the results.
Ruby was a massive failure because arrogant hipsters coupled a pretty good idea (rails) with a dogshit arrogant language that traded masturbatory elegance for performance and usefulness. You already know this, I wager.
Rust delivers. Now regarding nVidia? Well, I am not GPU driver dev, but I would wager that it's not going to be manipulating memory registers. However, the nVidia driver download is nearly 1 GIGABYTE. I am sure a LOT of that code is not manipulating memory, but high-level functions that could benefit from Rust.
Re: (Score:2)
Java is only a "Hog for RAM" if you write code for that hogging.
Old school Java had not "concurrent garbage collection".
So it literally ran until the memory was used up, and the moment you called "new Object()" the memory allocator said: oops we are out of memory.
As multithreaded clean up is not trivial (at that time, because no one really knew how to do it), the VM stopped all threads, reclaimed unused memory and did the so called "stop the world garbage collection".
In our times, we have concurrent multi t
Re: (Score:2)
Java is only a "Hog for RAM" if you write code for that hogging.
Old school Java had not "concurrent garbage collection".
So it literally ran until the memory was used up, and the moment you called "new Object()" the memory allocator said: oops we are out of memory.
Has nothing to do with Java or with (insert other perceived memory hungry language) - it is a matter how you program.
Remember all the claims of java being just as fast and memory efficient some two decades ago. At the time I found them mildly amusing. Today I assume those who persist with the same assertions especially using unfalsifiable doing it wrong / it's the programmer nonsense are merely engaged in gaslighting.
Whatever happened to the operating systems written in java running on processors that natively execute java byte-code? Enough time has elapsed to where any inertia based excuses should have been overcome
Re: (Score:2)
Our entire stack runs in a smaller footprint than the ram needed to fire up a JVM just to print "Hello World".
Obviously. And that was not the point.
Re: (Score:2)
I would wager that it's not going to be manipulating memory registers.
That's pretty much what device drivers do. They turn high-level calls to do X into bare-metal instructions. And they very much need to deal with all the ugliness that entails to do their job well.
I'm very much in favor of safer languages and tools for user-mode programming (heck, I consider SQL my third main language), but firmware ain't for everyone. If you don't need to think in terms of cycles, side effects, execution units, and pipelining, sure, save your sanity and use whatever language makes it eas
Sure (Score:1)
Trust? (Score:2, Insightful)
” Rust is not incidental to this role. You will help establish how Rust is used in performance-sensitive and high-trust parts of the GPU stack, including the compiler and tooling support, system interfaces, engineering practices, and validation methods required for production deployment. You will have the opportunity to influence both near-term implementations and the longer-term architecture for using Rust across current and future AMD platforms.”
Who is going to use Rust in a trusted compute environment? Rust isn't trustworthy, it has no mechanism for independent validation or verification using cross compilation from multiple toolchains. Rust is often regarded as being “memory safe”, which it absolutely is not, since it has an “unsafe” keyword. You can't have an “unsafe” keyword and at the same time claim you're safe. Even without the unsafe keyword, you can still corrupt memory, which effectively makes all
Re: (Score:2)
Re: (Score:2)
Then you get into problems like its language spec doesn't exist as a final
Re:Trust? (Score:4, Informative)
it has no mechanism for independent validation or verification using cross compilation from multiple toolchains
You can compile an older toolchain with mrustc [github.com] (which is a C++ project), and then work your way up to the recent version.
Rust is often regarded as being “memory safe”, which it absolutely is not, since it has an “unsafe” keyword. You can't have an “unsafe” keyword and at the same time claim you're safe
"Unsafe" sections in Rust are typically small isolated code blocks, in contrary to legacy system programming languages like C and C++, where the entire application is unsafe.
Even without the unsafe keyword, you can still corrupt memory
No, you cannot corrupt memory outside of unsafe block. As far as I remember, there was one compiler bug where you could bypass the borrow checker with some very tricky code, however I don't think you can find this in production.
Re: (Score:1)
It needs an independent compiler, not an older one built upwards, that would just produce the same lack o
Re: (Score:2)
Re: (Score:2)
Re:Trust? (Score:5, Insightful)
Rust is often regarded as being “memory safe”, which it absolutely is not, since it has an “unsafe” keyword.
I think you may have just written the dumbest words ever put to text in a technical context (sorry but Slashdot politics still has your post beat). The whole point of memory safety is that you explicitly need to make a conscious decision to avoid it and do so in an auditable way.
Re: (Score:1)
Re: (Score:1)
I think you may have just written the dumbest words
And we all know you're a shithead from the sheer number of shitposts [slashdot.org] you do on a daily basis.
Re: (Score:2)
Re: (Score:2)
A number of US TLAs appear to be actively developing in Rust and requiring contractors implementing "high-side" systems to do the same. C++ seems to be on its way out now. Not sure if that's the smart move. There's millions of man-hours in C++ libraries and utilities that likely need to be converted, if the edict is "Rust only" for sensitive systems. Kinda reminds me of the Ada days.
Re: (Score:2)
Rust might turn out to be an excellent solution, but it's not there yet, so from an engineering prospective, it's not an option if you really have a sensitive system. You can write bulletproof C, or probably bulletproof any language, you just have to understand what you're d
Re: (Score:2)
Any programming language needs the equivalent of Rust's "unsafe". Without it would be impossible to do any input or output. The language would be useless. It is far better to have such unsafe code clearly wrapped up and delimited in "unsafe" blocks rather than have memory unsafely permeate the entire code base.
Why are people using C++? The spec for the language isn't finished, the tooling isn't finished.
Rust has met the claims of its creators extremely well. It's not Rust's fault if some crazy "evangelists
Re: (Score:2)
Any programming language needs the equivalent of Rust's "unsafe". Without it would be impossible to do any input or output.
U wot? unsafe in Rust lets you scribble cheerfully over memory. That's different from I/O.
Why are people using C++? The spec for the language isn't finished,
I don't even...? I mean the spec for C++23 is finished and ratified. The spec for C++26 isn't but 2026 isn't over yet...
the tooling isn't finished.
What as in all C++ compilers have failed to reach their final versions with no upda
Re: (Score:2)
Before Rust can be considered ready for production, it needs a stable spec, multiple compilers that are independent, and, it has to drop the stupid, id
Re: (Score:2)
> Any programming language needs the equivalent of Rust's "unsafe"
Not really, no.
> Without it would be impossible to do any input or output.
Have you ever used any programming languages other than C, C++, etc? The important thing is that the language itself implements an interface between the OS and programs written in that language. In addition to that, most usually have an ABI that can be used to glue assembler libraries to the language - this is not the equivalent of "unsafe", because it's not part
Re: (Score:2)
An utterly stupid comment.
Hint: it is possible to write a Rust program, that does not use the "unsafe" keyword.
Re: (Score:2)
Re: (Score:2)
"unsafe stuff" can not travel into the "save world".
So: it is not useless.
You can completely narrow down where something "unsafe" is happening.
No idea what your problem is, did you ever even program anything?
There is no reason at all that program can not be 100% safe. By simply not having the need to use any "unsafe" stuff.
I program mostly in Dart, all my code is 100% safe.
Re: (Score:2)
Re: (Score:2)
The keyword makes a single variable, or a small block of code "unsafe".
The rest of the code is still safe. So what is your problem?
You do not grasp the concept?
Well, your problem, then continue to code in C, and everything in your code is unsafe, and you can safe the usage of the keyword unsafe.
Of course you could fake the keyword:
#define unsafe
And off you go!
When you have to write safe code, that is used for automotive, or military, you can't use pointers, function pointers, or the cool new features of mos
Re: (Score:2)
Re: (Score:2)
You have some serious misconceptions.
Either it is a linguistic problem, that you do not grasp the meaning of words, or you are a kind of autist.
I am happy that you are not in my team.
I simply do not like to argue about idiotic claims like this:
C is not unsafe, the developer writes unsafe C code, C is just as safe as Rust,
If you do not intentionally write unsafe code in Rust: the code is safe.
If you write C, then frankly, an uneducated moron - or idiotic nitpicker - like you seem to be: does not know if the
Re: (Score:2)
Safety is either absolute or it's not, a degree of safety, which is what Rust provides, is the same as not having safety at all, from a functional standpoint. All I'm saying by that statement is you have to assume you have no safety. Why start with the assumption that what you're going to build is safe, so you can be unprofessional, rushed, sloppy, and careless? What i
Re: (Score:2)
Safety does not need to be absolute to be present.
It is just your idiotic definition of your perceived idea of "safety". A safety belt is a safety belt. Nevertheless your car can be hit by a fuel truck, spilled all over and catch fire.
for instance not misusing NULL, but do you trust them, or, do you write code to check them?
Nope, if a language is null safe, like Dart, I do not check for null.
That would be idiotic.
The compiler would optimize away the null check, as it perfectly well knows: it can not be null
Re: (Score:2)