AMDGPU

AMDGPU is Article description:: the next generation family of open source graphics drivers using the new Display Core (DC) framework for Vega GPUs and Raven Ridge APUs. It is however also capable of handling newer AMD/ATI Radeon graphics cards based on GCN1.0+, namely the Southern Islands, Sea Islands, Volcanic Islands, and Arctic Islands chipsets.

If the card in question does not appear in the Feature support section below, it is not supported by AMDGPU. In that case check the radeon article, which contains instructions for older open-source AMD/ATI Radeon graphics card drivers.

Prior to Kernel 4.15 Display Core (DC, developed from Display Abstraction Layer, DAL) was not included in the vanilla kernel sources, thus AMDGPU was not able to provide graphics output to a monitor on VEGA and later chips.

Installation
Setting up a system to use AMDGPU requires identifying the proper card, installing the corresponding firmware, configuring the kernel, and installing the X11 driver.

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

Check the output for one of the product names listed in the table below.

Feature support
Video cores supported by the AMDGPU driver feature OpenGL 4.6 and OpenGL ES 3.2. The VIDEO_CARDS variable must be set to. Via (version 20.0 or higher) the driver additionally supports Vulkan (  driver) and OpenCL 2.0 is available via. There is also support for VDPAU and VAAPI via.


 * A AMD previously called the microarchitecture Display Core (DC). GCN stands for Graphics Core Next and was introduced with the Radeon HD7000 series (GCN1.0). It was superseded by RDNA, short for Radeon DNA, introduced with the Radeon RX 5000 series (NAVI) in 2019.
 * B The actual Instruction Set Architecture (ISA) is defined by the Display Core Engine (DCE), which was superseded by Display Core Next (DCN), introduced with the Raven Ridge APUs (mobile Vega graphics core).
 * 1 Experimental, optional support since kernel 4.9-rc1, full stable support for GCN1.x can be found in the older radeon driver.
 * 2 Support is optional in the kernel.
 * 3 Since kernel 4.7-rc6.
 * 4 Usable for graphics output since kernel 4.15.
 * 5 Since kernel 4.16.
 * 6 AMD Zen 2 "4000" series 7nm laptop APUs
 * 7 Requires at least kernel 5.3, Mesa 19.2 and LLVM 9.0.
 * 8 RX 6*00 series since kernel 5.9.12 with.

Firmware
It is necessary to install the proper firmware (or microcode) for your card. Firmware files are provided by. Make sure you have all necessary files for your hardware in your configuration file if you use the savedconfig USE flag.

The firmware files installed this way will be incorporated into the kernel.

Kernel
Set the following kernel options for the graphic chipsets mentioned above:

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. On newer kernels where Enable AMD Audio CoProcessor IP support appears, that should also be set.

AMDGPU with Display Core was first implemented for VEGA10 (GCN5.0) and RAVEN (with DCN 1.0) GPUs/APUs. Kernels before version 4.17 have (experimental) DC support for older cards (GCN1.1 and newer) via command line option amdgpu.dc=1, which may work better than the older radeon kernel module. Likewise, if DC needs to be disabled for any particular reason, option amdgpu.dc=0 can be used on the kernel command line.

See the radeon article for more details about using HDMI/DisplayPort audio.

Incorporating firmware
The firmware package installed in an earlier section provides files in (for Volcanic Islands and Arctic Islands cards) and/or  (for Southern Islands and Sea Islands cards). Configure the kernel to use the correct firmware files by setting the following options:

In the case that the firmware needs to be included in the kernel or in an initramfs, and if you use the savedconfig USE flag for, make sure that the savedconfig configuration file is updated with a changed set of firmware files as well (like the change in 2018 mentioned above). Incorporate all the newly added files to your kernel configuration file in the firmware line, then rebuild and install your new kernel image. Otherwise your boot will likely fail with a blank screen and firmware load errors thrown to the kernel log.

Unknown firmware blobs
A trial and error method often leads to success. In a multi-step process a basic bootable system may suffice to get the required information: missing firmware is indicated by an amdgpu error in dmesg, which helps to identify the required firmware files.

The way the AMDGPU firmware files are named, all files starting with the GPU model code name are the right firmware blobs to include. In the above example the code name is "Green Sardine", thus this command looking for  will get the required list:

Known firmware blobs
or  should be replaced with the full list of filenames given with the chipset's name in the table below, separated by spaces. Use to expand the filenames. E.g. for Volcanic Islands/TONGA, run:

Then  is the string that should be put into the kernel configuration.

After expanding the firmware file names from the following table and copying them into the kernel configuration, save the configuration, then compile and install the new kernel and modules.

USE flags
Set the USE flags for the  driver as needed.

The package will be automatically emerged as a dependency of after setting VIDEO_CARDS following the instructions in the next section.

Emerge
Portage uses the VIDEO_CARDS variable for enabling support for various graphics cards in packages. Setting VIDEO_CARDS to  (see the feature matrix section above) and asking Portage to update changed USE flags in the @world set will pull in the correct driver:

The system should now be prepared to use amdgpu after the next reboot.

dpm
In most cases since Linux 3.13 dpm is the default power management method. Unlike with dynpm and profile methods enabling or disabling dpm must be done via kernel command line. Users who have GPUs older than HD5000 -series may need to add  on kernel command-line to enable dpm.

In most cases just enabling dpm is enough but there are some tunable settings. dpm has three main modes of operating: battery, balanced and performance. The names are quite self-explanatory. To set the GPU to most performant mode the following command is needed to run:

Even if GPU is set to performance -mode it does not mean that the GPU is running with highest clockspeeds at all the time. This is the normal and intended way how dpm works. If it is desirable to run the GPU at the highest speeds all the time, even if there is no actual load, users can then run following command:

This manually overrides dpm's own bahaviour. This is however mainly intended for testing purposes but may also be useful when doing GPU benchmanks.

To give control back to dpm following command is needed to run:

Clocking and voltages
In order to set clocks and voltages with AMDGPU, first set the performance level to :

Then, adjust clocks/voltages according to the Linux AMDGPU sysfs documentation with the control file.

Debug tools
It might be helpful to install the package, which provides the packages  and.

Test, if a discrete graphics card is in use
First make sure that the kernel was compiled with the following settings:

Check, if the discrete graphics card was recognized:

After that. Make sure that the path was mounted successfully:

Then, check, if the driver vga_switcheroo was loaded successfully and can output values:

This output has the following structure :

represents the discrete graphics card, which is inactive, but currently disconnected. is the integrated graphics card, which is active and is currently in use.

The status can be manipulated using the following command:

Replace  with one of the following paramters :

By using the environment variable, one can use the discrete graphics card individually:

This opens an X window with rotating gears.

Let it run in the background and check,  again:

Another indicator is to check the temperature sensors. This requires :

To use the discrete graphics card globally, one can set the environment variable in :

One might export it in the  as an alternative:

Or individually in front of the command, like above using :

Prime Synchronization
The driver does not support Prime Synchornization. This might cause tearing on monitors connected to the integrated GPU if the AMD GPU is set as the primary GPU. One possible workaround is to use the modesetting driver instead, to do this remove  from the VIDEO_CARDS variable. Or use a xorg configuration file to force the use of the modesetting driver. That being said, you might encounter other issues with the modesetting driver.

Another possible workaround is to set the integrated GPU as the primary GPU. This will not enable Prime Synchronization. However, tearing will be prevented nonetheless through AMD's TearFree. In this case it will be neccesairy to use the,  (for VDPAU) and  (for VAAPI) variables on applications that should be rendered on the AMD GPU.

VESA
If you have no other machine to browse web pages for solution - emerge x11-drivers/xf86-video-vesa This will allow you to use basic vesa driver so you can start X with no 3d and no 2d acceleration. Your usual kde/gnome/xfce or whatever else should start with vesa driver, so you can bootstrap yourself from within GUI.

Older kernels
Older kernels which do not support the amdgpu driver will not provide the AMDGPU option. For VEGA and newer chips there is no video output without DC (Display Code), which was first included in vanilla Kernel 4.15. In both cases a fairly recent kernel can provide the required drivers. For very new AMD graphics cards and APUs trying an unstable (denoted by a ) kernel may provide the required kernel-sources.

AMD Secure Memory Encryption
If amdgpu fails to load or the screen stays frozen, it might be an incompatibility of the amdgpu module with AMD Secure Memory Encryption (SME).

SME can be temporarily disabled on the kernel command line (using GRUB, or in or as part of GRUB_CMDLINE_LINUX ) by adding mem_encrypt=off. If this fixes the issue, a permanent solution is to configure the kernel accordingly.

AMD_MEM_ENCRYPT may remain enabled, but either AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT must remain unset or the kernel command line option mem_encrypt=off must be used in order to turn Memory Encryption off. Likewise, with mem_encrypt=on SME can be activated for unaffected systems on the kernel command line or more permanently using GRUB_CMDLINE_LINUX in for GRUB.

AMDGPU/RadeonSI drivers do not work
If the graphics card is not supported by including  and   alone in VIDEO_CARDS, try adding   to 's VIDEO_CARDS definition. For example:

After the values have been set update the system so the changes take effect:

Full-screen windows perform poorly
The installed version of may be too old. Try emerging an unstable/testing version.

Pixel-wide line on left side of screen when X server is started when using a Southern Island card
Those using a Southern Island card may notice a pixel-wide line on the left of the screen in both the X server and console environments after having started a X server (This issue doesn't exist when using Linux 4.13 or newer). This is a known bug. Disabling audio through HDMI for that display resolves this issue. This may be done via:

where  should be replaced by the name of the output, obtained by running

For more information please see https://bugs.freedesktop.org/show_bug.cgi?id=97861.

Xrand doesn't see HDMI port with hybrid system
On hybrid system with AMD iGPU and dGPU xrandr can show only eDP port, but not HDMI:Where as Xorg log shows that port was detected and EDID of the monitor decoded without issues:

If it doesn't then it is different issue. And it should be addressed first.

Xrandr would have 2 providers since there are 2 GPUs.

And we need to link source with output:

In provided example it would be this:

After this xrandr shows HDMI and can manipulate layout properly:

External resources

 * A list of RadeonSI articles on the Phoronix site.