radeonhd:DRI

1. How to setup DRI with radeonhd

Enabling DRI with radeonhd is currently still challenging, because the released versions of Mesa and DRM do not have sufficient support for r5xx GPUs. The RS690 is - technically speaking - a r3xx based GPU, but support for it hasn't been added until recently either.

Please also note that there is no DRI support for r6xx based cards yet! RS6xx cards are not r6xx and are supported.

So in order to enable DRI on your r5xx card you need

Contents

  1. How to setup DRI with radeonhd
    1. Known Issues
    2. Building
    3. Configuration
    4. Troubleshooting, Q & A

1.1. Known Issues

1.2. Building

It's a smart idea to pull all this source down into it's own self contained area, in case you need to blow it all away cleanly and redo the git clone, builds, etc. So in this case we'll use /var/tmp/radeonhd-dri as the main area. Don't use /tmp, this is cleared on reboot on some distributions. 

  SRC="/var/tmp/radeonhd-dri"
  mkdir $SRC
  cd $SRC

Please note that the following information is quite Linux-centric at the moment.

1.2.1. Sources

At the moment we're only suggesting git repositories for the main components, because changes in the source repros are moving fast, and there are probably still bugs lurking somewhere. This will change over time. 

  git clone git://anongit.freedesktop.org/git/mesa/drm
  git clone git://anongit.freedesktop.org/git/mesa/mesa
  git clone git://anongit.freedesktop.org/git/xorg/xserver
  git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd

Apparently you need to fetch and build the Xserver only on x86_64 - don't update if not necessary, this is painful!

1.2.2. Preconditions

You will stumble upon some preconditions, the following should help here (using released versions whenever possible). You can unpack the released versions with tar xvfj <file>. If they don't work, try the according git tree, you can find the path to the git repository on the gitweb page.

Mesa needs dri2proto:

When building a newer Xserver you will have to fetch and install a number of newer prototypes and libraries. This includes:

Also, after building the Xserver you have to build and install all input drivers you are using as well. Apparently, you need the very latest bits for them to be compilable, and they have to be compiled against the new ABI of the Xserver. At least this includes:

Also, for the DRM kernel modules you need the kernel sources of your running kernel installed in /usr/src - all major distributions do this correctly nowadays if kernel sources are installed from your distribution.

You may also run into a problem where your libpciaccess it out of date and you need to pull down the latest from git:

and build it with the usual manner. This seems to show up on x86_64 builds when the xf86-video-radeonhd build croaks.

1.2.3. Installation

The drm package contains two subsystems, which have to be built and installed separately at the beginning. There's no reason to actually build all the other vendor drm modules, so we'll just build the one we're interested in. In order to make sure that the correct module is loaded check that extra is part of the search list in /etc/depmod.conf - in Ubuntu this typically isn't. 

  cd $SRC/drm
  ./autogen.sh --prefix=/usr
  make
  make install              (as root)
  cd linux-core
  make DRM_MODULES="radeon"
  make install              (as root)
  depmod -a                 (as root)

After that, all other subsystems have to be built and installed in the same way, in the order mentioned below: 

  cd $SRC/<subsystem>
  ./autogen.sh --prefix=/usr
  make
  make install              (as root)

If using a released package (a .tar.bz2), there is no autogen.sh. In that case (and only in that case) you have to call ./configure with the same arguments.

Depending on your distro, you might want to add --libdir /usr/lib64 to ./autogen.sh. Note: Has anyone tested this on Hardy Heron x86_64 yet? I'm in the process, but not quite there yet.

The subsystems have to be built and installed in the following order:

1.2.4. Notes for Experienced Users

If you have a little experience with building and installing foreign packages, you might want to use a different --prefix in order to not override your installed configuration. In that case you will have to additionally set 

  export ACLOCAL="aclocal -I $PREFIX/share/aclocal"
  export PKG_CONFIG_PATH=$PREFIX/$LIB/pkgconfig"
  export LD_LIBRARY_PATH=$PREFIX/$LIB
  export PATH=$PREFIX/bin:$PATH

with $PREFIX being the directory to be installed to and $LIB being "lib" on i386 and "lib64" on x86_64 (might be distribution dependent).

You can also use build dirs for all subsystems (except for the kernel module and the Mesa subsystem, which uses autoconf, but not automake) by creating a build directory, changing into that directory and calling ../autogen.sh [args]. This has the advantage that the source directory remains untouched. Again, this doesn't work for Mesa and the drm kernel module.

1.3. Configuration

When DRI is active, 2D acceleration is disabled at the moment. Therefore, DRI is inactive by default.

In order to activate DRI, you have to add 

   Option "DRI"

to the driver section of your xorg.conf.

1.4. Troubleshooting, Q & A

1.4.1. Only the first invocation of a OpenGL program works as expected

You're probably running an older Xserver (< 1.4.99.x) on an x86_64 machine. This is known to exhibit this bug.

1.4.2. I only get "Error: coudn't get an RGB, Double-buffered visual."

Same as above. Xserver is too old.