This isn't really fixable on the DXVK side anymore. Games need to fucking stop trying to put >30GB of resources into VRAM, we already do pretty much everything we can to deal with overcommit, but there's a point where this just stops being reasonable.
Also I don't think nogttspill is available in Mesa 25.1, and your apitrace link is locked.
You can try disabling memory defrag by setting DXVK_CONFIG="dxvk.enableMemoryDefrag=False" and see if that helps, but there's likely going to be massive perf issues too if it hits resources that AMDGPU itself puts into system memory. The current default behaviour is known to not work properly without working nogttspill.
Thanks for the response, I'll give that launch option a try later when I get the chance.
The apitrace link should be public now if you want to take a look- didn't know it was set on private.
EDIT: DXVK_CONFIG="dxvk.enableMemoryDefrag=False" this sadly does not work
This isn't really fixable on the DXVK side anymore.
The current default behaviour is known to not work properly without workingnogttspill.
@doitsujin just to clarify then, should I think about forwarding this towards the mesa repo or do you think that it wouldn't be of any help?
This isn't solvable in mesa either. I haven't looked at the trace yet, but it's just not possible to make every stupid thing that games do work well.
Having the same issue
Had the same issue, falling back to WineD3D with PROTON_USE_WINED3D=1 seems to work for me.
Got an Rx 6600 and this issue has been persistent for a long time on another AMD card and distro.
It's not ideal but brings it from unplayable (< 3 fps) back to very playable fps (>30 fps) with all the graphics mods available + Volumetric Clouds V5 + Sol 16k, although it has percievably less fps than on Windows which sat at around 40 fps.
It does appear to consume considerable RAM aswell, but much less than the broken native version of KSP.
Yes, everyone is going to have that issue, adding more comments isn't going to make this any more fixable inside DXVK.
Memory management stuff is being worked on on the kernel side of things, but will likely take months to materialize on stable and even longer to make it into any sort of distro. And even then there's no guarantee that it'll work well because, as it turns out, loading 20 GB of resources into 8 GB of VRAM is just not a great idea.
Yes, everyone is going to have that issue, adding more comments isn't going to make this any more fixable inside DXVK.
Indeed, so just leaving the quick tape fix here, just in case.
I'm having this same issue too? I'm pretty sure KSP shouldn't be eating 5.5 GB of VRAM on its own on the title screen... no i don't have any graphics mods other than deferred installed. Yes, I'm using wined3d, yes I'm using proton experimental.
EDIT: NVIDIA RTX 4060 as a gpu if that hurts or helps in any way.
proton experimentalx1 2026-06PROTON_USE_WINED3D=1`x1 2026-05DXVK_CONFIG="dxvk.enableMemoryDefrag=False"x2 2025-08PROTON_ENABLE_WAYLAND=1`x1 2025-08RADV_PERFTEST=nogttspill`x1 2025-08
Some mod packs like Realism Overhaul and RSS/Sol need an excessive amount of both DRAM and VRAM due to the way that KSP handles planetary texturing and loading of other elements such as parts and scenes. Since about maybe 2 months ago, my primary Kerbal Space Program RO/Sol modpack went from a stable ~150FPS to ~15 FPS on the main menu. Reducing memory load fixes the frame drops but at the cost of really bad looking textures due to down-scaling (especially on my hardware which should be able to handle the graphics).
In Windows and OpenGL (WINED3D/Native) there are no observable frame-drops. However DXVK remains the only long-term solution as KSP's native build is shockingly outdated and WINED3D has significant graphical glitches and memory leaks.
This GTT memory overspill causes some strange framerate effects when at specific distances from certain celestials as shown in the video below.
https://github.com/user-attachments/assets/d8aeab8b-36a7-42c9-be5b-d6e91ea0df3a
I had initially thought this to be a problem with the mods themselves but I can also observe the problem across multiple installs, and after consulting the creators of significant mods this appears to be a DXVK issue.
I have created multiple "sandboxed" modded installs where I load a minimal amount of mods, and each time I found that framerate drops were directly linked to overflowing VRAM and using GTT memory, no matter the mod pack used.
Attempted to use various launch args such as
PROTON_ENABLE_WAYLAND=1RADV_PERFTEST=nogttspillto no successAttempted switching to amdvlk to no success
Software information
Kerbal Space Program 1.12.5.3190. Example modpacks include - Realism Overhaul + Real Solar System/Sol - Interstellar packs such as Kcalbeloh in tandem with stock system replacement mods. Parallax-Continued also contributes greatly to VRAM costs
I am directly launching the game by pointing steam to the .exe file and not going through the PDLauncher.
My RO/RSS modpack settings.cfg file attached:
settings.cfg.zip
System information
Apitrace file(s)
Will post a link in a comment as soon as it's uploaded to google drive
Log files
Relevant KSP.log, Player.log, Proton log and d3d11/dxgi logs attached. (Please note that these logs are not from the same run as the apitrace due to a launch arg mistake on my end - however they should still be very similar)
logs.tar.gz