gfx-enable-gfx-jobs=1
gfx-enable-native-gfx-jobs=1
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?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
You are right, its happeninfg with or without, sorry and thanks for great plugin. I deleted my post.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
BROS
BROS
BROS
BROS
IN \VaM_Data\boot.config
SET
EVEN MORE FREE FPS
yes ofc,View attachment 336038
I only have one of that out of 2. Can i just paste the other one myself?
wait-for-native-debugger=0
gfx-enable-gfx-jobs=1
gfx-enable-native-gfx-jobs=1
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.htmlThis 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.
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.
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;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.
Huh, there is an "Only physical core" option in tarkov it seems, exactly what I also discovered by messing around.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.
This will improve FPS, but will make GC stutters very longgc-max-time-slice=10
not available in current unity versionjob-worker-count=5
had no effectvr-enabled=0
hdr-display-enabled=0
lowers fpsgfx-disable-mt-rendering=1
yes, v12 still has a location where allocations were made every frame. v13 will fix that.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.
oh sweet, thanks for the headsupyes, v12 still has a location where allocations were made every frame. v13 will fix that.
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"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
they are very small, its millions of json values (the var metadata). The large content of .vars (clothing textures, etc) is ofc not preloaded.Are these object large enough to go to LOH?
I wonder if forcing LOH defrag/compacting after loading everything would make future allocations faster.
GCSettings.LargeObjectHeapCompactionMode Property (System.Runtime)
Gets or sets a value that indicates whether a full blocking garbage collection compacts the large object heap (LOH).learn.microsoft.com
I'm pretty sure the default for LOH is not to compact memory and it's different from SOH
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.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.
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.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
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.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.
- 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.
- 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.
- async-upload-persistent-buffer: Determines whether Unity should keep the buffer for asynchronous uploads between frames, which can be faster but uses more memory.
- disable-unity-audio: Disables Unity's audio system entirely, which can save resources if your game does not require audio.
- scripting-backend: Chooses between Mono and IL2CPP. IL2CPP can sometimes offer better performance due to ahead-of-time (AOT) compilation.
- 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.
- scripting-runtime-version: Determines the .NET runtime version used, which can affect compatibility and performance.
- vr-enabled: Enables or disables VR support in the game.
- 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.
- use-direct3d11-no-singlethreaded: Forces the use of multi-threaded rendering in Direct3D 11, which might improve performance on multi-core systems.
- force-d3d12: Forces the game to use Direct3D 12 on Windows, which could offer performance benefits on compatible hardware.
- graphics-jobs-enable-native: Another toggle related to graphics jobs, similar to gfx-enable-native-gfx-jobs.
- native-gfx-disable-mt-rendering: Disables multi-threaded rendering at the native graphics level.
- 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.