Out of Address Space Megaissue

[misyltoad]

I'm making this issue to consolidate a bunch of issues on the D9VK tracker which are all essentially the same thing, running out of address space (there's like 4 separate reports of the same thing in Borderlands 2 and Rocket League).

The main issue is that these games are running out of address space and crashing with failed to map memory.

One thing I did notice, was that I could reproduce none of these issues (ie. Borderlands 2) on Windows with DXVK, but I could very easily when using Proton + DXVK.

One thing I did also try was disabling pulseaudio entirely which helped for a while but it still inevitably crashed (that thing was eating up way too much!)

Another thing I also tried was with WineSteam (wine-tkg) where I was not able to reproduce the issue with DXVK master, compared to Proton with DXVK master, but the address space (VMSize) was still scarily high! I'm not sure what I was looking at on Windows, but even the regular Memory in Task Manager + whatever Visual Studio's Debugger is telling me was much lower on Windows at ~2.3GB.

I disabled the game overlay (using the Steam Properties tab for the game) and also tried disabling Fossilize (bShaderEnableFossilizeLayer 0 in the console.) for Proton which didn't help.

Supercedes misyltoad/d9vk#383 misyltoad/d9vk#221 misyltoad/d9vk#170 and misyltoad/d9vk#93

[ericwomer]

Does this issues fall into this category? misyltoad/d9vk#165

[misyltoad]

No idea because you deleted your gists.

Also the game uses both DXGI and D3D9 which may be an issue with nvapi hack thats default

[ericwomer]

Fixed.

[misyltoad]

I did some testing to compare address space usage between Windows and Wine/Proton and when we get into game. Wine/Proton is throwing away 1.3GB more address space than is used on Windows. No idea what/where though.

[ericwomer]

Could be a driver/library issue, as with UE4 Editor on Linux, running with Vulkan, opening and closing a bunch of windows relating to a skeletal mesh and animations, I don't know exactly where, will cause a crash relating to running out of memory.

[ericwomer]

[Here[(https://gist.github.com/ericwomer/f29e22d55467538a3adbddc837eb6fc1) is a log output for UE4 that I believe is related to the issue I was talking about.

[misyltoad]

That's unrelated: UE4 is 64-bit, we're talking about address space not you just running out of physical memory here.

[ericwomer]

It ran fine under OpenGL4, but with Vulkan it 'ran out of memory'. But I do have a 2 gb card which isn't much.

[jrugia]

I've had this issue with quite a few games even before D*VK and the first thing I do is patch the game to enable Large Address Aware. I've been using this tool for patching: https://github.com/randomstuff/pe-set-laa

I've had a quite a few successes with this method: Legend of Grimrock 2, Risen 1 + 2, Titan Quest, Race Driver Grid, Tomb Raider Anniversary/Legend/Underworld and Far Cry 2...just to name a few.

[VortexAcherontic]

@Joshua-Ashton and @jrugia

Hm I tried setting PROTON_FORCE_LARGE_ADDRESS_AWARE=1 %command% as an additional launch option in Proton to achieve the same as your linked git repo but Borderlands2 still crashes with the out of memory message with Textures set to High =/

How ever this dose not happen if I run BL2 with WineD3D instead.

Any further suggestions?

[kelvinhbo]

Not sure if this is related but, turning Ambient Occlusion on takes a massive performance hit on D9VK titles, this setting seems to be broken, because on Windows it doesn't have the same effect, games I've tested are Borderlands 2 and Rocket League on NVIDIA cards.

[pchome]

@Joshua-Ashton

No idea what/where though.

Try this on running Proton game (replace winecfg.exe w/ game name):

mem usage summary

cat /proc/$(pidof winecfg.exe)/smaps_rollup | less

mem usage per lib/exe/etc.

cat /proc/$(pidof winecfg.exe)/smaps \
| grep -A1 '/' | tr '\n' ' '| sed 's/ -- /\n/g' | sed -E 's/ +/ /g' \
| sort -k8,8gr -k6,6 | less

Edit: swap -k8,8gr -k6,6 for sorting by name.

proc details

Maybe this will help to find suspect for detail analysis, IDK.

[wgpierce]

I did some more analysis on the interesting repro scenarios. I summarized information about where all the VA space goes with this script and imported it into libreoffice and did a pivot table on the two columns to sum up the total maps for each distinct map type and did a sort to get the top consumers:

pmap -q $(pgrep Launcher.e) | sed -e 's/\[ anon \]/[anon]/' | sed -e 's/\[ shmid=0x5800e \]/[shmid]/' | sed -e 's/\[ stack \]/[stack]/' | awk '{print $2"," $4}' | sed 's/K//' > map_sizes.csv

Here are the top consumers for some different scenarios in Borderlands 2 (a D3D9 game). Units are KB. These tests are on Nvidia 440 with the BL2 Ultra HD Texture Pack enabled running under Proton. Wine is at least 4.11 and DXVK is at least 1.5. Values didn't really change with newer or older wine/DXVK versions.

After starting up with DXVK enabled:

Total Result                  | 2949448
-
[anon]                        | 2104764
nvidiactl                     | 419636
memfd:pulseaudio              | 262144
libnvidia-glcore.so.440.44    | 28660
steamclient.so                | 26156
u1000-Shm_2019bf0e            | 16388
libnvidia-glvkspirv.so.440.44 | 11288

When the game crashes gives the "Ran out of video memory! Exiting..." error. Do note that the reference to video memory is a red herring -- it runs out of address space:

Total Result                  | 3904024
-
[anon]                        | 2206960
nvidiactl                     | 1263412
memfd:pulseaudio              | 262144
libnvidia-glcore.so.440.44    | 28660
steamclient.so                | 26156
u1000-Shm_2019bf0e            | 16388
libnvidia-glvkspirv.so.440.44 | 11288

After starting up with DXVK disabled, using WineD3D instead (and basically the steady state since it does not crash):

Total Result               | 2553480
-
[anon]                     | 1935996
memfd:pulseaudio           | 262144
#169462                    | 146484
nvidiactl                  | 53128
libnvidia-glcore.so.440.44 | 28660
steamclient.so             | 26156
u1000-Shm_eb9ca525         | 16388

A few interesting points:

• Using WineD3D, VA space usage usage is not significantly higher than Windows. In Windows, it typically sits at 2.3GB VA space usage.
• [anon] mappings total ~200MB more in the DXVK case, which is more but not as significant as nvidiactl
• nvidiactl is significantly higher using DXVK in grows enormously in the out of memory case. mmaping against /dev/nvidiactl corresponds to mapping system memory as you can see in the Nvidia open source code at /nvidia/nv-mmap.c, but I'm not 100% this is what is causing that to appear.

[pchome]

So, if the issue is not reproducible on Windows + DXVK, then it's likely Wine doing something unwanted. Either

• doing double job to allocate memory,
• UE3 limits are broken in Wine+DXVK (MemoryBudgets section, etc.),
• UE3 engine receives available memory from ddraw, d3d8, nvapi, etc. (which is the same function in Wine, AFAIK), which is different to the value reported by DXVK. (wined3d_device_get_available_texture_mem ?)

Maybe WINEDEBUG=+d3d tracing will show something.

[DaRkL3AD3R]

I don't know if this is the same issue, but I use DXVK on Windows and somewhere in the last 7 days something broke it for every game I test. They all crash on initialization with many of them referencing out of video memory or no hardware accelerator detected. Rolling back to the artifact for depth bias fix corrects the issue.

I haven't bisected builds yet to see which one caused this issue but I think it's related to this topic? I'll update if I find the exact commit that broke things for me.

It was this commit 7c53a99

[dlshinobi]

I don't know if this is the same issue, but I use DXVK on Windows and somewhere in the last 7 days something broke it for every game I test. They all crash on initialization with many of them referencing out of video memory or no hardware accelerator detected. Rolling back to the artifact for depth bias fix corrects the issue.

I haven't bisected builds yet to see which one caused this issue but I think it's related to this topic? I'll update if I find the exact commit that broke things for me.

It was this commit 7c53a99

Yes, this is happening for me too. But I'm on Linux.

[Oliver-1xok]

Rocket League sometimes freezes in the lobby. The music continues until the song is finished. I get the following error message:

As soon as I click on okay, the game ends. Could it have something to do with this?

I'm not getting a dump and I don't see anything unusual. The game don't seems to use up all the video memory when I look at the memory usage with the "nvidia-smi" command. Everything looks normal.

I'll try to get more information. Does Proton write log files somewhere?

Apart from that, Rocket League runs perfectly with D9VK.

[wgpierce]

@Oliver-1xok yes that freeze is this issue. It is not a video memory issue as referenced earlier in this issue. We already have the logs we need.

@DaRkL3AD3R @dlshinobi I hope you filed another issue if this is still affecting you? Seems like a different problem from this issue.

[misyltoad]

Those issues by that commit should already be fixed in master now @wgpierce

[Animajosser]

I was told that my question was related to this. Walking Dead Season 1 crashes at launch when starting with vanilla wine and dxvk. I don't know enough about dxvk and wine to say anything about it, but installing a wine build with support for forcing LARGE_ADDRESS_AWARE (I used the 32 bit proton build here https://github.com/Kron4ek/Wine-Builds) and setting PROTON_FORCE_LARGE_ADDRESS_AWARE=1 or WINE_LARGE_ADDRESS_AWARE=1 will fix it. The LARGE_ADDRESS_AWARE patch is not implemented upstream yet as far as I can see, but it seems like that would be a fix for walking dead season 1 + dxvk compatibility with wine vanilla. If the other problems are also caused by this, it could be a fix for all of them.

By the way: I copy pasted part of this as an edit into my own closed issue (If someone else has the same problem they can find it in 2 places this way).

[wgpierce]

@Animajosser yes, LARGE_ADDRESS_AWARE is already being used. That can help 32-bit programs that use less than 4GB of address space with DXVK. This issue is all about programs that try to use >4GB of address space with DXVK because 32-bit programs cannot address >4GB of address space. When the program does try to map >4GB of memory, it fails. You can see this failure in this comment above

[rtentser]

I have a similar issue with Disco Elysium. The game doesn't crash, but after starting i'm getting no graphics except character's model and some objects. No background, just a blackness. And i'm getting some "out of memory" errors for my GT 710 with 1GB VRAM in terminal. I can reproduce it in 1.5.3.

But the game works fine with 1.4.6, so it's a regression.

[doitsujin]

Disco Elysium is a 64-bit game and therefore cannot run into this issue. The problem you're running into is #1100.

[Blisto91]

Ye that would would be great thanks 🙂

[Mats391]

Trace of loading with normal Direct3d https://mega.nz/file/JFdmFaiD#dVscXhfPOlKFCRwVtulkPx5eLEGFUR8vrxu4-O1ezJI

[Blisto91]

Try checking if it helps unmapping more aggressively.
Make a file called dxvk.conf next to the exe or where the dxvk logs appear and insert this

d3d9.textureMemory = 16

To verify the conf file gets picked up you can also enable the hud through there with dxvk.hud = 1 and see that it shows up ingame. Or just look in the log under Effective configuration:

[Mats391]

Still runs out of memory in same area as before prbf2_d3d9.log

[Blisto91]

Apparently this game (plus mod i guess) uses a ton of mapped buffers besides mapped textures.
The latter the merged unmap pr handles fine and saves around 850MB with default settings in your trace. The former used to be a part of the unmap pr but was pulled because it causes issues in some games. Original crysis crashing randomly in dx9 mode as an example.
The devs will try to look into that again here at some point, possibly default disabled so it can be enabled for specific games where it doesn't cause issues. Might save another 600+ MB

[Mats391]

That sounds very promising. Is there already an issue to track that change? Very interested in the progress as using dxvk provides quite some FPS increase.

I also did some further testing to better quantify the problem. The problem appears to come from the lighting+shadow system. This is something we did not touch yet (and probably never will) in the mod, so results should be comparable to normal BF2. Changing the configuration as mentioned above did not change these numbers.

d3d9 Highest | 2gb
d3d9 Med Light | 1.9gb
d3d9 No Shadow | 2gb
d3d9 No Shadow + Med Light | 1.9gb
dxvk Highest | 2.8gb
dvxk Med light | 2.1gb
dxvk No Shadow | 2.2gb
dxvk No Shadow + Med Light | 1.8gb (actually saves memory compared to d3d9, but within margin of error)

[Blisto91]

There is no issue but I'll ping you for testing when something pops up

[Kreyren]

I think i have the same issue on Final Fantasy: XIV where i get this spammed in the output before the game crashes:

err:   DxvkMemoryAllocator: Mapping memory failed with VK_ERROR_MEMORY_MAP_FAILED

Using wine-staging-7.8 on GNU Guix setting the WINE_LARGE_ADDRESS_AWARE=1 doesn't seem to affect it and neither is using dxvk.conf in the root of executable:

$ cat boot/dxvk.conf 
d3d9.evictManagedOnUnlock = True
d3d9.textureMemory = 16

[K0bin]

Please make an apitrace of that game and open a separate issue.

[mirh]

WINE_LARGE_ADDRESS_AWARE is just a proton patch. Check this for vanilla wine.

[jo-oe]

Civilization 4: Colonization (dxvk-2.0 / Proton-GE 7-42), including mod "We The People"
[NVIDIA GeForce 940M / Optimus configuration / ENV set up to use the NVIDIA device; 12GB total RAM]
PROTON_USE_WINED3D=0: Total address space use peaks at 3.97 GiB before game crashes on loading a save.
PROTON_USE_WINED3D=1: Total address space use after loading save stays around 2.9 GiB. Performance is much worse though (around 15 fps)

I tried all the suggestions in this thread, especially the dxvk.conf ones. Memory use did not change using any of them.

[Blisto91]

@jo-oe Hello.
Please make a apitrace of the game without dxvk so it doesn't crash while tracing (wined3d or windows) and share it here. You can find a guide at https://github.com/doitsujin/dxvk/wiki/Using-Apitrace

Also upload the dxvk logs that are generated while it crashes.
With dxvk they should appear in the games folder when you launch with PROTON_LOG=1

[jo-oe]

@jo-oe Hello. Please make a apitrace of the game without dxvk so it doesn't crash while tracing (wined3d or windows) and share it here. You can find a guide at https://github.com/doitsujin/dxvk/wiki/Using-Apitrace

Also upload the dxvk logs that are generated while it crashes. With dxvk they should appear in the games folder when you launch with PROTON_LOG=1

apitrace: https://ufile.io/dxyrjfnm
dxvk log: https://ufile.io/50ynaovn
Note that this time the game threw an exception when reaching 3.97GiB adress space use and froze instead of crashing.

Hope this helps :)

[Blisto91]

@jo-oe Thank you.
Could i get you to make a new issue? Then it doesn't risk getting lost.
Just repeat the information you've included here and link apitrace and log also 🙂

[Blisto91]

@Mats391 This probably won't help as i understand your issue is most likely just mapped buffers, but you could try giving #3239 a spin. It helps with memory size in some very specific cases.

[Mats391]

@Blisto91 thanks for the heads up, just gave it a try on two of our maps and the results are promising! Not sure if this is due to the changes to stateblocks, some other change in dxvk or updates to our shaders:
Map1 (Fallujah West):
d3d9: 2gb
dxvk: 1.5gb

Map2 (Ascheberg):
d3d9: 3.1gb
dxvk: 2.3gb

So with the dev build (https://github.com/doitsujin/dxvk/actions/runs/4108270569) dxvk actually has lower memory footprint than normal d3d9

[Blisto91]

Huh. Interesting

[NoTitleGamesOfficial]

Might this be the same issue? https://www.reddit.com/r/linux_gaming/comments/1bn089i/some_crashes_while_playing_the_guild_ii_pirates/

heres the log: https://pastebin.com/Di5JgFPP

[Blisto91]

Yes but according to the log they seem to be using wined3d and not dxvk

[NoTitleGamesOfficial]

Yes but according to the log they seem to be using wined3d and not dxvk

Do you have a solution such as adding 'WINE_LARGE_ADDRESS_AWARE=1' for d3d?

[K0bin]

WINE_LARGE_ADDRESS_AWARE impacts WineD3D as well. Besides that, this is a DXVK bug tracker, not a general support forum.

[Espionage724]

I've had this issue with quite a few games even before D*VK and the first thing I do is patch the game to enable Large Address Aware. I've been using this tool for patching: https://github.com/randomstuff/pe-set-laa

I've had a quite a few successes with this method: Legend of Grimrock 2, Risen 1 + 2, Titan Quest, Race Driver Grid, Tomb Raider Anniversary/Legend/Underworld and Far Cry 2...just to name a few.

With Titan Quest DX9 I get a consistent crash with or without WINE_LARGE_ADDRESS_AWARE=1

https://www.youtube.com/watch?v=YG6e-7_eIyc

In Act 3 from Village of Zhidan town, walk backwards up the thick path until right before the staircase with some kind of faded path-fork off to the left. Walking around anywhere seemingly on the left-side of that dirt area crashes.

[Blisto91]

@Espionage724 hi there. Are you able to share a save game?

[Espionage724]

@Espionage724 hi there. Are you able to share a save game?

Hi; I'm not sure on a specific file, but here's my 3 TQ folders in Documents\My Games: 20240825-TQAE.zip