conf option questions

[Blisto91]

Hi there.
I hope it's alright i open a quick issue to ask a few questions (can close it again quickly), was not sure where else i could ask.

When testing games and going through the issues i sometimes mess with the conf options and was wondering about a few things, mainly about the ones relating to vram/memory.
I've read a bit of your comments from old issues and peaked slightly at some code, but lack some of the knowledge to dig deeper and understand.

As an example for a dx9 game what is the practical difference between setting dxgi.maxDeviceMemory dxgi.maxSharedMemory & d3d9.maxAvailableMemory. Mostly the first and last since i guess maxSharedMemory is just how much regular memory is reported to be allowed to be used as vram? Tho how does this relate to a APU/igpu such as the steam deck?
maxDeviceMemory i would guess would be like saying what actual memory i want to report my gpu having?
maxAvailableMemory i gather has something to do with initial memory amount allowed to be dedicated? Although i'm not sure here.

Would it even make sense to set maxAvailableMemory to more than 4096? I see it's used in a place where it's multiplied with Megabytes which is 1024 * 1024. So if the variable is a 32bit uint it can't get much larger anyway?

Lastly i saw a couple of issues where d3d9.memoryTrackTest solved the problem. What is this used for? Tracking and freeing vram?

Thx for any replies.

[Deus-nsf]

I personally tried to play around with d3d9.maxAvailableMemory (to circumvent the out of memory issue with black mesa at xen) but any attempts at changing the value did either nothing, or increased crashes. Which makes sense I suppose but I tried anyways.

I'd be curious with the d3d9.memoryTrackTest though, didn't try that one yet.

[Blisto91]

Depends on if it's VRAM or system memory issues i guess. If it's the latter this PR would be a better bet.
#2524

You can grab a CI build of it here of you want to test it out.
https://github.com/doitsujin/dxvk/actions/runs/2042082711

(This is only relevant for 32bit games btw. Dunno what black mesa is)

[Deus-nsf]

yep BM is 32 bit, and playing with d3d9.memoryTrackTest didn't help as i suspected, I'm gonna test that build you linked
EDIT: the dll didn't improve the situation sadly, however by searching in the source engine console commands I found this:

cl_always_flush_models
"If set, always flush models between map loads. Useful on systems under memory pressure."

switching it to 1 seem to get rid of the crashing scenarios I had, at no cost in loading times (at least I couldn't notice it) which is very good news, I need to test this further to be sure though

[K0bin]

As an example for a dx9 game what is the practical difference between setting dxgi.maxDeviceMemory dxgi.maxSharedMemory & d3d9.maxAvailableMemory.

D3D9 games don't use dxgi, so only the d3d9 option will have an effect on those. As you said, it only changes what DXVK tells the game when it asks for how much memory is available. The value is stored as a 32bit integer internally, so no, it does not make sense to set that above 4GB.

DXVK also counts the amount of memory used for D3DPOOL_MANAGED resources and refused to create new ones once that has the maximum amount of memory we report. Some games rely on that and keep creating resources until it fails. That is however not something you'd want for heavily modded games, hence why we have an option (d3d9.memoryTrackTest) to turn that behavior off.

[Blisto91]

Thanks for the reply K0bin. What about the memoryTrackTest?

@Deus-nsf I can try to test the game and see if i can reproduce

[Deus-nsf]

no it's fine, seems like a lost cause for now, the command helped but it still crashes, I am also guilty of using a few mods from the workshop, which probably doesn't help with the memory load (even though it doesn't crash in D3D9)

[Blisto91]

You can't stop me hohoho.
I've been meaning to play through black mesa again after they added Xen anyway.

[Deus-nsf]

okay, a very interesting fact, on windows (useful to directly compare D3D9 and Vulkan, when it works of course) on D3D9 my RAM usage goes from 6.5 GB to 8.5 GB, with Vulkan through the dxvk dll, it's 9.5 GB.

if you want to test something, please test that as it may prove very interesting. if you don't have windows just load xen and compare your RAM usage before launching the game, and after loading a new game from xen (sv_unlockedchapters 19 from the console if it's locked)

[Blisto91]

Roger. I have windows so can test that.
We should probably move this to your other or a new dxvk issue tho. Or proton issue hehe

[Deus-nsf]

a new issue then, but I need to test previous dxvk versions as well first, I'm not sure they use to allocate so much ram, but I dont know.

EDIT: even older versions, like 1.9.0 has this behaviour, from 6.7 GB to 7.7 on D3D9 vs 8.9 on DXVK, that's +1.2 GB of RAM allocation, just booting to the game menu (in -oldgameui mode, not using the new UI).

[K0bin]

@Blisto91 I should've been a bit more clear about this. d3d9.memoryTrackTest controls whether we fail resource creation based on tracked memory usage. I've edited the comment to clarify that.

@Deus-nsf Yes, please open a new issue for Black Mesa please. I'm playing through that again anyway right now so I'll probably look into that soon-ish.

I answered the question so I'm gonna close this. Feel free to ask if there's still things that aren't clear.

[Blisto91]

Thanks K0bin. I think i get it.
Am i correct in understanding that when you set d3d9.memoryTrackTest to true is when dxvk will refuse to create more once that max reported has been reached? Like i see it's been set to true for some games to "Prevents the game from consuming all system memory." in the case of Anarchy Online

[K0bin]

Exactly. Some games keep creating resources until it fails as a weird way to measure the amount of available VRAM.

[Blisto91]

Quick question that isn't about the conf but is about memory.
What is it that "vidmem heap 2" shows in the hud? Shared mem or some cache?
I'm guessing vidmem heap 0 is regular old vram.

[K0bin]

Heap 0 is VRAM,
Heap 1 is RAM,
Heap 2 is BAR memory. It's VRAM which the CPU can access directly. CPU access to that is slow but GPU access is faster than to RAM. DXVK uses that for specific resource types.

With modern GPUs the CPU can access the entire VRAM heap directly, there's only 2 heaps on those. AMD calls that Smart Access Memory. Generally it's known as resizable BAR.

[Blisto91]

@Deus-nsf just as a quick fyi i tried a play-through of the Xen levels of the windows version on linux through proton & dxvk. But i didn't experience a crash.

[Deus-nsf]

@Blisto91 Sorry about that, one of the biggest reasons of the crashing was identified after a long and painful process of troubleshooting, it's not "just" that, but a big reason was the "Enable Shader Pre-Caching" and ESPECIALLY the "Allow background processing of Vulkan shaders" option on the Steam Shader Pre-Caching options.
Really no idea why, but as soon as I unchecked those options, memory utilization was down 1 whole GB! And the crashing was significantly less occurent as a result.