AMD's New Gambit: Open Source Video Drivers
by Ryan Smith on September 25, 2007 12:00 AM EST- Posted in
- GPUs
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.
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