Difference between revisions of "ATI"

From ArchWiki
Jump to: navigation, search
(With KMS enabled: Stock kernel provides the sysfs interface as of 2.6.35. I'vel also made some general syntax corrections etc.)
m (With KMS enabled: typos, grammar etc.)
Line 221: Line 221:
 
=== With KMS enabled ===
 
=== With KMS enabled ===
  
With the radeon driver, powersaving is disabled by default but the stock kernel (2.6.35 as of this writing) provides a sysfs option to enable it.
+
With the radeon driver, power saving is disabled by default but the stock kernel (2.6.35 as of this writing) provides a sysfs option to enable it.
  
 
Power saving through KMS is still a work in progress for the most part. It should work, but some chips do have problems with it. A common issue for all is screen blinking when the kernel switches between power states, and in some configurations it even causes system freezes. But KMS is awesome, so it's your choice. The UMS method is generally more stable, however its power savings might not be as good as those provided by KMS options.
 
Power saving through KMS is still a work in progress for the most part. It should work, but some chips do have problems with it. A common issue for all is screen blinking when the kernel switches between power states, and in some configurations it even causes system freezes. But KMS is awesome, so it's your choice. The UMS method is generally more stable, however its power savings might not be as good as those provided by KMS options.
Line 229: Line 229:
 
1. Try adding radeon.dynpm=1 to the kernel parameters (if using the stock kernel < 2.6.35). If you are using kernel26>=2.6.35 this option is no longer needed and the sysfs interface will be present by default. If this option is passed to a kernel >= 2.6.35, the driver will fail and fall back to software rendering.
 
1. Try adding radeon.dynpm=1 to the kernel parameters (if using the stock kernel < 2.6.35). If you are using kernel26>=2.6.35 this option is no longer needed and the sysfs interface will be present by default. If this option is passed to a kernel >= 2.6.35, the driver will fail and fall back to software rendering.
  
2. Use the (unsupported) [radeon] repo:
+
2. Use the (unsupported) [radeon] repository:
  
 
This repository gives you the git and more up-to-date version of the radeon driver and it's dependencies.
 
This repository gives you the git and more up-to-date version of the radeon driver and it's dependencies.
Line 248: Line 248:
 
</code>
 
</code>
  
The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.
+
The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The re-clocking is attempted during vertical blanking periods, but due to the timing of the re-clocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.
  
  
Line 262: Line 262:
  
 
<code>
 
<code>
   echo low > /sys/class/drm/card-0/device/power_profile  
+
   echo low > /sys/class/drm/card0/device/power_profile  
 
   ## forces GPU to lowest available frequency  
 
   ## forces GPU to lowest available frequency  
 
</code>
 
</code>

Revision as of 15:49, 13 September 2010

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Summary help replacing me
An overview of open source ATI/AMD video card drivers.
Related
ATI Catalyst
Intel
NVIDIA
Xorg

Owners of ATI video cards have a choice between ATI's proprietary driver (Template:Package AUR) and open source alternatives (Template:Package Official or Template:Package Official).

Currently, the performance of the open source drivers are not on par with the proprietary driver in terms of 3D performance and lack certain features, such as reliable TV-out support. They do, however, offer better dual-head support (xf86-video-ati), excellent 2D acceleration, and provide sufficient 3D acceleration for OpenGL-accelerated window managers, such as Compiz or KWin. Currently, the ATI Catalyst package is available in the AUR.

If unsure, try the open source drivers first; they will suit most needs and are generally less problematic and flexible. (See the feature matrix for details.) For an overview of ATI's proprietary "Catalyst" video card driver, see ATI Catalyst; this article covers the open source drivers.

Naming conventions

ATI's Radeon brand follows a naming scheme that relates each product to a market segment. Within this article, readers will see both product names (e.g. HD 4850, X1900) and code or core names (e.g. RV770, R580). Traditionally, a product series will correspond to a core series (e.g. the "X1000" product series includes the X1300, X1600, X1800, and X1900 products which utilize the "R500" core series – including the RV515, RV530, R520, and R580 cores).

For a table of core and product series, see Wikipedia:Comparison of AMD graphics processing units.

Differences between open source drivers

xf86-video-ati (radeon)

  • Works with Radeon chipsets up to HD 4xxx (latest R700 chipsets) as well as HD 5xxx (latest R800 chipsets).
  • Radeons up to the X1xxx series are fully supported, stable, and full 2D and 3D acceleration are provided.
  • Radeons from HD 2xxx to X4xxx have full 2D acceleration and functional 3D acceleration, but are not supported by all the features that the proprietary driver provides (for example, powersaving is still in a testing phase).
  • Supports DRI1, RandR 1.2/1.3, EXA acceleration and kernel mode-setting/DRI2 (with the latest Linux kernel, libdrm and Mesa versions).
  • All cards from HD 5xxx (R800) and newer are supported, but for now, with 2D support only.
  • HDMI support will soon be implemented in xf86-video-ati over AtomBIOS. It is already working for some chipsets (RV620 at least are working fine).

xf86-video-radeonhd (radeonhd)

  • Driver for ATI R500 chipsets (Radeon X1000 series) and newer.
  • Written by Novell with specifications provided to the public by AMD.
  • Supports RandR 1.2 and is under heavy development. It does also support HDMI with sound (if your hardware is so equipped, except RV730 based chip sets).

Generally, xf86-video-ati seems to offer more consistent performance as compared to xf86-video-radeonhd and is more actively developed, so it should be your first choice, no matter which ATI card you own. xf86-video-radeonhd should be used as a "fallback" driver in case you encounter errors with xf86-video-ati and it should not be used as a primary driver - radeonhd's development has been unofficially halted. In case you need to use a driver for newer ATI cards, you should prefer the proprietary catalyst driver.

Note: xf86-video-ati is recognized as "radeon" by Xorg (in xorg.conf) and xf86-video-radeonhd as "radeonhd".

Installation and configuration

Installation

Note: If you have previously installed the proprietary driver, make sure to remove catalyst and reboot.

To install xf86-video-ati :

pacman -S xf86-video-ati

To install xf86-video-radeonhd :

pacman -S xf86-video-radeonhd libgl ati-dri
Note: All cards from HD3xxx (R600) and newer need to install additional firmware files.

To install linux-firmware :

pacman -S linux-firmware 
Note: The GIT versions of these drivers can be found on AUR.

Configuration

You now have the choice between creating an xorg.conf, or attempting to use the recently enabled Xorg autodetection.

Running Xorg without xorg.conf

In most cases, Xorg can autodetect your hardware settings. The Xorg.conf configuration file in /etc/X11 is optional since Xorg-server 1.5.x.

Always make sure you have mesa, the group xorg and the group xorg-input-drivers installed:

 pacman -S xorg-input-drivers mesa xorg
Note: With KMS (Kernel Mode Setting) enabled, xorg.conf may not be needed at all. For more info on Radeon Kernel mode-setting, read #Kernel mode-setting (KMS).

Running Xorg with expanded xorg.conf

Note: /etc/X11/xorg.conf no longer requires sections for all input devices because Udev can configure some/all via hotplugging. (Ensure xorg-input-drivers are installed.)

In case you want manual configuration, edit your xorg.conf, and add or make sure you have the following in their given sections:

Section "Module"
  Load  "glx"
  Load  "dri"
  Load  "drm"
EndSection

Device section for xf86-video-ati :

Section "Device"
 Identifier "name"                     # your alias
 Driver "radeon"
EndSection

Device section for xf86-video-radeonhd :

Section "Device"
 Identifier "name"                     # your alias
 Driver "radeonhd"
 Option "AccelMethod" "exa"            # to enable 2D and Xv acceleration on R6xx/R7xx - default AccelMethod shadowfb
 Option "DRI" "on"                     # to enable 2D and Xv acceleration on R6xx/R7xx - default DRI disabled
EndSection
Note: Try below for smooth performance,over Option "DRI", for RS780M/MN [Radeon HD 3200] using the radeonhd driver(as of 3rd May 2009)

This section (DRI) is not needed (thus deprecated), but use it if you encounter DRI related problems.

Section "DRI"
 Group        "video"
 Mode         0666
EndSection

Adding only the Device Section in the xorg.conf should fit most cases. Using that Section, you can enable features and tweak the driver's performance or behaviour.

When using the opensource drivers, ensure catalyst is not installed -- ati-dri is being used instead. Otherwise, the wrong libGL.so will be installed, which will cause direct rendering to fail.

Kernel mode-setting (KMS)

KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies (such as DRI2) which will help reduce artifacts and increase 3D performance, even kernel space power-saving.

KMS for ATI video cards requires the Xorg free video user space driver Template:Package Official version 6.12.4 or later.

Enabling experimental KMS

Since kernel26 v.2.6.33, KMS is enabled by default for ATI cards.

Early KMS start

This method will start KMS as early as possible in the boot process (when the initramfs is loaded).

  1. Remove all Template:Codeline options from the kernel line in the bootloader configuration file (Template:Filename for GRUB users). Using other framebuffer drivers (such as uvesafb or radeonfb) will conflict with KMS. Remove any framebuffer related modules from Template:Filename. Template:Codeline can now be used in conjunction with KMS.
  2. Add Template:Codeline to MODULES array in Template:Filename. Depending on motherboard chipset, it may be necessary to add Template:Codeline before the Template:Codeline module. Previously, the Template:Codeline module also needed to be listed to be able to switch to the console after X has started, but is now compiled into the default kernel.
    • Following is probably not true since Linux 2.6.33, at least author didn't run into any problems: For newer ATI cards (R6xx and newer) extra microcode is currently needed. Install linux-firmware and grab radeon-initrd from AUR, build and install them and add Template:Codeline to HOOKS array in Template:Filename.
  3. Re-generate your initramfs:
    # mkinitcpio -p kernel26
  4. Add Template:Codeline to the kernel options in the bootloader configuration file to enable KMS.
  5. Reboot the system.

Late start

With this choice, KMS will be enabled when modules are loaded during the boot process.

  1. Remove all Template:Codeline options from the kernel line in the bootloader configuration file (Template:Filename for GRUB users). Using other framebuffer drivers (such as uvesafb or radeonfb) will conflict with KMS. Remove any framebuffer related modules from Template:Filename. Template:Codeline can now be used in conjunction with KMS.
  2. Add Template:Codeline to MODULES array in Template:Filename. Depending on motherboard chipset, it may be necessary to add Template:Codeline before the Template:Codeline module. Previously, the Template:Codeline module also needed to be listed to be able to switch to the console after X has started, but is now compiled into the default kernel.
  3. Reboot the system.
Tip: Some users have reported faster udev module loading by adding Template:Codeline to Template:Filename.

Troubleshooting KMS

Generic problem solution

If your card often crashes when loading the radeon module, starting your login manager, entering desktop or crashes when you start 3D apps like glxgears you can try if the kernel boot option "pci=nomsi" solves your problems. See https://bugzilla.kernel.org/show_bug.cgi?id=15626 for X200m cards.

Disable KMS

Users should consider disabling kernel mode-setting if encountering kernel panics, distorted framebuffer on boot, no GPU signal, Xorg refusing to start, Xorg falling back to Mesa software rasterizer (no 3D acceleration) or 'POWER OFF' problem (kernel 2.6.33-2)at shutdown.

  1. Add Template:Codeline (or Template:Codeline, if this does not work) to the kernel options line in the bootloader configuration file (Template:Filename for GRUB users). That should work. If you want to remove KMS support from the initramfs, follow the next two steps.
  2. If Template:Codeline was added to the MODULES array in Template:Filename to enable early start, remove it.
  3. Rebuild the initramfs with
    # mkinitcpio -p kernel26
Warning: Catalyst users will likely need to blacklist the Template:Codeline module by adding Template:Codeline to the MODULES array in Template:Filename.

Alternatively, module options can be specified in a file within the Template:Filename directory. If using the radeon module (Template:Codeline) disable KMS by creating a file containing the above code:

Template:File

Renaming Template:Filename

Renaming Template:Filename, which may include options that conflict with KMS, will force Xorg to autodetect hardware with sane defaults. After renaming, restart Xorg.

Performance tuning

The following options apply to Section "Device" in /etc/X11/xorg.conf.

Tuning performance with xf86-video-ati

By design, xf86-video-ati runs at AGP 1x speed. It is generally safe to modify this. If you notice hangs, try reducing the value or removing the line entirely (you can use values 1, 2, 4, 8).

       Option "AGPMode" "4"

ColorTiling is completely safe to enable and supposedly is enabled by default. People have noticed a performance increase when enabled via xorg.conf.

       Option "ColorTiling" "on"

Acceleration architecture; this will work only on newer cards. If you enable this and then can't get back into X, remove it.

       Option "AccelMethod" "EXA"

Page Flip is generally safe to enable. This would mostly be used on older cards, as enabling this would disable EXA. With recent drivers can be used together with EXA.

       Option "EnablePageFlip" "on" 

AGPFastWrite will enable fast writes for AGP cards. This one can be problematic, so be prepared to remove it if you can't get into X.

       Option "AGPFastWrite" "yes"

EXAVSync option attempts to avoid tearing by stalling the engine until the display controller has passed the destination region. It reduces tearing at the cost of performance and has been know to cause instability on some chips. Really useful when enabling Xv overlay on videos on a 3D accelerated desktop. It is not necessary when KMS (thus DRI2 acceleration) is enabled.

      Option "EXAVSync" "yes"

See an example Device Section in xorg.conf:

Section "Device"
       Identifier  "My Graphics Card"
       Driver      "radeon"
       Option      "DRI" "on" 
       Option      "DynamicPM" "on"      # Dynamic powersaving.
       Option      "ClockGating" "on"    # Assisting option for powersaving.
       Option      "AccelMethod" "EXA"   # EXA should fit most cases.
       Option      "EXAVSync" "on"       # EXAVSync is explained above.
       Option      "DMAForXv" "on"       # Forced option in order to enable Xv overlay.
       Option      "ScalerWidth" "2048"  # That should fix some very rare bugs.
       Option      "EnablePageFlip" "on" # It will not be enabled on R5xx cards.
       Option      "RenderAccel" "on"    # Optional. It should be enabled by default.
       Option      "AccelDFS" "on"       #Optional. See the man page.
       BusID       "PCI:1:0:0"
EndSection


See the manpage for more configuration options. man radeon

A fine tool to try is driconf. It will allow you to modify several settings, like vsync, anisotropic filtering, texture compression, etc. Using this tool it is also possible to "disable Low Impact fallback" needed by some programs (e.g. Google Earth).

Powersaving

The powersaving part is totally different with and without KMS.

With KMS enabled

With the radeon driver, power saving is disabled by default but the stock kernel (2.6.35 as of this writing) provides a sysfs option to enable it.

Power saving through KMS is still a work in progress for the most part. It should work, but some chips do have problems with it. A common issue for all is screen blinking when the kernel switches between power states, and in some configurations it even causes system freezes. But KMS is awesome, so it's your choice. The UMS method is generally more stable, however its power savings might not be as good as those provided by KMS options.

There are two ways to enable power management:

1. Try adding radeon.dynpm=1 to the kernel parameters (if using the stock kernel < 2.6.35). If you are using kernel26>=2.6.35 this option is no longer needed and the sysfs interface will be present by default. If this option is passed to a kernel >= 2.6.35, the driver will fail and fall back to software rendering.

2. Use the (unsupported) [radeon] repository:

This repository gives you the git and more up-to-date version of the radeon driver and it's dependencies.

[radeon]
Server = http://gtklocker.tiven.org/radeon-repo/$arch/

You can select the methods via sysfs. So, with root access, you have two choices:

 echo dynpm > /sys/class/drm/card0/device/power_method
 ## dynamic clock switching based on GPU load

 echo profile > /sys/class/drm/card0/device/power_method
 ## profile based frequency switching

The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The re-clocking is attempted during vertical blanking periods, but due to the timing of the re-clocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.


The "profile" mode will allow you to select one of the five profiles below:

  • "default" uses the default clocks and does not change the power state. This is the default behavior.
  • "auto" selects 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 only uses "low" when displays are off.
  • "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.

So lets say we want the "low" option...for this, run this command:

 echo low > /sys/class/drm/card0/device/power_profile 
 ## forces GPU to lowest available frequency 

Replace "low" with any of the aforementioned profiles you wish.

Template:Note: These echo settings are not permanent, so when you find something that fits your needs, you will need to add it to /etc/rc.local, so it's executed at system startup.

The "profile" method is not as aggressive as "dynpm," but is currently much more stable and flicker free and works with multiple heads active.

Power management is supported on all asics (r1xx-evergreen) that include the appropriate power state tables in the vbios; not all boards do (especially older desktop cards).

Thermal sensors are implemented via external i2c chips or via the internal thermal sensor (rv6xx-evergreen only). To get the temperature on asics that use i2c chips, you need to load the appropriate hwmon driver for the sensor used on your board (lm63, lm64, etc.). The drm will attempt to load the appropriate hwmon driver. On boards that use the internal thermal sensor, the drm will set up the hwmon interface automatically. When the appropriate driver is loaded, the temperatures can be accessed via lm_sensors tools or via sysfs in /sys/class/hwmon .

To view the voltage that the GPU is running at, perform the following command and you will get something like it's output:

~$ cat /sys/kernel/debug/dri/0/radeon_pm_info

 state: PM_STATE_ENABLED
 default engine clock: 300000 kHz
 current engine clock: 300720 kHz
 default memory clock: 200000 kHz

It depends on which GPU line yours is, however. Along with the radeon driver versions, kernel versions, etc. So it may not have much/any voltage regulation at all.

Without KMS

In your xorg.conf file, add 2 lines to "Device" Section:

       Option      "DynamicPM"          "on"
       Option      "ClockGating"        "on"

If the two options are enabled successfully, you will see following lines in /var/log/Xorg.0.log:

       (**) RADEON(0): Option "ClockGating" "on"
       (**) RADEON(0): Option "DynamicPM" "on"
       Static power management enable success
       (II) RADEON(0): Dynamic Clock Gating Enabled
       (II) RADEON(0): Dynamic Power Management Enabled

If you desire low power cost, you can add an extra line to "Device" Section of xorg.conf:

       Option      "ForceLowPowerMode"   "on"

TV out

Since August 2007, there is TV-out support for all Radeons with integrated TV-out.

It is somewhat limited for now, it doesn't always autodetect the output correctly and only NTSC mode works.

First, check that you have an S-video output: xrandr should give you something like

Screen 0: minimum 320x200, current 1024x768, maximum 1280x1200
...
S-video disconnected (normal left inverted right x axis y axis)

Now we should tell Xorg that it is actually connected (it is, right?)

xrandr --output S-video --set load_detection 1

Setting tv standard to use:

xrandr --output S-video --set tv_standard ntsc

Adding a mode for it (currently it supports only 800x600):

xrandr --addmode S-video 800x600

I'll go for a clone mode:

xrandr --output S-video --same-as VGA-0

So far so good. Now let's try to see what we have:

xrandr --output S-video --mode 800x600

At this point you should see a 800x600 version of your desktop on your TV.

To disable the output, do

xrandr --output S-video --off

Also you may notice that the video is being played on monitor only and not on the TV. Where the Xv overlay is sent is controlled by XV_CRTC attribute.

To send the output to the TV, I do

xvattr -a XV_CRTC -v 1
Note: you need to install xvattr from AUR to execute this command.

To switch back to my monitor, I change this to 0. -1 is used for automatic switching in dualhead setups.

Please see Enabling TV-Out Statically for how to enable TV-out in your xorg config file.

HDMI with sound

Given that your hardware supports it, and you have installed xf86-video-radeonhd (note: The driver xf86-video-ati will soon get HDMI support.) you can insert the following into xorg.conf to enable HDMI with sound:

Section "Device"
  # ...
  Option "Audio" "on"
  Option "HDMI" "all"
EndSection

Restart X when you have done this, try to see if there is sound transmitted to TV via HDMI cable.

  1. Connect your PC to the TV via HDMI cable (duh).
  2. Use xrandr to get picture to the TV. Ex: xrandr --output DVI-D_1 --mode 1280x768 --right-of PANEL. Simply typing xrandr will give you a list of your valid outputs.
  3. Run aplay -l to get the list of your sound devices. Find HDMI and note the card number and corresponding device number. Example of what you want to see: card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI]
  4. Try sending sound to this device: aplay -D plughw:1,3 /usr/share/sounds/alsa/Front_Center.wav. Be sure to change plughw:z,y to match your hardware number found with last command. You should be able to hear the test sound from your TV.

Using xf86-video-ati

xf86-video-ati can enable HDMI output for some chipsets (RV620 for instance, and therefore probably R*600) . Using KMS, add radeon.audio=1 to your kernel line in /boot/grub/menu.lst. Then, use xrandr and aplay to get HDMI output, as explained above.

Note on RV730 and RV710

xf86-video-radeonhd does not support yet audio through HDMI for these chipsets, but work is in progress.

Troubleshooting

I encounter artifacts when logging into my DE or WM

If you encounter artifacts, first try starting X without Template:Filename. Recent versions of Xorg are capable of reliable auto-detection and auto-configuration for most use cases. Outdated or improperly configured Template:Filename files are known to cause trouble.

In order to run without a configuration tile, it is recommended that the xorg-input-drivers package group be installed.

Artifacts may also be related to kernel mode setting. Consider disabling KMS.

I have switched from catalyst to radeonhd or radeon and some things don't work

First of all, don't panic. Uninstall catalyst, install xf86-video-radeonhd or xf86-video-ati and then reboot.

Make sure you are not using the xorg.conf generated by catalyst. Your original should have been backed up and you can recall it:

cp /etc/X11/xorg.conf.original-0 /etc/X11/xorg.conf

Otherwise, stop your graphical server if running, and in a tty, type as root:

Xorg -configure
mv xorg.conf.new /etc/X11/xorg.conf

and make sure you put the required options.

If it still doesn't solve your problem, know that apparently catalyst has the bad idea to replace Xorg files with symbolic links pointing to its own files. The easiest at this point is to uninstall all catalyst stuff (just to be on the safe side) and then to reinstall xorg, libgl, ati-dri and xf86-video-radeonhd or xf86-video-ati.

If it still doesn't work, then have a look into the forum, your problem might be a configuration issue.

Note: When you switch to xf86-video-ati or xf86-video-radeonhd, remember that you can login without xorg.conf as well (without problems in most cases), since Xorg can autodetect your settings. So xorg.conf is optional.

I have installed a free driver and my card is painfully slow

Some cards can be installed by default trying to use KMS. You can check whether this is your case running:

dmesg | egrep "drm|radeon"

This command might show something like this, meaning it is trying to default to KMS:

[drm] radeon default to kernel modesetting.
...
[drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL

If your card is not supported by KMS (anything older than r100), then you can disable KMS. This should fix the problem.

If you're getting and error message in dmesg like this:

platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
[drm:r600_startup] *ERROR* Failed to load firmware!
radeon 0000:01:00.0: disabling GPU acceleration

Install linux-firmware or linux-firmware-git from AUR.