dxvk: DXVK takes large portions of RAM and never frees them, causing system freezes
I have noticed that when playing games using DXVK the amount of RAM memory available to the system slowly reduces. Initially the value is not significant, but in longer sessions (2 hours, for example), the amount of RAM taken is significant, as 1,3 GB.
This RAM memory is never freed, reducing the available memory for the entire system. Once DiRT 3 Complete Edition took 5,2 GB of RAM from the system, and I had to use the computer with only 2,5 GB usable (before I discovered what the problem was).
Even longer session take all RAM memory and the system freezes, sometimes with INFO messages in dmesg, sometimes with a General Protection Fault. The messages are only readable on the next boot.
One strange thing is that the memory is shown as “free” on htop
, so while it shows a large amount of free memory the system swaps until it freezes. The screenshot below shows htop
when the system froze with all memory used while playing DiRT 3 Complete Edition. Notice The large amount of memory “free” as cache (the yellow):
Software information
Two games were tested: DiRT 3 Complete Edition (using Steam Play) Forsaken Castle (Win64 build, using Wine 3.15 and DXVK git-e48c27ac30ee92df6f378a11030fd1ee980d0017)
System information
- GPU: Intel HD Graphics 520
- Driver: Mesa 18.3.0-devel (git-07a2098a70)
- Wine version: Proton 3.7 and Wine 3.15
- DXVK version: v0.70-16-g07b4d3c and git-e48c27ac30ee92df6f378a11030fd1ee980d0017
Log files
-
d3d11.log: Forsaken_Castle_d3d11.log
-
dxgi.log:
Forsaken_Castle_dxgi.log
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 54 (27 by maintainers)
I’ve submitted the kernel patch to the mailing list. Hopefully, it will land fairly soon and we’ll make sure it gets back-ported as far as needed.
Jason Ekstrand wrote a fix for the issue. It is available from the free desktop bug tracker:
https://bugs.freedesktop.org/show_bug.cgi?id=107899 https://bugs.freedesktop.org/attachment.cgi?id=141619
I have reviewed and tested it. It appears to resolve the issue entirely in Rise of Nations: Extended Edition. The patch itself does a fairly good job of explaining what went wrong (and also why I missed the issue when I tried to debug it).
@FurretUber reported a small number of long lived allocations even with the patch, but further testing by him shows that they get garbage collected by an OpenGL game. I am unable to reproduce them. It might have something to do with me using KDE 5.
After this goes into mainline, someone should ping the linux-stable mailing list so that it is properly backported to Linux 4.14.y and 4.18.y. We probably should ping Canonical so that they apply it to their kernel too.
The fix has landed in drm-misc-fixes; it will propagate to a kernel release near you shortly.
Can you provide tests without DXVK?
@FurretUber What happens when you clear PageCache, dentries and inodes?
echo 3 >/proc/sys/vm/drop_caches