Mesa is the Linux graphic driver stack. As soon as you install a desktop environment like KDE, the Mesa graphic driver stack is installed by default, to install Mesa including Vulkan support run:
sudo pacman -Sy mesa lib32-mesa libdrm lib32-libdrm vulkan-icd-loader lib32-vulkan-icd-loader vulkan-tools vulkan-radeon lib32-vulkan-radeon vulkan-intel lib32-vulkan-intel vulkan-mesa-layer
- AMD RadeonSI: OpenGL 4.6 plus NIR by default (since Mesa 20.0, Mesa 19.x required radeonsi_enable_nir=true), OpenGL ES 3.2 and Compat profile 4.6, FreeSync support in X11 driver amdgpu for RadeonSI and RADV (since Linux 5.0 + Mesa 19.1, patches for Wayland not available yet).
- Intel Iris: OpenGL 4.6 plus NIR (since Mesa 19.3, Iris Gallium driver planned as default in Mesa 20.1 for Broadwell and newer). Intel i965: OpenGL 4.6 (since Mesa 19.3), OpenGL ES 3.2
- Mali 400/450 graphics: Added Lima to Mesa 19.1 and Linux 5.2
- Mali 600/700/800 Midgart/Bifrost graphics: Added Panfrost to Linux 5.2, Mesa 19.0 provides support, experimental OpenGL ES 3.0 support in Mesa 20.1
- Mali /G71: Added Komeda since Linux 5.1 as a display output driver without 3D
- Qualcomm: Freedreno supports OpenGL 3.1 and OpenGL ES 3.1
- Other: See https://mesamatrix.net
You can remove all 2D drivers like xf86-video-* in Arch Linux if working on Wayland Even on X11 it is recommended to use the Glamor, except for amdgpu (required for FreeSync on X11). Example:
pacman -Rsc xf86-video-ati xf86-video-fbdev xf86-video-vesa xf86-video-intel
Especially the Intel 2D driver is known to cause instabilities, it has a lot of bugs and is bad maintained. Therefore Distributions like Debian switched already away from it.
HUD – OpenGL
MangoHud is a beatiful Hud that supports Vulkan, OpenGL and DXVK and as the preferred solution nowadays, read Gaming.
You can add to the OpenGL HUD for Gallium drivers (AMD, Intel, nouveau, …) to see the frames per second (FPS) in a terminal:
or Steam launch option:
Personally I don’t like the graphs and I use the following options:
Both AMD and Intel GPU’s (before Skylake) require proprietary/closed firmware blobs, which is sad. For older Intel platforms there are some available without the need for a Intel GPU firmware blob. Personally not requiring a firmware blob is an important argument for free and secure software and I prefer to run as much as possible free and open source software.
Mesa Application Specific Settings
If you wonder, which drivers are required for AMD GPU’s, look at this illustration of the architecture https://people.freedesktop.org/~mareko/dot_mesa.png.
Older generations run on RADEON but at least GCN 1.1 or later can be switched via a kernel parameter to AMDGPU including optionally DC. AMD still needs to decide when to switch on AMDGPU and DC for these older GPU’s (not happened yet, still open as of Linux 5.2).
Vega and Polaris GPU require AMDGPU and DC to provide display output, HDMI audio, ROCm initial support, Atomic modesetting and FreeSync.
Add the kernel parameters to your boot loader config to enable for Southern and Sea Island (older than Polaris) the AMDGPU module “amdgpu.si_support=1 radeon.si_support=0 amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.dc=1“
Intel provides since Mesa 19.1 a new Gallium 3D driver and it supports Core i-5000 and newer. This can be enabled with the environment variable MESA_LOADER_DRIVER_OVERRIDE=iris.
- General GPU Crashes can bring down the hole system. They need a technology to avoid complete GPU crashes to prevent complete desktop or even complete kernel freezes because of the graphic drivers. Reporting these issues upstream is therefore as well not easy for the normal users. Example https://phoronix.com/scan.php?page=news_item&px=Intel-Mesa-Less-Haswell-Hangs.
Theoretically HMDI 2.0 should be available on AM4 mainboard with Raven Ridge APU’s even if not specified officially, read https://smallformfactor.net/forum/threads/raven-ridge-hdmi-2-0-compatibility-1st-gen-am4-motherboard-test-request-megathread.6709/
If you want to monitor the activity of a AMDGPU there is the radeontop application in AUR. I have installed the git version.
Videos and games show sometimes a stuttering that is quite noticeable to the user, read https://email@example.com/the-elusive-frame-timing-168f899aec92. To avoid stuttering all the components will need adjustments, from the drivers, game engines to the compositors. Actually only Vulkan has a new extension to measure when a frame is shown on screen, read Vulkan driver AMD/Intel.
Video Hardware Acceleration
Video Hardware acceleration requires additional libs, see https://wiki.archlinux.org/index.php/Hardware_video_acceleration. Video hardware acceleration is one of the topics that can be quite complicated to understand (and definitely could be improved), as you always need driver support for a backend, then support for the special codecs in the backend and then support of video player like VLC, gstreamer, mpv or Kodi. For Intel and AMD VA-API is recommended. VDPAU lacks Wayland (works only trough XWayland) and 4K support and is a fallback to the CPU. It is recommended to install both native backends and to avoid the driver shim for AMD (VDPAU -> VA-API, libvdpau-va-gl) where for Intel it is required.
For AMD and Intel install:
sudo pacman -Sy libva-mesa-driver mesa-vdpau libva-intel-driverlibva libva-utils vdpauinfo
If va works you should get an output like:
$ vainfo libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.0) vainfo: Driver version: Mesa Gallium driver 18.2.0-devel for AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.25.0, 4.17.0-1-ARCH, LLVM 7.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc
If vdpau works you should get an output like:
$ vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types ------------------------------------------- 420 16384 16384 NV12 YV12 422 16384 16384 UYVY YUYV 444 16384 16384 Y8U8V8A8 V8U8Y8A8 Decoder capabilities: name level macbs width height ---------------------------------------------------- MPEG1 --- not supported --- MPEG2_SIMPLE 3 65536 4096 4096 MPEG2_MAIN 3 65536 4096 4096 H264_BASELINE 52 65536 4096 4096 H264_MAIN 52 65536 4096 4096 H264_HIGH 52 65536 4096 4096 VC1_SIMPLE 1 65536 4096 4096 VC1_MAIN 2 65536 4096 4096 VC1_ADVANCED 4 65536 4096 4096
If it doesn’t work, you may need to set a environment variable like this for AMD:
$ sudo nano /etc/environment VDPAU_DRIVER=radeonsi
Check if DRI3 is activated with the following command, you shouldn’t see something like this:
$ cat /var/log/Xorg.0.log | grep DRI [ 12.580] (II) modeset(0): [DRI2] Setup complete [ 12.580] (II) modeset(0): [DRI2] DRI driver: radeonsi [ 12.580] (II) modeset(0): [DRI2] VDPAU driver: radeonsi [ 12.582] (II) Initializing extension DRI3 [ 12.585] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 12.585] (II) Initializing extension XFree86-DRI [ 12.585] (II) Initializing extension DRI2
The mesa modeset driver should enable it by default, if not it is a bug
Option 1 – Use mesa modeset driver
Just remove the 2D xf86-video-* driver packages like ATI, Intel, AMDGPU, fbdev, vesa….
pacman -Rsc xf86-video-
Just press 2 times TAB key to see what can be removed.
$ LIBGL_DEBUG=verbose glxinfo | grep libgl libGL: pci id for fd 4: 1002:67df, driver radeonsi libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/radeonsi_dri.so libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/radeonsi_dri.so /usr/share/libdrm/amdgpu.ids version: 1.0.0 libGL: Using DRI3 for screen 0 GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_texture_from_pixmap,
Option 2 – Install 2D drivers
According to the wiki https://wiki.archlinux.org/index.php/AMDGPU the default for the 2D xf86-video-amdgpu driver should enable DRI3 by default. You can install it with:
pacman -Sy xf86-video-amdgpu
After a reboot, I got the following output with DRI3 support:
$ cat /var/log/Xorg.0.log| grep DRI [ 5.559] (II) glamor: EGL version 1.5 (DRI2): [ 5.716] (II) AMDGPU(0): [DRI2] Setup complete [ 5.716] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi [ 5.716] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi [ 5.716] (==) AMDGPU(0): DRI3 enabled [ 5.854] (II) GLX: Initialized DRI2 GL provider for screen
Replacing the AMDGPU with ATI should do the same for older generations of AMD graphic cards, for details see https://wiki.archlinux.org/index.php/Ati#Driver_options.
Early KMS and flicker free boot
Enabling early kernel modesetting (KMS) is a nice feature, straight during initializing the initramfs stage Linux will switch to the native screen resolution allowing a flicker-less boot. For more details read https://wiki.archlinux.org/index.php/Kernel_mode_setting#Early_KMS_start.
To enable it, add for AMD “amdgpu” (older cards may require the radeon module, read the above link for details) and for Intel “i915” to your modules in mkinitcpio :
sudo nano /etc/mkinitcpio.conf ... MODULES="... amdgpu ..." ...
After this regenerate the initramfs (if you use linux-hardened, then use it instead of just linux in the command below):
mkinitcpio -p linux
You will notice the difference at the next boot.
Right now on AMD the boot is not flicker free as it could be. To reduce on a Intel GPU unnecessary modeset operations further, you can experiment with the boot loader paramter which can be added e.g. to systemd-boot or grub:
OpenGL VM passtrough
The VirtIO-gpu driver based on VirGL (https://virgil3d.github.io) for virtual machines allows 3D acceleration via the GPU of the host. It supports OpenGL 4.3 (Mesa 19.1 will support OpenGL 4.4) and OpenGL ES 3.2 acceleration since Mesa 18.2. In April 2018 OpenGL ES 2.0 support has been merged to Qemu, read https://www.collabora.com/news-and-blog/blog/2018/05/09/gpu-virtualization-update. OpenGL ES 3.0 is in the pipeline.
Guest VM interface on Host
There is an effort to allow guest VM applications to show an interface directly on the host windowing system, read https://www.phoronix.com/scan.php?page=news_item&px=VirtIO-DRM-Window-Server.