Valve says Nvidia GeForce support for SteamOS is progressing, but could take years

[Daniel Sims]

Why it matters: More and more users prefer gaming on Linux distros such as SteamOS and Bazzite over Windows, but Linux still lacks up-to-date support for Nvidia graphics chips. Although Valve hasn't resolved the issue for SteamOS yet, the company claims it is making steady progress.

A Valve spokesperson recently told IGN that the company is working hard to make Nvidia graphics drivers viable on SteamOS, the Linux distro powering the Steam Deck and Steam Machine. Introducing Nvidia hardware support would dramatically expand the appeal of Valve's OS and other Linux distros for third-party hardware manufacturers and custom builders, potentially making them much more viable rivals to Windows.

Valve's Pierre-Loup Griffais said supporting Nvidia drivers is at the top of Valve's list, but could still take years. Internal tests have enabled drivers in SteamOS's main tree and displayed graphics using certain generations of Nvidia GPUs, but gaming performance still lags behind AMD. Griffais claimed Valve is seeing daily improvements.

SteamOS's controller-friendly interface is one of the biggest advantages of the Steam Deck and Steam Machine compared to conventional gaming PCs. While Valve's distro now supports third-party devices, the company currently only recommends installing it on PCs with AMD graphics chips. Since Nvidia GPUs power roughly 73% of systems that responded to the most recent Steam Hardware Survey, SteamOS needs Nvidia driver support to become viable for most of Valve's users.

The company also aims to bring Steam to Arm devices, starting with the recently released Steam Frame VR headset. Griffais likened Valve's work on its FEX compatibility layer to the slow grind of getting Nvidia drivers working on Linux.

Just as the Steam Deck and Steam Machine use Proton to run Windows software on Linux, the Steam Frame uses FEX to run x86 software on its Arm-based Qualcomm Snapdragon SoC and Lepton to run Android apps on an Arm version of SteamOS. Expanding Steam and SteamOS to Arm processors could make PC gaming viable on tablets, smartphones, the growing market for Arm laptops, and Qualcomm-based gaming devices from manufacturers such as Ayn. Meanwhile, Microsoft aims to promote an Arm version of Windows for laptops and mini PCs, powered by Snapdragon chips and Nvidia's upcoming RTX Spark SoC, using a separate translation layer.

Aside from Nvidia drivers and Arm support, anti-cheat remains SteamOS's biggest obstacle. While anti-cheat providers have recently thrown their support behind Arm Windows and RTX Spark, SteamOS still struggles with popular online games such as Grand Theft Auto and Call of Duty.

Permalink to story:

Valve says Nvidia GeForce support for SteamOS is progressing, but could take years

 

[Eldrach]

I cheer them on - we need a fully fledged alternative to Windows, not there yet..But some day!

 

[Gezzer]

Nvidia needs to help with this and since they seem to have walked away from gaming...

 

[CrisisDog]

I’m still using the proprietary Nvidia drivers, but with Proton GE, I’ve even got PhysX running. What is the holdup?

 

[romatthe]

To be clear, there are Linux Nvidia drivers that work... fine. But they're proprietary and are annoying to deal with. They live entirely out of tree, are not part of Mesa, need to be installed by the user seperately, break fairly often during kernel release cycles, and we are entirely at the mercy of Nvidia. If they lose interest tomorrow, it's over.

There is an existing open source implementation for *older* Nvidia GPUs (nouveau), but while it works, it doesn't work well with the modern cards with GSP firmware. Modern cards reclock aggressively, and nouveau is not able to deal with this.

There is also an effort to implement a modern Vulkan driver within Mesa (NVK). However, NVK still needs more work. But more importantly, it needs a rock-solid modern device driver to work well. There has been very little time and money to sponsor work on a new device driver it seems, and I haven't heard a lot of news from that front.

 

[bviktor]

(del)

 

[bviktor]

To be clear, there are Linux Nvidia drivers that work... fine. But they're proprietary and are annoying to deal with. They live entirely out of tree, are not part of Mesa, need to be installed by the user seperately, break fairly often during kernel release cycles, and we are entirely at the mercy of Nvidia. If they lose interest tomorrow, it's over.

There is an existing open source implementation for *older* Nvidia GPUs (nouveau), but while it works, it doesn't work well with the modern cards with GSP firmware. Modern cards reclock aggressively, and nouveau is not able to deal with this.

There is also an effort to implement a modern Vulkan driver within Mesa (NVK). However, NVK still needs more work. But more importantly, it needs a rock-solid modern device driver to work well. There has been very little time and money to sponsor work on a new device driver it seems, and I haven't heard a lot of news from that front.

I've been developing Ansible playbooks for graphics drivers deployment (amongst other things) for maybe 6 years now. You're confusing a lot of things here, and making up others.

To begin with, their "problem" with NV isn't the closedness of the driver _at all_. He never once mentions this in the interview. They complain about performance. Bringing in an experimental new driver will not fix performance, in fact, it'll most likely make it worse, while also bringing a truckload of new bugs as well.

But there's nothing special about installing an NV driver. It's closed, yes, but how is that relevant? The Windows driver is also closed, so what. It works. Unlike AMD. I have AMD in my bedroom HTPC now, and guess what, it's been giving me the green screen for months. Look it up, the internet is full of it. Apparently this is sometimes a RAM problem, or a BIOS problem, or 9 million other possible cases problem.

For me it turned out to be ... a Mesa problem. Because that lovely open source AMD driver baked into it was buggy for a certain release, and Flatpak happens to be bundling that precise version. Switched from Flatpak Firefox to native, proper apt Firefox, and tah-dah, all my problems are gone. Before Flatpak, I used the promoted Snap version btw, which had other issues. It's funny, huh? We've been told how awesome these new delivery methods are, but at the end of the day, native always wins.

I built a bunch of other AMD comps as well, the drivers always break maybe every 6 months, even on Windows. Something that never happens to me with NV. I know I know. Coincidence.

But I digress. Installing the NV driver is not rocket surgery. In fact, it's so much easier to deploy and switch between versions precisely because it's its own separate package (or runfile, whatever), it's not baked into all parts of the core OS, like with AMD.

Oh, it doesn't always work with the very latest kernel release? Well maybe that's just one of the many reasons why using a rolling distro for the basis of SteamOS doesn't make any sense at all? In fact, a rolling distro doesn't make sense for any use case whatsoever, period? Newsflash: MOST software that's reliant in any shape or form on the kernel _will_ break during new releases. That's how API changes work. You change the foundation, then the rest follows. Newsflash: graphics is usually very reliant on the kernel.

nouveau never worked and never will. It was your go to driver to download the closed NV driver with, and that's about it. It's like Edge is the best browser to download Firefox (or whatever) with.

NVK is experimental. Will get there, maybe, in a few years. That doesn't make installing the NV driver, that's been available for maybe 20 years, impossible. No, NV will not "lose interest". It's their main platform (no, datacenters don't use Windows), what are you even talking about?

TLDR: stop making stuff up.

 

[raleya]

I've been developing Ansible playbooks for graphics drivers deployment (amongst other things) for maybe 6 years now. You're confusing a lot of things here, and making up others.

To begin with, their "problem" with NV isn't the closedness of the driver _at all_. He never once mentions this in the interview. They complain about performance. Bringing in an experimental new driver will not fix performance, in fact, it'll most likely make it worse, while also bringing a truckload of new bugs as well.

But there's nothing special about installing an NV driver. It's closed, yes, but how is that relevant? The Windows driver is also closed, so what. It works. Unlike AMD. I have AMD in my bedroom HTPC now, and guess what, it's been giving me the green screen for months. Look it up, the internet is full of it. Apparently this is sometimes a RAM problem, or a BIOS problem, or 9 million other possible cases problem.

For me it turned out to be ... a Mesa problem. Because that lovely open source AMD driver baked into it was buggy for a certain release, and Flatpak happens to be bundling that precise version. Switched from Flatpak Firefox to native, proper apt Firefox, and tah-dah, all my problems are gone. Before Flatpak, I used the promoted Snap version btw, which had other issues. It's funny, huh? We've been told how awesome these new delivery methods are, but at the end of the day, native always wins.

I built a bunch of other AMD comps as well, the drivers always break maybe every 6 months, even on Windows. Something that never happens to me with NV. I know I know. Coincidence.

But I digress. Installing the NV driver is not rocket surgery. In fact, it's so much easier to deploy and switch between versions precisely because it's its own separate package (or runfile, whatever), it's not baked into all parts of the core OS, like with AMD.

Oh, it doesn't always work with the very latest kernel release? Well maybe that's just one of the many reasons why using a rolling distro for the basis of SteamOS doesn't make any sense at all? In fact, a rolling distro doesn't make sense for any use case whatsoever, period? Newsflash: MOST software that's reliant in any shape or form on the kernel _will_ break during new releases. That's how API changes work. You change the foundation, then the rest follows. Newsflash: graphics is usually very reliant on the kernel.

nouveau never worked and never will. It was your go to driver to download the closed NV driver with, and that's about it. It's like Edge is the best browser to download Firefox (or whatever) with.

NVK is experimental. Will get there, maybe, in a few years. That doesn't make installing the NV driver, that's been available for maybe 20 years, impossible. No, NV will not "lose interest". It's their main platform (no, datacenters don't use Windows), what are you even talking about?

TLDR: stop making stuff up.

You don't seem to bring much references to support your claims on the other person. The fact that it's closed source _does_ hinder Valve on their performance work: on AMD's graphics stack it did many contributions to mesa _and_ the kernel driver, there has been numerous articles on phoronix about it: the search bar is somehow not good enough to find them, so a search by commiter's email domain will do (it's either valve or their contractor, collabora)


https://gitlab.freedesktop.org/mesa/mesa/-/commits/main?message=valve
https://github.com/search?q=repo:torvalds/linux+valve&type=commits

A rolling release is useful because valve's fixes and improvements live on the bleeding edge, can't wait 2y to bring them about to users