Radeon 3D acceleration Portal

This page is the entry portal for everything related to open source 3D hardware acceleration support on AMD (formerly ATI) Radeon cards, from the old Radeon 7000 up to the latest Radeon HD cards. More information about general Radeon issues (2D acceleration etc.) can be found over at the X.org Wiki.

How to get bleeding-edge 3D drivers?

Your distribution should install a nice choice of default drivers. This section applies only if you want to experience the bleeding edge, if a developer has suggested that you try some patch, or if you want to become a developer yourself.

Be careful, for this section may lead you into a world of pain and crashes.

As a first step, maybe your distribution offers more bleeding edge packages already:

r600: all Radeon HD cards
There is currently no bug tracker for the experimental r300g driver. We'll create one as soon as we are interested in receiving bug reports for that driver.

Make sure you use good bug hygiene:

Check whether the bug has already been reported.

Provide steps to reproduce the bug.

If the bug affects uncommon programs (in particular, if it affects games), provide a link where developers can obtain the program.

State clearly what is going wrong, i.e. what do you expect to happen, and where do things fail. In the case of incorrect rendering (i.e. graphics artefacts), it is most useful if you can provide screenshots of both incorrect and correct rendering.

Provide full information about your system. Many distributions have tools to help with that. In particular, you should provide:

the version of all involved software, in particular the kernel, the DDX, ?libdrm, Mesa

How can I help?

Contribute to this documentation (for example, you may come across troubleshooting advice from developers that they haven't been able to add; don't hesitate to add it yourself!); be helpful to people who are running into issues in the various Linux and FreeBSD communities.

Run bleeding-edge drivers on your own system, and report any regressions you run into. We try to keep Mesa master as stable as possible, but regressions do creep in occasionally, and the sooner we know about them, the better.
If you want to get your hands dirty with the code itself, welcome! Here are some of things that should help you to get started:

Get yourself acquainted with the development community places (see section below).

Browse the source code and familiarize yourself with how it works, perhaps via the other development resources.

Learn to program small OpenGL programs and learn to read the OpenGL and extension specifications.
Finally, you should find yourself some small project to work on. This could be:

Fix one of the many open bugs in the bug tracker.

Check out the piglit test suite. There are still failing tests, maybe you can fix one of them.

There may be a bug affecting your favourite 3D game.

Perhaps you want to improve the performance of your favourite 3D game.
There are also semi-up-to-date Todo lists that you may peruse for inspiration:

r300: R300ToDo; note that work on new feature is more appreciated for r300g these days

r600: R600ToDo;
Once you have a working patch (even if the patch merely adds or clarifies some comments in the source code!), you should send your patch to the developers. The most accepted way to do this is to send your patch in an email to the mesa3d-dev (for Mesa patches) or dri-devel (for libdrm or kernel patches) mailing list. The git format-patch command can help you with that. If your patch is small enough and you feel comfortable with IRC, you can also ask for feedback on #radeon, having uploaded your patch to a pastebin site (e.g. here) or to a public Git repository of your own.

Development Community Places

The development centers around the source code, which is available in the Mesa Git repository. Most of the development discussion actually takes place on IRC, in #radeon on irc.freenode.net. Some discussions, particularly about Gallium3D, also take place in the channel #dri-devel. IRC logs of past discussions are available. The second most important place are the relevant mailing lists. Furthermore, many developers visit the Phoronix forums, where they will often provide useful information; however, development discussions usually do not take place there.