I'd say setting d3d9.maxAvailableMemory = 1024 is a reasonable workaround for systems with little memory. It's hard to say what exactly the game is doing, but if reporting a different amount of VRAM to the game fixes the issue, it's not really our fault.

Fair enough. I think the game's pre-loading a ton of stuff on startup, which is a bit weird anyway.

d3d9.evictManagedOnUnlock = True might be another option to try.

It doesn't help in terms of getting the game to not crash on startup and also tanks the framerate during gameplay (the hardware's somewhat maxed out anyway). The game will manage its memory well once it's started, so it doesn't really help here.

DXVK is known to have very high memory overhead, it's not really possible to change that without a complete rewrite (and potentially sacrificing performance for memory efficiency).

I thought as much, hence the can of worms I mentioned. Ok, got it and I'll close this, I just had to ask :). Thanks!

With new hardware comes new insight into old issues.

I've recently upgraded to an 8GB laptop with an Iris Xe-LP G7 iGPU and I'm still seeing the same behavior. It's the only game out of 30+ D3D9 games I've tried that has this problem, so it's not a system-specific or low heap memory problem, as I initially thought. It appears the game will reserve all the VRAM it possibly can + whatever RAM it needs for its 32-bit LAA-aware process. While this allocation logic works fine with dedicated GPUs, it eats up all available memory on iGPUs and causes the game to crash on startup.

Could you please add d3d9.maxAvailableMemory = 1024 as a permanent workaround for this game? I have confirmed it works on my new system as well. In fact 2048 and 3072 work as well, problems start around 4096 and above or with no value. However, considering this is a game from 2009 and the top tier GPUs at the time had either 512MB or 1GB VRAM, I think it's the value that makes most sense. I had no issues with it on several playthroughs.

Either way, there has to be a limit in place on systems with an iGPU or the game will not start with DXVK. I'm not sure how WineD3D works around what the game is doing to be honest... but it offers worse performance, so I also don't care that much.

As a last note, I've also tried d3d9.memoryTrackTest = True, but it makes no difference here.

Log files

• d3d9.log (without limit): Majesty2_d3d9.log
• d3d9.log (with limit): Majesty2_d3d9.log

Hm, I think we should maybe add maxAvailableMemory to something sane on iGPUs to avoid the "allocating all RAM" problem.

Fair point, but to be honest this is the only game I've ever had issues with. All other D3D9 stuff seems to behave nicely and NOT crunch on all they detect.

It's hard IMHO to determine what might be a sane limit using a hard cutoff value, unless you go for something dynamic like 30% of system RAM for example.

How much memory does your new laptop have out of curiosity?

8GB in total.

If my understanding is correct on how the heap size is calculated, having more RAM could potentially prevent the memory allocation error. But the game would still take up an unjustifiably large portion of RAM/VRAM.

Well, not if the game decides it wants to eat all of it if you're on UMA.

Maybe something like min(60%, 4GB) for UMA would be sensible

I'll be happy to test whatever you come up with and think is best :). But for this particular game the crashes started between 3GB and 4GB max VRAM, as I mentioned above.

While trying to narrow down the exact point on which the game breaks (just for fun), I noticed the following behavior: starting with d3d9.maxAvailableMemory = 3502 (wtf???), the game will "gracefully" show its own out of video memory message rather than crash directly. Further increasing the available memory up to 4096 will cause it to just crash without the error at some point.

It clearly does not know how to handle more video memory than it's ever been designed for... at this point I'm intrigued by why it works on my GTX 1080. Ancient NUMA magic maybe.