Enable VA-API hardware acceleration in default Chromium flags

[Reventlow]

Problem

Omarchy's default chromium-flags.conf doesn't include VA-API flags, so hardware video decode/encode falls back to software rendering on Intel GPUs. This causes unnecessary CPU load, high temperatures, and fan noise — especially during video calls (Teams, Meet) and video streaming.

On a ThinkPad X1 Carbon Gen 13 (Lunar Lake), a simple Teams meeting pushes the CPU to 80°C with fans at ~7000 RPM. The Intel iHD driver fully supports VA-API (H264, HEVC, VP9, AV1), but Chromium doesn't use it without explicit flags.

Proposed change

Add these flags to the default chromium-flags.conf:

--enable-features=VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--enable-gpu-rasterization
--enable-zero-copy
--ignore-gpu-blocklist

This would also benefit the Electron flag files (electron-flags.conf, etc.) since Electron apps like Teams and Spotify have the same issue.

Why it's not enabled by default

Chromium disables hardware acceleration on Linux by default due to driver compatibility concerns across the wide variety of GPU drivers. Since Omarchy targets a known setup (Arch + Intel/AMD), it should be safe to enable by default.

Verification

After adding the flags, hardware acceleration can be verified in Chromium at chrome://gpu — look for "Video Decode: Hardware accelerated" and "Video Encode: Hardware accelerated".

[LurkAndLoiter]

If this is every taken into Omarchy, and you're on Nvidia be aware this may use more energy. If still inclined to do so, add export CUDA_DISABLE_PERF_BOOST=1 to the environment.

[abguymon]

Some measured findings from an X1 Carbon Gen 13 (Lunar Lake, Arc 140V) — same machine as the original report. Two things have changed since this was filed that affect the proposed flags.

1. VaapiVideoEncoder no longer exists. It was renamed to AcceleratedVideoEncoder in Chromium 131. On Chromium 151 the old name is a no-op — it isn't in the binary's feature list at all. So the flag block in the original suggestion silently does nothing for encode today.

2. The decode flag is now redundant. Chromium 151 enables hardware video decode by default. With a completely stock config (zero VA-API flags) I get:

video_decode  enabled
HW decode profiles: h264 baseline/main/high, vp8, vp9 profile0/2,
                    hevc main/main10/main-still, av1 main

So VaapiVideoDecodeLinuxGL isn't needed to get hardware decode anymore — which matters given ad2ae30 removed it for crashing machines. The decode half of this request appears already solved upstream.

3. What the encode flag actually buys on Lunar Lake. Adding --enable-features=AcceleratedVideoEncoder flips video_encode from disabled_software to enabled. But testing what WebRTC can actually use, via navigator.mediaCapabilities.encodingInfo({type:'webrtc', ...}) at 1280x720@30:

Codec	stock	with flag
H.264	powerEfficient=false	powerEfficient=false
VP8	false	false
VP9	false	false
AV1	false	true

Only AV1 crosses over. The reason is the hardware: probing VA-API encode entrypoints directly on this GPU,

h264_vaapi   OK        vp8_vaapi   No usable encoding entrypoint (VAProfileVP8Version0_3)
hevc_vaapi   OK        vp9_vaapi   No usable encoding entrypoint (VAProfileVP9Profile0)
av1_vaapi    OK

Lunar Lake's media engine dropped VP8/VP9 encode (decode is retained). Since most WebRTC still negotiates VP8/VP9, the flag only helps when a call actually uses AV1. Worth noting H.264 has a working VA-API entrypoint but Chromium still reports it as not power-efficient, so it isn't wired up on this platform either.

4. Magnitude, where it does apply. ffmpeg, 720p30, 300 frames, CPU time:

libvpx-vp9 (realtime, cpu-used 8)   1.95 s CPU   ~19% of a core
av1_vaapi                           0.46 s CPU   ~4% of a core

Caveat: that's a synthetic testsrc2 source, not a measured Meet/Teams call, so treat it as an encoder-level ratio rather than a promised end-to-end saving.

Suggestion: given ad2ae30, and the NVIDIA power-draw caveat raised above, a blanket default still looks like the wrong shape. But AcceleratedVideoEncoder is a genuinely different flag from the one that was reverted, and it's decode — not encode — that Chromium now handles by default. An opt-in toggle for people on Intel iGPUs with AV1 encode silicon would capture most of the benefit with none of the fleet-wide risk.

One practical gotcha for anyone adding it by hand: Chromium honours only the last --enable-features= argument, so it has to be merged into the existing line rather than added as a second one:

--enable-features=TouchpadOverscrollHistoryNavigation,AcceleratedVideoEncoder

Environment: Chromium 151.0.7922.173, kernel 7.1.8-arch1-3 (xe), mesa 26.2.1, intel-media-driver 26.2.4, libva 2.24.1.