While the BFS scheduler is getting ready to celebrate its second birthday, in just three weeks AMD’s open-source Radeon graphics driver strategy for Linux will be turning four years old . . . which has ended up being a game-changer in the Linux world. AMD continues to support open-source hardware enablement on their latest graphics processors and recently even hired more developers to work on the code and documentation. How far have they come though in four years?
“For newer Radeon GPUs, we are also still waiting for the stack to even reach 80% the speed of Catalyst.
Besides the performance, the open-source driver stack still needs to catch up with supporting modern revisions of OpenGL (i.e. OpenGL 3.0+), better power management, and other features being sought after by desktop Linux users.”
The whole 6 pages condensed to a couple sentences.
If you do not use your computer to run high-end games, as is the use case for the vast majority of desktop/notebook/netbook computers in actual use, then the performance of the open-source driver stack is already entirely adequate. The open-source driver stack runs a modern composited desktop (such as kwin or compiz) just fine, thanks, with oodles or performance to spare.
After ATI/AMD has discontinued support for r300 devices I had to switch to open-source drivers in my old laptop. While the performance was adequate, there were quite a few stability issues and my laptop got hotter and noisier. Perhaps by now these issues are all resolved but at the time I didn’t like the fact that I was forced to use OS drivers at all.
Now I have a new laptop with a NVidia chip (that’s not a coincident). Proprietary driver is better but open-source one (Nouveau) is not far behind and it does a good job in mode-setting, 2D and basic 3D. Considering that things like suspend to memory “just work” with the Nouveau driver, I chose to use it instead of NVidia’s one.
What I found amazing is that the Nouveau driver is made without any help from NNidia and they are still making as much progress as they are.
The features supported by the open source radeon drivers (for AMD/ATI GPUs) is tracked here:
http://www.x.org/wiki/RadeonFeature
Apart from memory re-clocking for R300 or older GPUs, all of the “Power Saving” functionality is already in place.
The work to go towards OpenGL 3.0, 3.1 and beyond is listed here:
http://www.phoronix.com/scan.php?page=news_item&px=OTc3OA
After stagnating for a long time, this work is finally nearing completion and the majority of items in the OpenGL 3.x work are done. Thankfully it is going ahead at an accelerating rate now.
Performance is also improving all the time.
Just for a bit of perspective here …
Edited 2011-08-19 03:30 UTC
It is also important to note that the “older” hardware they used for the test was 6-7 years old I believe, so it’s VERY old (in hardware years).
With the amount of resources they likely have devoted to the open driver, I’m just glad that there are two (open and proprietary) options to choose from.
It also shows the amount of work it takes to get top performance out of a driver; a lot!
Indeed. 4 years ago I wouldn’t touch an AMD card if you gave it to me for free because I knew the Catalyst drivers would make my life a living hell if I wanted to do anything interesting with my system. Now I just roll with the open driver “just working” and save the headaches for problems I bring on myself.
If you need all features of the hardware and well performing drivers you still have to choose the NVidia closed source drivers.
Your statement is under serious challenge right now.
The closed source drivers (either those from nVidia or fglrx from AMD/ATI) do not implement either Kernel Mode Setting (KMS) or graphics memory management in the kernel. This precludes them from working with Wayland.
Then of course there is the perennial problem that proprietary drivers do not update with kernel updates, so a new kernel breaks these drivers.
The features currently covered by open source radeon drivers (for AMD/ATI GPUs) are tracked on this page:
http://www.x.org/wiki/RadeonFeature
This is updating rapidly. Even video decode is happening, even though AMD/ATI did not release programming specifications for UVD, so the drivers are using the 3D engine instead. This will bring video decode acceleration even to AMD GPUs which do not have a dedicated hardware video decode capability.
BTW, there is a Google Summer of Code project to implement a hardware video decoder for WebM using the 3D engine. This project will bring hardware video decoding for WebM video even to GPUs which do not have a dedicated hardware decoder for that codec.
Tuning for for performance of the open source drivers has not really been undertaken in earnest yet, as the final pieces of functionality are still being worked on. Even so, if you had looked into it a few months ago, you would have seen that performance was about 60% of that of the closed source driver (fglrx). Right now it is perhaps 80%. In a few months time …
In a few months time it is likely that the radeon open source Gallium3D drivers will overtake the closed source driver fglrx for performance. OpenGL 3 compliance will be reached, and OgpenGL 4.x work will be underway. The open source radeon driver is a part of the kernel, and it updates automatically and seamlessly with Xserver updates and kernel updates. Running the new Wayland graphics server is not a problem at all.
When this all occurs, IMO your statement will be well and truly overtaken by events.
Edited 2011-08-19 00:51 UTC
That’s non-issue for at least a couple of years to come. Perhaps even longer.
If NVidia really cares about the general purpose desktop market (that is not enterprise and not mobile, where most of money are coming from) they have plenty of time to produce their own mode-setting stack and a custom version of Wayland.
Although, I guess, they will simply continue to ignore developments in the kernel land the way they are doing it today. After all workstations will continue to use X for a decade or so and mobile devices already use some custom graphics stacks (Wayland could potentially get some foothold there but their licensing policy might be an issue).
It won’t be long before the open source AMD/ATI drivers deliver the same kind of GPU performance-per-hardware-dollar (or better) as closed source nVidia drivers. Already this point has been passed for some of the older GPUs (for which AMD/ATI released the programming specifications first, some four years ago).
When that point is reached for newer GPUs also, there will be absolutely no reason at all to get nVidia hardware for a machine intended to run Linux. To do so would be madness, regardless of any intent to run Wayland or not.
Even if nVidia finally release programming specifications for nVida GPUs today, as AMD/ATI began to do up to four years ago, it is too late … it will still take the Nouveau open source project a number of years to catch up with other open source drivers.
For low-end inexpensive graphics, use Intel. For low-power-reasonable-performance graphics, use AMD Fusion APUs. For highest-performance graphics, use ATI/AMD graphics cards. This is clearly the way to go for the future. We are almost unequivocally at this point already. If you don’t run games, it could be argued that we passed that point some time ago.
Edited 2011-08-19 03:14 UTC
I sincerely hope they ATI/AMD OS guys will manage to match and overtake competition. But I will let others verify the result. I’ve done my part of fiddling with both Catalyst and OS drivers and I didn’t like that experience. In big part that was AMD fault – they dumped majority of their Linux users almost at the same time they released the specs. Hard to blame OS guys for the state of their drivers at the time.
Frankly speaking I have no time to fiddle with graphics drivers anymore. I went NVidia drivers on my RHEL workstation (work beautifully) and Nouveau drivers on my laptop (for easy upgrades, suspend to memory, and Compiz).
Intel drivers are also an option, especially for netbooks/small notebooks, but (1) I’m currently using XP on such hardware, (2) Intel drivers are too unstable at the moment (but I’m sure they will be best in class really soon).
AMD/ATI graphics hardware stomps all over Intel graphics.
Some time ago I happened to be granted a modest award for which I could choose, amongst other things, a new low-end netbook. I chose this model within the allowed price range:
http://techreport.com/articles.x/20415
The CPU is under-powered, it has only 1GB of RAM, but the graphics capabilities absolutely stomp all over other Intel Atom netbooks of a similar price.
Now that AMD/ATI GPUs have good open source drivers, which no-one has to “fiddle with” as they work out of the box, there is no way that Intel graphics will ever again be best in class on Linux platforms. Not a hope.
Edited 2011-08-19 05:13 UTC
That kind of works both ways, if the drivers work well.
It would be easier and more feasible that the project will be a success. Thus the project might be finished sooner as it attracts more developers.
I’m not sure why you believe that the open source driver will overtake the closed-source one in a few months time. It’s really hard work to get that performance out, and I really doubt the Linux driver team has the same resources as the Windows driver team at AMD.
Btw, it’s not 80% now on new cards, it’s still closer to 50-60% I think. The 80% figure is relevant for cards that are about 6-7 years old, as far as I can tell.
The programming specification documents that AMD/ATI released are here:
http://www.x.org/docs/AMD/
Note the dates. The documents for the older cards were released (~ early 2008) about a year before the documents for the newer cards (~ early 2009). There is a direct correspondence to the performance, in that there is better performance (relative to closed source driver for the same card) for those older cards where the open source developers have had a year longer to work on the drivers.
That is the first point. Given the same amount of time, it would be reasonable to expect a similar improvement for newer cards as we see now for the older cards. In fact, having gone through the process once for the older cards, the still-to-be-done performance fine tuning for the newer cards might even happen quicker.
The second point is that closed source drivers are developed for Windows. The majority of this code is then re-used for Linux, with a small open source wrapper program to interface to the different kernel. The drivers are optimised for Windows. Because of that fact, and also the fact that the closed source drivers require an extra “adapter” layer, it is reasonable to expect that eventually the open source drivers will catch up, given that they are tuned for Linux.
Apart from the development going on at Xorg, AMD itself has been hiring new open source developers of late.
Edited 2011-08-19 04:59 UTC
That’s precisely my point: the older cards are now at about 80% on average. So if we apply your reasoning, then a year from now we will have the same 80% performance of the newer cards, which I wouldn’t say is really “overtaking” the closed source drivers.
In terms of the drivers being written for Windows vs Linux, I think there’s not much of an overhead from the current Catalyst drivers being first developed for Windows.
For example:
http://www.phoronix.com/scan.php?page=article&item=897&num=1
In terms of pure raw performance, it is probable that open source drivers will only ever catch up to closed source drivers.
In terms of overall working, even at 80% raw performance (speed), the open source drivers are already ahead of the proprieatry graphics drivers for Linux. The open source drivers will work “out of the box”, whereas the closed source drivers are simply not supported any longer. If you have an older ATI card on your Linux box, already it would be utter insanity for you to run anything other than the open source radeon driver written at Xorg.
There are some games for Linux now which work better under the open source drivers than they do under the closed source drivers. World of Padman is one.
http://www.phoronix.com/scan.php?page=article&item=amd_four_r300&nu…
In other cases it is, of course, the other way around, as shown for OpenArena on that same page.
Being open source, this allows people to investigate exactly why World of Padman is faster than OpenArena. This in turn allows two things to happen:
(1) driver developers can focus their efforts to improve performance by seeing where OpenArena performance is low, and
(2) game developers can use the better performance in areas where World of Padman is strong as the basis of their game engines.
Just by natural evolution the performance of games on Linux will eventually be better with the open source drivers than with closed source drivers. It is inevitable.
Edited 2011-08-19 06:12 UTC
Err, what?? This is the point I was discussing, first:
Then just now:
Yes, that was definitely confused, I have to admit.
Obviously the hardware is the same for both open source drivers and closed source drivers. In some areas the closed source drivers are already optimal or nearly so, and there can be no worthwhile gains achieved beyond that no matter how hard one tries. Clearly in this sense the open source drivers will never surpass the closed source ones, it isn’t possible.
Howver, having said that, there are obviously some areas for each driver where performance is not optimal (i.e. is not absolutely constrained by the common hardware). In some situations the closed source drivers are better, and in other areas the open source drivers are better. Right now the former occurs more frequently than the latter, and as an overall average the closed source drivers are better.
Howver, for some older cards, the closed source drivers are never going to get any better. AMD/ATI no longer support them.
The open source drivers have two distinct advantages. Firstly they are designed for Linux so any “impedance mismatches” between the drivers and the rest of the graphics stack can be tuned out. For closed source drivers, the drivers are tuned for Windows, and one gets what one gets on Linux.
Secondly, being open source, both the open source drivers drivers and the rest of the graphics stack can “evolve”. Whatever already works better than the closed source drivers can be left strictly alone, and whatever doesn’t work as well as the closed source drivers can be tuned for performance. The open source Linux graphics stack is not constrained by what works best for Windows.
Eventually, the open source Linux graphics stack will out-perform the closed source drivers, simply by exploiting areas where the closed source drivers are not optimal on Linux.
Edited 2011-08-19 07:06 UTC
Yeah, I definitely think the open source drivers have a lot of promise, especially being integrated so much better and naturally than the closed-source drivers.
It would be great to see the open and closed source teams at AMD be able to collaborate on the same code-base, but that’s probably a bit of an architectural stumbling block (ie, keeping hidden whatever they want secret in the closed-source).
Stop making stuff up. You said the same crap about the Nvidia Proprietary driver and we discovered that was a load of made up rubbish.
Sharing components != designed for Windows.
Edited 2011-08-19 08:24 UTC
Of course the nVidia binary driver is designed for Windows. Not even nVidia would contest this, it is self-evident.
There will therefore be some things that are not optimal for Linux.
This is also plainly evident by the fact that open source drivers are already faster than closed sorce drivers in some areas.
Edited 2011-08-19 10:05 UTC
From here
http://www.phoronix.com/scan.php?page=news_item&px=ODg3NQ
Sharing common compontents != designed for Windows.
This supports exactly what I have said continuously to you.
I have read countless articles on this and not once have I seen anything where NVIDIA claim they have just wrapped a Windows Driver.
All they have done is simply re-architecture their code so they can reuse as much common code cross platform.
Believe whatever ridiculous rubbish you like.
Edited 2011-08-19 14:05 UTC
“Performance parity with Windows” != designed for both.
Windows is pretty abysmal at OpenGL too, it is optimised for DirectX.
The Nvidia binary blob driver is not capable of KMS or memory mangement in the kernel.
The nvidia binary blob is not designed to integrate with the Xorg/Mesa graphics stak … in fact it replaces most of it.
The nvidia binary blob is designed for Windows, and adapted for use on Linux.
This gets ridiculous. You have made up your own criteria for what it means to be designed for a particular operating system.
Your criteria for whether the driver is designed for Windows or not seems to stem from opinions rather than facts.
Basically when you lose an argument you make up new criteria that “proves” your argument.
Pathetic.
Nvidia Binary Driver has by far the highest OpenGL performance for Linux, so them replacing large parts of Xorg and Mesa is probably done for a bloody good reason. Probably due to Xorg being a bit of mess and Mesa supporting OpenGL 2.1.
KMS is unfortunate … but this does not mean the Drivers are designed for Windows. It just means it is not supported.
Edited 2011-08-20 18:33 UTC
If only they should make 1 way for drivers to interact with the kernel and keep it that way between versions. That way you don’t have to spend a lot of hours to keep drivers working, but you can use that time to make them better.
To keep options open for future functionality they could ask drivers to tell how they want to interact with the kernel by a version number or something like that.