Open Source Drivers

AMD has made waves in recent weeks by releasing detailed specifications for its latest cards for the sake of an open-source Linux driver. What prompted this sudden change in policy?

Our customers are increasingly using Linux in areas other than the traditional server and workstation markets, and it became clear that some of those customers would be better served with an open source driver than a proprietary solution. We also discovered that the larger CPU customers tended to have a stronger interest in open source solutions than we had seen from our major GPU customers.

Why did AMD choose to create an entirely new open source driver instead of releasing its Catalyst Linux driver as open source?

One of the big advantages of an open source driver is that it can be easily maintained and kept compatible with advances in the OS kernel and graphics framework. Our proprietary driver is focused on providing a very feature rich, high performance solution but the downside is that the code becomes larger and more difficult to maintain.

After working with developers and users in the open source community it became clear that starting with a new and simple code base would be more useful than cutting down from a fully featured but complex driver. We are hoping that the open source driver settles around the "80% of the value with 10% of the code" sweet spot.

Will AMD developers be contributing to the open source driver?

Yes, although our primary effort will still be to empower and support the development community. We are trying to be part of the open source development community, not a replacement.

Obviously making the driver more open to outside development will mean AMD will have to manage that development. What's in place to make that as productive as possible, or are x.org handling most of the interaction issues from external developers?

I don't think any of us expect to be able to manage or control the development community. We are concentrating on supplying information, answering questions, and providing sample code as a way of saying "we think this is a good approach".

We are building a small but experienced team who will act as the primary contact point for developers, both through direct email and by participating in existing mailing lists and IRC discussions. Alex Deucher, maintainer of the "radeon" open source driver, will be starting at AMD as a key part of that team.

We presume that part of the reason you can't make the current driver open is that portions of it aren't AMD's work, and you have to respect any license or copyright there. Are you confident that those portions aren't crucial enough to performance or other core driver functions that a complete open driver can engineer good replacements?

Yes, we do have third party IP in our drivers. However, we believe that the open source community will be able to develop open source solutions to satisfy the majority of user's needs.

Will AMD contribute an open source shader compiler/assembler to the driver?

We originally felt that we would need to provide an open source assembler (or at least provide a lot of support while one is being written) but it is possible that the Tungsten Graphics enhancements to Mesa will fill the need using LLVM.

How will the existence of a full-featured open source driver affect the goals of the Catalyst Linux package? Will it continue to be a comprehensive driver package, or will it become more focused on workstation applications?

Combined with next question. See below.

Will the new open source driver ever completely replace Catalyst on Linux? How will the two cooperate, and will AMD do anything to inform customers of the choice?

I see the two drivers complementing each other. Having an open source driver makes it possible for distributions to keep the graphics driver in sync with their own development efforts, provide a great "out of box" experience, and to fully support their corporate customers.

The Catalyst Linux driver (fglrx) will focus on released and stable OS distributions, offering ISV-certified support for workstation users and providing a feature and performance upgrade for consumer users. OEMs who pre-load Linux on their products will use fglrx

In general, consumers will have access to both of these drivers and will be able to choose the one which best meets their needs.

 Will you release public information on the UVD registers?

We do not have a plan to release UVD programming information.

With regards to future products, how close to the launch of a new product will you release the information necessary to creating an open source driver for that product?

In general, we will try to release driver programming information shortly after the product is announced. If the changes are simple we will try to have the information available at the same time as the product, but if the documentation changes are more complex there may be an additional delay.

There may be cases where we decide to perform some of the development work before product launch in an offline depot (either in-house or using embargo NDAs for outside developers) so that we can make open source support available sooner.

What's the timeline for making shader core information available to the open source community?

We expect to start providing information in the first quarter of 2008.