This is very interesting.

I have a theory after reading the statement that the game tend to use a lot of video memory than usual. I do think that the game may just use this tactic to "optimise" the game by just letting the video card handle memory instead of manually managing video memory. So I tried every single way to "lie" to the game that I'm starving VRAM with every DXVK configs I could think of

DXVK_HUD=memory DXVK_CONFIG="dxgi.emulateUMA = True; dxgi.maxDeviceMemory = 2; dxgi.maxSharedMemory = 0; d3d11.zeroWorkgroupMemory = True; dxvk.halveNvidiaHVVHeap = True;" %command%

I don't know which options make a difference, but after this, the game now tries to be very, very conservative on VRAM usage instead lol. It always kicked off to full VRAM usage before.

Be warned, these launch options cause significantly more stutter than usual, but it no longer runs out of video memory. My 970 can run the game at 1600×900 just fine now.

This is very interesting.

[...]

DXVK_HUD=memory DXVK_CONFIG="dxgi.emulateUMA = True; dxgi.maxDeviceMemory = 2; dxgi.maxSharedMemory = 0; d3d11.zeroWorkgroupMemory = True; dxvk.halveNvidiaHVVHeap = True;" %command%

Very interesting indeed. With that config - and the fact that 1.1 also drove down the OOM issues quite a bit on my RTX3080 - the memory overuse SEEMS to be getting mitigated QUITE A BIT. I've broken 8gb total in my validation but it quickly came back down,, whereas booting into the game, warping to Scott Outpost and merely walking into the tent gets me to 8gb+ total VRAM (5.ish GB to ZZZ alone) and hovers around that.

VERY nice find, @SysError99. Much appreciated.

I got a conclusion, there's two options that need to be set in order to lie the game (at least, on my machine), dxgi.enableUMA, and dxgi.maxDeviceMemory. The dxgi.maxDeviceMemory can be set to any low value but zero, and the game now behaves properly with low memory graphics cards.

DXVK_HUD=memory DXVK_CONFIG="dxgi.emulateUMA = True; dxgi.maxDeviceMemory = 1;" %command%

Yes..., the option that happened to be removed in further versions (https://github.com/doitsujin/dxvk/commit/eb8d1885bde916b3476229a9220952ad0f639ff9) happens to be the option that's crucial for this workaround to work...

I did surf the dxgi_adapter.cpp a little bit, it seems like this is all that the option dxgi.emulateUMA does.

if ((m_adapter->isLinkedToDGPU() && deviceProp.deviceType == VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU) || 
    options->emulateUMA) {
    sharedMemory = std::max(sharedMemory, deviceMemory);
    deviceMemory = 512ull << 20;
}

The deviceMemory must be set to anything in absurd value in order to get it working (in this case, 512 << 20 or 536870912), and the sharedMemory must be very low value. So I did try to set the maxDeviceMemory to an absurd value, but this code section blocked me away to do it...

// Some games are silly and need their memory limited
if (options->maxDeviceMemory > 0
 && options->maxDeviceMemory < deviceMemory)
    deviceMemory = options->maxDeviceMemory;

if (options->maxSharedMemory > 0
 && options->maxSharedMemory < sharedMemory)
    sharedMemory = options->maxSharedMemory;

I think we just need to remove true max memory limit to allow its users to freely set any values into it. We just need to warn them that it can be risky and may crash their machine, like below.

// Some games are silly and need their memory limited
if (options->maxDeviceMemory > 0)
    deviceMemory = options->maxDeviceMemory;

if (options->maxSharedMemory > 0)
    sharedMemory = options->maxSharedMemory;