AMD's New Gambit: Open Source Video Drivers
by Ryan Smith on September 25, 2007 12:00 AM EST- Posted in
- GPUs
As the computer hardware industry has matured, it has established itself in to a very regular and predictable pattern. Newer, faster hardware will come out, rivals will fire press releases back and forth showcasing that their product is the better one, price wars will break out, someone cheats now and then, someone comes up with an even more confusing naming scheme, etc. The fact of the matter is that in the computer hardware industry, there's very little that actually surprises us. We aren't psychic and can't predict when and to whom the above will happen to, but we can promise you that it will happen to someone and that it will happen again a couple of years after that. The computer hardware play book is well established and there's not much that goes on that deviates from it.
So we have to admit that we're more than a little surprised when AMD told us earlier this month that they intended to do something well outside of the play book and something that we thought was practically impossible: they were going to officially back and provide support for open source drivers for their video cards, in order to establish a solid full feature open source Linux video driver. The noteworthiness of this stems from the fact that the GPU industry is incredibly competitive and consequently incredibly secretive about plans and hardware. To allow for modern, functional open source video drivers to be made, a great deal of specifications must be released so that programmers may learn how to properly manipulate the hardware, and this flies in the face of the secretive nature of how NVIDIA and ATI go about their hardware and software development. Yet AMD is and has begun to take the steps required to pull this off, and we can't help but to be immediately befuddled by what's going on, nor can we ignore the implications of this.
Before we go any further however, we first should talk quickly about what has lead up to this, as there are a couple of issues that have directly lead to what AMD is attempting to do. We'll start with the Linux kernel and the numerous operating system distributions based upon it.
Unlike Windows and Mac OS X, the Linux kernel is not designed for use with binary drivers, that is drivers supplied pre-compiled by a vendor and plugged in to the operating system as a type of black box. While it's possible to make Linux work with such drivers, there are several roadblocks in doing so, among these being a lack of a stable application programming interface (API) for writing such drivers. The main Linux developers do not want to hinder the development of the kernel, but having a stable driver API would do just that by forcing them to avoid making any changes or improvements in that section of the code that would break the API. Furthermore by not supporting a stable driver API, it encourages device makers to release only open source drivers, in line with the open source philosophy of the Linux kernel itself.
This is in direct opposition to how AMD and NVIDIA prefer to operate, as their releasing of open source drivers would present a number of problems for them, chief among them exposing how parts of their hardware work when they want to keep that information secret. As a result both have released only binary drivers for their products, including their Linux drivers, and doing the best they can to work around any problems that the lack of a stable API may cause.
For a number of reasons, AMD's video drivers for Linux have been lackluster. NVIDIA has set the gold standard for the two, as their Linux drivers perform very close to their Windows drivers and are generally stable. Meanwhile AMD's drivers have performed half as well at times, and there have been several notable stability issues with their drivers. AMD's Linux drivers aren't by any means terrible (nor are NVIDIA's drivers perfect) but they're not nearly as good as they should be.
Meanwhile the poor quality of the binary drivers has as a result given AMD's graphics division a poor name in the open source community. While we have no reason to believe that this has significantly impacted AMD's sales since desktop usage of Linux is still low (and gaming even lower) it's still not a reputation AMD wants to have as it can eventually bleed over in to the general hardware and gaming communities.
This brings us back to the present, and what AMD has announced. AMD will be establishing a viable open source Linux driver for their X1K and HD2K series video cards, and will be continuing to provide their binary drivers simultaneously. AMD will not be providing any of their current driver code for use in the open source driver - this would break licensing agreements and reveal trade secrets - rather they want their open source driver built from the ground-up. Furthermore they will not be directly working on the driver themselves (we assume all of their on-staff programmers are "contaminated" from a legal point of view) and instead will be having the open source community build the drivers, with Novell's SuSE Linux division leading the effort.
With that said, their effort is just starting and there are a lot of things that must occur to make everything come together. AMD has done some of those things already, and many more will need to follow. Let's take a look at what those things are.
Facebook
Twitter
RSS
34 Comments
View All Comments
gouyou - Thursday, September 27, 2007 - link
I think you have to take a look at the move in a bigger context. Offloading processing function to GPUs and integrating CPU and GPU: not long ago ATI/AMD released ACML -a library to offload some mathematical computation to GPU- and AMD is talking for quite some times about fusion -putting a GPU core in the same package as CPU cores-.Having linux, thanks to open specifications, be able to use seamlessly both CPUs and GPUs would be great for a numer of people in the HPC community. A processor with both CPU and GPU cores seamlessly integrated with Linux might target a place in some of the top 500 computers in the worlds ...
... Just thoughts ...
floffe - Wednesday, September 26, 2007 - link
I just want to point out that AMD has been good with releasing specs so that their CPUs can be fully supported by open source (for example when they launched amd64, Linux was ported before the hardware was actually available, but also several of the BSDs ran on x86-64 before a Windows port was released). ATi, on the other hand, has treated Linux as second-hand users, which is where they got the reputation for shoddy drivers. The fact that ATi executives now answer to AMD ones could have been a major factor in this change.stevekgoodwin - Wednesday, September 26, 2007 - link
There's nothing limiting drivers written to just Linux. Any operating system could be targetted. It should be possible to create cross-platform drivers from the same source code (assuming the low-level stuff can be abstracted away successfully).Laptop video drivers tend to be updated rarely to never; it'd be fascinating if this led to better Windows drivers for some users.
OSS could result in new features that aren't commercially worthwhile (although given the amount of junk in ATI/nvidia drivers...), or control panels that are easy to use, or just plain better drivers.
Maybe innovative features could result from people who experiment with the hardware -- anyone ever see a BBC micro running 2 screen modes at once (2/3 hi-res/low colour, 1/3 low-res/hi-colour)? Better OpenGL drivers. Drivers for out-dated OSes.
This is potentially of interest to everyone. Be interesting to see how it pans out.
stmok - Wednesday, September 26, 2007 - link
Have you even written drivers for Linux? What about Windows? You do realise they're completely different driver models, don't you? (This is especially the case with Vista when MS changed the spec, which had both AMD and Nvidia scrambling to bring out something stable).You can't just write a driver for all OSs willy-nilly. It has to be seriously well-thought out in design. No one would bother given the fact that there is not a need or demand for such an approach.
Then again, why would the Linux driver community help Windows? That's what the AMD/ATI driver team is for!
The OSS driver isn't some super fancy thing. Its just gonna provide the bare essentials. If you use the existing "radeon" xorg driver with older Radeon cards, don't expect miracles. It won't be fast as the proprietary one, but it will have bugs resolved quickly. As well, it will NOT have all the goodies of the binary one from AMD/ATI.
All AMD has done is provide specs and some resources to establish a foothold for their future project. ie: Fusion.
rebturtle - Tuesday, September 25, 2007 - link
How nice would it be to have a driver that allowed 1 card for general graphics, and a second for number-crunching/ scientific data calculation / game physics from that older GPU you have left over from your last upgrade? Imagine crunching BOINC units in seconds.....BurnItDwn - Tuesday, September 25, 2007 - link
I saw something about this posted to Dailytech a while before this. This is VERY good news. While the % of users who run *nix on their desktop machines is very small, many of us can not stand having to use a BLOB for a driver. This should make for much less buggy drivers and much better functionality within X and possibly even allow for some better gaming support too. (But I'm not about to put any money on the last part.)Anyhow, I think this move by AMD showing that they support the Open Source ideology and that they will start to cater a bit more to Open Source users will gain them a lot more support then the potential IP losses to their rival Nvidia. I think this will give them a little boost to sales when they really need it. I had been planning on replacing my old 939 x2 4000+ with an Intel Q6600, but because AMD is doing so much to cooperate and support the Open Source sector, I am going to give them a chance and wait for them to release something that can compete with the Q6600. I also was thinking of replacing my X1800xt with an Nvidia 8800GTX once the prices come down a bit, but perhaps the X2900XT will interest me instead.
PS all the comments about "windows can do it better" or "command lines are so 80s" are false. Windows can sometimes do some things better, but generally, OpenBSD or Linux can do most things using less resources and with less frequent problems. Also, there are things that are much better left to a GUI, but there are also things that are much quicker and more efficient when left to a CLI. Just because something has a learning curve doesn't mean it's bad.
smitty3268 - Tuesday, September 25, 2007 - link
yyrkoon - Tuesday, September 25, 2007 - link
that a lot of people are missing a lot of points here.First, not only can AMD use this as a recruiting tool for potential new driver devlopers(which really, who is going to prove they are qualitfied enough by proving that they can turn on a video card, and render a minor 2d polygon?), they can also use this as a free way to have others improve their drivers for them.
Second, this can be viewed as AMD trying to improve their relations with the OSS movement, getting their foot in the door so to speak, in anticipation that perhaps Win Vista may drive more users to the Linux side of the camp. Sharing minor details such as turning on a video card, drawing a 2d polygon, and whatever else that does not hurt them technology wise cannot really hurt them, because the Linux/BSD communties are already doing this right now. SO, this greatly improves their appearance with the *NIX people, perhaps raising their market share slightly in anticipation that their CPUs of current may actualy loose them money.
Thirdly, it should not be all that hard for a seasoned/good developer with knowledge of how drivers work to reverse engineer even their most current driver technology. It would be the implmentation without permission of said features that would be the problem. So, this is not a magic bullet that will immedaitely solve all ATI/AMD driver problem with *NIX, at least, not right away.
All in all, I think this could be a step in the right dirrection, and if AMD is sucsessful in this endevor, nVidia will surely have to follow suite. That being said, AMD still holds claim to being the first to do so. IF AMD does release much more information on their video cards, it could even work out as being a win/win situation for everyone. At the same time, this *can* open doors of all sorts in the realm of system exploitation, but there is really nothing a malicious developer cannot already do with enough knowledge / time on his hands to begin with . . .
I would be very interrested to see what the OSS community could come up along the lines of unified shader technology capable drivers for *NIX, *if* AMD ever made this data public. Although I am not sure who actualy holds patents on this information/technology so, I am not sure this is even legally possible. It would be great if other vendors, including those with various other hardware types would eventually do the same thing as driver support is one of the few things that has kept a stranglehold on Linux/BSD for a while now.
With this hurdle finally passed(eventually), perhaps this would make Microsoft more compeditive in the OS field, and possibly dump things like DRM, and the other stupid tactics we who use Windows because it is currently more solid have to put up with.
HiThere - Tuesday, September 25, 2007 - link
This article is full of detail, but lacks polish...it reads like someone who is intentionally wordy, in the hopes that the audience mistakes verbiage for intellect.Example: "As the computer hardware industry has matured, it has established itself in to a very regular and predictable pattern."
How about: "The maturing computer hardware industry has established a predictable pattern."
Or: "The maturing hardware industry has established a pattern of..."
You could trim a good portion of the article and not loose any useful content.
Araemo - Tuesday, September 25, 2007 - link
Who knows, maybe they're paid by word count? :P