Summary

EVE Frontier (CCP, alpha, Trinity engine) loses the Vulkan device with VK_ERROR_DEVICE_LOST shortly after pipeline-state-object setup on RTX 5090 / driver 595.71.05. Kernel-side: Xid 109 CTX SWITCH TIMEOUT on exefile.exe, hitting both the graphics queue (channel 0x24, Info 0x5c02c) and the compute queue (channel 0x25, Info 0x5c03a).

vkd3d-proton already has a per-binary workaround entry for this exe (hash 9fc0db2b525692fd, applies config 0x10000000), but it's insufficient — the device-lost reproduces with that internal workaround active, and with every VKD3D_CONFIG / VKD3D_DISABLE_EXTENSIONS permutation that helps related Blackwell games like Crimson Desert.

Reproducer

1. Install EVE Frontier via Lutris on Blackwell (Linux kernel 7.0.8 cachyos, NVIDIA proprietary 595.71.05).
2. Launch through proton-cachyos-11.0-20260506-slr-x86_64 (or GE-Proton10-34 — both fail identically).
3. Log in via the Electron launcher → pick character.
4. Engine takes over → black screen → exefile.exe pegged at ~100% CPU on one thread (WCHAN ntsync_schedule); GPU idle; ~7 GB VRAM allocated.
5. Within ~40 s of vkd3d_config_flags_init_once, the device is lost.

System

• GPU: NVIDIA GeForce RTX 5090 (10de:2b85 10de:2057)
• Driver: 595.71.05 (proprietary)
• Kernel: 7.0.8-1-cachyos-bore
• Distro: CachyOS (Arch-based)
• Proton: proton-cachyos-11.0-20260506-slr-x86_64
• Compositor: Hyprland (Wayland)

Friends on Ampere (RTX 30-series) NVIDIA and on full-AMD systems report EVE Frontier works without intervention. The fault is Blackwell-specific.

VKD3D log excerpts

Two attached:

• steam-default.log.txt — bare env, only PROTON_LOG=1 set.
• steam-default.log.prev-attempts.txt — same session earlier in the day, with the descriptor_heap / experimental_features / single_queue / force_raw_va_cbv stack plus VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id, VK_KHR_present_wait,VK_EXT_mesh_shader,VK_NV_raw_access_chains.

steam-default.log.prev-attempts.txt
steam-default.log.txt

Key lines (bare env run):

info:vkd3d-proton:vkd3d_instance_apply_application_workarounds: Program name: "exefile.exe" (hash: 9fc0db2b525692fd)
info:vkd3d-proton:vkd3d_instance_apply_application_workarounds: Detected game exefile.exe, adding config 0x10000000, removing masks 0x0.
info:vkd3d-proton:vkd3d_config_flags_init_once: VKD3D_CONFIG=''.
...
err :vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore: Failed to wait for Vulkan timeline semaphore, vr -4.
warn:vkd3d-proton:d3d12_device_mark_as_removed: Device is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").

(Repeated 6× as the engine retries.)

Kernel log

NVRM: Xid (PCI:0000:01:00): 109, pid=..., name=exefile.exe,
channel 0x00000024, errorString CTX SWITCH TIMEOUT, Info 0x5c02c
NVRM: Xid (PCI:0000:01:00): 109, pid=..., name=exefile.exe,
channel 0x00000025, errorString CTX SWITCH TIMEOUT, Info 0x5c03a

Channel 0x24 / Info 0x5c02c — graphics queue, ~7 events per session.
Channel 0x25 / Info 0x5c03a — compute queue, ~2 events per session.

A/B: with flags vs. bare

The flag stack changes VKD3D's translation behavior (e.g. eliminates the descriptor-pressure fallback path) but does not affect the device-lost timing, count, or error code. The crash-triggering Vulkan submission is unchanged either way — i.e. the bug is below the layer VKD3D_CONFIG can influence.

User-side mitigations tried, none successful

• VKD3D_CONFIG=force_raw_va_cbv,descriptor_heap,enable_experimental_features,single_queue
• PROTON_VKD3D_HEAP=1
• VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id,VK_KHR_present_wait,VK_EXT_mesh_shader,VK_NV_raw_access_chains
• WINEESYNC=0, WINEFSYNC=0
• GPU clock cap (nvidia-smi -lgc 0,2400) — confirms this is not a clock-state transition fault
• Both GE-Proton (10-34) and proton-cachyos (11.0-20260506) — identical failure mode
• DX11 force via prefs.ini — EVE Frontier is DX12-only (its launcher app.asar enumerates only dx0 and dx12 as DirectX dropdown values)

Note for triage

vkd3d-proton already recognizes this exe and applies an internal workaround — that suggests the project is aware of the engine, but the current workaround doesn't cover Blackwell's Xid 109 path for Trinity. Crimson Desert hits Xid 109 on the same hardware and is cured by VKD3D_CONFIG=descriptor_heap,enable_experimental_features (VK_EXT_descriptor_heap path); the same flags applied here have no effect on the device-lost. So Trinity's sub-flavor of Xid 109 has a different trigger than Crimson Desert's.

Happy to capture additional diagnostic output on request (VKD3D_DEBUG=warn, RenderDoc/GfxReconstruct captures, specific extension toggles).