Proprietary Driver

When Catalyst 7.1 was announced, AMD told us that the Linux and Windows Catalyst drivers would reach feature parity by year's end. How is the progress on that front?

Our Catalyst Linux driver has already improved in a very considerable way in terms of both features / performance and stability / compatibility. We expect this trend to continue. However, due to the fundamental differences between the Windows and Linux environments, we don’t expect a 100% feature parity to be reached. There will always be some differences between the functionality of these two versions of our drivers.

Will Linux Catalysts get UVD support? If so, how will that be exposed to developers?

We are currently unable to comment on our future product plans.

This past month, you also released a significant improvement to the Catalyst Linux package by incorporating the Orca OpenGL driver for the first time. What further improvements can we expect to see on that front?

We are currently unable to comment on our future product plans.

Since the Windows and Linux Catalysts are now using the same OpenGL driver, will you be able to share code and accelerate progress?

Yes. The Windows and Linux drivers have always shared some GL code, but the new code base was designed from the start to provide good Linux support.

When can we expect AMD to commit to making initial new generation product drivers (R300, R420, R520, R600) available in Linux at the same time as the initial Windows drivers become available, rather than having a several month difference?

Going forward, we expect that the delay between Linux and Windows support will be significantly smaller than in the past.

Some flavors of Linux are a little bit different than others. Can you talk about what kind of challenges that presents you as a developer in initial development and ongoing maintenance?

Each distribution's kernel and X versions are subtly different with different patch sets, build options and different component versions.

From a development standpoint, this means that we need to have code paths for a wider range of environments (ie: Xorg 1.4 is actually a base that varies from distribution to distribution), and from a maintenance standpoint it means that our test resources need to be split across a number of distributions. The visible effect of this is where a distribution has a unique problem due to upstream changes being integrated early. This happens with kernels quite a bit and X servers close to release time.

With a monthly release cycle we try to close this gap within a release or two.