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.
Contents
How well does it work?
As of October 2009, all Radeon cards are well supported in 2D using the Radeon DDX 6.12.4. Using Mesa 7.6, the 3D support is as follows:
Radeon 7000 - X1950: Well supported by the free drivers radeon, r200 and r300. Experimental work on a Gallium3D driver for Radeon 9500 - X1950 is in progress under the codename r300g.
Radeon X2000 - X4870: Initial experimental 3D support is available by the free driver r600, and is rapidly improving in the Mesa master branch.
For more detail, see a list of supported features and the program and games test matrix.
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:
Ubuntu has an xorg-edgers team and PPA
- Rawhide tends to provide a very recent and up-to-day graphics environment
TODO: Add information for other distributions
If you want to go to the source, you should follow the instructions on the Building site.
Where can I get help?
If you have a concrete problem for which you need help, perhaps the problem is already known. Check out the RadeonTroubleshooting page.
Your distribution may have documentation and/or an active community that is willing to help you out:
Ubuntu has a How to get help
TODO: Add information for other distributions
You can also visit the forums at Phoronix or the IRC channel #radeon on irc.freenode.net.
How to report bugs
First of all, make sure your problem isn't already known, by perusing the "Where can I get help?" section.
We use the FreeDesktop Bugzilla for bug tracking, and this should be your first stop to check for already existing bugs. There are separate components for the different 3D drivers:
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
- the version of the program that is affected by the bug
whether you are using Kernel Mode Setting (KMS) or not
information about your hardware: state the model of your graphics card, whether it's AGP or PCIE; output of lspci can't hurt either
output of dmesg, and your Xorg.0.log
- output of the affected program, if any
Do not paste log files and the like into bug comments. Instead, add those files as attachments to the bug report.
- Be responsive if a developer asks for more information or asks you to test some workaround or patch.
If at all possible, use git bisect to pin-point the cause of the bug if it is a regression.
How can I help?
There are many ways you can help, whether you are a programmer or not. Here are some suggestions for non-programmers:
Help us keep the program support matrix up to date.
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:
Build Mesa and related packages from source.
- 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.
There are also several developers' blogs which are aggregated on Planet Freedesktop, and an (also aggregated) extremely irregular blog specifically about Radeon development.
Development Resources
R300Compiler provides some information about the shader compiler for R300-R500
- Hardware Information
ATIRadeon: Chipset naming, and various information that maybe should be integrated in a nicer way
Radeon Architecture - mostly superseded by the documentation from AMD
- R300-R500
- R000-R700
- Various collected links (may benefit from updating):
MesaDriver: How to write a Mesa driver (only applies to classic drivers and the Mesa state tracker, but not to Gallium3D drivers)
A locking mechanism for the DRI (no longer applies to DRI2)
ReverseEngineering: Reverse engineering tools
Old TiRDCs: Radeon%Companion%1, Radeon_Companion_2, Radeon_Companion_3, Radeon_Companion_4