This engine is known to allocate a huge amount of STAGING resources, I guess 8GB just won't cut it for your selection of mods.
Can't really do anything here from our end. Ideally, the driver would just allow more than half the system memory to be used for allocations.
Edit:
d3d11.relaxedBarriers = True
Please don't do this unless there is solid proof that this a) can never cause problems with under-synchronization and b) meaningfully improves perf. And if it does both of those things, we should have an app profile for this.
You didn't actually attach the logs you mention. Logs from latest release are usually the most interesting.
here are the logs AnomalyDX11AVX_d3d11.log
In your game config file (user.ltx) find "r__no_ram_textures" parameter and switch it (on/off), see if it helps.
In your game config file (user.ltx) find "r__no_ram_textures" parameter and switch it (on/off), see if it helps.
i set r__no_ram_textures to on, it was off initially
xray_igor.log
AnomalyDX11AVX_d3d11.log
Post dxgi log also
Greetings, @piscopancer
I am DXVK-GPLALL developer. Please, can you check DXVK-GPLALL 2.6.8-2? I am interested in your feedback.
@Digger1955 It's well intentioned but could you please not spam about your downstream fork in all threads that have issues with 3.0?
@K0bin
There was no such intent.
I focus on specific issues, which may or may not be present in my release, due to backporting commits from DXVK 3.x.
@Digger1955 i tried your fork (2.6.8-2) and it does not work on my machine, STALKER Anomaly splash image hangs indefinitely and the process memory gets stuck at about 354mbs. the process never crashes and never prints an error, it just sits there not responding until i kill it, i left it for 10+ minutes the first time
i tried three of your builds:
all three behave exactly the same, so it's not the compiler or the instruction set. the dxgi log always stops at the same place, right after the instance extensions, and the d3d11 log never even gets created:
info: Game: AnomalyDX11AVX.exe
info: DXVK-GPLALL: 2.6.8
info: Build: x86_64 msvc 19.44.35228
info: Vulkan: Found vkGetInstanceProcAddr in vulkan-1.dll @ 0x7ff835f8f200
info: Built-in extension providers:
info: Platform WSI
info: OpenVR
info: OpenXR
info: OpenVR: could not open registry key, status 2
info: OpenVR: Failed to locate module
info: Enabled instance extensions:
info: VK_KHR_get_surface_capabilities2
info: VK_KHR_surface
info: VK_KHR_surface_maintenance1
info: VK_KHR_win32_surface
so the instance gets created and then nothing, no "Found device" line ever. upstream dxvk on the same machine with the same dlls path gets to device creation in under 25 seconds, i tested 3.0.2, 2.7.1 and 2.6.2 and all three enumerate fine
system: gtx 1650 mobile, nvidia 610.74.0, ryzen 5 5500u, 16 gb ram, win10 19045. the laptop also has an amd vega igpu but its driver is from 2021 and doesn't do vulkan 1.3, upstream dxvk just skips it and picks the 1650. i also ran with VK_LOADER_LAYERS_DISABLE=VK_LAYER_AMD_switchable_graphics,VK_LAYER_RTSS,VK_LAYER_OBS_HOOK
happy to test anything or grab more logs if you want
@piscopancer
Thanks for report.
vulkan-1.dllx1 2026-07d3d11.dllx1 2026-07rtssvklayer64.dllx1 2026-070xc0000005x1 2026-07
i know windows isn't officially supported, posting anyway because the 2.6.2 one is a deterministic null deref at a fixed offset and might be useful to you. close it if it's out of scope
Software information
S.T.A.L.K.E.R. Anomaly 1.5.3 (x-ray monolith, modded exes), running the GAMMA 0.9.5 modpack through MO2. renderer is DirectX 11 (Enhanced), 2560x1440, borderless. it crashes while loading a save, every time, same spot. plain Anomaly without GAMMA at 1920x1080 with the exact same dlls loads fine, so it's the modpack's size that does it
dxvk.conf:
System information
The problem
on 3.0.2 and 2.7.1 the host visible heap fills up completely and then any allocation fails, while vram is basically untouched:
2.7.1 is the same picture, 7104 of 7204 on heap 1, heap 0 still at 926. the heaps as dxvk reports them:
mem types 0,1,3,4,5 is the buffer mask, so these are buffers, and 0 and 1 are device local, so it could have gone to vram and didn't. the engine says it loaded 2411 base textures, 2809697 K, and heap 1 ends up with 7 gb in it. heap 1 being 7.66 GiB is about half my ram so i think that's just what the nvidia driver gives, but dxvk fills all of it every single time
the funny thing is 2.6.2 doesn't do this at all. no allocation failures, it gets past the textures and into the ui setup, and then it just dies:
null deref, it reads 0x40. same offset in two different runs at two different load addresses, so it's deterministic
things i tried that changed nothing:
dxgi.maxSharedMemory = 2048, it shows up in the effective config and the engine completely ignores it, heap 1 still went to 7172dxvk.enableMemoryDefrag = True, heap 1 still 7168VK_LOADER_LAYERS_DISABLEtogether with the obs hook and the crash is byte for byte the same. nvidia overlay off tooso on 2.6.2 there's no memory problem but a crash, and on 2.7.1 and 3.0.2 there's no crash but the host heap gets eaten
probably related: #5556 is the same heap symptom with GAMMA on amd/mesa, closed without a fix. this one is the windows/nvidia side of it
Apitrace file(s)
none yet, the trace of a gamma save load would be huge. can do it if you want it
Log files
attached:
AnomalyDX11AVX_d3d11.logandAnomalyDX11AVX_dxgi.logfrom the 2.7.1 run, plus the minidump from the 2.6.2 crash. say the word and i'll get the 3.0.2 and 2.6.2 logs too, each run overwrites them so i have to reproduce one at a time