Vidmem heap 1 memory leak
I went here for a video memory leak as well, but I'm using a GTX970.
When I disable "ForceCompositionPipeline" and disable VSYNC it work as expected (<2Gb VRAM used and high FPS). VSYNC doesn't seem to sync at all when enabled.
When I enable the composition pipeline, to reduce tearing, video memory slowly creeps up to 4Gb and FPS chugs to sub 20 territory.
I've noticed this while playing Planet Coaster for extended periods of time, with compositing enabled the game becomes unplayable within an hour and with it disabled it stays playable.
This is not a leak, DXVK oversubscribes memory heaps by design when it can.
What you're seeing here is address space exhaustion, which happens in all 32-bit games. See #1318 for details. Note that since you're not using Proton or wine-staging, you'd have to patch the executable to enable Large Address Awareness.
Alternatively, set d3d9.evictManagedOnUnlock = True in dxvk.conf.
Just for information, the dxvk.conf alternative didn't work on the main screen, but in game it make it last long, if you pass the main screen quickly, the amount of memory used on Vidmem heap 1 remain stable for a long period.
Video (with dxvk.conf): DXVK 1.5.5 memory bug with TOS 2.0
Video (without dxvk.conf): DXVK 1.5.5 memory bug with TOS 2.1
However if I stay waiting in the main screen, doesn't matter with or without dxvk.conf the result is still the same as reported.
I will try Wine staging later.
TL;TR:
It seems not to be related to 32-bits games and indeed being a DXVK bug.
The long history:
I was going to try wine-staging but during my research I realised it won't be enough, even the official binaries provided by winehq doesn't allow this behaviour by default, it would require me to build it from source with some flags, before trying it I decided to try patching the game first, but for my surprise the patched game had exact the same md5sum, so I went to investigate and in fact the game alread had the flag.
Evidences:
Image:
Log: objdump.txt
Apitrace: Client_tos.trace.xz (28,6 MiB original 104,7 MiB) with DXVK on main screen
Yes it absolutely is related to 32-bit games. It's unfortunate that this happens here even though the game already does use LAA, but you're still running out of address space, which basically cannot happen in 64-bit applications.
We are aware that DXVK uses more (virtual) memory than wined3d, but this is not a bug and not something that we can easily fix.
I understand you are not being paid for supporting it and have no commitment to do anything, but for me it is clear that memory is leaking somewhere, if you see the videos and the trace you will notice that is happening nothing that would require a huge amount of memory, maybe the game is bad-designed, but if it works on Windows and on wine's d3d9 it is clear for me that dxvk should expect this bad behaviour as well.
I guess it may be drawing the same resource several times and the original d3d9 understand it is the same and don't over-allocate the same memory again and again while dxvk does.
If you allow me I will investigate it by myself, although I have no experience with DirectX I will try.
Launch options
DXVK_HUD=memoryx1 2020-03DXVK_LOG_LEVEL=debugx1 2020-03WINEARCH=win32x1 2020-03WINEDEBUG=-allx1 2020-03WINE_LARGE_ADDRESS_AWARE=1x1 2020-03
Software information
Tree of Savior, only happens with DXVK.
System information
Environment
Log files
Description
In some extent the memory consumption of Vidmem heap 1 will surpass 100% and once it is near 400% the game breaks, but it works plainly without DXVK.
Evidences
Image: DXVK 1.5.5 memory bug with TOS
Video: DXVK 1.5.5 memory bug with TOS