Dennis HilkLinux Fix LabDE

Graphics, GPU & Display

Mesa falls back to CPU rendering

A desktop may remain usable through llvmpipe while GPU acceleration is missing; distinguish intended headless rendering from a failed driver path.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

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.