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
but for myself i still prefer nvidia than amd, because when u use nvidia the grapich always better than amd ,,
maybe just from my side not from another person reason,, nice thread , keep going dude
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. ;-)
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.
The Summary says that the AMD open source driver out performed the nVidia open source driver, not that an open source driver beat a closed one.
Now if only AMD didn't completely drop Linux support for 6 year old graphics cards. If you want hardware acceleration for your x300 or x1800 then you're stuck with 2.6 kernels. This is the same generation graphics card as the Geforce 7 series. In contrast, I can still get hardware acceleration with a Geforce 2 (13 years old!!) using Nvidia blobs.
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.
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.
Let's try to be precise here. Closed source is the cancer, but it's closed specs that causes it.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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.
There, FTFY.
It's just too bad that both open source drivers are still nowhere close to matching their proprietery couterparts.
Anyone know if the Linux drivers for the AMD graphics engine support CUDA and OpenCL?
If so, for which specific boards?
Are benchmarks yet available?
For people curious what the answer to this troll would be...
In AMD's case:
- The proprietary driver has been in development much longer
- The proprietary driver shares much code with the windows driver
- Related to the previous point: The proprietary driver has much more developers. (The open source driver has had 2 AMD employees for some time I believe and some months ago they made that 5). There are several big contributions from the community but GPU drivers is hard and specialized work, so not very many people can do it, or would want to do it in their own time
- Shortly after this article there was an experimental optimizing shader compiler pushed to master that according to some early testers boosts the performance again quite a bit
- AMD releases hardware documentation but I have heard that especially for newer hardware it is not really complete
- 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. This means that nobody else will invest that much time into it since it will be replaced by AMD's code anyway. One example of this is the code for using the UVD for video decoding that they recently released. That thing took forever to be deemed ok for release because they worried so much about not exposing secret DRM decoding methods or something.
That's all I can write down on the spot right now but there are probably several more things to consider. All in all the development could be faster but it is still quite good how it is.
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.
Nice activist moderation.
Suck more NVIDIA cock, loser.
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.
I read Slashdot every day, but only read articles that have some interesting, quirky, geeky non-technical content. Just for once, I thought I'd open one of these highly-specific hardware threads, of which the topic is totally alien to me. I have zero to the power of infinity interest in graphics drivers, but I wanted to see what the general tone of the 116 (!) comments were, compared to the other Slashdot articles.
That's all. No judgement, no witty reply. Carry on.
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).
The people AMD fired had nothing to do with their graphics card devision.
The problem with the power management is that "full" doesn't mean "full".
Mainly there are two methods:
The "dynpm" method which dynamically switches between power states based on gpu usage. But it flickers and doesn't work with multiple monitors.
The "profile" method allows you to choose between "high", "mid" and "low" power profiles. The problem is that "low" still often uses more power than with fglrx. But it also depends on the graphics card, what the bios on it says.
One of the AMD guys has said somewhere in a phoronix thread that only the power management code of fglrx is bigger than the whole open source radeon driver. For a notebook HD 6550M I used some time ago the power management was ok. It used about 2-5 watt more than fglrx on "low" and this was pretty much bearable.
Ditto for various security systems, etc, which still use good ol' co-axial for video.
seems opensource only wins on the HD6450 ... but with no hardware video-format decoding.
to find out why it's cool though: http://www.chromeexperiments.com/webgl/