I was using linux for gaming until recently. I need to repair it, and also have been using some windows centric software. So booting mainly into windows right now.
But one thing I noticed was that on nvidia blob drivers at least (cannot attest to amd), in FPS games, where every millisecond does count. There's definitely a bit more latency on linux compared to windows. Enough to feel it for sure.
Otherwise almost everything (windows store games being mostly the exception) worked fine or could be made to run fine in linux and performance aside from what I am feeling as added latency was on par and sometimes better than windows.
I’m on Linux full time for programming and gaming. I play battle.net games (WoW, hearthstone, overwatch, HoTS, WoW classic), League of Legends, and a lot of steam games. I have virtually no issues. I have a ryzen 5900x and a RTX 3080.
The key to Linux gaming (outside of steam) is Lutris. You just search the game you want to install, and it installs all the dependencies needed automatically and you can launch the game from one place. They even have a simple 1 click button for adding steam games too if you want a single launcher for every game you have (this is what I do).
The only issues I really have are with EAC, like DKO didn’t work for a bit after it came out (but does now), and Valorant/Fortnite don’t work (they can easily enable Linux EAC but choose not to). I happen to not play these games so it’s a non-issue for me, but worth mentioning.
League of Legends is also worth mentioning as having more issues than the rest. Usually I can run the game for months or even a year+ with no issues, but earlier this year the game was virtually unplayable on Linux for about 6 days due to a bug Riot Games added. This bug also effected Windows users, but to a much less extent. They would get disconnected once every couple games, while Linux users would get disconnected once every couple minutes. The League of Linux community is amazing though, and people were troubleshooting it constantly and making it more and more playable (getting to Windows parity on the bug), until Riot Games fixed it on their end.
I even helped my brother swap from Windows to Linux recently. He isn’t super into Linux or anything, but he was having consistent issues on Windows with his monitor turning off in games, specifically League. We tried reinstalling drivers, watching temps, reinstalling League (since it didn’t happen in other games), and uninstalling certain apps that can add overlays (though they were disabled). Some of these issues seemed to fix it until it returned usually hours or days later. Eventually we gave Linux a try and the issue is entirely gone. It’s likely that resetting windows would work too, but he dual boots and it’s easier to not have to reinstall everything.
Well I’m not atm because I really like the setup at the moment, but I was hoping it was a known quick fix just in case I feel like hopping on something else for whatever future reason. That being said I am pretty happy with my pop experience.
I used to buy Nvidia cards, but since AMD providing support for teams building in-kernel drivers I’ve mostly walked away from team green.
Unfortunately when it comes to stuff like laptops the selection with AMD kit is a bit limited, do I do have one with an NVidia card there and it’s still a huge pain. In Linux I have to worry about the driver stub borking every time there’s a kernel update, and in Windows they seem to want you to login to their app to do damned updates.
I’m happy to see Nouveau getting better accelerated support but it would be even nicer if NVidia could step up to the plate themselves.
In a way, I think it’s also best if the community would work this driver out, because if Nvidia steps in and gets involved in this project, chances are that they might update their Linux kernel driver to become incompatible with Nouveau/NVK.
Would that necessarily be bad. If they made a proper open-source Nvidia driver - similar to the in-kernel AMDGPU - then Nouveau could still build off that or be merged in to add functionality.
I don’t miss the old fglrx drivers now that AMDGPU is around.
Definitely would not mind having an AMDGPU equivalent for Nvidia. It’d be awesome if things like proprietary CUDA could be an optional installable package alongside an open graphics driver.
Tbh all nVidia should’ve done was to make their firmware available and easily redistributable. Them locking down their hardware down to the firmware level is what killed the development of Nouveau.
They don’t need to step up to the plate, just don’t block the guys who are willing to do the necessary work themselves
Yes, but that license change took them quite a while after the first release of the open kernel module, and still, that’s only for the GSP firmware. Nothing of the sort is the case for the PMU firmware that could be used for Maxwell and Pascal*.
(*Fun fact, there is actually some code for power management for Maxwell series at least (not upstreamed I presume), Nouveau devs even demonstrated NVK via playing Hollow Knight on a GTX950m, which ran the game pretty smoothly, the main issue seems to be not being able to control the fans of the GPU due to the firmware, something that was not really a problem for the particular laptop they’ve done the demonstration on)
Yeah the APU availability isn’t bad (and I’d choose AMD for an APU over others) but selection with dedicated graphics chips is pretty limited, especially if you’re looking for both an dedicated AMD GPU and CPU.
I have definitely had DKMS not play nicely with my Nvidia drivers, as well as the “which Nvidia driver actually supports this older GPU… oh look it’s dropped” issue, but that’s also on Ubuntu variants so you might have better luck in arch.
To be fair, I do some weird shit on my environments. One thing I’d love if NVidia had reasonably supported native drivers is to have a PXE-boot system that plays nicely regardless of whether one is one is team green or team red. I used to maintain one which contained a decent catalog of games but had to do some quirky overlayfs stuff to make both viable.
While this is true the linux kernel + Mesa package versions needs to be new enough in your distro too
this is the case for Ubuntu 22.04.02 and Ubuntu 23.04 but not for the older but still supported Ubuntu 20.04.04
For how great AMD usually is on Linux, it's not without it's issues. RDNA2 (the entire RX 6000 series) still suffers to this day from this 2 years old issue that can cause stutter in games as the GPU constantly downclocks itself aggressively. I still prefer it over Nvidia (having owned one and now using AMD) but just be aware, it's not all as perfect as some Linux users would have you believe.
One warning, if you use a display over HDMI, then you might have a bad time with Radeon on Linux. I use an LG C2 TV as my monitor, and there is a bug in the driver that forces it to a crappy ycbcr mode that ruins text clarity. I did try all manner of workarounds like hacking up the EDID profile, but I gave up and went back to Windows for now.
It’s a very specific issue, but a showstopper if it affects you
That’s the display advertising a specific function set, not the card, and it has to do with the large panel size and pixel density. If you used a proper monitor I’m pretty sure you wouldn’t have that issue.
Ok, then why does the same display work perfectly in windows? The display supports full RGB both 8 and 10 bit uncompressed. There is an open issue for this on the driver gitlab repo.
Don’t monitor shame me please. Also, the pixel density is within 5% of my 27" 1440p monitors.
I haven’t seen too many positives regarding Radeon on Linux
Funny you say that, because Linux users have a lot of hate for Nvidia due to its poor support and closed-source drivers, and lots of love for AMD with it’s great support and open source drivers.
I think i’m just naive. I did a bit of searching but didn’t find much. I didn’t realize the drivers are built into the kernel which makes me feel much better.
linux_gaming
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.