This is your once a month reminder to make sure your PC information is correct on your user profiles. A fresh batch of statistics is generated on the 1st of each month.
You need to be logged in to see when you last updated your PC info!
You can see the statistics any time on this page.
While we don't currently have a drop-off implemented for old/stale data, it will be implemented next year. If you want to make sure you're included at any time, clicking update without any changes will update the last time you edited them. The drop-off for old data will be done in months, since people aren't likely to change hardware that often.
Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Patreon
PayPal
Those were the reasons I switched a few years back; the closed source driver was never very good. The open source driver has improved by leaps and bounds the last couple years, and I was quite happy when AMD announced they were moving to the hybrid model (crappy proprietary modules for those who really want/need them, but all will [eventually] run on top of the open source bits).
As others have mentioned, the power consumption / performance ratio is a bit behind on the hardware side; we'll see how the next generation from both vendors compares. At least AMD is much more competitive than previously, for both GPUs and CPUs!
Other than Tegra, it's been mostly lip service... don't forget they used to have a (heavily obfuscated) open source nv driver, which they completely abandoned.
fglrx is called Catalyst now (the driver package was never separate). I don't think they ever really figured out how to compete with the Quadro line; they were also trying out "FireHD" for a while, targeting "high-end" multi-display users - the same market Matrox was trying to sell into at the end of their run...
I started Linux gaming when I had a GTX 660 and now I'm using a 780. The only games where I remember heavy screen tearing were the Shadowrun games. I had to fiddle with driver settings there. All Unity games were fine I think.
I know they renamed the fglrx ones to catalyst, The FireGL drivers were their PRO drivers (though honestly I can't recall if they dropped those as far back as when AMD bought ATI or not).
Looks like they're here;
http://support.amd.com/en-us/kb-articles/Pages/Workstation-Graphics-Drivers.aspx
I used to LOVE the Matrox cards, they just couldn't compete with the 3D side of things, but still did the best dual-head and triple-head displays. I think their downfall was that they didn't patent that, because I'm fairly certain they were the first ones to come out with single cards that were capable of it. Apparently they now have a card that handle up to 9 displays at 1920x1200.
Last edited by slaapliedje on 28 December 2017 at 3:50 pm UTC
Ha, I actually bought G-Sync displays, and yes it's supported in Linux.
I don't see why people feel like there are too many radeon drivers compared to nvidia. There is mesa for opengl, radv for vulkan and their blob, of which the vulkan part has been opened lately. So that's 3 drivers.
On the other side, i see 2 variants for the vulkan driver, a couple of packages mostly matching the same parts fglrx has, and noveau. Counted the same way, it is also three drivers.
That's about the same amount for me. Also, i have a 5-6 year old APU at this point, which is/was still supported by their blob.
I think you are mixing up kernel driver (radeon / amdgpu), and API implementations (radeonsi/r600 for OpenGL, radv/amdvlk for Vulkan and etc.). Having different names is quite reasonable, if they have actually different code for different hardware, or simply different implementations.
For starters, Gentoo includes git versions of all packages in its repos so no need to git clone, ./configure, make, make install anything manually. Arch does something similar with its aur.
More importantly though, when you build a package from source using a git repository as the source on Arch that package is tracked by your package manager and can be updated along with the rest of your system (pacaur -Syu --devel). As far as I know, Debian and variants lets you build a package from source, but doesn't automatically keep it up to date. If you install Mesa git but never update it it will quickly fall behind the fixed release version.
Last edited by natis1 on 28 December 2017 at 9:55 pm UTC
I see. But all those methods install Mesa as a replacement for stable one. That's not the goal for me in this case. I like to have experimental / master Mesa alongside stable one, and only use it on demand when needed. So in such case building it and placing it in custom location works best.
Here is an example how to do it: https://www.gamingonlinux.com/wiki/Building_Mesa_from_source