Red Hat's Long, Rust'ed Road Ahead For Nova As Nouveau Driver Successor

[yoshi314]

Not everyone wants to run closed proprietary crap. Of course they would be smarter if they bought GPUs from better companies.

the reality is that nvidia is pushing the market ahead and competition is merely catching up. it's been this way for years.

in the consumer (gaming) gpu, amd has honestly done nothing revolutionary. the typical gaming gpu has become an afterthought for nvidia as of now. they are making obscene amounts of money on AI hardware - judging by their latest keynote it's not going to change anytime soon.

for the majority of people - the smart thing is to get nvidia right now. you don't like it, i don't like it. it is what it is. gaming is a fraction of gpu usage as of this point, even though there are dedicated non-gaming cards for non-gaming tasks.

if you are not a power user, might as well get amd/intel gpu.

[Alexmitter]

Why? Rustc does work fine on riscv.

Nope, absolutely not. The best thing I was able to compile with that POS toolchain on riscv was a small example. Nothing else worked so far. Firefox still not in the debian repo either, why? Because the rust code in it can't be compiled without dirty hacks. Basically all rust containing packages are not available on the riscv port of debian.

And beside that, Linux is supported on Alpha, ARC, ARM, C-Sky, Hexagon, LoongArch, m68k, Microblaze, MIPS, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, x86, Xtensa and that compiler officially only properly supports i686, x86_64 and aarch64 as by their own documentation.

I would not have allowed any Rust code into the kernel before rust can be compiled for all the supported platforms and via GCC.

[rene]

Nope, absolutely not. The best thing I was able to compile with that POS toolchain on riscv was a small example. Nothing else worked so far. Firefox still not in the debian repo either, why? Because the rust code in it can't be compiled without dirty hacks. Basically all rust containing packages are not available on the riscv port of debian.

And beside that, Linux is supported on Alpha, ARC, ARM, C-Sky, Hexagon, LoongArch, m68k, Microblaze, MIPS, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, x86, Xtensa and that compiler officially only properly supports i686, x86_64 and aarch64 as by their own documentation.

I would not have allowed any Rust code into the kernel before rust can be compiled for all the supported platforms and via GCC.

At least on this T2 Linux Firefox with all it's Rust runs mighty well on the unmatched RISCV64 desktop: https://www.youtube.com/watch?v=MiGfP0-g2q0

[rene]

So instead of getting Nouveau more function and performance boosting and full featured, they choose to waste all their development time on rewriting it yet again for no functional changes for a long time. Also compiling Rust code along inside the Linux kernel is a major PITA.

[cend]

So instead of getting Nouveau more function and performance boosting and full featured, they choose to waste all their development time on rewriting it yet again for no functional changes for a long time. Also compiling Rust code along inside the Linux kernel is a major PITA.

Not that many people are willing to go out of the confines of GC or other fences to roam the world of unsafety. I think Zig is a nice introduction to unsafe programming, but it is very immature and it hasn't been tested in kernel programming.

[tesfabpel]

Nope, absolutely not. The best thing I was able to compile with that POS toolchain on riscv was a small example. Nothing else worked so far. Firefox still not in the debian repo either, why? Because the rust code in it can't be compiled without dirty hacks. Basically all rust containing packages are not available on the riscv port of debian.

And beside that, Linux is supported on Alpha, ARC, ARM, C-Sky, Hexagon, LoongArch, m68k, Microblaze, MIPS, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, x86, Xtensa and that compiler officially only properly supports i686, x86_64 and aarch64 as by their own documentation.

I would not have allowed any Rust code into the kernel before rust can be compiled for all the supported platforms and via GCC.

There's rustc_codegen_gcc to make Rust target GCC. It's still a WIP but in the future it may (I'd say it WILL) be used in the kernel to build Rust code...

[billyswong]

I don't get it.

Nvidia officially supports Linux and provides blobs, maybe not the best support as we wanted. I can run CUDA, do deep learning at least.

Why one is writing its own reverse enginired open source Nvidia driver without CUDA support? Which problem will be solved?

Nvidia only support their cards in Linux for about 10 years. So if you want an old Nvidia GPU still function with some 3D capacity, the open source reverse engineering effort is essential. Many people have been bitten by this problem when they reuse old computers with Nvidia GPU. Especially for old laptops and old desktops that didn't contain Intel iGPU as fallback but relied on the Nvidia GPU on-board.

[moltonel]

The best thing I was able to compile with that POS toolchain on riscv was a small example. Nothing else worked so far.

Maybe it's rough around the edges (common on less popular archs, regardless of language), but AFAICS other people manage just fine. My guess is that you didn't try very hard ?

Firefox still not in the debian repo either, why? Because the rust code in it can't be compiled without dirty hacks. Basically all rust containing packages are not available on the riscv port of debian.

Here's the debian riscv64 firefox package. You might need to requalify your statement.

And beside that, Linux is supported on Alpha, ARC, ARM, C-Sky, Hexagon, LoongArch, m68k, Microblaze, MIPS, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, x86, Xtensa and that compiler officially only properly supports i686, x86_64 and aarch64 as by their own documentation.

What are you on about nearly all of those are supported. If you feel that tier 3 is not an acceptable support level, you should probably give up on gcc on many platforms, as gcc support is often not better than rustc tier 3.

I would not have allowed any Rust code into the kernel before rust can be compiled for all the supported platforms and via GCC.

I'm glad you don't make the decisions. And FWIW, it's been possible to compile rust kernel code with gcc for a while already.

[danilw]

the reality is that nvidia is pushing the market ahead and competition is merely catching up. it's been this way for years.

If it was not Nvidia - you would have now separated Physix accelerator, separated "video encode/decode" accelerator, separated compute-accelerator, separated screen-capture card - every device separated and use its own PCIE slot and cost money.

Even today - AMD want to sell "chips" designed for single task, they do not want to sell you "AI chip" as gaming GPU.

in the consumer (gaming) gpu, amd has honestly done nothing revolutionary

If it was not AMD - you would pay monthly subscription to Nvidia for rendering "game" on their GPU.

Competition.

[danilw]

there is a whole class of exploits tageting gpu drivers, so i would say it's the perfect place for some memory safety.

well, assuming you can perfectly manage memory on that level. just because something is written in rust doesn't magically make it memory-safe in 100% of cases.

GPU have its own firmware, and GPU firmware size of 10+Mb - is basically entire OS.
And GPU-OS have its own bugs and leaks and problems, most of GPU bugs/leaks I know - is GPU-OS bugs.
You can not fix GPU-OS from user-OS driver, you can but you need to "detect pattern of calls" - this have nothing to do with "memory safe rust" aspect.