protonscr

Massive GPU-bound FPS drop (~20 FPS) in EVE Online DX12 new UI windows

vkd3dopen
HansKristian-Work/vkd3d-proton#3108 · opened 2026-06-16 by copyliu · updated 2026-06-18 · 2 comments · github
Ccopyliu 2026-06-16 github

https://github.com/user-attachments/assets/c23471cb-4ae8-423b-a1cb-7ea0003b4811

Software information

EVE Online (CCP, Carbon engine), DX12 mode. The issue triggers when opening certain new-UI-engine (Photon-UI) windows (e.g., character sheet, starmap, etc.). In-game shader quality LOW works around the issue; medium or higher reproduces it. Reverting vkd3d-proton to v2.11 also eliminates the problem.

System information

  • GPU: GeForce RTX 5060Ti
  • Driver: 595.80
  • Wine version: Proton Experimental 11.0 (wine-proton-exp-11.0-amd64) / also tested with vanilla Wine builds
  • VKD3D-Proton version: v2.12 and later (v2.11 is GOOD)

Log files

Root cause (bisected with AI assistance)

I bisected the 175 commits between v2.11 and v2.12 using binary search, with builds compiled by my AI assistant (Hermes Agent). The trigger commit is:

6fe77929 — "vkd3d-shader: Fix maximum ICB size" (Philip Rebohle, 2024-01-29)

This commit corrected MAX_IMMEDIATE_CONSTANT_BUFFER_SIZE from 4096 dwords to 16384 dwords (the correct D3D12 spec limit: 4096 vec4 × 4).

Before the fix (v2.11):
EVE loads a compute shader (SM 5.1) with an ICB of 10096 dwords (2524 vec4). The old limit rejects it:

Unexpected immediate constant buffer size 10096.
Encountered unrecognized or invalid instruction.
Failed to compile shader, vkd3d result -3.

EVE silently falls back to an alternative shader path → normal performance.

After the fix (v2.12+):
The same shader's 10096-dword ICB is now accepted, but the generated SPIR-V is catastrophically inefficient. The ICB is placed in Private storage class as a 2524-element OpConstantComposite initializer:

%icb = OpVariable %_ptr_Private__arr_v4float_uint_2524 Private %11820

Each thread gets its own copy. With 64 threads/workgroup (the shader uses LocalSize 64 1 1), that's ~2.58 MB of private memory per workgroup, all spilling to VRAM. This saturates GPU memory bandwidth and causes the observed FPS collapse (100+ → ~20 FPS, GPU 100%).

Why this matters beyond EVE

The 6fe77929 fix is correct for D3D12 spec compliance. The bug is that vkd3d-shader's codegen for large ICBs is pathologically inefficient — it should place ICB data in a Uniform Buffer or StorageBuffer rather than per-thread Private memory when the ICB exceeds a reasonable threshold (e.g., >256 vec4). Other games with large ICB compute shaders are likely affected but may not trigger the shader frequently enough for users to notice.

Ddoitsujin maintainer 2026-06-16 github

If the ICB is the issue (which I can certainly believe, DXVK has had issues in that area as well on Nvidia) then that should really be promoted to a buffer at a driver level; especially with all the recent binding model reworks we basically have no viable way to pass in an extra buffer address.

Mesa drivers already do this FWIW.

HHansKristian-Work maintainer 2026-06-18 github

We cannot easily do this due to binding model issues in D3D12. This has to be fixed by their driver.

Proton versions