Graphics Hardware Acceleration and How to Check and Toggle It Under Linux

Last updated: January 15, 2024

1. Introduction

Graphics hardware is vital for many applications. To use it, we often enable so-called graphics hardware acceleration. However, the setting can be detrimental when attempting to work with the central processing unit (CPU) alone or simply experimenting. Still, dedicated graphics processors are often much better suited to visual tasks, so using them can be a big advantage.

In this tutorial, we talk about ways to toggle or just check the current state of video hardware acceleration. First, we discuss graphics hardware acceleration in general. Next, we look at the same from the perspective of a specific Linux distribution and how to ensure we have support. After that, we check the current status of video hardware acceleration. Finally, we go over methods to toggle graphics cards and the acceleration that they provide.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Graphics Hardware Acceleration

Graphics interfaces can accelerate the processing of suitable tasks:

  • video production
  • video editing
  • 2D and 3D graphics rendering
  • graphics user interface (GUI) elements
  • cryptocurrency mining

Even if a given system has a graphics card physically attached, it doesn’t mean that the operating system (OS) or applications can and do use it for hardware acceleration. For example, Linux hasn’t been a video-oriented OS for a long time, so expectations can be low for hardware acceleration support.

Many levels of configuration might enable or prevent the use of a graphics processing unit (GPU):

Considering all of these points of potential failure and severance, it can be fairly difficult to get a video card working towards a given goal. In particular, as mentioned, a GPU doesn’t immediately optimize everything that it can process. In fact, it’s up to the graphics application programming interface (API) and any frameworks or libraries used to ensure proper support, before an application can even take over.

For instance, we can choose any low-level 3D API like Direct3D (DirectX), Mantle (AMD), OpenGL, or similar. Based on that, some software might leverage our video card, but some might be unable to.

On the other hand, in some cases, we want to disable hardware acceleration by the GPU for a given application. For example, older games may not support newer graphics hardware.

3. Support Video Hardware Acceleration

To ensure we even support hardware acceleration, we might have to install different components.

When it comes to Debian-based systems, there are three main options:

  • VA-API: supports Intel, AMD, and NVIDIA (only Nouveau, not proprietary drivers) and is widely supported by software, including Kodi, VLC, MPV, Chromium, and Firefox
  • VDPAU: supports AMD and NVIDIA (proprietary and Nouveau drivers), but not Intel, and is supported by most desktop applications like Kodi, VLC, and MPV, without support in Chromium or Firefox for Web acceleration
  • NVENC/NVDEC: proprietary, supports only NVIDIA, and is only supported by a few major applications like FFmpeg and OBS Studio for encoding, FFmpeg and MPV for decoding

To ensure video acceleration is possible on a Debian-based OS, we often have to install a graphics API for the purpose. How we do that varies according to our requirements and hardware.

At the most basic level, we can install the vainfo or vdpauinfo packages and employ their respective vainfo and vdpauinfo commands to check for support. In addition, intel-gpu-tools provides the intel_gpu_top command for listing how and whether processes employ an Intel GPU.

4. Check Video and Video Hardware Acceleration Status

Before attempting changes, let’s see the current status of our video hardware acceleration in general.

To do so, we use APT to install glxinfo, part of the mesa-utils package:

$ apt-get install mesa-utils

The glxinfo command, part of FreeDesktop, shows general information about the graphics setup of the system. While it employs the Mesa 3D Graphics Library to do so, it usually provides accurate data for OpenGL, Direct3D, and other frameworks within multiple hardware settings.

So, let’s run glxinfo:

$ glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    [...]

390 GLX Visuals
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x021 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x389 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x38a 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0 16 16 16 16  0 0 Slow
[...]

The output is very long, but we can briefly summarize each section:

  • general information about server and client data
  • OpenGL characteristics and profile
  • buffer values and settings

As per the official documentation, we can check whether our setup is working by filtering for the render string:

$ glxinfo | grep render
direct rendering: Yes
[...]
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)

Here, we use grep to show whether direct rendering is enabled and what the current OpenGL renderer string is. In this case, we’re dealing with software rendering without hardware acceleration.

On the other hand, we can get an output that shows an external GPU and its associated driver and graphics hardware:

$ glxinfo | grep render
direct rendering: Yes
[...]
OpenGL renderer string: NVIDIA GeForce GX 666 PCIe/SSE2

In this case, we see an NVIDIA driver video card.

5. Enable or Disable Video Hardware Acceleration

There are different ways to prevent hardware acceleration. Some of them involve completely disabling the graphics processor, while others are more refined and targeted.

5.1. Physical Video Card Presence

Naturally, there can’t be any video hardware acceleration if we don’t have dedicated graphics hardware connected to the system. So, disconnecting the GPU physically is one option.

However, modern systems almost always have at least a basic graphics processor, often embedded in the motherboard. So, even if we disable an external GPU, some hardware acceleration can occur unless we configure it.

5.2. BIOS or UEFI Toggle

Another option is to toggle whether a video card is active or usable within the most basic machine settings. The process is specific for each system but generally involves booting to BIOS or UEFI.

Then, we enable, disable, or switch between external and internal graphics interfaces.

5.3. Kernel Modules

Of course, the kernel can also handle the loading and unloading of graphics card drivers and settings, especially via kernel parameters and kernel modules.

For example, we can change the GRUB_CMDLINE_LINUX line in the /etc/default/grub file to include specific features or disable a card altogether by unloading its driver. After making changes, we update the boot options via update-grub:

$ update-grub

Similarly, we can do that by automating modprobe or using systemd-modules-load to configure kernel modules related to graphics. Depending on the settings and modules, hardware acceleration might be disabled altogether or enabled only for some operations.

5.4. Dedicated Tools

Most video card manufacturers provide a toolset for management:

There are usually commands that can handle enabling and disabling the relevant interface or hardware. By doing so, we can allow or prevent hardware acceleration.

5.5. Graphics Server

Some machines have enhanced Kernel Mode Setting (KMS) during CLI-only boot, so graphics hardware is part of the boot process even in a supposedly text-only interface. Yet, this isn’t required.

In any case, since the graphics server is usually at most the second process in the system that performs graphics operations and also supports most other such requests after it’s loaded, we can use it to manage hardware acceleration.

For example, Xorg has configuration files in the /etc/X11/xorg.conf.d/ directory, which can aid with card selection, driver loading, and more:

$ cat /etc/X11/xorg.conf.d/disable-gpu.conf
Section "Extensions"
  Option "GLX" "Disable"
EndSection

In this case, we disable the GLX extension of X to prevent our graphics hardware from rendering windows.

Further, we can create vendor-specific configurations:

$ cat /usr/share/X11/xorg.conf.d/99-nvidia.conf
Section "OutputClass"
    Identifier "nvidia"
    MatchDriver "nvidia-drm"
    Driver "nvidia"
    Option "AllowEmptyInitialConfiguration"
    Option "Accel" "off"
    ModulePath "/usr/lib/x86_64-linux-gnu/nvidia/xorg"
EndSection

This way we turn off video hardware [Accel]eration by our nvidia hardware for the window system.

Importantly, although some newer display servers such as Wayland have X integration via tools like Xwayland, we can’t rely on them to read and apply settings from the xorg.conf.d directory.

6. Summary

In this article, we discussed the hardware acceleration provided by graphics hardware and how we can check or control it.

In conclusion, despite the catch-all term, video hardware acceleration isn’t always trivial to get working or prevent, as it strongly depends on the actual physical components, system, drivers, settings, and applications.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.