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.

Between Here and There

It's only fair to preface this section with a warning that when AMD announced this effort earlier this month, we are and continue to be skeptical about their actual intentions and how serious they are about all of this. "Open source" has been and continues to be a buzz word that gets used by companies wanting to attract attention to themselves, and we're not going to throw out the possibility that this is AMD abusing the term to their own benefit. We've already noted that AMD has previously suffered from a poor reputation in the open source community due to their poor drivers, and this announcement has already done a lot to turn that around. As we've stated before, this isn't something that is in the computer hardware play book, so we can't help but wonder if what AMD has promised may be too good to be true.

With that said, our skepticism has tempered some in the past few weeks as AMD has taken the first few steps needed to make these drivers a reality, and at a pace faster than we were expecting. There are a few "moments of truth" to come that we are left wondering if AMD will pass, but they have proven to us that they are serious so far. This article is proof of that, we initially were not going to write an article about AMD's effort believing it to be PR fluff.

There are several steps in making the modern, functional driver that AMD wants to achieve, and broken down they are roughly as follows: Initialization, primitive 2D, accelerated 2D, primitive 3D, and finally full 3D functionality. Because this driver is being developed externally, for each step AMD needs to deliver hardware specifications for all the products they want supported by the drivers, so that the programmers working on the driver can use the specifications to make their driver work. As we get in to the later steps, the driver & specification complexity increases, along with the number of secrets that must be revealed.

So far AMD has released two specification documents, one covering the RV630 (HD2600 series) and the other covering the M56 (Mobility X1600). To give you an idea of the complexity of these specifications, they only cover the first two steps, initialization and primitive 2D, and yet they add up to just shy of 900 pages. Amazingly, these are (as far as we know) AMD's own internal documents and not new documents created/censored for public use, which is one of the factors that have convinced us about how serious AMD is about their efforts.

In spite of the length of the documents however, they are really only the tip of the iceberg. With these documents programmers can create a driver that turns the video card on and can draw a basic 2D image via directly manipulating the frame buffer (and indeed Novell's driver is already close to achieving all of this so soon), but that's it. These specifications are not enough to enable advanced 2D functionality such as blitting, blending, or video decode acceleration. They are also not enough to do any 3D rendering.

The fact of the matter is that the specifications released so far do not involve anything that is a trade secret or otherwise needs to be kept hidden; what AMD has released thus far is what will be the easiest to release. What lies between here and a fully functional driver as a result will be the hard things that AMD needs to do, and hence our continuing skepticism in spite of what they have already done.

Releasing the rest of the specs required to build a fully functional driver will expose information that isn't usually public, such as details of the Ringbus memory controller, the UVD video decoder, the programmable anti-aliasing processor, latencies, texture compression, and basically everything else needed to identify the strengths and weaknesses of their chips along with some idea of how AMD goes about implementing all of the major features in those chips. Even though the specifications to their chips won't be anywhere near enough to duplicate the chips, it is a start for anyone that needed some "inspiration." The GPU development cycle is still short enough that it's plausible that someone could steal AMD's technology and implement it before it is outdated; where someone doesn't have to be only NVIDIA.

In other words, AMD is taking an unprecedented risk for a graphics company by doing this; the only groups doing anything similar are either doing it for underpowered/insignificant GPUs (Intel, S3, Matrox) or release a 2D-only driver (NVIDIA).

With that said there are a couple of issues we're wondering how far they're really willing to go, and if they can find the kinds of programmers they need to complete the driver, who don't already work for AMD. It's not a big secret that GPUs are pretty worthless without a driver, as a decent amount of the work that needs to occur to render something is actually done at the driver level. Consequently AMD has invested a lot of money over the years in to researching technologies such as anti-aliasing filters and just-in-time compiling for shader programs, none of which it appears they'll be able to contribute to their open source driver. We're generally concerned that even among the brilliant minds in the open source community, there may not be the knowledge and experience to replicate these driver features, or replicate them to the extent where they can perform as well as AMD's own drivers, defeating some of the usefulness of these open source drivers. As the development of these drivers will take years, it's going to be equally long until we know whether these concerns are valid or not.

On a lighter note, we're curious to see what if any errata documentation AMD will release. Design errors are to be expected in something as complex as a GPU, and on the CPU side both Intel and AMD make their processor errata public knowledge so that it can be worked around by software. At the same time processor errata is extremely minor since it is caught and corrected before mass production, with the last major flaw escaping in to production was the Pentium FDIV bug over a decade ago. AMD and NVIDIA do not adhere to that same strict level of quality control with their GPUs however, and in the past few years we have seen things such as broken video processors and anti-aliasing units make it in to the final silicon. To that extent AMD needs to release information on some errata so that the drivers can work at all, but will they release it all? We admit that we'd like to see just what is broken in their GPUs given the secretive nature of such defects.

Closing Thoughts

With the negatives of AMD's open source efforts out of the way, let's talk about the positives.

First and foremost, once these drivers are in a usable state, this will be a massive boon to most if not all of the Linux distributions. Virtually all of the major distributions do not include binary drivers in to their distributions due to legal and philosophical reasons. With an open source driver available for ATI's video cards these distributions will be able to include this driver out of the box, making Linux installations easier for users who previously would have needed to go about more convoluted methods of installing the binary drivers. Make no mistake, binary drivers while workable are not easy to use under Linux, and having a major open source driver like this will further the goal of many Linux distributions of making themselves easier to install and maintain.

Simultaneously, an open source driver alleviates the problems posed by the unstable driver API. Currently any changes to the driver API that break the binary drivers supplied by AMD and NVIDIA require that those drivers be fixed by the appropriate party and only the appropriate party, which can take more time than some people want to wait or may never come if it's for depreciated hardware. With an open source driver, the open source community (the same one that made the API changes that broke the driver in the first place) can quickly make the changes in the driver to work with the new API. Admittedly, the Linux driver API does not change so frequently that this is a major issue, but never the less it does occur enough that it's a nuisance.

There are also some lesser benefits in terms of security and stability. One particular set of concerns within the open source community in dealing with binary drivers is that the operating system is giving the black box full access to the system, hoping and praying that it's doing what it's supposed to do and nothing else. Bad drivers causing system crashes have long been a gripe among the Windows community, and the open source community likes it even less when an open source driver would allow them to fix the offending bug. This further extends to security concerns, as drivers can introduce weaknesses that can be exploited, something that has happened with NVIDIA's Linux drivers in 2006, and ATI's Windows Vista drivers in 2007. Open source drivers may or may not be inherently more secure depending on whose rhetoric you believe, but open source drivers can be patched a great deal sooner, reducing the risk earlier.

Finally, there is the feedback effect that this could have on hardware manufacturers. We of course are hinting towards NVIDIA, whom has faced very little of a threat from ATI due to their superior drivers. If the open source AMD video driver does end up evolving in to a driver capable of delivering Windows-like performance, AMD will have little trouble sweeping the Linux graphics market with the combination of powerful hardware and drivers that are both technically and philosophically superior. This of course would be bad for NVIDIA, who would need to consider their own full feature open source driver to keep the balance of power with AMD on Linux. This would bring all of the previously mentioned benefits to Linux users with NVIDIA cards.

With that said however, it's important not to lose sight of the present. What AMD has begun is a remarkable plan to bring in to the world open source drivers for their entire range of video cards, but it's something that we believe is a significant risk for them. We are not convinced that this is something AMD completely wants to do as a result, and remain skeptical about how far this will go. We hope that our skepticism is misplaced, but it's too soon to tell.

The only immediate unfortunate result of AMD's open source efforts here are that they will not be directly contributing code from their current drivers for the open source drivers. We understand the reasons for this, but it also means that the open source driver is starting from scratch and has a lot of ground to cover. A good video card driver will take years to develop and while we're talking about what can be, by the time this driver is finished and we can test our predictions and its effects the R600 won't even be AMD's leading GPU series.

This is the start of a long process, not the end of it, but never the less we can't wait to see how things turn out.