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."
...for you guys who like closed source stuff:
funny.exe
boobies.exe
yourprize.doc
Have fun!
I can't quite put my finger on it, but something tells me this is a job for a captain. Captain something or other. Anyone care to help me out?
Intel seems to have the only graphics that doesn't suck horribly on Linux for normal day to day use.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Is that why, on my HD6450, Linux Mint setup boots into a garbled screen, PCLinuxOS skips the desktop installation, and Desktop BSD just gives me a black screen when any setup method is selected?
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
Wait, nVidia linux drivers now support optimus properly? Last time I checked (some 2 years ago) I had to run a command line (bumblebee or something) to turn on the offboard video card for the process I was about to run. And even to get to that pathetic level of usability took hours of internet search and messing with configs.
Really, to me as a user, I want Linux open source drivers, not because I am an open source fanatic. I just don't want to have the headache of configuring that kind of stuff, hardware that has open source drivers just work in Linux.
I had an AMD HD 6850 card that ran great on Windows, but could not run any game respectably in Linux. I was burned out waiting, so I bought an nvidia Geforce 750 ti, and now I can play games in Linux using the nvidia drivers from the website. This newer nvidia card is about the same performance as my old 6850 and it does not use any extra connectors from the power supply.
I didn't go through every page so I might have missed it, but were there any tests done using the same game or benchmarks for both closed and open source drivers? It looked like the previous article was using a completely different set of games than this test.
Anybody have links to actual apples to apples comparison? I'm using mostly amd cards for reasons that don't have anything to do with gaming but are opengl based. I'd like to get some idea just how far behind the open drivers are from the closed drivers on any recent fairly high end amd card. I know it depends on exactly what features are used and if a feature isn't available the fps will be zero.
thanks.
I find this also a bit odd. A lot of Linux desktop environments do not ship with a proper "Device Manager".
Not to mention that the "dumped to console" was ALSO fixed many, many years ago (8.04?) as part of their bulletproof-X initiative.
Yup. Now its just dumps you back to the gdm screen and you have to manually get your way to a text console to fix it.
You should definitely chose White. Or Black. Definitely.
This seems to always have been a "Chicken of the Egg" problem for Linux.
We want major game titles to run on Linux, but vendors won't port because there isn't a large enough Linux user base; There isn't a large Linux user base because the quality of what is there is often inferior (dues to running in wine, bad/neglected drivers, etc) to Windows.
Mageia handles the nvidia driver within it's packaging system. Automatic updates along with the kernel, easy installs, no problems. It's been this way since the Mandriva days. Mageia's a nice, no-hassle distro.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
These reviews are nice, but they always focus on gaming. There's very little information for media playback.
How well do each of these drivers do with accelerated playback of MPEG2, MPEG4, and other formats? If given a 1080i source, can they produce a real 1080i stream to the display, or will the alternating fields get reversed? (I have an older CRT HDTV that is 1080i native. With newer displays, it's good to have the option of letting the display handle deinterlacing.)
If I want to build a low-power media player, what are my options for video hardware and drivers?
Most really don't need to anymore. I've been using Linux for a LONG time. Started when I was in high school circa 1997 or so. I'll admit that back then it was a pain in the ass to get a lot of stuff working.
Now - I install it and everything just works. I haven't had to mess around with text config files just to get the system running or the like for years (probably around 2009 or so).
The only time when things get a little hairy is when doing something a bit outside of the ordinary - IE, getting certain games running under Wine and the like. That's trying to work around a simple lack of native apps though. When running Linux software on a Linux system - piece of cake. As a matter of fact the only thing that keeps Windows from feeling completely foreign to me is that I have to use it at work.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Really, all OSs are guilty of it to some extent: MS "hides" tons of stuff in the registry,
I always find it hillarious when the registry is brought up, but somehow noone wants to discuss gconf or the .gconf folder with all of its bizarre files.
news at 11.
I'm pretty sure I could underclock my nvidia card to be as slow and shitty as the AMD card and the performance per watt would be comparable too.
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).
>Linux has much nicer package management, Windows has much nicer configuration management.
If I have two computers, and I'd like the programs one computer A to be configured just like computer B, how does windows help me do this? :)
Depends on the program; on every platform, programs all have their own quirks. For instance, some programs on linux store their config in ~/.program, some in /etc/program, some in /usr/local/program/conf, etc etc etc.
I don't know.
Depends on the program; on every platform, programs all have their own quirks. For instance, some programs on linux store their config in ~/.program, some in /etc/program, some in /usr/local/program/conf, etc etc etc.
What linux program worth its salt stores configuration in /usr/local of all places ???
Crashplan is one I can think of off the top of my head.
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
A lot of Linux distros are derived from Ubuntu and -- presumably -- can use Ubuntu's system settings and its driver manager.
What driver manager? There's the "proprietary drivers available" tool, which is pretty neat, but I'm not aware of any full driver manager.
I don't care if they are closed source or open source, as long as they are good.. I'd rather have excellent closed source drivers than crappy open source drivers...
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.
By default, only ones you compiled and/or installed by people who don't know how to properly use the previously mentioned superior package management.
Lollerskatez.
Consider the following.
I'm at a loss to understand how that giant huge mess called "Registry" could be labeled "nice" by anyone...
CLI paste? paste.pr0.tips!
It's a shame Microsoft doesn't include a "proper registry editor" in Windows.
Agree. The Registry Editor is quite rudimentary.
no, you're simply not understanding the conventions which apply here.
/etc/foo is the global/system configuration of <foo>
/usr/local/etc/foo is the same, but <foo> was not installed via the package management (but rather by the user extracting a tarball and running make install after building it)
~/.foo is user-specific configuration of <foo>, configuration settings specified here will usually take precedence over the global configuration
Hope that helps
CLI paste? paste.pr0.tips!
Eh, that's the default etc directory for programs which use the GNU Build System (autoconf and friends), i.e. nearly all. It's your package management which chooses the /-prefix instead of the default /usr/local
CLI paste? paste.pr0.tips!
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.
Actually, that's quite wrong. /etc is for system-wide configuration, and $XDG_CONFIG_HOME (~/.config, be default) for user-level configuration. The former is only user when configuring the OS itself, generally, and the latter for desktop applications. Most users will only care about ~/.config.
There's are standards for configuration locations, and only legacy applications and notable exceptions keep them elsewhere.
Generally,
See the XDG Basedir Spec for more details.
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.
Actually, were it not for propietary blobs, there would be abolutely no necesity for them. Linux is designed to have drivers in-kernel, so no user intervention should be required to have devices working, hence, a friedly UI for users to configure devices is sort of wierd.
Seeing as how propietary drives need to be properly integrated for non-power-users to install them, the package manager usually sounds like the right place.
I'd rather have hardware that works well. Closed source drivers don't bother me.
While I agree, I still would prefer that nvidia open sourced it's drivers once and for all, so we can have hardware that works well and stability to go with it.
I'd agree that Linux configs are like Windows .INI.
What's different between Linux and Windows though is that Linux has a culture of documenting its configuration files so that users and administrators understand the various setting and can change them. Windows doesn't have that culture. So that Windows admins, and users often have no way to ever know what the registry entries mean. .INI files were often an intermediate case with context and clear variable names. They quite often could be user modified. Whether registry was a step forward or a step backward really comes down to what you want out of your unified configuration system.
Crashplan distributes an executable binary which installs all of its logs, preferences, etc to /usr/local. Believe me, I've used it for years.
Drivers in Windows land aren't that rosy either btw, try upgrading from Windows 8 to 8.1 (when I say upgrade, I don't mean a clean install of 8.1 after formatting, I mean upgrading to 8.1 from within 8). After upgrading my HP Envy 15 from Windows 8 to 8.1, the laptop stopped hibernating, shutdown/restart would regularly take around 5 minutes and could go upto 15 minutes (no idea why, my usage patterns are fairly consistent). wifi would stop working off its own accord, laptop speakers would suddenly kick in ignoring the headphones, disk usage was almost constantly 90%+ (I have a 128GB SSD and a 1TB HDD) and a myriad of other issues. So I started update all the drivers (10 in total), each updated driver required a reboot and thanks to the time it would take to reboot to windows, I was updating drivers for roughly 2 hours. Since upgrading the drivers, Shutdown and Restart are working like they're supposed to, Hibernate is still flaky (in that, I sometimes get dumped back to the login screen after clicking hibernate or typing in shutdown /h, powercfg throws a different program as the culprit behind not letting me hibernate the laptop each time there's an issue), while wifi and sound are working as expected, disk usage would still randomly shoot up to 90%+ and the only solution I found was to switch of Superfetch and Windows Search and as a bonus, the fingerprint scanner has gone to be flaky, just yesterday, I switched on the laptop from hibernate and at the login screen, Windows tells me to use a longer swipe to scan my finger (I hadn't yet swiped my finger), after that no matter what I did, I kept on getting the same message (couldn't login using my password either since as soon as I'd click the password button, I'd get the same darned message again) and in the end, I had to hard reboot my laptop and the first thing I did after getting to my desktop was disable the Biometric scanner from Device Manager,
If you think this is just anecdotal, try googling for windows 8.1 upgrade disk usage 100 or windows 8.1 upgrade hibernate not working or windows 8.1 upgrade fingerprint login not working
Aaah, but you see, youngune, you secretly do love configuring stuff, you're just in denial about having that masochistic streak.
That would be because a most of the open-source drivers (yes, video is one of the exceptions) are baked right into the kernel and Just Work (TM)(if the hardware's supported, that is). This is why there's no excruciatingly slow "please wait while we search for drivers" when you plug in a new keyboard or mouse; there is no driver.
True, sometimes a device is recognized incorrectly and one needs to dig into arcane settings, but at least most of it is documented in some form or another most of the time. In windows, these problems are less common, but when they happen, far more time is spent on them (aaugh... shotgun debugging the Windows Registry)...
Actually, that's the package manager's doing; automatic re-installing upon kernel updates worked right from day one. The "proprietary drivers" tool that was introduced later is just a friendly front-end to the package manager, because finding the package that makes the most out of the hardware without breaking anything is somewhat less than straightforward for the inexperienced user.
Doing opensoure vs closedsource comparison has also being been done on a regular basis at phoronix.
To sum things up:
Current Mesa/Gallium3D stack is opengl 3.x only, proprietary drivers are 4.x (but work is being done, including by paid developers)
AMD:
except for the latest generation (where the opensource driver team is still debugging the support - but at least AMD does publish documentation and pays a few opensource developpers on their own, so I WILL EVENTUALLY end up supported), the opensource drivers have a decent performance, which has progressively went closer to the proprietary. For slightly older cards you might as well use the opensource drivers (a bit less buggy). For really old cards, even AMD is acknowledging it: they dropped the support from catalyst and are pointing toward the opensource drivers as the preferred drivers.
In short: if it's not the latest generation of hardware, give the opensource drivers a try. Unless you want to only play OpenGL 4.x games on your machine.
Nvidia:
Here, take this pair of dice, they are better performance predictors...
More seriously: performance is rather random, mainly due to the fact that the opensource drivers are entirely developed by reverse-engineering on whatever the developers hapenned to have (if you happen to have a slighly different model, there isn't much they can do). So random bugs and problems even in the middle of an otherwise supported range.
For newer cards the situation is even worse performance-wise, because they boot underclocked by default, and the driver don't know how to ramp-up clocks as demand increases.
At least, opensource drivers follow linux standards and some features aren't utterly broken.
So for know, stick to closed-source drivers - best performance ever -, unless you happen to need a feature which works differently under windows (and thus wasn't ported to linux). In that case, you might do an attempt with opensource and se on which random result you end-up.
With time, this is bound to change: Nvidia might get interested in helping a bit (they hey released a few bits of useful information regarding the Tegra line of embed GPUs).
Intel:
Has a bit lower support than their (windows proprietary) driver (opensource Linux is GL 3.x, Windows is GL 4.x), and their opensource drivers are a bit slower.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Oh yeah, and you can leave inline comments in text files. Like the old setting when trying something new, or a note-to-self.
Hi! everybody, give you recommend a good shopping place. http://www.jerseysoncn.com/ Cheap jerseys/NBA/NHL/NFL/MLB/Hats/Belts/Jewelry/ High quality and best service. Believe you will love it. You must not miss it.
Depends on what you're willing to compromise. I have Nvidia Optimus, everything works perfectly for me. I had to use bumblebee and not Nvidia's own hacks, since NV's don't work yet, and bumblebee does, but it's pretty close to the Windows experience. While it doesn't auto-detect apps and select Intel/Nvidia automatically for me, it does allow me to manually force Nvidia usage much more simply, so I score that a wash.
Intel for 2D/desktop - works great.
Nvidia for performance 3D - works great.
Auto-power-off of Nvidia when not in use - works great.
The only thing I get in Windows that I don't get in Linux at the moment, when I'm docked with 2+ monitors connected in Windows, The drivers seem to understand the connection setup, and the Nvidia chip will stay hot/lit-up all the time, to drive monitor #3. In Linux, if the Intel graphics can't make all the connected displays go, they don't. I'm told that I could fix this too, with quite a bit of hackery/tinkering, but I just plain can't be arsed.
Setup literally consisted of 3 or 4 commands and some testing to verify it was working correctly. No reboot needed, just an X restart once everything was in place.
Now, since I have a nice high end Dell, I can bypass the entire issue by making the Nvidia chip the primary/only graphics adapter, but that kills my battery runtime (from 5-6 hours easily, down to 2-3), and makes the machine hotter and louder.
The preceding comment is my own, and in no way construes an opinon of the Emperor of Mankind.