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.
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.
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.
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.
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.
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.
Combined with next question. See below.
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.
We do not have a plan to release UVD programming information.
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.
We expect to start providing information in the first quarter of 2008.