Dennis HilkLinux Fix LabDE

Graphics, GPU & Display

Application runs on the unintended GPU

Hybrid graphics separates display ownership from rendering; compare device selection per API before forcing the entire desktop onto another GPU.

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

  • An application uses the integrated GPU despite an available discrete GPU.
  • A monitor attached to one GPU works while a rendering application chooses another.

Relevant environment

Multi-GPU systems using Mesa PRIME or NVIDIA render offload; offload support depends on the installed driver and session.

Possible causes

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

  • Default enumeration order or an application’s selection policy may prefer the integrated GPU.
  • OpenGL and Vulkan may use different offload controls; display connector ownership does not establish the rendering GPU.

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

List all display controllers and active drivers; no administrative changes are made.

lspci -nnk

Interpret the result: Both GPUs need a suitable active driver for useful offload. An unbound GPU cannot be selected merely by setting an environment variable.

Check 2

Read Vulkan device names in the application’s runtime; requires vulkaninfo.

vulkaninfo --summary

Interpret the result: Multiple devices make per-app selection possible, but enumeration order alone does not prove which device the application actually chose.

Evidence-guided next steps

Select a Mesa GPU for one application

If both Mesa-supported GPUs are listed, test the application with the documented DRI_PRIME selector in its launcher. Confirm the application’s own renderer; Vulkan can require the selector form that hides other devices.

Precautions: Apply the setting per application, not globally. A selected GPU still needs runtime and device access; avoid changing PCI binding.

Recovery / rollback: Remove the added DRI_PRIME setting from the launcher to restore normal device selection.

Did this solution help you?

Share this solution#

Use NVIDIA’s supported render offload

If NVIDIA is the intended rendering GPU, use its documented PRIME offload variables for the specific API: OpenGL GLX also needs NVIDIA vendor selection, while Vulkan uses the NVIDIA offload layer. Check the installed release’s guidance.

Precautions: Do not assume Xorg examples fully configure a Wayland session. Forcing the whole desktop to a discrete GPU can affect battery life and external displays.

Recovery / rollback: Remove only the added offload variables and return to the original application profile.

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.

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