isNvidia() false negative on hybrid laptops under proton + dxvk-nvapi (DLSS disabled, explicit DLSS.Enabled=true ignored) #1175

New issue

Open

opened 2026-09-24 00:40:21 +00:00 by reichembach · 0 comments

reichembach commented

2026-09-24 00:40:21 +00:00

(Migrated from github.com)

Environment

OptiScaler v0.9.4-final (7534ad0) as winmm.dll (manual install); a nightly (github.com/optiscaler/OptiScaler-nightly@c62a170f45) behaves the same
Final Fantasy XIV (DX11) on Linux (CachyOS), Proton-Wineland 20260922 with native Wayland
RTX 3050 Laptop + Intel UHD (TGL GT1), KDE Plasma Wayland, NVIDIA 615.71.09

Problem

Optiscaler disables DLSS even though the game renders on the RTX:

isNvidia Using dxvk-nvapi
isNvidia Detected: false
Not running on Nvidia, disabling DLSS

Downstream effects: OverrideNvapiDll gets set to true, DXGI spoofing stays on, and DLSS.Enabled=true in the ini has no effect, because it is only honored when detection succeeds.

Cause

In the dxvk-nvapi branch, isNvidia() (dllmain.cpp, same logic as isNvidiaViaNvapi on master) loops EnumDisplayDevicesA(NULL, i) and requires DISPLAY_DEVICE_ACTIVE plus VEN_10DE in DeviceID. That tests which GPU the displays are attached to, not which GPU renders.

On Wine, the DeviceID of each adapter is the PCI path of the GPU its display source was attached to, and that GPU comes from the window driver. Proton-Wineland's Wayland driver (since 915c504, "winewayland.drv: Identify the compositor GPU") passes the compositor's GPU to Wine, while Proton-CachyOS with Wayland does not. WINEDEBUG=warn+system,trace+system, same prefix and launch options, Wayland enabled in both:

wineland-11.0-20260922:
  add_gpu (null) 8086 9A68 00000000 00 (null)
  commit_display_devices adding vulkan-only gpu ... "NVIDIA GeForce RTX 3050 Laptop GPU"

cachyos-11.0-20260703-slr (PROTON_ENABLE_WAYLAND=1):
  add_gpu (null) 0000 0000 00000000 00 (null)
  find_gpu_info Using GPU pci_id 0x10de:0x25a2 ... "NVIDIA GeForce RTX 3050 Laptop GPU"
  commit_display_devices adding vulkan-only gpu ... "Intel(R) UHD Graphics (TGL GT1)"

Proton-CachyOS: the driver gives Wine no GPU identity (0000 0000). Wine then falls back to the first entry of its Vulkan GPU list, which it sorts with discrete GPUs first. That picks the RTX, and the displays attach to it. Intel is added afterwards with no display.
Wineland: the driver passes Intel's PCI ID (8086 9A68) because KWin runs on the Intel iGPU. The displays attach to Intel, and the RTX is only added afterwards as a GPU with no display.

So on Wineland EnumDisplayDevicesA returns two adapters, both PCI\VEN_8086&DEV_9A68, and no VEN_10DE is ever seen. Wine still knows about the RTX, and Optiscaler's own DXGI hook logs it with vendor 0x10de shortly after, but that information isn't available inside DllMain where isNvidia() runs.

The same setup works on Wineland with Wayland disabled (that driver also passes no ID, so the fallback picks the RTX) and on Proton-CachyOS with Wayland.

Suggestions

Respect an explicit DLSS.Enabled=true, so users can override a wrong detection. That's a small change with low risk.
Where possible, detect any Nvidia GPU visible to the process (for example DXGI or Vulkan vendor ID 0x10DE, checked lazily after DllMain) instead of only display-attached adapters. PRIME offload setups are common, and there the display GPU and rendering GPU differ by design.

I also reported this on proton-wineland since I initially thought it was an issue with that, but informing the compositor's gpu isn't really wrong behavior. I know it's not really a big issue, especially considering it's a linux problem on hybrid laptops, and there a few things I can do to get it working (running a different proton,disabling wayland or having the compositor run on my dgpu), but I'd be nice if I could get it running on this specific setup. I really like how proton-wineland is handling wayland related things lately.

I'll be happy to test patches if it ever gets to that.

Disclaimer: I relied heavily on Claude to test/troubleshoot my issues as I couldn't find anything about this, so I'm also posting their results mostly as is since I would not be able to explain this properly. This problem is the result of an unfortunate coincidence of how Optiscaler and proton-wineland work. --- **Environment** - OptiScaler v0.9.4-final (7534ad0) as `winmm.dll` (manual install); a nightly (https://github.com/optiscaler/OptiScaler-nightly/commit/c62a170f45ebaa4a466a81dd5d0ecedc168f302c) behaves the same - Final Fantasy XIV (DX11) on Linux (CachyOS), Proton-Wineland 20260922 with native Wayland - RTX 3050 Laptop + Intel UHD (TGL GT1), KDE Plasma Wayland, NVIDIA 615.71.09 **Problem** Optiscaler disables DLSS even though the game renders on the RTX: ``` isNvidia Using dxvk-nvapi isNvidia Detected: false Not running on Nvidia, disabling DLSS ``` Downstream effects: `OverrideNvapiDll` gets set to true, DXGI spoofing stays on, and `DLSS.Enabled=true` in the ini has no effect, because it is only honored when detection succeeds. **Cause** In the dxvk-nvapi branch, `isNvidia()` (`dllmain.cpp`, same logic as `isNvidiaViaNvapi` on master) loops `EnumDisplayDevicesA(NULL, i)` and requires `DISPLAY_DEVICE_ACTIVE` plus `VEN_10DE` in `DeviceID`. That tests which GPU the displays are attached to, not which GPU renders. On Wine, the `DeviceID` of each adapter is the PCI path of the GPU its display source was attached to, and that GPU comes from the window driver. Proton-Wineland's Wayland driver (since `915c504`, "winewayland.drv: Identify the compositor GPU") passes the compositor's GPU to Wine, while Proton-CachyOS with Wayland does not. `WINEDEBUG=warn+system,trace+system`, same prefix and launch options, Wayland enabled in both: ``` wineland-11.0-20260922: add_gpu (null) 8086 9A68 00000000 00 (null) commit_display_devices adding vulkan-only gpu ... "NVIDIA GeForce RTX 3050 Laptop GPU" cachyos-11.0-20260703-slr (PROTON_ENABLE_WAYLAND=1): add_gpu (null) 0000 0000 00000000 00 (null) find_gpu_info Using GPU pci_id 0x10de:0x25a2 ... "NVIDIA GeForce RTX 3050 Laptop GPU" commit_display_devices adding vulkan-only gpu ... "Intel(R) UHD Graphics (TGL GT1)" ``` - **Proton-CachyOS:** the driver gives Wine no GPU identity (`0000 0000`). Wine then falls back to the first entry of its Vulkan GPU list, which it sorts with discrete GPUs first. That picks the RTX, and the displays attach to it. Intel is added afterwards with no display. - **Wineland:** the driver passes Intel's PCI ID (`8086 9A68`) because KWin runs on the Intel iGPU. The displays attach to Intel, and the RTX is only added afterwards as a GPU with no display. So on Wineland `EnumDisplayDevicesA` returns two adapters, both `PCI\VEN_8086&DEV_9A68`, and no `VEN_10DE` is ever seen. Wine still knows about the RTX, and Optiscaler's own DXGI hook logs it with vendor `0x10de` shortly after, but that information isn't available inside `DllMain` where `isNvidia()` runs. The same setup works on Wineland with Wayland disabled (that driver also passes no ID, so the fallback picks the RTX) and on Proton-CachyOS with Wayland. **Suggestions** 1. Respect an explicit `DLSS.Enabled=true`, so users can override a wrong detection. That's a small change with low risk. 2. Where possible, detect any Nvidia GPU visible to the process (for example DXGI or Vulkan vendor ID `0x10DE`, checked lazily after `DllMain`) instead of only display-attached adapters. PRIME offload setups are common, and there the display GPU and rendering GPU differ by design. --- I also reported this on proton-wineland since I initially thought it was an issue with that, but informing the compositor's gpu isn't really wrong behavior. I know it's not really a big issue, especially considering it's a linux problem on hybrid laptops, and there a few things I can do to get it working (running a different proton,disabling wayland or having the compositor run on my dgpu), but I'd be nice if I could get it running on this specific setup. I really like how proton-wineland is handling wayland related things lately. I'll be happy to test patches if it ever gets to that.