Building new version from git

It is possible to compile either stable or development version of radeon from git.

Changes to stable branch should be upgraded by distribution packages but in practice distributions don't follow the stable branch for released versions. If your distribution has failed to upgrade to the latest stable version you might get better stability by compiling new version from branch that matches your distribution version.

Development branch (master) is for bleeding edge development where you might get regression but also better performance and features. But if you decide that new features are worth the possible regression and bugs that happen in development you are more than welcome to upgrade to the latest code base. It is good idea to join our irc channel #radeon@freenode to get help for possible problems in bleeding edge code.

Stable branch

xf86-video-ati (ddx)

Upgrading to the latest bug fix code is simple because you don't have to upgrade only driver packages. First it is good idea to upgrade xf86-video-ati that provide 2D and mode setting code for xserver. You will need to clone the git repository from anongit.freedesktop.org.

git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati

Now you have cloned the git repository but code that was checked out is master branch which includes the bleeding edge code changes. Sometimes development is done in another specific GIT branch, you can check remote branches via:

git branch -r

You can easily switch to other branches (here: cayman_accel) or back to the master branch:

git checkout -b cayman_accel origin/cayman_accel
git checkout master

Now you have to solve build dependencies for the driver. Your package manager should have easy functionality for installing all the necessary packages. But for example there is:

Now you have to configure and build the code like any other program. It is good practice to install driver without overwriting files installed by package manager. This can be done using few configuration option. We want to install driver to a clean place where it is easy to remove in case you want to get rid of it.

./autogen.sh --prefix=/opt/xorg
make
sudo make install

Then you need to add configuration instruct xserver to load your self compiled driver. Adding following lines to xorg.conf will do the trick.

Mesa3D

The Mesa3D library provides OpenGL with software and hardware rendering. There are also more libraries related to hardware accelerated graphics. Installing mesa to a location outside /usr is a bit more tricky. Problem here is that it is hard to make AIGLX load the dri driver from a non-system location.

There are multiple stable threads depending on your distribution so you should check your mesa version and renderer with glxinfo command.

Branches were named mesa_X_Y_branch where X is major and Y minor number (nomenclature changed with creation of 7.8 GIT branch). Switch to a specific GIT branch (here: 7.11):

git checkout -b 7.11 origin/7.11

To see all GIT branches available, run 'git branch -r' within local GIT repository/branch.

Now you need again build dependencies which you should install for package libgl1-mesa-dri (See the example above). After you have installed all build dependencies we have to configure, build and install mesa. Prefix is again /opt/xorg for easy clean up if something goes wrong. You can of course use what ever you prefer. Example case enables all ATI drivers, but you would only need radeon, one of the specific drivers for your own card (r200, r300 or r600) and swrast for software fall back in case of problems with DRI or Gallium driver.

Remember to read the instruction how to configure loading of new driver

Configuring system to load mesa and libdrm from /opt/xorg

Now comes the tricky part because you have to configure your system to load correct libraries when any application tries to load them. You have to configure ld to load first from /opt/xorg/lib so custom mesa libraries are loaded. Another tricky part is to load dri driver which requires environment variable set to point to /opt/xorg/lib/dri.

/etc/ld.so.conf.d/a-local-xorg.conf (new file) or add to begin of /etc/ld.so.conf if directory doesn't exists.

/opt/xorg/lib

and to /etc/environment you need to add new environment variable that tells libgl where to look for dri drivers (example r300_dri.so)

LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/

After changes to the files you have to run ldconfig as root to update the linker cache.

You can now test new dri driver in a terminal if you export LIBGL_DRIVERS_PATH. If everything works you can now restart to load new settings for all applications.

Problem with this configuration is that AIGLX doesn't respect it. This means that compiz doesn't get advantage of new driver.

It is possible to get the new libGL and dri drivers used without setting LIBGL_DRIVERS_PATH:

you need to build mesa with --with-dri-driverdir=/opt/xorg/lib/dri/ (or --with-dri-driverdir=/opt/xorg/lib/dri/ for 32-bit)

Updating git tree

Updating git repository has two phases. First part is downloading changes and updating the history data for git. Second part is updating your local branch to match remote changes.

git fetch && git rebase origin

If you have any build problems after updating your source code run make clean and autogen.sh.

Removing self compiled driver

If you at any reason want to get rid of your self compiled driver it is simple as removing the configuration option from xorg.conf, /etc/ld.so.conf.d/ and environment. Then you can just restart computer and you are back at using the driver from package manager.

Removing the extra libraries is also easy with rm -r /opt/xorg.

Bleeding edge code from development branch

You will most likely have to upgrade a lot of stuff depending on how fresh your distro is. But minimum requirement is to have the latest xserver from the latest stable branch, latest stable kernel (some features might be only in rc kernels), libdrm master, mesa master and xf86-video-ati master.

Compiling and configuration is similar to stable branch with few exceptions.

You may have to configure libdrm with --enable-radeon-experimental-api (If your distribution enables it or you want to use KMS)

Distro-specific development packages

Some distributions provide easy way to install development version of all required packages from single source. This makes beta testing a lot easier when you can get fresh packages without recompiling everything.

Kernel-based ModeSetting

Kernel-based ModeSetting (short: KMS) moves a lot of graphics card control logic to kernel which makes it possible to write more advanced 3D and 2D drivers. Kernel side mode setting improves VT switching and provides full resolution console.

KMS also moves DRI infrastructure to version 2 which will provide better performance for 3D drivers in future. But as always is case in large rewrite of basic infrastructure performance will go down at first because of missing features and not optimized code.

Current features in kernel side are

Mode setting

Memory management

Scheduling access to graphics card

After mode setting and memory management part has been finished there will be work to make dynamic power management work.

Anyway, this might work or not. If the packages in the distribution's repository are too old, consult first your distro's support for help.

Other solutions that might help: For example in Debian there exists also an experimental distribution repository with latest software. In the worst case... There could be new stuff in the distro's own SCM (GIT or SVN) repositories, where you have to checkout and build by yourself.

Solve build-deps manually

That is really hard to say... It mostly depends on the freshness of your distribution and its included packages.

Here, the strategy would be to look into the configure* and Makefile* scripts and/or to start compiling each package and check for error-messages. This is no fun.

To make it a bit easier, we have a look into the build-order and into the build.sh script from xorg-devel (see [1]):

macros

protos

libdrm (before ddx and mesa)

ddx (aka xf86-video-ati)

(mesa) <--- Optional, only if you want 3D-acceleration

xserver

Again, within the diverse GIT repos there are explicitly depends on other development packages and/or libraries. You have to solve them first! Easiest way would be to check out and build via the recommended script from [1]. As GIT software is mostly Work-In-Progress, you might ran into other problems. A good orientation if the diverse components do build from GIT together is to look at the so-called "tinderbox" [2] (build failures are listed).

Another rough way is to check out from GIT and create missing packages in the distro's format (deb, rpm or whatever).

Troubleshooting

radeon-KMS issues

Module for frame buffer console

First of all check that you don't load radeonfb, uvesafb or vesafb module. This includes no vga parameters for kernel when using KMS. Console is provided by fbcon and radeondrmfb frame buffer console. So it is best to make sure that fbcon module is loaded.

Hints to dig deeper into radeon-KMS problems on startup

If you can't boot with KMS enabled the easiest way to debug problems is to boot into runlevel-3 (text console, VT) with KMS disabled or blacklist the radeon kernel-module. Then try to unload/load drm and radeon kernel-modules via modprobe commands (preferable over ssh and from a second machine).

Activate via radeon.conf in /etc/modprobe.d directory

A good place to put persistent parameters for kernel-modules in general is /etc/modprobe.d directory, for radeon kernel-module use /etc/modprobe.d/radeon.conf.

cat /etc/modprobe.d/radeon-kms.conf
options radeon modeset=1

When KMS is not enabled before X is started, you might see the following error in your Xorg.log file (thanks TMM for providing a paste on IRC):

(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[dri] This chipset requires a kernel module version of 1.17.0,
[dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel.
[dri] If using kernel modesetting, make sure your module is
[dri] loaded prior to starting X, and that this driver was built
[dri] with support for KMS.
[dri] Disabling DRI

radeon-KMS with AGP gfxcards

AGP gfxcards have a lot of problems so if you have one it is good idea to test PCI/PCIE mode using radeon.agpmode=-1. Another common solution to agp problems is disabling accelerated download from screen. You can see details with man exa how to do this.

Missing firmware

This is not a KMS problem, but people often report X does not start (thus it's included in the troubleshooting list). The real cause for this is the drm cannot find a missing radeon firmware (or microcode). This depends on the Linux-kernel version you use. To fix this issue simply install the package containing the radeon firmware files or consult your distribution's support.

dmesg | egrep -i 'firmware|microcode'

Check if your ddx and mesa-dri driver have KMS support

Your xf86-video-ati video-driver for X (the "DDX", 2D) doesn't have support for KMS? NO, then you have to rebuild it against libdrm_radeon library.

As a consequence this also means that you have to rebuild mesa against same new libdrm. Mesa-dri drivers (3D, accelerated) don't have KMS support without built against libdrm_radeon either.

Furthermore, check if you have fitting components of the Linux graphics driver stack.

The output of ldd commands should clearly indicate a link to libdrm_radeon.

Missing Extra Firmware

All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files [1] to work properly with acceleration (Thanks agd5f for clarification on IRC). According to license issues [2] and the fact that no new firmware files will be shipped in upstream kernels, you need to activate the following kernel-config parameters:

Use 32-bit GL applications on 64-bit systems

32-bit applications (such as wine) will need a 32-bit libGL and mesa dri drivers. If you've only built the 64-bit libraries, your 32-bit apps may still be using the distro provided 32-bit libGL and dri (if you have already installed them), which will probably just result in slowness and wrong image being displayed.

To make 32-bit apps use the new driver (the examples below show 64-bit libs installed in /lib (Debian), your distro may install to /lib64 instead (Fedora and others):

build libdrm from git (here for Debian 64-bit, Info: The original libdrm libs from ia32-libs package will be replaced):

You should include xorg.log and dmesg at minimum. Also exact steps to reproduce the problem will help a lot in solving the problem. Any extra debugging info you have gathered is welcome too. Please select text/plain mime type for any text attachments so they are easier to read.

Debug symbols are important when submitting backtraces so you should take little bit time to install them. There is usually easy way to install them from distribution provided packages. Minimum for debug symbols is mesa, ddx and xorg core to give easily readable backtraces.