Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

Not that odd. AMD and NVidia are both trying to find ways to tweak the standards for tiny increases in framerate, Intel is honoring the standards and improving performance by boosting the power of the hardware underneath. That means Intel will continue to lag when it comes to all the different GPU metrics (but they did close the gap a lot recently), but since they're not trying to do shortcuts with the OpenGL and DirectX standards, they are much more straightforward to use.

At this point I have no idea what you are smoking. First, the amount of free RAM does not affect graphics performance and even a shared video memory is allocated to a fixed size on bootup (for example 224 MB). Second, the GMA950 Linux driver is excellent.

Well, you managed to mention not one thing where video power truly matters.

The moment you go into games, game development, image processing, rendering and modeling, perhaps HD video playback (and processing?), or working with very high resolutions, your video card sure does matter, so does the quality of the drivers and its acceptance of standards (specially OpenGL).I found nVidia to be the safest bet in both those tasks I mentioned, as well as support for dual-booting while keeping the same capabilities in

Did you read jedididah's comment above mine?I did specifically ask what he considers "normal day to day use".What I specified is the case for 80% of the 10,000 users that my organisation supports. And even so, there are fewer than 500 that have anything beyond a stock, onboard Intel graphics card.

At home, I have a 9600GT but it's only now after perhaps 4 years that I think it's becoming the bottleneck in my main system despite 2 CPU & RAM upgrades in that time.

You can be using your CPU to decode that video perfectly fine if your video player is not set up to (or can't) decode the video through GPU. Depends a bit on player configurations, I think in VLC you have to explicitly enable it, for example.Well, to be perfectly honest with the current generation of consumer CPUs it's not that much of an issue, so it's becoming an obsolete thing real fast even in mobile land. For the other examples a GPU is definitely much nicer though.

That's only true if you don't need support for newer versions of the OpenGL standard. If you do, the Nvidia proprietary driver is pretty much the only viable option in Linux. The Intel driver is perpetually a few generations behind, and the AMD/ATI drivers are perpetually buggy (though I hear they're getting better).

CURRENT open source drivers should work well on that card, get a more update distro or manually update the kernel, libdrm, mesa and possibly the xorg-ati driver. Also, this open drivers status is for Linux, for BSD the open status may not be as good due the missing/incomplete lower level support in the kernel

If it is failing on a recent distro, with recent kernel and mesa , you should open a bug (sometime fixing a bug on new cards can create another on older cards due the different features available)

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.

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.

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.

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

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.

If we are going to be honest about things, we should also look at why: neither vendor is enthusiastic about providing complete documentation on the products.

We should also be clear about some of the consequences. Better open source drivers provide a better long term solution under Linux. Yes, this is because Linux developers are somewhat hostile to closed source drivers. On the other hand, it is something that you should consider if you are using Linux.

TL:DR;Vendor A nVidia - driver errs on the side of "make it work" vs GL specVendor B AMD - conforms to the OpenGL spec, but is buggy, inconsistent performanceVendor 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

Also if you are a gamer why spend lots of money on a gaming PC and then live with shitty performance because you pick the open-source driver (even if it would be no more shitty than the AMD drivers)?

AKA: If you play advanced games get an Nvidia card and run the proprietary drivers.

Now if you don't play games do you really need a graphics card in the first place? Likely not. So get the integrated Intel or AMD graphics depending on your choice of processor. (And you could always leave AMD in the cold there to

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 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

Just getting facts straight: actually that NVIDIA card is 50% faster than your old AMD card. Still though, the GTX 750 Ti is a chip with reasonable price and fantastic performance/watt ratio, so congratulations on the upgrade.:)

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 driv

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 ha

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.

Of course there are a few here or there. The point I was trying to make was that the titles that are available cross-platform usually don't run as well on Linux as their windows counterpart due to the drivers.

Companies don't put the money into better driver development for Linux because the user base isn't there.

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.)

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

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.

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).

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

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.

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.

/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

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

Actually, that's quite wrong.There's are standards for configuration locations, and only legacy applications and notable exceptions keep them elsewhere.Generally,/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.

[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.

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.

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.

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.

In Linux, programs use text files, which are slow and unreliable to parse, and require a separate config file interpreter in e

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

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 windo

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).

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.

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.

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 th