Slashdot Mirror
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."
Ubuntu has had its own method of dealing with nVidia drivers for about 7 years now. If you really want to go with the official nVidia driver (rather than the ubuntu-provided package which, IIRC, automatically handles kernel upgrades), all you have to do is cd to where you stuck the nVidia bin installer, and "sudo ./run" it. But really, if you're manually going outside of the package management system, you should learn how it works rather than complaining that you got burned,
Not to mention that the "dumped to console" was ALSO fixed many, many years ago (8.04?) as part of their bulletproof-X initiative.
In last week's testing of 65 GPUs on the open-source Linux drivers, the winner overall was the AMD Radeon graphics cards: they were the least problematic (though several Radeon GPUs still ran into different problems) and they delivered the best performance (including generally the performance-per-Watt).
Can confirm. The open source Radeon driver has been improving greatly. A bit surprisingly, Radeon hardware is actually starting to become a quite good choice for a Linux user.
I'd rather have hardware that works well. Closed source drivers don't bother me.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Yeah, as long as you ignore "NVidia Optimus". I have a AMD-A6 based desktop, it works fine with the occasional glitches, but the only thing that is truly stable and works for everything is called "Intel". There simply is no contest.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
One note:
AMD OpenSource drivers are best OpenSource drivers out there, but shitty drivers per se.
NVIDIA drivers are great drivers, but not OpenSource.
This is the real difference and conclusion. Don't try to hide it.
Ubuntu has had its own method of dealing with nVidia drivers for about 7 years now. If you really want to go with the official nVidia driver (rather than the ubuntu-provided package which, IIRC, automatically handles kernel upgrades), all you have to do is cd to where you stuck the nVidia bin installer, and "sudo ./run" it. But really, if you're manually going outside of the package management system, you should learn how it works rather than complaining that you got burned,
Not to mention that the "dumped to console" was ALSO fixed many, many years ago (8.04?) as part of their bulletproof-X initiative.
On ubuntu 14.04 there is a "driver manager" in system settings. This lets you easily switch between the nvidia binary driver and nouveau (open source).
The Truth on OpenGL Driver Quality
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
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
Even a GMA950 can easily perform all those tasks.
Yes, it can. Very easily.
That "driver manager" was added somewhere between versions 6.10 and 7.10. It not only installs the nVidia driver, it handles re-installing it every time you upgrade kernels (though, to be fair, it did still occasionally break).
Steam has SEVERAL major games that run on Linux.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
At the very least, the AMD FOSS driver hasn't broken any systems for me. The Nouveau driver, however, has consistently booted up various systems with modes that didn't work on the display, causing it to blank shortly after booting or when starting X.
I use a USB stick when dealing with client PC's. It's burned me enough times that I have memorized the need to put this on the kernel boot-line (basically, disable nouveau)
nouveau.modeset=0
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.
Didn't have to do any of that. After install I got a little message saying "proprietary drivers available". I clicked and they installed. Its been that way for years now.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
I decided to check to see if it would support my programs. It didn't take long to hit a roadblock.
Requirements for Office 2013 - http://office.microsoft.com/en...
Hardware acceleration Graphics hardware acceleration with DirectX10 graphics card
According to http://www.intel.com/products/... , there's no Directx10 support from this board.
Pain is merely failure leaving the body
IMO Windows Registry is way nicer than what Linux has got. In Linux, programs use text files, which are slow and unreliable to parse, and require a separate config file interpreter in each program. Then there are these desktop environment -specific directories like .config, .kde, and .gconf, which just add to the mess. In Windows, you just use the standard API for accessing the registry.
Are you trolling, or ignorant? There's no third way, because precisely the same situation persists on Windows, except with the added drawback that the registry is in a shitty format.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Are you trolling, or ignorant? There's no third way
Wouldn't "shill" be the classic third option?
For the developer, yes. For the user, fuck no. And since this is all precisely about how what's good for the user, then it really isn't relevant how nice it is for the developer, ignoring the whole point is precisely that no matter how nice it is for the developer, developers still consistently hide settings in the registry.
Short of some very special circumstances, the difference is parsing a binary or text file are unnoticeable to a user. As for being unreliable to parse, perhaps in a very esoteric way that's true--ie, the developers job might be harder, but very rarely do users get bitten with those corner cases short of disk corruption. But as a user, the main thing you'll notice is that in Windows, Linux, or whatever, that sometimes a developer uses a text box for a boolean option or goes for decimal instead of hex or whatever and hence the user doesn't know what all is a "proper" answer and it's then that parsing becomes an issue. Regardless, separate config file interpreters also come with separate config files which can at least hint at where all config options are.
And yes, this is the other side of the coin. In an effort to be more "standard", we've come across xkcd's observation that it just creates more of a mess. So, ones that actually followed the old standard of ~/.$program[.$ext] make it easy, for the user, to know where config options are, back them up if they want (or delete them to go back to the defaults), and generally be reasonably certain all the major user options are there to be fiddled with. With Windows? It's the same problem of files being in various config files plus settings scattered all over the registry. Windows itself is especially guilty of this.
Well, that's good and all. But it's just an API. The major thing preventing a standard API in Linux to do the same thing is the inertia of old standards and people unwilling to rewrite everything to fit the new system. The it be one binary hive or many scattered text files is rather beside the point from an API perspective (well, not entirely, but it's close enough most the time). And of course, .gconf trying to be the Linux registry...well...xkcd.
And this final point is where you seriously fail. Windows doesn't have *a* configuration manager. It does have *a* registry editor. Each program has to contain its own configuration management glued to a backend API be it the Windows registry or a config file. Yet in the end, it's the fact that every program is different and many options are either mutually exclusive or have potentially deep nested dependencies that leaves one to either (1) include a lot of text in your config file and have sane resolutions for conflicting options or (2) have a UI that preemptively protects against conflicts and still has to deal with user mucking around behind the scenes or (3) just not giving the user access to most configuration management with (3) being the most common problem with Windows and (1) being a rather lazy developer approach under the *nix philosophy which remain the norms.
I think that sums up why pretend that the registry and regedit are magical panaceas really misses the point.
Text files have their huge advantage. They're easy to back up and don't require anything aside from a text-editor to restore a broken system. I can easily copy them over, and diff them. Sample configuration files are quick to compare.
None of this is true for the windows registry.
Text files may be less newbie friendy, but then again, programs do have a settings/preferences option generally for stuff newbies want to touch. Messing the config files OR a registry by these sort of users tends to end badly anyway.