NVIDIA Is Better For Closed-Source Linux GPU Drivers, AMD Wins For Open-Source

An anonymous reader writes "Phoronix last week tested 65 graphics cards on open source drivers under Linux and the best result was generally with the open source AMD Radeon drivers. This week they put out a 35-graphics-card comparison using the proprietary AMD/NVIDIA drivers (with the other 30 cards being too old for the latest main drivers) under Ubuntu 14.04. The winner for proprietary GPU driver support on Linux was NVIDIA, which shouldn't come as much of a surprise given that Valve and other Linux game developers are frequently recommending NVIDIA graphics for their game titles while AMD Catalyst support doesn't usually come to games until later. The Radeon OpenGL performance with Catalyst had some problems, but at least its performance per Watt was respectable. Open-source fans are encouraged to use AMD hardware on Linux while those just wanting the best performance and overall experience should see NVIDIA with their binary driver."

Ex-Valve Rich disagreed: Intel was more open

[UnknownSoldier]

The Truth on OpenGL Driver Quality [blogspot.hu]

TL:DR;
Vendor A nVidia - driver errs on the side of "make it work" vs GL spec
Vendor B AMD - conforms to the OpenGL spec, but is buggy, inconsistent performance
Vendor C Intel - best open source driver, but performance doesn't compete with nVidia or AMD

Vendor A

What most devs use because this vendor has the most capable GL devs in the industry and the best testing process. It's the "standard" driver, it's pretty fast, and when given the choice this vendor's driver devs choose sanity (to make things work) vs. absolute GL spec purity. Devs playing at home use this driver because it has the sexiest, most fun to play with extensions and GL support. Most of what you hear about the amazing things GL will be able to do in order to compete against D3D12/Mantle are by devs playing with this driver. Unfortunately, we can't just target this driver or we miss out on large amounts of market share.

Even so, until Source1 was ported to Linux and Valve devs totally held the hands of this driver's devs they couldn't even update a buffer (via a Map or BufferSubData) the D3D9/11-style way without it constantly stalling the pipeline. We're talking "driver perf 101" stuff here, so it's not without its historical faults. Also, when you hit a bug in this driver it tends to just fall flat on its face and either crash the GPU or (on Windows) TDR your system. Still, it's a very reliable/solid driver.

Vendor A supports a zillion extensions (some of them quite state of the art) that more or less work, but as soon as you start to use some of the most important ones you're off the driver's safe path and in a no man's land of crashing systems or TDR'ing at the slightest hickup.

This vendor's tools historically completely suck, or only work for some period of time and then stop working, or only work if you beg the tools team for direct assistance. They have enormous, perhaps Dilbert-esque tools teams that do who knows what. Of course, these tools only work (when they do work) on their driver.

This vendor is extremely savvy and strategic about embedding its devs directly into key game teams to make things happen. This is a double edged sword, because these devs will refuse to debug issues on other vendor's drivers, and they view GL only through the lens of how it's implemented by their driver. These embedded devs will purposely do things that they know are performant on their driver, with no idea how these things impact other drivers.

Historically, this vendor will do things like internally replace entire shaders for key titles to make them perform better (sometimes much better). Most drivers probably do stuff like this occasionally, but this vendor will stop at nothing for performance. What does this mean to the PC game industry or graphics devs? It means you, as "Joe Graphics Developer", have little chance of achieving the same technical feats in your title (even if you use the exact same algorithms!) because you don't have an embedded vendor driver engineer working specifically on your title making sure the driver does exactly the right thing (using low-level optimized shaders) when your specific game or engine is running. It also means that, historically, some of the PC graphics legends you know about aren't quite as smart or capable as history paints them to be, because they had a lot of help.

Vendor A is also jokingly known as the "Graphics Mafia". Be very careful if a dev from Vendor A gets embedded into your team. These guys are serious business.

Vendor B

A complete hodgepodge, inconsistent performance, very buggy, inconsistent regression testing, dysfunctional driver threading that is completely outside of the dev's official control. Unfortunately this vendor's GPU is pretty much standard and is quite capable hardware wise, so you can't ignore these guys even though as an organization they are i

Re:AMD Wins For Open-Source

[MBGMorden]

Too bad that for a majority of users, Linux isn't an OS that they should be using to begin with...

Nonsense. The vast majority of users these days just need a working browser. My mom, dad, and sister all run Linux. Only my sister seems to even be aware that it's not Windows. Simple fact is they know to click on the Chrome logo (same one a Windows user uses) to bring up the browser and they're off. I don't have to worry about fixing any malware that does crop up, and in the event that they DO have a problem I can easily SSH into the machine and tunnel through to a VNC server to look at things remotely.

As a matter of fact its the mid-range skillset users who seem to have the most trouble with Linux. For basic users it covers all of their use cases. For the geeky power users they don't mind getting their hands dirty and getting creative to make things work. The mid-range users though want to do semi-complex things but get frustrated when it doesn't work exactly the same way in Linux.

Re:Just don't upgrade the kernel with nvidia close

[Narcocide]

text files, which are slow and unreliable to parse

require a separate config file interpreter in each program

[user]-specific diretories like .config, .kde, and .gconf,... just add to the mess

None of this is true. Stop believing everything about Linux you hear from your local Microsoft retailer. Drop the prejudice against the people you consider "try hards" and figure out why they're trying so hard and what it is they're trying to do.

IMO Windows Registry is way nicer than what Linux has got.

This would be considered a reasonable and well-informed decision if the Windows Registry wasn't the most twisted and corrupted unreliable piece of garbage-ware ever conceived and any of your above arguments about Linux were even remotely educated.