this post was submitted on 25 Oct 2024
2 points (100.0% liked)

Linux Gaming

15270 readers
241 users here now

Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.

This page can be subscribed to via RSS.

Original /r/linux_gaming pengwing by uoou.

Resources

WWW:

Discord:

IRC:

Matrix:

Telegram:

founded 1 year ago
MODERATORS
 

I've been having a couple of troubles playing Diablo IV, though they seem to be a lot worse with the new expansion. After a while of playing for a while, the game seems to leak VRAM and makes my desktop pretty unstable. Alt+tabbing occasionally breaks the game, the image freezes but I still hear the noises of the menus opening and such. If I don't alt-tab the game doesn't break.

I have found this reddit thread about setting a dxvk file to limit the amount of VRAM available to Diablo. I set up the max VRAM to 8gib but mangohud still reports 10gb being used. I tried setting the DXVK_CONFIG_FILE flag but that also doesn't seem to work. Mangohud report 10gb VRAM very fast. DXVK file contents:

dxgi.maxDeviceMemory=8192
dxgi.maxSharedMemory=8192

Decreasing the graphic settings just slows down the problem, it doesn't prevent it.

Launch options: DXVK_CONFIG_FILE=/gamedrive/dxvk.conf mangohud %command%

Specs:

Intel i7-12700K @ 4.900GHz
NVIDIA GeForce RTX 3080 (driver version: 560.35.03)
64GB DDR4
EndeavourOS Linux
6.11.3-zen1-1-zen
Hyprland
GE-Proton9-16

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Diablo IV is a DirectX 12 game. Those don't use DXVK directly, though I think they might still use the DXGI component that comes with it, even though vkd3d-proton is providing the Direct3D 12 support.

DXVK_CONFIG_FILE is not a flag, but an environment variable. It is for overriding the location where dxvk.conf is expected to be. By default, that file is expected to be in the game's current working directory when it starts, so you don't need this environment variable at all if you figure out what directory that is. (Hint: look for a dxvk or vkd3d log file.) Details here.

Note that one person in that reddit thread says dxvk.conf can be in "any folder of the wine prefix". As far as I know, that's just plain wrong. It has to be where DXVK is expecting to find it.

If you can't figure out where to put the config file, you might try applying those dxgi settings using an environment variable instead. In Steam, that would be DXVK_CONFIG="dxgi.maxDeviceMemory = 8192; dxgi.maxSharedMemory = 8192" %command% in the game launch options.

Here's a different possible workaround, to be put in Steam's game launch options: PROTON_HIDE_NVIDIA_GPU=1 %command%
Or if using Lutris with a Proton Wine runner, you would add the PROTON_HIDE_NVIDIA_GPU=1 environment variable to the game (or launcher) profile.

If none of those workarounds help, you'll want to get involved in these discussions:

https://github.com/HansKristian-Work/vkd3d-proton/issues/1588

https://github.com/ValveSoftware/Proton/issues/7199

Edit: Several people have reported that this VRAM bug doesn't happen on AMD cards. If you happen to have one, you might give it a try.

[–] [email protected] 0 points 2 weeks ago

I have tried the PROTON_HIDE_NVIDIA_GPU=1 before and I can tell you it definitely helps. The game is unplayable without it, to be honest. The VRAM still fills up but it's not instantly, it takes quite a while. Makes the problem manageable.

Edit: Several people have reported that this VRAM bug doesn’t happen on AMD cards. If you happen to have one, you might give it a try.

Unfortunately I do not. I bought this nvidia card long before I switched to Linux and boy, do I regret it.

[–] [email protected] 0 points 2 weeks ago (1 children)

I believe that config needs to be in the working directory context of the game, but maybe I'm misremembering that. I would try setting some other options to make sure it's actually being read.

I don't think it's going to do much to help your problem here though, except maybe crash it. If upon starting your game, it immediately starts using 10GB of vid mem, then that is what is needed by the game to run. Setting this to 8GB is going to magically make it run by using less.

If your main concern is the stability of your machine while using other apps, I would be attacking this a bit differently.

  • Try figuring out why your desktop is becoming unstable.
  • Maybe check the difference between running in full screen vs windowed.
  • See if you can force a specific renderer that is more stable.
  • Check ProtonDB for other settings suggestions
  • Try running different Proton versions

Things like that.

[–] [email protected] 0 points 2 weeks ago (1 children)

I believe that config needs to be in the working directory context of the game, but maybe I’m misremembering that.

Yep, I tried that as well. I have the exact same file in /gamedrive//SteamLibrary/steamapps/common/Diablo IV/

If upon starting your game, it immediately starts using 10GB of vid mem, then that is what is needed by the game to run. Setting this to 8GB is going to magically make it run by using less.

But the game does quickly fill 10GB with both low and ultra settings. It hints to me that the game doesn't need 10GB to run. It just makes use of the available memory. My theory is that using 8GB would at least make my desktop usable. Currently, switching to my browser in the second monitor can break the game. If I never focus out of the game it doesn't break.

  • Problem occurs in both x11 and wayland
  • Window vs fullscreen makes no difference
  • ProtonDB has some additional flags, I tried them all
  • I tried several proton versions from 8 to 9, GE and no GE. Made no difference

See if you can force a specific renderer that is more stable.

What are the available options? I haven't tried this.

Thanks a bunch!

[–] [email protected] 0 points 2 weeks ago

Looking at ProtonDB, I don't think it's worth the trouble. All users seem to be reporting the same issues as you, so it's probably just the nature of running it in Proton.