protonscr

EVE Online: VRAM/RSS not released after undocking ship with DX12 (accumulates over multiple dock cycles), DX11 unaffected

vkd3dopen
HansKristian-Work/vkd3d-proton#3250 · opened 2026-08-30 by RedAdair2026 · updated 2026-08-31 · 1 comments · github
RRedAdair2026 2026-08-30 github

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

  • OS: CachyOS Linux, kernel 7.2.2-1-cachyos
  • GPU: NVIDIA GeForce RTX 5070 Laptop GPU (hybrid/PRIME setup with AMD Radeon 880M iGPU, __NV_PRIME_RENDER_OFFLOAD=1)
  • NVIDIA driver: 610.57.04 (proprietary), Vulkan driverVersion 610.57.4.0
  • Proton: proton-cachyos-11.0-20260703-slr (Steam Linux Runtime / Steam Play)
  • vkd3d-proton: applicationVersion 3.1.0, build 3dfc6f07d0953b1
  • Game: EVE Online, client app-1.16.1
  • Launch options used: PROTON_LOG=1 PROTON_USE_NTSYNC=1 VKD3D_DEBUG=fixme,warn %command%

Steps to reproduce

  1. Launch EVE Online with DirectX 12 selected, log in, dock at a station.
  2. Note baseline VRAM/RAM usage (see table).
  3. Undock the ship (triggers station → open space transition).
  4. Observe VRAM and RAM usage spike, GPU load pinned at 100%, framerate collapses (observed as low as 0.15 fps / 6.6s frametime for tens of seconds before recovering).
  5. Dock again. Framerate and GPU load return to normal, but VRAM/RAM usage does not drop back to baseline.
  6. Repeat steps 3–5. Each cycle adds further residual VRAM/RAM on top of the previous cycle's residue.

Observed data (via btop, per dock cycle, DX12)

State VRAM (GPU) exefile.exe RSS GPU load FPS
Docked (session baseline) 1.0G / 7.0G 2.0G 35–37% 60
Undocked (cycle 1) 5.0–6.0G / 7.0G 7.0G 100% as low as 0.15
Redocked (cycle 1) 5.0G (unchanged) 7.0G (unchanged) 36% (normal) 60 (normal)
Docked, before cycle 3 (residual from cycle 1/2) 5.0G / 7.0G 7.0G 35% 60
Undocked (cycle 3) 6.0G / 7.0G 8.0G 100% —

GPU 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):

State VRAM exefile.exe RSS GPU load
Undocked, DX12 5.0–6.0G / 7.0G 7.0–8.0G 100%
Undocked, DX11 2.0G / 7.0G 3.0G 40%

Under 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, no err:, memory/allocation warnings, or DXGI errors appear around the undock event — only routine info:-level device/pipeline-cache messages and unrelated Wine UIAutomation stub noise. The default (no VKD3D_DEBUG) run shows a high-frequency but apparently benign warn: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.

Ddoitsujin maintainer 2026-08-31 github

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.

Launch options

Launch lines