Slashdot Mirror
AMD's Open Source Linux Driver Trounces NVIDIA's
An anonymous reader writes "In a 15-way graphics card comparison on Linux of both the open and closed-source drivers, it was found that the open-source AMD Linux graphics driver is much faster than the open-source NVIDIA driver on Ubuntu 13.04. The open-source NVIDIA driver is developed entirely by the community via reverse-engineering, but for Linux desktop users, is this enough? The big issue for the open-source 'Nouveau' driver is that it doesn't yet fully support re-clocking the graphics processor so that the hardware can actually run at its rated speeds. With the closed-source AMD Radeon and NVIDIA GeForce results, the drivers were substantially faster than their respective open-source driver. Between NVIDIA and AMD on Linux, the NVIDIA closed-source driver was generally doing better than AMD Catalyst."
NVIDIA doesn't have an open source graphics driver... Nice misleading title there, timmy.
1) unfair comparison
2) old news
3) 100% nvidia's fault
Same old shit as always (DNRTFA).
I'm tainting my pure and virgin kernels since about 10 years with the evil corporate drivers from Nvidia, because it works and performs. Sorry Gnu!
fine, don't open source the drivers but at least open up the video card hardware so dev's can write their own drivers. Intel and amd cpu's are open why not gpu's.
wow, what a subject line. for the oss community to be able to get hw acceleration through reverse engineering is impressive!
this isn't network/disk i/o hardware. opengl is a very complex api. it took nvidia years to get their ogl drivers into stable working order (without reverse engineering).
Access to the documentation of the hardware you are writing a driver for helps when writing the driver. If the OSS driver programmers are as good as the manufacturer's, or even slightly better, you'd still expect the manufacturer to produce better drivers simply because they don't have to waste their time to figure out how to access the hardware. Instead of experimenting some extended time, they just have a look in the internal hardware manual.
If the OSS drivers are better than the manufacturer's without the manufacturer opening up the relevant documentation, it usually means that either the hardware is outdated, or the manufacturer's programmers did a really bad job, or both.
What this shows is that when the vendor provides specs, as ATI has, it improves the quality of the drivers. If nVidia provided specs, the nouveau driver would probably be faster than radeon.
Personally, my problem with the radeon driver isn't that it's not fast enough. It's that it detects my 4:3 CRT HDTV as a 16:9 display when connected with HDMI, and no modeline I can come up with can convince it otherwise. This is despite Catalyst on both Linux and Windows on the same hardware supporting 1280x1024 and 1024x768 with no problems. That's the only thing keeping me from using the open source ATI driver on Linux.
BTW, Is anyone else having trouble logging in?
Not entirely.
AMD's main drivers are proprietary, but they have open specs making it much easier for the community to write open source drivers, and they also assist the community in making those drivers.
NVIDIA neither opens their specs or assists in the development of the open source drivers.
That the open source AMD drivers would trounce the open source NVIDIA drivers is about as surprising as the Daily Mail finding something causes cancer.
I stole this Sig
I would have preferred benchmarks on Windows game performance in WINE. Sure, that would have added some extra configuration problems to the benchmarks, but those are the numbers I really care about as a Linux user that keeps a Windows boot around just for games. From my experience, that's also where AMD cards take a shit, whether using open or closed source drivers (sometimes it's performance, sometimes it's game-breaking bugs that don't affect nvidia cards).
Apparently wizard is not a legitimate career path, so I chose programmer instead.
Maybe the Open Source driver does not support all the same features the NVidia one does?
I mean who can see from their screen if the GPU really did all of the 100+ flashy named video processing tasks and whatever else it was supposed to do?
Maybe it flunked on a certain texture-whatever effect and did a faster, almost as good one?
Maybe NVidia puts more auxillery tasks on the GPU, like physics stuff?
How can we compare the 2 drivers, when one of them is closed? And they dont even run on the same cards for AMD/NVidia...
I can login as Anonymous Coward quite fine. ;-)
I've never had a problem with the Nvidia driver. I don't know about AMD's driver because it sucked so bad back a few years ago that I didn't bother ever trying it again. I might buy an AMD board and try it again now.
If you can't see the difference, does it matter?
Give me Classic Slashdot or give me death!
Give two groups the task to write a driver. Give one group full documentation of the hardware the driver is for. Give the other group no documentation of the hardware. Which group do you think will produce the better driver?
Indeed, even if full documentation were available, the manufacturer's programmers would still have an advantage since they can simply ask the hardware developers whenever anything is not entirely clear.
More than that, the actual headline should have been:
Drivers with complete support for hardware features outperform drivers with partial support.
Even the summary says that the Nvidia reverse-engineered driver doesn't support adjusting the GPU's clock, and since Nvidia's firmware has the thing clocked to "barely running" when it starts up, it's hardly a shock that you get piss poor performance.
Obligatory car analogy: reverse engineering the ECU firmware on an engine, except in your version the rev limit is set to 1500 RPM, when the engine redlines at 8000; and then you wonder why you're short on horsepower and torque.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
The complexity of OpenGL itself may or may not be the issue. To the best of my understanding; both nouveau and the AMD OSS drivers use Gallium3d and Mesa(which can also provide an openGL implementation entirely in software, if you don't mind a lot of waiting). Actually taking advantage of the specialized hardware in a fast and stable way, though, is device specific.
apart from RMS?
More precisely, it said that both the closed-source drivers beat the open source ones with Nvidia's slightly ahead of AMD's.
I'm going to weigh in here. The Nouveau drivers are better than the open source ATi drivers. Simply because, the performance doesn't matter. It's the feature completeness of the drivers that matters. The Nouveau drivers have been very steadily working towards a point where all previous generation cards and the current generation cards have the same feature set at the same time. If you check out the nouveau feature matrix it's a stunning achievement how rapidly they've come to the point they're at. People don't seem to realise that aside from SLI, OpenCL and the hardware reclocking support. The Nouveau drivers are basically feature complete. Noone uses TV out anymore since HDMI/digital video has taken over. Within 2-5 kernel revisions, the reclocking stuff is going to be completed. When that hits, the Nouveau drivers are going to shatter the AMD ones for performance. Already in preliminary testing where reclocking was enabled, the Nvidia cards were performing at or above the level of the nvidia binary blob. When the reclocking support is turned on these cards are going to be running OpenGL 3.3 and probably pushing a lot of GL4 features. The interesting thing is if you check the status matrix, the same level of support exists in current high-end leading Nvidia graphics cards as in the previous generation's cards. This means that the nouveau driver appears to be similar to the Nvidia blob in that it's adapted to support multiple graphics card models easily.
He's talking about on Linux. The old ATI Linux drivers were notoriously bad for years, and while they've gotten better since AMD bought them, they still fall short of nVidia's reliability and capability, regardless of the performance of the hardware itself. If you just want a graphics card to drive a monitor or two, AMD hardware is fine. If you want something that will do OpenGL or video playback well, you want nVidia, or at the very least Intel.
The open source drivers support the older cards. ATI's plan is to dump support for legacy cards on to the community driver when it's too much of a pain in thte ass to keep the code going in their closed driver.
Nothing has changed in a couple of years regarding the relative performance of the open source kernel drivers for NVidia and ATI cards and their closed source binary counterparts.
Given similar and modern hardware, the open source ATI driver is much better in several areas including general performance and ease of installation. I believe this is due to ATI publishing specs to a much greater extent, and I think they even have (had?) employee(s) dedicated to developing the OSS driver that ships w/the kernel. NV on the other hand, shows very clearly through their (in)actions that they do not give a shit about Linux, and the neuveau (sp?) driver is completely reverse engineered w/little to no help or interest from NV.
The closed binary drivers in terms of relative performance show the opposite with nVidia edging ATI out in terms of performance. But again, the ATI driver is a breeze to install where the NV driver installation is a bit quirky, for example forcing you to exit X to do the install. Not a big deal for most users, but probably a bit disconcerting for "newbies". Another thing that turned me off about the closed NV drivers in the past (don't know if this still holds) is that they would not install if you were running a Xen kernel, or if you were running VMware Workstation.
Another thing to keep in mind when selecting a card is GPU compute capabilities: cuda vs. OpenCL support. The level of support varies by both OS and program; some apps support one API but not the other. If your app supports OpenCL only, by all means go for the ATI card as they perform much better. If your app supports cuda only, or if the app happens to be Blender, then the only choice is NVidia because ATI cards cannot run the proprietary cuda API, and in the case of Blender, it's OpenCL implementation is severely lacking for various reasons regardless of operating system.
In the end, use your head and do your homework before deciding on a GPU, and ignore the troll headlines.
It's just too bad that both open source drivers are still nowhere close to matching their proprietery couterparts.
And what is wrong with that? Didn't the FOSS community say "just open the specs and we'll support it" to everyone that would listen? Well here is their chance as AMD can't afford to keep supporting an arch that is no longer used anywhere in house anymore, the old cards used VLIW 4 and the new cards use vector based GCN so its NOT a case of simply backporting, the hardware just is no longer compatible.
Nvidia can support the older cards easier as they haven't had any major changes in the way they do things, with AMD that is simply not the case.
ACs don't waste your time replying, your posts are never seen by me.
What's interesting to me:
Nvidias driver owning AMDs.
Open-source? I'm not going to rewrite it anyway.
Should have just ranked them by speed. Slowest to fastest: ... I'd like to know where Intel's rank in that line up. I know they're slower than the closed source ones, but what about the open source ones (and what cards?)?
Nvidia with open source drivers
AMD with open source drivers
AMD with closed source drivers
Nvidia with closed source drivers
I haven't got many ATI cards, but my laptop has a decent mobile-series radeon and the *only* issue I've had was with Ogre3d terrain and the closed-source driver. Windows was solid. Linux works fine except it won't render textures on Ogre-terrain. I think that may be a non-issue as IIRC there were some fairly nvidia-specific extensions there.
Other than that, everything that works on my nVidia machines works just fine on the ATI card. For installation, the FGLRX driver is often easier to manage than the nvidia blob, with one annoyance in that it wants an X restart when adding an HDMI monitor (haven't seen how nVidia handles that). It's gotten MUCH better since AMD took over though.
On ATI, I've done multi-head, windows games, WINE games, and GL development without any major issues other than noted.
I haven't tried the FOSS driver recently, but I might just have to give it a shot as well.
Last complaint about ATI vs nVidia... AMD/ATI do seem to drive binary-support for cards faster (which is where having functional FOSS drivers is quite nice).
Except that Intel's GPUs just don't support some of their functionality on Linux. Like OpenCL. Or a modern OpenGL version.
Right, you might not care, if your usage pattern is mostly about websites and text files. For me, nVidia GPUs are the *only* thing that both brings the functionality I need (as a GPGPU software developer) and actually works.
AMD linux drivers are in a habit of losing functionality over time. Like all functionality (happened to me once). Others have complained that after updating the driver, some parts of the functionality that were present are no longer there. Because of the way Linux kernels work, you usually can't put an ancient driver to a new Linux distro.
I gave up on reading Phoronix because they report on nothing but benchmarks when those are very uninteresting from a Linux perspective unless things fall way behind. There are plenty of non-Linux sites benchmarking hardware. What we need in a Linux review site is someone focuesed on compatibility, stability and ease of configuration.
AMD releases hardware documentation but I have heard that especially for newer hardware it is not really complete
Due financial troubles, AMD had to fire many people, incl the majority of its Linux developers. Maybe that's why the docs are incomplete...
AMD allegedly has some code for the open source driver for power management and other stuff ready but they have always problems with legal review so they can't release it.
The Mesa wiki claims full power management support for almost all AMD GPUs. Can't verify that, though, as I'm currently on NVidia.
They didn't *completely* drop it. Their 5 full time employees for the open source driver can still work on the open source driver.
They don't work on drivers for legacy hardware. AFAIK most work on the R300 Mesa driver is done by Red Hat.
I see nobody has mentioned FreeBSD and Kernel Mode Switching. Problem is that some time ago in a galaxy not far away the authors of opensource Radeon driver decided to abandon UMS in favor to KMS which obviously required card-specific code in OS kernel of every OS that uses the card. FreeBSD folks work hard, but my Radeon supermeganotebook that costs me a fortune still collects dust, and I have been forced to sell my Radeon, buy Geforce and use proprietary drivers. They suck - they have some issue with framebuffer sync appearing as ghostly stripes on everything moving (both mplayer and Mozilla scrolling).
Ditto for various security systems, etc, which still use good ol' co-axial for video.