DXVK ignores VRAM limits

[talkingerbil]

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.

dxvk/src/dxvk/dxvk_memory.cpp

Line 388 in 9004c13

if (type->heap->budget && type->heap->stats.memoryAllocated + size > type->heap->budget)

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]

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]

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]

Adding additional documentation for reference.

Given the current state of DXVK VRAM allocation process, this PR #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 fd3fbf6 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.

[talkingerbil]

So, how do I use this VRAM limit?

You need to follow those reverts I mentioned above. They did a ton of VRAM allocation rework in v2.5 recently though, so I'd be surprised if those code changes could still apply correctly. I haven't touched it since my last post.

If you're on AMD you can patch/compile Mesa's radv (as a local install too, doesn't need to be system-wide with root, etc.) as I describe above to prevent over-allocation.

If using Nvidia, there's nothing you can do with certainty if the above reverts no longer work. It will depend on the app and many treat what's in maxDeviceMemory as a guideline only. Maybe dxvk v2.5 prevents apps from over-allocating by default but I doubt it.

That said, v2.5 does do a much better job of respecting vram status with the new dynamic allocations.

[awsms]

If using Nvidia, there's nothing you can do with certainty if the above reverts no longer work

What's the current situation on limiting the VRAM usage on NVIDIA with dxvk? :-(

[talkingerbil]

If only that was something they'd consider... It's very clear though that they don't want to be the "therapist" and stick their hands in the vram allocation side of things. They're happy to let that relationship drama stay between the gpu driver and the app itself.