search

doitsujin / dxvk

Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine
zlib License
12.28k stars 786 forks source link

DXVK ignores VRAM limits #3867

Open talkingerbil opened 4 months ago

talkingerbil commented 4 months ago

DXVK ignores device VRAM limits set by either override_vram_size (RADV) or dxgi.maxDeviceMemory (dxvk.conf). Is this intentional?

It appears to be caused by the VRAM budget value in DxvkMemoryAllocator::tryAllocDeviceMemory being 0 before the check for allocation limits/status at the start of that function. https://github.com/doitsujin/dxvk/blob/9004c132ed6fcbcfdb0f8b2c40f49d28b41fcb1c/src/dxvk/dxvk_memory.cpp#L388

This is a problem when the code/game in question doesn't respect the DXGI VRAM limits/suggestions mentioned above. Admittedly, I've only tested 3-4 games so far but I'm sure plenty more misbehave just as much as these.

If I hard-code a value in place of type->heap->budget in that IF check, everything seems to be fine for both VRAM limits and game stability. Note that in doing that, I'm currently also ignoring heap type, but initial testing has been positive.

If budget==0, that IF statement is a moot check, no?

K0bin commented 4 months ago

dxgi.maxDeviceMemory will just change how much memory DXVK reports to the application. The application could however ignore that and happily continue allocating. Oversubscribing VRAM generally works fine on Windows.

talkingerbil commented 4 months ago

Yeah. Noted.

This issue then, merely serves as documentation that passing on app bad behavior is both known and intentional.

Folks setting dxgi.maxDeviceMemory should not expect that value to be strictly obeyed.

To anyone looking to patch DXVK to obtain expected behavior: the above IF statement is at least one location in the code where that strict adherence could be achieved.

talkingerbil commented 4 months ago

Adding additional documentation for reference.

Given the current state of DXVK VRAM allocation process, this PR https://github.com/doitsujin/dxvk/pull/3877 is a straightforward method of hard-regulating VRAM usage on a per-app basis from within DXVK. The budget value would be set by the Mesa evar override_vram_size in Mb. Note that this value also propagates to dxgi.maxDeviceMemory though the latter overrides the Mesa setting.

Also note that allocation requests beyond the VRAM budget limit are sent to system RAM. Though performance degradation should be expected, RADV-requested VRAM limits would actually be honored.

Applying this PR would first require reverting https://github.com/doitsujin/dxvk/commit/fd3fbf66070e85bca8e7261577ea411e2bd620c7 to reintroduce the budget variables and the budget check in src/dxvk/dxvk_memory.cpp. Though they were introduced to workaround Nvidia driver bugs and declared unnecessary, this method is applicable to any GPU type.

Additionally, a second method of hard-limiting VRAM usage is to patch Mesa to disallow VRAM overallocation by default: set to true. At this time there does not appear to be an evar or similar config setting to achieve this limit in Mesa. This would achieve the same result as the DXVK method and is also controlled via override_vram_size.