Please attach a log, it's way more useful than 90% of the LLM vomit.
Do we know for sure that this isn't just a game bug (i.e. is there solid evidence that this doesn't happen on Windows)? Memory management is the app's responsibility in D3D12, the only time we'd "leak" anything is if the app uses literally nothing but committed resources in very unfortunate ways and that's basically unfixable.
Update with the requested log, plus follow-up evidence that points away from vkd3d-proton and toward the NVIDIA driver.
Cross-platform reproduction (rules out distro/Proton-build as the cause):
Reproduced the identical pattern on a second, independent stack: Fedora 44 (KDE/Wayland) + GE-Proton11-6 with the native winewayland.drv (PROTON_ENABLE_WAYLAND=1), instead of the original CachyOS + cachyos-11.0 Proton build. Same NVIDIA driver (610.57.04) both times. Undock again produced the same signature:
| Docked (baseline) | Peak during/after undock | |
|---|---|---|
| GPU utilization | ~72% | 100% |
| GPU VRAM (total) | ~1.4 GB | ~5.9-6.0 GB |
| Client RSS (RAM) | ~3.0 GB | ~7.6-8.2 GB |
Matches the original CachyOS numbers closely. Since OS, compositor, and Proton/vkd3d-proton build all changed between the two tests and the behavior didn't, the common factor left is the NVIDIA driver (and/or the game itself, see below).
Requested log attached: steam-8500.log from this Fedora run, VKD3D_DEBUG=trace PROTON_LOG=1, SSO/refresh tokens redacted. No err:/warn: lines correlate with the actual VRAM growth window — whatever's allocating memory during undock is below vkd3d-proton's own logging threshold.
New finding — real driver-level faults (Xid) during testing, not just app-level behavior:
Checked the kernel log (journalctl -k) across both test sessions and found genuine NVIDIA Xid errors, i.e. actual GPU/driver faults, not just high memory/utilization numbers:
Xid 109 pid=<exefile.exe> CTX SWITCH TIMEOUT (during the DX12 game client itself)
Xid 69 pid=<eve-online.exe> Class Error, ErrorCode 0xa4 (x3, during the Electron launcher's own GPU process, unrelated to vkd3d-proton)
Xid 109 (context switch timeout) on the actual DX12 client is the more relevant one for this issue — it's a real GPU hang signal, not just elevated memory. It lines up with the Presenter: Got VK_ERROR_DEVICE_LOST, recreating swapchain we already see in the trace log. Working hypothesis (not confirmed): a driver-side hang/timeout forces a device/swapchain recreation, and whatever resources belonged to the pre-crash context aren't released — which would look exactly like an accumulating "leak" that only a full client restart clears, without vkd3d-proton or the game mismanaging D3D12 resources in the normal sense.
The Xid 69 hits are on the launcher's own Chromium/Electron GPU process (not DX12/vkd3d-proton at all), so I'm not folding those into the same theory — flagging them only because they show the driver is generally less stable under this Wine-Wayland setup right now, on unrelated rendering paths too.
Full nvidia-bug-report.sh output (kernel log, module state, GPU info) from this session is attached alongside the trace log: https://gist.github.com/RedAdair2026/67bd11af1f298c297674615a85d2baea
Windows comparison: still can't provide this — no Windows install available to test against. Flagging as an open gap rather than claiming it's covered.
Where this leaves it: given the Xid evidence, I now suspect this sits on the NVIDIA driver side rather than in vkd3d-proton itself. Happy for you to close this on your end if you agree — I'll follow up separately via the NVIDIA Linux driver forum/bug report channel with the same data. Thanks for looking at it either way.
ge-proton11-6x1 2026-09PROTON_LOG=1x2 2026-09PROTON_ENABLE_WAYLAND=1`)x1 2026-09VKD3D_DEBUG=tracex1 2026-09PROTON_USE_NTSYNC=1x1 2026-08VKD3D_DEBUGx1 2026-08VKD3D_DEBUG=fixme,warnx1 2026-08
Summary
VRAM and host RAM allocated by EVE Online's DX12 client (
exefile.exe) grow sharply when undocking the player's ship (station interior → open space scene transition), and are never released afterwards — not even after redocking back to the station. The leak accumulates further with every additional undock/dock cycle, and only a full client restart clears it. A DX11 control test on the same hardware/session does not reproduce the issue, pointing at the DX12/vkd3d-proton path specifically.Environment
__NV_PRIME_RENDER_OFFLOAD=1)PROTON_LOG=1 PROTON_USE_NTSYNC=1 VKD3D_DEBUG=fixme,warn %command%Steps to reproduce
Observed data (via btop, per dock cycle, DX12)
exefile.exeRSSGPU load and framerate fully recover on redock; VRAM and process RSS do not.
DirectX 11 control test
For comparison, the same undock action was tested with DirectX 11 selected instead of DX12 (fresh client restart):
exefile.exeRSSUnder DX11, the same station→open-space transition does not produce the pathological GPU load or VRAM spike. This suggests the issue is specific to the DX12/vkd3d-proton rendering path rather than EVE's undock logic in general.
Log observations
With
VKD3D_DEBUG=fixme,warn, noerr:, memory/allocation warnings, or DXGI errors appear around the undock event — only routineinfo:-level device/pipeline-cache messages and unrelated Wine UIAutomation stub noise. The default (no VKD3D_DEBUG) run shows a high-frequency but apparently benignwarn:vkd3d-proton:d3d12_resource_QueryInterface: {6b3b2502-6e51-45b3-90ee-9884265e8df3} not implemented, returning E_NOINTERFACE.during undocked/high-load periods — unclear if related.Expected behavior
VRAM and RSS allocated for the open-space scene should be released (or at least trend back toward baseline) once the ship redocks and the station-interior scene is active again.