protonscr

Wrong GPU selected for devices with dGPU before iGPU on PCI bus

steamopen
ValveSoftware/steam-for-linux#11967 · opened 2025-05-02 by flukejones · updated 2026-10-07 · 9 comments · github
Fflukejones 2025-05-02 github

The laptop is an ASUS GA605W, G16. These and a few others have the dGPU before the iGPU on the PCI and this has caused numerous issues with many things including desktops making assumptions that the first gpu is always the iGPU.

Steam does the same:

Running query: 1 - GpuTopology
Response: gpu_topology {
  gpus {
    id: 1
    name: "NVIDIA GeForce RTX 4070 Laptop GPU"
    vram_size_bytes: 8585740288
    driver_id: k_EGpuDriverId_NvidiaProprietary
    driver_version_major: 570
    driver_version_minor: 144
    driver_version_patch: 0
  }
  gpus {
    id: 2
    name: "AMD Radeon Graphics (RADV GFX1150)"
    vram_size_bytes: 11805163520
    driver_id: k_EGpuDriverId_MesaRadv
    driver_version_major: 25
    driver_version_minor: 0
    driver_version_patch: 4
  }
  gpus {
    id: 3
    name: "llvmpipe (LLVM 20.1.2, 256 bits)"
    vram_size_bytes: 3221225472
    driver_id: k_EGpuDriverId_MesaLLVMPipe
    driver_version_major: 0
    driver_version_minor: 0
    driver_version_patch: 1
  }
  default_gpu_id: 1
}

Checking:

~ via C v15.1.1-gcc took 2s 
❯ DRI_PRIME=1 glxinfo | grep 'renderer string'
glx: failed to create dri3 screen
failed to load driver: nouveau
OpenGL renderer string: zink Vulkan 1.4(NVIDIA GeForce RTX 4070 Laptop GPU (NVIDIA_PROPRIETARY))

~ via C v15.1.1-gcc 
❯ DRI_PRIME=0 glxinfo | grep 'renderer string'
OpenGL renderer string: AMD Radeon Graphics (radeonsi, gfx1150, LLVM 20.1.2, DRM 3.61, 6.14.2-rog_cachyos1.fc42.x86_64)

If I try DRI_PRIME=0 steam , then I get:

Saving response to: /tmp/steamJHjahm - 167 bytes
Invalid value (0) for DRI_PRIME. Should be > 0
Invalid value (0) for DRI_PRIME. Should be > 0

lscpi snippet:

65:00.0 VGA compatible controller: NVIDIA Corporation AD106M [GeForce RTX 4070 Max-Q / Mobile] (rev a1)
65:00.1 Audio device: NVIDIA Corporation AD106M High Definition Audio Controller (rev a1)
66:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Strix [Radeon 880M / 890M] (rev c1)

Clarification: no matter what, Steam selects the dgpu because it is the first gpu on the bus. I would like it not to do this, or at least provide a method to change the default.

Kkisak-valve maintainer 2025-05-02 github

Hello @flukejones, this issue is already being tracked at #8179. Closing as a duplicate.

Fflukejones 2025-05-03 github

@kisak-valve I think this is a different issue. All the usual fixes like PrefersNonDefaultGPU or setting DRI_PRIME do not work as the root cause is that the GPU are ordered differently to standard. It is not related to nvidia drivers or nouveau at all.

Please re-open.

Kkisak-valve maintainer 2025-05-03 github

Can you clarify exactly what is broken here? I expect that the laptop's display is physically wired to the iGPU in your laptop, which is where this behavior is coming from. The NVIDIA driver might not listen to DRI_PRIME, and you may have more luck testing __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia and/or __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only from https://download.nvidia.com/XFree86/Linux-x86_64/570.144/README/primerenderoffload.html to push the video driver stack towards the dGPU.

Fflukejones 2025-05-03 github

The issue is that steam is selecting the dgpu no matter what, and I would like it not to. As I've stated in the description the dgpu is first on PCI bus before the igpu and so all assumptions that the first gpu is the igpu are broken. This affects kde, gnome, cosmic etc and all have had to be patched to solve it.

MMikilio 2025-05-04 github

Same instancee of this issue can reproduce this with the following GPUs:

> DRI_PRIME=0 glxinfo | grep "OpenGL renderer"
> DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 19.1.7, DRM 3.61, 6.14.1-zen1)
OpenGL renderer string: AMD Radeon 780M (radeonsi, phoenix, LLVM 19.1.7, DRM 3.61, 6.14.1-zen1)

So not an NVIDIA issue at all

Fflukejones 2025-06-02 github

I can force steam to use iGPU only like this:

❯ MESA_VK_DEVICE_SELECT=list vulkaninfo
selectable devices:
  GPU 0: 10de:2860 "NVIDIA GeForce RTX 4070 Laptop GPU" discrete GPU 0000:65:00.0
  GPU 1: 1002:150e "AMD Radeon Graphics (RADV GFX1150)" integrated GPU 0000:66:00.0
  GPU 2: 10005:0 "llvmpipe (LLVM 20.1.3, 256 bits)" CPU 0000:00:00.0

❯ MESA_VK_DEVICE_SELECT=1002:150e! steam

but this means I am completely unable to offload any games to the dGPU. Steam really needs a way to select the primary gpu for the client.

With the above I also tried various offload methods for games such as __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only, but nothing is able to run unless I set MESA_VK_DEVICE_SELECT="10de:2860!" %command% for the game.

using the ! is the same as using MESA_VK_DEVICE_SELECT_FORCE_DEFAULT_DEVICE, and this seems to be required if if the output from steam says it selected the correct gpu.

As a workaround, it works I guess.

MMikilio 2025-06-03 github

This definitely doesn't work on my case, but my setup looks different anyway. I will create another issue if a commit closing this one doesn't solve mine.

EEckoa 2025-08-12 github

Ive found that installing vulkan-mesa-layers and lib32-vulkan-mesa-layers lets DRI_PRIME properly set the primary GPU for steam BUT steam webhelper refuses to leave the Nvidia dGPU alone in my laptop and any combination of launch options just leads to steam webhelper telling me im not its dad and itll do as it wants.

This effectively doubles my power draw any time steam is running (from 30ish watts to 55-60w) which is just plain stupid. This also happened on my previous all AMD system so its not specific to the nvidia drivers and this happens with webkit browsers like Epiphany and on default happens with Chromium but unlike steam chromium gives you a choice and lets you force a GPU target. The real issue is that Steam is a fat CEF monster and unfortunately we have no way to step around it or use a lighter weight GUI as it got removed.

EDIT: just thought, a sorta workaround would be to use Lutris as your UI and only run steam when launching a game. This is been an issue with steam for at least 10yrs on not just Linux but Windows too so we arent treading new territory here.

DDaxAvalon 2026-10-07 github

I had a similar issue:

Summary: winex11: under Xwayland with zero XRandR providers, the faked GPU is bound to the first Vulkan device instead of the GPU driving the display, so all monitors land on a display-less GPU

Component: winex11.drv (fallback lives in win32u/sysparams.c)
Version: 11.0 (observed on Wine 11.0 staging as shipped in GE-Proton11-7; fallback code
confirmed present in upstream wine-11.0 source)
Platform: x86_64 Linux, Pop!_OS 24.04, COSMIC on Wayland, Xwayland

Hardware: two discrete GPUs. NVIDIA GeForce RTX 3080 Ti (01:00.0, nvidia 580.173.02) drives all
four monitors. AMD Radeon Pro Vega 20 (07:00.0, RADV, Mesa 26.1.6) has six DisplayPort
connectors, all disconnected. Xwayland runs on the NVIDIA device.

Symptom: D3D11 and D3D12 applications through DXVK render on the Vega and present fails every
frame (DXGI Present returns 0x80004005), giving a black window with working audio and cursor.
The application's own log shows it chose the Vega because DXVK reports every monitor attached
to that adapter and none to the NVIDIA adapter. Applications that select a GPU by name work.

Cause (from WINEDEBUG=+system,+xrandr during wineboot):
warn:xrandr:xrandr14_get_gpus XRandR implementation doesn't report any providers, faking one.
trace:system:add_gpu (null) 0000 0000 00000000 00 {00000000-0000-0000-0000-000000000000}
warn:system:find_gpu_info Using GPU pci_id 0x1002:0x66a0, uuid {00000000-0007-0000-0000-000000000000}, name "AMD Radeon Graphics (RADV VEGA20)"
trace:system:add_monitor 0 (0,0)-(3840,1080) ... (x4, all on this GPU)
trace:system:commit_display_devices adding vulkan-only gpu uuid {54a0c70c-...}, name "NVIDIA GeForce RTX 3080 Ti"

xrandr --listproviders reports 0 providers under Xwayland, so winex11 fakes a GPU with no
name, PCI ID, or UUID. In win32u add_gpu, find_gpu_info finds no UUID or PCI match and falls
back to list_head(&ctx->vulkan_gpus), which is the Vega. All monitors are attached to it. The
NVIDIA GPU is added afterward as a vulkan-only GPU with no monitors. Any D3D app using the
"adapter with outputs" heuristic therefore picks a GPU that cannot present.

Expected: when the display driver cannot identify the GPU, the fallback should prefer the
Vulkan device that can present to the display (e.g. match the DRM device Xwayland uses via
DRI3, or prefer the device that supports presentation to the surface), not the first
enumerated device.

Environment experiments (fresh prefixes, Wine GPU order read from the Display class registry keys):

  • no DRI_PRIME: AMD 0000, NVIDIA 0001
  • NODEVICE_SELECT=1: unchanged
  • __VK_LAYER_NV_optimus=NVIDIA_only: unchanged
  • MESA_VK_DEVICE_SELECT=10de:2208 (non-exclusive): unchanged
  • MESA_VK_DEVICE_SELECT=10de:2208! (exclusive): NVIDIA becomes 0000, monitors attach to it,
    apps render correctly. Only working workaround short of setting a GPU name per application.

Regression note: on Wine 10.0 (Proton 10, April 2026) DXVK listed the monitors under both
adapters, so name-based selection worked and the auto heuristic was less harmful. On Wine 11.0
the monitors appear only under the Vega.