Mesa falls back to CPU rendering · Linux Fix Lab

Symptoms & scope

Animations consume substantial CPU and games are unexpectedly slow.
The OpenGL renderer is llvmpipe or softpipe although a hardware GPU was expected.

Relevant environment

Mesa OpenGL applications in a local desktop, container, remote session or virtual machine; software rendering is valid in some environments.

Recognizable messages (synthetic examples)

libGL error: failed to load driver: iris

Inspect preceding path and library errors; software rendering itself is not automatically a fault and is not matched.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

An explicit software-rendering environment override may be active.
Missing DRI libraries, missing render-device access, incompatible application runtimes or a deliberately virtual display can select software rendering.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Run as the user in the affected graphical session; glxinfo requires X11 or Xwayland and the distribution’s diagnostic package.

glxinfo -B

Interpret the result: llvmpipe/softpipe identifies CPU rendering. Under native Wayland this describes the Xwayland OpenGL path, not every native application.

Check 2

Read selected graphics overrides from this shell; a launcher or container may set a different environment.

printenv LIBGL_ALWAYS_SOFTWARE GALLIUM_DRIVER MESA_LOADER_DRIVER_OVERRIDE LIBGL_DRIVERS_PATH

Interpret the result: LIBGL_ALWAYS_SOFTWARE=true intentionally requests software. An unset value does not establish correct libraries or device permissions.

Evidence-guided next steps

Remove an unintended per-app override

If an affected launcher explicitly forces software rendering, remove that parameter from a copy of its profile and restart only that application. Compare the reported renderer before applying the change globally.

Precautions: Keep deliberate headless or test profiles unchanged. Do not force a hardware driver name that does not match the actual GPU.

Recovery / rollback: Restore the original launcher profile if the application stops working.

Did this solution help you?

Share this solution #

Repair the packaged rendering path

If no override explains a failed DRI load, reinstall the matching distribution Mesa/DRI package for the application architecture and check that the session can use its render node. For containers, configure the runtime’s documented GPU access.

Precautions: Do not copy host libraries into a bundled runtime or make all /dev/dri nodes world-writable; permissions should follow session or runtime policy.

Recovery / rollback: Restore the package snapshot or application runtime profile if the repair changes working applications.

Did this solution help you?

Share this solution #

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.

Mesa LLVMpipe software renderer (project or distribution documentation)
Mesa environment variables: software and loader overrides (project or distribution documentation)

Related hardware and driver context

These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.

Identify hardware locally

Investigate the gaming failure path

Connect these system observations to Proton, Vulkan and frame-time evidence. A detected GPU or a reset message alone does not establish the cause of a game crash.

Follow the gaming diagnostic questions · Inspect gaming logs locally