AMD Is Hiring To Work On New Radeon Driver Tooling Written In Rust

[Ironmask]

Probably a bad idea to use Rust.
The reason we don't see full blown apps in Rust taking over the Linux desktop is because it's far less productive because the issues it fixes come at a heavy cost and the bindings and style you have to use is alien to the human brain because writing otherwise is not allowed because of the borrow checker - I did a quick look at the Qt bindings - they're disgusting to me as a human.

I only see these cases as suitable for Rust:
- some complicated multi-threaded task
- some toy app, like fd [1] which is awesome
- a part of code in an app like telegram, tor or whatnot that are obsessed with security.

[1] https://github.com/sharkdp/fd

Not entirely sure what you're trying to say here. Computer resources are complicated to manage and applications are required to do a lot, that's a common truth, no matter what language you're using. You're saying Rust's facilities to help manage these resources better are more confusing and less productive? At doing what, letting you shoot yourself in the foot?

Not trying to make fun of you or praise Rust, just genuinely confused by what you're trying to say. I'm constantly having to think of clever ways to manage resources in other languages, and while I haven't used Rust, it sounds like a dream.

[jacob]

Probably a bad idea to use Rust.
The reason we don't see full blown apps in Rust taking over the Linux desktop is because it's far less productive because the issues it fixes come at a heavy cost and the bindings and style you have to use is alien to the human brain because writing otherwise is not allowed because of the borrow checker - I did a quick look at the Qt bindings - they're disgusting to me as a human.

I only see these cases as suitable for Rust:
- some complicated multi-threaded task
- some toy app, like fd [1] which is awesome
- a part of code in an app like telegram, tor or whatnot that are obsessed with security.

[1] https://github.com/sharkdp/fd

The main reason we don't see many full blown desktop apps in Rust is mainly because new full blown app projects don't start from scratch very often. But that doesn't mean it's not spreading its wings. Firefox of course has a lots of Rust in it now, librsvg is now written in Rust (that's one thing that's pervasive throughout the desktop), rav1e is in Rust and obviously lots of the server-side stuff uses Rust extensively, from Dropbox to Amazon and Facebook. I think there is even a project to rewrite the Python interpreter in Rust.

It is true that Rust feels alien - but not to the human brain in general, just to human brain conditioned to think like in Java/C#. Admittedly that makes for a huge percentage of developers, but in many ways it's the price to pay. Honestly, similar people often find C++ alien too, and lots of such people find Haskell incredibly alien. That doesn't make those languages bad, it just means the learning curve is steep and not necessarily justified for everyone and every project. To Rust's credit, its community is aware of the barrier to entry and tries to make up for it by providing extensive tutorials and absolutely top notch tooling.

I agree that Qt bindings in Rust are terrible but truth be told, they are really terrible in virtually every language other than C++ (because C++ is simply a terrible language to bind against, except possibly from D). Personally I actually find Qt revolting even in C++ itself. If you want to write a GUI in Rust, gtk-rs is objectively in a much better shape, but I usually write the performance-sensitive part in Rust and the gtk-based UI in Python.

[zxy_thf]

I hope they fell not victim to the illusion that the choice of programming language determines the quality of the software.
But hey, if some new "tools" (written in whatever language) help to get the show-stopping, years-long-standing bugs in amdgpu fixed, everything is welcome.

Well I would say Yes and No.
It's no news developer's productivity is constant in terms of LoC, irrelevant to what PL they're using.
The C Language, although still popular in system programming, is very verbose for user-level applications like debugging tools. For example, if you want to code up a function in C which returns a string as debug message, the memory management problem immediately pops up. (I hit this problem in real life and we eventually cancelled this idea after brief discussions...)

[oleid]

I am not sure if Option<Value> provides any benefit over nullable values, because then you have to extract it and check if it has a value or is None, so then you might as well check if its not null.

The point is : you have to handle both cases with option, for nullable types you don't have to. And if you forgot, then bad things may happen.

In rust, you may use unwrap() on option for quick prototyping. Then the program panics on None. But these cases are nicely find-able in the code after prototyping.

Pro-tip: For some types like enums, non-zero integer types, slices and C-style pointers using Option doesn't cost extra bytes of memory. Internally it is implemented by value stealing. And you could even transmute directly from e.g. u32* to an Option<u32*>.

[tildearrow]

Here: https://github.com/marazmista/radeon-profile
or there: https://gitlab.com/corectrl/corectrl

I don't want to see AMD spending precious time and resources on what is already implemented (multiple time). It's really better if AMD fills the gaps that are not filled yet, especially the gaps that require too much skills to expect a third-party developer to spawn magically to do the job by himself.

CoreCtrl seems to be the most viable option, as it resembles WattMan the most.
radeon-profile looks simplistic and too technical.

Isn't the official GUI based on Qt anyway?


Oh wait that would require open-sourcing the GUI code....

[oleid]

I agree that Qt bindings in Rust are terrible but truth be told, they are really terrible in virtually every language other than C++ (because C++ is simply a terrible language to bind against, except possibly from D).

I've been told that the nicest way to write Qt GUIs in rust is to go the qml way (rqml, I believe). But never tried it. Personally, I'm toying with Druid at the moment.

Personally I actually find Qt revolting even in C++ itself. If you want to write a GUI in Rust, gtk-rs is objectively in a much better shape, but I usually write the performance-sensitive part in Rust and the gtk-based UI in Python.

Relm is supposed to be a nicer wrapper for gtk+. It uses message passing to deliver events and thus can easily be used in highly multithreaded code.

[jacob]

Relm is supposed to be a nicer wrapper for gtk+. It uses message passing to deliver events and thus can easily be used in highly multithreaded code.

I never tried to use it (yet) but AFAIK it's actually based on gtk-rs, so it seems it's a complement rather than an alternative. The thing that makes gtk-rs great is that now it allows you to create new widgets natively in Rust. It's a little bit more verbose and less intuitive than in Vala though.

[shmerl]

Nice development! Looking forward to Rust catching up also to amdgpu, radeonsi, radv and Co.

[HadrienG]

No matter what you think about the choice of programming language, it's good to see AMD hiring some extra software devs. When comparing with the NVidia (GPU) and Intel (CPU) competition, software has always been AMD's weakest side in my opinion.

[oleid]

I never tried to use it (yet) but AFAIK it's actually based on gtk-rs, so it seems it's a complement rather than an alternative. The thing that makes gtk-rs great is that now it allows you to create new widgets natively in Rust. It's a little bit more verbose and less intuitive than in Vala though.

Right, it is not a different wrapper of gtk+, just a way to use gtk-rs it in a nicer way. Without having to deal with interior mutability.