Radeon

radeon is Article description::a family of open source graphics drivers for older AMD/ATI Radeon graphics cards. For cards based on Graphics Core Next (GCN) 1.1 and higher, read the AMDGPU article instead. Neither this nor the AMDGPU article cover installation and configuration of the closed source drivers (see the next paragraph).

Be aware AMD has dropped the support for closed source fglrx drivers (called Catalyst on Windows). The fglrx drivers only work with certain versions of the X server. This is contrary to the open source drivers, which are now compiled against the system's currently installed kernel and X server.

Those interested in the new closed source AMDGPU-PRO drivers (called Crimson on Windows) should head over to the AMDGPU-PRO article.

Hardware detection
To choose the right driver, first detect the graphics card. Use lspci for this task:

Feature support

 * 1) Needs testing packages: =mesa-9999 =llvm-9999
 * 2) Needs: >=mesa-11.0.0 >=llvm-3.7

If the card is not available in the above list the X.org wiki is a good place to look for the latest hardware.

Kernel
Depending on the card or the features desired, set the following kernel options.

AMD "Zen" CPUs
If you have a recent AMD CPU with Secure Memory Encryption (SME), it should not be activated by default (Linux 4.14+). This feature is indicated by  in flags of.

AGP
For cards that sit in an AGP slot, enable the AGP driver:

Audio
Some cards have the ability to output audio over the HDMI or DisplayPort connection. Set the following options for audio support:

The options from the Sound card support menu need only to be set if the card supports HDMI or DisplayPort audio and you want to use it. Other options there might be needed as well, e.g. don't set the number of soundcards too low, because even with one Radeon card alsa may detect more than one HDA ATI HDMI device, e.g.

Firmware
Microcode (firmware) is required for R600 and newer GPUs. Install (which also contains other firmware).

USE flags
With packages like these, which introduce a number of non-free binary blobs into the system, if you are security aware, it pays to use the savedconfig use flag, and do some removing of the unnecessary lines, or better yet uncommenting them, from the respective savedconfig file. See "How to install the linux-firmware package in Gentoo" in External resources at bottom of this article.

However, savedconfig editing is entirely optional, those in a hurry may not want to take this route. The system will work the same, with or without the savedconfig editing.

Built-in kernel
When radeon has been compiled directly into the kernel (instead of as a module), make sure the firmware for the model (check available ones in ) is built-in to the kernel as well:

For kernels before 4.18:

For kernels beginning with 4.18:

Below is a list of the firmware files needed for each family/chipset of cards:

Emerge
Portage uses the VIDEO_CARDS variable for enabling support for various graphics cards. Setting the VIDEO_CARDS variable to  (see the feature matrix above) then asking Portage to rebuild the @world set will pull in the correct driver for older radeon cards:

After the values have been ask Portage to rebuild the changed USE flags in the @world set so the change takes effect:

xorg.conf
The X server is designed to work out-of-the-box, with no need to manually edit X.Org's configuration files. It should detect and configure devices such as displays, keyboards, and mice.

However, the main configuration file of the X server is.

The X server can be forced to use desired driver with:

Power management
Power management can be set in the sysfs filesystem as follows:


 * Check the current power method:




 * Change the power method:


 * The "dynpm" method dynamically changes the clocks based on demand. (not effective as of June 27, 2012)
 * The "profile" method lets you set a profile on how the card should behave.
 * The "profile" method lets you set a profile on how the card should behave.


 * Check the current profile:




 * Change the profile:
 * Options for profile:
 * "default" no change of clock speeds
 * "auto" switches between "mid" and "high" power states based on the whether the system is on battery power or not. The "low" power state are selected when the monitors are in the dpms off state.
 * "low" forces the GPU to be in the low power state all the time. Note that "low" can cause display problems on some laptops; this is why auto does not use "low" when displays are active.
 * "mid" forces the GPU to be in the "mid" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.
 * "high" forces the GPU to be in the "high" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.


 * Check the current GPU, Memory clocks and voltage (needs to have kernel debugfs enabled):



Power Management with Linux Kernel 3.11, 3.12
Linux Kernel 3.11 introduces improved power management for some radeon cards, to activate it pass the parameter  to the kernel.


 * Check the dynamic power management state


 * Change the dynamic power management state

Other valid options include "battery" and "balanced"

In order to verify that the new dynamic power management code is active check radeon_pm_info (see above), it should say something like
 * uvd   vclk: 0 dclk: 0
 * power level 0   sclk: 25000 mclk: 15000 vddc: 900 vddci: 950

Power Management with Linux Kernel >= 3.13
Linux Kernel 3.13 enabled dynamic power managment by default for a lot of video cards.


 * Check the current GPU, Memory clocks and voltage (needs to have kernel debugfs enabled):

Power consumption when using multi-head / multi-monitor
When using more than one monitor at once, the power consumption of the graphics card increases up to additional 150% relative to its idle power consumption, because the memory clock switches to full speed (see above). This behavior causes a system using a Radeon HD6870 card to consume around 30 W of additional power when running in multi-monitor mode than in single-monitor mode. This behavior can be avoided by using power method "profile" instead of "dpm" and by forcing "profile" to "low".

Using power method "dpm" and setting a low power profile (i.e. "balanced") is sure possible but useless in this case. The "dpm" method does not allow to forcibly remain on a certain power preset, because it uses the internal GPU hardware to dynamically change the clocks and voltages depending on the current GPU load. As a result, the power consumption increases as soon as you activate a second monitor (because the GPU hardware wants it so).


 * Deactivate dpm first (Kernel >= 3.13) with an appropriate kernel commandline via GRUB at boottime:


 * After rebooting the system to desktop, force the power profile to "low". (This can also be automated by creating a script):

Limitation: For my KDE/Plasma desktop environment this procedure will only work when the power profile level is assigned after KDE/Plasma has started. An automated command in /etc/local.d/*.start is not sufficient. The memory clock rises and remains high (like normal behavior).

Solution: Let KDE/Plasma do the job with its autostart feature.


 * Allow the user to change the power profile by giving him the appropriate privilege when booting. Create a file like the following:


 * Add a startscript to KDE5/Plasma autostart:


 * Do not forget to make it executable:

You can check the result via kernel debugfs (see above) and it should be similar:

Benefit: After these changes, you may use as many monitors as possible without an increased power consumption of your system. Despite the fact that the GPU memory clock is constantly reduced there are still enough graphic resources left to render desktop effects, to play HD movies (also with ) and to do all the regular stuff to get your work done.

I recommend using two entries in GRUB (with and without DPM) and creating a startscript based on the value of /sys/module/radeon/parameters/dpm (0 = DPM off, 1 = DPM on), in order to automatically adjust the power management, based on the decision at boottime (single-head with DPM vs. multi-head without DPM).

Tuning
I couldn't find a summary of all options available so feel free to add to this.

Tuning with mesa from git
Mesa from git (=mesa-9999) offers a different way to tune the 3D driver. Use the environment variable R600_DEBUG with the following options

See mesa commit for more information.


 * Kernel parameters can be just added to the kernel commandline in or.
 * Environment variables could be put into a file like to have them initialized during boot.
 * parameter are usual in the Device section for the card.
 * A full list of kernel parameters can be found here: X.Org Wiki - RadeonFeature
 * S3TC compression needed for some applications like most 3D games:


 * 1) supported by Linux kernel 3.11

Monitoring
lm sensors can be used to monitor the cards temperature. It uses the I2C interface, which needs to be enabled in the kernel:

Audio over HDMI
Audio through the HDMI port is available for some cards. Check the X.Org Wiki - Radeon Feature Matrix for the model family. A recent 3.x kernel may be needed.

If you are using a kernel older than 3.13, HDMI audio must be explicitly enabled using the kernel commandline paramater radeon.audio=1. In addition, ALSA typically does not use HDMI as the default audio, so one way to force this as the default is to add a config file:

which may be moved to to make HDMI audio the system-wide default.

Another solution is to enable the  USE flag, update the system and use  to set the HDMI port as fallback (or use  to change manually which application uses which audio port).

Multichannel LPCM
If you want to enjoy full 5.1 HDMI sound on your Gentoo rig try out anssi's HDMI audio patch as mentioned in the phoronix forums.

Check the bootloader config to use the correct kernel and reboot.

Glamor does not load
If you see errors like "glamor detected, failed to initialize EGL.", then try enabling USE="gbm egl gles2 llvm" in the mesa builds.

If you see errors like "Failed to link: error: fragment shader lacks `main'", then make sure the glamor package has been built with USE="-gles".

On cards that are supported by radeonsi (starting at Southern Island, see the feature matrix) make sure to not only specify "radeon" but also "radeonsi" as the driver.

Poor X server performance
If graphic performance (such as playing videos) is terrible, then make sure KMS Color Tiling is enabled. You can see this in your Xorg log:

[ 3407.235] (II) RADEON(0): KMS Color Tiling: enabled [ 3407.235] (II) RADEON(0): KMS Color Tiling 2D: enabled [ 3407.235] (II) RADEON(0): KMS Pageflipping: enabled

If you see "no" instead of "enabled", then you'll have to look earlier in the log to see why it's been disabled. If glamor failed to load, see the previous troubleshooting item.

Trouble with integrated graphics (A8 or similar)
When having trouble getting an on chip integrated graphic core to work (strange visuals/black screen) the solution may be found in the motherboard's BIOS settings.

In some cases it appears the 'auto' settings don't work correctly, so make sure to explicitly enable the integrated graphics. In my case (MSI A88XM-E45 motherboard):

- I changed this from 'auto' to 'Dual graphics'

- This then appeared which I gave a setting

After this all problems cleared up.

External resources

 * X.Org Wiki
 * X.Org radeon feature matrix
 * Status of OpenGL features in Mesa
 * Phoronix Forums multichannel for radeon
 * hdmi multichannel patch
 * How to install the linux-firmware package in Gentoo