How to enable hardware acceleration in Linux browsers

If you use Linux daily, you've probably noticed that when playing videos in the browser, the fan spins up, the CPU reaches 100%, and the laptop feels like it's about to take off. That is usually a symptom that the hardware video acceleration It's not properly activated: the processor ends up doing the work that the GPU should be doing, and the result is more noise, higher temperatures, and less battery life.

The good news is that today Firefox, Chromium and almost all their derivatives already include real VA-API support and hardware acceleration on Linux, although it rarely comes well-tuned out of the box. In this guide we will review, step by step and in great detail, how to prepare the drivers, how to activate VA-API in the main browsers and how to really check that the video is being decoded on the GPU and not on the CPU.

What is video hardware acceleration and why should you want to enable it?

When we talk about hardware acceleration in browsers, we mean offloading the heavy work of decoding and processing video to the GPU, instead of leaving it all to the CPU. In practice, this means that when playing multimedia content (YouTube, Netflix(e.g., Twitch, etc.) the graphics card is responsible for decompressing and processing the video frames, while the CPU is much more free.

The technology that bridges applications and GPUs in Linux for video is called VA-API (Video Acceleration API), and it is the de facto standard on the penguin desktop. Many programs support it: browsers, players like VLC or OBS Studio for encoding/decoding with the graphics card, and even editing and capture tools.

The practical advantages of having video acceleration working properly are quite clear in everyday use: less CPU usage, lower energy consumption, lower temperatures, and more stable playback, especially in portable old or with modest processors (2C/4T, for example).

On the other hand, there are some disadvantages and limitations that should be kept in mind from the beginning: Many older GPUs no longer support modern codecs, some browsers limit resolution when using H.264 instead of VP9/AV1, and a loose implementation of VA-API can cause artifacts, green screens, or stuttering in certain videos.

Furthermore, support in Linux remains somewhat more delicate than in WindowsThe combination of drivers + VA-API + browser doesn't always work the first time, and the situation can be very different depending on whether you use Intel, AMD, or NVIDIA and according to the distribution. That's why it's key to first understand what hardware you have, what drivers you're using, and what codecs your GPU supports.

Check which GPU you have and which drivers your Linux uses.

Before touching anything in Firefox or Chromium, you need to know exactly which graphics card you have installed and which driver the kernel is loading. This is crucial for choosing the correct VA-API package and avoiding rare errors later.

To identify the GPU in a Linux-based system, simply launch a terminal something like: lspci -k | grep -EA3 'VGA|3D|Display'The output will tell you the card model and the kernel module it's using, for example, an Intel UHD Graphics 600/620 with the driver. i915.

If your computer only has one GPU, you will usually see a device like "VGA compatible controller" and the driver in use, while if you have a hybrid laptop (Intel iGPU + AMD/NVIDIA dGPU) two graphics devices will appear. This is important because in multi-GPU scenarios there are two DRI rendering devices involved.

To confirm which rendering devices you have, list the contents of /dev/dri with: ls /dev/driOn a simple computer you'll see something like card0 y renderD128; in a hybrid one they will also appear card1 y renderD129.

If you want to go a step further and find out which driver is associated with each DRI device, you can consult /sys/kernel/debug/dri/128/name, /sys/kernel/debug/dri/129/name, etc. For example, a file containing “i915” indicates that this render node corresponds to the Intel iGPU, while one with “radeon”, “amdgpu” or “nouveau” will represent the AMD or NVIDIA GPU used by the system.

VA-API drivers in Ubuntu and derivative distributions: Intel, AMD, and NVIDIA

Once the GPU has been identified, the next step is to install the appropriate VA-API driver so that the graphics card can decode video via hardware. In Debian/Ubuntu-based distributions, this is done via apt with a few key packages.

For Intel GPUs there are basically two families of VA-API drivers: the "classic" i965 and the more modern iHD (intel-media-driver), and free and "non-free" variants are also usually offered. Roughly:

• i965-va-driver: Free driver for VA-API supported in Cantiga, Ironlake, Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake and Cannon Lake generations.
• i965-va-driver-shaders: proprietary variant for those same generations, with certain optimizations.
• intel-media-va-driver: Free VA-API driver recommended for Broadwell onwards (Skylake, Kaby Lake, Coffee Lake, Whiskey Lake, Cannon Lake, Ice Lake, Alchemist, Meteor Lake, etc.).
• intel-media-va-driver-non-free: proprietary version of the previous one, which adds extra features such as hardware encoding in modern codecs like H.265, depending on the hardware.

On a typical laptop with Intel UHD 600/620, for example, you can install the modern, proprietary variant with: sudo apt install intel-media-va-driver-non-free vainfo. The package vainfo It is used to inspect later which exact codecs your GPU supports.

After installation you should have /usr/lib/x86_64-linux-gnu/dri/ a file iHD_drv_video.so (for intel-media-driver) or i965_drv_video.so (for i965). These binaries are what VA-API loads internally when a browser or other application requests video acceleration.

For AMD Radeon and NVIDIA GPUs using the open-source Nouveau driver, the central component on Ubuntu is mesa-va-drivers, which installs the necessary VA-API backends for these cards. In the case of NVIDIA cards with proprietary drivers, things get more complicated: VA-API itself is not directly supported, but rather through a VDPAU→VAAPI bridge (for example with vdpau-va-driver), and yet browsers hardly rely on VDPAU these days.

If you have a hybrid Intel + AMD or Intel + NVIDIA system with open-source drivers, the usual practice is to install both the VA-API driver for Intel (iHD or i965) and mesa-va-driversso that you can choose which GPU handles video decoding. Later we will see how to select a specific DRI device via environment variables.

VA-API drivers in Fedora and their peculiarity with NVIDIA

In Fedora the approach is similar, but the package manager and some specific package names are different. For Intel graphics, VA-API support usually involves installing:

In a terminal, with administrator privileges, you can use: sudo dnf install libva-intel-driver intel-mediasdk intel-media-driverThis ensures you have both the classic and new drivers and their associated libraries.

If you use AMD Radeon or NVIDIA with the open-source Nouveau driver, VA-API support is included in the package. mesa-dri-driverswhich is usually installed by default in Fedora Workstation. Even so, on some systems the actual result with VA-API on AMD/Nouveau may be inconsistent or even fail.

Fedora's advantage over Ubuntu in the proprietary NVIDIA arena is that the VDPAU bridge for VA-API (as libva-vdpau-driver) is usually available directly from official repositories. For example, you can install it with sudo dnf install libva-vdpau-driverHowever, that does not guarantee that browsers will actually make use of VDPAU in practice.

Use vainfo to check which codecs your GPU actually supports.

Installing the packages isn't enough: you need to know which codecs and modes (encoding/decoding) your GPU supports via VA-API to avoid getting stuck with impossible settings. Here comes into play vainfo, which lists supported profiles for a specific DRI device and VA-API driver.

The most robust way to launch vainfo is by explicitly specifying the name of the driver and the rendering device of interest, for example: LIBVA_DRIVER_NAME=iHD vainfo --display drm --device /dev/dri/renderD128This prevents confusion on systems with multiple GPUs or multiple drivers installed.

The typical output of vainfo starts by indicating the VA-API version and driver, and then shows a long list of “profile and entrypoints”. Each line usually has a codec profile (MPEG2, H264Main, H264High, HEVCMain, VP8, VP9, ​​AV1…) and an input/output mode.

What interests us for video playback is that entries like these appear VAEntrypointVLD for the desired codec, as that means the GPU can decode it in hardware. For example, see VAProfileH264High : VAEntrypointVLD implies H.264 decoding support; see VAProfileVP9Profile0 : VAEntrypointVLD This includes hardware VP9 support, and so on.

On older GPUs you will usually see comfortable support for H.264 but an absence of VP8, VP9 or AV1, which forces you to use browser extensions to force websites to serve H.264 instead of newer codecs. Be aware that if the video only exists in VP9/AV1, there's no magic trick: it will be decoded by software.

If vainfo returns errors such as “va_openDriver() failed” or is unable to initialize the requested driver, it is likely that your GPU is not compatible with that specific backend. In that case, it usually works to switch from iHD to i965 on older Intel systems, or to check that the corresponding Mesa package is correctly installed for AMD/Nouveau.

Configure environment variables to fix VA-API driver and DRI device

Many tutorials assume that the first DRI device (renderD128) is always the iGPU and that the system chooses the correct driver without further ado, but in practice, especially on laptops with multiple GPUs, this may not be the case. Hence the importance of setting some environment variables before starting the browser.

The three most commonly used variables for controlling the VA-API and the Firefox graphical back-end on Linux are:

• MOZ_WAYLAND_DRM_DEVICE: path to the DRI device you should use (for example, /dev/dri/renderD128 o /dev/dri/renderD129).
• LIBVA_DRIVER_NAME: short name of the VA-API driver to be loaded (i965, iHD, nouveau, r600, radeonsi, etc.).
• MOZ_X11_EGL / MOZ_ENABLE_WAYLAND: integer indicators (0/1) to enable the use of EGL and the specific route depending on whether you are on Xorg or Wayland.

For example, to launch Firefox in an X11 session using an Intel HD with an iHD driver, you could use something like: MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 LIBVA_DRIVER_NAME=iHD MOZ_X11_EGL=1 firefoxIn Wayland the variant would be similar but with MOZ_ENABLE_WAYLAND=1 instead of MOZ_X11_EGL.

So I don't have to write this every time Bootmany users add LIBVA_DRIVER_NAME=iHD (or whoever it is) to the global file /etc/environmentso that the entire system has that VA-API driver by default. Even so, keep MOZ_WAYLAND_DRM_DEVICE and MOZ_X11_EGL/MOZ_ENABLE_WAYLAND in the launcher or script Firefox is still recommended on hybrid laptops.

On desktops like KDE Plasma, you can edit the Firefox launcher and add "env" followed by the variables to the execution command so you don't always depend on the terminal. Something like Exec=env MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 LIBVA_DRIVER_NAME=iHD MOZ_X11_EGL=1 firefox %u It usually works well.

Enable hardware acceleration in Firefox (VA-API + WebRender)

Mozilla introduced official VA-API support in Firefox for Linux starting with Wayland and later extending it to X11, but for a long time it was disabled by default or only partially implemented. That's why many tutorials recommend tweaking several internal preferences to get the most out of it.

The first thing to do is enter the famous advanced settings page: type about:config In the address bar, accept the warning and use the search bar at the top. From there, there are several relevant adjustment groups.

To enable the modern GPU-based compositor, you should either activate the WebRender engine or force the use of OpenGL: search gfx.webrender.all and put it to trueAnd if you prefer, you can also force layers.acceleration.force-enabled a true to ensure that Firefox attempts to utilize the GPU.

Secondly, you need to make sure that Firefox uses FFmpeg with VA-API instead of its internal decoders where appropriate. To do this, locate these keys and adjust their values:

• media.ffmpeg.vaapi.enabled → true (allow the use of VA-API via FFmpeg).
• media.ffvpx.enabled → false (Disable the internal FFVPX decoder to force the use of FFmpeg).
• media.av1.enabled → false If your GPU does not support AV1 by hardware, the website will preferentially offer other, more "friendly" codecs.
• media.rdd-vpx.enabled → On modern GPUs with hardware VP9 support, you can go to true; in older graphics it is preferable to leave it as is false.

On machines with multiple GPUs and open-source drivers (Intel + AMD, for example) you can also play with the variables MOZ_WAYLAND_DRM_DEVICE and LIBVA_DRIVER_NAME to decide whether the video is decoded on the iGPU or the dGPU. For example, pointing to /dev/dri/renderD129 with LIBVA_DRIVER_NAME=r600 or radeonsi to use the Radeon as a video accelerator.

In systems where, even after adjusting these parameters, VP9 and AV1 remain too resource-intensive, a practical solution is to force the use of H.264 with extensions such as h264ify o Enhanced h264ify. These extensions block VP8/VP9/AV1 on sites like YouTube and specifically request AVC1 (H.264) streams, which almost all GPUs with VA-API decode without breaking a sweat.

Once the changes are made, close Firefox completely, start it with the appropriate environment variables, and try playing a YouTube video at 1080p60 while monitoring the CPU and GPU load. You'll especially notice the improvement on computers that are more than a decade old, where the CPU is already struggling to process high-resolution video via software.

Verify that Firefox is using the GPU to decode video

It is not enough for the browser to "appear" to be running more smoothly: it is necessary to objectively verify that VA-API is being used and that the frames are being decoded on the GPU. There are several ways to do this in Firefox under Linux.

The first is simply to look at the output of the terminal from which you launched Firefox with the environment variables configured. If everything goes well, you should see messages from libva info indicating that va_openDriver() returns 0 and references to the loaded driver (e.g., i965 or iHD) without subsequent errors.

If you use Intel GPUs, you can resort to intel_gpu_top (part of intel-gpu-tools) to view specific activity sections, such as “Video”, which represent the percentage of use of the decoding engine. Without VA-API you'll see that column at zero even if the video is choppy; with VA-API active, it should show a noticeable percentage while the video is playing.

In Radeon graphics cards, the equivalent tool is radeontop, which shows GPU and VRAM usage bars. Although it doesn't always have a separate, explicit section for video decoding, it's easy to see how activity increases when VA-API is running and the driver (e.g., r600 or radeonsi) is correctly directed to the Radeon DRI device.

In environments with multiple GPUs, you may also need to add options such as --bus in radeontop to monitor only the appropriate card. In any case, the pattern is the same: if the CPU load drops and the GPU has more work to do when we play video, we're on the right track.

Finally, repeating the same test with h264ify extensions enabled and disabled allows you to check the real impact of changing VP9/AV1 to H.264 on resource consumption. Measurements taken on systems with i5-2450M and i7-7700HQ show reductions in CPU usage that, on modest processors, can be up to half when VA-API comes into play.

Hardware acceleration in Chromium, Chrome and derivatives (VA-API + flags)

Chromium 88 marked a turning point by introducing "serious" VA-API support in Linux, although with nuances: strong dependence on Xorg, need to use certain flags, and better support for Intel and NVIDIA than for Radeon. Even so, that support has been passed down to the whole family: Google Chrome, Edge, Brave, Vivaldi, Opera, etc.

The first step in any Chromium-based browser is to check the internal flags page, accessible with chrome://flags in Chrome and Chromium, brave://flags in Brave, edge://flags at Edge, vivaldi://flags in Vivaldi or opera://flags at Opera. Once inside, search for and activate at least:

• Override software rendering list → Enabled (forces ignoring the GPU blacklist and forcing accelerated features).
• Hardware-accelerated video decode → Enabled (enables hardware video decoding).

After enabling these options, your browser will ask you to restart to apply the changes; do so and then visit chrome://gpu (or the variant for your browser) to check the status of “Graphics Feature Status” and “Video Acceleration Information”. Ideally, everything relevant should appear as "Hardware accelerated".

The next key point in Chromium and derivatives is how the application is started from the line of commands. In Xorg sessions it is usually recommended to add the flag --use-gl=desktop, whereas in Wayland sessions where the browser runs on XWayland, it is often used --use-gl=egl to avoid problems.

Additionally, there is a set of VA-API related flags in Chromium that should be added, either to the execution command or to a flags configuration file:

• --enable-accelerated-video-decode
• --enable-accelerated-video-encode
• --enable-features=VaapiVideoDecoder
• --disable-features=UseChromeOSDirectVideoDecoder

For example, in Xorg with Google You could launch something like this in stable Chrome: google-chrome-stable --use-gl=desktop --enable-accelerated-video-decode --enable-accelerated-video-encode --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoderThe same pattern applies to Brave (brave-browser), Vivaldi (vivaldi), Opera (opera) or Edge (microsoft-edge).

In distributions like CachyOS, Arch, and similar systems, many browsers allow these flags to be centralized in files like ~/.config/chromium-flags.conf, ~/.config/brave-flags.conf or similar. Another common alternative is to edit the file. .desktop from the browser, copy it from /usr/share/applications a ~/.local/share/applications and add the flags to the line Exec=.

Once again, if you want everything to be persistent and not depend on the terminal, it's best to edit that. .desktop or the launcher in the desktop environment menu so that it always adds the correct flags. This way, when opening the browser from the menu or the dock, the VA-API options are always respected.

Checking hardware decoding in Chromium browsers

In the Chromium family there are two main ways to verify that video decoding is happening by hardware. One is more generic and the other takes advantage of development tools.

The quick way is to visit chrome://gpu (or the equivalent in your browser) and check that in “Video Acceleration Information” there are entries with a status of “Hardware accelerated”. This gives an overall view of the capabilities, but it doesn't guarantee that a specific video will actually use the GPU.

To check a real-world example, open a video (for example, on YouTube), then enter the developer tools with F12 or Ctrl+Shift+I and look for the tab Media (If it doesn't appear, you'll find it in the additional tabs menu). Within Media, select the player for the video you are playing.

In the player's detailed information, you will see a field that indicates the type of video decoder used and whether the "Hardware decoder" is set to true. Ideally, you should see a decoder associated with VA-API/GL and with the hardware decoder enabled; if instead you see names like VpxVideoDecoder, FFmpegVideoDecoder o Dav1dVideoDecoder Without reference to hardware, it is likely that software is being used.

In some older versions, it was recommended to use chrome://media-internals for this same check, and review fields such as kVideoDecoderName, where a value of type MojoVideoDecoder It indicated the use of hardware acceleration versus purely software decoders. With modern tools, the Media tab in DevTools has largely superseded that page.

Finally, you can combine this verification with GPU monitoring tools similar to those seen in Firefox (intel_gpu_top, radeontop, amdgpu_top, nvtop, etc.), ensuring that when the browser plays video, the GPU's video engines show real activity.

Encoding and codecs: H.264, VP9, ​​AV1 and extensions such as h264ify

One detail that often goes unnoticed is that, even if the GPU supports VA-API, if the video codec is not implemented in the hardware, you will inevitably end up using software decoding. This is where extensions and extra configurations come into play.

H.264/AVC1 is the "wildcard" codec that virtually all GPUs that are a few years old handle well via VA-API, while VP8, VP9 and AV1 are only hardware-accelerated in relatively modern generations. This is clearly seen in the exit of vainfowhere older GPUs show support only for H.264 and little else.

Platforms like YouTube, however, prioritize VP9 or even AV1 for modern browsers, leaving H.264 as a secondary option or only for specific resolutions. Therefore, even if you have VA-API configured, if YouTube decides to serve you VP9 and your GPU doesn't support it, the CPU will take the hit.

That's where extensions like h264ify and its forks (Enhanced h264ify, etc.) are tremendously useful: they block VP8/VP9/AV1 and force the website to use the available H.264 profile when it exists. However, if there is no H.264 version of a specific video, they won't be able to create one.

It's worth noting that YouTube, when forced to use H.264, often limits the maximum resolution to 1080p at 60 FPS, whereas with VP9/AV1 it can offer 1440p, 4K and high frame rates. Therefore, enabling h264ify sometimes means sacrificing the maximum possible resolution in exchange for smoother playback that is less aggressive on the CPU.

In the case of next-generation codecs like AV1, only very modern GPUs have real hardware decoding support, so on most current PCs it's still best to disable it in the browser if you notice your fans becoming like turbines when watching any video.

Real impact on performance: when it pays to fight with VA-API

Empirical tests performed on laptops with 2-core, 4-thread CPUs (e.g., an i5-2450M from years ago) show that enabling VA-API and delegating H.264 decoding to the GPU can practically halve the average CPU usage during 1080p60 video playback in Firefox. This translates into cooler and quieter equipment, and a much more stable experience.

In newer machines with 4C/8T processors or higher (such as an i7-7700HQ), the difference in CPU percentage is less dramatic, sometimes on the order of 3-6% lower. Even so, the load tends to be distributed better and extreme usage peaks that can cause small jerks are reduced.

Interestingly, if you compare browser playback with VA-API against a player like VLC also configured with VA-API, you'll see that the browser's CPU consumption is usually significantly higher. This suggests that there is still room for improvement in how browsers integrate VA-API and manage data transfer between CPU and GPU on Linux.

In any case, for modest or older laptops, spending some time fine-tuning hardware acceleration can make the difference between having to give up on 1080p videos and being able to consume high-resolution content without the system suffering. On powerful systems the improvement exists, but it is more subtle and in many scenarios it may not be worth complicating things too much if you are already doing "well enough".

What does seem clear is that the combination of Linux + modern browsers + VA-API is still a bit behind the experience achieved on Windows, where the ways to delegate video to the GPU are more polished and standardized. Even so, with the right steps, very respectable behavior can be achieved on the penguin's desktop as well.

If you've made it this far, you already know that enabling hardware video acceleration in Linux isn't just about checking a box in your browser, but about properly aligning VA-API drivers, environment variables, internal flags, and codec choices so that Firefox, Chrome, Brave, and others work seamlessly with your GPU instead of unnecessarily straining your CPU.