CPU Performance Patch (Up to 30% faster physics, up to 60% more FPS)

Other CPU Performance Patch (Up to 30% faster physics, up to 60% more FPS)

Oh dear what have you done :). Brings me back in time when optimising config.sys and autoexec.bat for Elite and Wing Commander on my rig back in the days.
Having a 13900k/4090 now. Not done much overclocking yet though. Using below settings with HT disabled.
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,2,3,4,5,6,7,8
[threadsVR]
computeColliders=6
skinmeshPart=6
applyMorphs=6
skinmeshPartMaxPerChar=6
applyMorphMaxPerChar=6
affinity=1,2,3,4,5,6
Only switch off HT for gaming. Not many games seem to profit from HT. Also cpu runs much cooler in VAM, while performing better without HT.
I guess I could leave HT on now and use the standard settings. But that is an experiment for another day.
The idea for lower settings in VR is to leave Virtual Desktop and Steam something to work with. Did not had time to analyse it proper to see which processes actually gets allocated to which core. There is also all the Windows bloatware doing stuff in the background no one really needs, but that is a different story.
Keep up the great work and thanks.
 
Hi,
FPS perfect, but now I get an error, see picture, I'm not an expert, but it's probably a Z-Buffer problem, it's special that I only go through the UnityAsset object through the menu, but that's probably the order of the object during drawCall, turn on and off FreeSync make no sence : Lenovo Legion RTX
are you sure it only happens with my patch? I didnt touch any rendering related. Does it happen every time you start vam with my patch?
 
BROS
BROS
BROS
BROS


IN \VaM_Data\boot.config
SET


EVEN MORE FREE FPS

This removes almost all of the CPU bottleneck remaining after the patch. GPU usage in my Kpop Dances scene jumped from 70% to high 90% after the config change.

Wondering if there are more boot.config settings we can tweak for VaM. Saw similar posts on other Unity games being optimized by changing boot.config

I don't know what this actually changes in the engine, are there any drawbacks like physics glitches on changing this config? If so, maybe worth creating a dedicated thread for users to test this change.
 
[threads]
computeColliders=2
skinmeshPart=2
applyMorphs=2
skinmeshPartMaxPerChar=2
applyMorphMaxPerChar=2
affinity=1,2,3,4

[threadsVR]
computeColliders=2
skinmeshPart=2
applyMorphs=2
skinmeshPartMaxPerChar=2
applyMorphMaxPerChar=2
affinity=1,2,3,4

[profiler]
enabled=0

Cpu = Intel 6600k (4 core, base clock 3.50 ghz -- 3.90 ghz turbo, 6mb cache);
Gpu = Nvidia 1070 @8gb vram;
32gb Ram;

It's an old rig by today's standards and the gains in performance for me were huge. The UI in VR ( Rift S ) is smooth like never before with the almost constant 80fps (Rift S refresh rate) with 1 person active. Have not tested much with 2 but the gains are sick....
 
BROS
BROS
BROS
BROS


IN \VaM_Data\boot.config
SET


EVEN MORE FREE FPS
1708171684619.png

I only have one of that out of 2. Can i just paste the other one myself?
 
Finally had some time to figure this out...my memory should of been set to 6800 instead of Auto in the Bios, ended up defaulting to 2000. Changed it and restarted a few time and it works.
 
I have a pretty old machine and I'm not tech-savvy. which settings should I use for this setup?

AMD Ryzen 7 2700 Eight-Core
16GB RAM
 
Just changed boot.config file.
Holy crap
[HT off, v12 of the patch with the same settings i posted earlier, no changes to any hardware]
Benchmark-20240217-141949.png


Practically in every single test got ~ 10 fps more @1% lows

/ Edit /
Just out of curiosity i ran another benchmark on my bloated ~ 700GB install, with new boot.config file...
Results... Are just crazy!
Thanky you, @turtlebackgoofy for all your hard work!
With yours patch, and new boot.config settings, my bloated install runs now even slightly faster than vanilla, 'empty', VaM with original settings\dlls
Benchmark-20240217-151100.png
 
Last edited:
View attachment 336038
I only have one of that out of 2. Can i just paste the other one myself?
yes ofc,

wait-for-native-debugger=0
gfx-enable-gfx-jobs=1
gfx-enable-native-gfx-jobs=1

This removes almost all of the CPU bottleneck remaining after the patch. GPU usage in my Kpop Dances scene jumped from 70% to high 90% after the config change.

Wondering if there are more boot.config settings we can tweak for VaM. Saw similar posts on other Unity games being optimized by changing boot.config

I don't know what this actually changes in the engine, are there any drawbacks like physics glitches on changing this config? If so, maybe worth creating a dedicated thread for users to test this change.
as I understood it converts "high level unity rendering commands" to opengl/directx/vulkan/cuda commands with more worker threads, that way the commands reach the GPU faster and it can start working sooner, resulting in more FPS and the GPU consuming more power. Newer unity versions have this as a switch in the Editor: https://docs.unity3d.com/ScriptRefe...de.NativeGraphicsJobsWithoutRenderThread.html
@meshedvr I hope you already discovered it for vam2, as long as unity itself doesnt have bugs in this mode it should be fine.

In some scenes its a literal game changer, I am now GPU limited in VR when playing at 2x4k and when I switch to 50% rendering in steamvr (rendering scale 0.5 in vam has no effect besides looking bad) I now have 90fps in scenes that were unplayable before.
 
yes ofc,




as I understood it converts "high level unity rendering commands" to opengl/directx/vulkan/cuda commands with more worker threads, that way the commands reach the GPU faster and it can start working sooner, resulting in more FPS and the GPU consuming more power. Newer unity versions have this as a switch in the Editor: https://docs.unity3d.com/ScriptRefe...de.NativeGraphicsJobsWithoutRenderThread.html
@meshedvr I hope you already discovered it for vam2, as long as unity itself doesnt have bugs in this mode it should be fine.

In some scenes its a literal game changer, I am now GPU limited in VR when playing at 2x4k and when I switch to 50% rendering in steamvr (rendering scale 0.5 in vam has no effect besides looking bad) I now have 90fps in scenes that were unplayable before.

Yeah, I felt considerable improvement in VR from doing the boot.config tweak. Excellent find, thank you! Also nice to know that render scale inside VAM isn't helpful for VR performance.
 
Yeah, I felt considerable improvement in VR from doing the boot.config tweak. Excellent find, thank you! Also nice to know that render scale inside VAM isn't helpful for VR performance.
It may not be if using steam. I don't use steamVR and the in-game render scale acts as expected, quality and performance-wise;
 
This removes almost all of the CPU bottleneck remaining after the patch. GPU usage in my Kpop Dances scene jumped from 70% to high 90% after the config change.

Wondering if there are more boot.config settings we can tweak for VaM. Saw similar posts on other Unity games being optimized by changing boot.config

I don't know what this actually changes in the engine, are there any drawbacks like physics glitches on changing this config? If so, maybe worth creating a dedicated thread for users to test this change.
Huh, there is an "Only physical core" option in tarkov it seems, exactly what I also discovered by messing around.

gc-max-time-slice=10
This will improve FPS, but will make GC stutters very long
job-worker-count=5
not available in current unity version
Edit: it's not documented but does change things, job-worker-count=6 worked best for my 5950x where I use 8 cores for vam.
vr-enabled=0
hdr-display-enabled=0
had no effect
gfx-disable-mt-rendering=1
lowers fps
 
Last edited:
Hey, so I noticed that despite I cleaned my vam from leaky plugins that cause my heap grow and cause stutters every time the emergency garbage collector runs, with the addition of this mod my heap started growing again.
I tested this with a clean vam aswell. The more my fps grows the faster my heap gets flooded and the more frequent my micro stutters get (every time the heap gets cleaned up).
Only tested on desktop. The only thing I changed was the addition of this mod.
 
Hey, so I noticed that despite I cleaned my vam from leaky plugins that cause my heap grow and cause stutters every time the emergency garbage collector runs, with the addition of this mod my heap started growing again.
I tested this with a clean vam aswell. The more my fps grows the faster my heap gets flooded and the more frequent my micro stutters get (every time the heap gets cleaned up).
Only tested on desktop. The only thing I changed was the addition of this mod.
yes, v12 still has a location where allocations were made every frame. v13 will fix that.
 
Just changed boot.config file.
Holy crap
[HT off, v12 of the patch with the same settings i posted earlier, no changes to any hardware]
View attachment 336087

Practically in every single test got ~ 10 fps more @1% lows

/ Edit /
Just out of curiosity i ran another benchmark on my bloated ~ 700GB install, with new boot.config file...
Results... Are just crazy!
Thanky you, @turtlebackgoofy for all your hard work!
With yours patch, and new boot.config settings, my bloated install runs now even slightly faster than vanilla, 'empty', VaM with original settings\dlls
View attachment 336115
yeah the way VaM loads .vars is a real pain for performance. By having a lot of jsons loaded it makes a lot of small allocations that never get freed and make every single allocation slower, making every code in VaM slower. Also it's not possible prevent those allocations because you actually want to use the assets that are inside the .vars... I wish unity had a marker to tell the GC "this is something that will never get freed, put it on a different heap and let me GC collect it manualy"
 
Are these object large enough to go to LOH?
I wonder if forcing LOH defrag/compacting after loading everything would make future allocations faster.

I'm pretty sure the default for LOH is not to compact memory and it's different from SOH
 
Are these object large enough to go to LOH?
I wonder if forcing LOH defrag/compacting after loading everything would make future allocations faster.

I'm pretty sure the default for LOH is not to compact memory and it's different from SOH
they are very small, its millions of json values (the var metadata). The large content of .vars (clothing textures, etc) is ofc not preloaded.
In a perfect setting the small var metadata would be in one heap and the other objects that are generated while frames render would be on another heap. And the var metadata heap would have GC disabled and would only be GCed when a new scene loads.
 
Last edited:
Yeah, I felt considerable improvement in VR from doing the boot.config tweak. Excellent find, thank you! Also nice to know that render scale inside VAM isn't helpful for VR performance.
What is this boot.config tweak? Can you give more info on how to apply it. Prior link, from who you quoted, doesn't work.

But even without it, this is an amazing mod, creator is a God!
 
Huh, there is an "Only physical core" option in tarkov it seems, exactly what I also discovered by messing around.


This will improve FPS, but will make GC stutters very long

not available in current unity version
Edit: it's not documented but does change things, job-worker-count=6 worked best for my 5950x where I use 8 cores for vam.

had no effect

lowers fps
Some are dupes, but I asked GPT4 for additional values and it came back with the below. Not sure if these have been tried already.

  1. async-upload-buffer: Sets the size of the buffer used for asynchronous texture and mesh data uploads. Larger buffers might improve loading times at the cost of increased memory usage.

  2. async-upload-time-slice: Controls the amount of time per frame that can be spent on asynchronous resource uploads, which can improve rendering performance by spreading the uploads over several frames.

  3. async-upload-persistent-buffer: Determines whether Unity should keep the buffer for asynchronous uploads between frames, which can be faster but uses more memory.

  4. disable-unity-audio: Disables Unity's audio system entirely, which can save resources if your game does not require audio.

  5. scripting-backend: Chooses between Mono and IL2CPP. IL2CPP can sometimes offer better performance due to ahead-of-time (AOT) compilation.

  6. scripting-gc-wait-for-pending-finalizers: Controls whether the garbage collector should wait for finalizers to complete before collecting objects, which can impact memory usage and performance.

  7. scripting-runtime-version: Determines the .NET runtime version used, which can affect compatibility and performance.

  8. vr-enabled: Enables or disables VR support in the game.

  9. player-connection-debug=1: Enables the player connection for debugging. It is recommended to turn this off (player-connection-debug=0) for release builds for better performance.

  10. use-direct3d11-no-singlethreaded: Forces the use of multi-threaded rendering in Direct3D 11, which might improve performance on multi-core systems.

  11. force-d3d12: Forces the game to use Direct3D 12 on Windows, which could offer performance benefits on compatible hardware.

  12. graphics-jobs-enable-native: Another toggle related to graphics jobs, similar to gfx-enable-native-gfx-jobs.

  13. native-gfx-disable-mt-rendering: Disables multi-threaded rendering at the native graphics level.

  14. particle-job-system: Enables or disables the Particle System Job System, which can improve performance for particle systems by using multiple CPU cores.


I haven't had time to test mysel yet.
 
Some are dupes, but I asked GPT4 for additional values and it came back with the below. Not sure if these have been tried already.

  1. async-upload-buffer: Sets the size of the buffer used for asynchronous texture and mesh data uploads. Larger buffers might improve loading times at the cost of increased memory usage.

  2. async-upload-time-slice: Controls the amount of time per frame that can be spent on asynchronous resource uploads, which can improve rendering performance by spreading the uploads over several frames.

  3. async-upload-persistent-buffer: Determines whether Unity should keep the buffer for asynchronous uploads between frames, which can be faster but uses more memory.

  4. disable-unity-audio: Disables Unity's audio system entirely, which can save resources if your game does not require audio.

  5. scripting-backend: Chooses between Mono and IL2CPP. IL2CPP can sometimes offer better performance due to ahead-of-time (AOT) compilation.

  6. scripting-gc-wait-for-pending-finalizers: Controls whether the garbage collector should wait for finalizers to complete before collecting objects, which can impact memory usage and performance.

  7. scripting-runtime-version: Determines the .NET runtime version used, which can affect compatibility and performance.

  8. vr-enabled: Enables or disables VR support in the game.

  9. player-connection-debug=1: Enables the player connection for debugging. It is recommended to turn this off (player-connection-debug=0) for release builds for better performance.

  10. use-direct3d11-no-singlethreaded: Forces the use of multi-threaded rendering in Direct3D 11, which might improve performance on multi-core systems.

  11. force-d3d12: Forces the game to use Direct3D 12 on Windows, which could offer performance benefits on compatible hardware.

  12. graphics-jobs-enable-native: Another toggle related to graphics jobs, similar to gfx-enable-native-gfx-jobs.

  13. native-gfx-disable-mt-rendering: Disables multi-threaded rendering at the native graphics level.

  14. particle-job-system: Enables or disables the Particle System Job System, which can improve performance for particle systems by using multiple CPU cores.


I haven't had time to test mysel yet.
those are mostly made up parameters lol. I will try to delay the GC to the GPU rendering though, the CPU is doing nothing in that time. Also the stuttering now happens somewhere when the rendering happens, which is not noticeable it seems.
 
Last edited:
Back
Top Bottom